This post explains the use of Merkle trees in blockchain (specifically Solana), the introduction of a new account hash algorithm, and how it is able to support inclusion/exclusion proofs.
The Agave client currently uses a 16ary merkle tree in order to derive hashes of Account Delta Hash (ADH), which is a hash that encapsulates all account changes in a given block. Merkle trees are used in protocols such as Bitcoin and Ethereum to represent state changes with just a hash (ethereum does somehting more complex ofc). Since Solana slot times are quite low (400ms), merkle trees end up being quite slow for Solana use cases, as it will not scale to support eventually billions of accounts. It will not scale because it requires to hash a ton of zero-lamport accounts (only for eah not adh).
A PR has already been merged of experimental support using the lattice hash for the Epoch Account Hash and the Incremental Account Hash, however, not yet for the Account Delta Hash. The primary reason for this is because of this, which allows rollups to have inclusion proofs using the Account Delta Hash to prove that a state transition has occurred.
The SIMD mentions that Incremental Accounts Hash does not support inclusion and exclusion proofs but after doing some work, I think it does, allowing for the Incremental Accounts Hash to be able to eventually replace the ADH without any repurcussions.
Agave has been looking for an alternative accounts-db hash algorithm due to the speed of creating a merkle tree root with its block speeds
The LtHash uses BLAKE3 for its hasher
To start, you need to create an accumulator to be able to derive the lattice hash.