Message validation #1066

nkryuchkov · 2023-07-18T15:41:35Z

No description provided.

network/p2p/ATTESTER.md

network/p2p/AGGREGATOR_RULES.md

network/p2p/GENERAL_RULES.md

nkryuchkov · 2023-07-20T14:23:28Z

network/p2p/GENERAL_RULES.md

+- `Ignore` - message is invalid, ignored and not processed further, violation count is increased.
+- `Reject` - message is rejected, ignored and not processed further, violation count is set to violation threshold, peer is banned for the current round.
+
+## Semantic assertions


add a case when message for slot N is sent in multiple slots

network/p2p/GENERAL_RULES.md

nkryuchkov · 2023-07-20T14:30:45Z

network/p2p/GENERAL_RULES.md

+- Generally, If violation happens by a large margin, the message is rejected. 
+  - If an assertion has a rule for rejecting, the rule has higher priority than this one.
+- If violation count reaches a certain threshold, all further messages from the validator for current round are rejected.
+- Each round resets violation count to 0.


Handle case if node is a bit malicious (ignored) each round but does it repetitively: should it be punished?

nkryuchkov · 2023-07-20T14:59:05Z

network/p2p/GENERAL_RULES.md

+  - TODO: Need to check if upon reorg there can be more than one duty per epoch.
+  - First violation is ignored. Further ones are rejected.
+- Message round is equal to estimated current round.
+- Violation by [1; ceil(MAX_POSSIBLE_ROUND * 0.2)] rounds is ignored. Violations above that are rejected.


future rounds should be punished

earlier ones are to be discussed

test if clock drift may cause any false positives (if so, consider checking Prysm code regarding clock drift)

cli/operator/node.go

integration/qbft/tests/msg_router.go

message/validation/message_counts.go

message/validation/signer_state.go

message/validation/validator.go

message/validation/message_counts.go

message/validation/validator.go

protocol/v2/types/crypto.go

protocol/v2/types/batch_verifier.go

message/validation/validation.go

y0sher

Added just some minor comments. This is a lot of code, lets get it merged soon.
Generally I'm not a big fan of this approach, we're replicating the consensus state in a way and keeping the messages twice. the code is pretty well organized though and functions as a "separate entity" which is good because one of my concerns was bloating the p2p layer with consensus logic.
anyway I hope one day we would just relay on the protocol to validate its own messages since it should already have all tools in place. there are some extra stuff we validate by tracking the messages but IMO eventually it should be splitted from consensus logic.

* Message validation (#1066) --------- Co-authored-by: moshe-blox <[email protected]> Co-authored-by: moshe-blox <[email protected]> * e2e tests for eth execution layer package (#1143) * New slot ticker (#1149) --------- Co-authored-by: Matus Kysel <[email protected]> Co-authored-by: moshe-blox <[email protected]> --------- Co-authored-by: Nikita Kryuchkov <[email protected]> Co-authored-by: moshe-blox <[email protected]> Co-authored-by: moshe-blox <[email protected]> Co-authored-by: Anton Korpusenko <[email protected]> Co-authored-by: Matus Kysel <[email protected]> Co-authored-by: Matus Kysel <[email protected]>

liorrutenberg reviewed Jul 18, 2023

View reviewed changes

network/p2p/ATTESTER.md Outdated Show resolved Hide resolved