Vitalik's Blog Post Explained: Is the Next Step for Web3 Infrastructure Wrapping or Scaling?
TechFlow Selected TechFlow Selected
Vitalik's Blog Post Explained: Is the Next Step for Web3 Infrastructure Wrapping or Scaling?
This article will explore the design trade-offs among Web3 infrastructures regarding "encapsulation vs. extension," as well as share personal thoughts on this issue in the context of public blockchain infrastructure.
Navigating Web3 tides with focused insightsAuthor: CP, Artela CTO & co-founder
Vitalik recently published a blog post titled "Should Ethereum be okay with enshrining more things in the protocol?", sharing his thoughts on how foundational functionalities required by higher-layer applications could be “enshrined” into Ethereum’s core protocol, and exploring frameworks for systematically integrating such features.
This is a critical issue commonly faced by platform-style systems: whether to “enshrine” key upper-layer application functions into the base layer, or allow developers to “extend” these capabilities at the application level. As infrastructure approaches large-scale expansion, the design choice between “enshrinement vs extension” becomes crucial—one that may determine its potential for mass adoption.
In recent months, major Web3 infrastructures have rolled out significant technical upgrades: Uniswap introduced Hooks to support customizable pools; MetaMask launched Snaps enabling user-side extensions; and now Ethereum itself faces the “enshrinement vs extension” dilemma.
This article explores how Web3 infrastructures are navigating the trade-offs between “enshrinement and extension,” along with personal reflections on this pivotal challenge for public blockchain infrastructure.
What problem is Ethereum facing? Enshrine or Extend
On the question of “enshrinement vs extension,” Ethereum has long favored the path of “extension.”
Ethereum’s design philosophy draws from Unix—building a minimal, general-purpose kernel while leaving user needs to be fulfilled at the application layer through developer innovation. The key technology enabling this approach is the EVM. Its Turing-complete smart contract language allows developers to customize their applications freely at the application layer.
This model appears sound in theory, but proves less effective on a “decentralized Unix.” A major reason lies in the fact that EVM’s so-called Turing completeness isn’t truly complete in practice. Under gas constraints and limited opcodes, programs must accomplish tasks within finite steps using restricted operations—this severely limits what dApps can achieve compared to Web2 applications running atop Unix. Many advanced capabilities needed by high-end dApps remain unattainable under EVM. Whether it’s Rollups or account abstraction (AA) wallets, they may function without L1 modifications, but often remain MVP-level solutions, falling short in both efficiency and user experience.
For developers, the only recourse becomes an EIP—to propose that core functionality they depend on be “enshrined” into the protocol by Ethereum’s core team for broader use.
Since EVM-based “extension” fails to meet evolving application demands, Ethereum must now seriously consider when and how to “enshrine” certain features.
However, enshrining application-layer features into decentralized infrastructure is no simple matter. It goes beyond merely integrating code—it touches upon the greatest challenge in decentralized systems: governance. “Enshrinement” means the core team takes on not just development and maintenance, but also ongoing governance responsibilities for those features, potentially weakening Ethereum’s trust model and introducing risks to long-term sustainability.
The result is predictable: the number of features the core team can enshrine is inherently limited; any candidate feature must gain broad community consensus; and implementation timelines stretch over years.
Consequently, if your required functionality does not qualify as a widely recognized foundational need, Ethereum may never accommodate it—or even your attempts to build around it. You might end up needing to launch a dedicated appchain, bearing high development and operational costs, while losing access to the composability magic of the smart contract ecosystem.
On the “enshrinement vs extension” dilemma, Ethereum still lacks a clear resolution. How to conduct “enshrinement” in an orderly manner—what Vitalik refers to—is still under exploration. They’re actively seeking a framework to identify which functions should be enshrined, and how to do so effectively.
What else can we learn from Unix? Native Extension!
Ethereum’s current push toward enshrinement stems largely from insufficient extensibility at the application layer—forcing reliance on core teams to fill gaps. But what if we flipped the perspective: could enhancing application-layer extensibility solve much of the problem? For example, allowing developers to customize底层 functionality for their own apps without waiting for protocol-level enshrinement?
We know Ethereum borrowed heavily from Unix design principles. Let’s continue mining insights from the Unix world.
Commercial operating systems based on Unix face diverse application needs—including enterprise-grade extension requirements. Yet their core teams don’t bear heavy burdens of enshrinement because they provide powerful extensibility mechanisms, empowering users and developers to implement most desired features themselves.
Take Mac OS X as an example. Like most operating systems, it separates kernel space and user space, where applications typically run in user space relying on kernel-provided services. A simplified analogy: smart contracts on EVM are like user-space apps, while Ethereum’s protocol layer corresponds to kernel space.
But Mac OS X allows developers to deploy code directly into kernel space to extend its capabilities—without requiring Apple’s core team to review and integrate each case individually. It provides two mechanisms—Kernel Extensions and System Extensions—that let developers safely develop privileged extensions, unlocking functionalities impossible in pure user-space apps.
The insight here: could a “Kernel Extension”-like model work on a “decentralized Unix”? Its structure would look like this:
Beyond supporting “smart contracts,” blockchains could support another type of program: “Native Extension,” which:
1) Has greater access to底层 protocol APIs than smart contracts
2) Runs in a significantly more efficient execution environment—orders of magnitude faster than EVM
3) Is isolated from the底层 protocol, preserving its stability
4) Requires no maintenance by the底层 team; instead, governed and deployed by application teams themselves
If such a model meets all four criteria technically, it could resolve many issues: developers could customize底层 functionality per their needs, without waiting for core team enshrinement.
Let’s call this paradigm the “Native Extension” model, and see whether traces of it already exist in today’s Web3 infrastructure.
Hook, Hook, Hooks…
In software, great tools emerge from great use cases. As a DeFi cornerstone, Uniswap stands at a pivotal juncture of becoming a true platform—and its answer to the “enshrinement vs extension” dilemma is impressively elegant: Hooks. These allow developers to permissionlessly enhance pools via Hooks, creating diverse pool experiences without requiring constant feature enshrinement by the core team.
The Hook mechanism aligns closely with the earlier-described Native Extension conditions:
· Hooks can inject into the pool’s execution lifecycle and access runtime data—offering higher-level access privileges
· Hooks are separate contracts from the pool, so their security doesn’t compromise the pool
· Governance-wise, third-party developers can deploy Hooks permissionlessly, and they aren’t globally activated—each pool binds specific Hooks on demand to enable custom behaviors
Hooks represent an elegant, minimalist solution to pool extensibility. Having seen application-layer infrastructure adopt such concepts, let’s now turn to more complex底层 protocols (L1/L2), and examine their approaches.
New L1 projects’ approaches to extensibility
As Ethereum struggles, let’s look at Layer 2 projects aiming to extend Layer 1, and explore their visions.
Arbitrum Stylus: letting developers self-compile precompiles!
Most know that EVM extends functionality via “precompiled contracts”—code not executed within EVM, but built into nodes and run at the底层. For instance, adding new cryptographic algorithms—too complex and costly for EVM—can be implemented as precompiles, callable by application contracts. However, only the core team can add precompiles via EIPs; developers lack permissionless access.
Arbitrum Stylus introduces an “EVM+” paradigm: while maintaining EVM equivalence/compatibility, it allows developers to break EVM limitations and permissionlessly deploy high-performance precompiled-like contracts. It achieves this by adding a WASM execution environment at the execution layer, dynamically loading WASM contracts. WASM offers an order-of-magnitude performance boost over EVM and supports multiple programming languages.
This is one promising way to alleviate Ethereum’s enshrinement bottleneck: instead of waiting for core teams to enshrine features, EVM extension needs are met directly by developers. The core team focuses on maintaining the extended execution environment, while innovation, development, and governance shift to the application layer.
Still early, Stylus hasn’t yet exposed all potential challenges, and its scope remains limited—currently supporting only dynamic precompile-like encapsulation. Ethereum faces broader enshrinement challenges beyond precompiles. Still, it’s encouraging: this is one of the closest realizations we’ve seen of the Native Extension paradigm. As a next-gen infrastructure representative, it incorporates extensibility by design to address future scalability bottlenecks, thinking ahead for long-term ecosystem growth.
Native Extension: A “modular enshrinement” approach!
Reviewing both Web2 and Web3 infrastructure projects, a clear path emerges on the “enshrinement vs extension” question: enhance extensibility so developers can modularly enshrine the functionalities they need.
This is the essential role of the Native Extension paradigm in infrastructure: by boosting extensibility, it returns control to developers—enabling them to freely modularize, enshrine, and extend features without compromising core protocol stability.
While Ethereum seeks to improve enshrinement efficiency, and Arbitrum Stylus liberates precompiles, looking further ahead, public blockchains can fully unleash application-layer creativity through the Native Extension paradigm—just as Uniswap V4 has begun to demonstrate.
A new L1 built on Native Extension: Artela
Now shifting perspectives—“we” refers to my team as CTO: Artela. Here’s our thinking and actions on this front.
On the Artela blockchain, alongside EVM, we’ve embedded a WASM execution environment. This can run stateful programs—akin to stateful precompiles. Moreover, it supports a Hook-like mechanism, triggering execution at multiple lifecycle points during block and transaction processing. Thus, it goes beyond Arbitrum Stylus—not just encapsulating precompiles, but customizing transaction and block execution flows for broader functional enshrinement. For example, a WASM-based Native Extension could trigger at the transaction validation stage, applying novel algorithms for transaction identification and verification. We call these triggers Join Points, and refer to these Native Extensions not as Smart Contracts, but as Aspects—drawing from Aspect-Oriented Programming (AoP)—dynamically injecting new capabilities at various Join Points within the live blockchain system!
To illustrate concretely: we’ve spoken with investors and Web2 institutions about barriers to bringing large-scale assets onchain—the top concern is always security. Web2-grade risk control safeguards trillions in value, yet struggles to enter Web3 tech stacks. Carl from NASA’s aerospace division echoed similar views: why do we need Runtime Protection and Aspects?
Runtime Protection is central to security risk management. In today’s Web3 landscape, we see strong security firms offering static audits, formal verification, real-time monitoring, and frontrunning mitigation—yet these fall far short of Web2-grade runtime risk controls. The root issue? Security measures around the mempool are exhausted once transactions leave it. If there were extensibility *after* the mempool—during transaction execution—security experts could deploy runtime-level policies, elevating protection to new heights. Aspects empower developers with deep execution-layer security extensibility!
Developers can deploy project-specific Aspects to customize protocol-layer features—such as runtime security that blocks transactions likely to lead to large fund losses.
They can also deploy public Aspects, encapsulating reusable基础 functionalities across projects. For instance, an Aspect implementing a specific algorithm and transaction type could make AA wallets more programmable and composable—other developers can then enable this Aspect to leverage the same底层 capability.
For Artela, our vision has grown increasingly clear:
· Enable developers to permissionlessly solve problems at the application layer via Native Extension—instead of waiting for the底层 chain team to enshrine features
· Empower large Web2 institutions and capital to stake confidently on blockchains—by integrating Web2-grade runtime risk controls
· Provide developers with a thriving environment to innovate beyond existing boundaries (EVM may soon hit its ceiling—EVM + Native Extension holds greater potential)
· Offer an ideal home for dApps like omnichain gaming and RWA that aim to move substantial business logic onchain
We see clearly that Ethereum remains in the phase of figuring out *how* to enshrine application-specific features, with no visible plan to relieve this enshrinement pressure and return creativity to developers. For the next wave of innovators eager to突破 boundaries in decentralized applications, this situation feels deeply restrictive—they need a robust decentralized network, yet lack the freedom to build boldly. This is precisely why we’re committed to building a new L1 on the Native Extension paradigm: to ensure infrastructure never blocks the pace of innovation.
Import Web2
Finally, I close with these two words. While coding on decentralized Web3 stacks versus Web2 stacks involves entirely different mindsets, we shouldn’t hesitate to mine treasures from the Web2 library—at the level of design philosophy and evolutionary history. Keep building!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@Artela_Network
