This EIP removes the blake2f (0x09) precompile by changing the precompile behaviour to result in an exceptional abort.
EIP-152 has never capitalised on a real-world use case. This fact is clearly reflected in the number of times the address 0x09 has been invoked (numbers from the date this EIP was created):
0x09 has been called only 22,131 times.One of the reasons why EIP-152 has failed is that the envisioned use cases were not validated before inclusion.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
All CALL, CALLCODE, DELEGATECALL, and STATICCALL invocations to the blake2f precompile address 0x09 MUST result in an exceptional halting state that consumes all supplied gas and returns no data.
The EVM should be optimised for simplicity and future-proofness. The original Yellow Paper states: these are so-called 'precompiled' contracts, meant as a preliminary piece of architecture that may later become native extensions. Considering that no use cases have been realised in the last 3.5 years, we can conclude that the precompile blake2f (0x09) will never transition into a native opcode. In that sense, the precompile blake2f (0x09) is an obsolete carry-along with no real-world traction and thus should be removed. This removal will simplify the EVM to the extent that it only consists of clear instructions with real-world use cases. Eventually, the precompile blake2f (0x09) can be safely used as a test run for the phase-out and removal of EVM functions.
This EIP requires a hard fork as it modifies the consensus rules. Note that very few applications are affected by this change and a lead time of 6-12 months can be considered sufficient.
There are no known additional security considerations introduced by this change.
Copyright and related rights waived via CC0.