The tendermock from charlycst

Proof for key that is overwritten twice is incorrect

Hi,
I just noticed that proofs for keys that are overwritten twice are incorrect and fail to verify using verify_membership().
Here's a failing test ->

fn key_overwrite() {
    let mut tree = AvlTree::new();
    tree.insert("K", [1]);
    tree.insert("K", [0]);
    tree.insert("K", [2]);

    assert!(check_integrity(&tree.root));

    let root = tree
        .root_hash()
        .expect("Unable to retrieve root hash")
        .as_bytes()
        .to_vec();
    let proof = tree
        .get_proof("K")
        .expect("Unable to retrieve a proof for 'K'");
    let spec = get_proof_spec();
    assert!(verify_membership(
        &proof,
        &spec,
        &root,
        "K".as_bytes(),
        &[0]
    ));
}

Testing ibc-rs relayer with ibc-mock

General workflow for running the ibc-rs relayer and testing against ibc-mock.

Use a relayer configuration file, similar to relayer/tests/config/fixtures/relayer_conf_example.toml.
Start two instances of ibc-mock

It is important to use the same ports as the relayer will be using, specifically 26657/9090 for first chain and 26557/9091 for the second chain:

ibc-mock $ cargo run -- -c config/config.example.json -v -j 26657 -g 9090

ibc-mock $ cargo run -- -c config/config.example.json -v -j 26557 -g 9091

Prepare the relayer. In directory ibc-rs, do the following:

# remove any lingering data
rm -rf data0/*
rm -rf data1/*

# remove all light clients for each chain, the '-c' parameter must correspond to the chain identifier in the relayer_conf_example.toml file:
cargo run --bin relayer -- -c relayer_conf_example.toml light rm -c chain_A --all -y
cargo run --bin relayer -- -c relayer_conf_example.toml light rm -c chain_B --all -y

# setup primary light client peers for each chain
cargo run --bin relayer -- -c relayer_conf_example.toml light add localhost:26657 -c chain_A -f -p -s data0 -y
cargo run --bin relayer -- -c relayer_conf_example.toml light add localhost:26557 -c chain_B -f -p -s data1 -y

# setup witness peers for the light clients (note: the precise peer ids are not important here):
cargo run --bin relayer --  -c relayer_conf_example.toml light add localhost:26657 -c chain_A -s data0 -y --peer-id 5CD00153B35C4811D29736BF7C1B825056BED454
cargo run --bin relayer --  -c relayer_conf_example.toml light add localhost:26557 -c chain_B -s data1 -y --peer-id 8C16EEB6C01698F62E2359C6250FDB965FC2A89B

# register the key seed files for each chain
# download the file from https://gist.github.com/adizere/f17ea650de7d9256edfeee248fe22b18 and save as 'key_seed.json'
# we'll use the same key seed for both chains
cargo run --bin relayer -- -c relayer_conf_example.toml keys add chain_A key_seed.json
cargo run --bin relayer -- -c relayer_conf_example.toml keys add chain_B key_seed.json

start the relayer

for example create a client on chain A, the client identifier should be printed to the screen

cargo run --bin relayer --  -c relayer_conf_example.toml tx raw create-client chain_A chain_B

and updating the client on chain A

cargo run --bin relayer --  -c relayer_conf_example.toml tx raw update-client chain_A chain_B {CLIENT_ID}

charlycst / tendermock Goto Github PK

tendermock's People

Contributors

Stargazers

Watchers

Forkers

tendermock's Issues

Proof for key that is overwritten twice is incorrect

Testing ibc-rs relayer with ibc-mock

General workflow for running the ibc-rs relayer and testing against ibc-mock.

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent