This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
implement custom proposer #1320
implement custom proposer #1320
Changes from 61 commits
54873ea
5eea3bf
27456b5
3bf17fa
e05abd2
ba005c9
7572bba
24a91c4
064a00c
c116061
e6162de
844a9d1
cae1561
2c9be73
534535f
8ac6269
51ff607
960029b
eb52f9a
f6526c4
0f5a1b1
8f75746
940216b
a20cfd5
5c44804
6efd05a
fedd931
d696e1b
9f05198
859bd8b
c504d12
4343f5c
98c4c54
d194838
d468a2b
b676adc
7d44a62
989e8b5
dffb0ab
da07b9e
3110bf8
64792f7
6b88341
2b6a7d0
01f2cd9
d2af626
50b51dd
fd1dea5
2ab09a7
ad5cbc8
4577215
5bcf147
2377744
af699dd
3642dce
75190d8
3063303
6e41882
cfec8c2
6092ba0
c78dd28
d37e89e
b91be19
9bae56e
0b0b86c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
The implication of returning an error here is that the validator node will not author any block. I think that it's better to author an "empty" block (at least in terms of inherent data) than no block, if the overseer or subsystems are unresponsive. Coupled with a critical warning of some kind. This would make the chain more robust.
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 it actually make the chain more robust, though? If this inherent data doesn't get injected, the inclusion_inherent module panics:
polkadot/runtime/parachains/src/inclusion_inherent.rs
Lines 133 to 134 in aeb79d4
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 think 9bae56e takes care of this as well; do you agree?
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.
Wouldn't any consumer of
RequestInherentData
be interested in disputes as well?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.
In practice our main consumer is the block authorship logic, which is clearly interested in disputes so it can report them to the chain. I am not aware of any other component which would be interested in disputes or dispute-related reports.
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.
The proposer consumes
RequestInherentData
, and if it cares about disputes, I haven't yet seen why it does.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, on further inspection we probably don't need the proposer to be aware of disputes. I was thinking about a more antiquated approach where the
Proposer
constructs the dispute transactions and submits them to the block directly.It seems that the "right way" to submit reports (based on @andresilva's work in GRANDPA/BABE) is to call a runtime API that submits a transaction to the queue. I guess that will end up being the main role of the MA subsystem - acting as an intermediary between POD reports and the Runtime API subsystem. Maybe we should rename it to Misbehavior Reporting, as most reports are "complete", and the actual dispute resolution / arbitration process will happen on-chain in the
Validity
module.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.
Then we shouldn't need the dispute records to be present in the
Provisioner
then either, because the assumption is that anything that the Provisioner is responsible for everything that the Proposer will need. If the Proposer doesn't need them, then the Provisioner shouldn't either. And then I suggest removingRequestBlockAuthorshipData
, as I don't see an immediate need for it if there are no disputes and no other intended users of theProvisioner
.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 think I agree with those proposals, but I also think they're out of scope for this PR.
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.
Yup, that's fair. We have a discussion on-record to reference now at least
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.
Created an issue from this so we don't lose it: #1362.