Assisti a um validador DUSK sendo removido do conjunto ativo no testnet. Não foi hackeado. Não foi slashed. Apenas removido. O motivo foi liveness: perdeu votos de finalidade demais dentro de uma janela de 28 horas.
O sistema funcionou exatamente como foi projetado. É isso que me deixou inquieto.
O validador não perdeu sua participação vinculada. Nenhuma punição criptográfica. Nenhuma chave privada exposta. Apenas uma saída silenciosa do ciclo de consenso. E aqui está a parte que ficou comigo: a janela de encarceramento é medida em relação a um valor StartHeight que é redefinido toda vez que o provedor retorna. Sai rapidamente, volta, redefine o relógio e repete. Um operador cronicamente pouco confiável pode evitar a remoção permanente para sempre, nunca ficando offline tempo suficiente para acionar a penalidade completa. O caminho de aplicação suave é o que tem a brecha.
Continuei pensando nessa brecha enquanto observava a comunidade DUSK debater se provedores de finalidade devem ser tratados como infraestrutura ou como parceiros. Alguém no chat disse: "Se a punição por ser pouco confiável é um timeout, então a falta de confiabilidade é apenas uma estratégia com passos extras." Ninguém riu. Porque todos sabiam que um validador que redefine seu próprio relógio de jail não está quebrando as regras. Está fazendo um jogo com o ritmo da aplicação.
Esse é o abismo entre segurança técnica e segurança prática. O gatilho criptográfico para double-signing é absoluto, implacável, automático. O gatilho social para a preguiça é uma máquina de estados com um botão de reset. Um protege a rede contra malícia. O outro protege contra negligência. E, neste momento, o botão de reset pertence justamente ao operador que deveria ser contido.
#dusk $DUSK @Dusk $EDEN $AKE
O sistema funcionou exatamente como foi projetado. É isso que me deixou inquieto.
O validador não perdeu sua participação vinculada. Nenhuma punição criptográfica. Nenhuma chave privada exposta. Apenas uma saída silenciosa do ciclo de consenso. E aqui está a parte que ficou comigo: a janela de encarceramento é medida em relação a um valor StartHeight que é redefinido toda vez que o provedor retorna. Sai rapidamente, volta, redefine o relógio e repete. Um operador cronicamente pouco confiável pode evitar a remoção permanente para sempre, nunca ficando offline tempo suficiente para acionar a penalidade completa. O caminho de aplicação suave é o que tem a brecha.
Continuei pensando nessa brecha enquanto observava a comunidade DUSK debater se provedores de finalidade devem ser tratados como infraestrutura ou como parceiros. Alguém no chat disse: "Se a punição por ser pouco confiável é um timeout, então a falta de confiabilidade é apenas uma estratégia com passos extras." Ninguém riu. Porque todos sabiam que um validador que redefine seu próprio relógio de jail não está quebrando as regras. Está fazendo um jogo com o ritmo da aplicação.
Esse é o abismo entre segurança técnica e segurança prática. O gatilho criptográfico para double-signing é absoluto, implacável, automático. O gatilho social para a preguiça é uma máquina de estados com um botão de reset. Um protege a rede contra malícia. O outro protege contra negligência. E, neste momento, o botão de reset pertence justamente ao operador que deveria ser contido.
#dusk $DUSK @Dusk $EDEN $AKE