Optimistic Rollup, from the Bottom Up

The best way to understand something is to build it.

He is optimistic about reaching the other side, and although it would really suck if he didn’t, he has cryptoeconomic guarantees that someone will be waiting for him with an airbag down below.
Photo by Alex Radelich.

This article presents Optimistic Roll-Up (ORU) from the bottom-up through a simple example. We will spec out a simple ORU chain, so we can "touch and feel" what it's all about.

ORU is an important design pattern for layer-2 scaling which lets you have your scalability cake and eat it too -or at least some of it. They are exciting because they, and their close cousin ZK-Rollups, overcome fundamental limitations that have plagued sidechains, plasmas, and state channels for years.

The problem

A high-school is facing a problem: every other day there is a fight between two intimately involved students because one of them caught the other cheating.

A typical scenario would be:

Alice is angry that her Bob was seen kissing some Cathy. Bob would be shouting something like "I SWEAR IT'S NOT TRUE" or "WE WERE ON A BREAK!", but Alice disagrees, throwing a chair at Bob and creating a scene in the hallway, which disrupts the whole school.

Solution v1

Jamal, the de-facto top nerd at the school, proposed a solution to this pesky problem: every night, every student cryptographically signs one of the following messages:

• "Im single"

• "Im dating X exclusively"

• "Im dating multiple people non-exclusively"

Nothing special about these signatures. They are the same type of signatures that facilitate the transfer of cryptocurrency from one address to another.

A table mapping students to their public keys is publicly displayed in the school hallway, so the validity of a student's signature can be confirmed by anyone.

Jamal made it easy for students. On a mobile app he developed, each student just selects one of these three options and clicks a"Sign & Send" button, and that's it. In the background, the signed message is broadcasted to the Ethereum P2P network. Actually, they get sent to Jamal's home server because he is acting as a relayer for the students, that way they don't need to worry about gas or even know what it is. Jamal used some smart contract wizardry (CREATE2 EVM opcode) to allow him to pay gas on behalf of the students. The school reimburses him those gas costs each month.

There are 1000 students, each signing 1 message per day, and each message costs on average $0.1 in gas, which means the school's monthly gas expenditure is:

1000 students x 1 message/day/student x $.1 gas/message x 30 days/month

= $3000 gas/month.

Ouch.

Solution v2

$3k per month is not sustainable for the cash-strapped school.

Optimistic Rollups (ORU) to the rescue. Jamal says with ORU the school could cut gas costs by up to ~99%, here is how:

Jamal appends the signatures of all students into one big string of data.
Let's call this piece of data WiSwWhom as in "Who is Sleeping with Whom":
WiSwWhom = "[alice_id, alice_msg, alice_signature], [bob_id, bob_msg, bob_signature], ... etc".

There are of course more efficient ways of packaging this WiSwWhom data, but let’s ignore that.

Jamal then broadcasts ONE transaction that is signed by HIS private key. The transaction message says:

"I Jamal certify that the data (WiSwWhom) attached to this transaction represents the relationship status of students for dd/mm/yyyy and I pinky swear that this is the whole truth and nothing but the truth".

Jamal is called "The Operator" in layer-2 jargon.

If you ever transacted on Ethereum you probably have seen where this attached data goes, it’s the “Input data” field on Etherscan explorer. As the figure below shows, for simple Ether transfer, most people just leave it empty. When calling a function, like the swap function of Uniswap for example, the name of the function and the input to it get attached in that field. And this is where WiSwWhom gets attached to Jamal transaction: his transaction is a call to a function in the ORU contract on layer-1.

Left: No data attached to a simple Ether transfer transaction. Right: a Uniswap’s function name and its input (e.g. min_tokens is the amount to receive) are attached as data.

The ORU contract on Ethereum only verifies this one signature by Jamal. Students' signatures inside the attached WiSwWhom are just blobs of "cold" binary data as far as layer-1 is concerned.

This is where the scalability gain comes from: Ethereum full nodes do not run verification of the signatures inside WiSwWhom, they only verify the ORU operator's signature and store the attached data.

Let's see why this data must be stored by full nodes forever.

Loose ends

You may have noticed in Jamal's signed message above two phrases were emphasized:

1. the whole truth

2. nothing but the truth

Failing (1) would be censorship. It means Jamal is maliciously censoring, say, Alice's message because Bob bribed him to do so. Bob has a beef with Alice and wants to mess up her romantic life.

Failing (2) would be fraud. It means Jamal included one or more invalid messages. For example, the message Jamal included for Alice says "I am dating 10 boys and 10 girls simultaneously" when in fact she never signed such a message. The signature Jamal included in WiSwWhom for Alice is invalid, it’s a fake signature. Bob may have bribed him to this to hurt Alice, or maybe Jamal himself has a grudge against Alice and wanted to embarrass her. And as we said, the ORU smart contract doesn’t check the validity of what's inside WiSwWhom, that would defeat the purpose of using ORU in the first place: it would drive up gas costs (signature verification ain’t cheap) and this essentially degrades into the unsustainable Solution v1 above.

Jamal is a nice guy and he promised never to commit censorship or fraud. To be safe, however, we are going to rely on “can’t be evil” and not “won’t be evil”.

Keeping Jamal in check

The school incentivizes Jamal not to commit censorship or fraud using a carrot and stick strategy:

• Carrot: Jamal gets paid an attractive fee for his service. Every time Jamal submits the daily WiSwWhom transaction, the smart contract increases the amount that he can withdraw from the School's wallet by, say, $5. Jamal can't withdraw that $5 just yet, he can only do so at the end of the month. So Jamal sees this pot increasing in value everyday. It should be high enough for him to start salivating.

• Soft stick against censorship: if Jamal ignores a signature from student Alice, she must be able to directly post her own signature to the smart contract for that night (and incur the gas fee of course). She then goes to see the school principle in the morning to tell him about the censorship. She'd probably raise the alarm to all students as well. Jamal's reputation would take a hit.

  It is very easy for the school to solicit a replacement for Jamal: the contract is already up and running on layer-1, Jamal’s replacement just needs to fire up an AWS lambda function listening for student messages, batching up signatures, and broadcasting that single transaction to the ORU contract. Ain’t no thang.

  In fact anyone willing to lock a bond on the contract can become the operator. It’s just that they need to advertise themselves to the students etc.

• Hard stick against fraud: anyone can detect a fraudulent post by Jamal and call the contract on layer-1 with a simple proof of that fraud. Furthermore, Jamal is required to lock a bond in the contract (and anyone wanting to become an Operator must deposit a bond before the contract recognizes them as such).

  A fraud proof by a whistleblower against Jamal goes like this: "hey ORU contract, here is a signature that was included in this posted data in which Jamal attested it was signed by Alice, but I -the whistleblower- claim that this signature is invalid".

  The contract extracts¹ Alice's signature from the belly of that previously posted data, runs signature verification against Alice's public key (which is stored in the ORU contract when it was set up). If indeed this signature is fake, the contract:

  • zeros out pending rewards for Jamal.

  • sends half of Jamal's bond to the whistleblower and burns the other half.

A closer look at the hard stick

The hard stick is the most interesting and most defining aspect of ORUs. It's actually what makes a layer-2 solution an ORU!

What is different about this stick: anyone can wield it, not just the school or the students. The WiSwWhom data is available on-chain now and forever, and that is all a whistleblower needs to detect invalid messages committed by Jamal, prove them to the ORU smart contract, and collect a reward for it.

How that stick is designed and exercised is the most important distinguishing factor between different ORU implementations.

A call from the Ministry of Education

"When mainstream adoption?" is an oft asked question in crypto circles. Well if the mainstream finally starts "blockchaining" in a big way, ORU can help contain the stampede.

Suppose the Ministry of Education wants to commission Jamal to start processing signatures from all schools nationwide. We would then ask: how many schools can layer-1 handle, not how many students.

You might ask "why not push this further by having 1 tx for the whole nation instead of 1 tx per school?"

And that brings us to the ultimate ceiling on ORU scalability: block gas limit. Although the data being posted by Jamal is cheap gas-wise, it does costs gas nonetheless. And ultimately the total amount of gas for all data of all school nation-wide may exceed the block gas limit, in which case Jamal would need to submit them in batches.

So there is a ceiling to how much scalability gains can be squeezed out of ORUs. If you want infinite scalability, go with sidechains or plasma .. but then FUNDS NOT SAFU.

The scalability gains, one more time

The gains come from the fact that, in the happy case, layer-1’s full nodes need not execute transactions buried in the belly of the data attached by the ORU operator:

• Less overhead costs incurred because storing data is way cheaper than running whatever logic inside its belly.

• Less gas costs per individual transactions because storing data costs less gas than executing transactions.

How ORUs are different from Sidechains / Plasma's / State Channels

• Unlike sidechains, which have been around since 2014 but have thus far failed to gain any traction, ORU chains are secured by layer-1.

  If you are transacting on an ORU chain, say playing poker or trading tokens, then your assets are as secure as they would have been had you been transacting on layer-1 itself (e.g. Ethereum mainnet). You may go through inconveniences when there is a fraud situation, like waiting a week or two for your funds to be released, but funds are secure by L1 nonetheless.

  In contrast, if you were transacting on a sidechain, the sidechain's miners (PoW) or validators (PoS) could steal your funds if they wanted to because they can tell layer-1 any story they want about what's happening in layer-2. Layer-1 has no way of knowing what's happening down there.
  

• Unlike plasma and state channels, ORUs have simple fraud proofing mechanisms and anyone can submit them. Whistleblowers have all the data needed available on layer-1 to detect and report fraud and get rewarded for it by the ORU smart contract. In plasma and state channels generally, the users are responsible in part or in whole about the safety of their funds and must be “watching” what is happening on layer-1’s contract in case the operator or another user tries to make a fraudulent exit.

Executive summary for the road

An optimistic rollup chain is really just (1) a smart contract on some layer-1 chain like Ethereum mainnet and (2) block producer(s) that listens for transactions on a dedicated P2P network, batch them up into one big string of data, and post it to layer-1 along with a signature attesting to their validity. This attestation can and will be used against them in the court of the ORU smart contract if they commit fraud.

The contract must be capable of accepting transactions directly from users in case the Operator is censoring. That allows a user to exit the ORU safely with their funds if the Operator goes rogue or unresponsive. And importantly, the contract can verify fraud claims and slash the operator’s bond if indeed there was fraud.

It must be the case that the data attached to an ORU transaction is all a whistle-blower needs to detect and report fraud. Layer-1 full nodes never execute what’s inside the attached data (unless someone reports fraud) and that is where the scalability gain comes from. To layer-1, that data is just a binary blob to be stored forever.

---

Thanks to Takahiro Kido for this song which accompanied the writing of this article on-repeat. Thanks to Harry Kalodner for his feedback.

Have a great day.

1. The contract can’t access history (logs) which is where the data is, but it does keep track and updates of a Merkle root that can later be used to validate the data when submitted during a frault alarm.