search

celestiaorg / celestia-core

A fork of CometBFT
Apache License 2.0
480 stars 257 forks source link

Full nodes should stop participating in consensus after receiving valid LightClientAttackEvidence #1130

Open cmwaters opened 10 months ago

cmwaters commented 10 months ago

Feature Request

Summary

CometBFT nodes, while having the ability to handle and verify LightClientAttackEvidence, don't do anything other than try to commit the evidence on chain so the application can punish the corresponding validators.

A byzantine cabal thus could maintain a fork and honest nodes would simply continue to follow their side of the fork. Trying to submit evidence on chain is futile for two reasons: 1) the cabal could simply censor it and 2) punishing the faulty validators doesn't resolve the fact that there are currently two chains.

The best response currently is to halt and fallback to social consensus.

Proposal

Upon receiving a valid LightClientAttackEvidence, the node should halt both the consensus and mempool services yet continue to help in broadcasting the evidence to all other honest nodes.

Note, something to be wary of is that LightClientAttackEvidence doesn't necessarily mean that the fork has happened to other consensus nodes. The fork may have only been revealed to a light node as it's easier to fool a light node than it is a full consensus node

Furthermore, there is the argument that we remove DuplicateEvidence as a proof type and only use LightClientAttackEvidence (which arguable could be better renamed)

For Admin Use

rootulp commented 10 months ago

It doesn't seem like this issue is unique to our fork. Is this something we should consider eventually upstreaming to CometBFT?