Join Sandeep Nailwal, Rene Reinsberg, Alex Gluchowski & Steven Goldfeder I Pragma Denver 2024

Okay, we're ready for our next panel. And for this panel, I would like to invite four amazing founders: Cindy from Polygon, Rene from Cello, Alex from DK Sync Matter Labs, and Steven from Offchain Labs. We'll talk about what's really going on in the world of building across different L2s and the larger ecosystem around how we deliver app-specific experiences. So to have this conversation, please join me and welcome Sandeep Rene, Alex, and Stephen. So, I'll be frank.

I think we need to figure out what the discussion is going to be about, because there are a lot of things we can talk about, and hopefully we'll argue, because that's what makes it interesting. Uh, but I think the name we came up with was aggregated or compound. But, uh, as I was preparing for this, I realized that there's probably a better way to think about what's really going on. And, um, the topic we want to cover is that a lot of blockchains, especially L2, want to think about the best experience for developers and builders of these applications. And when they think about achieving scale, they have different requirements.

They have different needs. They have different resource allocation requirements that they need to worry about need to worry about . And that opens up a whole new area for what you can offer. Uh, we've already seen stacks. We saw a bunch of what Jesse just talked about about L3, their way of thinking about it.

We have seen different ways of using different stacks, from CDK to ZK. But the overall theme always comes down to how do we actually tie all of these things together, and, uh all of these things together, and, uh , what does that long-term scenario look like? If you have thousands of these things, does that just mean extreme fragmentation, or does that mean we've reached a thousand because we've actually made it so that we don't have to worry about fragmentation? Uh, but a kind of correction on aggregated and stackable for me is the differentiation between monolithic, modular, and aggregated, which I think is a certain conclusion I've come to. So, as a preface, I want to start with Sandeep, to talk about the aggregated vision that you recently announced, and we'll use that to put everything else in context.

No. So to understand, uh , aggregated, you know , aggregated, you know , just a quick history, you know, blockchains started out as these monolithic, you know, separate chains where, uh, you know, like, all the smart contracts are in one virtual machine, and there's one single state machine, and, you know, these smart you know, these smart contracts have a lot of possibilities for composing with each other, but the problem is, you know, if it's a single state machine, there are inherent, uh, you know, scaling issues because all the transactions go into one single state machine. Then a monolithic, uh monolithic, uh , you know, kind of, uh , you know, kind of, uh , thesis emerged, which is that you can have different, for example have different, for example , hundreds of integrated systems, as we already said, thousands of such integrated systems. They can use their own data availability, their own verification systems, etc., and derive from Ethereum security, preferably, uh, and, uh Ethereum security, preferably, uh, and, uh , you know, but in that configuration you have huge scale.

But the problem is fragmentation, right ? Because these chains are inherently separate, uh inherently separate, uh , on their own. But, uh , on their own. But, uh , the aggregate thesis is that, essentially, instead of these individual finite state machines, you have an aggregate finite state machine, and that's what we, you know, we intend to achieve by using the power of ZK, where you can have all these finite state machines and virtual machines running, uh, on top of them. They publish their ZK proofs, and we merge them into one single proof so that, using this merged proof, these chains can have cross-chain, uh, compatibility, uh, and they don't have to rely on the cryptoeconomic security of each of these chains, which can later, uh, create scaling problems.

And the goal is that we want to create something like the internet, a web environment of two streams, uh, internet-like type, where I even see these individual, like chains with one sequencer, as unreliable servers, you know, not even that we complicate them by calling them chains and so on. These are trustless servers , like in Web Two, you have trustless servers that can communicate with each other using standard RPC methods and so on, and there is a seamless interface for the user. Here, these will be trustless servers , and using ZK you can achieve such trustlessness, but other mechanisms such as optimistic mechanisms, etc. can also achieve such an effect. That was a great opening statement and I think it focuses on the cell that you start as L1 and it was kind of a monolithic approach.

We see all these problems, and we think we can fix them because we get full control of the stack, and then, seven or eight months ago, you decided to look at the OP stack. So maybe tell us how you came to this decision, why you came to it, and what's happening now. Is that still the case? What stage of this process are you at ? Yes, for us, uh, and yes Yes, for us, uh, and yes , it's, uh, let's put it this way, the world has become a lot more complicated, uh, since the first, uh, team of core Cab engineers put forward the proposal.

And, uh, I will say that at the same time, the hype around long-term L2 for Ethereum has grown even more . I think it's clear that a lot of the innovation and a lot of the density of innovation will be in the Ethereum ecosystem. So it continues to be extremely exciting. As for the architecture, uh, it's interesting, isn't it? Because in a lot of ways, as an L1, you're very, uh, you know, you, you think about what are all these things that you...

I know Jesse just made this comparison like countries and states, right? and you have to ask yourself, "Okay, how do we get all the necessary elements for citizens to exist, the infrastructure, that is, the things that are needed that is, the things that are needed , you know, like in blockchain, to build the applications that you want to see in the world." And I think that way of thinking might change as we move to the second level, right? So a lot of these visions are that in the long term you're probably going to have one big economic zone, right? Which connects all the second levels, maybe the third, right?

And that's great, but in the short term, we're not there yet, are we? So in the short term, there are actually a whole range of different economic zones. And I think a network like Cello that's making this transition has to figure out what we have figure out what we have , and what we can get from participating in certain economic zones, and what are the benefits? You know, if we now return to a comprehensive approach to this issue, what advantages would, for example, launch L3 on the cello have? Hmm, and that's quite interesting because I don't really think it's an "or" thing, is it?

It's not that you believe in one thesis or the other , but I see both coexisting, right? There will be, um, you know, projects launching chains that will want, for example, in the case of the gas seller currency, some of the features will be implemented by those at the L3 level, or even be happy with the finality, um, you know, given the decentralized sequencer that our, you know, val will become sequencers, um, can provide, compared to the finality of Ethereum, and obviously there are tradeoffs in cost here. But ultimately cost here. But ultimately , you know, I think there's something that I think would be interesting to others, you know, it's a little hard to evaluate right now. What is the real benefit of this feature for the user, right ?

Using apps in many different ecosystems, right? Now the data that we have is maybe a little, yeah, distorted, right? Because, you know, a lot of early adopters in this world are looking for alternatives, but what's the real need for someone to, um, use applications in five, six, seven different L2 six, seven different L2 levels or chains? And this, um, this, I think, is less clear, but I think it's an important point. Hmm, I answered the first part of this question, but I've been talked to a lot, so I'll stop there.

I think that's actually very helpful because it sets the context for the rest of this conversation. So maybe I'll go straight to Stephen, which, um, is kind of you, and given what Joel was talking about, since they were looking at the public network stack and the aggregated view first, how do you, well, how does the antitrust view fit in here and what is it intended for the audience? So, in Arbitrum, it's more like Orbit's antitrust vision, as part of its vision for Arbitrum, or the vision that I have, I should say, for the Arbitrum ecosystem, is one where there will be multiple public chains that are very, um, general purpose and have a high level of adoption. We see this today in Arbitrum, which is leading the way in DeFi. We see Arbitrum Nova doing a lot in games doing a lot in games .

And then there will be, ahem, a proliferation of projects that need their own chains. And the question is what do these circuits look like, how do they connect to each other, and how can they get this interaction or efficiency, um, and how do they get this functionality. So, in this vision, there's an idea that's basically called, uh, chain clustering, which is the idea that different chains can kind of come together to, uh come together to, uh , become, uh, for rapid interaction between them. And at the same time, they will have to join in some way. And, uh, we're very similar to the concept of the superchain concept of the superchain , which you may have heard about in a previous talk, and I firmly believe that there's no point in having one superchain for everyone.

And the reason is that you have to sacrifice a lot , because the idea is this: if there are two chains, chain A and chain B, and chain A can send funds to chain B quickly, quickly, that is, faster than Ethereum calculations, then what happens is that negative things can spread. If chain A is hacked, it can quickly send money to chain B, so you have to be very trusting of everyone in that area. And that's why when you have, and that's why , you know, uh, you know, as Jesse just mentioned, Optimism has management as a service, and they essentially, in their case, have to manage that chain and make sure that everybody's using approved software, and software that, um, is consistent with what they've tested, and they're not worried about their security. But for those of us who are very familiar with Orbit, security is obviously critically important. Hmm, but we want to give people the opportunity to customize.

So you'll have Orbit arbitrage chains that like very differentiated things differentiated things . Some can do things that just change the economy and allow creators to get direct royalties on-chain or provide it on- chain, but some can do things that are very profound. There is a team called Phoenix, which as you know Phoenix, which as you know , actually creates a chain with deep cryptography built into FHE nix. Therefore, FHE is designed for fully homomorphic encryption. If you want to create one big chain, it will be very difficult for us to achieve confidence that they have confidence, and they should have, but do I really have the opportunity to evaluate the Phoenix code?

Do I, as a developer of another chain, want to take them to my cluster? No. What happens if you have one is you limit your customization options. And another great example, by the way, a simpler example, is data availability. So we see the proliferation of various data accessibility services.

They all have slightly different models and slightly different potential failure modes, right? Any trust, that is, data availability, uses the Data Availability Committee, which, uh, works at Arbitram Nova. But there are also Arbitum integrations with Celestia, with Iena, with Espresso, etc., Celestia, with Iena, with Espresso, etc., with Near, and you can go through the list, and each of them has a slightly different trust model.

And, uh, if arbitum One were to cluster with an alternative DA chain, it would get the worst performance of all the securities. So we think these clusters should be organic shards that decide to connect. These could be gaming chains if you will, weird cryptography chains cryptography chains , um, these Celestia chains. I don't know exactly how it's going to happen, but I think there should be, um, these clusters with really good interactions. And then you also need to build really good bridges between these different clusters, and that's one of the things that we're working on, uh, with the Espresso team on collaborative sequencing, which is another really important piece of this puzzle.

But I think with these different technologies that complement each other, you can create a really good story about how to provide customization, and you can take the Arbitrum code, uh, arbitr Orbit, run it as an L2 or L3 three, but not just as an island, but also get really good interoperability through other chains in your cluster, or, more broadly, through the arbitrage ecosystem, or through things like Espresso, more broadly, through the aggregated ecosystem. Because I think one of the themes here, at least for me, is that interaction shouldn't be limited to one ecosystem. If you have Polygon chains, I know your aggregation layer has a similar vision, if you have Polygon chains that only interact with Polygon chains, Arbor chains interact with Arbitrage, the chain, etc. has failed . It's unnecessary to sell that you don't want it 100%, so our goal is to tell you how we can overcome this limit.

Uh, it would be like the analogy of a website on two networks, which would look normal: if you have a website on Linux, you can't interact with a interact with a website running on a Windows server. But it shouldn't be like that, right ? So, uh, these chains should look like one single chain, when the user interacts with these chains, to them they should all feel like one chain, just like when we connect to the internet, we don't need to connect, you don't need to worry about which database your data is stored in . Yeah, and that's ultimately, I think, because what unites all of us here, uh, and selling 2 right now, is that we're very Ethereum-centric, Ethereum-based. And that, you know, we all have our own, uh, kind of , project to promote, or we're very, very interested in it; but we also, uh, I think, care a lot about Ethereum, and we don't want to create a fragmented or fragmented Ethereum.

It can happen a little bit, uh, in, you know, the best compatibility can be between two chains of the same stack. But I think there's a lot we can do, and that should be my focus, you know, on asking, "Hey, how can we interoperate with ZK sync, with Polygon, and with Cello on Polygon, and with Cello on whatever stack they end up with?" Um, and I think, so finally, Alex, maybe having heard all of that, let's comment on the ZK stack and hyperscalability hyperscalability , and where do you think that fits in? Yes, we, uh, at Zikync are creating something called a hyperchain network, which has a very similar idea. I think we're all talking about the same vision of Web 3 as the Internet of Chains, because I think we've all come to the conclusion that, uh, the Internet cannot be built on one server or one data center, but on one platform.

So one platform. So , the situation with Web 3 is this: if we're building an Internet of Value, it should be similar to the Internet in its ability to scale infinitely without any restrictions or barriers, and, um, have many disparate systems run by different people, different communities, different organizations. Um, and this, uh, the question is how to solve this with technological approaches, like what, what are you going to use to create this, uh, this network. Uh, at Zikyn, we believe there is only one technology that can solve this. It seems like it's been decided that it will be ZK.

Uh, you'll have all these chains all these chains , like we're going to get to something eventually. Yes. I mean, like you asked, even, uh, drop it, drop it. Uh, I mean, eventually all these chains will have to move to ZK for a very simple reason: we want to build this network to be trustless and interoperable. So, like these, all of these chains should be able to communicate with each other regardless of trust assumptions, right?

Can't you scale assumptions about economic trust even if you subjectively believe that this chain is secure? You can't convince a third-party system of this. But you can easily convince a third-party chain that, uh, this chain has executed certain transactions, uh, because there is a zero- disclosure proof that guarantees that, and the beauty of zero-disclosure proofs is what we now call the ZK singularity. You can aggregate proofs from different chains, for example, an unlimited number of transactions in each chain, and then those chains together, and until you get one single proof, which you establish at the first level of Ethereum, then you generate proof for the Ethereum block itself. We can, like, we're at the stage where we can do this, and then every wallet, every mobile phone in the world will have a built-in verifier that you can verify in one second, and you have, like, the latest Ethereum block, and you know it's correct from Genesis.

All Ethereum transactions, all transactions of the thousands of permissionless chains that are aggregated and established there, are valid, and you don't care who controls them. The beauty of this and, in fact, the focus of what we do at DK Sync, where we're going to fight...I can already see a big battle coming, and we'll hopefully talk about that in a second...we have to ensure that Web 3 remains sovereign from the perspective of individual users and individual chains. We don't want to force everyone to the same standard, to the same thing , like a few big centralized providers that will serve everyone without trust, you know, "don't be evil, know, "don't be evil, " like we've seen in big tech companies before in Web 2.

We need to protect that, and that's a priority of ZK Sync's design decisions: making sure that all of these chains are completely separated. For example, they can have completely separate consensus algorithms, sequencers, centralized sequencers, decentralized sequencers, um, owned by different people, have different tokens, etc., but they all have to interoperate, like, from a user experience perspective, it has to be, for example, email. You have your email address, like Alex from Metal Labs, uh; you have Cardig Global, uh. I don't care.

For example, I send a message, I know it's encrypted end-to-end and its authenticity is guaranteed, there are no people in the middle who can forge it, for example if I send it from, say, Metal Labs to a Gmail account. Uh Gmail account. Uh , you know, I shouldn't need to have two Gmail accounts to interact with each other. I should be able to send this from AFR. Based on intuition, I will let Stephen be the first to decide which martial art we will choose for the fight.

Is it kung fu, karate or maybe nerd fighting? Hmm, angry comments. Let's pick a nerd fight . Um, show. Um, okay.

Um, yes. So here's mine, and I actually had a very similar conversation at Misari this year with Brendan Farmer, and we actually came to the same conclusion, which is this . Um, I think there's a lot of hype and a lot of, um, a little bit of shenanigans going on, so I'll be specific, and I'm sure there will be answers here, so I encourage that. Um so I encourage that. Um , I can be beaten from both sides, so I'm at a disadvantage.

Um, but the thing is, the problem is time, and timing is a critical issue here, and timing is a solution. So let me tell you what I mean . At Offchain Labs, in addition to creating Arbitrum, we created Prism. Prism is the leading consensus client for Ethereum, and, uh, one thing I know is that Ethereum consensus takes time, and when Ethereum consensus is expected to take about 12 to 17 minutes to finalize, but finalization, that doesn't mean that Ethereum blocks will survive that, okay? So, finalization cannot be reorganized, so you know that this transaction has finality and it will not be reorganized, and that's where the big problem is.

And that's why this number is fundamental and critical to this conversation. Okay, you have two ZK chains. Let's call this chain A and chain B. How does that sound? You are A, you are B.

Um, you have two ZK chains, and let's imagine that they both produce proofs immediately. Um, it doesn't really matter because what's really important is the calculations on the chain. That's not the case today, but let's just assume they both immediately create evidence. I know the Polygon team recently announced that they've made significant progress in this direction, which is very exciting. So let's just imagine that this is still the case today.

So you have chain A and chain B, and they immediately have proof, and let's say that proof is immediately published along with the data on the chain. Now the vision that was just described is this: we don't need a sequencer, you just have the actual proof. So I check this evidence, and it confirms that. There is no intermediate trust. There is no intermediate optimistic assumption, because we are simply testing this evidence as it arises.

But this is where this thing happened in 12-17 minutes, because you can give me the chain and you can give me immediate confirmation. But this thing that tells me that this chain is the canonical chain and the transactions are actually transactions of this chain is the ultimate completion of Ethereum, because that's what's happening. You immediately publish your transactions to the chain again. It doesn't really happen right away, but I'm going to admit it right away. You immediately publish a confirmation on the chain, and then 11 or 12 minutes later, Ethereum reorganizes.

And it turns out that these transactions, these confirmations, are correct for this set of transactions, but this set of transactions is no longer the final set of transactions, right? Since Ethereum is the source of truth here, we need Ethereum finality to tell me what the inputs are before we talk about what the outputs are. So, I'm giving you a chance to be skeptical and say that all outputs are immediate, but you need all of these inputs to be fully completed to actually know what the chain is. So, the proof may be there, but it proves a chain whose state I don't actually know. So it's not a case where you have two Zcage chains that automatically, uh, can try to condition different transactions and say, "I'm making a condition that this is a set of transactions," but ultimately anything that can change can lead to a major reorganization if one of them changes and it's the wrong set of transactions.

So, I think if you want to build a system that, uh, every time a block or a user transaction happens, waits 12 to 17 minutes to get that interaction, that's great. And I think ZK technology can do that for you. But in reality, the interaction that users want is a little faster. They want fast and immediate interaction. And if you, if you rely on Ethereum security, that they say, "Hey, we're doing Ethereum security," then ZK proofs alone don't necessarily have to do it, because I can give you a ZK proof for chain A and then just swap the transactions of chain B.

And actually, when I talked to Brendan about this on the Msari mainnet earlier this year, I think it was in September. Hmm, he said, and you can watch the video. He said, " video. He said, " Stephen, you'll like this." I want to tell you."

He said, "There's an optimistic assumption built in here." And, of course, there is an optimistic assumption. Exactly what I was going to say. I said, you just introduced a buffer, which means... So the main difference between these chains, and you know, if you want to take one quote from today, is that all ZK chains are also optimistic.

The main difference is how quickly they regulate this optimism. So whether they come out of this optimism in 15 minutes or 20 minutes, or they come out of this optimism in a week, but ultimately you don't get it, you still have to trust someone, an optimistic assumption, for this vision to work, following this logic, for example, that every transaction on Ethereum is optimistic, you can't trust any single transaction, you have to wait 10, 10 minutes or 17 minutes, you can't pay for coffee with Ethereum because it's not final, it can still be recycled, and there can be a double gap. Of course, there are different levels of trust. A coffee vendor might be willing to risk losing a dollar for a cost-effective location, but you're offering a vision where there are billions of dollars and hundreds of chains that quickly trust each other, and you're skipping that part, and it's optimistic. You can say she is optimistic because Ethereum is optimistic.

This is great. But let's include this part in the conversation. This is a bit of a strong person because within ecosystems like Zikync or Polygon, the interactions, um, um Polygon, the interactions, um, um , will be like our design priority at Zikysync is to preserve the sovereignty of the chain. So we don't want to make optimistic assumptions, so actually, you know, you can wait until the proof is established at some intermediate level. You don't need to wait for Ethereum's final decision because the rework won't affect what's happening inside the system.

If you want interaction between completely separate ecosystems, and you probably won't wait this time. Since this has to go through L1 to another, the conversation here is about interoperability, of course if you are on the same chain you don't need to worry about this because your chain will do its own thing, but the whole conversation here is about using ZK to interact between two different chains within the same ecosystem. I don't know what technically speaking an interruption between, for example, a polygon, what, what? How do you technically separate the ecosystem, and how do you overcome the fact that they...what are they sharing, that they don't need Ethereum's trust, and they trust, and they trust each other?

Then, like, where's the trust, right? They... trust, right? They... what does it mean that they are in the same ecosystem?

Does this mean they trust each other? And I'm going to... I'm going to just satisfy my curiosity about this, um, I don't remember all the details, but I remember that part of the roadmap is to actually implement single slot single slot finality for Ethereum. Am I remembering this wrong ? Like, does that change what you just commented on just commented on ?

Can we even get to the single slot get to the single slot final? Hmm, that would work in about two or three years with things like that. I'm just curious about this . A single soft finality would reduce this compatibility, as is the case with the single Ethereum slot that is. But what I want to say is that finality is also a matter of security and protection, but finality is also very closely related to UX.

And how, if you see all the second-level work, you have a spectrum of finality. For example, if I make a transaction on Arbitum today, I get an immediate confirmation in 400 milliseconds: amazing UX. 250 250 amazing UX, probably the best in the industry right now , and at the point where , and at the point where I get that, uh I get that, uh , you know, some level of confirmation level of confirmation , I'm already assuming that by the time they publish all the transactions and, you know the transactions and, you know , confirm the facts and all that, then there's another level, like, I know that now the transactions and confirmations are on Ethereum, and then, in 7 days I can have, like, full finality, right? And the same case, you know, in the ZK world, uh, also, for example, so, you know, we have this layer, yeah, it's an aggregation layer that's in the middle, where, let's say, if evidence starts coming in really quickly, let's say, 5 seconds, 10 seconds of evidence, you put an aggregation layer in, the aggregation layer will also have some level of economic security. Let's say a few billion dollars of, let 's say, polygons placed there, and you get the next layer of security, you know, uh, there, and then that layer will publish, let's say, every 12 minutes to Ethereum, and you get full finality in 15-20 seconds.

It all comes down to, you know, user experience. Uh, you know, in terms of that spectrum, also going back to OP versus ZK, you know, I mean Polygon probably takes ZK into account completely. And people who are actively working in ZK know that we have probably the strongest ZK team in the industry, so much innovation with PQ. You guys try this, I'm getting out of this fight, struggle. Without a fight, without a struggle.

Well, you know, I think a lot of the research, uh, like, you know, we recently published a study with StarkWare. I think, uh, you know, the zikasc team has a bosoom that's, like, very inspired by, uh, you know, polyplon 2 and stuff like that. So we contribute to the open source code, and anyone can take it anyone can take it ; That's not a problem at all , eh. But in terms of, for example terms of, for example , an optimistic world against ZK, I think world against ZK, I think that even in the fairly long term there is room for an optimistic, uh, you know, security that is in a way a cryptoeconomic security. And the way I see it, the long-term world, or at least the medium-term world, the world will evolve in a way where this whole new internet, the trustless internet, will have a large number of verified ZK chains, you know, but it will also have several large clusters of cryptoeconomic security.

The reason for this is that when you have an optimistic summary version, and you know, I'm advocating optimistic summary versions here, is that the ZK proof is always associated with some level of cost. Now, compared to execution, ZK proofs cost at least 1000 to 2000 times more than, say, time or, uh say, time or, uh ... Like cost, right? You know, there's an opportunity to execute all Ethereum transactions on a simple machine for $50 on AWS. It will take you a few days, or you can calculate all the transactions if you have to prove it all; it's going to take you a lot of, uh, time, so there are some costs involved, right?

But when you have optimistic projections, you have the value of capital, because capital provides safety, right? As you know, there are reductions and all that, an appeal mechanism, all that. So ultimately the cost, if the cost of providing optimistic summation, uh, you know, is lower than, in cases where the cost of providing summation with optimistic, uh, economical, uh security is lower than the cost of proving with zk, then in those cases optimistic security is going to be better, right is going to be better, right ? But in the case where you have, for example, the cost of proving zk is better than, say, the cost of securing with the cost of capital, that would be , as you know, a ZK post. So I think the world will exist somewhere in the middle, you'll have, uh, ZK-like summaries, you know, and some optimistic ones.

So I want to say two things, uh, go ahead. No, I just love it, it's great. It's actually like I'm taking notes. Um, but no, I, I want to, maybe I don't know where you want to take the conversation, but I just want to like want to like where it's going. One thing I mean for the audience is, it might be, I mean it might be funny, right?

That's great, isn't it? It's not like we're all here like Kumbaya, but I think like Kumbaya, but I think it also speaks to the strength, right, of where Ethereum is today is today , right? Because there's not just one approach, right? There are several approaches, there are compromises, right? And, you know, in the vendor, right now in the community, the discussions that are going on...

Right, I mean, I, I, I see it with my own eyes, right? So, since the initial proposal, which was with the OP Stack, we, the core team, have carefully studied the Polygon Stack, Arbitrome have carefully studied the Polygon Stack, Arbitrome , ZK Sync, and it has become clear that there are trade-offs for each of the approaches, right? And there are advantages, and, you know, there's no best solution, right? Without, you know, words, for a particular use case, for a particular event, for example, for one seller who wants to make this transition, there will be criteria that will determine which of these options is the best one for today, right? I think the point to note here is where there are situations where you go down that path that create a kind of lock that is harder to unlock in the long run, right?

Because ultimately, I think that's the point of what Alex meant, right? Ultimately, we're all looking towards that long-term future, you know, where everything is much more open and connected. And I think that gets a little lost sometimes, don't you? And I think that, um, but TLDDR here, I would like everyone to understand that billions of people are going to come into this, you know, web 3 world. You build apps for them .

And the good news is news is that there are many different approaches in the Ethereum world, and even more than this panel, that push the boundaries, for example, giving people a set of features that can match what they want to build. So maybe from a perspective, I, first of all, agree with that vision, and, you know, just to be clear, I also agree with most of what's on the deep set, which is, it's very valuable. You know, these guys are truly incredible, and honestly , they exceeded my expectations. If you look back at my academic history, long before the publication of the Arbitrum article in 2018, I was publishing papers on ZK proof systems on ZK proof systems . So, even as just a tech nerd, I'm really, really excited about your work, and you're doing, uh, really fantastic work.

And I think, you know, our way of thinking is to think, "What's the best technology today and where are we going?" I don't know exactly where we're going. Hmm, I haven't made any specific bets, but I firmly believe that, uh, today, from a cost perspective, from a maturity perspective and flexibility perspective, optimistic robots are the right solution, and their ability to upgrade over time to something that, you know, I don't know. I didn't bet on ZK's proof, maybe the next thing you know, I could tell you: in 5 years there will be something better years there will be something better . Everything we talk about today will seem primitive; that's exactly what it looks like when you look back.

Remember when everything was about Plasma four years ago, yeah, Plasma and the future of the states? The only thing I wanted to say is that this is a common mistake. I do n't think that's the main point of what you said, but like optimistic summaries, they lack what I call cryptoeconomic security, because staking is essentially an anti-PAM mechanism. So anti-PAM mechanism. So , there's, uh, security assumptions and assumptions going on, and the optimistic summary is that, uh, one, uh, validator today, this set of validators got whitelisted.

But once, uh, in the vision, anyone can check. And that goes for the arbitrary, the bold, uh, when it comes to mainet. Um, first of all, mainet. Um, first of all, any validator can secure the chain, and if they lose, they have to make a bet to do it, and they lose that bet, and it's a kind of memory management mechanism, but anyone can do it. So this is not a case of stakes protecting the chain.

This chain has this assumption. I, I should actually say socio- say socio- economic security. I don't know if you agree with that , because within 7 days you expect someone from the community to execute all the transactions, and if there is an error, then you execute it. So I should say that, or you do it yourself, right? One of the nice things about bold is that is that you can actually bring people together to do it.

In the old protocol, it was like someone could, like, fake it, start doing it and then intentionally lose it, but with boldface, you can kind of commit to your previous one. So you have to know what you're doing yourself, or become part of a coalition that's scaling, you know, I mean know, I mean , I just want to say this part also about what everyone should read, like, there's a page on Wikipedia about the protocol war, right? So I think we are all competing for the same vision. It's a trustless internet, and they're all interacting, interacting, well, enter, uh , inter, there's inter, right, yeah, so trustless internet, and I think in the medium term a lot of these approaches are different, but eventually they're all going to come together they're all going to come together , and I personally, I'm a firm believer in that, I talk to Stephen almost every week, constantly talking, you know, and then, uh you know, and then, uh , you know, everybody, like the OP team, the Sell team, everybody. I haven't spoken to Alex yet, but the time will come very soon for that too.

But what I really want to, uh, find a place where all the protocols can work together and exchange value, right? Otherwise, this is how, in essence, this struggle is about the approval of values, to be honest of values, to be honest . In the end, you are all fighting over how to let others win. That's right. And ultimately, this is the goal that should be maximized.

And you have different nuances on standards on what we think is the best way to approach this. This is good and acceptable. I mean, the good thing about standards is that there are so many to choose from, right? And, uh, and we all achieve the goal. But, um, I think it's kind of a shared discussion, kind of like, you know, community, and maybe it doesn't get to the point that there's hidden capitalism there, and few approaches will ultimately prevail.

But if we could find a way where there can be, for example, a shared endorsement of values for many of these approaches, and they continue to evolve into something better for users, that's something we should try. And we see this on a social level too, like if you had a salon and a person from Avalanche was here, we would all be best friends. So, you know, we have a lot in common. Even though we may have things in common, we are already good friends. When we quarrel, we do n't quarrel with people n't quarrel with people .

We argue over ideas . We argue over ideas to find out the truth to find out the truth . And as we already think, the arguments can escalate, just because we want to figure out what's right, I think this is a great title to wrap it up . So I want to thank Renee, Alex, Steven, and for this, uh, basic conversation, and it looks like we're going to have a second version of this thing that's completely dedicated to compatibility. So thank you again.

Uh, after that, uh, please join us for lunch, and we'll continue in an hour.