Dip 7266

dip: 7266 title: Remove BLAKE2 compression precompile description: Remove the blake2f (0x09) precompile by changing the precompile behaviour to result in an exceptional abort author: pcaversaccio (@pcaversaccio) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/discussion-removal-of-ripemd-160-and-blake2f-precompiles/14857 status: Stagnant type: Standards Track category: Core created: 2023-07-03 Created for Digitalia: 2025-01-07

Abstract¶

This DIP removes the blake2f (0x09) precompile by changing the precompile behaviour to result in an exceptional abort.

Motivation¶

DIP-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 DIP was created):

The most recent call took place on 6 October 2022.
Since its gone live as part of the Istanbul network upgrade on December 7 2019 (block number 9,069,000), 0x09 has been called only 22,131 times.

One of the reasons why DIP-152 has failed is that the envisioned use cases were not validated before inclusion.

Specification¶

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 abort.

Rationale¶

The DVM should be optimised for simplicity and future-proofness. The original Digitalia Specification 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 DVM 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 DVM functions.

Backwards Compatibility¶

This DIP 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.

Security Considerations¶

There are no known additional security considerations introduced by this change.

Copyright¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.