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

Merge the valid_bundles, invalid_bundles, and block_extrinsics_roots fields of the ER into one bundles field and add more precise fraud detection #1995

Merged
merged 6 commits into from
Oct 6, 2023

Conversation

NingLin-P
Copy link
Member

@NingLin-P NingLin-P commented Sep 22, 2023

This PR merges the valid_bundles, invalid_bundles, and block_extrinsics_roots fields of the ER into one bundles field, this simplifies the verification and fraud detection of the ER.

This PR also brings more precise fraud detection of the ER::bundles, with cases unconsidered before handled properly:

  • A bundle can contain multiple invalid extrinsic
    • Before: the honest operator uses the first invalid extrinsic as the invalid_type of the bundle, but the malicious operator can construct fraud proof to prove the bundle is invalid of a different type due to another invalid extrinsic, the fraud proof will be accept and pruning the valid ER
    • Now: an extrinsic_index is added to the invalid_type, thus the verifier can get the exact extrinsic when verifying the proof
  • An extrinsic can be considered invalid due to multiple invalid_type at the same time
    • Before: even with extrinsic_index added, a single extrinsic can be OutOfRangeTx and InvalidXDM at the same time, thus the malicious operator can still construct valid fraud proof to prune the valid ER
    • Now: define a checking order for each invalid_type (like the order in the invalid ER fraud proof), thus the honest operator can know the exact invalidation to prove/verify according the mismatch of invalid_type

Introducing an extrinsic_index also means the invalid bundle fraud proof doesn't need to carry the whole bundle instead just a single invalid extrinsic with a storage proof of the bundle_extrinsic_root cc @ParthDesai

Code contributor checklist:

…undleValidity from sp-domains

Minor refactoring to avoid naming conflicy with incoming changes

Signed-off-by: linning <linningde25@gmail.com>
…ields into the bundles field in ER

The bundles field have type of Vec<InboxedBundle>, the InboxedBundle contains all the data of
the previous three fields and addtionally the invalid extrinsic index is added to InvalidBundleType
which will be used to detect the bundles mismatch in the next commit

Signed-off-by: linning <linningde25@gmail.com>
This version of find_inboxed_bundles_mismatch not only updated with changes of the ER fields
but also consider more cases that not are considered before like: a bundle can contains multiple
invalid extrinsics and an extrinsic can be considered as invalid due to multiple invalid_type
at the same time, and handle these case properly.

Signed-off-by: linning <linningde25@gmail.com>
This commit fix the test test_invalid_domain_extrinsic_root_proof, before this commit it
is not a legitimate test at all since it try to generate valid fraud proof for a valid
receipt.

Signed-off-by: linning <linningde25@gmail.com>
Copy link
Contributor

@vedhavyas vedhavyas left a comment

Choose a reason for hiding this comment

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

Did a first pass. I'm confused on few things and raised questions. Will do another pass later

@@ -47,6 +47,11 @@ type DomainBlockElements<CBlock> = (
MaybeNewRuntime,
);

enum BundleValidity<Extrinsic> {
Copy link
Contributor

Choose a reason for hiding this comment

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

it is weird seeing some of the type in sp-domains and some in here. Not sure I understand why this is needed ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Naming conflict unfortunately, would be great if you suggest a better name for this.

crates/pallet-domains/src/block_tree.rs Outdated Show resolved Hide resolved
crates/sp-domains/src/lib.rs Outdated Show resolved Hide resolved
@@ -118,11 +118,6 @@ where
))
})?;

if local_receipt.invalid_bundles != receipt.invalid_bundles {
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't this check be done for inboxed_bundles correct ?

Copy link
Member Author

Choose a reason for hiding this comment

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

inboxed_bundles is checked in the domain_block_processor but not the ReceiptValidator which is used in the block-preprocessor since we don't consider bundle as invalid due to invalid ER anymore. And you remind me that ReceiptValidator should be removed completely.

}
// TODO: update test
// #[test]
// fn invalid_bundles_fraud_proof_detection() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why comment them? You can just ignore them instead

// constructed/imported thus the `external_receipt` must have the same `bundles_extrinsics_roots`
//
// NOTE: this also check `local_receipt.bundles` and `external_receipt.bundles` have the same length
if local_receipt.bundles_extrinsics_roots() != external_receipt.bundles_extrinsics_roots() {
Copy link
Contributor

Choose a reason for hiding this comment

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

isn't this another type of invalid ER and should be proved on the consensus or is this already checked as part of bundle submission?

Copy link
Member Author

Choose a reason for hiding this comment

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

It has already been checked as part of bundle submission, but I want to add the check here to make it more robust and also give more context about why the following expect/unreachable is unreachable.

/// pointing to first mismatch in invalid bundles array.
pub(crate) fn verify_invalid_bundles_field<Block, CBlock>(
// Find the first mismatch of the `InboxedBundle` in the `ER::bundles` list
pub(crate) fn find_inboxed_bundles_mismatch<Block, CBlock>(
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be nice to have removed the commented code instead. Git diff after uncommenting and updating is painful to review TBH.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for letting me know! will do that next time.

domains/client/domain-operator/src/aux_schema.rs Outdated Show resolved Hide resolved
// The `local_bundle` and `external_bundle` are checked to have the same `extrinsic_root`
// thus they must being mismatch due to bundle validity
let mismatch_type = match (local_bundle.bundle.clone(), external_bundle.bundle.clone()) {
(
Copy link
Contributor

Choose a reason for hiding this comment

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

Please do not use nestings like. I have no clue how to process this function. Would be ideal if fucntionality to check a single bundle mismatch would be easier and does not hurt readability. Also Git diff from commented code to uncommented code is not helping either

Copy link
Member Author

Choose a reason for hiding this comment

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

Please do not use nestings like. I have no clue how to process this function. Would be ideal if fucntionality to check a single bundle mismatch would be easier and does not hurt readability.

Could you be more specific? I use match to handle each mismatch case in a dedicated branch which should be straightforward and clean IMHO, commented/uncommented code could hurt readability when reviewing though.

@NingLin-P NingLin-P added this pull request to the merge queue Oct 6, 2023
Merged via the queue into main with commit 7728b93 Oct 6, 2023
10 checks passed
@NingLin-P NingLin-P deleted the ER-refactoring branch October 6, 2023 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants