Differences between Coinweb and rollups

info

• Coinweb wallets are light network clients that acts as referees in refereed delegation of computation (RDoC).
• Unlike typical (Ethereum) wallets, Coinweb wallets do not require a trusted node to connect to.
• Coinweb light network clients (wallets) have built-in support for bisection algorithms similar to fraud proofs for optimistic rollups.
• Coinweb light network clients (wallets) must have access to a WebAssembly runtime to evaluate the bisection leaf nodes.
• Coinweb light network clients (wallets) find and filter dishonest nodes.

(a typical L1 blockchain using decentralised consensus to secure the consistency of the blockchain state)

Introduction

Coinweb, unlike rollups, has a dispute mechanism, the referee, in the client (on your phone), not as a smart contract on L1.

This makes it easy to run on a diverse set of blockchains, including bitcoin-derived chains, it removes the delay associated with the dispute period in rollups, dispute resolution does not depend on the L1 smart contract language, results become deterministic in time, and by not having a sequencer responsible for posting transactions, certain availability and censorship issues are eliminated.

A good background on rollups can be found in this post: https://research.paradigm.xyz/rollups

In rollups there is a sequencer that posts transactions and the results to the L1 chain. If the result is invalid/wrong, then there is a dispute period where some ETH amount (called a fidelity bond) can be won by detecting the fraudulent result.

Example: The sequencer posts the following data to the L1 chain:

given transactions: Transfer 3 from A to B, Transfer 1 from B to C, Transfer 1 from C to A, the state root of all accounts is 0xdeadbeef

where 0xdeadbeef is a compressed version of the new L2 state, the L2 state root.

After the sequencer has done this, then a verifier can post a statement:

it's not 0xdeadbeef, it's actually 0xf00baad

during the dispute period, and reap a reward, part of the fidelity bond. The verifier posts a fraud proof, and figuring out of this fraud proof is real or not can involve an interactive back and forth that takes a long time on-chain.

This dispute protocol requires smart contract support.

If we look at this from the point of view of the Ethereum client, the client would connect to multiple other Ethereum clients to first figure out what the latest correct block is.

The app running on your phone will connect to one such trusted Ethereum client, find the correct last block, and look inside the block to find the hash that defines what the L2 state is.

When starting this process, when the client wants to understand what the latest block is, it can be given different possible "tips" on the last block, and it needs to figure out which one is correct. In PoW systems, this is (easily) done by having the client calculate the total work the miners have done since the start of the system, and trust that to be the last tip. In general, a client needs to understand which block is the latest by evaluating some consensus algorithm. When this is done, it can extracted from the smart contract that manages the L2 rollup logic.

In Coinweb, we post the data "Transfer 3 from A to B, Transfer 1 B to C, Transfer 1 C to A" to the l1 chain. Similar to the rollups, this is just data posted to L1, not transactions executed by L1. However, Coinweb does not post the result "... after which the state is 0xdeadbeef".

So how can the clients (on your phone) read that the L2 state is 0xdeadbeef after those L2 transactions have executed?

The Coinweb light client will, a bit similar to the Ethereum client, need to figure out what the "tip" is, but instead of trying to find the latest Ethereum block by asking a set of Ethereum network nodes, it will ask the Coinweb network nodes for the latest coinweb state, the hash. Similarly to the Ethereum case, there can be different states proposed by different Coinweb nodes.

The client as the referee

At this point, things start to differ. The client (on your phone) will do a divide-and-conquer protocol similar to the dispute resolution that is done in rollups. This type of dispute resolution iteratively narrows the disputed part of the computation in order to find where the dispute lies.

When the dispute is narrowed enough, there is one "atom" left, something that cannot be further subdivided. Examples of atoms can be that the two nodes disagree on what the tip of Ethereum is, or they disagree on the result of executing a WebAssembly instruction, or they disagree on the contents of an L1 block.

For each of these atoms, the client is equipped with a way to evaluate that atom itself. In the case of a disagreement on what the tip of Ethereum is, the client will evaluate that itself, similar to what an Ethereum client will do (i.e. connecting to nodes and evaluating the consensus). If there is disagreement on executing a WebAssembly instruction, the inputs and outputs for the instruction are gathered and evaluated. If there is disagreement on the contents of a block, Merkle proofs are evaluated by the client.

Implications for dApps - unifying interoperability and data-availability

Moving the dispute resolution mechanism out of L1 smart contracts not only makes it more effective it also becomes blockchain-agnostic, meaning that the output from dApps can now be verified against any L1 blockchain input. This is very significant since the availability of verifiable data is one of the drivers of network effects. Coinweb dApps can now tap into the aggregated network effects from all the connected chains, making them immediately more powerful and easier to bootstrap. You can read more about this here