Should CometBFT have a mechanism to spot _lazy validators_ ? #3148
Replies: 1 comment 1 reply
-
|
As you mentioned the Solana example, the only real way to catch such "lazy validators" is to inject spurious data in the system, I would mostly say in the consensus algorithm. I.e., message with invalid signatures or invalid blocks. This of course will imply some performance impact, as rounds with spurious votes/blocks should not succeed. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with you. This is of course long term (when we have some bandwidth for proto design), but if we don't do anything, we risk having validators modify their nodes to skip verification, and that's not good for the health of chains using our software. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Intro
There is an idea that has been circulating in informal discussions a few times during the last 2 years: lazy validators.
Let me start by describing some basic distributed systems & PoS concepts (at the risk of being redundant).
The well-known byzantine model of distributed systems separates processes (i.e., validators) into correct and byzantine.
Cosmos Proof of Stake (PoS) builds on this model by encouraging processes to be correct by punishing validators caught being byzantine (a.k.a. misbehaving) by slashing a part of their stake. CometBFT contains provisions to detect some instances of misbehaviour (currently, double-signing of proposals and votes, and light client attacks) and provides the evidence to the application so that it can act accordingly.
Validators' checks
As correct validators MUST fully follow the algorithm, they have to do a number of checks upon receiving certain messages from other nodes, such as block proposals, proposed blocks, prevotes, precommits. Some of those checks are:
Lazy validators
Some of these checks are computationally expensive, in particular, in networks with many validators. So certain operators may be tempted to modify the code they run to disable some of these checks and save on CPU and/or other resources.
The problem is that most of these checks (e.g., signature verification) are the basis of a blockchain's security and integrity. So, if more and more operators reach the conclusion they can disable them assuming others are running the checks anyway, the blockchain may eventually reach a point where not enough validators are running all the checks.
Bear in mind that, according to the definition provided in the Intro, a validator skipping some checks is byzantine, and all byzantine-fault-tolerant algorithms (including Tendermint, used by CometBFT) require at least a supermajority of correct processes (2/3 of the total voting power in Tendermint's case) in order to provide strong correctness guarantees.
How to catch lazy validators
There are techniques to catch validators that are skipping some checks. Solana's design includes provisions for a leader (a block proposer) to produce incorrect blocks as part of the algorithm. So, producing an incorrect block under those circumstances does not make the leader byzantine.
With clear rules, correct processes producing incorrect data is a way to catch (and, in PoS, slash) those that don't run the checks they should be running.
The question
The question I'd like to ask is the following. Is this scenario something we should worry about in practice? Should we plan for including provisions in CometBFT to ensure that, at least at our level, operators are not skipping checks for economic incentives?
Beta Was this translation helpful? Give feedback.
All reactions