DAPPCON 2025: Defragmenting the World Computer - Adrian Brink

Transcript

All right, great. Thank you very much for coming. Um, yes, so today I'll quickly go through defragmenting Ethereum or defragmenting the uh the world computer. Um, how we get to better better crosschain 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 across this multi-chain world that we're clearly seeing at the moment.

Um and this is a lot of this technical work is motivated actually by the fact that I think I cannot explain the current e the current state of the ecosystem to anyone in the real world. Um, 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 um none of them have privacy and so on, right? Like so how do we actually fix this and how do we get crosschain integrity with controllers?

Um so the next generation of inter interoperability really requires a paradigm shift from asynchronous message passing um 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 asynchronous message passing action or even like when you move from um Ethereum main chain to optimism this is an asynchronous action. Um the controller architecture fundamentally provides a framework to solve the core problems of provenence, privacy and composability uh that limit current protocols whether this is IBC or sort of our um patchy

framework of Ethereum interop um okay so starting with a fundamental um trma 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 available or we are petition tolerant. Um and you can generally only pick two. Um so what did sort of what does the multi-chain ecosystem actually pick at the moment? Well, we pick um availability and precision tolerance. So there's it does not mean that there's current that currently have guarantees for global consistency. Um and when you don't have guarantees for global consistency, the core challenge becomes how do you manage

this uh shared state integrity? um where like forks happen all the time or inconsistency can arise naturally, right? Like we never really built an interoperability or the interoperability solutions around this idea that like many of these systems may spin up at any given moment, may disappear at any given moment, may become unavailable at any given moment. Um so we really like with this actual fundamental design constraint in mind we have to come up with like what is the correct uh or like what is the best way to actually make the to def fragment the um sort of multi-chain ecosystem and actually just a curious show of hands who here still remembers that you like would run def

fragment on Windows hard drives um so yeah this is pretty much the same idea sort of conceptually speaking uh you want to make the system faster and like more nicely to use or nicer to use um by actually from time to time um making sure that state lives in the right places. Um but let's stay start with a past critique um and I'll focus here on IBC mostly because IBC is actually like by far the most battle tested and well scoped and well sort of like designed system that was trying to solve or that is trying to solve interoperability in this multi-chain ecosystem. Um and and maybe just quickly when I say chain I really mean um 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 sort of like ordering domains. Um so when I say chain you can interpret chain as to mean an L2 or an L1. Um maybe this will be next year's talk of how we should stop calling these systems L1's and L2s and how we should stop confusing everyone with these like very nonsensical terms that sort of from a fundamental technical perspective mean very little. Um but yeah let's start with IBC and sort of like what worked, what didn't work. Um so IBC made some tactical mistakes. I mean it was a very complex problem or it

was very it's a very complex protocol. um that was honestly overengineered and in its defense I can only really say that IBC was ahead of its time i.e. It was designed when the multi-chain it was designed in when 2017 2018 when we really didn't see sort of the multi-chain problem at scale like we didn't have optimism arbitum and all these like 20 different rollups that actually need to talk to each other. This was much more of a conceptual idea like we are going to move to this world and we should think about how interoperability will actually work in practice. Um as a result you also ended up with a bunch of primitives um that honestly in retrospect were like provided suboptimal trade-offs. Um so now sort of 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. Um yeah, some of the strategic mistakes were that IBC never really addressed the problem of path dependent tokens, right? And sort of like when you think about it, um this is actually something I think that a lot of people don't fundamentally sort of internally understand. It's when you send an asset from Ethereum to optimism to arbitum um or it matters like the path matters. So like you go from Ethereum to optimism to arbitrum to ZK sync. Um and now you have some ETH there. Um this is not the same as the ETH that you send from Ethereum to

arbitrum to optimism to ZK sync. Like these two systems are fundamentally like the two assets are fundamentally different. Um and there's sort of like you have to think about how you provide um a way to do automatic path unwinding for not just asset transfers but more complex state transfers. Um and I think we had a lot of talks today about sort of relating to privacy, right? Um 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 uh that we're trying to put like scotch tape over. How do we fix this problem of fragmentation in the ecosystem? Uh none of the current proposed solutions sort of like provide

for native privacy. Um, 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. Um, because sort of otherwise you are fundamentally always going to be limited to not being able 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. Um, yeah. So outside of IBC really there haven't been many sort of like wellthoughtout end to-end design protocols. There have been some few derivative solutions. I mean polka dot tried some things. Um but again no overarch architecture was um

sort of proposed and actually deployed. Um 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. Um yeah, the control architecture just fundamentally introduces new primitives to manage shared state integrity across sovereign domains. And like again like all the rollups have sovereign domains really when you think of them from an ordering perspective.

Um yeah just sort of a very brief comparison. Um 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 a state layout work and like how do you come to agreement over shared state integrity? Um yeah you think of transferable resources. you have arbitrary state and logic and really when you think of the provenence it is not a linear path trace anymore but rather a directed asyclic graph um and it supports privacy.

Um okay coming to the core concepts and guarantees that controllers actually provide you. Um so the 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. Um it is somewhere in the middle of like a UTXO and an account model. Um this is sort of 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. Um beyond the resources or the resource logics you have the controllers and

controllers really are um traditionally you'd call them blockchains or sequences right like the optimism sequencer that's one controller uh the Ethereum main chain that's one controller um and the controllers are the authoritative state machines that order transactions for a specific resource preventing double spending um 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 um through sort of through the ecosystem and as a result you get this like provenence record or controller DA. Um and so the last thing which is sadly cut off from these slides

here is that it has a terminal a current terminal controller. Um you can for example think of ETH like when you move ETH from Ethereum main chain um to arbitum uh you're currently delegating a resource to now currently the terminal controller is actually on arbitum or like the arbitum sequence is now the terminal control out here. Um so what is a coarantry? Well you get consistent controller labels and 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 is 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. U thus you make trust very explicit and actually very easily checkable. Um okay now as the next thing we come to the affordances here like what affordances does this controller system bring you for def fragmenting um the world computer um or actually making the my co-founder Chris gave an interesting talk on um making the world computer a reality so that rather than it feeling like an incredibly messy ecosystem there's just like one interface you interact with and this could be then running on many different systems under the hood. Um n this is what yes um 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 um 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 um with maker and then I'd like to move now my CDP to a specific um other system um where I would like to use the C as collateral but I want to maintain the same sort of uh liquidation rules. This becomes and you know sort of the simple answer the simplistic answer to this is well just unwind your CDP on sort of 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 into the raw asset types. And for example, when you think not of this as a CDP, but rather as a loan agreement for like a real world mortgage, you're not going to sell your house every time you want to move like to a different system, right? Like you're not going to go, "Oh I want to move my mortgage from Ethereum main chain arbitum. Let me just quickly in the middle sell my house, get the cash, move the house to the other system and reby it all in an atomic system, right?

An atomic transaction." Um so the basic mechanism is that with research logics um you can move stateful applications um such as CDPs because you can encapsulate these like very complex stateful applications within a single resource um and when a resource moves to a new domain it logics it logic its logic travels with it um and then the new controller becomes responsible for enforcing this specific logic. Um this also prevents the problem that like you need to start redeploying all your applications on all these systems at the moment. you can rather have like you deploy your application for example on Ethereum main chain and then when you

want to take your resource logic to another system it's not limited to whether like someone has deployed maker to arbitum um like 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 interactive um yeah the example that I always like to think of it is a a portable CDB um where you can move it from Ethereum to some other system uh without having to unwind it and rebuild it on the other side.

Uh you also get provenence simplification and how does this work? Um essentially it solves the problem of some resources maybe long lived and may move across the multi-chain ecosystem or the multi-chain universe for I don't know 500 times. Um you need some way to condense the history graph. Um and this is what the provenence simplification mechanism actually allows you to do so that you don't actually have to carry around sort of the never- ending history of it. Um and sort of at a very high level it controllers can essentially endorse subsegments. Um and then you get a reduced proof and then you just attach the reduced proof rather than the entire history. Um yeah this is what

fundamentally enables uh it generalizes the IBC problem of simple unwrapping to arbitrary state and arbitrary network topologies. Um, 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. Um, this this doesn't have this problem. And lastly you get shielded bridging. um you get actually privacy as a first class car citizen which again I think if we want sort of the real world outside of this room to actually start adopting the technology that we're building here

um we can't say well all your neighbors know exactly when you went to the doctor and like what kind of medication you buy at the pharmacy. This is just not going to work in practice. Um 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. Um so instead of requiring the entire public data for validation you just have the ZKP. Um and honestly actually this 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. Um yeah and as a result you actually get true end to end uh cross domain privacy where you don't have uh split shielded sets. Um yes so um controllers really it's an all-encompassing solution to solving Ethereum's fragmentation problem. Um and I don't know if how many of you were at L2 interop day uh yesterday. Um but I mean we spoke a lot about these things.

The problem is like like they are scotch tape on a sucking chest wound. And I think like we've got to be sort of 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. Um so yeah controllers give uh you all of this. Um yeah and as a result you get a unified fabric for the L2 or the interchain ecosystem um to do this with. Oh, I'm at 40 seconds. Um, fundamentally it eliminates asset fragmentation. So rather than having a single canonical E, so you just end up with a single canonical E3 resource. Um, and when you move it to a new controller, you just

update the terminal controller label on that specific resource. You got also trust minimized bridging security um because the entire system just relies on light client proofs and not on s the incredibly shitty uh multisc bridges at the moment. and you get composable privacy. Um yeah, it's a fun it's sort of a foundational paradigm shift here where we get generalized interoperability for arbitrary state in applications. It manages historic complexity quite well. Um and it ensures native privacy through ZKP first design. Um yeah, if you're interested in this um I'll link the paper in a second. Um 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 like we should aim to have this feel like a unified ecosystem. Um, so thank you very much. [Applause]