TLDR;
Refutation games are at the heart of Smart Optimistic Rollups. They allow for disproving incorrect assertions, thus protecting the rollups' integrity. This post showcases a new feature of Explorus that enables observing refutation games as they happen in a rollup and provides the required steps to reproduce the experiment.
What is Explorus?
Explorus is a web interface designed to monitor, analyze, and troubleshoot the behavior of the consensus mechanism and cutting-edge features of the Tezos blockchain, such as transactional and optimistic rollups. It is lightweight and resilient and only needs to connect to a node to display live information of a network. There is no need for an indexer, a database, or an API server. You can find more about these features in a previous blog post.
Smart Optimistic Rollups and Refutation Games In a Nutshell
Smart Optimistic Rollups (SORU) are layer 2 solutions, similar to sidechains, that enable blockchain scaling (layer 1) by moving execution off-chain or to subchains. But, unlike sidechains, which only interact with the mainchain by periodically notarizing their states' hashes, SORU integration with layer 1 is much tighter, allowing it to rely entirely on the main chain:
- for its own consensus;
- to resolve conflicts and slash bad actors, in case two operators pretend to obtain two different states after executing the same bunch of messages.
Conflicts resolution is achieved via what is called "refutation games". When a divergent state is detected, two involved operators will successively bisect their executions and challenge each other by sending the intermediate states' hashes to the main chain.
Once there is only one conflicting execution step left, the operator whose turn it is to play should produce a refutation proof demonstrating that his calculation step or his imported input step is legit. If so, the opponent will lose the game and forfeit their deposit for that rollup. For this to work correctly in practice, at least one honest operator should run a rollup, periodically post their successive state's hashes (a.k.a "commitments"), and adequately defend them in case of conflict.
Finally, a non-conflicting commitment (state hash) can be finalized (we say that it's cemented) after an amount of time (a few days or two weeks, depending on networks). In this case, the executed messages cannot be questioned anymore.
Explorus in Action: Tracking a Refutation Game
The SORU tab of explorus displays the list
of all games in progress if any. In a given game, opponents are called Alice
and Bob (instead of using their public key hashes). The states (we will omit
hashes in the rest of the post) on which
Alice and Bob agree are shown in green, and those on which they disagree are
displayed in red (see screenshots below).
At the beginning of a game, two states are presented. In the screenshot below,
the red one is the state of the commitment published by Bob at the conflicting
level. Of course, Alice has a different state at that level, as she disagrees
with Bob's. The green one is the state of the previous commitment on which
Alice and Bob agree.
Once the game is started, Alice makes the first move. In the screenshot below, she sends 32 intermediate states between the agreed and the conflicting state. At this moment, there is no information on which of her states Bob agrees/disagrees with. That is why the hashes are displayed in black. This is called a dissection move in the refutation game. It is how players can pinpoint the exact execution step (tick) in the virtual machine of the rollup.
Then, Bob detects the last Alice's state he agrees with before they start diverging. Step 300 is the latest agreed state, and step 312 is the first conflicting state in the screenshot below. So, in turn, he sends a dissection of intermediate states between these two steps. At this point, Bob's move allows coloring in Explorus Alice's intermediate hashes sent in the previous move as follows: hashes 300 and above are green, and hashes 312 and following are red. As you may have noticed, Bob's states are still in black for the moment.
Opponents continue playing until one does not send any states for a certain amount of blocks (we say that they timeout) or one sends a valid proof for an elementary step.
In our example, Alice sends a PVM proof showing that Bob's state at step 302 is not as expected. The conflict is resolved, and Bob has lost the game.
Get in the Game: Triggering a Refutation with SORU
To observe a refutation, two operators must send different commitments at a
given level for the same smart rollup. Of course, we don't want this kind of
behavior in production networks. But, for testing purposes, a node option
--loser-mode is provided in Tezos smart rollups to trigger this kind of
scenario.
There are several refutation tests in the Tezos codebase. To enable monitoring
the underlying layer 1 nodes of these tests, they should be run with the
--cors-origin="*" option. We made this change on a modified version of the
tests
and slowed down the tests to be able to correctly follow refutations live.
Above, we shared the screenshots obtained with the test entitled: 'Alpha:
arith - refutation games winning strategies (pvm_proof_2)'.
If you want to reproduce, do the following:
- Clone the repository:
$ git clone https://gitlab.com/functori/dev/tezos.git - Checkout the right branch:
$ git checkout origin/functori@fit-refutation-tests-for-explorus - Build Tezos from sources
- Run one of the refutation scenario tests, for example:
$ dune exec tezt/tests/main.exe -- -f sc_rollup.ml -t 'Alpha: arith - refutation games winning strategies (pvm_proof_2)' -v - Visit explorus settings, and:
- Enter the node address:
localhost:16385 - Go to the
SORUtab - Finally, select the smart rollup. The view should be refreshed at each new block. You should see the different steps shown above displayed
- Enter the node address:
Contribute with us!
Do not hesitate to give us feedback either through tezos-dev's slack or by opening an issue ticket from our repository explorus/issues. It'd be much appreciated!
