See all Parallel Polis transcripts on Youtube

Let me begin. All right, hello, everyone. How do you do today? Ahoy, if shikni. Yaxin is made.

So today I'm going to give a talk, improving interoperability through hybrid roll-up. This is inspired, actually, by the city of Prague. So let's begin A little bit about me. So my name is Guoming so Ming is my First name although in my own language. It's the second name.

Although we don't call it like that. So I was born in northern China. But I spent my childhood in a city called Chengdu. So the picture here is actually I went back a couple years to visit my childhood place. And this is a natural habitat for giant pandas.

And there were actually a couple of pandas there, but when I took a picture, they just hide. So I'm the chief scientist of Metis, a smart layer 2 solution provider. My Twitter handle is Dak Economy. This is a construct that I promote for decentralized economy. Dak stands for D-A-C, decentralized autonomous community.

And it is a construct for a sustainable decentralized economy, which is something I care very much and I think it's at the heart of Blockchain, Ethereum, crypto, everything. So that's something I'm very passionate about. All Right, I'm here to talk about layer 2 technology. That is something I do, and it is the technology we also develop at the METIS. So roll-ups, There's just many roll-up projects spring up every day.

So do we have too many of them? And the question is actually a different 1 for the sake of adoption. Because this is a point of view of developers, and end users doesn't see it as we do. Because ideally, they don't see roll-ups. They don't see layer 2.

And for that matter, they shouldn't even see Ethereum. It's like when you're using the internet, right? The cell phone, how many times do you think of TCP IP or CDMA? So it is time for us to think from a product view. I know that develop roll-up builders, we're at the bottom.

There are usually a couple layers between us and the end user. There are middleware developers and app developers, And they're the ones who have to deal with all this chaos. So to make things easier, we should think of the middleware developers and app developers. What do they see? What do they think when dealing with users?

I think a inspiration that I, by visiting this great city, is think of a city. The city is a perfect union between function and community. A city was built to merge different, sometimes competing communities. For cities, there's never a problem of compatibility. That's something prevalent in software development.

But cities think in a different way. Cities accommodate people. People come together to a city to live in harmony, not to live in an environment where they have disagreement and conflict. There are conflicts, but they resolve them by living together. So what can we learn from a city from a software developer or like roll-up developers point of view.

This is important especially for roll-up because we're a decentralized software ecosystem. It's different than traditional software development. The key word here is interoperability, which means that different functions work together. You can switch out parts. You can shift them.

And they just work like a city, right? A city has many parts, many districts, and people can just go to different parts of the city, different shops, different places. And that's how a city thrives and how it functions. So we can definitely take a page from how cities are planned in the first place. And city planning and software development have many similarities.

For example, zoning. So software usually divided the function blocks and connecting them with circuits and city connect different zones, different districts with roads, waterways. So there's a similarity there. And we can probably take a page in try to fit everything together in an interoperable way. So what are the problems facing roll-up design and what we can learn from city planning.

So let's see some of the criteria. I call them the matrix. So in a city space, there's these universal factors, cost, time, and task. And in roll-up space, yeah, we're also being constrained by these factors. So for cost, in the city there's living, right?

Living cost is a major issue when people are living in the city. If you've been to any big cities, you know, right? Some parts are expensive. So some parts are cheaper, but further away from where you work. Also time for you to commute in the city.

Sometimes you live cheaper but in a further place. And also tasks, tasks of the life that you live. For work, for leisure, those are important because you live in the city, not just to stand idle, right, you do things, you complete tasks. And it's the same for roll-up space as well. So the cost is, of course, mostly transaction fees.

Time, we have important ones, confirmation time, finality. Those outside of roll-up space, don't really understand what they are, But they're important for you to design the software. And tasks, we have very distinct but important categories. For example, withdrawal. We withdraw some funds.

And also, most of the tasks that are not these type deposit, but they're also important. So I'll talk about it. Now we come to what I'm here to talk about interoperability in action. This is what we call hybrid rollup. Hybrid rollup creates the best of all worlds.

By worlds, I mean optimistic rollup and ZQ rollup. They have different characteristics which are important for software infrastructure developers, middleware developers, and app developers. But what we should do is that we shield users from all this view. They shouldn't be able to tell what rollup they're using. If they have to know that, that's a failed design.

So hybrid rollup marries optimist rollup and ZK rollup through interoperability design. And Hybrid rollup is a result of a careful product-centric design, because otherwise we could just use 2, right? If we feel like a hybrid rollup, we can use hybrid rollup. Otherwise, ZK rollup. So hybrid rollup is a product-centric view design, which is important as we have so many solutions out there.

So Hyper-Rollup serves diverse users, bringing harmony like a city of conflicting user cases, just like a functional city, a booming, sometimes chaotic, but prosperous functioning city. So we continue doing the musing on what we can learn from city planning. So the challenges in this space, the roll-up space, I mean, What are the challenges? So optimistic roll-up have this seven-day fraud-proof window. This is enough for now.

But consider, right now we're probably in a Very bearish, very down market. Consider in 3 or 6 months, we have the coming boom of layer 2, layer 2 boom, roll up boom. So maybe the TVL will triple, you know, double, triple, you know, and it will become, you know, so significant, it's worth a major attack on Ethereum, right? Sometimes you think this is unthinkable. But when the stakes are high, anything is possible.

So in that situation, the seven-day fraud-proof window might not be enough. So certain users, so here is why it's important we talk about planning. So for a certain category of users, they actually don't care too much about the fraud-proof seven-day window, Because they are not the withdrawal kind of users, right? Those are the deposit type. Probably 2 banks, you know, or 2 private businesses, right?

They want to deposit a large sum of crypto. And they think, oh, 7 day, this amount of money will attract attackers, right? They want to steal our fund. So they want longer fraud proof window, right? They don't, you know, because they're depositing, right?

They don't have urgency to use it. So they can tolerate longer ones, they want security. So can you provide a 30 day, 14 or 30 day fraud proof window, right? I bet most of people think of optimistic. They usually ignore this small but significant use case, because those actually involve a large amount of funds.

All right, so this is some use case challenge for optimistic roll-up. For ZQ roll-up, so we have many ZQ EVM solutions. And EVM is constantly evolving. So there's an EVM stability problem. The circuits you developed for 1 version of EVM might not be compatible with a version 3 days from today.

So it's a bit exaggerated, but you know what I mean. So unlike other mature VM, for example, like the Java EVM, EVM changes are very frequent, and that make ZKE EVM very hard to maintain. So those are the challenges. So how can we learn from city planning point of view to solve those problems, right? So we have to adopt a mitigation strategy.

For optimistic rollup, we designed in our project, the METI's team, what we call ZK-MIPS that enabled a hybrid roll-up that we can provide a much longer window. And this is not by glue a ZK roll-up with OptiMix roll-up. It has to be designed carefully, like planning a city, when Romans develop a city. Roman cities are usually developed from Roman garrisons, So their functions are already pre-designed and pre-planned. And based on this initial setup, and you know, the city was developed this way.

So this is how all these big cities started. So for ZKey Rollup, to solve the EVM stability problem, we adopted MIPS instruction set. So this is a very stable instruction set. It's not like the EVM. Also, they sit on different planes of software hardware stack.

All EVMs are VMs. They're software stack. And MIPS actually are CPU instruction sets. So they're much lower, much stable. All right.

So how does hyper-rollup work in a city planning kind of way, not just kind of roll them together in an arbitrary way. So we basically embed a ZK solution, ZK MIPS, inside an optimistic rollup. So this is still starts. So when you use the hybrid rollup, it still start as a optimistic rollup. So transactions, according to the use case, will go at first optimist way.

So there will be a roll up to layer 1, as was just a pure optimistic roll up. But Most of the use cases that fall in the middle, right? They want fast withdrawal, and they don't want to pay a lot of gas fee. Those can probably be utilized, be solved by ZK solution, ZK roll-up solution. In our case, it's ZK MIPS.

These users will want low SCAS fee and also a moderate, well, moderate confirmation and finality time. Those are not, we say they're instant, but they're actually not instant. Sometimes it takes an hour or a half, depending on your hardware. So this suits certain users. And remember the deposit users that I mentioned earlier?

Those can actually be accommodated by the rest of the optimistic route. We can give them 15, 30 days of frog-proof window. So this is the hybrid rollup that suits a lot of users, a broad spectrum of users. And from product point of view, most of the app developers, middleware developers, don't need to think which rollup to pick to use. They just pick hybrid rollup.

Because hybrid rollup, by careful planning and design, solves the problem that different spectra of user face. OK, I guess that's my talk.

Are there any

questions?

Thank you.

Thank you. OK. Thank you. Oh, it moves. Yeah, well, This is a little bit about what I mentioned, the zk-mips.

So zk-mips is our zk-rollup solution. It's very unique. That basically, the devs, you don't need to know anything about zk. So you can't dodge bullets, but we do it for you. I'm telling you, when we're ready, you won't have to.

So stay tuned for ZK-MIPS. See you guys in Paris. Woo!

Paris. Are there any questions? If no, then thank you again.

Enjoy the ceremony in Studio 1.