robert
robert
This is probably the best solution to have it handled all in-node. In principle, it shouldn't be a problem for one node to be a collator for many different parachains...
Gotcha. I tackled it in my newborn Rust version using a promise that resolves as soon as `f+1` good shares have been received. Another caveat I ran into was that...
FYI, `ethcore-light` already exists and stores the light client database schema, import logic, and network code.
Re: this bullet point "Ensure only the first V + 1 blocks from a given author at a slot are accepted by the runtime" What I'm imagining is an extension...
https://github.com/paritytech/polkadot-sdk/issues/83
Yes, I recommend approach (2). It will be more future-proof.
Yeah, I mean the "framework" only loosely. The information just needs to be available, as well as some easy hook to trigger orders.
re: https://github.com/paritytech/polkadot-sdk/issues/968 The use of PreVFs for the faster PoV-fetching usecase requires reasonable uniqueness per relay-parent, so punishment for equivocations should be important even for equivocations made on the same...
The issue we were observing was that with the new logic from https://github.com/paritytech/cumulus/pull/2658/, https://github.com/paritytech/cumulus/pull/2501, https://github.com/paritytech/cumulus/pull/2551 , that integration tests for all runtimes began to fail when integrating the new Aura...
cc @ggwpez , can you take a look at this?