本文介绍了Optimism Rollup 的 SystemConfig 合约，该合约用于在L1上发出rollup配置更改的日志事件，这些更改会被L2的区块衍生过程获取并应用。文章详细说明了SystemConfig合约中包含的参数，如batcherHash、overhead、scalar、gasLimit以及unsafeBlockSigner，以及如何读写这些配置。
系统配置
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
目录
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
SystemConfig 是 L1 上的一个合约，它可以将 rollup 配置更改作为日志事件发出。
rollup 区块推导过程 会接收这些日志事件并应用更改。
系统配置内容（版本 0）
系统配置合约的版本 0 定义了以下参数：
batcherHash (bytes32)
当前授权的 batcher 发送者(s)的版本化哈希，用作 batch-submitter 来轮换密钥。
第一个字节标识版本。
版本 0 将当前的 batch submitter 以太坊地址 (bytes20) 嵌入到版本化哈希的最后 20 个字节中。
将来，此版本化哈希可能会成为对更广泛配置的承诺，
以实现更广泛的冗余和/或轮换配置。
overhead 和 scalar (uint256,uint256)
L1 费用参数，也称为 Gas Price Oracle (GPO) 参数，
会一并更新，并将新的 L1 成本应用于 L2 交易。
gasLimit (uint64)
L2 区块的 gas 限制是通过系统配置来配置的。
对 L2 gas 限制的更改将完全应用于第一个具有引入该更改的 L1 起始区块的 L2 区块中，
而不是像 L1 区块的限制更新中看到的那样，以 1/1024 的比例调整到目标值。
unsafeBlockSigner (address)
区块在 L1 上可用之前，会在 p2p 网络中传播。
为了防止 p2p 层的拒绝服务，这些不安全的区块必须使用特定的密钥签名，才能被接受为“规范”的不安全区块。
与此密钥对应的地址是 unsafeBlockSigner。为了确保
可以通过存储布局无关的方式，使用存储证明来获取其值，它存储在一个特殊的存储槽中，该存储槽对应于
keccak256("systemconfig.unsafeblocksigner")。
与其他值不同，unsafeBlockSigner 仅适用于区块链策略。它不是共识级别参数。
写入系统配置
SystemConfig 合约对所有写入合约函数应用身份验证，
配置管理可以配置为任何类型的以太坊帐户或合约。
在写入时，会发出一个事件，以便 L2 系统接收该更改，
并且新的写入配置变量的副本会保留在 L1 状态中，以便与 L1 合约一起读取。
读取系统配置
rollup 节点通过根据其过去的 L2 链找到一个起始点来初始化其推导过程：
- 从 L2 genesis 启动时，初始系统配置从 rollup 链配置中检索。
- 从现有的 L2 链启动时，先前包含的 L1 区块被确定为推导起始点，
因此可以从最后一个将 L1 区块作为 L1 起始区块引用的 L2 区块中检索系统配置：
batcherHash、overhead 和 scalar 从 L1 区块信息事务中检索。gasLimit 从 L2 区块头中检索。- 其他未来的变量也可以从 L2 区块的其他内容（例如标头）中检索。
在为给定的 L1 起始输入准备初始系统配置之后，
通过处理每个新的 L1 区块中的所有收据来更新系统配置。
包含的日志事件经过过滤和处理，如下所示：
- 日志事件合约地址必须与 rollup
SystemConfig 部署匹配
- 第一个日志事件主题必须与
ConfigUpdate(uint256,uint8,bytes) 的 ABI 哈希匹配
- 第二个主题确定版本。未知版本是关键的推导错误。
- 第三个主题确定更新的类型。未知类型是关键的推导错误。
- 剩余的事件数据是不透明的，编码为 ABI 字节（即包括偏移量和长度数据），
并对配置更新进行编码。在版本
0 中，支持以下类型：
- 类型
0：batcherHash 覆盖，作为 bytes32 payload。
- 类型
1：overhead 和 scalar 覆盖，作为两个打包的 uint256 条目。
- 类型
2：gasLimit 覆盖，作为 uint64 payload。
- 类型
3：unsafeBlockSigner 覆盖，作为 address payload。
请注意，各个推导阶段可能会处理不同的 L1 区块，
因此应维护单独的系统配置副本，
并在该阶段遍历到下一个 L1 区块时应用基于事件的更改。
