Replace or improve blake2b-py dependency

[MatthiasLohr]

• py-evm Version: 0.3.0a19
• OS: linux
• Python Version: Python 3.9.0rc1

What is wrong?

py-evm depends on blake2b-py, which looks quite unmaintained. The PyPI package for blake2b-py comes with some prebuilt binaries, however for e.g. Python 3.9 or support on ARM architectures (Raspberry Pi) the only chance is to have it compiled. This requires to install the whole Rust toolchain to get it compiled (including: CI/CD stuff, there we would theoretically have to compile it for each commit!).

How it could be fixed?

For this reason I want to open the discussion, if there might be the chance to rely on another library for the required functionalities. Currently, some people including me are trying to reach the maintainer to get access to update the project, but for now there is no reaction from the maintainer.

I'm looking forward to your opinions.

[fubuloubu]

Blake2 was added 4 years ago to hashlib (3.6+), and should be considered for updating this library moving forwards.

[fubuloubu]

After doing some digging, I noticed that this was indeed the way this was attempted before (see #1818), but it proved too slow (see #1836) to use in practice for the Trinity client. In either case, my suggestion to use the hashlib implementation was indeed not viable given the reasoning in those two issues.

However, since the Trinity client became obsolesced rather recently (reducing the necessity for sync-viable speed of this algorithm), and the numerous reported issues users have had setting up the Rust library on different platforms (see https://github.com/ethereum/blake2b-py/issues), as well as the problem that this issue notes about lack of support for blake2b-py... perhaps it would be time to reconsider this decision and move py-evm back to the slower native python implementation in order to reduce dependency and maintenance issues.

[MatthiasLohr]

What about making blake2b-py an optional dependency? So, if you install py-evm via pip install py-evm it will use the (slow, but struggle-free) hashlib implementation, if you use pip install py-evm[blake2b-py] it will additionally install the (faster, but maybe annoying setup required) rust-based variant. And the code has then to detect if blake2b-py is installed, if yes it will use it, if no it will fall back to hashlib.

Any thoughts on that?

[cburgdorf]

What about making blake2b-py an optional dependency

Yes, I think that's the way to go. We've used that pattern before and it works well.

[fubuloubu]

What about making blake2b-py an optional dependency

Yes, I think that's the way to go. We've used that pattern before and it works well.

One thing to note is that the problem arises from eth-tester using py-evm when installed via web3[tester], so the optional has to bubble up 2 levels to web3 for it to work. e.g. py-evm[blake2b-py], eth-tester[py-evm,blake2-py] and web3[tester,blake2b-py]