docs(multi-chain): clear distinction between settlement and arbitrati…

…on chains (#859)

no more non-arbitration chain

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

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

@@ -27,8 +27,10 @@ These three steps are all initiated by the user, which maximizes flexibility and
 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.
 
-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:
+In Rooch terminology, a settlement chain refers to a chain that establishes message communication with Rooch but does not provide arbitration services, and an arbitration chain refers to a chain that provides arbitration services on top of the functions of a settlement chain.
+
+For settlement 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 settlement 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 settlement chain, the prerequisites is as follows:
 
 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)

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

@@ -27,8 +27,10 @@ import Image from "next/image";
 1. 保证 state commitment 在 L1 上被确认
 2. 仅需一个诚实的验证节点即可在仲裁链上确认 L2 状态
 
-对于非仲裁链来说，条件1 与 条件2 无法直接满足，因为仲裁链无法确认来自其他链的消息。为了解决这个问题，我们需要在一个去中心化的中继服务，将非仲裁链的信息（条件1）中继到 L2, 再通过 L2 向仲裁链提交的 state commitment
-完成条件2。同时，为了验证条件1，我们还需要这个中继 L1 的区块信息。那么对于非仲裁链来说，其前提如下：
+在 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)