Por que Ethereum Precisa de um Protocolo Dinamicamente Disponível

A camada de heartbeat do Ethereum deveria garantir liveness sempre que a maioria do stake online for honesta, tratando validadores offline como ausentes em vez de ameaças à liveness. Essa propriedade, denominada disponibilidade dinâmica, permite que a cadeia se recupere automaticamente de bugs de cliente, interrupções na nuvem ou censura adversária sem intervenção social coordenada. Existe um dilema entre disponibilidade e finalidade, análogo ao teorema CAP, que impossibilita uma solução de protocolo único: garantir simultaneamente liveness sob participação dinâmica e segurança sob partições de rede não pode ser alcançado em uma única camada.

Isso exige um design de duas camadas: um heartbeat dinamicamente disponível e um 'gadget' de finalidade subsequente. Protocolos BFT padrão (PBFT, Tendermint e HotStuff) param quando a participação cai abaixo de limites de quorum fixos, enquanto os protocolos de heartbeat candidatos Goldfish e RLMD-GHOST utilizam pequenos comitês por slot (~256 validadores) para fornecer disponibilidade dinâmica comprovável. Comitês menores permitem slots mais rápidos e eliminam a necessidade de agregação de assinaturas em larga escala, abrindo um caminho de curto prazo para a segurança pós-quântica da camada de heartbeat. ️