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

ADR 0018: Inter-Runtime Communication Protocol (IRCP) #9

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kostko
Copy link
Member

@kostko kostko commented Oct 13, 2022

No description provided.

more **channels**. Each channel can be used to send and receive ordered
packets.

The transport of packets does not require any new interactions with the
Copy link

Choose a reason for hiding this comment

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

It is a bit unclear how this would work on other nodes that do not run both runtimes (where do they get the packets from?). If packets are not written to the consensus layer or elsewhere, how do new nodes verify which packets were received in the past and in what way they affected the state?

Copy link
Member Author

Choose a reason for hiding this comment

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

This will be more clear once the protocol flow sections are written. But to answer briefly:

  • Packets are transported via P2P, similar to transactions (see the Transport section), and are verified using Merkle proofs and light clients (see the Authentication section).
  • All nodes sharing the consensus layer have a trusted view of consensus light headers. Since the consensus layer state stores all state roots of all runtimes, any node can obtain the state root at given height of any runtime.
  • Verifiable packet batches (generated by the source runtime which does have access to the entire runtime state) contain Merkle proofs, rooted at the runtime's state root, proving a certain leaf is stored in source runtime's storage.
  • Usually the leaf to be proven is the outgoing packet being stored in the source runtime's send queue.
  • This proves (to the destination runtime) that the packet was indeed sent by the given runtime.
  • Ordering is verified by tracking sequence numbers.

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.

2 participants