web3基于OP_Rollup的L2扩容方案-Arbitrum
业务模型
价值：arbitrum对于用户来说的核心价值是交易速度、更低的gas费用、欺诈证明技术保证L2层交易具备L1层的安全性。
L2层的网络具备兼容L1层所有应用的特点，任何L1层的应用都可以拓展到L2层，包括普通的消息调用、治理、代币交易等。
Arbitrum整体业务流转包括三个部分：
- 部署启动Transaction fees (TXFEES) = L2 Gas Price (P) * Gas Limit (G)
- L2层交易处理
- L1层业务结算
项目部署启动
目前大多数项目基本遵循的是跨链中的Lock/Mint和Burn/Unlock模式。在L1上和L2上分别部署一套应用，在L1上锁定资产，在L2上进行等量铸造，或者在L2上销毁再到L1上进行解锁。通过跨链的模式完成资产在L1上和L2上的流动。
Arbitrum Fundation的ARB也是符合上述模式，但只是在L2上发行桥接到L1上使用。与跨链桥不同的是，本身Arbirum的安全性基本是与L1等价的，只是作为L1层的拓展，并不像跨链具有不同的共识或者安全性假设。因此，L2上的资产与L1上的资产是等价的，其流动不需要通过交易所，而是直接进行桥接。
Arbitrum的桥接规范中，有三类合约：
- 资产合约（Asset），代币合约本身
- 网关合约（Gateways），实现特定类型的跨链资产桥接
- 路由合约（GatewayRouters)，为每一种资产进行路由到指定网关合约
L1到L2之间的代币转账都是开始于L1的路由合约发起对资产的L1的网关合约的deposit调用，再由L1的网管合约发起对L2的网管合约的调用完成。反之亦然。
| L1到L2 | L2到L1 |
 |  |
L2层交易处理流程
基本处理流程如下：
接收交易
在L2层的交易通常是被排序器（Sequencer）接收，通常有两种方式发送交易：
- 客户端使用钱包链下直接发送给排序器，针对的是经典的纯L2网络的交易（如直接使用L2的原生DAPP）
- 通过延迟队列（Delayed Inbox），客户端通过钱包直接发送交易到L1层的延迟队列中。通常被用于通过桥deposit ETH或代币。
排序
排序主要有排序器负责
- 将延迟队列的交易和本地收到的L2交易排序，并预执行返回给用户一个即时的收据
- 推送排序好的batch到L1上，以便验证者验证，并推送给验证者交易batch
验证者（Validator）断言
验证者执行交易batch生成L2区块，并向L1发起的断言，通常的断言包含很多L2区块组成的一个摘要信息，供merkel proof验证的root，和相关挑战的执行过程证明信息
L1层业务结算
结算比较简单，和跨链交易的目的链执行过程类似。通过被确认的断言内包含的root，用户提供提款L2交易到L1交易发生的一个Merkel proof，即能够完成结算。
跨L1、L2消息
跨链消息分为两类，L1 → L2，L2 → L1，两种交易的处理方式也不一样
1、L1 → L2消息
Retryable Tickets：arbitrum上规范的发起L1到L2消息的方式，通常被用来执行L1到L2的deposit操作，其提交和执行是异步完成。同时，也能用于强制让L2执行任何消息，因为直接发给排序器的消息可能会被审查而忽略掉。
可以保证跨链消息的原子性，如果L1消息提交成功，则最终能够有很强的保证其在L2能够执行成功。
生命周期：
 | 创建Ticket（L1上执行）
|
 | 自动兑换（L2上执行） 由于消息的提交和执行是异步的，成功的Retryable Tickets并不能保证L2上一定能执行成功。当Tickets创建成功后，排序器将会尝试在L2上执行，会检查L2的账户余额是否大于maxFeePerGas * gasLimit 且 maxFeePerGas >L2Basefee（和L1的计费方式一样），可能会产生两种结果：
手动兑换（L2上执行） 任何人都能够通过调用L2上的预编译合约方法ArbRetryableTx尝试手动在L2上执行Ticket未完成的执行，并且会捐赠一定的gas费用来进行下一次尝试执行。 通常，如果在7天内还是没有被执行成功，Ticket将会超时被自动丢弃，除非用户未Ticket再次付费让排序器再次为其保留7天，只要用户一直在超时前付费则Ticket能够一直保留下去 |
2、L2 → L1消息
这类型的消息主要用于L2到L1 withdraw，由于有L1的欺诈证明作为安全性保证，任何被定序后的不执行操作，都会被认为是作恶，很容易在挑战中被发现。只可能在定序前被排序器拒绝的情况，这种情况也可已通过向L1的延迟队列中发送交易让排序器强制执行解决。
此类型消息与L1结算消息是相同的。
预编译合约：如从L1上发起的消息是通过合约完成的。而从L2上发起向L1的提款消息，在Arbitrum中不是普通的合约，而是部署在Arbitrum上的预编译合约，完成Arbitrum系统层面的一些特定工作。
Gas费&提交费用
提交费用（submission fee）：L1到L2消息的提交费，使用ETH未使用ARB。
用户支付的费用：
- 提交到L1的calldata的存储费用，即定序时将L2交易压缩上传的费用（通过brotli-zero算法压缩），该部分钱会被发送到一个特殊地址L1PricerFundsPool上，专门用来支付L1的存储费用。
- 使用L2网络资源的费用：包括执行、存储、其他L2层节点提供服务的费用（L2上Gas费），此部分与以太坊go-geth客户端计费一致。
计算方式为：
Transaction fees (TXFEES) = L2 Gas Price (P) * Gas Limit (G)
Gas Limit (G) = Gas used on L2 (L2G) + Extra Buffer for L1 cost (B)
Extra Buffer (B) = L1 Estimated Cost (L1C) / L2 Gas Price (P)
L1 Estimated Cost (L1C) = L1 price per byte of data (L1P) * Size of data to be posted in bytes (L1S)
其中，L1P时在L2上预估的当前L1上存储每个字节的gas价格，该值随着L1动态波动；L1S即是压缩过后的存储空间。
L2上统一收取Gas费：经过上述的两部分计算，得到一个最终的Transaction fees (TXFEES) 费用，在L2层统一结算。由于在L1层的EOA账户将会直接在L2层创建相同的地址作为L2的EOA账户。因此，结算gas费也是使用相同的EOA地址，使用ETH结算，并未使用ARB代币。
代币
2023年3月Arbitrum Foundation开始空投治理代币ARB，ARB代币目前只作为DAO治理使用，不作为gas计费使用。目前已经将L2主网（包括Arbitrum Rollup和AnyTrust）过渡到DAO阶段。
缺点：由于目前ARB不用来支付L1和L2的消息，虽然ARB是标准的ERC20代币，但是只是通过治理来影响Arbitrum生态，其价值很难与Arbitrum的生态绑定，只是起到了DAO的作用，
Arbitrum治理
| arbitrum治理目前包含两个部分：
| 提案生命周期 |
排序器
目前Arbitrum官方提供的排序器依然是中心化的，但是去中心化的方案正在DAO组织的讨论当中
Tips：目前在官方提供的排序器中，优先使用FIFO的方式进行排序。因此，用户只需要支付一个basefee而不用考虑小费。