Add determinism docs

[pcw109550]

No description provided.

[ImTei]

Great article 👍

[ImTei]

What's the exact meaning of determinism in this article? We need the definition and examples of determinism.

[ImTei]

In the preceding paragraph, you mentioned factors of non-determinism, and this paragraph is a specific example case of Cannon. So it will be better if this paragraph is organized by numbering, subheading, or bullet points.

[ImTei]

Can you elaborate on this part? What does 'identical virtual machine' exactly mean? Why does pipelining affects determinism? why don't you add more examples we have discussed, such as system call handling?

[taempark]

Suggested change

	[Determinism](https://en.wikipedia.org/wiki/Deterministic_system#In_computer_science) is crucial for rollups because of [fault proof](https://community.optimism.io/docs/protocol/2-rollup-protocol/#fault-proofs). Validators will execute program([Turing machine](https://en.wikipedia.org/wiki/Turing_machine) tape) to validate the proposed state of rollup, syncing shared [repliced state machine](https://en.wikipedia.org/wiki/State_machine_replication). The state machine consists of a transition function. The transition function must be deterministic to decide which party is correct when dispute occur. For example, let's say that Alice is the state proposer and Bob is a validator. Bob will advance its own machine state by validating the program, and checks the sanity of proposed state at L1 and disagrees with it, and tells L1 that Alice has lied, triggering fault proof. If the program is nondeterministic, L1 will never find out who's claim(state) is right, leading L1 security inheritance loss.
	Rollups allow faster, cheaper, and more complex program executions because they execute programs off-chain and validate on on-chain. Thus, it is very important that all off-chain clients generate the same output; otherwise, off-chain clients will incorrectly verify executions, cannot validate correctly on on-chain, and the rollup won't ever be able to be correctly verified. We call the validation process [**fault-proof**](https://community.optimism.io/docs/protocol/2-rollup-protocol/#fault-proofs), the characteristic that gives the expected output [**Determinism**](https://en.wikipedia.org/wiki/Deterministic_system#In_computer_science), and off-chain clients that validate the chain **Validator**.
	Let's take an Alice and Bob example where Alice is a state proposer, and Bob is a validator. Alice would propose a state at L1. However, when Bob advanced his own off-chain machine state machine, he received a different result. He triggered fault proof because he figured Alice lied. Here comes the importance of determinism. If the program is non-deterministic, L1 will never find out whose claim(state) is correct, and the rollup no longer inherits L1's security.

[taempark]

Suggested change

	Note that determinism is only required when validating. When sequencer executes transactions(not validating), determinism of the entire program is not required. EVM state machine will provide necessary determinism for execution. For example, let's say that the sequencer uses [geth](https://github.com/ethereum/go-ethereum)'s EVM implementation for transaction execution. Even if geth program is nondeterministic because of parallelism(multiprocessing + goroutines), EVM state machine will still be deterministic. When validating, since required logic for validation is a part of execution program, the required logic can be taken care for guaranteeing determinism, such as compiling down to [Wasm](https://en.wikipedia.org/wiki/WebAssembly) or [MIPS](https://en.wikipedia.org/wiki/MIPS_architecture).
	Every validator must share identical virtual machine structure for supporting determinism. If not, nondeterminism will sneak in. For example, Alice is validating MIPS program using virtual machine where pipelining is disabled. Bob is validating using actual MIPS chip which pipelining is enabled. Intermediate state may be different due to discrepancy of validation machine.
	There are multiple causes which introduces nondeterminism, such as parallelism, concurrency, virtual machine difference and even instruction level nondeterminism. We need to dodge this issues while validating(proving), making the proved program be deterministic. Let's observe how the two big rollup giants: [Arbitrum](https://arbitrum.io/) and [Optimism](https://www.optimism.io/), managed to overcome nondeterminism and handled side effects. After that, we will discuss food for thought topics related with determinism.
	In the preceding example, we should ensure that Alice and Bob's off-chain client generates the same value as the on-chain validation program to guarantee that a rollup inherits L1's security. On-chain validation program could easily guarantee determinism because it's executed on EVM, where determinism is built-in. However, Alice and Bob's off-chain clients may not guarantee deterministic execution depending on how their clients solve the determinism problem.
	Guaranteeing deterministic execution for off-chain clients is quite challenging since it's hard to build an execution environment that works exactly the same at the machine-language level for every computer. We should resolve some difficult issues such as parallelism, concurrency, virtual machine difference, system call, and non-deterministic machine instructions.
	Let's take Alice and Bob's example. They are both validators, Alice uses an 8-core CPU, and Bob has a 4-core CPU. Even though they are running the same program, machine-level instruction cannot be identical because the order of instruction will be different due to parallel execution. It's not guaranteeing deterministic execution. Many similar issues interrupt deterministic execution in the computing world.
	Arbitrum and Optimism solved the determinism problem and achieved their mission despite its difficulty. In this article, we'll figure out how each two rollup giants solved the problem, handled side effects, and some food for thoughts related to determinism.

Not sure if it's good though. Let's chat tmr.