A Test of zkSync 1.0’s Exodus Mode on Ropsten

This post was originally published on Matter Labs

Try out zkSync’s emergency exit mechanism in action.

Matter Labs

Apr 23 · 3 min read

Yesterday, the “Exodus Mode” was triggered on our Ropsten testnet. This was unplanned, but shows that the safety mechanisms of zkSync 1.0 work as intended. Here is what happened.

We are currently testing a new system to mitigate consequences of possible forks of the Ethereum network on both Rinkeby and Ropsten testnets. This system pings different Ethereum nodes to make sure that they all remain in sync. It turned out, there was a bug in the implementation of the request rate limiter for this system, causing unavailability of the web3 API for Ropsten, which led to priority operations (deposits and full exit requests) being ignored.

This scenario could not have happened on Rinkeby or mainnet, because everyone would have quickly noticed that the system is not working properly. But Ropsten is our least used, and therefore least monitored testnet. We do not have as many alerts set up for Ropsten as we do for the production system. Moreover: for mainnet, not only are there extensively more alerts, it is also proactively monitored with multiple independent mechanisms deployed on different cloud providers.

The situation led our system to believe the operator was offline or malicious, and enabled exodus mode to be triggered. Exodus mode is what ensures L1-level security in zkSync. You can always trustlessly reconstruct the state data and withdraw your funds — this is the security claim of a zkRollup. It works as follows:

If transactions are being censored by the rollup operator, users can withdraw funds from the rollup by submitting a L1 call to the rollup smart contract function `requestFullExit`. `requestFullExit` is a priority operation, and if a priority operation is not processed in 3 days, anyone can call `activateExodusMode`. During the exodus mode, all rollup activity is stopped and all users can withdraw funds by calling `performExodus`.

Now we have to set up a new Ropsten testnet next week. In the future, we will no longer need to do this. In zkSync 2.0, exodus mode will be replaced with a non-terminal emergency mode. If it’s triggered, rollup blocks can still continue to be produced, but may only contain priority operations. The tx sequence thus becomes deterministic, so anyone can produce the proofs and submit new blocks without the danger of a race. This mechanism can be used for permissionless mass-exits or censorship-free voting / governance on the zkRollup. And we will be able to safely recover from any temporary issue without the need to redeploy the entire system.

But this is a great opportunity to check out how trustless zkSync is in practice! You can do so using our emergency exit tool, which will perform the following:

  1. Restore the state complete from the calldata of Ethereum tx history.
  2. Create a proof for the user’s exit balance.
  3. Prepare a tx with the ownership proof to claim the funds.

You can test it to withdraw funds for any account.

Fun fact: exodus mode was not triggered by the zkSync team. Thank you, d̶e̶v̶o̶p̶s̶1̶9̶9̶ 0xFd5c87! 😉

Leave a Comment