Shard security in the bribing model

The situation is better with the latest design for a couple reasons:

  1. As Vitalik points out, we moved away from the proposer-validator separation paradigm which had a bribing vulnerability baked in.
  2. With the advent of proofs of custody the cost of bribing to break data availability includes deposits (in addition to the significantly smaller subsidies and transaction fees).

The main defence we have against bribing is infrequent shuffling of persistent committees which secures against a “slowly adaptive attacker”. Things that can help address adaptive attacks:

  • Data availability proofs: Allows for clients to be aware of availability, securing the data layer.
  • Stateless clients: Allows for ultra-fast shuffling of executors, securing the state layer.
  • More stake: A larger validator pool increases the stake of proposer committees.
  • Reduced randomness lookahead: Lowering the amount of time randomness is known by an attacker before it is used.
  • Private leader election: Helpful for censorship attacks, especially networking DoS.
  • Join-leave attack mitigations: Following Dfinity’s latest research we may add defences such as the “Cuckoo rule”.