@BabylonLabs_io Eu continuo voltando à forma como a condição de slashing de Babylon está escrita. Assine dois blocos conflitantes na mesma altura com sua chave EOTS, e a própria matemática expõe sua chave privada. Não há revisão de comitê, não existe votação que decida isso; a criptografia simplesmente dispara.

O que está por baixo disso é ainda mais interessante do que o mecanismo em si. Agora existe um mercado de gerenciadores de chaves de terceiros que existe especificamente para impedir que isso dispare, porque o protocolo não tem como separar um operador que trapaceou de um cujo software do cliente deu um glitch. A proposta de “sem confiança, sem comitê” é real na camada do protocolo, mas a segurança no mundo real agora depende em parte de o provedor de finalidade em questão ter se dado ao trabalho de adotar um desses fornecedores. Isso é uma decisão de negócio privada, não algo escrito na cadeia.

Para quem está alocando BTC por meio de um provedor de finalidade, é uma variável que você não consegue verificar atualmente. A adoção por fornecedores não é divulgada, não é padronizada e não faz parte de qualquer checklist de due diligence que eu tenha visto circulando.

A “pureza” criptográfica deveria eliminar a necessidade de confiar no julgamento de alguém. Em vez disso, ela apenas moveu esse julgamento uma camada para baixo, para a seleção de fornecedores que ninguém publica.

Uma condição de slashing sem comitê ainda tem um comitê; só que é o mercado de fornecedores que decide quem fica coberto.

A lacuna honesta aqui é que eu não tenho também números de adoção, então é uma observação estrutural, não um risco medido.
#baby $BABY $BLESS $HOME
Seu provedor de finalidade executa proteção de chave EOTS?