Deprecate support for BMPT

[frisitano]

Describe the feature

Several modifications in our fork of reth are required to support Scroll's state representation. This results in a significant diff with upstream and extensive conflicts when merging upstream. We should decide on a specific point at which we should deprecate support for the BMPT and scroll account modifications. I propose that we do this once Milestone 2 is complete.

Additional context

No response

[frisitano]

I don't think we should deprecate support for bmpt completely but we should remove Poseidon hashing and remove non-native fields from the Account type. This will remove the need for the scroll flag and allow the StateCommitment abstraction to be much cleaner.

[greged93]

If we remove the additional account fields and the Poseidon hash, don't we just end up with the exact same state commitment as Ethereum?

[frisitano]

No, the main difference will be in the arity of the branch nodes. The Ethereum tree has branches that can have 16 children nodes. The binary tree has branches that can only have 2 children. We will need to put the bit packing / unpacking with the HashBuilder of the BMPT following the removal of pack_bits and unpack_bits from the rest of the codebase. Additionally, the Ethereum MPT uses rlp to encode nodes, whereas the current BMPT implementation uses raw hashing of the nodes. We will likely have to modify the specification in the future.

[frisitano]

After thinking through this a little more, I think we should deprecate the bmpt completely. Efforts will likely be needed to make it functional in its current state. If we decide we want to contribute/support the bmpt in the future we can always reintroduce it easily.