node: proposer for limiting blocks #156
Conversation
|
Current dependencies on/for this PR: This stack of pull requests is managed by Graphite. |
rphmeier
force-pushed
the
rh-limiting-proposer
branch
from
c1a80d8
to
f2bd414
Compare
rphmeier
force-pushed
the
rh-limiting-proposer
branch
from
f2bd414
to
64dd5ed
Compare
| use sp_runtime::generic::Digest; | ||
|
|
||
| use cumulus_client_consensus_proposer::{Error as ProposerError, ProposerInterface}; | ||
| use cumulus_pallet_parachain_system::relay_state_snapshot::RelayChainStateProof; |
There was a problem hiding this comment.
Sounds like we might need to think to extract this. (Well, I guess by we I mean cumulus devs)
There was a problem hiding this comment.
Extract in what sense?
There was a problem hiding this comment.
oh, sorry, I meant that RelayChainStateProof seems like a generally useful primitive and as such probably would be better placed in a primitives crate. That crate would be dependent upon by places such as this one and the cumulus_pallet_parachain_system.
| } else { | ||
| Err(ProposerError::proposing(anyhow!( | ||
| "no need to create a block" | ||
| ))) |
There was a problem hiding this comment.
Hopefully, this isn't going to be printed all the time, or is it?
There was a problem hiding this comment.
Yes, it is. Needs an upstream fix.
There was a problem hiding this comment.
|
Consider publishing this on crates.io or upstreaming to polkadot-sdk? This is a must-have for all runtimes post-coretime |
Tracked as part of #163. |
This creates, but does not activate, a solution to #147.
The implementation differs from the proposed model in #147 because
UpgradeGoAheadsignals are accounted for directly, so there is no need for an intermittent heartbeat.We cannot activate this yet because the fees logic needs to account for skipped blocks, which it currently is incapable of.