docs: proof_of_fraud in en (#46)

docs/ch/challenge.md → docs/ch/proof_of_fraud.md

@@ -2,10 +2,8 @@
 
 > 在阅读本文之前，建议读者了解 op/arbitrum 中使用的交互式仲裁的技术概念。
 
-
 ### 交互式的链上仲裁
 
-
 当二层网络的参与者对于某一个区块的状态产生分歧时，二层网络需要在一层网络中提供仲裁手段，作为法官的角色，裁决控辩双方各自提交的证据的真假。
 在交互式证明中，控辩双方需要轮流提供各自在执行区块过程中产生的中间状态证明。
 
@@ -55,7 +53,6 @@ OMO 也是基于这种朴素的方法实现中间状态证明。
 只需要在链下预执行这一步指令，拿到它访问的数据即可。外加这些数据的状态证明，链上就可以执行这一步并生成证明。
 这种思路类似于以太坊轻节点：在没有完整区块历史的情况下，轻节点只需要拿到验证某个区块所必须的状态数据，就可以完整对某个区块的校验。
 
-
 ### 仲裁合约（法官）
 
 为了验证 OMO 的可行性，我们用 Move 实现了针对 mips 指令集的[仲裁合约](https://github.com/starcoinorg/omo/tree/main/contracts)。
@@ -66,7 +63,6 @@ OMO 也是基于这种朴素的方法实现中间状态证明。
 - 执行后的内存/寄存器状态的证明生成，（包含了以太坊 trie 的实现）。
 - 以及完整的交互式流程。
 
-
 ## 链上仲裁的 DEMO
 
 OMO 代码库里，包含有一个模拟控辩双方做链上仲裁的命令行程序：[omo-workflow](https://github.com/starcoinorg/omo/tree/main/omo-workflow) 。

docs/guidelines.md

@@ -5,7 +5,7 @@ Guidelines of background, design and implementation docs of OMO.
 
 * [Overview](overview.md) / [[概览]](ch/overview.md)
 * [Components](components.md) / [[组件]](ch/components.md)
-* [Challenge](challenge.md) / [欺诈证明](ch/challenge.md)
+* [Proof of Fraud](proof_of_fraud.md) / [欺诈证明](ch/proof_of_fraud.md)
 * [Contracts](../contracts/README.md) - Details of Move modules for verifying Layer2 instructions.
 
 ## Additional Information*

docs/proof_of_fraud.md

@@ -0,0 +1,69 @@
+## Proof of Fraud
+
+> Before reading this article, the reader is advised to understand the technical concepts of interactive arbitration used in op/arbitrum.
+
+### Interactive on-chain Arbitration
+
+When participants in a Layer2 network disagree about the status of a block, the Layer2 network needs to provide a means of arbitration in the Layer1 network, acting as a judge to decide the truth or falsity of the evidence submitted by each of the accuser and the defender.
+In an interactive proof, the prosecution and the defense need to take turns to provide intermediate state proofs generated by each during the execution of the block.
+
+A relatively quick method is the dichotomous approach. Assume that a block takes `N` steps to execute. The prosecution and defense first provide proof of their respective states after the final execution (i.e., step `N`), and if the judge finds that the results are inconsistent, he or she can ask both sides to provide proof of the state of step `N/2` again.
+If the results are consistent at this point, the disagreement is between steps `N/2` and `N`, and the judge may ask the parties to provide evidence of step `(N/2 + N) / 2`.
+If the results are inconsistent, the disagreement is between step `0` and step `N/2`, and the judge can take evidence from both sides for step `(N/2) / 2`.
+With this multiple rounds of interaction, the judge keeps comparing the evidence submitted by both sides until he finds a step (say `m`) where the evidence of the two sides diverges (the intermediate states of the two sides prove inconsistent).
+
+At this point, the prosecution and defense have already agreed on the intermediate state proof of the previous step (`m-1`), and the judge 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 prosecution and defense to determine which side has submitted the right evidence.
+
+### Evidence Generation (intermediate state proofs)
+
+As can be seen, there is a key element in interactive on-chain arbitration, namely evidence generation. How intermediate state proofs are defined and generated is a key technical indicator that distinguishes a two-tier network from other two-tier networks.
+
+For example, arbitrum defines its own set of virtual machines, AVMs, and corresponding underlying instructions. AVMs save different types of data, e.g., code blocks, memory blocks, registers, call stacks, etc., when executing contract code, and then generate proofs of these data in an efficient way.
+
+! [arb one-step proof](... /imgs/arb-onestep-proof.png)
+
+For example, optimisim's latest [cannon](https://github.com/ethereum-optimism/cannon) is also based on a similar principle of state proof generation.
+The difference is that instead of customizing a new set of virtual machines, cannon compiles existing EVM virtual machine code into assembly code for the MIPS instruction set.
+It then generates intermediate state data and proofs for the underlying MIPS code.
+
+I think cannon's idea is more flexible, general and extensible, but cannon's current implementation is too tightly bound to geth to make it easy to apply it directly to other contract language VMs, such as Move.
+OMO tries to extend the applicability of this intermediate state proof generation idea to more VMs.
+
+Currently, OMO implements the execution of the mips instruction set code and the generation of intermediate state proofs (other instruction sets such as wasm, riscv are planned in the future).
+The underlying implementation of the MIPS simulator uses [unicorn](https://github.com/unicorn-engine/unicorn) and references some of the logic of [qiling](https://github.com/qilingframework/qiling).
+During the execution of the mips code, unicorn provides various hooks that allow the caller to easily know the running state of the program.
+Specifically for state proof, OMO is concerned with the _memory/register_ state of the program.
+
+``` rust
+pub struct EmulatorState {
+    pub regs: BTreeMap<i32, u64>,
+    pub memories: BTreeMap<u64, Chunk>,
+    pub steps: u64,
+}
+```
+
+Memory and registers are essentially an array (some addresses have a value of 0 and can be left out of the state proof), and a more popular way of generating proofs is merkle tree root.
+OMO is also based on this plain approach to implement intermediate state proofs.
+
+### On-chain Execution (arbitration)
+
+In interactive arbitration, at the end, the judge needs to execute the `m` step based on the state of the `m-1` step, thus generating a proof of the state of that step to compare with the proofs submitted by the prosecution and defense.
+This step is executed on the chain. Obviously, we cannot put all the state data of the program at step `m-1` on the chain; after all, it is too large.
+Nor do we need to do so, since the instruction will only access a few relevant pieces of data during the execution of the `m` step instruction.
+Just pre-execute this step instruction under the chain and get the data it accesses. Adding a proof of the state of this data, the chain can then execute this step and generate the proof.
+This idea is similar to that of the Ethernet light node: in the absence of a complete block history, the light node only needs to get the state data necessary to validate a block, to complete the verification of a block.
+
+### Arbitration Contract (Judge)
+
+To verify the feasibility of OMO, we implemented [arbitration contract](https://github.com/starcoinorg/omo/tree/main/contracts) for the mips instruction set using Move.
+This contract implements the on-chain execution functionality described above and contains.
+
+- The up-chaining of pre-states.
+- Single-step execution of the mips instructions.
+- Proof generation of the memory/register state after execution, (incorporating the implementation of the ethereum trie).
+- and a complete interactive flow.
+
+## DEMO for on-chain Arbitration
+
+The OMO code base contains a command line program that simulates on-chain arbitration between the accuser and the defender: [omo-workflow](https://github.com/starcoinorg/omo/tree/main/omo-workflow).
+The code home page describes how to run the program, and interested readers can try it out.