Where Sovereign Labs Fits In The Modular Thesis

Transcript

Welcome back to the Rollup. In today's episode, we sit down with Sovereign Labs co-founder Jim O'Zeir to discuss where Sovereign Labs fits in the Maza thesis. We talk about the noisy neighbor problem, Sovereign rollups, the rise of ZK virtual machines, how the Sovereign SDK is building a network of interoperable rollups, why builders should choose the Sovereign SDK, and some of the unanticipated side effects of their design choices. This was a semi-technical conversation in which we talked about things like state commitment schemes, but also talked at a higher level about some of the ideological and business logic choices.

Thanks for watching, and hope you guys enjoy. First, here's a quick word from our lovely sponsors. Welcome back to the Rollup. Today we

have a interview with Gem from Sovereign Labs. We're pretty bullish on app chains. I think something that we believe here on the Rollup is that we are excited to see uh non-EVM app chains launch, as well as rollups using um modular DA. I I put a tweet out today that was like, "We don't need more general purpose EVM L2s." Maybe that'll that'll uh ruffle some feathers. Maybe we can talk about the app chain thesis a bit. And also about what Sovereign Labs is doing with their SDK. Here today with Rob. Rob's got his golf shirt on. I don't know if he's got a match planned after the podcast, but Got the clubs in the back, too, if you can see those. My My plush Pudgy's

hanging from them. No, just just the shirt today. No tee time. But uh But yeah, tend to agree on the app chain thesis, on the golf thesis, and the Sovereign thesis. So, uh Gem, I want to kick it over to you. Hear a little bit about your story, how you got into in- into this world of sovereignty and uh ended up at Sovereign Labs. Yeah. Well, first of all, thank you very much for having me, guys. Um so, I joined the ecosystem around 2017, and quickly after like dabbling with smart contracts, building some of them, I noticed that like the main work that needed to be that needed to be done in the ecosystem was at like infrastructure level. I had used dial-up internet back in the day, and it felt

like we were in the dial-up era in terms of infrastructure. So, uh I quickly got very passionate about like working on that infrastructure level, and I joined the E2.0 team at ConsenSys. Uh I worked from like very early stages of like the prototype of the Ethereum consensus client Java Teku that is running in production and has about 25% of the Ethereum consensus network today. So I worked on that for a long time and after it went after the beacon chain launched and Teku was in production, I got out of the consensus team wanted to take a step back because I've always wanted to be an entrepreneur in like the tech space and I wanted to do something

that creates impact like pushes the space forward. And so I started looking around at that point like a friend like reached out like asking to like set up a like fund and I would take on like the research work. That work enabled me to like take a comprehensive look at all the like the infrastructure projects in the space and that's what I noticed like that's all that was when I read the Lazy Ledger white paper and I was like wow. Like the data availability problem like the data availability scaling is going to be solved. There are not that many like open questions left. Erasure coding is at the bottom of it and like Ethereum is going to implement one way of it.

Celestia is going to implement another way of it. There's going to be other other teams that do that. But like it's going to get commoditized and what needs to happen next is really commoditizing the execution layer. Really making that as simple to launch and as scalable as possible and as seamless to communicate as possible. So that's when I was like I need to start an infrastructure company to address the scaling issue on the execution layer and soon after I met my co-founder Preston and we basically started like asking questions around how can we build infrastructure that enables people to scale their applications, scale the execution as seamlessly as possible. And yeah, so basically And my story of getting into the modular space.

Um yeah, I'll stop there to see if you have any questions or if you want me to talk about anything else. Yeah. Is sovereignty important to you as a as a builder? Like do you care about like how much do you care about the original ethos of crypto in terms of sovereignty and kind of like this idea of being your own bank or this idea of um kind of the Ethereum as a nation-state versus like the the US? Yeah, I might have a little bit more pragmatic view on all on those issues. Um I believe that like all these crypto systems that we're building will be a new type of compute substrate where we enable uh completely permissionless and

censorship-resistant and verifiable backend systems, but they don't necessarily need to be like replacing the government. Like I just want to like basically um my the way I see it, we're building like backend systems now that like can't be shut down, can't be replaced, and that generally like really uh tells the entrepreneur inside of me that backend developers can build on top of the like the systems they've built. Companies can build on top of the system other companies have built without asking a lot of questions, without having like without having a lot of doubts about oh, is Twitch going to shut down my whole service? Can I really get an investment on this? No way because like Twitch literally really owns all

the IP and all the like they can shut down the APIs at any moment. Twitter has done that for a bunch of projects. So, I see it as like a like new type of um backend system standard uh like where like soon enough almost all the companies developing um infrastructure will want to do it on chain as because if they they do it on chain, they're promising their customers that they can shut up the service down at any moment, and so competitors doing it on chain will have a major advantage.

Uh, because they will be give a better signal to customers. And over time, this signal will be so strong, you will need to be on chain to actually, uh, be competitive long term. So, that's like I I'm obviously very excited about being able to like governments not being able to like uh, completely control your funds or like um, like I grew up in Turkey. Like there's a lot of monetary policies that affected all my friends and my like families like livelihoods. Uh but um, I think in the short to medium term, crypto's going to have like a way more, uh, practical effect on the way these general like uh, back-end systems and APIs work, rather than like having an

effect that changes states and how we like how humans govern themselves. That's going to happen like crypto's likely going to help that in the long run, but in the short and medium term, uh, from the business sense, I think these impacts are going to be, uh, sooner and more visible. Cool. Now, a more dialed-in, uh, question as far as blockchain development goes, do you believe in sovereignty for builders who can want to build their own app chains or their own execution environments or or their own roll-ups?

Um, do you believe that builders should have sovereignty and not have to deal with kind of noisy noisy neighbors or uh, uh, congestion at the at the block space or kind of share block space with other people? Or is there kind of a a different view? Yeah, I think there's a few questions packed in there. And one of them is like the noisy neighbor problem. The noisy neighbor problem is horrible. Like when you write an application, you don't want another completely random NFT application impacting your cost. Um, and um, like I think this was a solved problem in the Cosmos ecosystem or generally like any app chain ecosystem like substrate mostly.

Uh, but the problem is these L1 blockchain frameworks require you to launch your own validator set every time you're trying to like build an application that doesn't have the noisy neighbor problem and that's very costly and that requires a lot of like logistical effort from the like perspective of the builders. And so it's not super practical. So the noisy neighbor problem Jim as you described, this is the classic uh, separation between Cosmos and Ethereum. In Cosmos, uh, Cosmos requires you to bootstrap your own validator set, have your own token and this removes the noisy neighbor problems because all Cosmos chains have their own validators, their own little neighborhood if you will. On Ethereum, everyone kind of shares this

big neighborhood, this big Ethereum validator set. You get a lot of economic security, there's a lot of gates that guard this neighborhood and whatnot, but you have a lot of noisy neighbors because everyone in that Ethereum neighborhood shares their own validator set. Okay. So this is kind of the classic separation and I have a feeling there's a way with all the innovation that's been done with sovereignty, sovereign rollups and and now the sovereign SDK, there's a way to get the best of both worlds. So how how do we remove the need to bootstrap our own economic security and and still re- avoid and prevent this noisy neighbor problem?

That's a great question, Robbie. So to go back like to 2017 when Cosmos and Ethereum were like different visions of like scaling uh, blockchain execution uh, where like Cosmos was like we just got to have different state machines. If you need to like have different state machines, we got to have like different validator sets that secure each one of these and so they're going to have different securities, but it'll be fine. We'll use IBC to communicate between them and we can get IBC to like um, if none of the chains have like really low security, uh, like we can have generally a quite high security messaging between these roll-ups, between these chains. That was the Cosmos idea, whereas Ethereum was like, yes, you have like a single validator

set. Sorry, Yeah, that at the time it was like like proof of work chain. Like you have the miners and um like all these miners like secure the single chain, single state machine. And Ethereum Foundation and like researchers in the Ethereum ecosystem, they were all looking into scaling the single execution. But over time Ethereum and generally almost everyone like focused in the scaling space noticed that the way to scale like properly is through roll-ups. It's to basically creating a separation of concerns where the the like the layer where you need to have the security,

like the consensus layer this layer like is focused on ordering and data ability. And by that I mean like the only need the only thing roll-ups require really from the chain like they they run on is like the ordering of their transactions and the fact that these transactions are available for everyone to see and compute their own state of the roll-up. And so um basically the understanding was that we'll separate the concerns. This one chain will focus on data and we can scale data throughput well using techniques like erasure

coding. We didn't know how to scale like state like execution because like if when you when you there's just a limit on like how much you can execute on a single state machine. Like as like a state grows like so much, uh you run into issues like accessing the state from the disk. So, like you just like run into fundamental issues when you're trying to scale a single machine, but if your validator is trying to secure only data availability and ordering, those things are much easier to scale. Like if you're only trying to like scale like secure data, that's much easier like much easier to scale using techniques like

erasure coding. And so, that's generally the insight. Um so, now with like the roll-up architecture, we are um enabling one chain one individual chain to focus on the data side of scaling and uh you can have as many applications execution chains on top that inherit security of this chain. And um these execution chains do share the data from the chain below, uh but data is much more abundant and abundant and it it's easier to scale. So, the the noisy neighbor problem that you would have on a single execution chain is

much less visible, uh almost invisible, when you're when you're like execution chains only share the data from the chain below. Um for example, like with current like Celestia's current capacity or with like the block size increase they're planning to do, uh you would have to have so much so much like roll so many roll-ups uh that consume insane amounts of data until you see congestion. But um it's quite easy to create congestion on a single state machine, as we can see from Base or any other like um single EVM chain.

Awesome. Okay, so so as you mentioned uh data is much much more scalable uh than uh the execution layer. Now, what it what is it about the execution layer that isn't very scalable? Why is that a difficult problem to solve? It's mostly the state growth and the accompanying like state access times. The more state you have and longer time it takes for you to basically access certain objects from the state. And so it becomes at some point it becomes almost impossible to compute new state updates in time due to that.

Got it. Okay. And this is this is kind of what you hinted at as like the very core problem to why you got into this space. You saw that state state growth and state transitions were becoming a big problem. They weren't scalable and you said we've got to commoditize this execution layer. We've got to make these state transitions easier to append onto the blockchains. So, now kind of take us through like how you're able to commoditize the execution layer. What what is it about these state transitions What is it about that sovereign SDK that makes these state transitions so much easier? So much more scalable?

Yeah. And perhaps real quick Jim, maybe for the not so gigabrains, what is a state transition? Yeah, so state transition is how a state machine, a machine that holds some like data, like let's say like let the data is like one NFT and like you have some tokens and I have tokens. How do you go from state A where I have 10 tokens and you have five tokens to state B where you have 10 tokens I transferred you something. There was some like transaction and like you now have like at state B you now have 10 tokens and I have five tokens.

So um like that's the like that's the core of like state transition and how like how basically the state changes on a blockchain. Um And so the way we do this at Sovereign is by we enable anyone to bring any Rust code and we take it take this like business logic that people bring in Rust and we turn these into uh individual blockchains roll-ups that can be deployed on any other blockchain.

Uh so you write your application and your application let's say you wrote and you wrote your application and it is uh your like um Andy token chain and you can deploy that if you want to Bitcoin, you can deploy it to Ethereum, you can deploy it to Celestia, maybe you thought like data is quite cheap there. So we're making it super simple for you to build this um application chain application roll-up that really inherits the security properties of the blockchain it's deployed on. So I don't want you to like deal so so much about the security how like how you ZK prove or fraud prove your chain uh how you make sure like uh that you get can you can get forced

transactions, how you can get verifiability uh from the chain you run from. Like so when you write your application how like we're trying to make it as in seamless as possible so that you can get the safety and liveness of the chain that you're deployed on. Uh of like the base DA layer that you're deployed on. Uh so that's what Sovereign SDK enables. You just bring your business logic and we turn it into an uh application in the form of a roll-up that can be deployed on any base blockchain. Got you. And being very ZK focused as well from from my understanding, but also having like a uh some some other properties which kind of allow you to not necessarily need to do some intensive tasks um such as like creating entire circuits for each individual

roll-up. Um I know there's different types of ZK proving like there's like Plonky and like Air and like a couple others, which have different like circuit designs. We can kind of touch on that a bit. Um, but you mentioned how like the how this works from a business logic perspective. Could you perhaps go a bit deeper into that in terms of um kind of where that where the ZK uh and kind of logic crossover happens? Yeah, so one of our main insights when we like thought of building Sovereign was that there's so many teams focusing on the ZK cryptography.

And that's not necessarily an area with me and my co-founder that we're like the best at. Uh, we're really good at like generally like blockchain architecture, uh roll-up architecture. And so why should we spend so much time, especially having seen projects like Risk Zero, where they take Rust code and turn it into so like take they they're fully able to prove this Rust code. Like we don't need to or ZK roll-up teams we noticed don't really need to focus on the circuits of their own. Circuits are just like part of like the supply chain.

And as long as we build on good interfaces, where in our case is basically Rust, as long as we build in a good interface, we can uh completely bypass building our own circuits question and actually like let the market uh give us the best circuit performance possible because now there are multiple teams competing to build to build the best uh Rust compatible ZKVM. It's Risk Zero, SP1, now Jolt. And we can leverage the like the the leverage the performance and ease of use these tooling provides. So, we basically saw these like Rust compatible ZKVMs like I coming alive and we're like, "So, we're going to build all of the machinery

required to build a ZK roll-up, all the force transactions, all the proving the state accesses, everything that you might think uh that that like requires like that that is required to build a ZK roll up. We're going to build it in full purely in Rust. We're going to move so fast. We're going to like iterate so fast. Um and uh we're going to be able to get like the most performance from our sequencers because we're building on blazing fast Rust tooling uh and we're not like focusing any engineering bandwidth on optimizing the circuits. Other teams are.

Uh and many teams are. And so that was our main insight. That's also why So that bet paid off. That paid off well. So Yeah. Yeah. And that was made some 2 years ago. 2 years ago, yeah. Yeah. So you you saw like you you were thinking like there's not just going to be like one team building ZK VMs. There's going to be a ton. Yeah. Like Rust is a simple interface. As long as you have a very simple interface in like infrastructure world, things usually get commoditized and given this strategically, it made so much sense. And so like at the time So like We we started with Risk Zero because

they were the first one and they made our like they made us think, "Oh my god, like this can actually happen." Uh but uh and like a lot of like teams and VCs have thought like you're like a Risk Zero project, you're purely betting on them. And we were like uh we love Risk Zero. We love working with them. We think they're a great team. But no, you're just like not thinking like a bit like a few years ahead where like these things are definitely going to proliferate. And here we are. Yeah. Cool. Uh that's also just the why we enable people to build any Rust code to build their business logic with any Rust code.

Uh so they we don't have like some certain new environment. It doesn't need to be EVM. Any Rust code we're able to run as a ZK roll up due to leveraging Rust compatible ZK VMs under the hood. Okay. This is awesome. I'm going to ask you a dumb question. Yes. why would I use Sovereign SDK? I mean, I understand the rust and ZKVM capabilities, but why would I use Why would Why would somebody choose to build on Sovereign over like an alternative of EVM, SVM, Move, Cosmos SDK? Like Like why would I Why would I go and and build on your stack when there's already options that are more battle-tested and kind of like existed?

Yeah, that's a great question. So, we think of Sovereign SDK as basically a next-generation roll-up framework. There was a lot of roll-up frameworks. There's a lot of roll-up frameworks being built, all stemming from like the idea of scaling Ethereum, scaling the EVM. Uh we've basically our project that looked into all the roll-up systems that existed at the time and all the ways to build app chains at the time. And we're like, "How can we build the most flexible, the most easy like the most seamless to use, and the most performant roll-up framework?"

Uh and so, Sovereign SDK will provide a level of customization, flexibility, and sequencer performance, as well as ease of use to like bridge and like um faster and cheaper force transactions. Um All these things that really other frameworks just cannot provide because we're built from the ground up, first principles, how to like provide the most optimal UX for a roll-up application. And you're going to think that I'm picking on you now, but I promise I'm not. Okay, so I think that that was a good answer, and and there's there's quite a bit of a value and truth in there. The one things that The one thing

that these ecosystems have, uh which Sovereign appears to it's of not have, is this underlying base chain. Ethereum's got ETH, Polygon CDK has like Polygon, Cosmos is Cosmos, um Move has kind of Aptos, etc. This gives them almost like this unlimited distribution via the beautifulness of crypto economics and token economics, which we'll get into that, but you guys chose to not do that and not build your own base layer effectively, not be your own uh settlement layer.

Don't you worry about kind of distribution and business model and tokenomics and kind of revenue problems or uh general kind of uh competitive advantages in the SDK marketplaces marketplace compared to those who have a base chain? Yeah, I think there are two separate questions there. I'll first start with like developer tooling that you mentioned, like the ecosystem. Sovereign SDK will actually have a lot of ecosystem support and tooling right out of the box because we're not purely enabling app chains via Rust. We do enable that, but we've been building from day one with trying to be as flexible as possible to provide support for any virtual machine that you might want to put on top of sovereign

sovereign SDK. Like as an example, using Reth and REVM libraries, we built an EVM module and there are two teams following the our like EVM module example and building Move EVM modules for Sovereign SDK. And there is like one team that's starting and one team that's considering building an SVM module into Sovereign SDK. So, what will this mean? Um this will mean that the rollups that leverage the EVM module in Sovereign SDK will be able to launch EVM chains on any base blockchain, including Bitcoin, including Celestia, Ethereum.

There's a lot of the ZK rollup teams that you heard building EVM chains, ZKEVM chains on Bitcoin are using Sovereign SDK under the hood. Um and like Move EVM like teams that you've heard they're leveraging sovereign SDK. And so like the EVM teams that are building on us will get the full EVM compatibility. The only thing that will be different is the state commitment scheme because we're using our own state of the art state commitment scheme that my co-founder devised so that we have the highest performance like highest throughput possible for each individual of these rollups. But apart from that like metamask like the all the regular RPCs that you expect from an EVM

chain these rollups are going to have. They're going to have they're going to have that for the EVM chains they're going to have it for the move VM chains they're going to have it for the SVM chains. So sovereign SDK is going to plug in and is going to take advantage of the tooling that's built for each of these individual ecosystems right from the get go. Very cool. And you you brought into into the loop a new a new concept. If you want to finish that thought please. If you had something else. Yeah, I don't think we got the uh distribution base chain answer here. This is the sauce. I do have a follow I do have a a follow up but yeah please please finish that thought.

Yeah, so distribution wise I don't think we have any issues like people see how better of a user experience you can get building on sovereign how faster and cheaper for transaction can be how you can natively leverage the layers like Celestia without like having settlement settlement in Ethereum like the on Celestia Celestia leveraging interesting contracts and etc. I think thanks to that like we already have bunch of teams building on us. Like as I said like Bitcoin teams like new virtual machine teams teams that are like building keystore rollups that are trying to bypass cost of like verifying on the L1 every time they're making updates elsewhere.

Like that yeah and so I think at the moment at our alpha stage that we don't even have proper docs out and like want to get the test net and like we're seeing enough adoption already that we have no questions around distribution. That might change, but like we don't have any issues at the moment there. The reality is we've just seen that you can have a more simple and better architecture without a settlement chain. And as a company we're never going to sacrifice user experience and like the simplicity of the like product to have a settlement chain and to have tokens and etc. We think by building service businesses around sovereign SDK and by

supporting customers, by by supporting users of sovereign SDK as seamlessly as possible there are many ways to like earn revenue. But we don't want to architect our product just so that we have a good business model. We think we got to architect the best like best way that we think we're is going to benefit our users, our developers and will like the monetization will follow through the services we provide. That makes a lot of a lot of sense. I heard you bring in a concept there that it was a little bit different, but it sounds like it's a it's a significant feature of sovereign SDK. You talked about like some of the different elements, you talked about state

transitions, and then you mentioned this piece that your co-founder developed which was the the state commitment scheme. Could you could you talk a bit about like what taking a step back, what is a state commitment scheme? And then how were you able to adapt that so that it it is quite innovative and and brings this new user experience? Yeah, so this is pretty deep in the weeds, but a state commitment scheme I only mentioned that because we have some very exciting work going there that will enable us to increase the throughput for an each individual like roll up chain uh about 10 to potentially 50 times um of like what we're able to do right

now, which I think is going to be quite significant for the whole industry. Uh and so a state commitment scheme is um how like So, we talked about how like like in like a roll up is like we like roll ups are like or like blockchains are state machines. I have a balance of like I said five and you have 10. But, we need to basically compress the state like data of the state into uh like a single 32-byte 32-byte value or like single like value that is easy uh for um like light clients to read, people to make like proofs and like verify things, like for us to have an understanding of like, "Okay, like we have a bunch of state, but like what is the actual like

agreed upon um like state like state like all the the whole state?" And so, if for example, Ethereum uses the statement called Merkle Patricia tree. Polkadot also uses something similar. And um that's just um a custom way uh of Merkle-izing that whole state into a single value uh that everyone everybody can get a consensus on or when you're like uh bridging, let's say, a you only send this 32-byte value and then everything every asset transfer that you're trying to do gets Merkle proven, like gets tied to this like state root.

So, a state commitment scheme is a way to generate a state root uh for a given blockchain. And um it ties very deeply into how your state accesses uh are done. And so, uh given that for a single state machine, state accesses is the biggest bottleneck in crypto right now. Um having like sovereign state in one way enables like splitting the like the state problem by enabling you to launch as many rollups as you want. Uh but at the same time we want like the maximum performance from each individual rollup as well. And so having the state of the art

state commitment scheme will enable us to notch the throughput a quite a good amount on each individual like rollup. Um and if we want to dive even more in deeper into the weeds, the way this like uh optimization occurs is like we build base basically a new Merkle tree. Uh and this Merkle tree enables you to um basically make the database accesses uh more parallel rather than sequential sequential. Uh it has a few like few more optimizations too, but I'm getting out of my depth here.

Got it. Okay, so we won't dig into too many more of the nuances there, but um I've also heard of like you mentioned Merkle trees. I've heard of Verkle trees with a V. And then even more more recently I saw something come out of Lagrange that the ABS and they're doing Reckle trees. Are they I just want to confirm these are all examples of different state commitment schemes? Yeah, exactly. Yeah. I don't know about the Reckle cuz I just haven't read it. A Verkle tree is another like state commitment scheme. Uh Ethereum team is has been working on them Ethereum Foundation uh like uh a friend of mine has been working on that quite a long time. And the main point of that research that started so

that Ethereum validators can do stateless validation. And it's a interesting goal. Um like and there are teams that think Verkle trees are the future for rollups as well. Um but generally our thesis is that like we have a really good understanding of both vertical trees and uh like the state commitment scheme obviously that we built and we generally think um vertical trees like don't really lend well to CK proving and since uh like you have to CK prove the accesses uh over long term I like our thesis is

that this is like the approach that we built is going to be the most performing. Um due to the constraints on the CK side. Got it. And so I want to relate this back to like a little bit more of the broader conversation which is that you know a big problem in the modular world and the sovereign world which are very very related is this fragmentation problem um because you know on Ethereum everyone has this validator set. It's very easy to interoperate cuz everyone's kind of like on that same base layer as Andy mentioned. Now in the sovereign world we have this problem where it's difficult to interoperate uh between rollups from from rollup to rollup because what you end up having to do is you have to prove your state to

the L1 and then the L1 goes and proves it to the L2 um and that's the way that we get we go rollup A to L1 L1 to rollup B. There's no rollup A direct to rollup B type of state verification or state commitment. So how have you been able to leverage like this new and improved Merkle tree state commitment scheme to enable like this rollup A to rollup B type of interoperability? It's great question. So the like the state commitment scheme that we work on uh is an orthogonal thing that's just to increase uh performance but as long as we can commit to some state root um where like which we already do in Sovereign SDK uh

we currently use the jellyfish Merkle tree that out of like the DM project at the time. That we're going to replace that with our own state-of-the-art Merkle tree. Uh, but so as long as you can commit to like a some state root and you can prove that in ZK, you can enable bridging. Um, so the way we differ the way the way we differ in terms of bridging compared to all the Ethereum based rollups is that, as you said, Ethereum based rollups um have to prove their like their state to the L1 smart contract and then the L1's through the L1 smart contract you like since like the state can only directly proven there, it can't be directly proven to another like roll up without

taking additional security assumptions, uh, you have to go through the L1 smart contract to uh, bridge. So the the thing that we do different here is in our like sovereign roll up construction um rollups are pure functions of the blockchain they work on. So, just by looking at an Ethereum block A uh, and verifying a ZK like just by looking at Ethereum block A, you can know if you read all the Ethereum blocks up until then, you can know the exact like state of the roll up. You don't have to like check the smart contract.

You don't have to interact with the smart contract. Um and so like a full node can do that full node can read all the data up until like that refers to the roll up uh, for a given Ethereum block and know the state of the roll up deterministically. And then what consequently, what is like light client can do, which is useful for bridging, is that you the light client can look at Ethereum block and verify a recursive ZK proof that verifies the correct application of all the roll up transactions on the Ethereum like correct application of the roll up transactions on the Ethereum blockchain up until to block and say that this is the correct statement.

So, um since we are able to generate this recursive proof of the sort that like Mina has, like a recursive proof that verifies the blockchain all the way back to Genesis, but this time we do it for the roll up. We're able to send this proof directly to other roll ups. We don't need to communicate through the L1. And this also means that some like very like some like third party can come in, take the recursive proofs for all the roll ups in the same ecosystem, and like compress that into a single proof recursively, and then share that. And so, then communication across roll ups becomes basically a mesh network. Every roll up verifies a single proof, and it

get it gets access to bridges from all the other roll ups. So, that's the beauty of our bridging system basically. It has no single failure point like the L1 smart contract or the Ethereum L1. Everybody just verifies a single proof and gets to see all the other roll ups the same way a smart contract was able to see all the other smart contract state. Very cool. Very, very cool. Okay, so so then because this state that you generate is able to trace back all the way to the Genesis of that roll up, you get both the history all the way from Genesis all the way to the current state embedded in this single uh proof.

And then you're able to combine that and aggregate that. This is kind of like like the Mecca of like interop that we've been hearing is like this proof aggregation type of setup. And so, because you're able to combine the entire history of the roll up up until its current state with and you let's say you do that for several different roll ups, you can combine all of those uh you can aggregate all all proofs of each roll up into a single one, and then what you have is you have this single proof that that has both the current state of all the roll-ups in the network, as well as all of the history of of the roll-ups in the network and their state since Genesis.

Like that's mostly correct. The only part is when you have a block header, a roll-up block header, or a blockchain block header, since like a blockchain is just like a continuous like hashing that takes input of the previous block, you already have a proof for like the state of the blockchain at like previous point in time. Do you like do you only like so the recursive part of it is an implementation detail, but it's useful because it enables us to like to the like the chains that the to roll-ups that you're bridging, it enables us to verify the state of the roll-up at a certain Ethereum or Celestia height or Bitcoin height without having to interact with the smart contracts.

Yeah, so the light clients just pass the block header, not the entire history of the entire chain. They just pass the most recent like basically block header or Merkle root to the broader proof and amongst each other. Yeah, I need to look into the details, but likely like the ZK proof will be of the sort a single aggregated ZK proof that verifies that a bunch of different like like ZK proofs were aggregated and verified, but but that commits to roll-up A like like that commits to like a DA block height like Bitcoin height 10, Ethereum height 100, or like Celestia height like 200. And like roll-up A state root was like XYZ, roll-up B state root was ZXT. And in

this way, you can have just a single ZK like proof that like that gets verified on these chains and they get access to the state roots and secured as a result secure messaging from all these other roll-ups. And Jim, correct me if I'm wrong here, but the the difficult part in the past was that like because these rollups were kind of executing in their own environments, you had to go down to the L1 to sort of synchronize those environments and kind of synchronize those like figure out which block headers apply to which rollups at any given time.

That was a that was a reason why we had to bring those down to L1. But because you have this recursive nature that that has the the the proofs at any given time or the state at any given time in that history, you're able to kind of do that synchronization. You're able to kind of like align the state of those two rollups rollup to rollup instead of doing the synchronization down at the L1 level. Yeah. So it's not only the like the to be fair, I'm skipping over some like details. Like it's not only the recursive proof. The reason we were able to leverage this like recursive proof is well like what like is because um

Well, like what happens with like rollups is that you got to one show that some data was posted on the DA layer and that that that data was executed correctly. So regular rollups work such that they check the data commitment like the the Z sorry. Regular rollups work such that there's a ZK proof that says like there was this is the hash of the data commitment that my proof prover saw and this is the result. So like there's like smart contract verifies the execution and then like the smart contract checks through the KZG blob check or like through like hashing the whole data that like the data that like addressed the rollup through the form of blobs or call data

like is hashed and the hash matches the commitment in the ZK proof. So the smart contract does that data like check. Whereas in ours, we do that data check in the ZK circuits. And so we uh are able to bypass the smart contract check that needs to happen on the L1. Awesome. And And does this enable that that like pinnacle of atomic composability? And just zooming out for anyone who hasn't heard about atomic composability, I think it's just like it's worthwhile mentioning that this is like a certain type of transaction where if I have some capital on let's take Arbitrum and Optimism. We can even you know, those aren't sovereign rollups, but let's just say I have Arbitrum and Optimism and I

have some capital on both and let's say Arbitrum is trading on Uniswap at uh or let's say Ethereum is trading on Uniswap at like 3,000 on Arbitrum, but for some reason it's 3,100 on Optimism. What I would want to do is I would want to buy ETH at 3,000 on Arbitrum and I would at the same time in the same transaction before the price can move, I would try to sell Ethereum on Uniswap on Optimism at 3,100 and get that $100 arbitrage profit.

Is because we don't have to pass back to the L1, are we able to execute those atomic atomically composable transactions rollup to rollup if both of those rollups use the sovereign SDK? So that might be possible down the line through a centralized uh centralized piece that has good security fallback mechanisms like AggLayer. Uh Like this is a definitely possible design, but like the at scale um if you're not going to run like the sequencer of all these rollups from a single machine, um this um like regular normal rollups basically

have message of if they're like ZK rollups of like two hops, they go from rollup to Ethereum L1 to other rollup. In our case, we can just do it one. If the ZK proving latency comes down like low enough, we can do one block time. Um like if the like the ZK latency is less than like one block time, we can just like the limit becomes one like uh DA block time. Because what needs to happen is that you post your transactions to the DA, then like DA like generates a like it generates uh new block. And so, given this new block, you can create a ZK proof that's like ties uh like that proves the state of the

roll-up given this new um DA block. And then you can send it to the destination chains to verify and enable transfers to it. Uh but so the limit here is uh still one DA block. They like you don't achieve atomic composability to this, but down the this opens up down the line uh easier ways to build atomically composable uh applications, but like that requires a lot more engineering complexity. So, it's not um given the currently high ZK like proving latencies, that's not an engineering focus of ours at the moment.

Understood. Yeah, it's a it's a bit of a dollar and a dream, but you know, it takes time. And uh we have time, so that's all right. I understand that you're somewhat bearish on L3s as a result of this light client point-to-point uh interoperability mechanisms because uh why do we need L3s to settle to L2s and then effectively have this L2 that batches all these L3 transactions and post it to L1 um and then be able to then go ahead and do a state verifications and um kind of interoperability between roll-ups, when we can just have a bunch of L2s or a bunch of normal roll-ups with nothing on top of them that all are able to interoperate with each other. Um

yeah, maybe that you could dive into this thesis a bit more and uh perhaps play devil's advocate because I think L3s are gaining significant popularity right now and a lot of app chains are being launched on various stacks as L3s settling to you know Arbitrum Optimism and others. Yeah. For optimistic rollups, the hub and spoke model does make sense. Um, but I was sovereign rollups I do expect that this hub and spoke model to reflect more like the existing Cosmos like topology rather than just like purely L2s L3s. Um, it's because like you'll have a connection to Osmosis likely if you like if you're but then you're going to have connection to with

the sovereign rollups you can do that since you're like state is deterministic and it's not determined by the L2 that you settle to. You're going to have like a connection to as an optimistic like sovereign rollups you're going to have connection to like Optimism but you're also going to have a connection to Arbitrum and maybe you're going to like have your asset transfers to Ethereum through them. You're not going to directly settle to Ethereum because it's too costly for you. Um, but yeah, like I expect to be a more fluid graph like um, like the Cosmos topology that exists today for the optimistic sovereign rollups. For the ZK sovereign rollups, um, like there really is no need for the L3 architecture at all. Like what happens is that like like every like ZK sovereign chain is what we call an L2 and

if they want to do trust minimize bridging with the L1 which I'm sure like most of them will then as we said like someone will generate an aggregated proof to send it to other rollups but this aggregated proof for that proof of state for all rollups can also be submitted as a single proof to the L1 too. So you can enable bridging with the L1 as well with the cost of a single proof verification. So, um, yeah. I think the generally L2 L3 model is all this flawed and kind of missing the fact that sovereign ZK rollups is just a simpler and probably better design long term.

Spoken like a true sovereign ZK co-founder. Love that for you, sir. You brought up a good point though, which we've talked so much about ZK, not a lot about optimistic rollups. And so, you guys are doing an interesting model where you guys not only enable ZK rollups, but also optimistic rollups with um a different withdrawal period, uh perhaps a shorter withdrawal period, and maintaining some uh same level of security or a high-level of security using ZK proofs. Um basically, there's optimistic rollups, we've got these kind of challengers and these um verification games that are played with fraud proofs, and there's a 7-day withdrawal window.

Um basically, the purpose is to is to make sure that, you know, what happens on optimistic rollups, uh when there's pre-confirmations on the L2, uh and then eventual finality is reached that there's no fraud. That's why there's this kind of window. But, you're saying that you guys can reduce this computational time period as well as effort and, you know, uh energy, and still uh optimistic rollups using ZK fraud proofs or ZK proofs to verify a fraud proof, so much so that you can get some something all the way down to where you have a a single ZK proof, which represents a fraud proof. Maybe talk us through how this works,

um and some of the security uh design choices that you guys have made here, or at least thinking about in the research phase. Yeah, no, we've uh implemented them, and so these are not research questions, uh not even implementation questions. These are at the moment just productionization, uh getting to testnet, cleaning up the latest but like last Yeah, stupid question, Andy. Just just stop asking questions, actually. I just need to clarify where we are in terms of product roll. Um so, we were initially building a ZK rollup framework leveraging these Rust Rust But then we were like, um the core challenge in optimistic

rollups, like the the core difference between ZK rollups and optimistic rollups is that uh in ZK rollups, you prove every block. Uh and in optimistic rollups, you need to prove {slash} verify an individual block when a fraud occurs. So we're like, we should be able there the conceptually it sounds very simple to adapt our framework uh to become an optimistic rollup framework, too. And so we were like did some research, and yeah, so like um like our optimistic model works in this like in the following way. Uh rather than like us like having provers prove like every block for a given like ZK

rollup, we have introduced another party called attesters, similar to all the other like optimistic rollup frameworks. Uh attester like attesters attest state roots. Uh and then when there's a challenge, rather than playing this interactive verification games that Arbitrum team have invented and Optimism have adopted, uh and like uh so like there's this lengthy like interactive verification game um that a challenger and the attester that attested to the like fraudulent uh like state root play. Uh and the like the goal of the state like the goal of this game in these optimistic rollup frameworks uh is to

decrease the number of steps that needs to be run on Ethereum L1 or on the light clients to a single very easily computable step so that any light client or at the Ethereum L1 can execute it cheaply. Uh and so it's it's basically a binary search of the trace of like the roll up block. A roll up block can be hundreds of millions or like billions of like some like simple CPU instructions. And so like the attester and the challenger play a game on like okay, it's this side, this side, this side, this side, this side, this side. And in the end they're like okay, this is this step. They they need to come to like a agreement on like okay, this is the step

that was problematic for me. Like the challenger said says I think you computed this state like incorrectly. And so they take this step and the inputs to it to the Ethereum L1 and Ethereum L1 like computes the step for its own and is able to determine if either the challenger or the attester was the correct party here. And so we're like and like the main reason we have the 7-day withdrawal period is like each of these like individual like interactive verification game steps the each step of the binary search and then the execution of the last step has to be done on chain for censorship resistance.

And every time you're trying to take this on chain step like some people that are trying to steal funds from the roll up try to put a lot of effort and bribe the like the L1 proposers to like push back this transaction. And so we need to account for about 50 on chain transactions that can each individual be censored and that's why we have such a 7-day like long withdrawal like withdrawal period from these roll ups. And in our like optimistic construction we just basically skip this whole interactive verification game step by asking the challenger when he makes a

claim that this fraudulent like this state root is fraudulent to just provide a ZK proof of the block. Um like so like this is challenger just creates a ZK proof for the correct execution of that block. It like this so like all the on-chain like ETH L1 like smart contract or just any light client on another like sovereign ZK roll-up is just able to check this ZK proof and like it doesn't need to play Nobody needs to play this whole game. Nobody needs to like run this like chain like execution step on chain. It just needs to be able to verify a snark.

And uh that's obviously computationally lightweight because that's what like uh ZK verification of like snarks achieve achieve to do. Uh and as a result of that we have just one uh transaction that needs to be on chain. Uh so theoretically, we should be able to cut down the on-chain withdrawal period by about 50 times, but at the same time we're trying to be conservative. Uh we want to account for the time that like you like this challenger might probably like contact a ZK proving service like Bonsai or like Six Sent Prover Network and get the roll-up block proven and then like submit it like And so to account for like that maybe logistical time, we say one day.

Uh but over time as we gain more confidence in these prover networks, we can potentially pull the like the withdrawal period way less than that. So this is this is optimistic verification in the best case. And then in the case of any kind of disputes of the the optimistic transactions, you fall back to a ZK verification and therefore you go around any kind of interactive fraud proof game. Yeah, but like uh So these are just in terms of cost or like the all the trade-offs, these are optimistic roll-ups. Just like the verification mechanism we use is not this like very complicated IVG game.

It's just like a mechanism that leverages ZK proofs and hence is able to do it way faster do the verification. Yeah. So, optimistic rollups in the Sovereign's SDK do not have a 7-day withdrawal window. They are just baked into the system, which is much more efficient in terms of withdrawals by ZK proofs. Effectively. Yeah, I wouldn't say baked in, but due to like this next gen- next generation optimistic like framework we have, like that skips all these 50 steps and does it in one step, they have significantly shorter withdrawal periods.

Uh compared to regular like optimistic rollup that exists today, they do 7 days. Uh we we're we're currently advertising 1 day, but should be less than that as we gain more confidence in proving networks. Very cool. We we did a we did a podcast with Steven Goldfeder of Offchain Labs, founder of Arbitrum, and we asked him like, "Hey, you know, Arbitrum is an optimistic rollup right now, but like if ZK tech gets to a point where it's just better than optimistic tech, is you know, would would Arbitrum go ZK?" And he was basically like, "Yeah, like like it just has to get to a point where it's battle-tested and it's proven and it makes more sense than than keeping things optimistic." And so I I think this is a really really cool way to again, combine the best of both worlds.

Like, you guys have optimistic, but you don't need to play this complex, almost like excessively uh like costly interactive fraud fraud proof game on chain. You can simply just say like, "Hey, screw all that on-chain stuff, all that fraud proof stuff. Just give me a ZK proof. If you can do that, then you clearly weren't lying." Exactly. Well, well, well, let's let's let's pipe down here, fellas. Let's talk about the tradeoffs of this design here because for some reason we were able to go from 7 days to 1 day, but we can't go much lower than a day, but we maybe we can in the future. Is it a matter of the ZK proving time that you have to be confident in? Is there an amount of blocks that you have to be like like is

there amount of confirmations that you have to be confident in? Jen, what is that? to try to take this one cuz I think and Kirk please jump chime in if I'm wrong but I think the idea here is that you're going to ask a an entity that is not normally producing ZK proofs to come up with one in order to to prove against the the fraud claim. And so because this entity that is normally accustomed to just optimistic verification, because they have to do something that they're not used to doing, they have to generate a ZK proof, that's why they're going to have to do some sort of like off-chain communication or coordination with an entity that is more accustomed to to generating ZK proofs to come up with one

in time. And and it shouldn't take 7 days but it is going to have some latency to coordinate with some ZK proof generation service that can produce that proof. Jen, did I did I get that right? I think that's pretty good. Like uh it's pretty good summary. I was like basically trying to find like so the main thing is though the main core difference is that 50 on-chain steps that all individually can be censored versus one individual step like that can be censored. So that's where like main uh like difference and why these like uh why the finality mechanism of sovereign secure rollups is much faster.

And um like the reason like normally like 50 like compared to one like we should just be able to take like a 7-day like period uh and slash it by like divided by 50 and get like 3 and 1/2 hours like of like um withdrawal period. The reason we don't like slash the thing down as aggressively as it is is exactly as you said. So now this challenger is going to contact uh like Succinct Prover Network or like use the APIs of Bonsai Risk Zero Proving Service. And so we want to be safe. We We to be very conservative.

Like these systems are like They're like uh uh I like these systems are going to be quite easy to leverage. Like you just like connect to an API endpoint and I like send your execution trace, they send you back the ZK proof. But these are really in the early days. Let's assume that it might like the succinct is down or like one's eyes down and like you can't contact. So we're trying to like be safe here and be conservative that you're not able to get it proven immediately. The proving of a roll overall up block even for like a mega block shouldn't be more than 15 minutes. And so that's not really a concern. We're just trying to be We're just trying to be at these early phases be conservative about uh this like challenger reaching out to uh a ZK proving service.

And can the challenger is is there some sort of like incentive design here where there's like maybe like an auction or some sort of mechanism where the challenger goes and like puts an intent almost that it's like, "Hey, I have this need to have this this uh ZK proof generated." And then succinct and uh risk zero and others can can kind of come in and like bid to do it or like does it just get sent to one of them or how does that like aggregation kind of look? Almost all these ZK VM teams that we talked about are trying to build these open prover networks. They're like it's almost their like number one like public ambition. And so yes, like no Currently centralized proving networks

exist but um these teams are trying to move in that direction as you said. So these systems are like succinct pretty soon. Got you. And there will be some sort of incentive for the for the team to create is a a legitimate ZK proof given this with sovereign SDK providing incentive to these networks to operate? So we only provide incentives. We like we provide all the incentives for a roll up to like function securely. Uh like all baked into sovereign SDK and which is one of the core components of Sovereign SDK is the incentives of these attesters, incentives of these provers.

In the case of like fraud, incentives of these challengers. For example, in the RZK roll-up mode, almost all the gas fees, and not all of it, but almost all the gas fees go to the provers so that the like block like gas block limit, which is the roll-up block gas limit, can adjust dynamically with the changing like ZK proving. As more ZK proving like as more GPUs come online for proving. These are all baked in Sovereign SDK. And in the optimistic roll-up mode, like most of since like attesters put all put like put some put some stake in the case that they were fraudulent to be compensated for the capital that they put, a lot of like the gas fees go to

these attesters. And in the case of a fraudulent state proof attestation, then almost like half of the stake of the attester I think the challenger. So all of these incentives are baked into the SDK so that when you're running this thing, like you don't have to think about incentives, like people will just come in, the market will solve your security questions for you. Blockchain engineering in our minds I like that. as well as systems engineering. So we're the all of that is in deeply baked into the SDK.

Sounds like we're engineering our way into a sovereign token deep deeply baked into the SDK, my friends. This has been a great great podcast. Um Cem, thank you for coming on. Um and yeah, how can our community get involved with Sovereign? And feel free to respond to the token claim as well. Yeah, I definitely I will definitely respond to that. Like you can feel free to follow us on Twitter. We're sovereign_labs. And feel free to follow me on Twitter. I think it's c m o z o underscore and join our discord like go to our GitHub run sovereign SDK ask us questions

check out our docs on our GitHub will soon publish a sovereign SDK book which will shed a lot of light on really how we're improving all these all these like roll up core components like forced transactions like easy way to build applications just using rust is a way to like integrate VMs and sovereign SDK all these things will have a comprehensive box suit so so stay like so wait for that to come out and to address the token claim we're not currently considering any tokens if we feel a service that like improves the user experience of sovereign SDK users exist that requires a token we will definitely

launch one but currently we don't have any plans we don't have anything that indicates that so and like we're not like we don't have any plans for tokens and so all of the incentives that you mentioned that go to the attesters that is all driven by the the block gas uh fees that are generated via transactions and those are in incentives for each individual roll up for the application developer like to yeah application developer can use it like TIA as a gas token or like it does a gas token or their own native token and like these these attester challenger and prover incentives are all managed

like through that token very cool Jim thank you so much this was this was a banger absolute pleasure thank you so much for having me it was a pleasure