Introduction

This is the second in the series of “0x Roadmap” posts covering the projects we are working in 2019. You can read the first post on the ZEIP process here.

Since this is my first post in the 0x blogroll, let me quickly introduce myself: My name is Remco, but I sometimes go by recmo as a handle. My interests cover peer-to-peer protocols, cryptography, compilers, formal verification, and much more. The decentralized web is my natural habitat. I was security auditor for the very first version of the 0x contracts in 2017 and joined full time a little over a year later. I see my role at 0x as “make sure 0x runs on the best technology.” Besides developing the 0x protocol itself, this includes contributing back to the technology stack we build on. In this spirit, I write EIPs and help improve various parts of the core Ethereum tooling. You can usually find me at meetups like Ethereum Magicians where these conversations take place.



Over the past year or so, I’ve been following the developments around DApp scaling and thinking about general strategy for 0x. We started actively developing this strategy after Devcon 4 and now is a good time to present some of our high-level ideas. A lot of this material was also covered in my closing keynote at EthCC Paris where I go deeper into the details of the technology.

Scaling Blockchains

Blockchain technology is in many ways still in its infancy, and this is particularly noticeable when it comes to scaling. It only takes a moderately popular project to fill up Ethereum’s blocks and send transaction fees skyrocketing. Users end up spending a lot on fees or waiting in long queues.



This is not just a bad experience for users, it also scares off some of the really interesting applications: For example, a year ago Maersk and IBM launched their supply chain chain as a private blockchain. Even if they wanted to, the Ethereum blockchain would not be able to handle their transaction volume. They were forced to opt for a private “blockchain.” Many other interesting use cases also require scaling: prediction markets, gaming, payment networks, etc. Ideally, these projects should be able to choose an open platform. For this to happen, public blockchains will need to prove they can scale.



So we need to solve the scaling issues. This is nothing new. However, solving scaling is very challenging when you also want security, openness, trustlessness, and decentralization. (If you see a project that claims to have solved scaling, it will likely have serious shortcomings on at least one of these fronts.)



Fortunately, the community has some of the brightest minds working on this problem and great progress is being made. Over the past years, a general double strategy towards scaling has developed called layer one and layer two.

Layer one and layer two

Layer one is making the blockchain handle more work. Right now every node verifies every transaction, which means the network can only process as many transactions as its slowest node. We could require participants to have really fast computers, but then the network would no longer be open. We could make everything more efficient, but that only gets you so far. Instead, the strategy here is to stop requiring every node to verify all the transactions and instead divide the work up among the nodes. This sounds easy, but dividing work in a trustless, decentralized way is challenging.



Layer two is making the blockchain handle less work. Not every transaction needs to go to the blockchain. With some clever thinking, we can settle transactions off-chain. Payment channels are a nice example of this: I can keep a line of credit open with you where we do our payments, and only when we are done or something goes wrong do we escalate to layer one.



In short, layer two is where the transactions will happen most of the time, and layer one is always there to guarantee that everything is done correctly. Layer one doesn’t get involved unless it has to. In many ways it acts as a court to resolve conflicts in layer two.

Layer two trade offs

There are many trade-offs in layer two solutions having to do with where data is stored and how the blockchain is informed of the goings-ons of layer two. I’ll leave the details for later, but want to give you two guiding principles I have been following:



Principle 1: Cryptographic guarantees. It should be impossible to break the guarantees of the system, not merely expensive.



Principle 2: Exponential scaling. Any layer two scaling solution should allow for exponentially more transactions than layer one.

Scaling Decentralized Exchanges

Right now scaling may not seem a big concern in DEXs. While DEXs constitute a significant fraction of all Ethereum transactions, there is still plenty of room for it to grow. My expectation is that usage can go up by about 5x before it becomes problematic.

Remember that it is still very early days for DEXs. We are looking at a 100x increase before centralized crypto exchanges are replaced. With tokenized securities it will be another two orders of magnitude to support the loads of traditional security exchanges. Add another two for mainstream consumer adoption.

Long term, I expect the majority of the trading volume to come from tokenized assets that currently don’t have a marketplace, like prediction markets or game items. In a tokenized world, we want all of these to have decentralized market places. This means that the average person will likely be making frequent automated trades as they convert between various tokens to play games, predict or do micropayments. In this future, DEXs need to handle loads massively higher than currently experienced even in payment networks.



Clearly, we need a plan. And it better be good. And it probably involves magical alien math.

Zero Knowledge Proofs

Luckily, magical alien math just landed. It goes by the name “zero knowledge proofs” or ZKPs for short. A zero knowledge proof allows someone to do a computation on some data and prove that they did this computation correctly, without revealing the data. For example, an account can prove that it summed up all of its expenses correctly without showing what those expenses were.

It is a technology that has been known for about two decades, but as often happens with cryptographic inventions the initial versions where impractically hard to use. In the last couple of years, and thanks to the hard work by Ben-Sasson and many others, ZKP technology has become practical in the form of zkSNARKS.

ZCash is an early adopter of zkSNARKS technology and uses it to achieve privacy. It does this by not telling you the balances while transactions on the ledger are computed. ZKP technology is still in its teenage years, as the recent vulnerability in ZCash showed. For privacy focused projects, this is particularly sensitive as by their nature it is impossible to verify if the vulnerability was exploited or not. (In my opinion, scaling is a better first application for ZKPs. If something goes wrong you will see this immediately and can take corrective action.)

Meanwhile, Ben-Sasson and others have developed a new ZKP technology called zkSTARKs. They continue researching and developing this technology as a world-class team called Starkware. Compared to earlier ZKPs, it has better security and it’s easier to produce proofs. It is also refreshingly simple, like great inventions tend to be.

At Devcon 4, we met with the Starkware team and discussed how we could use this technology to solve the DEX scaling problem. We’ve had many fascinating conversations since. The basic idea is as follows.

ZKPs for scaling

Settling 0x transactions is a computation: Verify the maker and taker signature, check that they hold sufficient balance, subtract the amounts and add them to the others balance. We do this for each settlement transaction.

Instead of doing this in a smart contract, we can do it somewhere else and send a proof that it was done correctly. This is entirely secure because the ZKP guarantees that the computation is done correctly. It is also a lot more efficient because now the smart contract only has to verify one proof instead of many transactions. In fact, we never have to send the transactions themselves to the contract, which makes it scale exponentially.

But we still need to update the traders’ balances, and this is where things get complicated. If we keep the balances on Ethereum, we would still need to update them for each transaction. This would not scale exponentially. The only way to scale big is to keep user balances off-chain and update them there. (Users can move their funds between on-chain and off-chain using deposit and withdrawal transactions. A detailed write-up of this process will follow.)

In this system, layer one will only be required for verifying proofs and all the trades will take place in layer two. This means that layer one will not provide any limits to scaling, while still guaranteeing the security of the protocol.

Research done between 0x and Starkware shows that STARKs proofs can be verified on Ethereum today without requiring any changes to the protocol. We are currently working on a proof-of-concept implementation to demonstrate the performance on testnet. Stay tuned!

Evolving the 0x stack

ZKPs are a powerful new tool that are well-suited for the DEX use case, but how do they fit into the 0x roadmap? Isn’t this a completely different technology?



Right now we have the Standard Relayer API to connect liquidity together between different relayers, market makers, and 0x Instant. This works, but is kind of an old-world way of doing things. Each endpoint must be correctly implemented and each connection must be setup manually. We are working on a peer-to-peer network transport layer that automates all of these connections, greatly increasing order flow throughout the ecosystem. As an added bonus, we are making the whole thing work in the browser so you can participate in the decentralized liquidity network without having to install a node! We’ll be sharing more info on this p2p layer soon.



With networked liquidity improved, the next step is to coordinate trades. Trade execution coordinators (TECs) are little services relayers can opt into. These coordinators provide a variety of benefits including protection against front-running, innovative marketplace mechanics, and soft cancels. They can do this while still allowing unrestrained liquidity sharing.



When trades are ready to be settled, they get collected in large batches and processed. The final result of all this is a small proof that shows all of it was done correctly. This proof is submitted to the on-chain contract for verification.

If you think about it, this looks a lot like a blockchain. There is a peer-to-peer network distributing orders (mempool), a mechanism for finalizing transactions (mining) and turning them into batches (blocks). Ultimately, it is still all connected to an Ethereum contract. We can call this the 0x sidechain.

Looking even further ahead

0x protocol is currently designed to serve as a building block that Ethereum dapp developers can use and extend however they see fit, and we currently assume that all Ethereum assets and decentralized applications exist within a single global state. When layer one scaling divides assets and dapps across different shards, users will want to either (1) execute synchronous trades directly on their local shard for some shard-specific use case or (2) move their assets into a highly scalable sidechain that allows for synchronous trades between assets that are native to different shards/chains.



Instead of straying away from the current design, we hope to replicate the 0x pipeline on different shards and stateful blockchains, and use cross-chain governance to push out synchronized updates. Each replica of the 0x pipeline, or “embassy,” will support local shard-specific trading activity and, due to the system’s extensibility, it should be able to support most use cases.



The highly scalable ZKP-based sidechain will plug into each of these embassies, allowing users to seamlessly transition from synchronously trading their assets locally with other people on the same shard to synchronously trading on a global network that connects markets together.

Help us make ZKPs accessible on Ethereum!

The 0x Core Team is committed to bringing ZKPs into the mainstream by improving Ethereum tooling and shipping developer-centric open source tools. We are currently working on several EIPs and proposals that make the Ethereum blockchain’s support for layer two scaling solutions even better. If you are an Ethereum developer that is interested in making ZKPs easier to use, please take a look at the following proposals!