Discussion: Removal of `RIPEMD-160` and `blake2f` Precompiles

[pcaversaccio]

@prestwich

ripemd160 is a launch feature of the EVM, and its implementation in geth is about 20 lines, because it’s simply delegated to the go std library. Why do you think it’s “tech debt”?

The EVM should be optimised for simplicity and future-proofness. Mostly unused legacy code should not be supported at one point since it can lead to further maintenance issues and unnecessary additional complexity for (future) EVM implementations (an example). Also, the mentioned ripemd160 is deprecated and not optimised anyways. Thus, I think it’s “debt” in the sense, that it’s an unnecessary carry-along.

@prestwich

Inserting bytecode is a lot more debt than leaving the precompile in, as it requires permanent HF code paths to insert a static program into state at a configurable height. The work on that feature alone is far more risky than just not touching the precompile.

Agreed.

@prestwich

For blake2f, we have a high degree of confidence that no running application is using it. We should favor changing the precompile behavior to be a dataless revert and give passive applications that rely on it a 6-12 month lead time.

Sounds reasonable to me.