Alon Muroch - Compose Network A New Validator Revenue Opportunity

Transcript

Awesome. Hey everyone, my name is Alan. I'm the CEO of SSV Labs. Um, we are building Compose, which is an interop layer that brings synchronous composibility to Ethereum. Um, we've been also the team behind SSV Network, uh, which I'm sure a lot of you know. Uh, SSV Network is, uh, the largest distributed validators, uh, protocol on Ethereum today with roughly 5 million ETH staked. Uh, the second largest protocol on Ethereum. um in staking with 14% of the total ETH staked in Ethereum and um with amazing partners building on top of us and of course uh Compose is actually building on top of the SSV validator set and we'll see in a

second how how that works. Um when we uh as as Ethereum started to talk about scalability, actually the original plan was to do um Ethereum sharding which is basically kind of split up the state of Ethereum into different u kind of independent chains if you will and each chain has its own uh way of building uh their blocks and somehow magically Ethereum will combine all of those chains including some kind of interop or composability between those chains and that will be the way to to scale Ethereum. Um that been kind of the the dream vision behind Ethereum for quite a long time. And uh a few years ago, Vitalic and others in the EF kind of

realized that doing sharding is very very difficult. And so we pivoted towards a rollup ccentric road map which has some of the characteristics of uh shards. Uh for example, they do settle on Ethereum. They do derive their security from Ethereum itself. um but without any interrupt or at least uh built-in interrupt between them. Um and of course that created what we know today as kind of the roll uh rollup centric roadmap um with many many different rollups. I think today we have roughly 100 plus rollups um running on Ethereum and a bunch of them uh continuing to kind of join and even some L1s are turning into uh roll-ups. But it also created fragmentation, right? Um

each rollup even though they settle together on Ethereum still has its own state uh and for by many consider its own uh chain and so DAPs are not necessarily can call one another. Contracts cannot call one another. Liquidity is fragmented and of course users um are kind of coexisting on a bunch of different rollups at the same time. So um it it feels like Ethereum is not really one piece, right? It's it's kind of Ethereum in the middle and a bunch of economic islands around it. Um which uh which I think kind of goes against um you know what Ethereum is trying to achieve. But also uh we we should look back in history with kind of looking at similar architectures like

Cosmos for example and and see that as a warning of what could happen if we don't really focus on the way that rollups in between themselves can actually interact. Um there are a few kind of quote unquote bridges that were built along the way. Um but none of them are really doing the job of of kind of composing together or making Ethereum this one uh big continent if you will uh together. Um one of those solutions is a synchronous message passing which is essentially a nice way to say that you can pass messages between rollups through some kind of a trusted committee or oracle. Uh but those messages um you don't have any guarantees on on when

they will be delivered uh or if they will be even be delivered. Um and if you want to compose a bunch of different things in one transa one go you need to do it block byb block transaction after transaction. This is the kind of the asynchronous property of those messages. And also most importantly the latency between them is quite um it's quite big. And so in terms of composability it's not really a great tool to use. Another type of solution are intents. Intents actually uh kind of um takes a completely different approach where the user describes what they want to get and then off-chain intermediaries kind of try to figure out how to execute. So uh for example, swaps and crosschain uh bridging work similarly. So I'm as a

user on chain A, I want to get the same token or a different token on a chain B. I say how much of those tokens do I want to move and what is the fee I'm willing to pay. The problem is that it's it's heavily based on intermediaries and liquidity. Meaning that ultimately the types of use cases are limited because if you make very complicated use cases, you'll need equally complicated solvers or off-chain intermediaries and also it's very liquidityheavy meaning that somebody needs to front liquidity in order for intents to work. The result of that is that one not all rollups can actually uh tap into that and two ultimately it's very limited use cases and uh very limited amount of tokens with high liquidity. Uh again because

it's it's based on liquidity. Another point is that we're we're forgetting that actually when you want to bridge a token between rollups the end goal is not to bridge the token the end goal is to do something on the other on the other chain. Um and to that end there is no composability with intents because intents in of themselves are asynchronous meaning you request it once and at some point in the future somebody will uh complete that transaction. The UX is pretty pretty good like it's it's very fast but it's still asynchronous meaning composability is always a two three or four step uh process which again kind of goes against what we're trying to do with um with composability and interop in general in Ethereum.

What we want to present is uh something called synchronous composability. Synchronous composability is this idea that there are three main properties we really want to have when you talking about cross-chain transactions. The first one is encapsulation or composability. It's simply the idea that you can compose a bunch of interactions within one transaction. So imagine that you want to transfer your assets to another chain and then do something with a contract and then return and go to another chain. It seems obvious that on Ethereum you can do that, right? Of course, there are no chains on Ethereum.

But if you want to compose a bunch of contract interactions on Ethereum, it's trivial. And so that's the composability or or encapsulation part. The second part is automicity, meaning that all of those interactions happen together or don't happen at all. It seems minor, but it's actually one of the most fundamental properties in financial transaction. So imagine that you want to transfer or swap a token. You want to guarantee that your token that you're selling is going out and something goes in the token you swapping to. But those are codependent, right? You cannot have a situation where you're just sending your tokens and not getting anything back and obviously vice versa, which is kind of a double spend uh problem. The third property is synchronicity. Meaning

that everything I've talked about happens instantly in one transaction, not across multiple blocks, uh, which can cause state changes and rollbacks and stuff like that. And so those three properties uh are something we're all used to on Ethereum, but when we port them to cross rollup transactions, it's called synchronous composability. We're all used to having that on Ethereum, but now we want to bring that to um to to cross rollup uh interactions. And if I need to kind of chart how we compare all of those types of solutions, then you either have currently either have very generic but very slow approaches to interrupt like asynchronous message

passing or you have pretty fast but very specific type of uh transactions which are intense. With synchronous composibility, we try to do both super fast but also super expressive and generic. So you can basically do any type of interaction you are used to do on Ethereum between rollups. And that's what compose is. Compose aims to um consolidate liquidity deps and users. It aims to create a user experience which is just like Ethereum. It's not between rollups. It's not in it's just Ethereum, right? Uh, and it's instant, meaning that whenever the transaction hits the block, that's it.

That's where it's executed. There's no multi-block type of waiting and latency and stuff like that. And there's ZK guarantees for automicity, meaning all everything you want to do happens or doesn't happen. And there's no kind of this locking and unlocking or waiting for your assets to unfreeze if if something went bad. And so that's what kind of Compose is aiming to do. Um and the tech it's built on top of is called um shared publishing. The shared publishing is actually built on top of SSV validators. Meaning that as validators are actually the ones running this piece of software. The idea there is to have it as a credibly neutral layer that many rollups can integrate to. Doesn't have to trust anyone. It's

just Ethereum validators. And that shared publishing is the one that guarantees synchronicity and automicity for those transactions. What happens is between rollups u the sequencers of those roll-ups can actually form the crosschain transaction. Each rollup has its own independent sequencer and they just produce blocks and zk proofs for those blocks. Those blocks and zk proofs are then aggregated using the shared publishing and then settled on Ethereum obviously guaranteed by zk proofs. It all starts with the concept of a mailbox. So each rollup has its own mailbox with in andout boxes and when they want to move move uh messages or in

other words call other contracts on other chains they simply move messages in between. Inbox is the messages you on rollup a receive and the outbox is obviously the messages you want to send elsewhere. And the cool part about it is a very simple construct, but it's a very powerful one because it's it's kind of the basis on which we can guarantee the execution and automicity and validity of that execution between rollups. The way it works is through simulations. When you want to do a crosschain transaction, the sequencers simulate between them the actual transaction. It happens very very fast. We're using a very lightweight consensus protocol which is kind of a a very simplified version of the BFT

protocols we're all used to from staking for example on Ethereum and other um and other protocols. By the way, we're using a BFD protocol in SSV. This is a much more lighter weight um version of that and it's super fast and they simulate between one another the transactions uh the transaction the crosschain transaction and they prepopulate messages in the inbox respectively and they come to a decision if they want to proceed to execution or not and if they do want to go to execution each one of them executes. Now what happens in reality is because we have the simulation part each rollup when it executes it's executing as if it's a synchronous action meaning it can do one

after the other because we already did the simulation part they do the execution they produce a block produce a zk proof and send it over to the shared publishing layer which are the SSV validators the validators are aggregating those zk proofs together and also add uh into a superb block um validity um uh uh conditions for the mailboxes meaning that the inbox of one rollup or the root of the inbox of one rollup has to be equal to the root of the outbox of another. This is how we check for validity and the zcap proofs are also guaranteeing the atomicity because if everything anything goes wrong in it they'll have to reorg and redo the transaction and so there's no

way that one side only executed versus another. I want to go back to this slide. What you'll notice is we have the optedin rollups that are part of compose but we also have external roll-ups here base arbitum and other roll-ups as well. Because we have independent sequencers, we can actually create synchronous composable transactions between a compos rollup and those roll-ups. Meaning that composed roll-ups can tap into the liquidity users and deps of the bigger roll-ups base arbitum optack and op mainet and so on in a seamless transaction and that's a really really powerful thing because we can bootstrap from day one using the liquidity depths

and users of those bigger rollups which is uh super important. And so this is kind of how the shared publishing works. But the cool part about it is synchronous composibility opens up the door for much more use cases than we're used to in intense or as synchronous message passing. The first two ones bridging and swaps are done instantly, no latency, without any intermediaries. You can literally bridge a token or swap a token uh with no latency. The same way it feels and looks like on Ethereum, a single transaction and it just it's it's done. And we actually just now made it so that we can um swap a token on another chain and return the asset we

swapped into the original chain in one transaction. That's it. It's literally as fast as it can be included in a in a block. And so that's a very powerful primitive. But synchronous composability goes far beyond swaps and and and bridging. It goes into things like cross-chain flesh loans or you can have crosschain transactions which involve more than two rollups, three, four, five different rollups. You can have multi-rollup DEX routing which is incredible. Find the best price out of many roll-ups, not just one. You can even do NFD bridging. The implications on developers is immense because it enables you to do arbitrary read and rights to any rollup in any contract.

And also it introduces a concept called a singleton depth deployment. Meaning that because you have synchronous composibility and because the there is no friction between roll-ups anymore. As a developer, you can simply uh deploy your contract once you don't need to deploy it on every rollup. And so you consolidate liquidity in users and remove a lot of the overhead of using of of deploying on many many different rollups. And that's a very powerful shift in the way we think about interrupt and the way we think about uh the rollup ccentric roadmap. It also has the side effect of actually enabling the smaller uh rollups to bootstrap using the bigger ones. And so in terms of competitiveness, it it really really

pushes the boundaries of what's possible. And so all of that is introduced with synchronous composability. I think this is the way Ethereum should be talking about interrupt and talking about its roll up roadmap. Instead of trying to patch things with uh temporary solutions, we need to look at the problem and understand that the UX is the most important thing. What can we enable from a UX point of view that enables Ethereum to just feel like Ethereum, not be on Ethereum and feel like base or feel like uni chain and feel like any other thing. Uh, and I think that's that's critical for Ethereum and Ethereum's future. Um, in terms of the road map, we've been uh working on this um behind the scenes for a few months and we're uh just ready to

release the first test net for uh compose. Um throughout uh and until the end of year, we'll actually be in integrating for the first time base into Compose. So, you'll be able to do on test net uh transactions with base uh the base test net. And then uh throughout 2026 we'll be starting to roll out uh compose in various pieces um and so on. Uh and so if you want to learn more uh we actually have a cool compose lounge today um scan the QR code if you want to join uh and talk more about interrupt and and how compose can really help Ethereum. Thank you.

>> Thank you very much Alan. Uh, we do have about five minutes for questions before break. Are there any questions from the audience here? Oh, perfect. I can have you stand up and walk this way. >> Hi there, Alan. Um, if that works, it's kind of the holy grail, right? Um, right now SSV has 14% of staked ETH. What percentage of staked ETH needs to be supporting this shared publisher before critical mass is hit for the compos network.

>> So it depends on what what exactly in the life cycle of compose you're talking about. I've just talked about L2 to L2 composability. But there's another big elephant in the room which is L1 to L2 composability that requires real-time ZK proofs. And to that end, you actually need u much more validators potentially um almost all of the validators on Ethereum because then you can have real time proving and real-time execution between L1 and L2. That's a a bit a bit into the future for current currently to do L2 to L2 composibility. You don't need any more validators. Um it's I think it's decentralized enough as as a layer for other rollups to trust and and be credibly neutral with uh to have this amount of validators. have enough

validators with enough entities and enough different actors with it within it to I think uh uh build a really solid base for it. If we're looking into the future and want to have L1 to L2 real time composability uh then it's going to take a bit more but it also depends on real-time ZK proofs. >> Uh how does compose fit into the EF's coordination efforts around chain abstraction? So chain abstraction I think is is more in the wallet side at least uh from what I know. Um and I think it goes very very very well. I haven't touched upon it yet here but we're making u heavy use of account abstraction and user ops uh to achieve the best UX we can. We actually

heard a conversation between the major L2s yesterday at the main event where they talked about adopting specifically base adopting account abstraction and 7702 natively in their wallets. And so all of those things are very much things that we need as well. Um and so we are making use of all of those bits and bites that the EF and others are building. Uh I think account abstraction can really work well in this. By the way, uh I don't know if you saw the announcement by the account abstraction team with the Ethereum interop layer uh to today or tomorrow they have their event, but they're making the same type of use cases uh with account abstraction and user ops as we do meaning that you sign once and you execute on multiple chains. Uh and so in in various ways we

are using all of those uh kind of techniques and uh and bits and bites. >> Excellent. I have a a follow-up question to the amount of validators. So if I understand this right, the idea is to start with the SSV network but not stop there. So the way you would get L1 to L2 eventually is by opening this up to really any Ethereum value. >> Yeah, I think ultimately if compose is going to be the kind of the gold standard for interop, yeah, it needs to be open up for everything. When and where it kind of depends on uh where we get to. uh we'll start with the SSV validators obviously because it's easy and and and of course we're working on tight collaboration um but uh but yeah ultimately I think down the down the

road yeah potentially open it up to everyone >> perfect thank you very thank you very much Alan and uh you'll be around a little bit during break uh we have a break for the next 15 minutes so we're back here at uh 15 minutes >> thank you everyone