1 opBNB 简介

1.1 什么是 opBNB？

opBNB 网络是 BNB 智能链的 Layer 2 扩展解决方案，由 Optimism OP Stack 的 bedrock 版本[1]提供支持，其原理在于将交易处理和资源利用从 BNB 智能链分流，同时将数据发布到底层主网上。用户可以通过将资金从 BSC 存入 opBNB，并在 opBNB 上使用应用程序和合约进行交互。接着，序列化器聚合交易、计算状态转换，并将其提交至 BSC 上的 Rollup 合约。证明生成器能够生成密码学证明，证明这些状态转换的有效性，验证者将检查这些证明以验证 opBNB 状态的正确性。opBNB 的核心是允许用户以高吞吐量和低费用存取资金、使用智能合约以及查看网络数据。通过充分利用 Layer 2 技术，opBNB 能够超越 BNB 智能链的限制，为用户提供更出色的体验。

• 容量可以达到每秒 > 100m Gas，这比以太坊上的其他 Layer 2 解决方案要高得多。
• 转账 Gas 费平均可低至 0.005 美元。
• 出块时间为 1 秒。

1.2 为什么 BSC 需要 opBNB？

Layer 1 网络是提供数据传输和验证基础设施的基础网络，例如 BSC 和以太坊。这些网络在高峰期面临网络拥塞的挑战，通常会发生在任何热门应用程序运行促销活动或流量激增时。网络拥塞可能导致高交易费用、交易缓慢和用户体验不佳。

为了克服这些挑战，Layer 1 网络需要提高其可扩展性，即处理更多交易而不影响安全性的能力。例如，2021 年，BSC 在 BNB 智能链上有一个 Web3 游戏，每天生成超过 800 万笔交易[2]。

在这种使用情况下，BSC 的吞吐能力显然会被大大超过，导致交易速度减慢、交易最终确认延迟以及游戏玩家和其他 dApp 用户的不佳体验。

每日 Gas 费用可能潜在地上涨到超过 6,800 BNB（价值 300 万美元），这将对游戏的可用性和可持续性造成重大障碍。

如此大规模的 dApp 所带来的巨大交易负载似乎难以在 BSC 的当前形态下有效处理。为了支持这样的 dApp，需要进行重大优化和扩展解决方案，以避免网络性能下降和不合理高成本。

2 opBNB 与其他网络的比较

2.1 opBNB VS other Layer1 Networks

opBNB 的目标是为 BSC 上高活跃应用程序，如 DeFi、NFT 和游戏，提供网络拥塞问题的扩展解决方案。opBNB 基于 OP Stack，并通过优化挖矿流程和缓存数据访问，实现了每秒 100M Gas 的吞吐能力，远高于 BSC。

2.2 opBNB VS other Layer2 Networks

与以太坊上的其他 Layer 2 解决方案，如 OP Mainnet 和 Arbitrum 相比，opBNB 具有较低的 Gas 费用和更高的区块 Gas 限制，这意味着当 Layer 2 的交易量增加时，Gas 费用将更加稳定。以下列出了以太坊 EIP-1559 参数以供参考。

2.2.1 Gas 参数差异

2.2.2 指标差异

3 opBNB 安全最佳实践

3.1 Solidity 最佳安全实践

在 opBNB 上开发几乎与直接在 BNB 智能链上构建相同。opBNB 使用 EVM 执行引擎，这意味着去中心化应用程序可以从以太坊、BNB 智能链、Polygon 和其他 EVM 兼容链迁移，而无需更改太多代码。遵循以下安全指南可以极大提高合约安全性。

3.1.1 做好应对失败和风险的准备

所有重要的合约都有可能出现错误。特别是在 opBNB 初期，仍然可能出现问题。因此，您必须准备好处理它们，而且您的合约必须具备响应的能力。您可以通过以下方式来做到这一点：

• 在出现问题时，暂停合约或“切断电路”。
• 制定一个有效的升级策略，包括改进和修复错误、漏洞等的方法。
• 通过限制最大使用率和有效管理总金额，有效管理处于风险中的资金。

3.1.2 升级与代理相关的错误

简单总结一下，以下是与智能合约升级相关的问题：

• 不应在实施合约内部使用 selfdestruct 和 delegatecall。
• 在升级期间，必须确保存储变量不会相互覆盖。
• 应避免在实施合约中调用外部库，因为不可能预测它们将如何影响存储访问。
• 部署者绝不能忽略调用初始化函数。
• 在基本合约中不包括间隔变量，以防止在将新变量添加到基本合约时发生存储冲突（这由 Hardhat 插件自动处理）。
• 不可变变量中的值在升级之间不会保留。
• 强烈不建议在构造函数中执行任何操作，因为未来的升级将不得不执行相同的构造函数逻辑以保持兼容性。

3.1.3 注意整数除法的舍入

Solidity 没有浮点数，因此舍入误差是不可避免的。设计者必须意识到向上舍入还是向下舍入是正确的做法，以及舍入应该对谁有利。

// bad
uint x = 5 / 2; // Result is 2, all integer divison rounds DOWN to the nearest integer

使用乘数可以防止四舍五入，将来处理 x 时需要考虑到这个乘数：

// good
uint multiplier = 10;
uint x = (5 * multiplier) / 2;

存储分子和分母意味着可以在链外计算分子/分母的结果：

// good
uint numerator = 5;
uint denominator = 2;

3.1.4 使用 Ownable2Step，而不是 Ownable

单步所有权转移意味着，如果在转移所有权或管理权限时传递了一个错误的地址，则表示该角色将永远丢失。如果在此功能中将管理权限赋予了错误的地址，则会对合约造成不可挽回的损失。

Ownable2step 要求接收者确认所有权，这可以确保不会意外地将所有权发送到输入错误的地址。

参考以下实现： https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/access/Ownable2Step.sol

3.1.5 使用多重签名钱包

实施安全访问控制的一种方法是使用多重签名帐户来管理合约。与常规外部帐户不同，多重签名帐户由多个实体拥有，需要最低数量的帐户签名（比如 5 个中的 3 个）才能执行交易。

使用多重签名进行访问控制增加了额外一层安全性保障，因为需要多方同意才能对目标合约执行操作。如果有必要使用所有权模式，这种方法尤其有用，因为攻击者或内部作恶者操控敏感的合约函数以达到恶意目的会更加困难。

3.1.6 区分函数和事件

为了防止函数和事件（Event）产生混淆，命名一个事件使用大写并加入前缀（我们建议 LOG）。对于函数，始终以小写字母开头，构造函数除外。

// bad
event Transfer() {}
function transfer() {}

// good
event LogTransfer() {}
function transfer() external {}

3.1.7 注意三明治攻击

资产价格随买卖压力而变动。如果内存池中有大额订单，交易者就有动力复制该订单，但价格会更高。这样，他们就会买入资产，让大订单推动价格上涨，然后立即卖出。卖出订单有时被称为“backrunning”。卖出指令可以通过下一个较低 Gas 价格的卖出指令来完成，这样的顺序看起来像这样：

1. 抢先购买
2. 大额买入
3. 卖

抵御这种攻击的主要方法是提供一个“滑点”参数。如果“frontrun buy”本身将价格推高超过某个阈值，“large buy”（大额买入）订单就会恢复，使 frontrunner 交易失败。

这就是所谓的“三明治”（sandwhich），因为大额买入被 frontrun 买入和 backrun 卖出夹在中间。这种攻击同样适用于大额卖单，只是方向相反。

3.1.8 记住链上的数据是公开的

许多应用需要提交的数据是私有的，直到某个时间点才能工作。游戏（比如，链上游戏 rock-paper-scissors）和拍卖（比如，sealed-bid second-price auctions）是两个典型的例子。如果你的应用存在隐私保护问题，一定要避免过早发布用户信息。

例如：

• 在链上游戏石头剪刀布中，需要参与游戏的双方提交他们“行动计划”的 hash 值，然后需要双方随后提交他们的行动计划；如果双方的“行动计划”和先前提交的 hash 值对不上则抛出异常。
• 在拍卖中，要求玩家在初始阶段提交其所出价格的 hash 值（以及超过其出价的保证金），然后在第二阶段提交他们所出价格的资金。
• 当开发一个依赖随机数生成器的应用时，正确的顺序应当是：（1）玩家提交行动计划，（2）生成随机数，（3）玩家支付。
• 如果你正在实现频繁的批量拍卖，那么 hash-commit 机制也是个不错的选择。

3.2 DeFi 协议安全实践

在 DeFi 协议中采取以下多种安全实践，能更大程度地保证 DeFi 协议安全。

3.2.1 智能合约审计

智能合约审计是对与区块链交互的代码进行详细系统的审查。智能合约安全审计对于排除在开发过程中可能出现的安全漏洞至关重要，这些漏洞可能会导致潜在的攻击，危及用户资金安全。定期进行安全审计对于在产品生命周期内排除漏洞至关重要。安全审计必须在智能合约的新版本（例如 V1、V2 和 V3）的开发完成后、主网部署之前进行。

ScaleBit 作为一个为 Web3 Mass Adoption 提供安全解决方案的区块链团队，凭借着在区块链跨链和零知识证明等扩展技术方面的专业能力，主要为 ZKP、Layer 2 和跨链应用提供细致和尖端的安全审计，致力于为可扩展的区块链生态系统的大规模应用提供安全保障。

3.2.2 链上可疑活动追踪

链上活动跟踪机器人用于检测智能合约中的关键操作或状态变化（恶意交易），如外部函数调用、重入调用，并通过自定义通知提醒团队及时采取必要的行动。

3.2.3 形式化验证

形式化验证是一种用于证明设计的正确性并通过严格的数学程序展示错误根本原因的方法。形式化验证可以帮助验证诸如加密协议等系统的正确性。它通过数学方式进行，以避免源代码中的任何加密漏洞。在形式化验证中，人们编写规范（根据上下文定义什么是正确的，什么是错误的），以揭示错误。

形式化验证与安全审计不同，它专注于智能合约代码的数学逻辑，并能够可靠地找到审计公司常常忽略的复杂错误。

3.2.4 经济安全

作为最大资本效率，降低风险的解决方案，经济安全是一种关注 DeFi 项目的财务模型的解决方案。它确保协议在财务安全方面经过广泛测试，并帮助开发人员了解有关安全、治理和共识机制的决策可能如何影响网络活动和资产价值。

3.2.5 吸取的教训

• 在 DeFi 协议中采取多种安全实践，以保护用户锁定的资金免受黑客攻击和漏洞的侵害至关重要。
• 依赖单一的安全实践可能会在发生安全事件时造成单一故障点。应当遵循多种安全实践，以规避潜在的攻击。
• 值得注意的是，大多数受攻击的智能合约要么没有经过审计，要么没有采用适当的安全实践来保护资产。

3.3 跨链桥安全实践

Layer 2 在很大程度上依赖于跨链桥，opBNB 也不例外。在 opBNB 网络上构建或部署任何应用程序之前，您必须首先将 BNB（tBNB）作为您的 Gas 代币从 BNB 智能链存入 opBNB，这也是通过跨链桥实现的。然而，跨链桥攻击数量明显增加，这些桥已成为恶意攻击的目标，成为漏洞利用的蜜罐，有时会造成严重的影响。

3.3.1 跨链桥常见漏洞

1. 托管者：

   • 与已销毁代币相比，释放的资产数量不正确。
   • 尽管债务代币尚未被销毁，但资产已被释放。
   • 单一销毁交易的资产交易重放。

2. 债务发行者：

   • 与存入资产相比，发行的债务金额不正确。
   • 尽管没有进行实际验证，但已发行债务代币。
   • 任何人都可以发行债务代币。

3. 通信者：

   • 尽管没有存入资产，但发行债务代币。
   • 尽管存入了资产，但没有发行债务代币。
   • 接受来自虚假托管人或债务发行者的欺诈消息。
   • 不转发信息。
   • 源合约在存款/提款时未发出事件。

4. 接口（可通过“撤销批准”来修复）：

   • 从其他账户存入资产。
   • 执行任何合约的任何调用。

5. 网络：

   • 51% 攻击。

如果项目中包含桥智能合约，就必须遵循标准，并在此基础上创建安全合约。从过去发现的错误中吸取教训，并准备好解决方案。

确保经过验证的合约满足以下要求：

1. 在项目上线前完成合约安全审计。
2. 考虑到与桥相关的潜在威胁。
3. 合约调用接口需要严格检查其适应性。
4. 版本更新时，需要重新评估相关接口和签名安全性。
5. 需要对跨链签名者进行严格审查，确保签名不被恶意攻击者控制。

3.3.2 安全验证要求

遵循以下安全验证要求可以极大提高跨链桥安全性：

1. 验证跨链桥是否要求在消息中包含所有必要的数值并进行签名：链 ID、接收者、金额和随机数（nonce）。
2. 验证已使用的签名是否失效，以保护跨链桥免受重放攻击。
3. 验证消息哈希生成算法是否具有抵抗碰撞攻击的能力。
4. 验证跨链桥是否在签名消息中包含源链和目标链标识符，并正确验证它们。
5. 验证跨链桥不允许欺骗性的链标识符。
6. 验证跨链桥是否使用 nonce 参数来防止多次执行相同操作（相同的发送者、接收者和金额）。
7. 验证已签名的消息不能在不同的上下文中使用。
8. 验证是否安全处理了 ecrecover 函数返回 0 的情况。
9. 验证特权合约与跨链中继调用是否分离。攻击者不能够交叉调用特权合约。
10. 在解决中继调用时，验证是否考虑了每个受支持区块链的最终性。
11. 验证跨链桥是否会忽略来自不同于设计功能的调用。
12. 验证跨链桥是否需要足够的费用来处理消息。
13. 验证发送方是否限制或完全支持中继消息的最大 Gas 消耗（例如，在费用方面）。

4 总结

在 opBNB 生态中，严格遵循上述安全实践对于确保您的协议的安全性至关重要。这些实践涵盖了多个关键方面，包括智能合约、DeFi 协议以及跨链桥。遵循这些实践不仅可以有效降低潜在漏洞和攻击的风险，还能增强用户信任，确保他们的资金和数据受到可靠的保护。

此外，我们还需要强调进行安全审计的重要性，作为一家业内领先的区块链安全团队，ScaleBit 团队在 ZKP、Layer 2 和跨链应用的安全审计服务具备专业能力和丰富的实践经验。安全审计是确保协议和智能合约完整性的至关重要步骤，它有助于识别并纠正潜在的漏洞和安全风险，以确保用户的资金和数据受到可靠的保护。ScaleBit 致力于为 Web3 的广泛采用提供安全解决方案，成为确保协议和智能合约安全性的可信合作伙伴。通过严格的审查和测试，提供对潜在威胁的深入洞察，以确保 opBNB 生态的用户能够放心使用这一创新生态系统。

参考资料

[1] https://community.optimism.io/docs/developers/bedrock/ [2] https://bscscan.com/address/0x39bea96e13453ed52a734b6aceed4c41f57b2271?ref=binance.ghost.io#analytics [3] https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/access/Ownable2Step.sol [4] https://docs.bnbchain.org/opbnb-docs/docs/intro [5] https://docs.bnbchain.org/opbnb-docs/docs/core-concepts/need-for-opbnb [6] https://github.com/arunimshukla/Best-DeFi-Security-Practices