Fireside Chat: Vitalik Buterin, Jordi Baylina and Mihailo Bjelic

So, with that uplift, we will continue with our friendly conversation, and we invite Vitalik and Jordi to stay with us. And there is no better person to conduct this conversation than Mykhailo . Take my word. Thank you very much, Grace. Not sure if I'm right for this right now, given the situation.

This is extremely exciting. This is very interesting. And so, fortunately, everything turned out very well. Oh, yes. Hello everyone again.

I am very, very excited and honored to have a brief conversation with two people I respect immensely. I think, without further ado, let's get to the point. I think we could start with emotions, if you don't mind. And then we can return to rational conversation rational conversation . So just tell me how you feel about what just happened?

Do you have any emotions you can share and what do you think about this event? Is this really as important a milestone as we think, and is it truly a gift to the community? Share whatever you are feeling. Yes. Well, I feel very happy and, you know, excited about what lies ahead.

This whole ZKVM thing—it's something that I think we've all been dreaming about and talking about for so long, and to see it actually happen on the mainnet, all the pieces coming together and just working—it's so amazing. For me, it's, you know, a strange feeling, because I've been dreaming about this moment for two years, you know? But when you get to that point, and even in the days leading up to it, I'm more worried about tomorrow and the day after tomorrow, and what's going to happen tomorrow and the day after tomorrow. We will plan what we will do next and what we will build, we have a lot of things in the backlog, because the last three months we have been working a lot on security and have not done anything new, just checked and checked the code many times, and we have a lot to improve. So for me, the most exciting thing about this event is that we will complete this phase and continue to build and improve, it's just an important milestone.

I think this is an important milestone because we have something that was previously impossible. So, now it's reality, it's a game. So yes, we might be able to build it, but there's a long way to go to scale. We are just starting to scale. This is just the beginning, and now we need to really scale.

We really need to make a lot of transactions happen faster, and I think that's why this is an important step, because it will allow for good scaling, this is the beginning of scaling Ethereum. We will finally see applications that were previously impossible because scaling now makes them possible with the security of Ethereum. So I think this is a really important moment for this area. Thank you so much, guys, for sharing this. So, okay, let's get back to rational conversation rational conversation , maybe a little more technical.

Maybe I should start by saying that I think over 10,000 people have registered, and hopefully that's what we've been getting from our friends at ETH Global, and hopefully a lot of them are a lot of them are newbies, right? And we want to attract as many newcomers as possible. So for their sake and for the sake of all of us, could you briefly summarize: what is the importance of these second-level solutions and the ZK-EVM itself, just in your own words for everyone? Perhaps it is always useful to summarize. Yes.

I think almost since Ethereum launched, I've been talking about scaling as one of the most important problems Ethereum needs to solve. And I think in the beginning, during the first few years of Ethereum's development, it was pretty theoretical, right? We knew that Ethereum had to scale somehow scale somehow to be able to serve millions of future users. But at that time, transactions were cheap for users, and Ethereum worked fine. But then, especially over the last few years and during the last bull market, it became clear how expensive the Ethereum core network layer is , right?

I remember the trip to Argentina and how everyone was using a Binance account, right? And from their perspective, it makes sense because transfers within Binance have no fees. But at the same time, you know, I think that as a crypto ecosystem, we, yes, of course, want to eventually move beyond centralized approaches. And I'm sure many at Binance feel this way too, right feel this way too, right ? But creating something decentralized that is both convenient and practical for users is much more difficult than making something centralized and simple.

We saw the FTX situation last year, and these incidents remind us once again how important it is to have real and practical decentralized access to the network. Because if this is not there, you get a kind of "Frankenstein" of centralized and decentralized elements, which often turns out to be even less secure than a completely centralized system. So I think scalability and decentralization are extremely important, and for the past few years, the Ethereum ecosystem has focused on rollups as a primary scaling strategy. This is because the time of Ethereum's core developers is limited, as is the network's ability to handle complex processes. We decided not to put all the responsibility on level 1 to leave room for independent innovation independent innovation .

And so, you know, recently we've seen the emergence of a Layer 2 ecosystem. Although, I think the second-tier ecosystem has been around for quite some time, right? But for me, 2023 is exactly the time when I want to see this ecosystem truly mature. And the main sign of maturity is when second- level solutions become truly full-fledged “ full-fledged “ second levels.” This means that you are not just claiming a future proofing system when in reality you only have multi-signature.

No, you have to have real evidence, you know? And, um, you know, you have a system where your coins at level 2 are actually protected by mathematics, not, um, you know, a group of, say, five out of nine people, or however many there are, who, if they wanted to, um, you know, take your $29 million and $29 million and , uh, enjoy retirement on some tropical beach in a country that's not Montenegro, then, uh, you actually have almost no protection against that. So it's, uh, you know, to see how, I think, Polygon is making such progress, just in terms of improving their security model over the last couple of years over the last couple of years , it's been, uh, really incredible. And that's, uh, something that incredible. And that's, uh, something that I, I know, look forward to seeing in the rest of the Level 2 ecosystem, right?

And, uh, I mean, yeah, I'm just excited that, you know, scaling—it's not just some theoretical thing, but something that Ethereum has already solved in practice. Such an achievement. Thank you very much, Ale. I'll give you the floor, Jordi. Well, that's the magic of engineering.

Engineering, I mean, um, we, we're not that much of a theorist. We simply take it and implement it to solve real problems. And, uh, when I entered this space entered this space , you know, it was amazing to me, because well, you can do so many things, but really things, but really , when you want to do something, you start to discover the limitations of that space. So okay, I want to use this because I think it's incredible. So, uh, this is what I've been working on I've been working on , this is, okay, what we need to do to get this amazing technology into people's hands and spread it around so that anyone in the world can use it.

And, and well, you see, there are a lot of things, uh, but security, uh, I mean , uh, usability, but scaling was fundamental. If, if you can only do, uh, I don't know, 30 transactions per second, that's not enough. This is not enough for the world, but it is not enough even for a relatively small community. So, what do we need to do? And we thought a lot about it: you know, state channels, we're thinking about plasma, a lot of effort is being put into rollups now, remember this blog by Vitalik?

People are just working on what they say is happening. Okay, it's like we're starting to see the light, and it's like, okay, this is the way to go in that direction. Okay, separating data availability and execution, and, and, and, that's a long way off. But we have just started on this path. The Ethereum Foundation, I think, is making a lot of progress in data accessibility and so on, and the ecosystem is also working a lot on these rollups and second-level tools, and it all looks like a long journey; But everything points to the fact that in a few years, or even months, we will be able to make this technology available to people, and I think that's the point.

Thank you very much, guys. It was really great. Maybe let's go a little deeper, a little more technical. And, as we can see, many projects working on ZKVM have appeared recently. And we at Polygon, and I'm sure Vitalik too, are very happy that this is the case.

But this has raised the need for some clarity: what exactly is ZKVM, are there different types of ZKVM? And Vitalik recently contributed and helped a lot in this matter by publishing several blogs about four different types of ZKVM, essentially different types of ZKVM, essentially introducing at least an initial nomenclature for this wonderful technology. And I'd like to ask you guys a little bit more about that. You can join in, both you, Vitalik, and Jordi, first about where Polygon ZKVM is now, what type of ZKVM it belongs to, what will happen in the future, and perhaps about the nomenclature itself. If now, from this perspective, would you change anything in this nomenclature?

And in general, what do you think about this whole nomenclature? Does this mean, for example, that the first default type is the best solution, or is it not so clear-cut? You should talk a little bit about this in the context of Polygon ZKVM and the nature of ZKVM in general. Maybe Jordi will answer the question about Polygon first. Yeah, I mean, we Yeah, I mean, we , I think it was in that blog post about classification.

I think that clarifies a lot, because at that time there were a lot of different rollups doing different things, and, you know, marketers were just adding and bringing everything in a row. And that clarifies a lot, because in the end, from a technical point of view, everything is as it is, and things are as they are. In the case of Polygon, we identify as type three. I think we fit very well into type three, and we are moving towards becoming type two; This is, to some extent, the path extent, the path we are taking. So the idea is to get closer and closer to Ethereum.

We want to implement some pre- compiled smart compiled smart contracts that are not ready yet, and there are some small details, you know small details, you know , this new type of transaction, and there are a few nuances that we want to get closer to on that front. We're moving in that direction, and I think that's a good thing, the fact that, for example, in our system, people don't have to reuse, they don't have to reuse the toolkit. So they don't need to use another toolkit another toolkit , they can use the entire Ethereum toolkit. You just use Solidity, you just use Remix or Hardhat, and you just build, connect to Ethereum, and go. This compatibility is very useful for the end user, so I think it's a good compromise to have.

many users using this. Yes. So, I guess from my perspective, the way I would summarize the type system in one sentence is that the lower the type number the lower the type number , the closer it is to being an almost exact copy of the Ethereum EVM. And the higher the type number, the further it is from this. But the reason you might want to use a higher type of EVM is because it's either easier to design, or because if you do some things a little differently than in EVM, you can get efficiency gains that you can't otherwise achieve, right?

So the difference between the first and second type first and second type , for example, is that the first type requires perfect compatibility so that you can verify the existing Ethereum runtime, and that includes some pretty " includes some pretty " unfriendly" SNARK stuff, like potentially verifying a huge amount of Keccak, right? And if you wanted, you could replace Keccak with some more Stark/ more Stark/ Snark-friendly hash function, right? It's possible, and it's probably right for level two today, and in 5 years it'll probably be right even for level one. But that means that today you won't be the same as the first level, right? So, in my opinion, the ideal ZK-VM implementation should be flexible and support all types, right?

I think the ideal ZK-VM would have the following settings: you want settings: you want to enable work with the Keccak Patricia tree and verify Ethereum blocks; you want— Ethereum blocks; you want— configure it to work with something more optimized for ZK, and it will be more efficient for you. It may even have different pre- compilations, depending on what you need. And you could choose to what extent you need compatibility and to what extent you need compatibility and to what extent you need efficiency. And this should be the choice of each individual project. I think it is quite possible to create such implementations of ZK-VM that would allow achieving a balance in this.

I guess it shouldn't be too difficult if you start with the higher types and move down to the lower ones, right? Because you had your previous code anyway, right? So you just make it open in both directions. Thank you. I want to add something else: I conducted such an experiment myself, because when you work with ZK-VM, you learn a lot of new things.

This is a challenge that arises every week. And you think: okay, having this technology, if you want, forget about full compatibility, let's try to do it efficiently, let's see how it can be implemented. And the interesting thing is, I wouldn't change a lot of things, you know, in how we've managed to optimize the process. There are things that, I guess, yeah, I know, there are things like memory alignment that are a little bit complicated in Ethereum, and maybe I would remove some of those parts, but not too many, but not too many, uh. You know, the way we compute, like arithmetic, arithmetic on different fields, the way we compute caches or hash functions, the way we work with storage, the way we execute programs, and I mean, yeah, there could be some differences, but there should be a lot less should be a lot less than I thought when I started, and that's because of the high level of optimization that we've achieved while staying compatible.

So, for us, the requirement is that we want to be compatible with Ethereum to be compatible with Ethereum . Uh, so this is the specification. Let's see what we can do with it , and we've gotten so good at it that we've come up with some really cool tricks and algorithms that are, well, even better than if we were doing anything else. So these are some of the conclusions we come to there we come to there . Of course, I mean, there's a whole spectrum of these things.

We should go step by step We should go step by step , but in many respects it should not be very different. Thank you very much, guys. I would have so many more questions besides that, but let's touch on at least one and then we'll wrap up a little bit, because I think we need to stick to a schedule. So, we're very happy to have made it happen, aren't we ? And we, uh, believe we're ready for the main network, right?

We have, uh, numerous external audits, numerous internal audits. We have a test network that's been up and running for months now and, uh, all that stuff, but still, it's very important to say that this is a very complex technology. This is a new technology that has n't been implemented before, and, uh, it's important to be responsible, right? With this in mind, Vitalik published another blog post where he talks about the proposed stages for ZKVM rollovers, or rollovers in general, in the context of gradually removing the " gradually removing the " training wheels" and safety measures. I know we have a security panel discussion coming up soon, but can you give us a one-sentence summary of your thoughts on this proposed plan by Vitalik, as well as on ZKVM in the context of liability?

Yes, of course. I think this post, or the post on EthMagicians, was caused by confusion and a strange marketing situation where many projects call themselves Layer 2, but people don't understand but people don't understand what makes a Layer 2 project, what doesn't, and what makes it decentralized. And the purpose of the post was to help people focus on what matters most— safety. And the main thing in security is a difficult compromise: when do you trust people more, and when do you trust the people more, and when do you trust the code more. It's a tricky balance, especially since we're dealing with a fairly new technology that inevitably has bugs, and they'll likely continue to appear for some time.

But overall, the challenge is that we want to start moving away from systems that call themselves Layer 2 but actually require complete trust in a small committee. We don't want a system where a multisig of four out of seven people can run away with $29 million and go on vacation to a tropical island. But at the same time, you know, we want to do it responsibly, and if you, say, from the very beginning, just to get ahead of others, put out a release saying, "Okay, guys, the code is the law, guys, the code is the law, " and then people put in 29 billion, and it turns out there's a mistake, then that would be pretty bad too, would n't it? So I think I tried to structure things and identify some compromises, you know? So, I have identified three stages: I call them stage zero, stage one, and stage two.

Stage zero stage two. Stage zero is essentially complete trust in people, right? So it's kind of like a rollup framework: you send transactions, you have backup channels, all of those things, but at the same time there's some kind of cancellation mechanism. After all, the cancellation mechanism can decide where the funds go, with a 51% threshold, right? It's like training with training wheels training wheels .

Stage two essentially means everything is running entirely on code. However, there is one caveat that I allowed for in defining the second stage: you can create a mechanism where, if someone can prove that the code contradicts itself, you can activate the emergency switch and get people involved, you know? And self-contradictory code can arise in two ways, right? You can have two different ZKVMs or one ZKVM, and the switch will work if someone successfully proves two different states for the same data—well, there are many different ways to do that. Or on the other hand, if no one sends valid data for a whole week, you know?

This would also indicate that something is broken. But otherwise, if the code works correctly, people shouldn't be able to undo the code's actions, right? This is a long-term goal, but it requires confidence in the code and that it does not have serious bugs. The first stage bugs. The first stage is something like a golden mean, right golden mean, right ?

So, essentially, it's halfway there, right? If stage zero requires 51% of stage zero requires 51% of people to, well, overturn the decision and transfer the funds anywhere. For the second stage, you need 101% of people, you know? 101% is more than 100%, so you can't do that. And for the first stage you need 75% of people.

So I proposed a "six out of eight" option, where there are enough people in multisignature outside the organization that the organization itself cannot simply take and transfer funds wherever it wants. And with that threshold, you still have the ability to intervene if things go completely wrong, right? I often worked with multi-signatures, you know? And if something really serious happens, you can usually get almost anyone together pretty quickly, right? Almost everyone, especially if they are professionals.

But at the same time, it is much more difficult to gather 75% of people to difficult to gather 75% of people to agree and escape to a tropical island than 50%. Yes? So it's kind of a middle ground, and my goal for 2023 was to have the level 2 ecosystem move to at least the equivalent of stage one. And I think it's perfectly normal to stay in the first stage for quite a while, right? Because we want to be sure that the technology works before we trust it even more.

But if you're at stage zero, then you're essentially not handing over any authority to the code yet, right? And it doesn't matter whether it's a ZK matter whether it's a ZK rollup or an optimistic rollup optimistic rollup —after all, you're just a multi-signature controlled by a security council. So, in the first stage, you're kind of saying, "Okay, we have a real proof system, and it has real power, but we don't necessarily give it all the power." And, you know, there is room for the Security Council, in the event of a strong consensus within it, to overturn the decision of the proof system if there is an error. So, I think the first stage is kind of a gold standard where we're talking not just about the very centralized things that we've had so far, but about real proof systems, whether they're optimistic or ZK, that have real weight and significantly influence what happens on the network.

But at the same time, we leave room for error and don't trust everything completely. And I think that 's a completely achievable goal for both many ZKVM and optimistic EVM projects this year, right? I've talked to some other developers, and for example I know that Arbitrum wants to open up their proofing system in the near future. And I think they have security council parameters that are even stricter than the requirements for the first stage. So I would really like Polygon to join the first phase camp soon and set the standard that, they say, you have to have a real proofing system.

The proof system must actually work and have some weight, but at the same time, we don't go from zero to full trust from day one. We can be a little more careful and act cautiously for a couple more years until we make sure that everything is really completely safe. And then we move on. I'll just mention that Polygon zkEVM is already the first stage, in fact, this morning we changed the synchronization to six out of eight. This morning it was four out of seven.

We changed that to six out of eight. just being at stage And the coolest thing is that we're already pretty ready, at least from a code perspective, to move on to stage two. In fact, we could be in the second stage be in the second stage , if you want. Of course, we don't want to rush until we feel safe; we need at least... but one of the pieces that we're missing for the second phase is, first of all, the need to enable...

we need to enable forced transactions forced transactions . We'll probably do it in a few weeks because it's an important mechanism, but it's something that... we turned off at the last minute because of some issues, but we'll turn it on, maybe turn it on, maybe in two or three weeks. There is one more thing— removing this safety switch. This is probably the hardest part the hardest part , because we need to be sure that all the security is in place, so it will probably stay.

We plan to have the system running for at least six months without any critical... issues being detected, at least. So, we'll need some time for that, and the other thing is the wait time for the update. Right now it's 10 days, we need to increase it to 30 days to... but the plan is there, and the main thing is confidence in the code, and we will continue testing and implementing some updates.

So we will stay here for a while. Yes. No, I really appreciate the commitment to security and I'm really glad we finally have a year or two of working with Keith on the mainnet. So, big congratulations on that. Thank you.

Thank you both very much again. I can just share my humble opinion. I completely agree. As we saw, as Groby said, Polygon ZKVM is officially probably the first type, sorry first type, sorry , first stage when it comes to these levels. And I completely agree that targeting the first phase in 2023, as you said, is a wise, optimal and responsible approach, because we really want to gradually move to a fully secure and fully decentralized solution.

Perfectly. It was a fantastic discussion. Thank you, guys. Thank you very much, everyone. And if you have any closing words or anything you'd like to share with the community, any message or advice, we can wrap up gradually.

I'll just try. That is, this is a network, a new network. This is ZKBN. So if you are a developer or user, just give it a try and see how easy it is to build on Polygon. OK.

Yes. I, well, I tried sending two transactions, and so far, it's been very straightforward. So, you know, I recommend it. And take your seats. Grace opens the door.