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

Bump consensus runtime spec version #2953

Merged
merged 2 commits into from
Jul 29, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions crates/sp-domains-fraud-proof/src/storage_proof.rs
Original file line number Diff line number Diff line change
Expand Up @@ -420,8 +420,6 @@ pub struct DomainInherentExtrinsicDataProof {
pub dynamic_cost_of_storage_proof: DynamicCostOfStorageProof,
pub consensus_chain_byte_fee_proof: ConsensusTransactionByteFeeProof,
pub domain_chain_allowlist_proof: DomainChainsAllowlistUpdateStorageProof,
// TODO: remove this before next consensus runtime upgrade. Skipping to maintain compatibility with Gemini
#[codec(skip)]
Comment on lines -423 to -424
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure how is this supposed to work on the client side, can you explain?

Copy link
Member Author

Choose a reason for hiding this comment

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

FP is expected to be rare in the network and the client only constructs/submits FP through the runtime time (not extracting FP from the runtime state), so the worst situation is the invalid extrinsic root FP triggered after the runtime upgrade and domain node didn't include this change will crash due to failed to submit FP, it can be fixed by upgrade the client to a newer release or restart after FP is submitted by other nodes.

Generally, I think this is okay for gemini-3h, but for mainnet we need to resolve #2942 completely before changing any shared data structure.

Also, we do need another client release to include this change and #2947, the domain node that is on jul-26 needs to upgrade to this new release otherwise they may crash after the runtime upgrade due to #2947.

Copy link
Member

Choose a reason for hiding this comment

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

I do not think I fully understand how this is going to work. We already had fraud proofs on 3h, changing data structure indicates decoding will fail for either old or future fraud proofs unless client is somehow prepared to deal with this. Unless I misunderstand what this does and how it works.

Copy link
Member Author

Choose a reason for hiding this comment

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

The client doesn't decode the FP, it only constructs, encodes, and submits FP through runtime API, so the domain node only crashes if:

  • FP is triggered after the runtime upgrade
  • And it didn't upgrade to the client that included this change

This is different from ER, where the domain node will extract and decode ER in every consensus block (from genesis to the best block) so any change to ER will crash the domain node.

pub maybe_domain_sudo_call_proof: Option<DomainSudoCallStorageProof>,
}

Expand Down
2 changes: 1 addition & 1 deletion crates/subspace-runtime/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -118,7 +118,7 @@ pub const VERSION: RuntimeVersion = RuntimeVersion {
spec_name: create_runtime_str!("subspace"),
impl_name: create_runtime_str!("subspace"),
authoring_version: 0,
spec_version: 5,
spec_version: 6,
impl_version: 0,
apis: RUNTIME_API_VERSIONS,
transaction_version: 0,
Expand Down
Loading