大家好，又见面了，我是你们的朋友全栈君。

简介

• Arbitrum是OffchainLabs 团队开发的以太坊Layer2层扩容方案，可以实现高吞吐量，让开发者以低成本部署、运营智能合约，同时可以保持无需信任的安全性。
• Rollup技术力求将所有交易数据记录在主链上，核心理念是将原本散布在区块中的大量交易数据，聚合压缩成一笔交易，发布到主链上；而合约的实际计算和存储在链下完成。这样就让主链的运算和存储压力降低，从而实现网络的高吞吐量。
• 将合约从以太坊移植到 Arbitrum 既快速又简单；无需更改任何代码或下载任何新软件。就像以太坊一样，Arbitrum 完全支持 EVM。这意味着所有适用于以太坊的智能合约语言（例如所有版本的 Solidity、Vyper Yul）也可以原生地适用于 Arbitrum。有关详细的兼容性信息，请参阅Solidity 支持。同样，所有标准的以太坊前端工具（例如 Truffle、Hardhat、The Graph、ethers.js）也可以与 Arbitrum 原生配合使用。有关更多详细信息，请参阅前端集成。并且原生支持所有以太坊工具。
• 尽管开发人员和用户不需要下载任何自定义软件来部署合约并与 Arbitrum Rollup 链交互，但一些用户可能希望自己验证链。使用 Arbitrum Rollup 时，任何诚实的用户都可以保证系统正确运行，从而保证您的安全。验证 Arbitrum 链是完全无需许可的；您需要做的就是下载 Arbitrum Validator 节点软件并将您的节点指向链。要发布或对断言提出异议，您只需放置一个赌注，您将在索赔解决后取回（假设您诚实行事）。
• 简而言之，Arbitrum 使您能够以本地使用以太坊的一小部分成本与您进行交互和部署智能合约，并使用您今天用来与以太坊交互的所有相同工具，而不会影响安全性或去中心化。使用该链不需要定制工具，但任何人都可以选择验证该链。

事务调用生命周期

在用户认为交易被确认之前，交易经历了许多不同的阶段，从保证交易顺序开始，到保证交易执行结束。我们从用户将交易提交给定序器（可能通过另一个节点转发）的那一点开始。

• A） sequencer 定序器已经下单并确认了交易，但还没有批量发布到L1链上。在这个阶段，如果用户愿意信任定序器，则交易可以被认为是最终的，但是恶意的定序器可能会破坏这种最终性。在未来，我们计划通过绑定和削减来增加一层加密经济安全性，以惩罚模棱两可和违反这种信任的测序仪。

• B)排序器在 L1 链上发布了包含交易的批次。在这一点上，sequencer 没有特殊的权力（假设批次没有从 L1 链中重组）并且根本不再需要被信任。对于不想依赖于信任排序器的用户，他们的交易现在与包含它的 L1 批量交易一样得到确认。

  一旦保证了排序，假设任何一个诚实的验证者都会强制协议正确执行，那么交易的结果就得到了充分的保证。

• C)验证者创建断言，断言用户交易的结果；请注意，验证者无权审查/排除您的交易（即，他们被迫包含队列中的下一个交易）并且无权重新排序。其他验证者也可以对该断言进行质押。此时，如果用户至少信任任何一个验证者（或者自己是验证者），则可以认为该交易是完全可信的。

• D) 7 天的挑战期结束，断言得到确认。此时交易结果完全锁定在 L1 链上。

ArbGas / 费用

• ArbGas 的操作原理与以太坊 gas 类似，用于衡量 Arbitrum 链上的计算成本。
• 然而，Arbitrum 链没有一个硬性的 ArbGas limit 要求，并且 ArbGas 消耗得比以太坊 gas 要快得多。
• ArbGas 的一个关键作用是为验证计算结果所需的时间提供一个可预测的度量。
• 每一个 rollup 区块内都包含一个关于链上 ArbGas 消耗总量的声明，这意味着当前区块的声明与前一个区块的声明之间的差异应该是当前区块消耗了多少 ArbGas 的有效指标。
• 通过这种方式，检查区块有效性时，验证者可以将他们的 gas limit 设置为这个值，如果这些 ArbGas 在区块完成执行前就耗尽了，那么就可以确定这是一个无效区块，并成功挑战了该无效区块。
• 用户在向链提交交易时，会被收取费用。
• 如果用户将他们的交易发送给一个聚合器，那么一部分费用将自动支付给这个聚合器。
• 剩余的费用将被发送到网络费用池，用于支付确保整条链安全运行的服务费。
• 费用还包含 L2 交易、L1 数据调用、计算以及存储成本。
• 费用以 ETH 的形式支付。

吞吐量

• 由于所有 Arbitrum 交易数据都发布到以太坊，因此每笔交易的成本以及 Arbitrum 每秒可以支持的交易数量受到在此期间可以发布到以太坊的数据量的限制。出于这个原因，优化交易压缩以最大限度地减少需要在链上发布的内容对于降低成本和提高吞吐量至关重要。
• 对于不携带自己的通话数据的简单转账交易，我们的基准测试表明，Arbitrum 将允许每秒最多 4,500 笔转账交易

跨合约通信

• 区分从以太坊到 Arbitrum 的调用和从 Arbitrum 到以太坊的调用很重要。以太坊合约可以将交易发送到快速到达的 Arbitrum。然而，从 Arbitrum 到以太坊的一般交易速度较慢，因为它们需要等待挑战期到期才能被确认。幸运的是，有一些优雅的解决方案可以让用户快速将可替代资产从 Arbitrum 提取到以太坊

Arbitrum虚拟机

• 尽管 Arbitrum 支持 EVM，但它在底层运行的是 Arbitrum 虚拟机 (AVM)。AVM 永远不会暴露给开发人员或用户，所以如果您只是对如何使用 Arbitrum 感兴趣，您可以放心地忽略它。但是，如果您对 Arbitrum 的内部工作原理以及它如何实现可扩展性感到好奇，请继续阅读下面的AVN设计原理

  AVM设计原理：

1. AVM 设计的起点是以太坊虚拟机 (EVM)。因为 Arbitrum 旨在高效执行为 EVM 编写或编译的程序，所以 Arbitrum 使用 EVM 的许多方面都没有改变。例如，AVM 采用 EVM 的基本整数数据类型（256 位大端无符号整数），以及对 EVM 整数进行操作的指令。
2. AVM 和 EVM 之间的差异是由 Arbitrum 的第 2 层协议的需求和 Arbitrum 使用多轮挑战协议来解决争议的
3. 详情查看：AVM design rationale · Offchain Labs Dev Center

ArbOS

ArbOS 是 Arbitrum 操作系统，位于 AVM 之上，负责将不受信任的合约相互隔离，使用ArbGas跟踪和限制它们的资源使用，并管理向用户收取费用以资助链的运营的经济模型验证器。ArbOS 通过将在 L1 智能合约中完成的工作卸载到更便宜的 L2 代码中，为 Arbitrum 提供了极大的灵活性。要了解更多信息，请参阅ArbOS部分。

L1和L2使用流程上的区别：

• L1-L2 Deposit 大概10分钟

• L2-L1 withdraw需要8天  

• L2-L2 tranfer 秒级别

为什么需要8天，因为为了安全基本要求；它确保验证者有足够的时间与链同步以在需要时发出争议。换句话说，由于我们没有在 L1 验证交易，我们需要给 L2 时间来检测和证明欺诈行为（就是利用这8天得时间检测你得所有交易记录的流水，确保你得账本是没问题的，然后在发布到L1链上同步数据）  

如何把L1的钱换到L2

• 第一种在Arbitrum官方bridge进行Deposit    

1.  具体地址：Arbitrum Bridge （支持测试网络，和正式网络）    

• 第二种在其他跨链Bridge进行兑换                                                                                              

1. cbridge : The Best Crypto & Binance Bridge | cBridge (暂不支持测试网)                               

2.  multichain: https://app.multichain.org/#/router (暂不支持测试网)  

开发安全注意事项和陷阱（开发必看）

希望在 Arbitrum 上构建的以太坊 dApp 开发人员通常会发现经验、工具和协议原理非常熟悉；也就是说，开发人员应该注意一些重要的考虑因素和“陷阱”。对于许多智能合约应用程序，以下内容均不适用，但建议开发人员进行调查

• 不同的 EVM/Soldity 行为：Arbitrum 支持每个 EVM 操作码，这意味着您编写的任何 Solidity（或 Vyper、Yuul 等）都将在 Arbitrum 上编译和运行。但是，某些操作在 Arbitrum 上的行为与在 Ethereum 上的行为不同；如需完整列表，请参阅Solidity 支持。此外，Arbitrum 支持大多数（但不是全部）以太坊预编译。
• 带有块号和时间戳的时序假设：人们可能在第 1 层做出的时序假设block.timestamp（block.number即平均每 15 秒将产生一个新块）不会在 Arbitrum 上成立。新“L2 块”的产生/描绘的速率是不可靠预测的；block.timestamp是在 Arbitrum 上测量时间的更好方法，但即便如此，仅应在较大的时间范围内完成依赖 L2block.timestamp或L2 来测量时间。block.number有关更多信息，请参阅块编号和时间
• L1-to-L2 Transactions’ Address Aliases ：“可重试票证”是一种特殊的交易类型，用于从 L1 向 L2 发送消息；如果您打算使用它们，强烈建议您在部署到主网上之前阅读他们的文档并仔细测试您的合约的行为。特别注意：在接收方的 L2 消息中，msg.sender不是返回 L1 合约，而是返回地址别名
• L1-to-L2 交易的票证创建失败：如果您在尝试创建可重试票证时少付了基本提交费用，那么尽管确认了 L1 交易，但不会在 L2 上创建票证；这可能——取决于你的跨链应用程序正在做什么——非常糟糕。当前基础提交费用可直接从仲裁节点查询，每 24 小时更新一次；对于给定的更新，它最多可以增加其先前值的 50%。您多付的任何金额都不会丢失；它将在您指定的 L2 地址收集。为了安全起见，我们强烈建议您多付钱。（在未来的版本中，基础提交成本将直接在 L1 上收集，完全避免上述故障模式。）
• 硬编码气体值：ArbGas的计价方式与以太坊 L1 气体不同；因此，如果在未修改的情况下部署到 L2，则在 L1 上工作的具有硬编码值的合约可能会中断；应该调整硬编码的气体值（或者更好的是，如果可能的话，完全删除（这可能是可能的；真的，你为什么要对气体值进行硬编码？））
• ETH 存款特殊行为：可重试票据以一种特殊的方式利用来处理从 L1 到 Arbitrum 的 ETH 存款；如果您的应用程序将直接使用 Ether 存款，则值得了解其设计细节。此外，无需在 L2 上发布已签名交易即可将 Ether 记入 L2 帐户的能力会产生一些 L1 上不可能的行为，即无需触发其接收回退功能即可将 Ether 记入合同的能力。
• 随机性的块散列：不应依赖 Arbitrum 的 L2 块散列作为随机性的安全来源。

如果有遇到不懂得或者有疑问欢迎联系本人进行交流

WC：luo425116243