docs(multi-chain): update multi-chain-settlement with content from th…

…e latest cross-layer communications article (#848)

Co-authored-by: popcnt-subodhi <subodhi@west>

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

@@ -20,7 +20,7 @@ The core difference between the arbitration/settlement chain in L2 to L1 messagi
 1. The user initiates the L2 to L1 request by calling the `call_remote` function in `l2_stub` with the following parameters.
     1. `action`: coded information about the contract call on L1
 
-2. `l1_stub` will call the `send_l2_to_l1` function in `rooch_transport` to complete the logging of events on L2, with the following parameters:
+2. `l2_stub` will call the `send_l2_to_l1` function in `rooch_transport` to complete the logging of events on L2, with the following parameters:
     1. `msg_sequence
     2. `msg_sender
     3. `action`
@@ -66,6 +66,6 @@ For the arbitration chain, we already have a complete fraud proof mechanism, and
 In order for the settlement chain to be equivalent to the arbitration chain, we need to construct consistent causality, which for the settlement chain implies the following preconditions:
 
 1. the same media completion result record: the proposer needs to record the L2 output in the settlement chain
+![Multi-chain Proposer](/docs/rooch-multi-chain-settlement-l2-to-l1.svg)
 2. the same observer to verify the result record: through the L1 light node on the L2 to complete the L1 result record in the L2 confirmation, to realize the verifier's observation.
-
-Translated with www.DeepL.com/Translator (free version)
+![Multi-chain State Verification](/docs/rooch-multi-chain-settlement-l2-to-l1-flow.svg)

docs/website/pages/docs/tech-highlights/l2_to_l1_messaging.zh-CN.mdx

@@ -20,7 +20,7 @@ Rooch 具备多链资产结算的能力，对于不同角色的 L1 (仲裁链/
 1. 用户通过调用 `l2_stub` 中的 `call_remote` 函数发起 L2 to L1 请求，所需参数包括:
     1. `action`: 编码后的 L1 上的合约调用信息
 
-2. `l1_stub` 将调用 `rooch_transport` 的 `send_l2_to_l1` 函数完成 L2 上的事件记录，参数包括：
+2. `l2_stub` 将调用 `rooch_transport` 的 `send_l2_to_l1` 函数完成 L2 上的事件记录，参数包括：
    1. `msg_sequence`
    2. `msg_sender`
    3. `action`
@@ -66,5 +66,7 @@ Rooch 具备多链资产结算的能力，对于不同角色的 L1 (仲裁链/
 为让结算链与仲裁链等效，我们需要构建一致的因果关系，对于结算链，则意味着如下前置条件：
 
 1. 相同媒介完成结果记录：proposer 需要在结算链上记录 L2 output
+![Multi-chain Proposer](/docs/rooch-multi-chain-settlement-l2-to-l1.svg)
 2. 相同的观察者验证结果记录：通过 L2 上的 L1 轻节点完成 L1 结果记录在 L2 的确认，实现 verifier 的观察。
+![Multi-chain State Verification](/docs/rooch-multi-chain-settlement-l2-to-l1-flow.svg)
 

docs/website/pages/docs/tech-highlights/multi-chain-settlement.en-US.mdx

@@ -1,39 +1,50 @@
 # Multi-chain Settlement
 
-Multi-chain Settlement is one of the most crucial functions of the Rooch Network. This chapter provides a brief introduction to the protocol and the challenges to be addressed.
+Multi-chain settlement is one of the most important features of Rooch Network. How to realize multi-chain communication while maintaining the L2 security assumption (only one honest verifier node is needed) is its core problem, in this article we will briefly introduce the workflow and principles.
 
 ## How it works
 
 import Image from "next/image";
 
 <Image
-  src="/docs/multi-chain-settlement.jpg"
-  alt="Rooch Architecture"
-  width={600}
-  height={600}
-  className="mx-auto my-4"
+    src="/docs/rooch-multi-chain-settlement-withdrawal-flow.jpeg"
+    alt="Rooch Multi-chain Settlement Withdrawal Flow"
+    width={700}
+    height={390}
+    className="mx-auto my-4"
 />
 
-The responsibility of the settlement layer is to perform state migration and asset settlement between Layer1 and the execution layer.
+Let's illustrate how multi-chain settlement works by taking the most complex and well-attended withdrawal transaction as an example.
 
-We use Ethereum as an example to explain how the settlement layer works.
+For any L1 (settlement chain/arbitration chain), the withdrawal process is the same for the user:
 
-Rooch deploys the settlement smart contract(`State Commitment Chain` & `Bridge`) on Ethereum, which maintains an off-chain state tree, with only the root of the state tree recorded on the chain, through which users migrate state between Layer1 and Rooch.
+1. Initialization transaction (step 1 in the figure): the user initiates a withdrawal request at L2.
+2. Proof transaction (step 4 in the figure): the user submits a proof of withdrawal at L1, and the withdrawal transaction is verified by the state commitment submitted by L2 to L1.
+3. Finalize the transaction (step 5 in the figure): the user submits a finalizing of the withdrawal transaction at L1, and L1 releases the assets after verifying and confirming the end of the challenge period.
 
-1. When a user migrates state from Layer1 to Rooch, the state appears in the state tree of Rooch after the transactions in Layer1 are finalized.
-2. When a user migrates state from Rooch to Layer1, the state is first locked and waits for the Layer2 (Challenge period to pass or **zkProver** provides valid proof) before being moved out of the state tree for settlement.
-3. When the `State Commitment Chain` receives a notification from the arbitration contract that fraud has occurred, it rolls back the root of the off-chain state tree to before the fraud occurred, discarding any state tree changes made during that period.
+These three steps are all initiated by the user, which maximizes flexibility and makes the prerequisites for L2 to work correctly very clear:
 
-Now, if we wish to extend the settlement layer to multiple chains, the biggest challenge we face is how to confirm the status of Rooch on non-arbitration chains.
+1. state commitment is guaranteed to be validated on L1
+2. only one honest verification node is needed to confirm the L2 state on the arbitration chain.
 
-Our solution packages the withdrawal proofs on the settlement chain into Rooch transactions, thus inheriting the security of the second-layer network. This can be achieved by running the corresponding chain's client in the Rooch network and performing native block parsing.
+For non-arbitrated chains, conditions 1 and 2 are not directly satisfied, since arbitrated chains cannot acknowledge messages from other chains. To solve this problem, we need a decentralized relay service that relays messages from the non-arbitration chain (Condition 1) to L2, and then confirms L2's state commitment to the arbitration chain through L2's state commitment to the arbitration chain.
+At the same time, in order to verify condition 1, we also need to relay the block information of L1. For the non-arbitration chain, the prerequisites is as follows:
 
-After the challenge period has passed, we believe that assets can be securely released on the settlement chain.
+a. In L2, each L1 light node is realized by contract, and the block data can be relayed by any person. Only one honest relay node is needed to guarantee correctness (light_client in the diagram).
+b. State commitment is guaranteed to be validated on L1 by relay node and condition a (step 3, 4.1 4.2 in the figure)
+c. Only one honest verification node is needed to confirm the L2 state on the arbitration chain (step 5 in the figure).
 
+In short, we construct the L2 -> L1 -> L2 message validation mechanism so that any L1 is protected by the security of the arbitration chain.
 
 ## Features
 
-Here are why Rooch's Multi-Chain Settlement solution is more advanced.
+- More secure: Compared to cross-chain bridges that rely on a central organization, Rooch multi-chain settlement is as secure as Rollups.
+- More generic: Generic state migration enables secure movement of Token, NFT, digital contract, etc. (any message).
 
-- Multi-chain settlement is more secure. The security of the cross-layer bridge in a multi-chain settlement solution is protected by the arbitration layer (i.e. Ethereum), and the execution layer inherits the security of the arbitration layer.
-- More generic cross-layer solution. In Rooch's multi-chain settlement solution, cross-layer is achieved through a generic state migration pattern where states can be used to represent Token, NFT, digital contracts, and other future application states, without the need to design specialized protocols for new state types.
+## Further Reading
+
+For more information on how Rooch implements transaction inclusion in a multi-chain system, see → [Transaction Flow](/docs/tech-highlights/transaction_flow)
+
+For more information on how Rooch implements generic L1 to L2 messaging in a multichain system, see → [L1 to L2 Messaging](/docs/tech-highlights/l1_to_l2_messaging)
+
+For more information on how Rooch implements generic L2 to L1 messaging in multichain systems, see → [L2 to L1 Messaging](/docs/tech-highlights/l2_to_l1_messaging).

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

@@ -1,42 +1,53 @@
 # 多链结算
 
-多链结算是 Rooch Network 最重要的功能之一。本章简要介绍了协议和要解决的挑战。
+多链结算是 Rooch Network 最重要的功能之一。如何在保持 L2 安全假设（仅需一个诚实的验证节点）的同时实现多链通信是其核心问题，在本文中我们将简要介绍工作流程和原理。
 
 ## 它如何工作
 
 import Image from "next/image";
 
 <Image
-  src="/docs/multi-chain-settlement.jpg"
-  alt="Rooch Architecture"
-  width={600}
-  height={600}
+  src="/docs/rooch-multi-chain-settlement-withdrawal-flow.jpeg"
+  alt="Rooch Multi-chain Settlement Withdrawal Flow"
+  width={700}
+  height={390}
   className="mx-auto my-4"
 />
 
-结算层的职责是在 Layer1 和执行层之间进行状态迁移和资产结算。
+让我们以最复杂也是最受人关注的提款交易为例来说明多链结算是如何工作的。
 
-我们以以太坊为例来说明结算层是如何工作的。
+对于任意 L1 (结算链/仲裁链) ，对于用户来说，其提款流程一致：
 
-Rooch 在以太坊上部署了结算智能合约（`状态承诺链（State Commitment Chain）`和`桥（Bridge）`），维护着一棵链下状态树，链上只记录状态树的根，用户通过它在 Layer1 和 Rooch 之间迁移状态。
+1. 初始化交易（图中步骤 1）：由用户在 L2 发起提款请求。
+2. 证明交易（图中步骤 4）：由用户在 L1 提交提款证明，通过 L2 向 L1 提交的 state commitment 验证提款交易。
+3. 确认交易（图中步骤 5）：由用户在 L1 提交提款交易确认，L1 在验证并确认挑战期结束后释放资产。
 
-1. 当用户将状态从 Layer1 迁移到 Rooch 时，该状态会在 Layer1 中的交易完成后出现在 Rooch 的状态树中。
-2. 当用户从 Rooch 迁移状态到 Layer1 时，状态首先被锁定，等待 Layer2 完成（挑战期结束或 **zkProver** 提供有效证明），然后移出状态树进行结算。
-3. 当`状态承诺链`从仲裁合约收到欺诈发生的通知时，它会将链下状态树的根回滚到欺诈发生之前，并丢弃在此期间所做的任何状态树更改。
+这三步操作均由用户发起，实现了最大的灵活性，也使得 L2 正确工作的前提条件变得非常清晰：
 
-现在，如果我们要把结算层扩展到多条链上，遇到的最大挑战是如何在非仲裁链上确认 Rooch 的状态。
+1. 保证 state commitment 在 L1 上被确认
+2. 仅需一个诚实的验证节点即可在仲裁链上确认 L2 状态
 
-我们的解决方案将结算链上的提款证明打包成 Rooch 交易从而继承二层网络的安全性。这一点可以通过在 Rooch 网络中运行相应链的客户端，并进行原生区块解析实现。
+对于非仲裁链来说，条件1 与 条件2 无法直接满足，因为仲裁链无法确认来自其他链的消息。为了解决这个问题，我们需要在一个去中心化的中继服务，将非仲裁链的信息（条件1）中继到 L2, 再通过 L2 向仲裁链提交的 state commitment
+完成条件2。同时，为了验证条件1，我们还需要这个中继 L1 的区块信息。那么对于非仲裁链来说，其前提如下：
 
-在挑战期过后，我们认为资产可以安全的在结算链上被释放。
+a. 在 L2 中通过合约实现各 L1 轻节点, 区块数据可由任意人中继。仅需要一个诚实的中继节点即可保证正确性（图中 light_client）
+b. 通过中继节点和 条件a 保证 state commitment 在 L1 上被确认 (图中步骤3，4.1 4.2)
+c. 仅需要一个诚实的验证节点即可在仲裁链上确认 L2 状态 (图中步骤5)
+
+简而言之，我们构建了 L2 -> L1 -> L2 的消息确认机制，从而使得任意 L1 接受仲裁链的安全性保护。
 
 ## 特性
 
-这就是为什么 Rooch 的多链结算解决方案更先进的原因。
+- 更安全: 相比依赖中心组织的跨链桥，Rooch 多链结算与 Rollups 方案安全性无异。
+- 更通用: 通用的状态迁移使得 Token、NFT、数字合约等（任意消息）安全移动。
+
+## 进一步阅读
+
+关于 Rooch 如何在多链系统中实现交易包含，可参考 →  [Transaction Flow](/docs/tech-highlights/transaction_flow) 
+
+关于 Rooch 如何在多链系统中实现通用 L1 至 L2 消息传递，可参考 →  [L1 to L2 Messaging](/docs/tech-highlights/l1_to_l2_messaging) 
 
-- 多链结算更安全。多链结算方案中跨层桥（cross-layer bridge）的安全性由仲裁层（即以太坊）保护，执行层继承仲裁层的安全性。
-- 更通用的跨层解决方案。在 Rooch 的多链结算方案中，跨层是通过一种通用的状态迁移模式实现的，状态可以用来表示 Token、NFT、数字合约等未来的应用状态，而无需为新的状态类型设计专门的协议。
+关于 Rooch 如何在多链系统中实现通用 L2 至 L1 消息传递，可参考 →  [L2 to L1 Messaging](/docs/tech-highlights/l2_to_l1_messaging) 
 
-## 原生桥