Enshrinement and fraud proofs

Enshrinement in Ethereum refers to the process of embedding certain functionalities or features directly into the core protocol, making them accessible to all users without any additional implementation requirements or fees.

The original design philosophy of Ethereum was towards minimal enshrinement, meaning that the protocol should be as simple as possible, giving users options to build on top of it based on their needs while staying out of the scope of the core protocol. The state transition function(the function that processes a block) being a set VM instruction calls, and all other logic happening through contracts: a few system-level contracts, but mostly contracts provided by users.

It's commonly acknowledged that in certain situations, especially when dealing with social systems like Ethereum, there are valid reasons to include specific features at the protocol level. This can help in optimizing implementation burdens and gas usage for widely adopted functionalities. Similarly, such an approach can be beneficial for mitigating risks associated with bugs and for minimizing potential vulnerabilities within the protocol.

As it is in Ethereum, enshrining less in optimistic rollups(ORUs) is cleaner and a more compatible implementation with the core Ethereum protocol. In ORUs, smart contracts and code execution are moved off-chain to a separate execution environment, which reduces gas costs and congestion on the main chain. To ensure the integrity and security of these off-chain transactions, the core features of Ethereum's EVM are enshrined within the protocol. This enshrinement allows ORUs to verify transactions off-chain and submit a simplified proof to the Ethereum main chain for validation. This is necessary enshrinement that every rollup has to make to rely on Ethereum as the settlement layer and enjoy it's decentralization and security.

While most of the modern ORUs are EVM compatible, arguably, some of them tend to enshrine more than necessary, creating a counter-effect in the core principles of enshrinement.

For example, Optimism and Arbitrum enshrine modified L2 client contracts and tools in their fraud-proof mechanisms. Specifically, their fraud-proof systems include a compiled Ethereum client binary along with accompanying contracts and tools. This binary is embedded on-chain and used as part of the interactive fraud-proof game to verify the correctness of the execution trace and ultimately the state transitions. By doing so, they effectively hardcode a specific client implementation into the protocol-level fraud resolution process, reducing flexibility and increasing the Trusted Computing Base (TCB).

"If enshrining a particular feature weakens the trust model and makes Ethereum as a whole much more "subjective", that weakens Ethereum's credible neutrality. In those cases, it's better to leave that particular feature as a mechanism on top of Ethereum, and not try to bring it inside Ethereum itself" - Vitalik Buterin

The cons of enshrining the TCB

Upgradability issues - when components like fraud-proof logic or client binaries are enshrined into the protocol, they become deeply coupled with the L2's core system. This tight integration makes it significantly harder to upgrade or iterate on these components. Any improvements or security patches may require coordinated hard forks or governance interventions, reducing agility and responsiveness.

Dealing with massive TCB - enshrining complex tooling such as Ethereum client binaries within the fraud-proof process inflates the Trusted Computing Base. A larger TCB increases the surface area for bugs, vulnerabilities, and trust assumptions. In security-critical systems like blockchains, every additional component enshrined adds weight to what all users and validators must implicitly trust. This undermines the minimalism that helps Ethereum and its rollups remain resilient, modular, and secure.

Unverifiable fraud proof code - When fraud-proof systems rely on compiled binaries or intricate, tightly coupled tooling, it becomes difficult for users, developers, or even auditors to independently verify correctness. The fraud-proof code might involve non-transparent dependencies, precompiled client logic, or off-chain components that are only partially auditable. This reduces transparency and increases reliance on a specific development team or organization to validate correctness.

The pros of a minimal enshrinement model

Avoiding Governance Trust - Minimal enshrinement limits the need for protocol-level governance decisions, especially around critical infrastructure like fraud proofs. By keeping these components external, the protocol remains agile and less vulnerable to capture or gridlock. Developers and users can evolve and improve systems without waiting for consensus among core protocol stakeholders.

Supporting Client Diversity - Enshrining a specific fraud-proof mechanism or client binary hardwires a single path into the protocol, which discourages alternative implementations. A minimal enshrinement model encourages a diverse ecosystem of clients and tooling, making the protocol more resilient to bugs, monoculture risks, and centralization pressures.

Preserving Credible Neutrality - Keeping fraud-proof logic and tooling outside the protocol ensures Ethereum doesn't endorse or depend on specific teams, ideologies, or designs. This neutrality is essential to maintaining Ethereum as a trustless, general-purpose platform where no one has privileged access to core infrastructure.

The balance

While minimal viable enshrinement is the goal, some functionality must be enshrined to support security, performance, and usability. The key is to draw a hard line between what is essential for protocol integrity and what should be left to the application layer.

The less you enshrine, the better - but compromises must be made carefully and with restraint. Enshrinement should serve the protocol's neutrality, not compromise it.