On October 19, 2026, Vitalik Buterin floated an idea on X that appeared to involve technical details but actually pertained to the long-term form of Ethereum: instead of continuing down the old path of "adding a precompiled contract for every new cryptographic algorithm at the consensus layer," he suggested transforming the on-chain environment into a universal proof verifier. The "ideal path" he proposed was to use EIP-8288 as an entry point, allowing users to freely choose and execute any signature or cryptographic scheme locally, and then generate the corresponding STARK proofs based on these operations. A dedicated STARK aggregator would then collect and aggregate multiple proofs off-chain before submitting them to the Ethereum chain for verification. Along this path, there would be no need to upload the original signatures as calldata on-chain, saving additional space, and it would not be necessary to add new precompiled contracts for every new algorithm, thereby avoiding further complexity in consensus rules and client implementations. The problem was sharply raised: should Ethereum continue to stack precompiles at the execution layer, or shift to a framework supported by EIP-8288 and a STARK proof system for generalized signatures and cryptographic expansion? This became the core point of divergence in the subsequent discussions.
The Invisible Burden of Precompile Stacking is Laid Bare
To understand how reality-based this point of divergence is, we must return to Ethereum's past practices: when the community requires a specific elliptic curve operation or hash function, the most direct approach is to insert a new precompiled contract at the protocol layer, allowing contracts calling such operations to pay lower gas fees during execution. For application developers, this is a "visible" advantage; however, for the consensus layer and client teams, each new precompile requires a specification change, a round of implementation and auditing, and subsequently a long-term commitment to follow network upgrades and ensure compatibility with older versions.
This cost does not dissipate over time; rather, it accumulates as the number of precompiles increases: consensus rules become increasingly lengthy, client code is forced to carry more special case logic, and any slight implementation difference could evolve into a consensus divergence risk. According to multiple reports, Vitalik explicitly identified "continuously adding precompiles" as one of the paths to avoid in this statement, laying bare the maintenance burden originally hidden in engineering details, spotlighting the choice between supporting multiple cryptographic algorithms.
Local Signatures Combined with STARK Proofs
In what he refers to as the "ideal path," the signing process is completely brought back to the user's local environment. Whether using existing algorithms or entirely new signing schemes, the user or wallet first completes a full set of cryptographic operations locally: generating signatures, verifying signatures, with all details processed off-chain. Subsequently, the same logic for "is the signature correct?" is written into a STARK proof circuit, producing a STARK proof that proves it has completed the signing or verification according to the predetermined algorithm. These dispersed proofs are then collected and aggregated by the STARK aggregator, ultimately submitted to Ethereum as an aggregated proof, accepted on-chain as a generalized object for verification under the path outlined by EIP-8288.
In this way, what is visible on-chain is no longer a dense collection of original signatures and public key parameters, but rather a STARK proof stating "this signing verification has been executed correctly." According to multiple reports, Vitalik emphasized that in this design, Ethereum no longer needs to squeeze the original signatures into calldata, naturally avoiding additional data writing costs; the consensus layer only needs to be able to verify STARK, thus indirectly accepting signature results from any algorithm. More crucially, this general proof path bypasses the old routine of "adding precompiles for every new algorithm," allowing the protocol layer to maintain a relatively stable set of precompiles, keeping the evolutionary pressure of diverse cryptography as much as possible within the off-chain proof system.
How STARK Aggregators Compress Verification Pressure
In the path described by Vitalik, the on-chain component only needs to verify one type of STARK proof, while the truly complex signing algorithms and proof assembly are relegated to an independent role—the STARK aggregator. It does not participate directly in user signing but is responsible for collecting the STARK proofs generated by multiple users off-chain and packaging them into a single aggregated proof suitable for validation by Ethereum contracts according to an agreed format. Once the packaging is completed, the aggregator only needs to submit this "total proof" to the chain, allowing the consensus layer to verify all included signature results at once without having to call the verification logic for each original proof individually.
This means that, from the protocol perspective, an originally N times STARK verification call can be compressed into a single call, and the proof data that originally would have had to appear repeatedly on-chain is combined into a single aggregated object, resulting in a shorter and more focused verification path. According to AiCoin data, public information is currently only at a principle-level architectural description, and the factual database does not provide specific implementation details, throughput capacity, or actual gas cost measurements for the STARK aggregator. Thus, it is premature to talk about how many resources are saved, but it is certain that this design of "off-chain aggregation, on-chain verification at once" maximizes the space for engineering optimization at the aggregator layer.
The Tug-of-War Between Protocol Simplicity and Flexible Signing
If the old path of "adding precompiles" is followed further, then for every new cryptographic algorithm, a highly optimized precompiled contract must be stuffed into the consensus layer. In the short term, it can provide extremely low-cost on-chain support for a single algorithm; however, over a longer timeline, this means that protocol specifications and various clients have to be updated frequently, with the precompile list growing longer and longer, accumulating maintenance and governance burdens. To ensure that the signing scheme is flexible enough, new bricks must constantly be added to the protocol, yet striving for protocol simplicity will conversely constrain the speed of introducing new algorithms. This structural tension has already been seeded in Ethereum's early days.
What Vitalik proposes this time is to combine EIP-8288 with STARK to "side-shift" this tension off-chain: users complete any required signing or cryptographic operations locally and then generate the corresponding STARK proofs, which are then summarized by the aggregator and submitted to the chain at once, so that the on-chain component only needs to verify this type of proof consistently without needing to add new precompiles for each algorithm. The diversity of algorithms is pushed down to the proof system, while the on-chain logic converges as much as possible; this is precisely why he refers to this combination as the "ideal path" supporting multiple cryptographic algorithms. However, the factual database also makes it clear that all of this remains at the level of directional technical statements, and the formal text, status, and whether EIP-8288 will enter a specific upgrade version have not been confirmed, making it more like a candidate route for the future evolution of signatures in Ethereum rather than a decided protocol resolution.
The Next Steps for Diverse Cryptography: Who will Land First?
Returning to the broader narrative of Ethereum's long-term evolution, Vitalik's statement on October 19, 2026, seems more like a narrative branch opening up for diverse cryptography beyond the established path of "adding precompiles": compressing algorithm diversity into the STARK proof system, using EIP-8288 as an entry point, allowing the protocol itself to maintain restraint as much as possible. Several Chinese media outlets such as PANews, Shenchao TechFlow, and Foresight News are highly consistent in their interpretations, emphasizing the implication of "replacing new precompiles with proofs." However, as of now, there are no records of any formal responses from the core development team or the Ethereum Foundation; the formal proposal text for EIP-8288, performance data, activation timeline, or inclusion in any upgrades remains completely blank. What is truly worth monitoring moving forward is whether community discussions will push this route toward a more formal governance and development process, as well as whether various client teams are willing to invest in implementation and maintenance costs. Until these key signals materialize, any judgments regarding timing, actual effects, or whether it will definitely transition to the chain can only be seen as uncertain open outcomes.
Join our community to discuss and grow stronger together!
Exclusive Hyperliquid benefits for AiCoin: https://app.hyperliquid.xyz/join/AICOIN88
Exclusive Aster benefits for AiCoin: https://www.asterdex.com/zh-CN/referral/9C50e2
On-chain Telegram community: https://t.me/AiCoinWhaleData
On-chain community: https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin on-chain Twitter: https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
