How Arbitrum Channels Work

This post is about an early version of Arbitrum Channels. If you’re interested in how Arbitrum Rollup works, see our developer docs.

In previous posts, I wrote about our Arbitrum system, and why you should try it out if you’re a blockchain app developer who is interested in scalability, low cost, security and privacy controls, and interoperability with Ethereum. But how does Arbitrum work?

The tl;dr: The Arbitrum compiler takes your Solidity contracts and compiles them to run on Arbitrum. The EthBridge connects Arbitrum-land with Ethereum-land, letting you communicate and pass ether and tokens back and forth. Your Arbitrum code is run by validators, whom you choose. Your contract will run correctly if even one of your chosen validators is honest — that’s the AnyTrust guarantee. All of this can happen quickly and mostly off-chain, thanks to the details of Arbitrum’s design.

If you’re interested in the nuts and bolts of Arbitrum, you can read the code and try out our developer preview; or you can read the Arbitrum white paper. If you like, you can read the academic paper that Arbitrum is based on, although that’s a snapshot from May 2018, so it’s missing some important features of today’s Arbitrum. Or … keep reading for a summary that’s as short as I can make it.

The details:

I’ll explain Arbitrum’s design in terms of its three main components: the compiler, the EthBridge, and validators. These components work together to make Arbitrum fast and interoperable, and to preserve the AnyTrust Guarantee that an Arbitrum virtual machine will execute correctly as long as at least one of its validators is acting honestly.

The Arbitrum compiler takes a group of contracts written in Solidity, and compiles and links them together into a single executable file that can run on the Arbitrum Virtual Machine (AVM) architecture. (Why did we design our own VM architecture? Because it lets us reduce the on-chain footprint of a VM, which makes things go faster. See below for details.)

Because many dapps are written as a group of contracts rather than a single contract, the Arbitrum compiler can take all of the contracts in your dapp and compile them together into a single deployable unit. To avoid confusion between a compiled Arbitrum program and the multiple contracts that make it up, we call a compiled dapp a Virtual Machine (or VM) when it’s running.

The EthBridge is a dapp running on Ethereum, written by Offchain Labs. As the name implies, its job is to serve as a bridge between Ethereum-land and Arbitrum-land. Anyone in Ethereum-land can call the EthBridge to interact with Arbitrum-land, for example to launch an Arbitrum VM, to make a call to a contract running on Arbitrum, or to send ether or any token to an Arbitrum VM. If an Arbitrum VM sends ether or tokens to you, the EthBridge will pass them on to you. And the EthBridge knows the status of everything in Arbitrum so you can make non-mutating calls to it (costing zero gas) to follow what’s happening in Arbitrum-land (except for the internals of private VMs).

The EthBridge’s other important job is to referee disputes between validators. As described below, the Arbitrum protocol and AVM architecture make dispute resolution very fast and cheap, as well as imposing strong disincentives against entering disputes in the first place. But if a dispute does occur, the EthBridge will referee it to preserve the AnyTrust security guarantee.

Validators are the workhorses of Arbitrum — and they do that work almost entirely off-chain. Every running VM has its own validators who are chosen by the dapp creator. Those validators keep track of the state of the VM and advance the VM’s state by emulating the instructions in the VM’s code. Arbitrum ensures the AnyTrust Guarantee: as long as any one of a VM’s validators is online and behaving honestly, that VM will execute correctly.

A VM’s validators know everything about the current state of that VM. The EthBridge just keeps track of the cryptographic hash of each VM’s state. You can think of that hash as a commitment by the VM’s validators to the complete state of the VM.

The common case: fast path

Most of the time, a VM’s validators will agree on what the VM does. Each validator will emulate some steps of execution by the VM, and then the validators will compute the cryptographic hash of the resulting state. If the validators are all behaving correctly, they will agree on the new state hash. They will then make a joint digital signature recording the VM’s evolution from the old state hash to the new state hash. That’s called a unanimous assertion. The EthBridge will accept any unanimous assertion as correct. (That’s consistent with the AnyTrust Guarantee, because assuming that at least one validator is honest, anything that was endorsed by all validators must have been endorsed by an honest validator.)

Usually a VM’s validators will be able to string together a whole sequence of unanimous assertions, without needing to bother the EthBridge or put anything on the main chain. A unanimous assertion is like a voucher that can always be taken to the main chain (via the EthBridge); or you can hang onto a voucher until you get a newer, more up-to-date voucher recording a more recent state of the VM. Honest validators will handle this for you, so you have a guarantee of finality in unanimously asserted transactions, even before they’re submitted to the EthBridge to be put on the main chain. This mode of execution can give finality very quickly — it requires only agreement and a digital signature from your VM’s chosen validators — while still supporting the AnyTrust Guarantee of correctness.

If a validator isn’t available

Occasionally a validator might be unavailable or offline. In this case, unanimous agreement can’t be reached. To make progress, any validator can make a disputable assertion: an on-chain claim, submitted via the EthBridge, that asserts what the correct next state hash and actions of the VM are. After this disputable assertion, the VM’s other validators have a time window, whose length is determined by the dapp creator, to dispute the assertion if they believe it incorrect. If the problem is just that one validator is unavailable, the assertion will be honest and correct, and nobody will dispute it. After the dispute window closes, the EthBridge will accept the assertion as correct, allowing the VM to make progress.

As soon as the unavailable validator comes back online, the validators will go back to the normal, unanimous, off-chain operation of the VM.

If a validator is dishonest

The most interesting case arises when a dishonest validator tries to cheat. This is the case where many state channel approaches get into trouble and have to move the full state of the dapp onto the main chain, which can be very expensive and slow. This case is where Arbitrum really shines.

There are two things a dishonest validator might try to do. First, they might try to corrupt the execution of a VM by making a disputable assertion that is false in the hopes that the EthBridge will accept that assertion. Second, they might let somebody else make a truthful disputable assertion and then start a bogus dispute about it.

Arbitrum deters misbehavior by requiring validators to put down a deposit or “stake” that is held by the EthBridge. If a validator gets caught cheating, it will forfeit its stake. (Half of the cheater’s stake goes to the other party in the dispute. The other half is burned, that is, destroyed.) When the VM completes, validators who haven’t been caught cheating will get their stake back.

Arbitrum’s dispute resolution protocol is designed to resolve disputes very efficiently, by identifying a cheating party while requiring a minimum of on-chain activity. The dispute plays out as a contest between an asserter (who claims their disputable assertion is correct) and a challenger (who claims that the same assertion is wrong), with the EthBridge acting as referee.

Dispute resolution

The dispute resolution protocol goes in two stages. First, the players narrow down their disagreement, using an on-chain bisection protocol, until they are disagreeing about a single step of the VM’s computation. Then the asserter sends a one-step proof — a proof of correctness for the execution of a single VM instruction — to the EthBridge which checks that tiny proof.

The bisection protocol starts when the asserter claims that a VM starting with state-hash X can execute N instructions, resulting in state-hash Y, and the challenger responds that this is false. The asserter is required to bisect their assertion into two half-size assertions, each involving the execution of N/2 instructions, which fit together to give the initial assertion. Then the challenger has to pick one those two halves to challenge. If either player fails to act within a time limit, they lose. After one round of bisection, the size of the dispute has been cut in half to N/2 steps.

The process continues with further bisections. After a logarithmic number of bisections (logarithmic in the number of instructions executed, N), the dispute has been narrowed to a single step: the dispute will be over whether or not a VM starting with state-hash Y can execute a single instruction to get to the state-hash Z.

At this point the asserter has to give a one-step proof to the EthBridge, containing the information that the EthBridge needs to quickly verify that the one-step assertion is correct. Or perhaps the asserter will fail to provide a valid one-step proof. Either way, the dispute is resolved.

We won’t go into the details of one-step proofs here — we’re pretty deep in the weeds already. Suffice it to say that Arbitrum’s custom VM architecture comes into play here, making the one-step proof small (a few hundred bytes at most) and cheap to check (costing about 90,000 Ethereum gas, or about $0.04 at current prices).

The bottom line

By making disputes relatively cheap to resolve, and imposing a substantial penalty on the loser, Arbitrum strongly disincentivizes attempts to cheat, but even if a dispute occurs this doesn’t impose a huge on-chain impact. In the common case, validators will agree and progress will occur off-chain, with only occasional touches to the main chain. By moving almost everything off-chain, and making even the worst case relatively fast, Arbitrum makes smart contracts much more scalable.