-
Notifications
You must be signed in to change notification settings - Fork 618
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: Dump and apply state changes for a range of blocks. #8628
Conversation
This simulates shard shadowing. In order to fully correctly replay state changes and get matching state roots, all kinds of state changes need to be applied, including the ones which currently are filtered out. To achieve this I add a compilation feature. Furthermore, DelayedReceipt{,Indices} state changes have no information about the shard they are coming from, which leads to two issues: 1) If two shards have a `DelayedReceipt` change, they will override one another, and the StateChanges column will contain only one of them. 2) We don't know to which shard to apply these state changes. The solution is to encode ShardUId in the row key of the StateChanges column for these two kids of state changes. The other kinds of state changes are matched to shards by their account_ids or receiver_ids. Combination of these two solutions lets us have a backwards-compatible solution.
@mm-near PTAL |
core/store/src/trie/shard_tries.rs
Outdated
trie_key.clone(), | ||
)); | ||
} | ||
let version_chunk = &suffix[..std::mem::size_of::<ShardVersion>()]; |
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.
this code (505-523) should be put in a method of ShardUId ('deserialize_from_key'?)
And similarly - line 483 + 484 should be moved to ShardUid method too.
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.
Removed, as that code is already available as to_bytes()
and try_from
/// State root of the shard at the height of the first block with state changes. | ||
state_root: StateRoot, | ||
}, | ||
/// Dumps state changes for a range of blocks from --height-from to --height-to inclusive. |
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.
so this dumps it for all the shards, right?
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.
Right, clarified
This simulates shard shadowing. In order to fully correctly replay state changes and get matching state roots, all kinds of state changes need to be applied, including the ones which currently are filtered out. To achieve this I add a compilation feature. Furthermore, `DelayedReceipt{,Indices}` state changes have no information about the shard they are coming from, which leads to two issues: 1) If two shards have a `DelayedReceipt` change, they will override one another, and the StateChanges column will contain only one of them. 2) We don't know to which shard to apply these state changes. The solution is to encode `ShardUId` in the row key of the `StateChanges` column for these two kids of state changes. The other kinds of state changes are matched to shards by their `account_id`s or `receiver_id`s. Combination of these two solutions lets us have a backwards-compatible solution.
This simulates shard shadowing.
In order to fully correctly replay state changes and get matching state roots, all kinds of state changes need to be applied, including the ones which currently are filtered out. To achieve this I add a compilation feature.
Furthermore,
DelayedReceipt{,Indices}
state changes have no information about the shard they are coming from, which leads to two issues:DelayedReceipt
change, they will override one another, and the StateChanges column will contain only one of them.The solution is to encode
ShardUId
in the row key of theStateChanges
column for these two kids of state changes.The other kinds of state changes are matched to shards by their
account_id
s orreceiver_id
s. Combination of these two solutions lets us have a backwards-compatible solution.