Defragmenting the World Computer

All right, great, thank you very much for coming. Yes, so today I'll quickly go through defragmenting Ethereum or defragmenting the world computer, how we get better cross-chain integrity with controllers. So this talk is really focused on controllers and what controllers actually buy us in the real world so that instead of the ecosystem currently feeling like 15,000 different chains that are all honestly not connected to each other, that it feels like actually one ecosystem where users and applications can easily roam and sort of cross this multi-chain world that we're clearly seeing at the moment. And this is, a lot of this technical work is motivated actually by the fact that I think I cannot explain the current state of the ecosystem to anyone in the real world. Like, my parents clearly won't understand how we've arrived in a situation that is honestly less convenient to use than many of the existing systems because you have to have, I don't know, six different wallets, they all sometimes work on some systems but on others, none of them have privacy and so on, right?

So how do we actually fix this and how do we get cross-chain integrity with controllers? So the next generation of interoperability really requires a paradigm shift from asynchronous message passing to managing shared state integrity. At the moment we're living in this world of asynchronous message passing, right? Like when you, for example, send an IBC message from chain A to chain B, you are doing an asynchronous message passing action. Or even like when you move from Ethereum main chain to Optimism, this is an asynchronous action.

The controller architecture fundamentally provides a framework to solve the core problems of provenance, privacy, and composability that limit current protocols, whether this is IBC or our patchy framework of Ethereum and Ops. Okay, so starting with a fundamental trilemma, like what's actually the problem? Why is this hard to do? Well, in the CAP system, CAP theorem in distributed systems, we sort of have three properties. We either are consistent or we're available or we are partition tolerant.

And you can generally only pick two. So what does the multichain ecosystem actually pick at the moment? Well, we pick availability and partition tolerance. So it does not mean that there is kind of guarantees for global consistency. And when you don't have guarantees for global consistency, the core challenge becomes how do you manage this shared state integrity?

Where like forks happen all the time or inconsistency can arise naturally, right? We never really built the interoperability solutions around this idea that many of these systems may spin up at any given moment, may disappear at any given moment, may become unavailable at any given moment. So we really, with this actual fundamental design constraint in mind, we have to come up with what is the correct or what is the best way to actually make the, to defragment the sort of multichain ecosystem. And actually, just a curious show of hands, who here still remembers that you like would run defragment on Windows hard drives? So yeah, this is pretty much the same idea, sort of conceptually speaking.

You want to make the system faster, more nicely to use or nicer to use by actually from time to time making sure that state lives in the correct places. But let's say, start with a past critique. And I'll focus here on IVC, mostly because IVC is actually by far the most battle-tested and well-scoped and well-designed system that was trying to solve, or is trying to solve interoperability in this multichain ecosystem. And maybe just quickly, when I say chain, I really mean whether you're talking about an L1 or an L2. These are very arbitrary distinctions.

To me, these systems are all just fundamental chains, they're fundamental to ordering domains. So when I say chain, you can interpret chain as to mean an L2 or an L1. Maybe this will be next year's talk of how we should stop calling these systems L1s and L2s and how we should stop confusing everyone with these very nonsensical terms that from a fundamental technical perspective mean very little. But yeah, let's start with IVC. And sort of like what worked, what didn't work.

So IVC made some tactical mistakes. I mean, it was a very complex problem, or it was a very complex protocol that was honestly over-engineered. And in its defense, I can only really say that IVC was ahead of its time, i.e. it was designed when the multichain, it was designed in 2017, 2018, when we really didn't see the multichain problem at scale.

We didn't have optimal and arbitrary and all these 20 different roll-ups that actually need to talk to each other. So it's much more of a conceptual idea. We are going to move to this world and we should think about how interoperability will actually work in practice. As a result, we also ended up with a bunch of primitives. The honesty in retrospect provided suboptimal trade-offs.

So now, with the benefit of hindsight, we can actually think about how do we design a protocol that is more adapted for the problems that we actually see at the moment in the real world. Yeah, some of the strategic mistakes were that IVC never really addressed the problem of path-dependent tokens. When you think about it, this is actually something I think that a lot of people don't fundamentally internally understand. It's when you send an asset from Ethereum to Optimum to Arbitrum, or it matters, like the path matters. So you go from Ethereum to Optimum to Arbitrum to ZK-SYNC, and now you have some ETH there.

This is not the same as the ETH that you send from Ethereum to Arbitrum to Optimum to ZK-SYNC. Like these two systems are fundamentally, like the two assets are fundamentally different. And there's sort of like, you have to think about how you provide a way to do automatic path unwindings for not just asset transfers, but more complex state transfers. And I think we had a lot of talks today about sort of relating to privacy, right? One of the big problems is none of the current ideas on how do we actually fix this, and I call this generally a sucking chest wound in our ecosystem that we're trying to put like scotch tape over.

How do we fix this problem of fragmentation in the ecosystem? None of the current proposed solutions sort of like provide for native privacy. And I think we have to be very realistic here that if we want to get the real world on board with these systems, we must provide a way where we can have proposable privacy guarantees, where you can, for example, implement things like private bridging. Because sort of otherwise, you're fundamentally always going to be limited to not being able to like, that you always have to unshield when you want to go from system A to system B. And this is never going to work at scale.

Yeah, so outside of IBC, really there haven't been many sort of like well-thought-out end-to-end design protocols. There have been some few derivative solutions. I mean, Polkadot tried some things. But again, no architecture was sort of proposed and actually deployed. So, with this, let's come to controllers.

So, controllers are all about thinking about how state moves around the multi-chain ecosystem and sort of who's in charge of ordering certain actions that can update state. Yeah, the controller architecture just fundamentally introduces new primitives to manage shared state integrity across sovereign domains. And again, like all the roll-ups, they're sovereign domains, really, when you think of them from an ordering perspective. Yeah, just sort of a very brief comparison. With IBC or the current message-passing paradigms, we really live in this like asynchronous message-passing paradigm with controllers.

You're thinking much more about state. You're thinking like, does the state layout work? And like, how do you come to agreement over shared state integrity? Yeah, you think of transferable resources. You have arbitrary state and logic.

And really, when you think of the provenance, it is not a linear path trace anymore, but rather a directed async-like graph. And it supports privacy. Okay, coming to the core concepts and guarantees that controllers actually provide you. So, the anatomy of the system. And it all starts with a resource.

You can think of a resource as a generalized transferable object that bundles data with programmable validation rules. It is somewhere in the middle of like a UTXO and an account model. This is, it comes very much from the reasoning of like, you want to have native privacy. And very quickly, your models start looking like UTXO models because this makes it much easier from a sort of practical perspective. Beyond the resources or the resource logics, you have the controllers.

And controllers really are, traditionally you'd call them blockchains or sequencers, right, like the Optimism sequencer, that's one controller. The Ethereum main chain, that's one controller. And the controllers are the authoritative state machines that order transactions for a specific resource, preventing double spending. And then you have resource labels, i.e.

, how do these resources move through many different controllers? Now, you can think of this sort of like as a passport with many different stamps for how each resource has moved through the ecosystem. And as a result, you get this like provenance record or controller DAG. And so the last thing, which is sadly cut off from these slides here, is that it has a current terminal controller. You can, for example, think of ETH.

Like, when you move ETH from Ethereum main chain to Arbitrum, you're currently delegating a resource to now currently the terminal controller is actually an Arbitrum. Or like, the Arbitrum sequencer is now the terminal controller here. So, what is a core grantee? Well, you get consistent controller labels. And what this really comes down to, it is too expensive to enforce perfect history.

So, CGL guarantees sort of like, try to do the next best thing. As in, they try to say that, or they say that, if a resource's history is inconsistent, there must somewhere be a Byzantine controller that is responsible and clearly identifiable. Thus, you make trust very explicit and actually very easily checkable. Okay, now as the next thing, we come to the affordances here. Like, what affordances does this controller system bring you for defragmenting the world computer?

Or actually making the, my co-founder Chris gave an interesting talk on making the world computer a reality, so that rather than it feeling like an incredibly messy ecosystem, that's just like one interface you interact with, and this could be then running on many different systems under the hood. Yes. So, the affordances are, you get to move arbitrary state, and this really extends beyond simple token transfers. In all the discussions, really, at the moment, we are thinking, how do we make simple token transfers work? And I think this is probably okay for maybe the current state of things, but this is certainly not okay if you think like, oh, I'd like to create a CDP with Maker, and then I'd like to move now my CDP to a specific other system where I would like to use the CDP as collateral, but I want to maintain the same sort of liquidation rules.

This becomes, and the simplistic answer to this is, well, just unwind your CDP on system A and just recreate it on system B where you want to use it as collateral. This will never work at scale, because you have to keep unwinding all your positions to essentially break down into the raw asset types. And for example, when you think not of this as a CDP, but rather as a loan agreement for a real-world mortgage, you're not going to sell your house every time you want to move to a different system. You're not going to go, oh, shit, I want to move my mortgage from Ethereum mainchain to Arbitrum. Let me just quickly, in the middle, sell my house, get the cash, move the house to the other system, and rebuy it all in an atomic system, in an atomic transaction.

So, the basic mechanism is that with research logics, you can move stateful applications, such as CDPs, because you can encapsulate these very complex, stateful applications within a single resource. And when a resource moves to a new domain, its logic travels with it, and then the new controller becomes responsible for enforcing this specific logic. This also prevents the problem that you need to start redeploying all the applications on all these systems at the moment. You can rather have, you deploy your application, for example, on Ethereum mainchain, and then when you want to take your resource logic to another system, it's not limited to whether someone has deployed Maker to Arbitrum. It's a single, unified application, really, that exists across the world computer, rather than many different deployments of the same application that are fundamentally not in practice.

Yeah, the example that I always like to think of it is a portable CDP, where you can move it from Ethereum to some other system without having to unwind it and rebuild it on the other side. You also get problem in simplification. How does this work? Essentially, it solves the problem of some resources, maybe long list, may move across the multi-chain ecosystem or the multi-chain universe for, I don't know, 500 times. You need some way to condense the history graph.

And this is what the problem in simplification mechanism actually allows you to do, so that you don't actually have to carry around the never-ending history of it. And at a very high level, controllers can essentially endorse sub-segments, and then you get a reduced proof, and then you just attach the reduced proof rather than the entire history. Yeah, this is what fundamentally enables, it generalizes the IBC problem of simple unwrapping to arbitrary states and arbitrary network topologies. This is, by the way, also just way more inherently scalable because one of the big problems with a lot of these interop systems is that you always have the same routing hub. Like, you always would have to go via the same system, and these sort of main routing hubs then become choke points.

This doesn't have this problem. And lastly, you get shielded bridges. You get extra privacy for first-class citizens, which, again, I think if we want the real world outside of this room to actually start adopting the technology that we're building here, we can't say, well, all your neighbors know exactly when you went to the doctor and what kind of medication you buy at the pharmacy. This is just not going to work in practice. This also makes the system very simple because, essentially, the mechanism for this is resource logics can either be authorized by simple signatures or they can be authorized by ZKPs.

So instead of requiring the entire public data for validation, you just have the ZKP. And honestly, actually, in the ZK world, this is much easier to do because the controllers just have to verify the ZKP. They don't have to verify anything else. Yeah, and as a result, you actually get true end-to-end cross-domain privacy where you don't have split-shielded sets. Yes, so controllers, really, it's an all-encompassing solution to solving Ethereum's fragmentation problem.

And I don't know how many of you were at L2 Interop Day yesterday, but, I mean, we spoke a lot about these things. The problem is they are scotch tape on a second chest wound. And I think that we've got to be very practical about this is not going to be fixed by applying small band-aids. This actually requires us to think about how we actually do this in practice at scale. So yeah, controllers give you all of this.

Yeah, and as a result, you get a unified fabric for the L2 or the Interchain ecosystem to do this with. Oh, I'm at 40 seconds. Fundamentally, it eliminates asset fragmentation. So rather than having a single canonical ETH, so you just end up with a single canonical ETH resource. And when you move it to a new controller, you just update the terminal controller label on that specific resource.

You're also trust-minimized bridging security because the entire system just relies on lifetime proofs and not on the incredibly shitty multi-fixed bridges at the moment, and you get composable privacy. Yeah, it's sort of a foundational paradigm shift here where we get generalized interoperability for arbitrary state and applications. It manages historic complexity quite well, and it ensures native privacy through ZKP first design. Yeah, if you're interested in this, I'll link the paper in a second. But really, this is all about enabling sort of the vision of an Internet of Sovereign Domains where many systems may interact with each other.

Some spin up, some spin down. But sort of fundamentally, this is supposed to, and we should aim to have this feel like a unified ecosystem. So thank you very much. Thank you. Thank you.