SIMD-0215 records a 2^81 collision attack on the accounts hash and explains why it cannot be built
Victoria Shinder2 min readA commit to the Solana improvement documents repository rewrites the security section of SIMD-0215, the Accounts Lattice Hash proposal. The previous text was one sentence: LtHash instantiated with BLAKE3 and a 2048-byte output provides the desired 128-bit security. The replacement is twenty lines, and it is considerably more useful.
The parameters are now stated: 1024 sixteen-bit elements with arithmetic modulo 2^16, chosen to target 128-bit collision security. Then the part that prompted the rewrite. A subsequent analysis describes a collision attack on exactly these parameters with an expected cost of approximately 2^81 hash queries, with upper bounds of 2^101 binary operations and 2^88.45 bits of peak memory including the records needed to recover the colliding sets. The document says plainly that the reported query complexity is below 2^128, and that the evaluated attack remains impractical.
The second argument is the structural one. With the evaluated attack parameters the two colliding sets contain at least 550^8 items, roughly 2^72.83. Only accounts with nonzero lamport balances contribute to the Accounts Lattice Hash, and since total capitalisation must fit in a u64, a single account state holds at most 2^64 - 1 such accounts — two valid states together, fewer than 2^65. The colliding sets are therefore too large to represent two valid account states.
What it means
This is what a good security note looks like, and it is worth holding up as an example. The honest thing about it is the admission: the published parameters do not deliver the 128-bit figure the original sentence claimed, and the document now says so with the exponent attached. Replacing a round assurance with a number that is lower than the round assurance is the hard direction for a specification to move.
The defence is then made on the right axis. Rather than arguing the attack is expensive — 2^81 queries is expensive, but that is an argument with a shelf life — the note shows that the objects the attack produces cannot be account states, because a valid ledger cannot contain that many funded accounts. That constraint comes from the u64 capitalisation bound, not from cryptography, and it does not weaken as hardware improves.
For validator operators nothing changes today; the proposal's own compatibility note already says this changes the bank hash and therefore consensus. What changes is the quality of the reasoning available to anyone auditing the design, and that is the part usually missing.