The Splurge
The Splurge
.
.
.
specification
EOA
conversion
enshrining
arithmetic
improvements
EVM
EIP-1559
account
abstraction
crypto (eg.
obfuscation)
encrypted
EIP-1559
August 5, 2021
EIP-1559 implemented a hybrid transaction fee mechanism in Ethereum,
instituting a base fee per block that was burned and a priority fee for validator incentivization.
The base fee was dynamically adjusted each block, targeting a consistent 50% capacity utilization
to reduce transaction fee volatility and improve network efficiency.
Designed to create a more predictable fee structure, this approach aimed to align Ethereum's economic activity with
its token value by diminishing supply, while ensuring validators were
compensated for including transactions through the priority fee.
There are aspirations to enhance EIP-1559 in the future.
Resources
ERC-4337 Specification
March 1, 2023
ERC-4337 is an Account Abstraction standard, and is not a hard fork requiring EIP. Where an EIP requires changes to the Ethereum protocol itself, an ERC, such as ERC-20 (for tokens),
proposes standards for contracts on the Ethereum blockchain that operate within the existing framework.
Instead of introducing new core features and altering the foundational transaction type,
ERC-4337 presents a novel approach through a higher-layer mechanism.
This approach utilizes a pseudo-transaction object called a UserOperation.
Users transmit these UserOperation objects to a new, distinct mempool.
From there, entities known as bundlers aggregate these objects into a single transaction by invoking a specialized contract.
This consolidated transaction is then incorporated into a block as usual.
Resources
ERC-4337
March 1, 2023
ERC-4337 is an Account Abstraction standard, and is not a hard fork requiring EIP. Where an EIP requires changes to the Ethereum protocol itself, an ERC, such as ERC-20 (for tokens),
proposes standards for contracts on the Ethereum blockchain that operate within the existing framework.
Instead of introducing new core features and altering the foundational transaction type,
ERC-4337 presents a novel approach through a higher-layer mechanism.
This approach utilizes a pseudo-transaction object called a UserOperation.
Users transmit these UserOperation objects to a new, distinct mempool.
From there, entities known as bundlers aggregate these objects into a single transaction by invoking a specialized contract.
This consolidated transaction is then incorporated into a block as usual.
Resources
Voluntary EOA Conversion
Soon | Prague - Electra
ERC-4337 probably isn't going to be enshrined in the protocol anymore. Instead Core Devs have decided to include
EIP-7702 in the Prague-Electra hard fork, which will allow externally owned accounts to delegate control to a smart contract.
Therefore, EIP-7702 covers two steps in published roadmap: it allows for voluntary EOA conversion, and that conversion is enshrined in the protocol. It is likely that EIP-7702 conversions will enhance the existing
ERC-4337 standard, by more easily allowing existing EOAs to convert to the aforementioned ERC standard.
Resources
In-Protocol Enshrining
Soon | Prague - Electra
ERC-4337 probably isn't going to be enshrined in the protocol anymore. Instead Core Devs have decided to include
EIP-7702 in the Prague-Electra hard fork, which will allow externally owned accounts to delegate control to a smart contract.
Therefore, EIP-7702 covers two steps in published roadmap: it allows for voluntary EOA conversion, and that conversion is enshrined in the protocol. It is likely that EIP-7702 conversions will enhance the existing
ERC-4337 standard, by more easily allowing existing EOAs to convert to the aforementioned ERC standard.
Resources
Endgame Account Abstraction
Ongoing Research
Nobody is going to agree 100% on what this should look like, but there are core goals nearly everybody is hoping to achieve.
- We want to greatly simplify onboarding to give everybody access to Ethereum, irrespective of technical capabilities.
- We want to give existing EOA accounts the ability to convert to this simplified form of account management.
- We want to limit the scale and scope of inadvertent permissions granting during these migrations.
- We want want your grandma on-chain.
In practice, it's looking the primary solution will be a combination of ERC-4337, and some opcode enshrinements in the Prague-Electra hard fork.
Resources
EOF
Awaiting Inclusion
Ethereum Object Format (EOF) is inspired by the concept of "object file formats" in traditional programming,
where an object file is a structured representation of machine code and data that's ready for use by the system. EOF aims to bring a similar structured approach to the EVM,
organizing the bytecode of smart contracts into distinct, systematic sections for code, data, and other types. This structure contrasts with the current format,
where such distinctions are less clear and systematic.
In EOF, this structured format would not only allow for more modular and efficient processing of smart contracts within the EVM,
but would also introduce versioning like object file formats in computing.
The format would support new functionalities like improved control flow operations and stack validation,
and enhance the overall efficiency and robustness of Ethereum's infrastructure.
This improvement track is made up on 8 EIPs that have been thoroughly researched, and are awaiting inclusion in a future hard fork.
Resources
Big Modular Arithmetic
Ongoing Research
Optimizing cryptographic operations that rely on modular arithmetic over very large numbers could increase efficiency by reducing computational costs and speeding up transaction processing when implemented directly in the EVM.
This enhancement could benefit various applications within the Ethereum ecosystem, such as zero-knowledge proofs and digital signatures, by improving the performance and scalability of cryptographic operations. This would support the network’s goals of increasing efficiency and supporting more complex decentralized applications.
Resources
Further EVM Improvements
Ongoing Research
This is a catch all roadmap item. The EVM is Turing complete, but Solidity is not the easiest language to use, and it has its inefficiencies.
To that end, we want to add and remove opcodes, or make other improvements as we can.
Resources
- -
Endgame EVM
Ongoing Research
Endgame EVM refers to the ultimate vision for optimizing the EVM to achieve peak performance, security, and scalability. This initiative aims to enhance the execution of smart contracts, making them faster and more efficient. By streamlining these processes, Ethereum can reduce the computational resources required for transactions.
EOF will go a long way to solving many of the EVM's original sins, and will hopefully help developers have an easier time making dApps.
Resources
- -
Endgame EIP-1559
Ongoing Research
Multidimensional EIP 1559 would improve resource management in the EVM by introducing separate basefees and limits for different resources, such as EVM execution, transaction calldata, witness data, and storage size growth. Each resource would have its own burst limit and sustained target, addressing inefficiencies in the current system where all resources are combined into a single gas metric.
Vitalik's proposal outlines two options: one retains the current gas system with adjusted prices for special resources, while the other eliminates the block gas limit, using only resource-specific limits.
Resources
Explore Deep Crypto
Ongoing Research
Explore Deep Cryptography involves staying up-to-date with the latest advancements in cryptographic techniques and integrating them into Ethereum’s cryptoeconomic structures. This initiative could include exploring advanced methods like obfuscation for enhancing privacy, fully homomorphic encryption for creating encrypted mempools, and one-shot signatures for eliminating slashing or implementing “quantum cash.”
Obfuscation can make transactions and smart contract data private, fully homomorphic encryption allows computations on encrypted data without decryption, and one-shot signatures offer new ways to handle consensus and security, potentially paving the way for more resilient cryptoeconomic models.
Resources
Explore Delay Encryption
Ongoing Research
Explore Delay Encryption involves using encrypted mempools to mitigate MEV and censorship in Ethereum. Users submit encrypted transactions, which block producers commit to before decrypting and executing. This prevents front-running and makes censorship difficult, as excluding all encrypted transactions would be costly.
Several methods ensure guaranteed decryption without user dependency: trusted parties, trusted hardware, and threshold encryption by a committee. These techniques secure transactions against MEV and censorship while maintaining the integrity and security of the network.
Resources
VDFs
Ongoing Research
Verifiable Delay Functions (VDFs) are being explored as a strategy to enhance the randomness used in Ethereum’s consensus. A VDF requires a significant amount of non-parallelizable work to compute but can be verified very quickly. This makes VDFs ideal for generating entropy for validator and committee selection, as they are resistant to manipulation and do not depend on a specific fraction of nodes being online.
A common example of a VDF is the iterated modular square root, where each computation step depends on the previous result, preventing parallelization. VDFs offer several advantages over other randomness schemes like RANDAO or BLS threshold signatures, including simpler setup procedures and increased resistance to manipulation. However, the possibility of attackers using ASICs to gain a speed advantage remains a concern. To mitigate this, the design must balance the computation and verification times to effectively resist such attacks within Ethereum’s ecosystem.