The Cosmos SDK of Rollups | Preston Evans, Sovereign Labs

Transcript

So the big difference between us and the Cosmos SDK is that Cosmos is meant for building layer one blockchains. And so in order to do that you have to recruit a validator set, you have to get a network of full nodes, you have to do all of the decentralization things in order to give your users security. As a roll-up of course you inherit the security of some other blockchain. So the barriers to entry are much much lower. What's up everyone? Welcome back to another episode of Zero X Research. Today is April 3rd and we've got a great interview lined up with Preston Evans, the chief scientist over at Sovereign Labs where we'll be discussing everything roll-ups. I was unable to make the episode but Westie was able to sub in for me and probably ask better questions than I would have been able to

anyway. So before that though as always we're joined by two Blockworks Research analysts Matt and Ren. This time we're not doing a hot seat cool throne segment. We are going to be dis- to discuss Arbitrum governance and there's been quite a bit of a debate on this front with the first proposal going live recently. So Matt, I'll kick it over to you to explain that situation. Blockworks Research's first step into governance was really becoming a delegate for Arbitrum meaning if you're an Arb token holder and you got an airdrop you'd be able to allocate us your tokens just for voting. So you can give Blockworks Research your tokens voting rights, you know, we don't have any control over them and we'll go ahead and vote to what we hope is in the best interest of the DAO and the protocol.

The first proposal AIP-1 did three real like three big things among a few a few smaller things as well. The first was it set up a governance process. The second was that it created a security council of 12 members who actually have full control over the protocol. They can they're kind of like a backstop against you know, if there's ever a vulnerability or something of that nature. And the third thing and the most important was is it sets up an Arbitrum foundation. The Arbitrum foundation was to be funded with 7 and a half percent of all tokens. This is 750 million Arb tokens worth a little bit over a billion dollars.

When looking at this proposal we had no issue with the first two points or any of the smaller ones, but we did find a few small issues with the Arbitrum Foundation. And because of this, we had to vote no and against the proposal passing. Ren was the one who actually found the issues to start, and the whole Blockworks research team kind of contributed, but would you go ahead and take it away on like kind of what we saw? concern lied within that 750 million OP tokens, worth more than a billion dollars. To us, those 750 million OP tokens were seemingly under the control of the Arbitrum Foundation, and the Arbitrum Foundation would be run by three initial directors. The names were listed out in the proposal, but no one really knew who they were.

I think the main concern from there on was that even though the proposal itself was speaking in future tense, that the foundation will move the 750 million OP tokens into this administrative budget wallet, actually all of those actions had took place already. We found out that the 750 million OP tokens had been separated from the DAO treasury of roughly 4.3 billion OP tokens. And then furthermore, the foundation had sent around 40 million OP tokens to a market maker, which we now know is Wintermute, for them to market make the OP token on certain centralized exchanges, and had also sold 10 million OP tokens to fiat in order to fund their operating expenses.

To us, that seemed like at the bare minimum a miscommunication in terms of what people were thinking that they were going to vote on, because in all honesty, reading the proposal it seemed like that that would have happened in the future had the Arbitrum DAO passed this proposal, but that was obviously not the case. And there was a large lack of clarity within the proposal in how those funds would be used, how they would be allocated, how they would be distributed distributed, what sort of accountability there would be from the foundation in terms of KPIs, OKRs, or somehow they would report back to the Arbitrum DAO. And it was mostly that lack of clarity that drew up a lot of the questions that we had and ultimately

led us to voting against on the proposal. Right. And I I think that that makes a ton of sense there. And you know, broadly from the point of contention being around how these 715 million tokens were allocated, it's it's more so in the communication side of things, right? It's not that there is a foundation that has this control over these tokens. It's a fact that it wasn't really clear who owned these tokens to begin with. You know, the initial you know, classic pie chart token allocation had 42% of the tokens under to the community control, right? So it's really more specifically under the DAO control with another portion going to user airdrops.

Um and so of those 42% it wasn't clear that 50 35% would be directly in the DAO treasury and the other remaining 7% would be held by the foundation. And so if you compare that 7% for a foundation uh to some of the other you know, all L1s or L2s in the space, it's a pretty reasonable allocation, right? It's even the smallest of the bunch that you would come up with if comparing to like things like Polygon, Avalanche, or StarkNet. Um and you know, generally speaking, foundations really are for the benefit of the protocol, right? Uh classic example of something a foundation can do that uh a DAO would really struggle to do is making partnerships uh with large Web2 brands, right? Like when you the

the from the initial onset of those conversations, you're under NDA, you can't disclose you know, the party you're talking to or the deal you're communicating about. And that's simply something that a DAO could never do, right? You can't have all these DAO participants sign an NDA with this this this uh you know, private organization like by by by the nature of the construction of a DAO, that's just not possible. Um so there are many other reasons why a foundation would be beneficial as as well. Uh it's just a question that it was really poorly communicated and something I think that the Arbitrum team could could have out like, you know, really own a little more like hey you know, we really should have done a better job in how this was communicated to the community. Um because again, in the reality, having a foundation is a

net positive for the ecosystem. So, um the question really ultimately is how do we move on from this? And like, what's a good strategy to move forward? Uh and something that, you know, Blockworks Research as a whole has really put a lot of time and effort into thinking about, you know, how do we kind of make amends here with the community, but also still make sure that there is this foundation that is pushing uh the Arbitrum ecosystem forward. So, um maybe Matt or Sam, I can toss it back over to you to really kind of summarize our thoughts on uh a recent forum post we had that kind of communicates what we believe. Yeah, just one thing before Matt, I pass it over to you to talk about that. I think it is important to recognize the fact that um they did come out and say,

okay, yes, there's X amount of votes against, this isn't going to pass, but really this was just a ratification saying like, hey, we're we're we're implementing this no matter what. It's kind of no turning back type of thing. It's required in order to actually establish the foundation in the first place. Um so, I get that. And now all votes will go through Tally. So, if we did want to propose to send the tokens that were put in the budget uh wallet for the foundation, that would have to go through a 30- to 40-day process, get back into the DAO control, another uh proposal would need to be made, and then another 30 or 40 days through Tally and every the whole governance process again. So, then the foundation wouldn't be able to effectively act on behalf of the DAO. Um which is not good,

obviously, cuz foundations are great. For comparison, Optimism put 25% of their treasury into the foundation, if I'm recalling correctly, and they just kind of put it into different buckets. I believe 8, 9% of that 25% isn't even allocated at this point. So, that that'll require a DAO process as well. So, it's not necessarily the sheer amount of tokens. 7 and 1/2% is honestly really small in my opinion. Um I would almost like to see it be more uh with the grain of salt that investors and core contributors of Arbitrum in comparison to optimism got more of a percentage of the pie. So, I don't know. You kind of got to look at it and make your own decisions, but yeah, we definitely have a lot of good ideas as a team. So, Matt, I'm curious, how do you think we should carry forward?

Sure, and just one last small thing to add is there's a lot of rhetoric on crypto Twitter that the reason that they went that the Arbitrum team went about it this way and kind of didn't include the foundation in the supplies for legal reasons. We're unable to confirm whether or not that's true, but there's just that a lot of support for the team is is coming from that angle on crypto Twitter. Moving forward, we really think, like Sam said, the foundation's not a bad idea. The real issue is that we have no idea who's involved in the project. So, we don't know who's, you know, allocating these grants, who's doing these potential business dev partnerships, you know, funding public goods, whatever else this foundation might do. And that's another problem.

So, we don't know who's doing it and we don't really know what they're doing. They all they really said was special grants. We can think of a lot of good uses of special grants, such as the ones I just said and plenty more, but it'd be really nice to see exactly what these use cases are and how much money they expect to be to be giving, you know, allocating to each of these uses. So, the two things we want to see is more transparency around the team and who's involved, and we want to see more transparency around how the funds are going to be used. Maybe a justification for the budget would be a good a good, you know, word of of how we want to see that that allocation justified. I think those are the two biggest things. Additionally, it would be nice if the team were to, you know, maybe

admit that it wasn't the best the best optics. They could have done better, but at the end of the day, I think we at this point we just want to move forward. We want to move forward. We want to this to be in the past, just like a small like a something that we got over and, you know, everyone forgets about. At the end of the day, this really did create a whole lot of controversy, and while a lot of it was positive and people calling for transparency and, you know, um a lot of positive conversation did occur as a result of us finding and, you know, publicizing our statement, there also has been some more negative outcomes in people, you know, not focusing on transparency as the main issue, but rather looking at oh, they dumped 10 million tokens on us, like the this is just a slush fund. And we just

want to say like Blockworks Research, or at least I personally, I definitely don't believe that's what's going on. I think there's a stupid mistake made and that it can be rectified and that we can move forward and mostly that's going to be through transparency around the team and the spending of the budget. Yeah, I strongly agree there, Matt. I think the main thing I want is also, on top of what you said, was a vesting schedule. And it's kind of hard to come up with an ideal schedule for these tokens considering we don't actually know their budget. No one knows the budget as well as the Offchain Labs team and the Arbitrum Foundation itself and the people in charge over there. So, just getting a better idea on how much it does cost to run a DAO at scale, like at the scale of Arbitrum, you know, the

largest, really the largest chain, one of them in in all of crypto, you know, top five by TVL. Um, so just transparency is all I would ask for and how the funds are going to be spent and then that way we can come up with a vesting contract that actually makes sense to meet those budgetary requirements. Uh, that that would be my my number one on the wish list and then also just every quarter kind of go through, look, we spent this much money, we had to liquidate liquidate these many tokens to fund these activities, these are the partnerships we could pursued. Uh, and and yeah, just providing more transparency in general as we actually live out the process of the DAO.

To add a balanced opinion here, I do think that there's nothing that wrong with Arbitrum still being relatively centralized in terms of the Arbitrum Foundation at this stage. It is near impossible to develop a large ecosystem like Arbitrum without a governing centralized body, right? We have seen time and time again that if you really want to run a business as a DAO, it is near impossible and that nothing will get done. And as a secondary point on transparency, likewise, right? It's nearly impossible for Arbitrum Foundation to provide an accounting statement for every single month for every single line item that they've expensed on. You also wouldn't expect a governance participants or

delegates to sort of go through Arbitrum's budget and say, "Hey, I want to spend $2,000 on this weekly lunch. Hey, I want to sponsor a party at Permissionless for $3,000." That's not really what we're here for and that's not what we're really here to do. Our role as delegates and as participants within the Arbitrum Arbitrum ecosystem is to provide overall accountability, right? Maybe we can skip the more granular stuff, but as long as the overall accountability and transparency is there, I think that's what the community really wants at the end of the day.

Yeah, totally agree with you there, Ran, and just to continue on what Sam said, I think a vesting schedule really does make a lot of sense here. Um, and some reasons why is like, okay, let's say you're trying to enter into a multi-year partnership with another group, right? Um, you need to know like I'm going to get X amount of tokens every year so that I can like pre-allocate tokens in the future uh that a vesting contract is going to give me in order to kind of like budget out things into the future. Uh, whereas uh more of like a verbal agreement with the DAO and saying each year we'll come back to the DAO and try to like top up our coffers and then pursue forward. Like that isn't a a known cash flow in the future. Uh, and so it makes it a little

harder, right? Like think about being on the other side of that. If that's the counterparty I'm dealing with and they have to, you know, uh go through a DAO process for a DAO vote to get future cash flows, um then I'm a little bit more concerned about making that multi-term multi-year deal. So, uh it it does make sense and I think that setting an industry standard here as a foundation having a vesting schedule is a pretty interesting opportunity because today that's really not the case. Uh, and most of these foundation allocations are just taken directly out of the initial token supply. So, uh it is kind of a good way to help push forward an industry standard as well.

I'd really like to just echo what Ran said, which is at least I'm I'm a huge supporter of the idea of sub DAO's or meta DAO's. I think that one token one vote on all spending initiatives is just not a sustainable way of going about DAO governance. So, I think ENS, DYDX, um Maker DAO, these are good protocols to look towards because they have respectively they all call them something different. I think it's like working groups, sub DAO's, meta DAO's, but it's basically the idea that you budget an entity under a centralized or a semi-centralized entity under your main DAO. It gets a budget for the year.

You know, if they do well, you continue to fund them the next year. If it doesn't do well, you don't continue to fund them. To Dan's point, I agree. I think it's better to give them uh you know, if they have a vesting so that if they become a better counterparty, cool. But, DAO governance better still have control over those over those vesting contracts just so they can pull them in case they had to. Um and that's kind of how I see like governance in the future. Very few things are actually voted on by the main DAO besides those reallocation of funds to these sub DAO's or meta DAO's or whatever you want to call them. But, that's just my opinion on on kind of the whole the whole idea of DAO governance and something that we could work towards.

Yeah, Sean agree there, Matt. And I also just think it's worth noting and highlighting again that today is Monday and governance in crypto in general moves super quickly. So, I imagine a lot will come out in between now and Wednesday when this episode airs, but it's definitely been like a fun conversation experience experience and just kind of generally seeing people, you know, express their opinions and get super involved in governance. Like, that's exactly what the space is about and in the very least, like, that's what we accomplished over the past week. So, that's super exciting to see and I'm excited to see Arbitrum and Offchain Labs response. All right, on that note though, I think it's a good time to hand it over to Dan and Westy to talk with Preston Evans from Sovereign Labs on all things roll up. I cannot recommend enough for you

guys to all check out blockworksresearch.com. If you go over to the research tab and toggle free research, you're going to get access to some of the best free reports in the industry. And if you want to subscribe to Blockworks Research, you can do so using zeroxresearch10 at checkout in order to receive $250 off. And you can also sign up to our free newsletter if you want to just get a little taste where we give alpha on governance, DGen trade ideas, market commentary, charts of the day, etc. Kind of get you caught up to speed on everything you need to know in the market within 5-10 minutes. Give us a follow at Blockworks Res, Blockworks RES, on Twitter. We'll release our new reports during the week and even if you uh don't have access to the reports, you're not a paid subscriber, you can still check out the

topics we're writing about and get a a little bit of a brief insight into what uh the content of the report is about. You want to know a little bit more how we think on the data side of things, head over to our Dune public account. We have four dashboards live there for free. The revolution will not be quarterly reported, so definitely check those out and let's kick it over to the interview. Alrighty, everyone. We are joined by Preston Evans, the CTO of Sovereign Labs. Uh Preston, thanks a lot for joining us today. We're super excited to kind of dive into everything that you're building. Um so, I guess we can probably start this by you know, if you could just give us an overview of the various scaling uh architectures for rollups and really like how uh what solve Sovereign Labs is is building and it kind of how

that differs from the market landscape today. Uh that'd be a great starting point for this. Yeah, first of all, thanks for having me on. It's great to be here. Um so, yeah, let's talk about rollups. So, broadly speaking, there are two categories which I'm sure your listeners have heard, but there's ZK rollups and there's optimistic rollups. Um and at Sovereign Labs, we build ZK rollups specifically. And then we we make a slight tweak to the architecture which makes us a little bit different from everybody else. And what people call us is sovereign rollups. Now, that may be a little bit of a misnomer, but a sovereign rollup is just just like a regular rollup except that it expects end users to decide for themselves what the state of the rollup is. So, let's back up just a little bit, right? What is a rollup? A rollup is a

blockchain and it's a blockchain that posts its data onto another chain. So, you've got some set of transactions that you've posted onto an L1 and those set of transactions logically give you some particular state. So, you know, maybe Dan, you sent me five ether and then I sent those five ether back. At the end of the day, I should have zero ether, right? And you know that just by looking at the transactions on L1, like that logical state is there no matter what. So, the question of ZK and optimistic and sovereign, none of that really affects the underlying reality of like you posted some transactions on L1 and you got a state root or a new state out of that.

The The question really is like how do you as an end user decide what the state is? How do you become aware of what it is? So, there are a few ways that you might do that. A traditional roll-up, you will be a light client of the L1. So, you will have your little phone or your MetaMask wallet or whatever following Ethereum. And it will get the Ethereum block headers and that Ethereum block header will have some commitment to the current state of the roll-up. So, there's some smart contract on the Ethereum L1 that is following the roll-up and checking proofs in some way to decide what the current state of the roll-up should be. And then you as a user, you look at that smart contract and you say, "Okay, the current account balance for Preston is zero ether."

A sovereign roll-up is just a little bit different. Instead of following a smart contract on the L1, we send you the proofs directly. So, somebody creates a zero-knowledge proof off-chain that says, "I have looked at all the transactions and when you apply them in order, here is the new state. Preston has zero ether." Um so, that's really all that sovereign life does. It's a little bit different from everybody else. Um and we're probably not the only ones building sovereign roll-ups. Um it's it's become a very popular space recently. Um but really I think the whole difference between sovereign and non-sovereign roll-ups is is maybe a little bit overblown.

Um the important thing is, you know, are you optimistic or are you ZK? And what properties does that give to your users? I would love to dive more into uh sort of the guarantees around that. So, I know when you have sort of like an enshrined smart contract in an L1, it helps define, like you said, the role of state as well as the canonical roll-up in the case of like a fork choice. So, I'm wondering sort of what guarantees are different between having like a sovereign roll-up where there's not actually that enshrined smart contract um and you have actually having that enshrined contract with that L1.

Yeah, that's a really, really good question. So, um things get complicated here very quickly because there's a massive design space for what your roll-up could end up with. So, I'll just highlight a couple of of kind of interesting points in the design space, but know that there are other options out there that I may not cover here. Um so, I'll start off by talking about what Sovereign does. At Sovereign, what we do is we create a zero-knowledge proof which says that essentially we have read all of the transactions from the L1. So, that that means there's no possibility of a fork on the L2 roll-up, right? There's There's no such thing as needing a fork choice rule or something like that um because your fork choice rule is just always take all of the transactions.

So, what that means is that you really do inherit the underlying guarantees of the L1. So, anybody who posts a transaction onto the L1 gets that transaction included on the L2 as well. So, you inherit its censorship resistance. And uh you inherit the liveness guarantees of the underlying L1 because there's no extra party who has to sign off on transactions before they get included, right? It's just L1 validators. Now, this is not necessarily the case for other roll-up designs. So, for example, if you're running an optimistic roll-up as a Sovereign roll-up, it's not necessarily clear to your users um if they're following the canonical chain.

So, what we do is we create a SNARK that says, "I've looked at the block headers, I've looked at all the data contained in those headers, and I ran a you know, a processing function over all of that data to get the new state." If you don't have that proof, then as a user you do have to worry about the possibility that somebody left out a valid transaction. So, this is what the sequencer could do. They could leave out some valid transaction. Maybe Dan sent me five ether and then I sent it back and they ignore that second transaction. So, it appeared on the L1, but they didn't include it in their state. Well, that's fraud, right? So, in theory somebody would create a fraud proof which would catch them.

Now, the problem is as a user, you don't have any guarantee of when that proof is going to become available to you. So, let's say Westy that you never find out about that proof. You will go along thinking that I have five ether and maybe I say, "Oh, sure. I'll send you this five ether." And now you end up with these five ethers that don't actually exist, right? With a ZK proof, you don't have that problem. Uh and the reason you don't have that problem is because as soon as you see the proof, you know that it's valid as opposed to optimistically sort of assuming that I'm not lying to you and hoping you find out after the fact. Um so, I guess that was that was the difference between ZK and optimistic in the sovereign setting.

Uh the last piece is how does the smart contract play into it, right? For a smart contract roll-up, you don't really have that problem because you assume that the L1 one is censorship resistant. And so, you know how you would find out about that fraud proof, right? Somebody would post it onto the L1, the smart contract would check it, and then you know whether or not somebody has lied. Um for ZK, you don't really need anything on the L1. For optimistic, it's not necessarily clear how secure you are without posting your data onto the L1. Yeah, Grave. Thanks for that overview as well. And so, one thing uh you know, Sovereign Labs is creating like this the Sovereign SDK to build these roll-ups on on any kind on any base L1 as I understand. Is it indeed any base L1? Um and if so, like how would you kind of

compare and contrast yourself to the Cosmos SDK because you know, most people in crypto at this point have heard of the Cosmos SDK and like understand that it's like this modular uh base to build blockchains out of. Uh so, what are like the the comparisons and uh like how would you compare and contrast against that SDK? Yeah, that's a very good question. So, we really do see ourselves as being very similar to the Cosmos SDK in spirit if not in the details. So, the big difference between us and the Cosmos SDK is that Cosmos is meant for building layer one blockchains. And so, in order to do that, you have to recruit a validator set, you have to get a network of full nodes, you have to do all of the decentralization things in order to give your users security.

As a roll-up, of course, you inherit the security of some other blockchain. So, the barriers to entry are much, much lower. Other than that, we're very similar to Cosmos, right? We're both targeted at supporting uh uh app developers who want to come in and build something new that hasn't been tried before, but don't want to start from literally zero, right? And so, this thesis of like app chains, or even just, you know, standardized infrastructure, uh is very much shared between Sovereign and the Cosmos ecosystem. Right on. Yeah, that's that's that's that's great to hear. And, you know, it does make sense why, um you know, you'd want to kind of use this this set of modules to build something uh that doesn't exactly, you know, have take the the full effort of building uh an entire blockchain from the ground up.

So, when I From my understanding, like really using an L1 as a settlement means you have this enshrined smart contract that helps define the roll-up state. And and like how I don't know, I guess can you like really expand on the role of settlement and what guarantees are added or taken away uh by either outsourcing the settlement or being completely sovereign? Um and essentially, you know, and what is the difference between trying having that enshrined smart contract and a general trustless bridge? Yeah, this is a this is a really interesting area. Um so, there's some ongoing debate in the community right now about how exactly we should think about this. But, I'll kind of try to give you the the high-level perspective and uh and we'll go from there. Um so, basically, as a roll-up,

right, you your goal is to scale some underlying blockchain typically. At least if you're a roll-up as they exist on Ethereum today. So, Optimism wants to be able to process a lot of transactions involving Ether and CryptoKitties that were issued on Ethereum and those sorts of things. And in order to do that, you need a trust-minimized bridge, right? You don't want everybody to be trusting some committee to make sure that they can't steal assets and that sort of stuff. Um So, the smart contract is the bridge. The roll-up is doing its thing, it's processing transactions, and then the smart contract checks that the roll-up is following its own rules.

And so, as long as the roll-up isn't buggy, you can guarantee that your funds can't be stolen. Now, in a sovereign roll-up, it's the exact same thing. We'll have a bridge, which is a light client of this roll-up, and it will it it can check that the rules are being followed. The only difference is how do you end users interact with the with the chain? So, for a smart contract roll-up, you interact with the smart contract to find out what the chain state is. For a sovereign roll-up, you interact directly with the roll-up's P2P network to find out what the roll-up state is. Uh but, the guarantees you get should be the same if the system is well-designed.

Now, of course, you can make a buggy roll-up that doesn't do that, but there's no difference in the guarantees you should get as a ZK roll-up, um whether you're optimistic or using a smart contract. The only difference that users will experience is they should be able to get sort of faster confirmations um and cheaper fees on a sovereign roll-up. So, let me explain why that is, right? That's kind of a bold statement. Um The most expensive thing for most ZK roll-ups is verifying the proofs on chain. So, verifying a typical Groth16 proof is maybe on the order of half a million gas, and something like a Stark proof could be up to 5 million gas or even 10 million gas, maybe. Um that's a ton of money to verify a single ZK proof on

chain. And so, systems like StarkWare, they don't post proofs onto the L1 very often, right? Because uh a proof doesn't get any more expensive to check if it's bigger. So, you can prove a thousand transactions or a million transactions for the same L1 gas cost. So, if L1 gas is the biggest cost in your system, then you want to wait as long as you can so that you can spread that out across more transactions and each individual transaction pays less fees. Okay, so in practice what that means is StarkNet posts a proof maybe every few hours, maybe 6 to 8 hours or something like that. Um and it's not that they can't prove faster than that, it's just that they don't want to pay the gas to verify the proofs on chain.

But because as a user you're looking at the smart contract to decide what the state is, your personal view of the state doesn't update until StarkNet posts the proof. And so you experience a latency of 8 hours or 12 hours or whatever it is for your transaction to be included. As a sovereign roll up, you don't have to do that. You can still have this bridge which checks the proofs on the side, but users aren't looking at the bridge. So sure, maybe you wait every 8 hours or 12 hours to submit a proof onto the L1 bridge, but you can create other proofs and send them directly to users in real time.

So as a user of a sovereign roll up, you can check a proof from the peer-to-peer network and if the proof checks out, you know what the state on the L1 will be in 8 hours or whatever the time window is. Well, yeah. That's a really good explanation. I know you mentioned that previously in the conversation with Anatoly about, you know, whether uh ZK proving is actually the bottleneck in finality whereas in reality uh you can you can just send it to the the peer-to-peer network. So I really appreciate that. What I'd love to dive into next sort of data availability and how that fits into the the sovereign thesis. So could you give a quick overview on what data availability is, why it's important, and how it relates to sovereign?

Yeah, sure. Um so I I assume your listeners are probably a bit familiar with the roll up design space, um but backing up, if you had a roll up that didn't have any of its data available, that would be completely insecure. So in that situation, someone would give you a zero-knowledge proof or a fraud proof and they would say like, "Hey, look, I had some transactions and now here is a commitment to the state of the roll up afterwards. And as a user you're like, well, that's great, but I don't know what's inside that commitment. Like I don't know what anyone's balance is. And so if the prover is malicious, they can give you one of these proofs and it really is a valid ZK-SNARK. It really does commit to some state, but there's no way for you as a user to know what that state is and so you can't do

anything with it. You can't withdraw your money, you can't check somebody's balance, you can't do anything. And so your funds are effectively stolen or effectively frozen, right? Okay, well, now as a user you're like, how do I get my money back? I want to do something with my money. You have to, I don't know, pay a bribe to the prover or do whatever the prover wants so that he'll move your money for you. So it's very important as a user that you know what's inside the state commitment that the ZK-SNARK attests to or that the the roll up attests to. Um that's the data availability problem. So how do you know what's inside this valid proof?

All you need to do to solve that problem is you need to publish the data on the internet somewhere. But the question of like what does it actually mean to publish data is a little bit hairy. So the gold standard for data availability is to post it onto an L1 blockchain. Um people have started out doing this with Ethereum and nowadays there are specialized chains that are just meant to do this. And that way users can know what the current state of the roll up is and that it's valid, not just that it's valid. Um so, you know, there are probably three or four or maybe five chains nowadays that specialize in data availability.

And the best way to build a roll up is to use one of those chains and post all of your data on that chain. And your roll up is only valid once the data appears on that L1. And just piggybacking on that note, so what do you think is the the most optimal optimal data availability solution today um and how does that fit in directly with Sovereign? Yeah, this is a it's a tough question actually. Um, so at Sovereign, we are not betting in particular on any particular data availability layer. Um, we see a lot of innovation in that space and um, it's too early to call a winner, and frankly, like, many of them make different trade-offs that I think will be good fits for different kinds of applications.

Um, now that being said, there are some clear winners and some clear losers in terms of the technologies that you choose. So, all of the really good data availability chains are integrating a technology called data availability sampling. And what that lets you do is, as a end user, you can very trivially check that the data availability chain is really doing what it claims that it's doing. So, if somebody posts the data on chain, you as a user really can download it, and you can check that you can download it without having to actually download it at all. So, what that means in practice is basically, these chains can be much more secure, and they can they can support a much higher throughput of data than a traditional blockchain could.

Um, other than that, you know, all these data availability chains make slightly different trade-offs in terms of consensus and time to finality and things like that. Um, and frankly, we think most of them are pretty well designed. So, we're very excited to see the explosion of innovation there. Uh, we support, um, or we plan to support basically any chain you can imagine as a platform for building Sovereign rollups. Um, so we've started out integrating with Celestia for our first demos, but we'll quickly add, um, Ethereum once Proto-Danksharding or EIP-4844 finalizes.

Uh, we will add Avail, we will add, uh, probably Bitcoin pretty quickly, and then we'll keep on adding chains as bandwidth permits. Um, we've chatted with a bunch more layer ones, and kind of everybody's adding this capability as time allows. I'd love to to ask you about sequencers. I feel like that's a pretty hot topic within the rollup space at the moment. So, I'd love to know, like, what is your framework for sequencers? Do you think centralized sequencers are okay or maybe optimal in certain context, or should all sequencers look to be decentralized? So yeah, I would love your opinion there.

Yeah, this is a really really good question. And again, like with so many things, there's a broad design space here. And so, we'll have to talk a little bit generally about what trade-offs people are making. Um but overall, we're big fans of decentralization. We kind of think that's the whole point for roll-ups, right? Like, if you just wanted a centralized chain, why not use a database on AWS? Um so, you know, we think decentralization is important, but it's important because it gives you specific guarantees, right? It's not important just in the abstract. It's important because it translates into better censorship resistance, um more resistance to things like, you know, regulatory capture, all of these sorts of things.

Um so, we think centralized sequencers are probably kind of just a stop gap because they're easy to build. But in the long term like it's very likely that some jurisdictions will treat centralized sequencers as being a money transmitter or something like that, you know, who knows what's going to happen. Um and then, as a user, like a centralized sequencer shouldn't really be acceptable. Because you never know what's going to happen with a centralized sequencer, but if they decide to start censoring you, then you're kind of straight out of luck right? So, there's this useful concept that we talk about called time to finality.

Um or time to censorship resistance. Uh with a centralized sequencer, either they can make your time to finality infinite, so that's like if there's no way to get around the centralized sequencer, or they can at least delay your transactions. So, think of Optimism or Arbitrum's inbox model, right? Like, if the if the sequencer tries to centralize you, sure you can still send it on L1, but it might take 5 or 6 hours to get processed from L1 onto the roll-up. And so, if you're trying to do something time sensitive, like liquidating a position on Maker DAO or something like that, right?

Like, there's lots and lots of time sensitive operations you might want to do, and the sequencer can prevent you from doing those time-sensitive operations. Um so, that's just not acceptable for power users, or really for any user. So, we think every design needs to be put something where the sequencer can't prevent you from accessing the roll-up for very long. Now, what exactly that looks like is a really interesting question. Um there's lots of kind of unique designs to explore here. So, I'll just lay out a couple that people are excited about right now. Um and then I'll I'll sort of mention how they fit into the sovereign ecosystem.

Uh so, one popular design these days is what people are calling like based roll-ups, where you just outsource all of the sequencing to the L1. So, instead of having a centralized sequencer at all, you just say like, "Hey, there's some smart contract, or there's some namespace on the L1, and any piece of data that lands there, we will treat it as a transaction, and we'll process it right away." Um the nice thing about that is that you inherit the exact guarantees of the L1. So, you get its censorship resistance, um and you can guarantee that there's no like two classes of citizens, where some of them get fast access, and some of them get slow access.

The downside to doing things that way is you don't get soft confirmations. Um so, a soft confirmation is essentially a promise from a sequencer that says, "Hey, I saw your transaction, and this is what's going to happen with your transaction in the future." And the nice thing about that is that the centralized sequencer can give you a soft confirmation much, much, much faster than the L1 would finalize. So, if you send a transaction onto Ethereum, you know, it typically takes 15 seconds, 30 seconds, maybe a minute for it to finalize. But, if you send a transaction on StarkNet, you can get the soft confirmation instantly.

Um so, there's there's other interesting designs that try to marry the best of both worlds. You can do something like maintain a separate validator set for the roll-up, and those people can vote on transactions off-chain, and still give soft confirmations faster than the L1 finalizes, but without having, you know, just one entity that you're trusting. Um So, at Sovereign, we kind of we like the base designs. We're looking at ways to try to combine base designs with um an optimistic centralized sequencer. So, the idea would be like, you have a centralized sequencer who always has the right to include some transactions in a block. So, he can still give you a soft confirmation, but he doesn't have the right to make the whole block. So, even if he tries to

censor you, your transaction still gets included in the next block. Um so, there's there's lots of interesting designs to explore here. Frankly, it's pretty early. A lot of these decentralized sequencer designs are really just white papers at this this stage. Um so, who knows how it's going to play out. But, there are lots of interesting efforts. There's the Espresso sequencer. There's Suave, which is trying to decentralize building. Um so, we're keeping a close eye on this space. Now, lastly, at Sovereign, we treat sequencing as a module. So, our whole system is a bunch of components that plug together. Sequencing is just one module, so you can swap in different sweet sequencing model without really touching the rest of your chain.

Um so, if you want to start out with a centralized sequencer for testnet, and then swap to a base roll-up, or swap to, you know, using Espresso sequencer or Astria or something like that, that all should be very, very easy to do. So, we we try not to bet too hard on any particular model. Um and just, you know, sort of contribute to the research and help push people towards the good decentralized models. Um but, it's it's really too early to pick a winner right now. Yeah, and just kind of like diving deeper onto the state of L2s and sequencers today. Um so, you know, today is March 24th, Friday, and we just heard zkSync uh launched the mainnet alpha of Era, their zkEVM. And then you hear, uh you know, Polygon's been talking about how they're going to be the first zkEVM to market as

well. So, ZK's like ZK ZK ZK, it's everywhere. You guys are building ZK roll-ups. And so, you know, if we look at the state of Ethereum L2s today, we see, you know, two of the largest uh L2s are actually optimistic rollups. And so, where do you think optimistic rollups kind of fit in into the rollup landscape when you look, you know, a little further out on the on the on the timelines here? Are ZK rollups the end state, or do you think there's room for optimistic rollups as well? Yeah, this is a really good question. So, as an optimistic rollup, you make some tradeoffs, right? You get much longer times to finality for end users.

So, in an optimistic rollup, you have to wait for somebody to submit a fraud proof if the sequencer, you know, did anything malicious. And because you you can't know if somebody's going to submit a fraud proof, you have to wait for just some subjective length of time. And over time, you get more and more confident that the sequencer wasn't malicious, right? And so, there's fundamentally just no way to really get that window down to the sort of timescales that you could get with a ZK rollup. You know, maybe as a user, you're comfortable you're comfortable that no one's going to submit a fraud proof after a week. Maybe it's a day, but it's certainly not like 100 milliseconds.

And that's just a really bad user experience if you're trying to do things that involve cross-chain interoperability. So, if you have a token on Optimism and you want to move it over to Arbitrum, you know, you just have to wait the week so that the L1 can finalize your rollup, right? So, that's really bad for applications that need composability across chains. But it has a lot of advantages, too, if what you really really care about is just having super low fees. Because creating ZK proofs is, you know, it's not that expensive, but it's a lot more expensive than not creating a proof at all. Um So, if you don't need if you don't need quick composability across chains, then being an optimistic rollup might make a lot of sense for your application. So, broadly speaking, we see optimistic as being, you know,

incredibly well-suited for things like gaming, potentially for, you know, new applications that haven't really started taking off yet, but like, I don't know, if somebody does a a medical records on the blockchain sort of thing. Like you don't need composability across chains for many applications. For all of those things, optimistic makes perfect sense. Um Now, the last thing I should add here is that it's kind of true that the biggest rollups are optimistic today, but really there aren't any rollups today. There's only one rollup and that's Fuel V1. And they are optimistic, but nobody else actually has a secured rollup. Like Optimism doesn't have fraud proofs, Arbitrum doesn't have sort of working fraud proofs. They've got fraud proofs, but nobody's allowed to submit them.

Um StarkWare has uh like they've they're the only ones who are allowed to submit ZK proofs to their rollup. And there's there's reasons for that that I won't get into. Um but basically like, you know, none of these are rollups yet. We're still really, really early. So, I wouldn't read too much into the fact that like certain chains have been successful so far. Every chain currently is just a bet that like this technology's interesting and worth building on. Yeah, that's definitely a fantastic point. All of the rollups that exist, there's definitely a lot to to bake out in terms of, like you said, the proofs as well as decentralizing the sequencers. It's still super early within the rollup ecosystem. You touched on composability a bit in your answer there. So, would love to to dive into

how Sovereign thinks about composability. Um I know we've heard ideas with how rollups can be composable with things like L3s where you have some sort of shared proving system as well as things like a shared sequencer. So, would love to know, yeah, like how does Sovereign think about composability between the rollups? Yeah, yeah. So, this is a really, really interesting question. Again, lots of cool research going on here. Um So, essentially what we see this as each rollup is its own independent universe. And within that universe, you have what we call synchronous composability. So, think of Ethereum, you know, you can take your token out of Uniswap and you can drop it straight into Compound all within a single transaction. And as a user, there's like no delay between

those two things happening. And you can also guarantee that like if the Uniswap list draw reverts, so does the compound deposit or whatever. Um so that's synchronous composability. Sovereign rollups or any rollups also have synchronous composability within chains. But across chains, they should be their own separate universe. So all the operations should be totally asynchronous. So that means that like if you want to bridge your CryptoKitty from, you know, ZK sync onto Optimism, the Optimism minting operation needs to wait until it's very confident that the ZK sync freezing operation really has happened.

Um so what exactly the properties of that look like depend again a lot on the specifics of the system. Um but at Sovereign we have this design that we were pretty excited about. So what we do is because we're sovereign and we don't have to pay to submit proofs on chain, um we create proofs in real time. So every time a new block of transactions come in, we create a ZK proof that says this block of transactions was valid and here's what the result was. So if you lock up your CryptoKitty on one of our chains, within a few seconds you'll have a proof saying, "Okay, I really have locked this CryptoKitty."

Now off-chain, anybody can take that proof. And they can aggregate it with any other proofs they want. So let's say you've got rollups A, B, C all the way through Z. They can take all 25 of those proofs, 26 of those proofs, and compress them down into a single proof. And this new proof says basically like, "Hey, here's what chain A's state was. Here's what chain B's state was." Blah blah blah all the way down the line. Now you can take this meta proof, this aggregate proof, and you can give that aggregate proof to any one of the rollups. So maybe pass that that new proof onto chain C.

Now all of a sudden chain C can say, "Oh yeah, Preston really did lock up his CryptoKitty on chain A. So now it's safe to bridge it over to chain C." Or maybe something on chain Z happened that was interesting. Maybe somebody burned some USDC, so they're entitled to mint some new USDC on chain Z. Uh so the magic here is you can use off-chain proof aggregation, and of course off-chain operations are basically free. So it's very very cheap. And because we can produce proofs in real time, you can do this very very quickly. So what that means for a user is you submit your transaction on chain A, you wait for it to finalize, and then you wait a few more seconds for the proof to be created.

As soon as that happens, somebody submits that proof onto chain C. And within, you know, four or five seconds, you can move your transact move your NFT over from A to B. And the magic of this is that there's no central party in the middle, including a chain. So let's say you wanted to do the same thing with smart contract rollups on Ethereum. The typical way that you would do that would be you would take your CryptoKitties from ZK sync, and ZK sync would submit its proof to the L1, the smart contract would verify it. Now your CryptoKitties are on L1, then you send a transaction over to, you know, whatever the StarkWare smart contract, and then the smart contract sends it back up to the L2.

So you have to, you know, wait for this this transaction to go through the L1. The problem is just that the L1 is congested, right? Like everybody wants to be on L1 all the time. And so you have to pay really high gas fees. Um so this is like a L1 L2 system or an L2 L3 system. Basically, these systems all work by passing the asset down from, you know, some chain up here down to a root and then over to a different chain and back up. What we do is we do a completely flat topology. So there's no central party, there's no going up and down. All you do is you send send things directly where they're supposed to go.

Um and what that lets you get is very concretely low bridging times, and hopefully concretely low costs. We haven't actually, you know, finished building this yet, so this is all speculative. Um but so this is one system. There are lots and lots of other ways to approach this problem. L2s and L3s are another sort of approach trying to it to do the same rough thing, except that instead of sending things through L1, they send them through L2. So, does that answer your question? Yeah, it definitely answers my question. One thing I'd want to know is does this only exist within the sovereign ecosystem or can another roll up sort of outside say, "Hey, I want to plug into this system?"

Yeah, it's a really good question. So, there's no reason in principle that you couldn't plug in a roll up that's not using the sovereign SDK into a system like this. And in fact, we do hope to support that pretty quickly. There is one caveat that I should mention here, which is that all of these systems only work across a shared DA layer. So, if you have two roll ups on the same DA layer, they can do this back and forth in the same way that like they can send transaction from, you know, ZK sync to StarkWare through Ethereum L1. But if you're moving across different DA layers, fundamentally there's no way around having a trusted third party doing your bridging for you.

So, so this is the same for us and for every other system that's trying to do bridging, you're going to have a trusted third party unless you are on the same DA layer, in which case you can do more interesting things like aggregate proofs or L1 to L2 bridging. And then going back to the comparison with Cosmos, how does this differ between something like IBC in terms of its security guarantees? Yeah, yeah, this is a really good question. So, IBC is actually it's a very impressive protocol, but it's fundamentally impossible to do bridging. So, bridging is known to be equivalent to the asynchronous fair exchange problem, which is provably unsolvable.

So, all you can do is trust some third party. Now, specifically in IBC, the party that you trust is the validator set of the other chain. So, the validator set of the other chain will sign off on a statement that basically says like, "Hey, some guy on this chain really did lock up 10 USDC. We promise it's safe to mint them on, you know, the Cosmos Hub." And now, that in practice that's probably a pretty good assumption, right? Like I'm I'm not aware of any IBC proofs being forged. But, if that validator set of chain B is malicious, then they can convince an IBC bridge of an untrue statement. Um in a in an optimistic or a ZK construction, there is no trusted third party. Like, if you're on a shared DA layer, you're not trusting the validator set. You're checking that work. And so,

fundamentally, you can be much more secure. Um And then, there's also this whole class of problems that just can't happen. So, let's imagine a bridge from Solana to Ethereum, right? Ethereum's chugging along and producing blocks. And in one of those blocks, maybe I send you a transaction. And that transaction is supposed to, you know, whatever, lock up my CryptoKitty and mint it on Solana instead. So, Ethereum processes processes this transaction, the CryptoKitty's locked up, and then Solana sees that transaction and it says, "Okay, we'll mint a new CryptoKitty."

Well, now Ethereum rolls back. So, all of a sudden, that CryptoKitty that was locked up on Ethereum at one point is no longer locked because of a reorg. Um but, Solana has already minted this thing. So, now either Solana has to reorg, or we've like created a CryptoKitty out of thin air. So, this is like the fundamental thing that makes bridging difficult. IBC has the exact same problem. So, the way they get around this in Cosmos is they basically just say like, "Hey, all of you IBC chains, you are not allowed to reorg. You have to use Tendermint. Um and if you ever reorg, then like that's a validator set fault, and we'll use social consensus to resolve it." Um Now, IBC the protocol actually has workarounds for this. So, they try to support chains that are not reorg-free, um but it's like pretty janky and and dicey, uh which is why IBC

is really limited to the Cosmos ecosystem so far. Or one of the reasons. And I I have another question on IBC, and I don't want to like dive too far down the IBC hole, but it I during this conversation just sprung to my mind, and is, you know, is IBC a case where uh your security is really the the weakest chain your total security is the weakest chain security, right? Because uh IBC assets are path dependent. Let's say there is malicious chain A that IBC'd assets to Osmosis, but then a user on Osmosis brought those IBC'd those to let's say Kanto. Well, now Kanto is holding the receipt of these IBC tokens that, you know, were maliciously created by this this chain A.

So, is that a like am I thinking about that properly that ultimately IBC as a whole is like the only as strong as its weakest link? You're completely right with one caveat, which is that IBC actually tracks all of those paths. So, assets on Osmosis are not fungible. Like let's say you had an asset that started on chain A and then some of them went from B to Osmosis and some of them went from A to C to Osmosis. Those two things would be completely separate assets in Osmosis' eyes. So, if one of either B or C is malicious, it sort of doesn't affect the other assets in pool. It only affects the ones that have actually gone through that path.

But yeah, you're completely right. If chain B is malicious, then they can convince Osmosis that they have a bunch of assets they didn't really have and like the price of those assets will crater or whatever. Right. No, that makes a ton of sense. And so, how do it when we look at Sovereign, like how does it kind of like how is that not applicable in in that ecosystem? And I know you kind of just touched on that, but if you could just kind of double down on that for us. Yeah. Yeah, so the reason this isn't applicable is basically because you're not trusting the validator set. So, in IBC, what you're doing is is you're looking for a a signed statement from the validator set that says, "Hey, we really did lock up these 20 assets and it's safe to mint them on chain C."

Well, if they're lying about that, you have no way to check, right? What we do is we use ZK proofs instead and so there's no way for them to lie to you. Now, I should mention that there are a bunch of caveats here because just because a ZK proof is valid doesn't mean that it's like, you know, useful or meaningful. So, somebody could create a perfectly valid ZK proof, but which doesn't say anything, right? And so, all your smart contract is doing is verifying a proof and not like checking some semantics as well, you're vulnerable to the exact same thing. So, to give an example, like I could create a valid ZK proof which says that 1 + 1 = 2.

And then I could tell you like, "Hey, here's a proof that I locked up 12 assets on chain A." Well, no, it's a proof that 1 + 1 = 2, not that I locked assets. And so, you have to be careful that like the proofs you're validating are actually meaningful. Um basically that like the roll-up chains you're bridging with are actually meaningful chains that have a notion of assets and locking them up and those sorts of things. And so, we've gotten pretty in the weeds here and I I kind of want to just zoom back out for a second and and take a more holistic view of what really is like what's going on here. And so, um you know, Sovereign essentially allows you to create roll-ups uh on any L1 and provided that they can use any DA layer as well. And so, how do you think about like the entire

roll-up ecosystem today? And I guess the ultimate question here is like if I'm a user looking to build a roll-up, why am I choosing Sovereign? What is Sovereign Labs' X-factor? Yeah, yeah. Um so, Sovereign is obviously like pre-launch right now, so you can't use Sovereign to build your roll-ups today. Um but, we think we're going to be, you know, a great contender for a lot of reasons. Um one of them is that we are by far the most agnostic of any way to build roll-ups. So, if you look at all the roll-ups today, like, you know, ZK Sync or Polygon ZK EVM or StarkWare, you couldn't take that framework and use it to build something completely different.

Okay, like they only have code for doing ZK EVMs. That code is super customized all the way down to their proof system. Um and then like you can only deploy them on Ethereum, there's no way to port them to other chains. Sovereign is fundamentally different, right? We are like a framework meant for building custom things. So, we don't make you pick any particular chain. We don't even make you pick a particular proof system. So, if you want to use ZK, you know, uh ZK LVM from like the Nil Foundation to do your proofs, you can do that. If you want to use Risk Zero, you can do that.

So, fundamentally, we're just much more flexible and hopefully much more developer-friendly than all these other frameworks. Um So, we're just in a completely different category, right? There's nobody else who's building tools for building rollups. Everyone else is building the rollups themselves. Um And then we think that the reasons you'd pick a ZK rollup are kind of obvious, right? Like you get good scalability, you get strong security, all that sort of stuff. Uh so, for now, we're kind of the only game in town, but hopefully we'll provide a really great developer experience as well. And one of the other things that we hit on earlier that I I would like to go back to was the ability to pick your own L1 means you could ultimately build a rollup on top of Bitcoin and a lot of people view Bitcoin and its proof-of-work network as like the

strongest form of security that we have today. So, what exciting ideas have you heard about or are thinking about as far as building rollups on top of Bitcoin? Yeah, boy. Um so, frankly, it's really, really early. Rollups on Bitcoin are like this cool idea that's starting to get a tiny bit of traction, but I think um this is maybe the first proposal that has a way of doing it incrementally. So, every other proposal that I've seen requires Bitcoin to like add new opcodes and do a bunch of other stuff, which is fundamentally just quite difficult cuz Bitcoin is a conservative chain for good reason. Um So, with that being said, like there's not actually too much talk about what specifically you would want a rollup on Bitcoin to be yet because we're just now

discovering that they're kind of possible in a reasonable timeframe. Um but some things that I would like to see, I would really love to see general-purpose programming on top of Bitcoin. Um so, maybe something like Ethereum, you know, maybe we don't want to take the EVM, maybe we'd use, I don't know, Fuel VM or Solana's BPF or something like that, but some general-purpose programming on top of Bitcoin would be really, really cool. Um I also think there's a ton of demand for DeFi primitives specifically. So, you know, something like Duality or some other, you know, Osmosis, any of these DEX specific chains, I think make a lot of sense on top of Bitcoin, especially if you also have an asset issuing chain. Something that you can essentially do ERC-20s. Uh, but it's

the early days for sure. I guess the last one I'll mention is NFTs. Ordinals have gotten a lot of attention recently, and they're great, but they don't really have any programmability baked in. Like, it's just JPEGs on the blockchain. Uh, but with a with a sovereign roll-up, you could make NFTs on top of Bitcoin that have the same guarantees as ordinals, but also have programmability. So, you could, you know, pay royalties, you could use them as membership tokens for, you know, uh, exclusive DAOs and that sort of stuff. The sky's the limit. One of the interesting points you mentioned there was that this would require no changes to the Bitcoin code itself, and I think, uh, a lot of a lot of true Bitcoin maximalists out there like rejoice at hearing that. Uh, even even myself who's a little bit more

interested in the smart contracting ecosystem rather than, uh, Bitcoin itself, uh, you know, that's that's a really cool proposition because ultimately Bitcoin's greatest value is the fact of its its simplicity, uh, and it's almost its refusal to change is why I personally find it interesting. Um, so, hearing that it is pretty exciting to kind of know we can build an ecosystem on top of that. But then, uh, the first thing that pops in my head is like, okay, well, those pesky 10-minute block times, uh, would that that would be something that like a roll-up built on top of Bitcoin wouldn't be subject to that correct? That's a really interesting question. Uh, so, it would be possible to build a roll-up on top of Bitcoin that has sort of faster than 10-minute soft confirmations of some sort, but you wouldn't get the full security of

Bitcoin until after the Bitcoin block had finalized. Um, now, I've been sort of kicking around this interesting idea for trying to turn proof of work into like add a add an overlay on the proof of work to let you like commit to some small pieces of blocks. Um so the the rough idea is basically like miners lock up their Bitcoin instead of just withdrawing it. So whatever they earn from uh from mining, they lock up. And then they use that to run like a little uh voting scheme basically based on how much hash power they have.

And this voting scheme is allowed to to a portion, you know, some small chunk of the block, maybe like 100 megabytes uh or sorry, 100 kilobytes of the block. So basically like every 15 seconds, some miner is allowed to say like, "Hey, I'll take a few transactions that are meant for the roll-up, and I'll promise that these are going to get committed." And if all of the miners are working together to do that, they can like give you faster confirmations um without affecting the properties that Bitcoin gives you. So anyway, there's there's interesting design spaces here as everywhere else, but um you know, you won't get full security until the 10 minutes for sure.

And then one last thing that I should add here is that um it is really cool that you can build these things on Bitcoin without needing to change Bitcoin in any way. But you don't get a trust-minimized bridge with Bitcoin. So there is a little bit of a distinction there, right? You can't take your Bitcoin and swap it for an NFT on this chain. Um but if you're holding an NFT on this chain, it has the same security guarantees as your Bitcoin. So it it really does inherit Bitcoin security, it just can't speak natively with Bitcoin until you add an op code to verify snarks back and forth.

Awesome. Uh going back to to Sovereign, I'd love to like one question that comes to my mind is sort of what's the business model here, since you're creating sort of an open source SDK. Um yeah, what's sort of the the business model here? What's the the plans to actually monetize Sovereign? Yeah, it's a very good question that we've been thinking about a lot, and you know, frankly, we haven't settled on a particular way to monetize yet. Uh one thing we're very committed to is making sure that the SDK is free and completely open source. Uh you know, a lot of businesses do this thing where they like open source their code under a license that says you're not allowed to use it unless you pay them. Ours is completely free, completely open source. It's Apache licensed. Like, you can take it and do whatever you want with it, and

it's always going to be that way. Um so, we will find other ways to monetize. We're not completely settled on anything in particular, but there are lots of good models for funding things, um including some stuff inspired by like retroactive public goods funding. Um there's also lots of opportunities to provide useful services around the SDK. Um so, we could help people run prover networks and help people run sequencers. Um but at the end of the day, like we think the SDK will create a lot of value um and once there's a lot of value being created, capturing some of it is not quite as hard as creating the value in the first place.

Yet another parallel to the Cosmos SDK itself. I love that approach that you're taking there. That's that's exciting to see. Um and so, being pre-launch, the obvious question is, how's development going? What are some challenges you've hit? And uh I think your probably your least favorite question I have to ask, you know, what's the ETA looking like? Yeah, yeah. Um so, we try not to give any super specific timelines just cuz we're still early. Um we're hoping to have, you know, something usable in a year to a year and a half, but who knows, right? That depends on a lot of things, including hiring and other stuff. Uh concretely, what I'll say is we ran our first devnet yesterday.

So, we actually sent transactions. We had all the data running on Celestia, and that all um that surfaced lots of bugs, but it did work. So, that was really good. Um we're hoping to partner with a couple of other teams to basically test out an alpha version of the SDK very soon. Our ETA for that is like a week and a half, um but that will not be sort of like the code will all be up there, but um we're not recommending that people try to use the code as it is. It's got lots of known bugs and that sort of stuff. Um so, yeah, a year to a year and a half, hopefully we'll have like a real productionized, audited, ready to go product.

That's fantastic. Yeah, congratulations on that on that first milestone as well as hitting hitting first devnet. Um well Preston, this has been a fantastic conversation. Really enjoyed getting to talk with you on the idea of what Sovereign Labs is building. It's then super exciting to push the roll-up space forward. I'd love if you could give the the listeners, you know, a closing thought and where to find you and learn more about Sovereign Labs. Perfect, yeah. You can follow us on Twitter. We're at Sovereign_Labs if I recall correctly. And yeah, closing thoughts, you know, we're really excited to see all the innovation in the ecosystem. It's a great time to be in blockchain.

And we really think this is all positive sum. You know, we we really believe that Sovereign roll-ups are good for Ethereum and they're good for Bitcoin and that we'll do better things if we all work together on them. So, come build with us. It'll be great. Awesome. We'll go ahead and throw some links to Sovereign Labs socials and website as well in the description. But thanks a lot, Preston. This was great. Cheers.