track leanVM main, add gossip arrival metrics

[bomanaps]

We have moved our signature stack onto leanVM main (a5909d18) the new internalized XMSS with 32-byte keys, postcard secret keys, and a prover permit so we never prove concurrently genesis keys need regenerating, so this shouldn't merge into devnet-5 yet. We also added the six new gossip arrival metrics from leanMetrics #40 this should land on its own devnet-* branch e.g. devnet-5-leanvm-main so CI publishes it under a separate image tag and the devnet-5 tag keeps serving the live devnet.

[bomanaps]

Hello @ArtiomTr please can I get a review on this?

[ArtiomTr]

so this shouldn't merge into devnet-5 yet

So no merge then?

We also added the six new gossip arrival metrics from leanMetrics #40 this should land on its own devnet-* branch e.g. devnet-5-leanvm-main

devnet-5-leanvm-main branch name doesn't make any sense. We can just start devnet-6 branch, as probably those changes should appear in the next version?

[bomanaps]

so this shouldn't merge into devnet-5 yet

So no merge then?

We also added the six new gossip arrival metrics from leanMetrics #40 this should land on its own devnet-* branch e.g. devnet-5-leanvm-main

devnet-5-leanvm-main branch name doesn't make any sense. We can just start devnet-6 branch, as probably those changes should appear in the next version?

I don't think this belongs on devnet-6 since it's just tracking leanVM main, not the next version's features what if we create a plain leanvm-main branch and add it to the release.yaml triggers? that way CI publishes sifrai/lean:leanvm-main and devnet-5 stays as it is, the plan is to merge this into devnet-5 eventually, but I want to test it with the other clients on a bigger devnet first and compare performance against the current build.

[ArtiomTr]

I don't think this belongs on devnet-6 since it's just tracking leanVM main

It is not "just" leanVM update - you're changing signatures, keys - it is essentially large change.

but I want to test it with the other clients on a bigger devnet first

Which devnet? Devnet5?

what if we create a plain leanvm-main branch

I don't see a purpose. If you need a test branch, for doing experiments, then why not building under your own docker image?

[bomanaps]

I don't think this belongs on devnet-6 since it's just tracking leanVM main

It is not "just" leanVM update - you're changing signatures, keys - it is essentially large change.

but I want to test it with the other clients on a bigger devnet first

Which devnet? Devnet5?

what if we create a plain leanvm-main branch

I don't see a purpose. If you need a test branch, for doing experiments, then why not building under your own docker image?

Before I go the own-image route, do you mind if I share an image I build with the other client teams for interop runs? I remember you weren't in favor when I wanted to build an image and hand it to Katya for a devnet, so I would rather ask first and for context, the other clients already ship two tags, their devnet-5 image and a new leanVM one, and that's what I want to test against, this also can not be validated on my local devnet alone ethlambda is already running 64+ validators on the new leanVM, and I can't run more than 5 nodes locally, so I need to join a proper multi-client devnet to get meaningful numbers.
The reason behind all of this is the finalization issues on the devnet Emile updated leanVM and pointed everyone to this commit to check if it stabilizes things, every client hit the same wall here, no amount of client-side optimization was enough, because the problem was never how optimized any of our code is, it's how much of the slot time the type 2 SNARK proof eats up.

[ArtiomTr]

sorry, took a bit too long to review, merged now