2026 年 10 月 19 日，Vitalik Buterin 在 X 上抛出了一个看似技术细节、实则关乎以太坊长期形态的设想：不再沿用“每多一种密码学算法，就在共识层再加一个预编译合约”的旧路，而是让链上变成一个通用证明验证器。他提出的“理想路径”是，以 EIP-8288 为入口，用户在本地自由选择并执行任意签名或密码学方案，再基于这些操作生成对应的 STARK 证明，由专门的 STARK 聚合器在链下收集、聚合多份证明后，一并提交到以太坊链上验证。在这条路径下，链上既不需要把原始签名当作 calldata 上传、去占用额外空间，也不必为每一种新算法新增预编译合约，从而避免继续拉高共识规范和客户端实现的复杂度。问题也由此被尖锐地抛出：以太坊未来要不要继续在执行层堆叠预编译，还是转向由 EIP-8288 加 STARK 证明系统支撑的通用签名与密码学扩展框架，这成为接下来讨论的核心分歧线。
预编译堆叠的隐形负担被摊开
要理解这条分歧线有多现实，得回到以太坊这些年的惯性做法：当社区需要某种特定的椭圆曲线运算或哈希函数时，最直接的办法，就是在协议层塞进一个新的预编译合约，让调用这类运算的合约在执行时支付更低的 gas。对应用开发者而言，这是一个“看得见”的优惠；但对共识层和客户端团队来说，每一个新增预编译，都是一次规范改动、一轮实现和审计，以及之后长期跟随网络升级、兼容老版本的维护承诺。
这种成本并不会随着时间自然消散，反而会在预编译数量不断增加时持续堆积：共识规则变得愈发冗长，客户端代码被迫携带越来越多特例逻辑，任何细微的实现差异都可能演变成共识分歧风险。据多家媒体转述，Vitalik 在这次发文中，明确把“继续不断新增预编译”点名为希望避免的路径之一，把原本隐身在工程细节里的维护负担，摊开摆在了支持多种密码学算法的路线选择上。
本地签名加 STARK 证明的通用算盘
在这条被他称为“理想路径”的路线里，签名这件事被彻底搬回用户本地。无论是现有算法还是全新的签名方案，用户或钱包先在本机完成一整套密码学运算：生成签名、验证签名，所有细节都在链下跑完。紧接着，同一套“签名是否正确”的逻辑被写成一个 STARK 证明电路，本地证明系统产出一份 STARK 证明，证明自己确实按预定算法完成了签名或验证。随后，这些分散的证明交给 STARK 聚合器收集、合并，最终以聚合证明的形式提交到以太坊，在 EIP-8288 所描绘的路径下，作为通用对象接受链上验证。
这样一来，链上看到的就不再是密密麻麻的原始签名和公钥参数，而是一份“这笔签名验证已经正确执行”的 STARK 证明。据多家媒体转述，Vitalik 强调，在这一设计里，以太坊不需要再把原始签名塞进 calldata，自然也就避免了额外的数据写入开销；共识层只要会验 STARK，就能间接接受任意算法的签名结果。更关键的是，这条通用证明路径绕开了“新增算法就新增预编译”的老套路，让协议层维持一套相对稳定的预编译集合，把多元密码学的演化压力尽可能留在链下的证明系统之中。
STARK 聚合器如何压缩验证压力
在 Vitalik 描述的路径里，链上只需要会验一类 STARK 证明，真正繁杂的签名算法和证明拼装，被挪到了一个独立角色——STARK 聚合器。它并不直接参与用户签名，而是负责在链下收集多位用户各自生成的 STARK 证明，按约定格式打包成一份适合以太坊合约验证的聚合证明。等到打包完成，聚合器只需向链上提交这一份“总证明”，共识层就能一次性验证其中包含的全部签名结果，而不必对每一份原始证明逐条调用验证逻辑。
这意味着，从协议视角看，原本 N 次 STARK 验证调用可以被压成 1 次，原本需要在链上重复出现的证明数据也被合并成一份聚合对象，验证路径随之变得更短更集中。据 AiCoin 数据显示，当前公开信息仅停留在这种原理级别的架构描述，事实库没有给出 STARK 聚合器的具体实现细节、吞吐能力或实际 gas 成本的测量结果，因此现在谈节省了多少资源还为时过早，但可以确定的是，这种“链下汇总、链上一次验清”的设计，将工程优化的空间尽可能留在聚合器这一层。
协议简洁与灵活签名之间的拉扯
如果沿着“新增预编译”的老路走下去，每出现一种新的密码学算法，就要在共识层再塞进一个高度优化的预编译合约。短期看，它能为单一算法提供极低成本的链上支持；但从时间轴拉长，这意味着协议规范和各类客户端要频繁更新，预编译列表越拉越长，维护和治理负担随之累积。想要签名方案足够灵活，就得不断往协议里加砖添瓦，而坚持协议简洁又会反过来约束新算法的引入速度，这种结构性的拉扯在以太坊早期就已经埋下。
Vitalik 此次提出的，则是用 EIP-8288 结合 STARK 的方式把这种拉扯“侧移”到链下：用户在本地完成任意所需的签名或密码学操作，再生成对应的 STARK 证明，由聚合器汇总后一次性提交链上，链上只需稳定地验证这类证明，而不再为每种算法单独新增预编译。算法多样性被下沉到证明系统，链上逻辑尽量收敛，这正是他在发文中把这一组合称作支持多种密码学算法“理想路径”的原因所在。不过，事实库同样明确，这一切目前仍停留在技术方向表态层面，EIP-8288 的正式文本、状态及是否进入具体升级版本尚未确认，这更像是以太坊未来签名演进的一条候选路线，而非已经拍板的协议决议。
多元密码学的下一步看谁先落地
放回以太坊更长线的演进叙事，这次 Vitalik 在 2026 年 10 月 19 日的发言，更像是在“新增预编译”这条既有路径之外，为多元密码学打开的一条叙事分支：把算法多样性压缩进 STARK 证明系统，用 EIP-8288 作为入口，让协议本身尽量维持克制。多家中文媒体如 PANews、深潮 TechFlow、Foresight News 对此给出的解读高度一致，都在强调“以证明替代新增预编译”的意味，但截至目前，事实库没有记录任何来自核心开发团队或以太坊基金会的正式回应，EIP-8288 的正式提案文本、性能数据、激活时间表乃至是否会被纳入某次升级，也统统处于空白状态。接下来真正值得盯的变量，是社区讨论是否会把这条路线推到更正式的治理与研发流程中，以及各客户端团队是否愿意为之投入实现与维护成本；在这些关键信号落地之前，任何关于落地时间、实际效果乃至是否一定会走到链上的判断，都只能被视作不确定的开放结局。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
