#baby $BABY Ontem, revisei linha por linha o documento EOTS de @BabylonLabs_io e descobri um detalhe fatal escondido pela aura do “staking nativo de BTC”: a penalidade não é gradual, é explosiva.
No PoS tradicional, se um validador assina um bloco incorretamente, a penalidade é escalonada — primeiro, desconta-se uma pequena quantia, dando a você a chance de corrigir o erro. Mas, sob o mecanismo EOTS da BABY, só pode haver uma assinatura válida para uma mesma altura de bloco. Se uma deriva no relógio do servidor, uma troca para o nó em espera ou um bug no código provocar uma assinatura dupla, a chave privada poderá ser deduzida matematicamente e divulgada imediatamente. O 1 BTC que você bloqueou será confiscado integralmente na mainnet: sem aviso, sem segunda chance.
Já simulei esse cenário: a FP implanta nós principal e de backup; a rede do nó principal oscila, e o backup interpreta a situação incorretamente em questão de milissegundos. Ambos assinam um bloco na mesma altura. No PoS do Ethereum, esse erro talvez custasse alguns milhares de dólares; na Babylon, significa perder diretamente 1 BTC.
O mais complicado é que os investidores de varejo participam com um clique por meio de protocolos LST, sem conseguir ver o gerenciamento de chaves e as estratégias de backup por trás da FP. Você não só assume o risco de slashing do protocolo, como também fica exposto aos riscos da auditoria de código da equipe de operações e da qualidade da fonte de entropia.
Altos rendimentos vêm acompanhados de tolerância zero a falhas. A menos que surjam, no futuro, seguros de custódia maduros ou redundância obrigatória com múltiplas assinaturas, quando os investidores de varejo se depararem com a narrativa de segurança do “staking nativo de BTC”, deveriam primeiro verificar se a FP delegada tem um nó de backup em espera. Estou dizendo isso para mim mesmo — talvez eu é que tenha feito backups demais.#baby BABY@BabylonLabs_io
No PoS tradicional, se um validador assina um bloco incorretamente, a penalidade é escalonada — primeiro, desconta-se uma pequena quantia, dando a você a chance de corrigir o erro. Mas, sob o mecanismo EOTS da BABY, só pode haver uma assinatura válida para uma mesma altura de bloco. Se uma deriva no relógio do servidor, uma troca para o nó em espera ou um bug no código provocar uma assinatura dupla, a chave privada poderá ser deduzida matematicamente e divulgada imediatamente. O 1 BTC que você bloqueou será confiscado integralmente na mainnet: sem aviso, sem segunda chance.
Já simulei esse cenário: a FP implanta nós principal e de backup; a rede do nó principal oscila, e o backup interpreta a situação incorretamente em questão de milissegundos. Ambos assinam um bloco na mesma altura. No PoS do Ethereum, esse erro talvez custasse alguns milhares de dólares; na Babylon, significa perder diretamente 1 BTC.
O mais complicado é que os investidores de varejo participam com um clique por meio de protocolos LST, sem conseguir ver o gerenciamento de chaves e as estratégias de backup por trás da FP. Você não só assume o risco de slashing do protocolo, como também fica exposto aos riscos da auditoria de código da equipe de operações e da qualidade da fonte de entropia.
Altos rendimentos vêm acompanhados de tolerância zero a falhas. A menos que surjam, no futuro, seguros de custódia maduros ou redundância obrigatória com múltiplas assinaturas, quando os investidores de varejo se depararem com a narrativa de segurança do “staking nativo de BTC”, deveriam primeiro verificar se a FP delegada tem um nó de backup em espera. Estou dizendo isso para mim mesmo — talvez eu é que tenha feito backups demais.#baby BABY@BabylonLabs_io