Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add grandpa justifications mock rpc #695

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

qiweiii
Copy link
Member

@qiweiii qiweiii commented Mar 15, 2024

add

  • grandpa_subscribeJustifications
  • grandpa_unsubscribeJustifications
  • state_getReadProof

@qiweiii
Copy link
Member Author

qiweiii commented Mar 15, 2024

is this impl what we expect? @xlc

@qiweiii
Copy link
Member Author

qiweiii commented Mar 15, 2024

weired, cannot pass test, the callback is only called once..

@ermalkaleci
Copy link
Collaborator

I'm afraid there's no use of fake data for these methods. These are required for beefy and needs to be real data

@xlc
Copy link
Member

xlc commented Mar 15, 2024

It is not possible to have real data as we don't have the signing keys. So the user of those RPCs (i.e. the bridge relayer) needs to have a special mode to skip signature validation, which is the plan.

Comment on lines 71 to 74
return {
at: hash,
proof: keys.map(() => ('0x' + '7'.repeat(64)) as HexString),
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any way we could get a real proof here ? As far as I know, for this we don't need signing keys.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@serban300 I've implemented state_getReadProof to return proof of requested keys but the trie_state_root won't be the same as block trie_state_root. I don't know if correct hash is required and not sure if we can do that. Can you give this a try first before I look deeper into the implementation?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ermalkaleci thanks ! Yes, will try this. Just have to prioritize some reviews first, and then I will get to this. Hopefully this week.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked. This doesn't work. I'm getting an error when validating the storage proof. We would need the trie_state_root to be the same as the block trie_state_root. Since I think that's how we're validating the proof. Would that be possible ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure


update = async (block: Block) => {
// Proof needs to be different for each block
callback(blake2AsHex(block.hash))

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm getting an error when receiving such a proof:

[Polkadot_to_BridgeHubKusama_Sync] 2024-03-21 20:22:21 +00 ERROR bridge Failed to read justification target from the Polkadot justifications stream: "decode failed with error Error { cause: Some(Error { cause: Some(Error { cause: None, desc: \"Not enough data to fill buffer\" }), desc: \"Could not decode `Commit::target_hash`\" }), desc: \"Could not decode `GrandpaJustification::commit`\" }"

The proof needs to be an encoded GrandpaJustification that contains at least the targetHash and targetNumber. Something like:

    const justification: GrandpaJustification = {
        round: 0,
        commit: {
            targetHash: block.hash,
            targetNumber: block.number,
            precommits: []
        },
        votesAncestries: []
    };

And then it needs to be encoded.

Not sure how to instantiate such a type here. Can you take a look please ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@serban300 can you try latest commit?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@serban300 do you have some instructions how I can test this?

Copy link

@serban300 serban300 Mar 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ermalkaleci just some context first. I haven't tested it yet, but I don't think this will work. Looks like it returns a beefy justification from grandpa_subscribeJustifications if I understand correctly. These should be 2 different APIs: grandpa_subscribeJustifications and beefy_subscribeJustifications. Also I would define them in 2 separate files.

Another thing I should mention is that we don't use the beefy justifications yet for the Polkadot<>Kusama bridge. We have a beefy light client, but it's still a work in progress, we don't use it now and it's not a priority. We only use grandpa. So we don't need beefy_subscribeJustifications yet. I don't know about the team working at the Ethereum bridge. They use beefy, but I don't know if they plan to perform tests using chopsticks.

For grandpa_subscribeJustifications we need to return an encoded GrandpaJustification struct as mentioned in the previous comment. For the moment I think a good enough test would be just to decode it and see that the targetHash and targetNumber match the latest finalized block if that's possible.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok my bad. I was looking for justification on wested and I just found BEEFY. updating now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@serban300 updated

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ermalkaleci Thanks ! Now I'm not getting any decoding error anymore. And if I comment the finality proof verification logic in the relayer and in the bridge hubs runtimes, updating the best header for the bridged relay chain works.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you send me a link to the code you're disabling?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

This is the disabled runtime code: serban300/polkadot-sdk@06dcf0a

And this is the disabled relayer code: serban300/parity-bridges-common@f334bdd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants