SSV: Ethereum Lite?

Transcript

Hi everyone. Thank you for coming today. And a special shoutout to the SSV community. It's a pleasure to be in front of you. I'm Shane and I work over at Sigma Prime. I've recently been focusing on Anchor, which is a Rust implementation of the SSV protocol. Recently, Vitalik put out a blog post that was about DVT light, which is kind of a provocation on what simplifications could be done in the DVT world.

And I think that's a really interesting question to explore. But over in a SSV world, I'm interested in exploring like how we have client diversity and how we can use things like shared specs and explicit forks to make sure that we're operating safely and performantly. So, good to start would be to explain how SSV works in a nutshell. On the left, you can see a validator key that you'll be managing and it can actually be split into multiple shares, basically partial keys, using Shamir secret signing.

And those partial keys will then be distributed to, let's say, a cluster of four operators. And they can use these keys to sign partially a duty that's coming in from the beacon node. Maybe they're managing multiple validators and within one slot, they could be having to do like two aggregation attestations and like a sync contribution as well. Well, in this world, we can then use We want to agree on what data that each one of these operators are going to sign.

So, that's where we use QBF T consensus to agree on the data. And then over a libp2p protocol, same as Ethereum, we're going to make sure that we are able to get partial signatures passed around and each operator will receive that and therefore then able to like hit a threshold, sign and with a Let's say for the three out of four case, if we get three operators that have been able to receive the partial signatures, they can then reconstruct the actual signature of the duty and pass that to the beacon node.

It's interesting to consider how this is different from like a normal high availability setup. With high availability, you have more of like a single trusted path. And it's possible that you could have, let's say, a bug that if even if you have failover redundancy, they could still implement have the same problem and same implement the same mistake. But on the right, you can see more of like a distributed setup where it's possible that each one of these like boats or SSV operators can be running different infrastructure, like to say different beacon node clients and different EL setups. So, yes, it increases your potential for uptime, but also just changes the type

of like failure mechanisms that are possible in this setup. A little bit more into that particular example. Let's say you have like four operators. One could be hooked up to Lighthouse, another one Teku, another one Prism, let's say Lodestar. Possible that there is some consensus bug that one of those operators is experiencing, right? But again, with SSV, since you have like three out of four in this case threshold signing, as long as like a those operators one, two, and four received enough proper partial signatures from their peers over P2P, then you're still going to get the correct attestation. And then below would be like high availability setup where

you could have a primary and also still a backup, but you know, still possibly the wrong attestation will get partially signed. And furthermore, in SSV world, since it's possible to have like client diversity, imagine like the boats on the left being like a Go version and like a Rust version of an operator. They are independent implementations and therefore, you know, they could potentially sway around and drift. But if you have something like a shared spec, like a shared protocol surface and explicit forks, you can kind of get them into alignment, make sure that they're able to interoperate over P2P properly.

And here we line out the like normal flow of how we implement that like shared protocol surface. If we want to have some change in SSV world, we will first like create a SIP for it. If it gets agreed upon, it'll move over to becoming a SSV spec where we'll implement the core behavior that these multiple clients will have to then implement. And if you also doing SSV spec, you want to have spec tests, too, that the different clients can ingest. These spec tests could look like SSV serialization or deserialization of a block proposal. And as long as like both clients are able to ingest these JSON test pictures and get the same results,

you feel pretty confident that you're going to be able to interoperate properly. So, then the Go SSV and Anchor nodes will then do like devnet and testnet interops where we will, let's say, be in hoodie and make sure that their duties are being signed properly. After that, we can do an explicit network upgrade. And as as I mentioned, we have SSV Go and also Anchor in Rust just to promote the client diversity and again to like reduce the risk services that are possible as opposed to having a single implementation with one code base, you could potentially have that become the entire spec and a lot of

different failure mechanisms associated. Furthermore about Anchor, it is the newest client to be created. It's been in production for a few months now and what's kind of special about it is that it re-implements or actually reuses a lot of the crates that are created by Lighthouse and we all know Lighthouse is a pretty battle-tested Ethereum consensus layer client. So, we can inherit like out of the box things like its slot clock or beacon node fallback, slashing protection, its validator store. So, the point is not to like rewrite a bunch of code if you can already reuse some really like safe stuff.

And yeah, just to like go a little bit deeper into that, you can see at the top the Lighthouse validator services. Maybe it's a slot and you're going to have to manage multiple things such as sync contributions and block proposals. We can use those Lighthouse validator service crates for either Anchor or Lighthouse because Rust is quite modular in that way. As long as you have, let's say, some shared trait. In this example, it's the validator store trait. You can think of a trait as just a shared contract to have some same result given same inputs. So, on the Lighthouse side, if it's asked for a, let's say, sync committee contribution, it just does a local signing of that object. But in Anchor, we use the same trait, but then

re-implement with QBF T consensus to agree on the shared data and also create partial signatures based off that, pass them around, get the threshold signing and then pass the signed duty back up to the Lighthouse validator services. So, the benefit here is that we get over like 5,000 lines of Lighthouse code for free. And also like furthermore the like slashing protection kind of comes along for the ride as well to keep your ETH safe. Really nice there. And just a little bit of differences between Anchor and SSV. SSV Go specifically. SSV Go will be more of a light runner-based setup where if you have a specific duty, like block proposal, it'll be a different flow

compared to attestation aggregation. Whereas in Anchor world, in Anchor, we will do a more like modular setup and use different like shared states. In this setup, you can see like the duty service where you'll have something like a hash map that will manage all sync duties, all attestations that are required for that particular slot. And also whenever it's time to pass around those shared consensus data objects, we can manage those through a shared QBF T manager. And the point here is just that it's nice to have very different implementations, but as long as we're using the same shared spec, we'll have guaranteed the same behavior in the end.

And it makes it more difficult to attack the very different architectures. And yeah, I think at this point of the presentation, it's a fair question to ask like what has any of this like discipline that's kind of like Ethereum has actually produced. So, let's try to see if we can prove that. Here's an example for attestation aggregations and sync contributions. During a slot at about two-thirds of the slot, it's possible that a committee SSV operators will have will be managing validators who have to do both, let's say, two aggregation duties and a sync contribution duty.

In our current flow, this is going to instantiate like three different QBF T instances for getting consensus and also passing around multiple partial signatures over the network. And that's kind of a heavy, so many messages, right? And this SIP for aggregating the committee consensus actually packages all those aggregated attestations and sync contributions into a single package and passes that around the network. And then the same thing for partial signatures. It can just be one object that gets passed around as well. So, we get a pretty significant decrease in network traffic.

Uh this is a example they did for the SIP where I use like a Monte Monte Carlo simulation and against like a mimicking of a main net and you saw a reduction from about 1,700 messages per second down to about 600 messages per second. So, 66% reduction. And uh yeah, it's pretty solid. Uh the next example is one of my favorites. It's because it's not really related to duties, it's just purely networking. Currently these committees of operators can share operators. In this example, you know, they both share like let's say operator 7 and 11 for and on the left is what we currently have. The

pseudo-random kind of selection of which subnets that they're going to be a part of for that committee. Um and currently, you could be like sharing the same operators, but they'll end up in different subnets, which is a little bit inefficient. So, the SIP has the idea of MinHash. So, you can think that if like committees A and committee B both share an operator who happens to after you hash his operator ID ends up being the lowest value, then that will signify which like gossip subtopic they're going to end up on and makes it to where like you're more likely to have if you're an operator to be just in one subnet. So, a bit more also efficient there.

And uh this last example is actually a little bit more of how like SSV can also be pragmatic. Not everything requires a SIP and SSV spec to be able to like make improvements. Some things can just be client-specific. And this example would be if you had an operator who is connected to multiple beacon nodes, you can then query each one of those beacon nodes in parallel and get back an attestation from each of them and then just use some scoring mechanisms to figure out which one is the most accurate and use that as like the data that all the operator is going to sign and then, you know, get the partial signatures and gossip that back and uh send to the beacon node.

And once I introduce our upcoming bull fork as well, we're currently in a devnet phase of testing out some of the features that I just mentioned, the MinHash deal and also aggregator community as well. Um it's nice to have these processes cuz again, like once we complete said devnet testing interrupt, we feel like it'll be much less of a potential like attack service, risk will be down and we're just going to be moving in the same direction. Yeah, what is going to be coming in the future? One of the biggest things will be EPBS where we'll be introducing a new payload timeliness committee and with said payload timeliness

committee, we'll also then have shorter like a restructuring of the slot and that'll have some different timing constraints of when we need to produce, let's say, attestations. And with that, you know, is an increase in complexity on the SSV protocol. It just kind of then proves to you that the shared protocol service, these SSV specs that we write in the SIPs are more important than ever to get right so that way we can tackle these more complex problems that will be ever coming.

And finally, we have what how is this important for the like node operators themselves? Uh it basically just gives you more options, right? Like you can be we took the abstraction of client diversity and brought it up to the operator level instead of just being at the consensus layer or the execution layer. You now have the ability to configure an operator with like a different like SSV operator implementation, like the Rust or the Go. And then also, you can just have multiple different options for beacon nodes and execution clients as well. So, it's nice to have this level of like optionality as an operator.

And also, Ethereum might learn resilience like the hard way as I mentioned and I just want to say like SSV can adopt those habits a bit earlier with the hard forks over time with Ethereum. They came up with, you know, with the consensus specs and all the devnet interrupts that they do based off of like learning the hard way, right? It was very tedious times. I'm sure they went through a lot of struggle and with multiple client implementations, it becomes like very important for a protocol like SSV to do the same as well.

And yeah, I just want to say thank you all for coming. Really appreciate your time. Cheers. We have time for one question. Well, thank you.