# Security

Rooch Network uses the Fraud Proof based on Optimistic Rollup (opens in a new tab) mechanism to ensure the security of Rooch DApps.

Rooch will also support Hybrid Security enabled by ZK Proof as part of the future fowkr.

## flexEmu - A General Purpose Emulator with Per-Step Proof

Generating Fraud Proof is a critical piece for ensuring security of the off-chain system in an Optimistic Rollup system. For this purpose, we have designed flexEmu (opens in a new tab).

Find the specifications of flexEmu on GitHub (opens in a new tab).

### Multi-Round Interactive Arbitration

The Fraud Proof generation is based on a multi-round interactive proving process. The objective is to find the exact step of instructions that caused the divergent state between the Challenger and the Defender.

Here's a detailed explanation of how it works:

Assuming that a block contains `N`

steps to execute. The challenger and defender first send proofs of their respective states after the final execution (i.e., step `N`

) to the arbitration contract, and if the arbitration contract finds that the results are inconsistent, it will ask both sides to provide the proof of the state of step `N/2`

.

- If the results are consistent at this point, the disagreement must have happened between steps
`N/2`

and`N`

, and the arbitration contract will require both parties to provide the proof of the step`(N/2 + N) / 2`

. - If the results are inconsistent, the disagreement is between step
`0`

and step`N/2`

, and the arbitration contract will take the proof from both sides for step`(N/2) / 2`

.

All parties will keep on having multiple rounds of proving process like this, until the arbitration contract identifies the exact step of instructions that caused the divergent state.

At this point, the challenger and defender have already agreed on the intermediate state proof of the previous step (`m-1`

), and the arbitratioin contract only needs to perform the `m`

step based on the state of the `m-1`

step, and then compare the generated state proof with the proofs provided by the challenger and defender to determine which side has provided the correct state.

The side that provides the fault state will be slashed with economics mechanisms.

Tokenomics will be published in 2024 Q4

### flexEmu Advantages

flexEmu is designed to be a general purpose bytecode emulator with per-step state proof. Its general purpose provides 2 advantages to Rooch's implementation:

**Compatibility with Arbitrary Layer1**Any Layer1 that supports MIPS operation code set will be able to arbitrate proofs generated by flexEmu. This enables Rooch to be Layer2 for arbitrary Layer1s.**Easy for Maintenance, Debugging and Upgrades**If there are any major upgrades to MoveVM in the future, flexEmu can quickly accommodate them.

## Hybrid Security with ZK Proof

This is a future work of the Rooch project and is not integrated in the current roadmap

Rooch will leverage zkMove (opens in a new tab) to generate ZK Proof for optimizing the challenge period of the Fraud Proof mechanism, and create a Hybrid Security mechanism with both Fraud Proof and ZK Proof.

zkMove (opens in a new tab) is a zero-knowledge Move language runtime environment that realizes bytecode level compatibility. Rooch Network has a partnership with zkMove and the two projects will collaborate in terms of technology development as well as application scenarios.

### How it works

With only Fraud Proof, a user's withdraw transaction submitted at `BlockT`

needs to wait for a challenge period of `N`

blocks to reach finality, and only after this the user can withdraw its asset on Layer1.

With ZK Proof generated by ZK Prover using zkMove, the challenge period can be optimized to a much lower amount of blocks. Here's how it works:

- The proposer keeps committing blocks of state to Layer1 at its maxmium speed
- ZK Prover generate ZK Proofs for the state blocks that have been committed to the Layer1, at a relatively slower pace, due to the considerably long proof generation time
- For the withdraw transaction submitted at
`BlockT`

, it can be considered finalized when the ZK Proof of`BlockT`

has been generated and verified on Layer1, instead of waiting to reach the end of the whole challenge period

## Proof-of-Stake based Security from Bitcoin

TODO: This section of the document needs improvement

- Explaination of getting security from Babylon system.