Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.
- Ethereum Foundation
Part of what makes Ethereum magical is the network in which hundreds or sometimes thousands of developers come together and discuss improvements to Ethereum. Topics range from small details like EIP-6789: Rename
mana to serious discussions as seen in EIP-5749: The ‘window.evmproviders’ object. Discussed on the Ethereum Magicians forum, the community slowly coalesces towards an agreement and builds improvements into Ethereum.
While powerful, this improvement mechanism has a big drawback.
Even hotly anticipated EIPs can bog down due to small technical details and lose steam during lengthy debates.
Thankfully, Caldera enables developers to implement and access proposals on their own chain — essentially creating a fork of the original. Rather than waiting for the dust to settle, developers can bring the benefits of the proposal to users immediately.
In this post, we’ll talk about some of the most anticipated EIPs and ERCs.
ERC 4337, account abstraction, is one of the most important latest improvements to Ethereum. ERC 4337 abstracts authentication, authorization, replay protection, gas payment, batching, and atomicity.
For most users, the main difference will be more powerful identity verification for wallets. Instead of authentication via public and private keys, wallets now support authentication with fingerprint, face scan, and even social account recovery.
The next billion users are not going to write 12 words on a piece of paper. Normal people don’t do that. We need to give them better usability, they shouldn’t need to think about cryptographic keys.
- Yoav Weiss
Specifically, ERC 4337 introduces a higher-layer pseudo-transaction object called a
UserOperation objects are sent into a separate mempool (waiting area for transactions before being added to a block). From there, bundlers (a special class of actor) package these objections into a transaction, which gets included in a block.
This new step merges Externally Owned Accounts (EOA) and contract accounts into one. Most Ethereum users today use services like Metamask to create and maintain EOAs. These EOAs are free to create, can initiate transactions, and authenticate via a cryptographic pair of keys.
More advanced users and developers create Contract Accounts. Contract accounts incur some costs upon creation, can only send transactions in response to receiving a transaction, and authenticate via the logic specified by smart contract code.
By bringing these two account types into one, wallets can now transact and create smart contracts without depending on centralized relayers.
Beyond new authentication methods, this also means bundled transactions which save time and lower transaction fees. Developers can even chose to partially or fully subsidize transaction fees for users for faster and broader adoption.
Although EIP 4337 was first proposed in September 2021, implementation took place earlier this year in March 2023 - a full year and a half of delay. Today (April 2023), ERC 4337 is deployed on Ethereum, Polygon, Optimistic, and Avalanche (testnet).
EIP 2537 adds nine precompile arithmetic operations to Ethereum, making it possible to implement the BLS12-381 curve.
At a high level, using the BLS12-381 curve as opposed to the current BN254 curve means greater security and more transactions in one zero-knowledge circuit, all with the same verification costs.
Before we dive into the use cases of BLS12-381, let’s first cover why we need elliptical curves.
The basic premise behind elliptical curves (and the broader cryptography science) is that it’s easier to compute in one direction than the other. For example, if given a point
P on some elliptical curve, we can multiply it by some random factor
x to get a new point
P2 — it boils down to basic multiplication (with some modulo). However, if we’re given point
P2 and point
P, it’s significantly more difficult to find the factor
Ethereum already uses an elliptical curve: BN254, which we mentioned above. When BN254 was initially implemented, the implied security of the curve was 128 bits (though over time that has dropped to 100).
While the security of BLS12-381 is still 128 bits, encryption is almost twice as fast as BN254 with a circuit size of 2^32 bits rather than 2^28 of BN254.
Higher security combined with a larger circuit size is extremely important to the future development of Ethereum. For example, zkSNARKs developers can now batch more transactions into one while keeping computational costs the same as before. In other words, a developer/DAO can verify a large number of signatures from participants quickly and efficiently.
EIP 2537 doesn’t advocate for BLS12-381 to replace BN254 entirely. Rather, it adds precompile operations such as basic point addition, point multiplication, and multi-exponentiation that make it possible for developers to build using BLS12-381 in addition to BN254.
At the moment, EIP 2537 is stagnant. While there were discussions of incorporating it into the Shanghai upgrade, the EIP was ultimately left out. The last comment on the discussion was made on January 19th, 2023.
EIP 5988 introduces a new precompiled contract that supports various Poseidon parameters.
Poseidon is an arithmetic hash function that is designed specifically for Zero-Knowledge Proof Systems (zk). That leads to better compatibility with zk and validity rollups through more efficient verification of proofs, while also helping native zk operations. If implemented, this EIP should lead to lower costs for L2 networks.
Although the EIP initially drew wide attention (with even Vitalik chiming in), progress has paused. The last update was on February 2nd, 2023.
The main missing piece here seems to be the MDS matrix and the round constants. Since the precompile is intended to be arbitrary-size, we can’t just save the round constants in the precompile as we do with SHA256, RIPEMD160, etc, we have to generate them.
A large sticking point to the adoption of EIP-3988 is the decreasing costs in lookups and hashing. That means the problem that Poseidon is meant to solve, more efficient hashing, is losing importance. Combined with the added complexity of implementing various parameters that are needed with Poseidon (prime field modulus, size of input, number of full rounds, number of partial rounds), this EIP is less suited for an L1 chain like Ethereum and better for L2 chains.
For example, Loopring uses Poseidon for private trading on Ethereum and Polygon uses Poseidon for Hermez ZK-EVM.
While many of these EIP’s are exciting developments for the Ethereum protocol, it’s unclear when they’ll become re-prioritized and included in subsequent updates. But thankfully, you don’t have to wait for these updates to include them into your specific chain with Caldera.
We help projects launch performant, customizable L2 rollups that can merge and instantly utilize pending EIPs. Reach out to us if you’re interested in implementing these, other EIP’s, or other custom protocol features as part of your chain.