From 1e16d0fec574fa2968826d1e30eb9ae5ae9b6889 Mon Sep 17 00:00:00 2001 From: Alexander Esgen Date: Tue, 9 Apr 2024 14:16:46 +0200 Subject: [PATCH] Praos chain order: add rationale --- .../Consensus/Protocol/Praos/Common.hs | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/ouroboros-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/Praos/Common.hs b/ouroboros-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/Praos/Common.hs index b56ba18b54..105b17a7c6 100644 --- a/ouroboros-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/Praos/Common.hs +++ b/ouroboros-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/Praos/Common.hs @@ -107,6 +107,46 @@ data VRFTiebreakerFlavor = -- +------+---+---+---+ -- -- Then we have @A < B@, @B < C@ and @A = C@. +-- +-- === Rationale +-- +-- 1. The abstract Consensus layer requires that we first compare based on +-- chain length (see __Block number precedence__ in 'ChainOrder'). +-- +-- 2. Consider the scenario where the hot key of a block issuer was compromised, +-- and the attacker is now minting blocks using that identity. The actual +-- block issuer can use their cold key to issue a new hot key with a higher +-- opcert issue number and set up a new pool. Due to this tiebreaker rule, +-- the blocks minted by that pool will take precedence (allowing the actual +-- block issuer to decide on the block contents), and they will end up on the +-- honest chain quickly, which means that the adversary can't extend any +-- chain containing such a block as it would violate the monotonicity +-- requirement on opcert issue numbers. +-- +-- See "3.7 Block Validity and Operational Key Certificates" in "Design +-- Specification for Delegation and Incentives in Cardano" by Kant et al for +-- more context. +-- +-- 3. The main motivation to do VRF comparisons as a final tiebreaker is to +-- avoid the "Frankfurt problem": +-- +-- With only the first two rules for the chain order, almost all blocks with +-- equal block number are equally preferrable. Consider two block issuers +-- minting blocks in very nearby slots. As we never change our selection +-- from one chain to an equally preferrable one, the first block to arrive +-- at another pool is the one to be adopted, and will be extended the next +-- time the pool is elected if no blocks with a higher block number arrive +-- in the meantime. This incentivizes block producers to concentrate +-- geographically (historically, in Frankfurt) in order to minimize their +-- diffusion times. This works against the goal of geographic +-- decentralisation. +-- +-- With the VRF tiebreaker, also a block with a somewhat lower propagation +-- speed has a random chance to be selected instead of the one that arrived +-- first by pools before the next block is forged. +-- +-- See 'VRFTiebreakerFlavor' for more context on the exact conditions under +-- which the VRF comparison takes place. instance Crypto c => ChainOrder (PraosChainSelectView c) where type ChainOrderConfig (PraosChainSelectView c) = VRFTiebreakerFlavor