Skip to content

Latest commit

 

History

History
61 lines (42 loc) · 4.88 KB

README.md

File metadata and controls

61 lines (42 loc) · 4.88 KB
Raw
ACP 131
Title Activate Cancun EIPs on C-Chain and Subnet-EVM chains
Author(s) Darioush Jalali (@darioush), Ceyhun Onur (@ceyonur)
Status Implementable (Discussion)
Track Standards, Subnet

Abstract

Enable new EVM opcodes and opcode changes in accordance with the following EIPs on the Avalanche C-Chain and Subnet-EVM chains:

Note blob transactions from EIP-4844 are excluded and blocks containing them will still be considered invalid.

Motivation

The listed EIPs were activated on Ethereum mainnet as part of the Cancun upgrade. This proposal is to activate them on the Avalanche C-Chain in the next network upgrade, to maintain compatibility with upstream EVM tooling, infrastructure, and developer experience (e.g., Solidity compiler defaults >= 0.8.25). Additionally, it recommends the activation of the same EIPs on Subnet-EVM chains.

Specification & Reference Implementation

The opcodes (EVM exceution modifications) and block header modifications should be adopted as specified in the EIPs themselves. Other changes such as enabling new transaction types or mempool modifications are not in scope (specifically blob transactions from EIP-4844 are excluded and blocks containing them are considered invalid). ANCs (Avalanche Network Clients) can adopt the implementation as specified in the coreth repository, which was adopted from the go-ethereum v1.13.8 release in this PR. In particular, note the following code:

  • Activation of new opcodes
  • Activation of Cancun in next Avalanche upgrade:
  • ParentBeaconRoot is enforced to be included and the zero value here. This field is retained for future use and compatibility with upstream tooling.
  • Forbids blob transactions by enforcing BlobGasUsed to be 0 here.

Note: Subnets are sovereign in regards to their validator set and state transition rules, and can choose to opt out of this proposal by making a code change in their respective Subnet-EVM client.

Backwards Compatibility

The original EIP authors highlighted the following considerations. For full details, refer to the original EIPs:

  • EIP-4844: Blob transactions are not proposed to be enabled on Avalanche, so concerns related to mempool or transaction data availability are not applicable.
  • EIP-6780 "Contracts that depended on re-deploying contracts at the same address using CREATE2 (after a SELFDESTRUCT) will no longer function properly if the created contract does not call SELFDESTRUCT within the same transaction."

Adoption of this ACP modifies consensus rules for the C-Chain, therefore it requires a network upgrade. It is recommended that Subnet-EVM chains also adopt this ACP and follow the same upgrade time as Avalanche's next network upgrade.

Security Considerations

Refer to the original EIPs for security considerations:

Open Questions

No open questions.

Copyright

Copyright and related rights waived via CC0.