以太坊预编译的起源，为何它们是区块链上的特殊公民？

在以太坊的复杂世界中，预编译合约（Precompiles）是一个独特且至关重要的组成部分，它们是以太坊虚拟机（EVM）中一组预先实现、硬编码的合约地址，执行速度远快于普通的智能合约，这些“特殊公民”是如何出现的？它们的存在又解决了哪些核心问题？让我们一同追溯以太坊预编译的起源。

以太坊的愿景与早期的挑战

以太坊的愿景是构建一个去中心化的、可编程的区块链平台，允许开发者部署各种复杂的去中心化应用（DApps），为实现这一愿景，以太坊设计了EVM作为执行智能合约的引擎，EVM的设计初衷是通用性和图灵完备性,这意味着理论上它可以执行任何计算任务。

在以太坊发展的早期阶段，尤其是在2015年主网上线前后,社区面临着几个严峻的挑战：

1. 性能瓶颈：纯基于EVM的智能合约执行，尤其是涉及复杂密码学运算或大量数据处理的场景，效率相对较低，这可能导致网络拥堵、交易确认缓慢和高昂的Gas费用。
2. 密码学原生的需求：区块链安全高度依赖密码学算法，如哈希（SHA-256、RIPEMD-160）、椭圆曲线运算（secp256k1）、以及对称加密（AES）等，如果这些基础操作都通过Solidity等高级语言编写并在EVM中逐条解释执行,会非常低效且浪费Gas。
3. 特定功能的“刚需”：某些功能是区块链基础设施所必需的，例如地址校验（如以太坊地址格式校验）、椭圆曲线签名验证（ECDSA）等，这些功能需要高效、可靠且一致的实现。

“软分叉”带来的“快捷方式”：预编译的诞生

为了应对上述挑战，以太坊社区和核心开发者们寻求一种能够在不破坏EVM通用性的前提下，提升特定功能执行效率的方法，他们选择了通过“软分叉”（Soft Fork）的方式，在EVM中引入一组预先编译好的合约——即预编译合约。

这些预编译合约被部署在以太坊地址空间的特定固定区域（从0x01到0x0e，后续有所扩展），它们并非像普通智能合约那样由字节码部署和执行，而是由EVM客户端直接在底层实现，当一个交易或调用指向这些预定义地址时，EVM客户端会直接调用其底层的高效实现,而不是通过字节码解释器执行。

预编译的核心目的与优势

预编译合约的引入,主要基于以下几个核心目的和带来的优势：

1. 显著提升性能：预编译合约的核心优势在于速度，它们通常用C 、Rust等系统级语言编写，直接与以太坊客户端的底层库交互，避免了EVM字节码的解释执行开销，对于密码学运算等密集型任务,性能提升可达几个数量级。
2. 降低Gas成本：由于执行效率极高，预编译合约的Gas消耗远低于等效功能的Solidity智能合约，这使得开发者可以更经济地使用这些关键功能,从而降低了整个网络的运行成本。
3. 提供基础密码学工具：预编译合约最初包含了最常用的密码学函数，如：
   • ecrecover (0x01): 椭圆曲线签名恢复,用于验证签名和提取地址。
   • sha256 (0x02): SHA-256哈希算法。
   • ripemd160 (0x03): RIPEMD-160哈希算法。
   • identity (0x04): 返回输入数据本身（用于测试或特定场景）。 这些是构建更复杂应用的基础模块。
4. 向后兼容性与平滑升级：通过软分叉引入预编译合约，确保了网络的向后兼容性，旧的客户端不会因为不理解这些新地址而拒绝处理交易，它们只是简单地忽略这些调用（或按未处理处理），而新客户端则能高效执行它们,这使得以太坊可以在不硬分叉的情况下逐步增强功能。
5. 为特定场景优化：除了密码学，后续还添加了其他预编译合约，如用于模幂运算的modexp (0x05)、用于椭圆曲线点加的alt_bn128_add (0x06)和alt_bn128_mul (0x07)（这些对于ZK-SNARKs等隐私技术至关重要），以及用于大整数运算的blake2f (0x09)等,都是为了满足特定场景下的性能需求。

预编译的演进与现状

随着以太坊的发展，预编译合约的数量和功能也在不断演进，在伊斯坦布尔（Istanbul）升级中，引入了blake2f预编译合约；在柏林（Berlin）升级中，调整了部分预编译合约的Gas费用，它们已经成为以太坊协议升级中一种灵活且高效的工具,用于引入新的优化功能或调整现有机制。