docs(data flow): add force inclusion, L1toL2 messaging (#731)

* init deposit flow docs

* docs(data flow): add tx inclusion mechanism

* docs(data flow): add a freeze request to freeze a sequencer after a long period of inactivity.

* docs(data flow): add TODO sequencer rotation mechanism

In multi-chain settlement, we rely on L2 nodes to confirm the state (since the state root of Rooch is not available to the settlement chain alone). Therefore, freezing the sequencer directly will prevent users from withdrawing their assets from L2. For these reasons, we need the sequencer rotation mechanism to be able to serve the malicious nodes even if they are forcibly frozen.

* docs(data flow): add deposit flow

basic roles & contracts layers

* docs(data flow): L2 tx censorship resistance by deposit tx event on L1

* docs(data flow): refine deposit flow with functions parameters

* docs(data flow): update deposit flow figure

* docs(data flow): add deposit gas fee mechanism

* docs(data flow): refine deposit protocol stack

* docs(data flow): rename deposit flow to l1_to_l2_messaging

Deposits confuse people and can easily be confused with asset transfers. Messaging is much more underlying, while asset transfer (deposits, withdrawals) is just a function realised through messaging. To better reflect this underlying logic, I dropped the use of deposit as the name for L1 to L2 messaging

* docs(data flow): rename deposit flow to l1_to_l2_messaging

Deposits confuse people and can easily be confused with asset transfers. Messaging is much more underlying, while asset transfer (deposits, withdrawals) is just a function realised through messaging. To better reflect this underlying logic, I dropped the use of deposit as the name for L1 to L2 messaging

* docs(data flow): transaction inclusion using L2 light node verification

Block header information for light nodes needs to meet a certain level of timeliness to break circular arguments

* docs(data flow): refine transaction inclusion arbitration mechanism

clearer

docs/website/pages/docs/tech-highlights/l1_to_l2_messaging.zh-CN.md

@@ -0,0 +1,83 @@
+# L1 至 L2 的消息传递
+
+## 概述
+
+L1 至 L2 的消息传递由 L1 触发的 L2 交易实现。（资产转移基于此机制实现）
+
+Rooch 具备多链资产结算的能力，对于每一条 L1 来说，其 L1 to L2 流程一致（注：合约名及其参数受不同智能合约语言影响略有不同）。都是从 L1
+的消息开始经过层层封装传递到 L2 对应的合约之中进行消费：
+
+<img alt="L1 to L2 Messaging" height="405" src="../../../public/docs/l1tol2.jpeg" width="800"/>
+
+我们需要保证来自 L1 的消息能够 `rooch_node` 正确的解析并中继给相应的合约，从协议栈的角度来看：
+
+<img alt="Rooch L1ToL2 Protocol Stack" height="203" src="../../../public/docs/l1tol2_stack.jpeg" width="500"/>
+
+## L1
+
+1. 用户通过调用 `l1_stub` 中的 `call_remote` 函发起 `L1ToL2` 请求，所需参数包括:
+   1. `target`: L2 合约地址
+   2. `msg`: L2 tx 的 calldata 
+   3. `min_gas_amount`: L2 上允许使用的最小 gas 数量，即对调用 `target` 的估计值。
+   考虑到 L2 需要在调用 `target` 之前的处理开销，实际开销肯定会超过这个值。详见 [Gas Fees](#gas-fees)。
+
+   `l1_stub` 提供了较为友好的接口，调用者只需关心 L2 调用信息而无需关注信息封装和传递。
+
+2. `l1_stub` 将调用 `rooch_transport` 的 `send_l1_to_l2` 函数，
+   `rooch_transport` 为 L1 与 L2 通信的底层合约。`send_l1_to_l2` 参数包括：
+   1. `to`: 对应的 L2 Stub 合约地址。在这个场景中为 `l2_stub` 合约地址
+   2. `gas_amount`: 基于 `min_gas_amount` 以及 `msg` 尺寸估算得到的 L2 上的基础 gas 开销
+   3. `data`: `relay_msg_data` 编码后数据 (`msg_sequence` `msg_sender` `target` `msg` `min_gas_amount` 等必要信息)
+
+3. `send_l1_to_l2` 在完成检查后，发出 `L1ToL2Event` 事件，其中包括：
+   1. `from`: 发起 `send_l1_to_l2` 的 L1 账户地址/合约别名。在这里是 `l1_stub`
+   2. `to`: `l2_stub` 合约地址
+   3. `L1ToL2Event_version`: event 版本号
+   4. `event_data`: 在 `relay_msg_data` 基础上增加了 `gas_amount` 字段
+
+## L2
+
+1. `rooch_node` 监听 `L1ToL2Event` 事件，解析其中的参数，并封装为 `l1_to_l2_tx`
+2. 将 ` l1_to_l2_tx` 传递给 `l2_stub` 的 `relay_message` 函数，参数包括：
+   1. `sequence`: 中继消息序列号
+   2. `sender`: 消息发送方
+   3. `target`: L2 合约地址
+   4. `min_gas_amount`: L2 上允许使用的最小 gas 数量，即对调用 `target` 的估计值。
+   5. `msg`: L2 tx 的 calldata 
+3. `relay_message` 在完成检查后，调用 `target` 合约
+
+## Gas Fees
+
+Gas Fee 分为两个部分：
+
+1. L1 合约调用开销
+2. L2 合约调用开销（由 L1 燃烧实现）
+
+其中 L1 合约开销占据整体开销的绝大部分，L2 合约开销相对较小且有一定的免费额度（对于绝大多数资产转移场景而言，L2 免费额度是绰绰有余的）。
+对于超过免费额度的部分，将以一定比例在 L1 上燃烧:
+
+<img alt="Rooch L1ToL2 Gas Fee" height="450" src="../../../public/docs/l1tol2_gas_fee.jpeg" width="500"/>
+
+这就像是一个 Gas 变速装置，对于不同的链来说，我们只要替换 L1 的变速齿轮（调整 L2:L1 gas 比例）即可。
+
+燃烧将以在 L1 中以 `while loop` 形式实现，伪代码如下：
+
+    ```
+    i = 0
+    while (i < burn_amount) {
+        i++
+    }
+    ```
+
+## 重放消息
+
+在极端情况下，一条合法的 L1ToL2 交易可能会在 Rooch 上失败：
+
+1. Rooch 服务不可用
+2. 过低的 `gas_amount`
+
+此时，用户可以通过重放消息的方式重新提交交易，重放消息所需要的接口正在设计之中，敬请期待。
+
+
+
+

docs/website/pages/docs/tech-highlights/multi-chain-settlement.zh-CN.mdx

@@ -36,3 +36,7 @@ Rooch 在以太坊上部署了结算智能合约（`状态承诺链（State Comm
 
 - 多链结算更安全。多链结算方案中跨层桥（cross-layer bridge）的安全性由仲裁层（即以太坊）保护，执行层继承仲裁层的安全性。
 - 更通用的跨层解决方案。在 Rooch 的多链结算方案中，跨层是通过一种通用的状态迁移模式实现的，状态可以用来表示 Token、NFT、数字合约等未来的应用状态，而无需为新的状态类型设计专门的协议。
+
+## 原生桥
+
+

docs/website/pages/docs/tech-highlights/transaction_flow.en-US.mdx

@@ -42,6 +42,33 @@ From the functional perspective of internal components, the transaction executio
 2. The entire process includes multiple components such as `Executor`,`Sequencer`,`Proposer`, but these components may not be on the same node, and they may communicate remotely through P2P network. This part will also be updated in future versions.
 3. The above process is described based on the current design and some logic has not yet been fully implemented, and it will continue to be updated in the future.
 
+## Transaction Inclusion
+
+There are three methods of transaction inclusion in Rooch, each escalating in transparency and compulsion:
+
+1. Direct Request to the Sequencer
+2. Submission through L1's (any settlement chain) transaction queue
+3. Submission via L1's (arbitration chain) transaction queue
+
+### Direct Request to the Sequencer
+
+Users can directly request the Sequencer to include transactions. The Sequencer will add the transaction to the Accumulator and immediately return the global order of the transaction. This inclusion is public and arbitral, but the Sequencer may ignore user requests, thereby enabling transaction censorship attacks. When users are concerned about transaction censorship, they can submit via the third method.
+
+### Submission through L1's Transaction Queue
+
+Users can submit transactions to L1's transaction queue, awaiting the Sequencer's retrieval. This inclusion is public but not arbitral in all circumstances. Such transactions typically manifest as messages sent from L1 to L2, such as deposit transactions. For non-arbitration chain, when users are concerned about transaction censorship, they can submit via the third method.
+
+### Submission via L1's (Arbitration Chain) Transaction Queue
+
+Submission via L1's (arbitration chain) transaction queue, awaits the Sequencer's acquisition, and can be forcibly included in arbitration via L1's arbitration contract. The arbitration mechanism is as follows:
+
+1. The user submits the transaction to the transaction queue contract of L1's arbitration chain.
+2. The Sequencer commits to retrieving the transaction within a certain time (t) after entering the transaction queue contract.
+3. If the Sequencer fails to retrieve the transaction within time t, any user can initiate arbitration via the arbitration contract, demanding that the Sequencer provide a proof of transaction inclusion in a certain tx list accumulator.
+4. This accumulator proof can be verified on the arbitration chain. If the verification fails or the Sequencer fails to provide proof within the stipulated time (t2), the Sequencer will be penalized.
+
+Due to the presence of the above arbitration mechanism, cheating is sure to be caught, making it imperative for the Sequencer to provide reliable service.
+
 ## FAQ
 
 ### How is the execution order of transactions determined?

docs/website/pages/docs/tech-highlights/transaction_flow.zh-CN.mdx → docs/website/pages/docs/tech-highlights/transaction_flow.zh-CN.md

@@ -41,6 +41,57 @@
 2. 整个流程包含了 `Executor`,`Sequencer`,`Proposer`多个组件，但这些组件可能并不在同一个节点中，它们可能是远程 P2P 网络通信。这部分内容也会在后续的版本中更新。
 3. 以上的流程基于当前版本的设计来描述，并且部分逻辑尚未完全实现，未来会持续更新。
 
+## 交易包含
+
+Rooch 中有两种方式实现交易包含：
+
+1. 直接请求 Sequencer
+2. 通过 L1 提交
+
+*在 Rooch 支持多链结算，任意一条结算链均可实现交易包含*
+
+### 1. 直接请求 Sequencer
+
+用户可以直接请求 Sequencer 对交易进行包含，Sequencer 会将交易添加到 Accumulator 中，并立刻返回交易的全局顺序。
+这种包含是可仲裁的（通过仲裁链），但 Sequencer 可以不响应用户请求从而实现交易审查攻击。当用户发现交易无法被包含时，可通过第二种方式提交交易。
+
+### 2. 通过 L1 提交
+
+用户可以通过 L1 发起 L2 调用，等待 Sequencer 抓取并执行。这也是 L1 向 L2 发送消息的运行机制。
+该方式使得 Sequencer 无法隐蔽的实现审查交易，因为任何人都可以很容易发现 L1 上的合约调用与相关事件，以及 L2 上是否包含该交易的事实。
+因此，只要我们把这个链下验证过程重现在 L2 上，那么便可以复用 Optimistic Rollups 的欺诈证明实现对作恶 Sequencer 的惩罚。这需要：
+
+1. 我们在 Rooch 上用合约实现等同 Optimistic Rollups 安全假设（只需有一个诚实节点中继区块信息）的各 L1 的轻节点，为欺诈证明提供审计跟踪的凭据。
+2. 轻节点的可仲裁时效性承诺。打破“实现交易包含需要 L2 轻节点验证，L2 轻节点验证需要包含中继消息“的循环。
+3. 至少一个诚实的 verifier 对 Sequencer 提交的交易包含证明进行验证。
+
+仲裁核心流程如下：
+
+1. 用户可以通过 L1 发起 L2 调用，产生 L1ToL2 事件，时间为 t0。
+2. Sequencer 承诺 L1ToL2 事件产生后将在一定时间内（t1）生成相应的 L2 tx 并完成执行。
+3. Sequencer 承诺 L2 上的 L1 区块信息与 L1 当前时间的最大延迟为 t2。 t2 <= t1/2，以确保 Rooch 上的合约肯定有能力验证已经超时 t1 的 L1 的事件。
+4. Sequencer 承诺 L2 state commitment 提交的最大间隔为 t3。 t3 << t2，以确保 L2 上的 L1 区块信息更新 tx 的执行结果可用于仲裁，同时也意味着该结果可被 verifier 验证和挑战以确保区块信息的正确性。L1 合约会检查每次 state commitment 提交的间隔。
+5. 在任意结算链上的任意用户发现 Sequencer 在 t0+t1 时间内未完成交易，任意用户可在链下生成 L1ToL2 事件的存在证明(包含区块头）向仲裁链申请交易包含仲裁：
+
+当仲裁合约收到仲裁请求，首先对用户提供的存在证明进行基本形式验证：
+
+1. 需满足： 当前时间 - 区块时间 > t1，否则仲裁终止。
+2. 通过 merkle 树验证事件存在于区块中，否则仲裁终止。
+
+以上验证完成后，Sequencer 需在 t4 时间内提供存在证明否则被惩罚：
+
+1. 提供 L1 最新区块头信息，产生该区块头信息的 L2 tx，该 tx 的累加器证明 （此证据会在合约中保存一个挑战期，以供 verifier 验证结果，避免 Sequencer 提供伪证。此步骤不在本仲裁合约内，但为本合约的正确执行提供了保障，它属于 verifier 的验证工作的一部份。）。
+2. 若最新区块头的区块时间不满足 t2，惩罚 Sequencer，挑战终止。用户后续可每隔 t1 时间持续性发起同一交易的包含仲裁，Sequencer 的不作为将面临逐步加重的惩罚[^1]。 
+3. 提供该 L1ToL2 事件所在区块高度的区块头，产生该区块头信息的 L2 tx，该 tx 的累加器证明 （此证据会在合约中保存一个挑战期）。
+4. 若 3 中提供的区块头与用户证据不一致，仲裁终止。（若 Sequencer 提供伪证，会被 verifier 发现。）
+6. 至此，L2 和用户均承认该 L1ToL2 事件已经产生，接下来验证 L2 在规定时间内包含了该事件。
+7. 提供该事件包含的 L2 tx 的累加器证明。
+8. 仲裁合约验证累加器证明及其是否满足 t1 承诺（累加器的根作为 L2 state 的一部份会携带提交时 L2 记录的最新 L1 的区块头信息一并提交至 L1），若验证失败，惩罚 Sequencer。
+
+* t1：24 小时
+* t2：8 小时
+* t4: 2 小时
+
 ## FAQ
 
 ### 交易的执行顺序是怎么确定的？
@@ -59,4 +110,8 @@ Rooch 中没有交易池的概念，交易的执行结果是即时确定的，
 
 总结一下：
 
-在 Rooch 中，应用和开发者可以认为交易是即时确定的，它的安全依赖于一套反激励机制，并且已经在区块链中广泛使用。当然，反激励机制的网络需要逐渐构建，用户和开发者都需要参与进来。
+在 Rooch 中，应用和开发者可以认为交易是即时确定的，它的安全依赖于一套反激励机制，并且已经在区块链中广泛使用。当然，反激励机制的网络需要逐渐构建，用户和开发者都需要参与进来。
+
+[^1]: 最终 Sequencer 将被 L1 合约拒绝更新状态。该惩罚机制的目的是防止 Sequencer 作恶，但也会导致 Sequencer 无法提供服务。
+这需要 Sequencer 轮转机制配合，恶意 Sequencer 节点被强制替换为新的节点。
+完善的 Sequencer 节点的替换依赖 Rooch 生态的蓬勃发展，因此这将在 Rooch 的下一阶段中被引入。