Tree is fixed depth 8

[slvrfn]

It appears the tree is of a fixed length of 8. This code appears to be easily modified to produce a tree of variable depth

[TimDaub]

yeah I can't remember anymore what were all steps to increase the size, but it may be as easy as forking and changing the constants on top of the file

[slvrfn]

Excellent thats what i was thinking!

Also, wouldn't this also require updating the bitmap function? I was thinking it would be something like the following for a DEPTH=14:

uint256 constant BUFFER_LENGTH = 1;
uint256 constant DEPTH = 14;
uint256 constant SIZE = (2**DEPTH)-1;

function bitmap(uint256 index) internal pure returns (uint256) {
    uint256 bytePos = (BUFFER_LENGTH - 1) - (index / DEPTH);
    return bytePos + 1 << (index % DEPTH);
}

[slvrfn]

could you also give some insight into what the purpose of BUFFER_LENGTH is?

[TimDaub]

The magic constant "8" in the bitmap, I think, refers to the number of bits present in a byte.

[slvrfn]

if the uint8 is maintained, wouldnt the _bits inside compute get set to all 0's if a DEPTH > 8 is used?

_bits = _bits >> 1;

[TimDaub]

if the uint8 is maintained, wouldnt the _bits inside compute get set to all 0's if a DEPTH > 8 is used?

yes I think so.

I'm currently trying to remember where I got the idea of this code from. How embarrassing! Anyways, I remember parsing the compression and decompression code of Vitalik here and then breaking it down for uint8 values: https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751

Here is code you might find helpful:

• https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/structs/BitMaps.sol
• bitmap transmissions11/solmate#206

[TimDaub]

could you also give some insight into what the purpose of BUFFER_LENGTH is?

no idea anymore. I think it is not significant and potentially badly named so that it's misleading the reader of the code...

[TimDaub]

@slvrfn has your problem been solved?