Closed SebastianElvis closed 3 months ago
Thanks @gitferry @KonradStaniec for the comments! You guys are right that the proposal could still contain invalid vote extensions and we have to be resilient against those. I have fixed the tests, and along the way we have found a bunch of new things:
ProcessProposal
, we used to return err if ValidateVoteExtensions
fails, and returning error will make the node panick. Given that now it validates a few more things that could be manipulated by the adversarial proposer, we should simply reject the proposal without panic.ProcessProposal
now also validates the ProposedLastCommit
given in the request due to ValidateVoteExtensions
. This PR has added relevant mock code to construct ProposedLastCommit
.FuzzAddBLSSigVoteExtension_SomeInvalidVoteExtensions
has to be resilient against invalid vote extensions, but not invalid signatures over vote extensions (upon which the proposal will be rejected). This PR has fixed ApplyEmptyBlockWithSomeInvalidVoteExtensions
to generate invalid vote extensions but with valid signatures.Please take a look again.
Now the CI has passed. Did some fixes:
chainID
v0.50.4
, theheaderInfo
is set to the finalized state via block header, so we can remove.WithHeader()