New merkle tree that is compatible with ICS23 / IBC proofs #279
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
pls update wasm |
tzemanovic
reviewed
Aug 8, 2022
tzemanovic
previously approved these changes
Aug 8, 2022
There was a problem hiding this comment.
LGTM! (it looks like it needs fmt, we can base this on #250 to get a working CI on this)
yito88
previously approved these changes
Aug 9, 2022
|
pls update wasm |
tzemanovic
force-pushed
the
bat/new-merkle-tree
branch
3 times, most recently
from
6752ebb to
e617cf9
Compare
|
for some reason the CI is not running on the last commit after rebase |
…ts (instead of changing the tests)
…ded professionalization and I made a change to minimize heap allocations and vector copies
…d non-existence proofs
tzemanovic
force-pushed
the
bat/new-merkle-tree
branch
from
ecdb8ec to
b6b6491
Compare
tzemanovic
added a commit
that referenced
this pull request
Aug 29, 2022
* bat/new-merkle-tree: changelog: add #279 apps/dev-deps: remove unused cargo-watch update checksums wasm [fix]: Fixed a small bug in existence proofs [fix]: Updated Cargo.lock files [feat]: Change the ibc-leaf-spec to be the same for both existence and non-existence proofs [fix]: Updating the .lock file [feat]: Downstreaming changes from arse-merkle-tree. That library needed professionalization and I made a change to minimize heap allocations and vector copies [fix]: Fixed map of ibc keys into fixed keyspace and fixed tests [fix]: Fixed new merkle trees to be compatible with existing unit tests (instead of changing the tests) [fix]: Fixed the proof specs. Tests now passing [feat]: Integrated in new merkle tree for ibc. Proofs are not correct yet
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #92
depends on #351
We are using a new implementation of merkle trees from our sparse-merkle-tree fork (this is also worth reviewing). The merkle tree uses a fixed key space (parameterized by a const set at compile time), but does not give any particular mapping from the app side key space into the tree's key space. Before, this mapping was given by a hash function. Now it is up to the application side to make this choice.
For the IBC subtree, our keys are strings, so the function we use is utf8 encodings which are right padded with 0xFF (an invalid utf8 character) to fill out a 120 byte array. (This 120 can be changed later). Then every byte is incremented by one, modulo 256. This is an order preserving, collision resistant mapping. It's not randomizing across the codomain however, so there is still reason to switch back to a tradition SMT once possible.
Our other subtrees use a Sha256 hash to map into their respective keyspaces. We have ensured that inclusion proofs works for all trees. Futhermore, non-inclusion proofs have been tested and verified for the IBC subtree.