-
Notifications
You must be signed in to change notification settings - Fork 241
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
Introduce submit_receipt
to fill up the unbounded gap between HeadDomainNumber
and HeadReceiptNumber
#2933
Conversation
This is for better code reusability in the upcoming commit Signed-off-by: linning <linningde25@gmail.com>
It is used to submit receipt to fill up the gap between HeadDomainNumber and HeadReceiptNumber, it consist of the receipt, proof_of_election, and the signature. Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
…s receipt gap Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
IIRC there was some specific reason we had epoch transition triggered by confirmed block instead of latest? I feel like we have already changed this behavior. Anyway let's not introduce the canges unrelated to the bug in this PR. |
Okay, will pick the change to a separated PR. |
Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall make sense.
Question on migration if required or not
/// | ||
/// Temporary storage only exist during block execution | ||
#[pallet::storage] | ||
pub(super) type HeadReceiptExtended<T: Config> = | ||
StorageMap<_, Identity, DomainId, bool, ValueQuery>; | ||
pub(super) type NewAddedHeadReceipt<T: Config> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this change require a migration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary because it is a temporary storage that only exists during block execution and is cleared at block finalization.
@NingLin-P can you please add this new behavior to the specs ? Here in bundle verification https://github.com/autonomys/protocol-specs/blob/7a1f861dedf6cf458632394285975270a2cdbee2/docs/decex/workflow.md?plain=1#L152 |
close #1673
The workflow of domain block production in main:
HeadReceiptNumber + 1
(in its local view)HeadReceiptNumber + 1
In step 1, the operator performs the check against its local view of the last block and the ER at
HeadReceiptNumber + 1
, if the operator is lagging its last block is an older block and it may include invalid tx (at a global view) into its bundle, this is inevitable in a distributed system. But as long asHeadDomainNumber - HeadReceiptNumber == 1
, the consensus runtime only accepts the bundle if it carries an ER atHeadDomainNumber
(i.e. the last domain block), and the stale bundle produced by the lagging operator will be rejected safely. This safeguard is broken if there is a receipt gap andHeadReceiptNumber + 1 < HeadDomainNumber
, so the consensus runtime will accept the stale bundle even if it carries an ER derived from an older block.The receipt gap can be brought by:
HeadReceiptNumber
HeadDomainNumber
This PR fixes the issue by:
HeadDomainNumber - HeadReceiptNumber >= 1
submit_receipt
that is used to submit receipts to fill up the gapsubmit_receipt
is similar tosubmit_bundle
that also requiresproof_of_election
and performs the similar checksubmit_receipt
doesn't contain any tx and thus doesn't derive any new domain blocksubmit_receipt
is only allowed when there is indeed a receipt gapER::domain_block_hash
in step 1 and check the bundle carries the ER of the parent domain block in step 3The security model:
Code contributor checklist: