-
Notifications
You must be signed in to change notification settings - Fork 704
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
Mixnet integration #1346
Mixnet integration #1346
Conversation
Moved PR from the old Substrate repo (old PR here). I think I've addressed all the comments except two... Not sure where the CLI param stuff should go. On the Substrate PR I made this comment:
Not sure how log levels should be picked. On the Substrate PR I made this comment:
|
So normally, I'd say network misbehaviour should be a |
I'm fine with keeping it in |
Thanks. Fixed up all the log levels. |
/// | ||
/// `session_index` should match `session_status().current_index`; if it does not, `false` | ||
/// is returned immediately. |
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.
I still don't get this requirement. If you know the current_index
why do I need to pass it then?
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.
It's just to avoid needing two calls into the runtime every block (one to check the session index and one to register). I can drop this argument if you'd prefer the two calls.
/// | ||
/// `session_index` should match `session_status().current_index`; if it does not, `false` is | ||
/// returned immediately. |
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.
Same comment as for the runtime api. I don't get why we not just fetch the session index?
Does anyone have any idea what's going on with the Zombienet block-building test (https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3884822)? The CI output is not particularly enlightening. |
We should update the version of zombienet used in |
This PR doesn't actually depend on that change as it doesn't include the Zombienet test; I was going to add that in a follow-up commit. It looks like there is some issue starting the nodes up in the block building test but I'm not sure how to start debugging this. The test works fine locally using the native backend, but this isn't exactly what CI is running. If I could run what is being run under CI locally that would be a good start but I'm not sure how to do that. |
This is the error, the node crash.
|
Ah ok, I guess that change is required then, my mistake. Thanks! |
Responsible for determining the mixnode set for each session.
impl<T: Config> Pallet<T> { | ||
/// Register a mixnode for the following session. | ||
#[pallet::call_index(0)] | ||
#[pallet::weight(1)] // TODO |
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.
Does this need a benchmark?
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.
Yes, but this pallet doesn't go to production directly?
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.
Sure, can be done as a follow-up, but our policy is to use tracking issues instead of TODOs :P
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.
Yeah, fair point.
* master: (33 commits) ci: set CI_IMAGE back to (now updated) .ci-unified (#1854) ci: bump ci image to rust 1.73.0 (#1830) Refactor Identity to benchmark v2 (#1838) PVF worker: bump landlock, update ABI docs (#1850) Xcm emulator nits (#1649) Fixes path issue in derive-impl (#1823) upgrade to macro_magic 0.4.3 (#1832) Use safe math when pruning statuses (#1835) remote-ext: fix state download stall on slow connections and reduce memory usage (#1295) Update testnet bootnode dns name (#1712) [FRAME] Warn on unchecked weight witness (#1818) [xcm] Use `Weight::MAX` for `reserve_asset_deposited`, `receive_teleported_asset` benchmarks (#1726) Update bridges subtree (#1803) Check for parent of first ready block being on chain (#1812) Make CheckNonce refuse transactions signed by accounts with no providers (#1578) Fix Asset Hub collator crashing when starting from genesis (#1788) Mixnet integration (#1346) [xcm-emulator] Decouple the `AccountId` type from `AccountId32` (#1458) Treasury spends various asset kinds (#1333) chore: bump zombienter version (#1806) ...
See paritytech#1345, <paritytech/substrate#14207>. This adds all the necessary mixnet components, and puts them together in the "kitchen-sink" node/runtime. The components added are: - A pallet (`frame/mixnet`). This is responsible for determining the current mixnet session and phase, and the mixnodes to use in each session. It provides a function that validators can call to register a mixnode for the next session. The logic of this pallet is very similar to that of the `im-online` pallet. - A service (`client/mixnet`). This implements the core mixnet logic, building on the `mixnet` crate. The service communicates with other nodes using notifications sent over the "mixnet" protocol. - An RPC interface. This currently only supports sending transactions over the mixnet. --------- Co-authored-by: David Emett <dave@sp4m.net> Co-authored-by: Javier Viola <javier@parity.io>
See #1345, paritytech/substrate#14207.
This adds all the necessary mixnet components, and puts them together in the "kitchen-sink" node/runtime. The components added are:
frame/mixnet
). This is responsible for determining the current mixnet session and phase, and the mixnodes to use in each session. It provides a function that validators can call to register a mixnode for the next session. The logic of this pallet is very similar to that of theim-online
pallet.client/mixnet
). This implements the core mixnet logic, building on themixnet
crate. The service communicates with other nodes using notifications sent over the "mixnet" protocol.