Coordination-Avoidance: Rethinking Decentralized Networks Beyond Global Consensus

Okay, yeah, that's about it, Thomas, take it away. Hello everyone, I'm Gyoti Gyoza, thanks for the warm introduction. Today, I want to talk about coordination avoidance, rethinking decentralized network beyond consensus. Now, I think from first glance, coordination avoidance may sound very strange because this industry is founded on top of algorithms that encourage coordination, not avoiding it. But there's a technical meaning to that that we'll get to.

Before that, let's talk about global consensus. So Ethereum gave us global finality in a trust-minimized flavor. It is a truly unique system, one of a kind. But we all know that Ethereum operates on global consensus, which is the finality algorithm is the modified two-phase commit protocol, where the supermajority among all the validators have to agree on a certain block for it to be finalized. And the consequence of running a consensus mechanism globally leads to, number one, latency issues.

So latency is heavily dominated by consensus, which means that the system is not highly responsive. Also, the cost of transaction is dominated by having to run global consensus. These fees of transactions make layer one really unsuitable for very frequent interactions, which actually is outside of the scope of its design. So that's all well and good. But as a result, we have a world computer that's not really suitable for interactive, content-rich kinds of applications.

So we're asking the question, is it possible to make decentralized applications that are actually responsive and free of cost to use? Enter local-first software. Local-first software is kind of software that functions on the local device seamlessly. And it uses the global network only when it needs to synchronize with other replicas or users, or it needs to perform a remote backup. For example, how does it do that?

Local-first software places a copy of the application state on the client side so that the client side are essentially only interacting with the local copy or replica of the state. Behind the scene, these copies on a network synchronize among each other to maintain consistency. The key advantage of this architecture is, number one, applications become super responsive because locally you can read your write and observe its effect immediately. It also gives you offline capability. Just like the Git protocol, you can edit your local clone of a repository at any time.

You can synchronize with the remote repository when you want to or when the internet is available. But how is concurrency handled? If everyone is editing their local copy of the same application at the same time, how do you handle consistency and collisions and so on? When we talk about CRDTs, CRDTs stands for Conflict-Free Replicated Data Types. It's a kind of data type whose instances is replicated across many machines.

And when these copies are synchronized, they would synchronize just fine without any conflict whatsoever. If you have no conflict to deal with, you don't have to resort to ordering systems or voting systems. That means that you can run a distributed application without using consensus mechanism. It's a spatial data structure that I like to call a multiplayer data structure. It allows you to build multiplayer software.

The mathematical guarantees behind CRDTs guarantee that whichever way you merge these copies of the same piece of data, you will always get the same result without having to resort to a central coordinator or resort to voting mechanisms. A famous case study would be HackMD. It's the collaborative note-taking applications that we all love to use. It started off with the operational transform approach, OT, which is the predecessor to CRDT that's more than 20 years old. But the HackMD later adopted YJS, which is a very popular open source CRDT library written in JavaScript, which also was rewritten in different languages, including Rust and Python.

The motivation of HackMD adopting YJS is that it wants to support offline editing capability. It also wants to allow users to manipulate the folder trees concurrently. OT is designed strictly for text editing. It's difficult to generalize to more complex structure for OT. CRDT was designed specifically for that.

As with all engineering approaches, there are limitations. CRDT is not a silver bullet for all possible multiplayer software. We can look at two case studies. TLDraw is a pretty popular multiplayer canvas application where users can draw on the same whiteboard, prototype designs together. They also integrate AI, so you can generate drawings.

TLDraw initially used CRDTs, but they dropped CRDTs because of performance issues. Imagine you are on a collaborative canvas and you want to draw a line from point A to point B. The typical user experience is that you will click on the canvas, which fixates the point, then you drag the other point, deciding where you want to place the second point, and you have a line that is connecting the two points at any given moment. When you generalize this to a multiplayer scenario where everyone is estimating and manipulating their geometries in real time, you get some pretty serious performance trouble with CRDT because operations or states are frequently transmitted across the network. You require very high bandwidth for correct operations.

For TLDraw, an application that requires very responsive experience, they had to handcraft their own synchronization mechanism for themselves. Second case study would be the Penguin World prototype built by Topology. Penguin World is a game prototype that looks like Super Mario, but only multiplayer. It's a side-scrolling sandbox where each player is a penguin that can jump around and collide. The game was prototyped using Yjs, so the entire game state is structured as a Yjs document.

The thesis behind the prototype was that, well, it seems to be a dimension jump from a collaborative document to a game, because what makes a difference between multiple people editing the same document and multiple people participating in the same game state? We thought it's a dimensional jump, so Topology proceeded with prototyping it. Synchronization works out of the box. You can make a simple baseline multiplayer experience right out of the box with the Yjs library, which wasn't built for game scenarios at all. But the tricky thing is, with side-scrolling games, one of the basic physics you would expect would be collision.

You want interesting things to happen when things collide, whether that's bullets or NPCs. Collision turned out to be very tricky on a peer-to-peer situation, because without an authoritative server, who is to say which collides with whom first? Tricky thing was bullets, for example. Did I headshot you first, or did you dodge the bullet first? If it works on top of a PDP network, there are various different ways for you to, for example, pretend you didn't receive a packet, or pretend you received a packet later, then you dodge the bullet-carrying packet.

How we prototyped the Penguin world was that we implemented a collaborative collision mechanism, where whenever anyone collides with anyone else, a message passing happens. That says, A collided with B, both A and B should back up by this much and change their velocity by this much, which obviously welcomes cheating behavior. So if collision is this tricky, let alone more interesting game physics, this turns out to be a very challenging proposal for video games. So we can move up the stack, because if you follow the local first software movement, nowadays CRDT as an algorithm is not so much heavily discussed anymore as before, as let's say 15 years ago. Nowadays, the trendy topic would be Sync Engine.

The Sync Engine sort of recognizes the fact that when you build an application with multiple people interacting with it, all you really want is for the synchronization to happen magically. So Sync Engine is the middleware that handles synchronization for your application. It takes care of network transport, and it takes care of any possible conflict resolution. So your software on top of a Sync Engine becomes a multiplayer version of it. A good Sync Engine should satisfy, should have a few properties.

One, it should be fast, obviously, even with very large data volumes. And specifically, there's something about initial load. When you first load up an application, how long does it take to load up the initial state, sort of the time between visiting a website to sort of the first render of the website? If you have to synchronize the entire application replica, it might make the initial load very slow, which would drive away internet users. Nowadays, all of us are pretty impatient online.

And so Sync Engine's solution to this would be partial sync. And there's different algorithms for partial sync. You would sort of synchronize pieces of your application state based on their query patterns or based on client-side sort of request or client-side patterns. So that's partial sync. Number two, it should be very easy to use.

So CRDD has this issue sometimes that you expect programmers to understand concurrent programming to use the CRDD properly. Concurrent programming is not very easy to understand. Sync Engine abstracts all of that so that your software on top of it becomes multiplayer instantly, ideally. Third property should be it should flexibly support many transport options from WebSockets, WebRTC, and so on. And furthermore, it should offer access control out of the box because multiplayer software invariably needs some kind of access control to prevent chaos.

But there's one thing about off-the-shelf Sync Engines. On the bottom right, you can see RepliCache and Electrics. These are the two big-name Sync Engine projects on the market. They rely on centralized servers for synchronization. This is not to blame anyone.

These communities come from very different directions. They are often sort of quite orthogonal to the blockchain community, although all of us are trying to build distributed applications with different guarantees. We want to make decentralized applications. We want to avoid or minimize the presence of centralized servers. So what can we do?

So we can imagine the existence of a decentralized Sync Engine, which, to my knowledge, does not exist at the moment. But we can imagine what should a decentralized engine look like. Well, first of all, it should work on top of a permissionless P2P network. And with all P2P networks, there are sort of basic functions that typically are fulfilled by centralized servers, such as bootstrapping. But we should minimize the presence of centralized servers as a whole.

And second, we would crucially need very good P2P transport layer. This is to say that when multiple users are working on an application on the Sync Engine, their deltas, or their updates, should be propagated on a network as efficient as possible. And also, not just efficiency, but also accounting for topology changes and membership churns, because people go online and offline all the time. So a few approaches to achieving this will be gossip mechanism. The P2P has a gossip protocol.

Broadcast trees, which has a sort of a more efficient way of multicasting information on a structured network. And RLNC is more catering to unstructured network, where you have a network topology that's very unstable, but you still want to make sure a guaranteed delivery as much as So network coding breaks up your payload into pieces and encode it in such a way that any recipient receiving enough amounts of these fragments can reconstruct the original data. That will give you sort of a robustness against topology changes of the network. Potential applications of this will be censorship-resistant social media, SparkCaster being the best example of this. Collaborative applications of different kinds, Fileverse with their DDoC is a great example for this.

In this talk, we want to propose a probably radical idea, but maybe it's time for this. Decentralized governance platform for Ethereum itself. So taking a detour from the technical aspect, sort of look at Ethereum governance from a constitutional perspective. The three power system, legislation, execution, and judicial branch. If we look at the Ethereum spec as the law, then all the full nodes collectively form a judicial function of Ethereum.

Execution function includes different entities and organizations that are working towards turning spec into production code and managing sort of the project management aspect. But what about legislation? Well, obviously, legislation is driven by the EIP process. So this diagram, this phase transition diagram is modified from EIP-1 directly. You have the phase transition diagram where every EIP goes, transitions through these different statuses on different conditions.

The entire process is stewarded by the core devs. Now the issue is that there are certain aspects of this process that somehow lack codification. So number one, the how, the arrows in the diagram can lack codification. The conditions, the triggers, and the entities that determine the transition somewhat lack codification. The who problem, so precisely the authority and the accountability of the special role EIP editor may lack a little bit codification.

Aside from EIP editor, client teams have significant voice in the process, but the way in which these teams are qualified and their voice is weighted or not, it's not exactly codified. And finally, the where problem. Discussions about EIPs are scattered on the Internet, across discourse server, ETH R&D, across the Ethereum Magician Forum, in the PR comments of the EIP repository, and of course, in the synchronous ACD calls. It's not very formally codified how the voices of the communities is incorporated into these discussions. Well, is it time to change?

In fact, the lackings, quote unquote, were actually very crucial because, for example, it provides flexibility for the foundation to steer in the environment where the regulatory situation changes. It also prevents formalized modes of capturing the system because when you have rules that are excessively formalized, you invite kinds of attacks for the rules. So when we look at Ethereum's history, it's now approaching the 10th anniversary. The ecosystem has grown explosively. Every change to the law or the spec can have profound implications to many stakeholders.

So we believe that Ethereum can foster stronger trust by increasing structure and rigor in the legislation process. The entire process may be very difficult to change, but we can start from the technical aspects just to demonstrate the feasibility. Sort of proposing, sort of fantasizing the concept of Ethereum Congress doesn't have to stick to the skeuomorphic language, but just as proof of thought. So Ethereum Congress is a platform that centralizes all the essential discussions with respect to spec upgrades on a decentralized platform. It consists of two locations, the floor where the top-level deliberation happens.

It also consists of hearing rooms allocated for each EIP so that they can be transparently and centrally discussed and edited and reviewed. On the layer one, we can have small contracts that manage the permissions of these locations, option locations. We can also have a special contract called the EIP manager that basically canonically manages the statuses and the transitions of every single EIP. So we've built a prototype using OrbitDB, which we see as an approximation of the decentralized sync engine. EIP manager.

sol is the special small contract on chain that canonically records the status of every EIP whose events are tracked by OrbitDB nodes. And here we have two hierarchies. We have the admin DB nodes that are responsible for tracking the Ethereum events and creating new databases for hearing rooms. And we have all the users that are locally running the OrbitDB nodes with the local first software principle. There are screenshots of the, we can't do live demos here, screenshots of the POC.

Not everything works, but the repository is open source. The floor is the place for top-level meetings and there's hearing room for every EIP where you have a forum-based interface. Just for last, food for thought, a side product that is unlocked by the system is you can then build a prediction market on chain that sources information about EIP from a special small contract and have the prediction market based on, for example, will EIPX reach final status by D-date? And that sort of provides a way to pull community sentiment, which can be factored into the legislative process in some way. And so, we conclude the talk by saying that global consensus is a very precious resource, global finality provider, Ethereum's core strength.

But there is value for building coordination avoiding systems on top of the system. And one valid proposition is using this coordination avoiding system to govern the coordination heavy system. Both are decentralized in nature. And we propose a proof of concept called Ethereum Congress, just to spur discussion. Thank you.

Thank you very much. Thank you very much. We have a few minutes for Q&A. You still have some time if you want to get a question in. Just scan the QR code up there and access Meerkat, log in and vote or upvote some questions.

We do have one question here. You partially answered this one already, but I'll give it to you anyway. What happened to OrbitDB and Radical? Do you use them? Are they part of your stack?

Right. We didn't use Radical, but I think it's a great point. A version control system for code should be in the picture. Ethereum's stack is not written in natural language, it's written in code. And so, there should be a place for such a system.

But we do use OrbitDB. And OrbitDB, to those who may not be very familiar with it, it builds on libhttp and a CRDT layer and a database abstraction. So, it follows the local for software principle nicely, and that's why we use it as an approximation. And then I think we have one last question here. Just a quick one.

And no, we have two more. Okay. Let me give you this one first. Have you tried GunJS? Amazing thing about it.

Personally, haven't tried it. But if I have spare curiosity, that will be the next project I try. Great. Okay. And this should be the last one.

Are you aware of the work being done with ethereum.forum? Actually, I am not.