"Just Enough and Not Too Much"
Threading the Needle on Ethereum Enshrinement
If this article resonates, please help spread thoughtful discourse by engaging with this tweet: https://twitter.com/l2iterative/status/1710171797700944374?s=20
A few days ago, Vitalik posted his thoughts on the effects of enshrining things into Ethereum.
Vitalik's enshrinement piece is an insightful deep dive, but we believe that we can all thoughtfully weigh the merits of minimalism versus pragmatic enshrinement based on our extended thoughts and principles. This discourse deserves a broad, interdisciplinary perspective!
Here’s a TL;DR
The post by Vitalik tackles a really fascinating and nuanced issue in blockchain design - how to balance protocol minimalism with pragmatic enshrinement of features.
Preserve minimalism's benefits
But enable progress through minimal enhancement
Complexity is risky, so enshrine judiciously
Focus on the smallest viable building blocks
Keep assessing as the landscape changes
The main thesis surrounding his post
“While Ethereum originally favored a minimalist base protocol and building higher-level functionality on top, there are good arguments for judiciously enshrining some features directly into the protocol - but care must be taken not to go too far.”
It addresses a key philosophical debate regarding Ethereum's technical vision and architecture going forward. The minimalist vs. pragmatic scope expansion question sits at the core of Ethereum's ethos and future. Hence, we’re exploring this.
But what is Enshrinement, and why does it matter?
By enshrining Ethereum, you refer to incorporating additional features and functionality directly into the Ethereum protocol layer rather than implementing them on higher layers as contracts. It allows optimizations like efficiency, stronger guarantees, avoiding duplicate work across applications, and avoiding centralization risks.
Vitalik’s post on enshrinement comes deep from an understanding of what he eventually envisioned Ethereum to be. The original Ethereum philosophy favored minimalism– keeping the base protocol simple and building on top. This follows the Unix philosophy of modular, flexible software.
However, there are arguments for judiciously enshrining some features in the protocol to avoid centralization, enable stronger versions of functionality, and fix systemic issues. Enshrining too many features can negatively impact governance, complexity, flexibility, and the trust model. A balanced, minimal approach is needed.
"Minimal Viable Enshrinement" - making focused protocol changes to unlock classes of functionality without over-prescribing - can be a good middle ground, and determining what to enshrine is an evolving tradeoff. As needs and technologies change over time, the appropriate balance between minimalism and enshrinement will shift.
We believe Vitalik raised some excellent points about the tradeoffs between keeping the Ethereum protocol minimal versus enshrining more features.
In summary,
Minimalism promotes simplicity, flexibility, innovation, and decentralization principles.
Enshrinement can improve efficiency, capabilities, coordination, security, and future-proofing.
But enshrinement also risks more governance disputes, ossifying flexibility, increasing technical debt and centralization, and diverging from minimalist ethos.
As we mentioned earlier, the core tension is between keeping the base Ethereum protocol as minimal as possible versus pragmatically enshrining additional features and functionality directly into the protocol layer.
We would like to address that there are reasonable counterpoints that enshrinement risks compromising Ethereum's core strengths. Layer 1 should focus on what it’s supposed to do - security and data availability. The entire ecosystem relies on that fundamental premise provided by Ethereum. Historically, Ethereum’s strength never came from functionality or usability but from community consensus.
If we look at how the founders build and the community contribute to the overall health and activity of Ethereum, we would like to expand with some additional thoughts:
There is merit to the argument that we should be cautious about adding too many features to the base layer protocol. More complexity and centralized governance/trust are definitely risks. However, we think there are some cases where targeted enshrinement does solve significant problems without too much added complexity, which Vitalik also mentioned.
For example, account abstraction seems to streamline and simplify transactions overall despite adding some protocol logic. Enshrining standards like a common ZK-EVM could drastically reduce duplicated work across rollups and improve interoperability. Low complexity for high reward?
Systemic issues, like fixed costs1, are fundamentally hard to solve with a purely minimal protocol. Enshrining solutions may be necessary in these cases, and we’re certain there are likely other creative minimal enshrinement designs yet to be explored. For example, enabling protocol-level data hints for rollup data availability without dictating details.
Now, Vitalik did dive deep into the potential enshrining of features in the following areas:
At L2IV, we have been closely following the developments & innovations around the following areas from the above table that are poised for growth, and it is not exhaustive.
Zero-knowledge rollups: ZK rollups are poised to be the primary scaling solution for Ethereum layer 2. Enshrining efficient and standardized ZK-EVM proof verification natively will allow rollups to avoid recreating redundant proof systems separately. This simplifies development, improves interoperability between rollup designs, and provides consistency in an important cryptographic component. With a robust ZK-EVM infrastructure enshrined natively, innovators can focus on building robust and interconnected rollup-based ecosystems spanning payments, trades, privacies applications, social platforms, games, data analysis, and more. ZK rollups empower Ethereum to scale exponentially while retaining security guarantees approaching the base layer.
Staking derivatives (LSDfi): tokens representing staked ETH that can be used freely in DeFi and transactions. Natively integrating these into the protocol reduces dependence on specific derivative contracts and their associated risks. Broader access and composability unlock newfound liquidity, allowing staked ETH to be borrowed, lent, traded, used as collateral, and more without compromising PoS security incentives. This explosion in use cases and the deep liquidity of protocol-enshrined staking derivatives can ignite exponential growth in Ethereum's staked asset security and earning potential. Also, Restaking services actively contribute to high data throughput without the computation slowing things down. There’s still a lot of research to be done in this aspect, but we are hopeful.
Data Availability Layers: If Ethereum enshrines more performant data availability primitives, ranging from decentralized storage integrations to fraud proof mechanisms, we could see surging adoption across scalability solutions like ZK rollups and Validium chains, privacy tech like confidential transactions, indispensable infrastructure like archival nodes and indexers, and key innovations like rotational sharding. By natively optimizing solutions relying heavily on efficient data propagation and verification, an entire ecosystem of data-availability-centric applications could flourish, multiplying Ethereum's throughput and capabilities. But restraint is wise - the minimal additions that unlock the most value should be pursued to avoid over-complexifying Ethereum's base layer.
Some other areas we are currently looking at:
Oracles: By natively integrating (enshrining) key components like verifiable randomness, identity mechanisms, historical chain access, trusted hardware, and customized governance, Ethereum could massively expand the capabilities and security of decentralized oracles.
For example, randomness and identity resistance fortify prediction markets, confidential computing enables private queries, efficient proof schemes allow recursive on-chain queries, native governance supports vulnerability bounties, and better chain data archiving benefits oracles requiring historical lookups.
The impact could be immense - with robust native primitives, oracle networks like Chainlink can reliably provide tamper-proof off-chain data at scale to feed smart contracts powering decentralized finance, insurance, games, NFTs, and more. Oracles shift from a problematic bottleneck to a deeply integrated core utility.
Private transactions: Constructing encrypted mempools and privacy-enhancing features directly into the base layer fortifies confidentiality assurances for users, protecting them from front-running and surveillance.
The Road Ahead:
As the end goal is navigating the minimalism vs. enshrinement tradeoff through focused, high-value additions, we believe a proposed strategy to balance these competing needs is adopting a highly selective, incremental approach focused on targeted areas with especially high value.
When considering protocol changes, we should remain disciplined. Additions should demonstrate clear benefits that can't be achieved otherwise. Analyze trade-offs around complexity, decentralization, and flexibility thoroughly.
"Minimal viable enshrinement" should be the mantra - enable functionality without over-defining implementations. Favor flexible primitives over prescriptive specs.
Introduce modular changes optionally when feasible so users/developers can opt-in if helpful.
Overall, we need a culture of restraint. Thoughtfully expand scope only given a compelling rationale that benefits outweigh costs. Ethereum's principles matter as much as its capabilities.
This seems like a targeted, incremental, high-value approach, but we believe it's important to preserve Ethereum’s ethos of decentralization, flexibility, and permissionless innovation as the decentralized future is unknown and, at the same time, unwritten.
As Ethereum continues maturing into its fuller potential, what are your thoughts on how we can best strike the right balance between protocol expansion (enshrinement) and principles preservation (minimalism)? What role does community consensus play in navigating this tension? What can other chains learn from Ethereum’s history?
Find L2IV at l2iterative.com and on Twitter l2iterative
Author: Arhat Bhagwatkar, Research Analyst, L2IV (@0xArhat)
Additional Reads
By fixed costs above, we mean certain functionalities that incur high fixed costs from the beginning, such as Loading and executing commonly used smart contract code. For example, shared account abstraction logic implemented in a contract would need to be loaded by every contract that uses it, costing gas each time. If enshrined natively, it could be accessed with no variable cost, or Rollups implementing DA via contracts also involve fixed costs for things like duplication, storage, and verification, or for ZK proofs or trusted setups, it requires expensive fixed computations if done off-chain.
Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.