EIPs for Pectra - Erigon’s stand
The members of the Erigon Team have considered the Pectra candidates, over and above the already included ones.
The EIPs have been categorized as “Favour”, “Neutral”, and “Against”. The following is a summary of our perspectives on these EIPs:
| EIP | Comments |
|---|---|
| [Favour] EOF |
- Speeds up EVM by eliminating the need for the jump destination analysis - Opens the way for potential future improvements such as EVMMAX |
| [Favour] EIP-3074: AUTH and AUTHCALL opcodes |
- A good step towards account abstraction and working around things like sponsored transactions - Better than alternative EIPs in the direction |
| [Neutral] EIP-2935: Save historical block hashes in state |
- Good for light clients - a step towards including ETH protocol within the state - Not urgent - Likely to be modified later to include changes/hacks for Verkle |
| [Neutral] EIP-7212: Precompile for secp256r1 curve support |
- Has applicability for the listed protocols (Apple’s secure enclave, passkeys, android keystore, etc.) and may welcome developers to build efficient apps around them - May not be popular enough yet, viz. a viz Ethereum application |
| [Neutral] EIP-7547: Inclusion lists |
- We do support the idea of having a feature to work around the possible censorship of transactions - Given the practical scenario of proposer-builder separation, this is a welcome step. We also don’t necessarily think that MEV alone can lead to exclusion of transactions |
| [Against] 5806: Delegate Transaction |
- The storage problem could create a bad UX |
| [Against] 5920: PAY opcode |
- This goes against the assumptions of most smart contracts, where something is supposed to be triggered in response to an incoming value transaction |
| [Against] EIP-6404, EIP-6465, EIP-6466 SSZ-(Transaction /Withdrawals /Receipts root) |
- The change in the formats introduces unnecessary additional complexity for the hard fork in terms of data formats, associated tests and many challenges of debugging |
| [Against] EIP-6913: SETCODE instruction |
- Goes against Ethereum’s principles in general - Introduces challenges in UX as it makes it possible to change contracts even beyond known upgrade patterns |
| [Against] EIP-6914: Reuse validator indices |
- Messes up the flow in the code for maintaining the state and indices, especially for historical indices |
| [Against] EIP-7377: Migration Transaction |
- Allowing EOAs to deploy smart contracts onto their accounts is a convoluted task, considering factors like security and upgradeability of general complexities of smart contracts. Potentially dangerous with not many upsides |
| [Against] EIP-7545: Verkle proof verification precompile |
- This should be done in the same upgrade as Verkle (Osaka). Otherwise, it can bind us to a potentially suboptimal early design |
| [Against] EIP-7609: Decrease base cost of TLOAD/TSTORE |
- The updated costs are too low |