Zac made a good point. We can copy the optimisation we made to the nullifier tree (converting it from a sparse tree to an indexed tree) with the public data tree.
Note a difference:
The nullifier tree has leaves of the form:
value,
next_index, // points to the index of the leaf which contains the next-highest value
next_value, // the value of the leaf at leaf_index = next_index
The public data tree's leaf will also need to contain a 'key' field. In its sparse version, the key is the leaf_index, but when we migrate to an indexed tree, the leaf_index loses such a meaning, so the key needs to become part of the leaf's preimage. Note, we don't include a key in a nullifier tree leaf's preimage, because in the sparse version of the nullifier tree, the key and the value were always equal!
key,
value,
next_index,
next_value,
Note: this will be fiddly to do, and since it's only an optimisation (which only really 'bites' when we're generating actual proofs), I'd be in favour of deferring this task until after we've built out other features for the local developer testnet.
Zac made a good point. We can copy the optimisation we made to the nullifier tree (converting it from a sparse tree to an indexed tree) with the public data tree.
Note a difference:
The nullifier tree has leaves of the form:
The public data tree's leaf will also need to contain a 'key' field. In its sparse version, the key is the leaf_index, but when we migrate to an indexed tree, the leaf_index loses such a meaning, so the key needs to become part of the leaf's preimage. Note, we don't include a key in a nullifier tree leaf's preimage, because in the sparse version of the nullifier tree, the key and the value were always equal!
Note: this will be fiddly to do, and since it's only an optimisation (which only really 'bites' when we're generating actual proofs), I'd be in favour of deferring this task until after we've built out other features for the local developer testnet.