EOF

预编译合约

EOF 为原本无结构的字节码引入了分段式容器框架，旨在通过强化验证机制和提升执行效率来优化底层代码的安全性与扩展性。

预编译合约作为内置于协议中的特殊账户，专门处理复杂的密码学计算，从而规避了操作码空间有限及计算开销过大的问题。

EOF 容器如何改善以太坊合约的安全性

EOF（EVM Object Format，EVM 对象格式） 是一种为 EVM 字节码设计的可扩展且具有版本控制的容器格式。目前的 EVM 字节码是一系列无结构的指令序列，而 EOF 通过引入“容器”概念，为字节码带来了结构化，使其更易于 EVM 解析和分析。

EOF 主要通过以下几个方面改善以太坊合约的安全性：

• 部署时验证： EOF 在合约部署时进行一次性验证，而旧版 EVM 仅有有限的运行时验证。这种全面的预执行验证允许在代码实际执行前进行更彻底的静态分析。

• 强制执行严格结构： EOF 引入了清晰定义的区块（Sections），将代码与数据分离。在旧版 EVM 中，数据和代码是混合在一起的，而 EOF 的这种分离减少了潜在的攻击向量。

• 改进的跳转机制： 旧版 EVM 使用动态跳转（JUMP/JUMPI），这使得控制流分析变得困难且容易出错。EOF 禁用了动态跳转并采用静态跳转，使合约执行路径更加可预测和安全。

• 引入类型系统： EOF 为 EVM 带来了函数签名和类型（Typing），而旧版 EVM 没有任何类型系统。这有助于在编译和验证阶段发现潜在的错误。

• 限制危险操作： 相关的提案（如 EIP-7620）在 EOF 容器中移除了使用 CREATE 或 CREATE2 指令创建合约的可能性，转而使用 EOFCREATE 和 RETURNCODE 等新指令，以提供一种更安全、结构化的合约创建方式。

预编译合约与普通操作码优劣

1. 预编译合约的优势

• 极高的执行效率： 预编译合约在 EVM 之外由执行客户端原生实现（Native implementation）。这使得它们能够高效处理复杂的密码学计算，而无需承担 EVM 的额外开销（overhead）。

• 节省有限的操作码空间： EVM 的 1 字节操作码空间非常有限（最多 256 个，范围 0x00 - 0xFF）。将常用但复杂的功能实现为预编译合约，可以为更基础的操作节省操作码空间。

• 优化的 Gas 消耗： 预编译合约的 Gas 成本与输入数据直接挂钩，且通常经过严格基准测试。此外，根据 EIP-2929，预编译合约会被包含在交易初始的“已访问地址”中，从而节省 Gas 成本。

2. 劣势

• 库实现的安全性风险：预编译合约依赖于客户端底层的优化库。如果这些库中存在漏洞，可能会导致整个协议层中断。

• 高昂的维护与测试成本：预编译合约是硬编码在协议中的，会增加客户端的代码臃肿度，并带来极高的测试表面积和维护负担。

EOFCREATE 与传统的 CREATE 指令区别

1. 容器化与结构化

• 传统的 CREATE： 用于处理无结构的传统 EVM 字节码，其中代码和数据通常混合在一起。

• EOFCREATE： 专为 EOF（EVM 对象格式）容器设计。EOF 引入了清晰定义的区块（Sections），实现了代码与数据的完全分离。

2. 验证时机与程度

• 传统的 CREATE： 验证相对有限，且主要在**运行时（Runtime）**进行。

• EOFCREATE： 遵循 EOF 的原则，在**部署时进行一次性（once-off）**的全面预执行验证。这种机制允许在代码实际执行前进行更彻底的静态分析，从而增强了安全性。