Optimize Commitment Computation Logic in Besu-Verkle-Trie

[neotheprogramist]

Description:
There's a need to optimize how commitments are computed and cached. The goal is to ensure that commitments are only recomputed when necessary. The current implementation has the following limitations:

• The HashVisitor returns a cached value if a node is not dirty (unchanged since the last database write) and if the commitment is non-empty. However, this doesn't account for situations where other attributes have changed or if the commitment itself needs an update.
• Calling getRootHash() consecutively leads to unnecessary recomputation of the hash, which is inefficient.

To address these issues, it's proposed to distinguish between a node being up-to-date in the database and its commitment being current. Specifically, the commitment should be reset to empty whenever it's out-of-sync.

Expected Behavior:

1. Testing: Develop a test case demonstrating that commitments are not recalculated between two consecutive calls to getRootHash(). The test could involve calling getRootHash(), altering the commitment to an incorrect value, and then calling getRootHash() again to verify that it returns the modified (incorrect) value.
2. Code Modifications:
   • Update PutVisitor to set the commitment of a leaf node to empty whenever the leaf is modified.
   • Adjust RemoveVisitor to ensure that commitments are set to empty whenever a leaf node is removed.

This change aims to improve the efficiency of commitment calculations and ensure accurate state management within the Besu-Verkle-Trie project.

[thomas-quadratic]

Let me add a little clarification/remark: when we say Update PutVisitor to set the commitment of a leaf node to empty whenever the leaf is modified.

A leafnode does not have a commitment, it is only a key-value pair. But if the leaf's value is modified, commitments of its parent nodes must all be reset