#baby $BABY Como você faz um "slash" (sanção) de um validador no Bitcoin quando o Bitcoin não tem lógica de slashing embutida?
Demorei mais do que o esperado para realmente entender este ponto, porque a resposta não é um contrato inteligente — é um esquema de assinatura que faz algo inteligente com matemática em vez de código.
@BabylonLabs_io usa o que é chamado de Assinatura Oportunista Extraível de Uma Única Vez (EOTS), construída sobre as assinaturas nativas do Schnorr do Bitcoin. Aqui está o truque central: um provedor de finalidade gera um par de chaves único para cada altura de bloco em que vota. Enquanto eles assinarem apenas um bloco por altura, a assinatura permanece totalmente segura e nada vaza. Mas se eles assinarem dois blocos conflitantes na mesma altura, a matemática desmorona. Reutilizar essa chave por altura para assinar duas mensagens diferentes expõe diretamente sua chave privada, por causa de como a matemática da assinatura Schnorr funciona quando um nonce é reutilizado.
A própria rodada de finalidade exige assinaturas de mais de dois terços do peso de BTC apostado para que um bloco seja realmente finalizado; ou seja, qualquer violação de segurança, por definição, exige mais de um terço do stake para ter feito dupla assinatura. É isso que torna a garantia de "totalmente punível" (fully slashable) garantida matematicamente em vez de ser uma promessa de política: quando a chave vaza, qualquer pessoa — não apenas Babylon, não apenas um validador — pode construir e transmitir a transação de slashing. Não é necessária votação de comitê nessa etapa, nem processo de apelação; é só matemática exposta.
O que eu não vi uma resposta clara: a geração de chaves para cada altura de bloco cria uma sobrecarga operacional significativa para provedores de finalidade que operam em múltiplas BSNs ao mesmo tempo, e essa própria sobrecarga poderia se tornar uma superfície de ataque, por exemplo, se um provedor sob carga reutilizar aleatoriedade por engano em vez de má-fé?
A segurança do EOTS é puramente uma garantia de matemática, ou ela depende silenciosamente de provedores de finalidade também terem uma infraestrutura sólida de gerenciamento de chaves?
$BABY
Demorei mais do que o esperado para realmente entender este ponto, porque a resposta não é um contrato inteligente — é um esquema de assinatura que faz algo inteligente com matemática em vez de código.
@BabylonLabs_io usa o que é chamado de Assinatura Oportunista Extraível de Uma Única Vez (EOTS), construída sobre as assinaturas nativas do Schnorr do Bitcoin. Aqui está o truque central: um provedor de finalidade gera um par de chaves único para cada altura de bloco em que vota. Enquanto eles assinarem apenas um bloco por altura, a assinatura permanece totalmente segura e nada vaza. Mas se eles assinarem dois blocos conflitantes na mesma altura, a matemática desmorona. Reutilizar essa chave por altura para assinar duas mensagens diferentes expõe diretamente sua chave privada, por causa de como a matemática da assinatura Schnorr funciona quando um nonce é reutilizado.
A própria rodada de finalidade exige assinaturas de mais de dois terços do peso de BTC apostado para que um bloco seja realmente finalizado; ou seja, qualquer violação de segurança, por definição, exige mais de um terço do stake para ter feito dupla assinatura. É isso que torna a garantia de "totalmente punível" (fully slashable) garantida matematicamente em vez de ser uma promessa de política: quando a chave vaza, qualquer pessoa — não apenas Babylon, não apenas um validador — pode construir e transmitir a transação de slashing. Não é necessária votação de comitê nessa etapa, nem processo de apelação; é só matemática exposta.
O que eu não vi uma resposta clara: a geração de chaves para cada altura de bloco cria uma sobrecarga operacional significativa para provedores de finalidade que operam em múltiplas BSNs ao mesmo tempo, e essa própria sobrecarga poderia se tornar uma superfície de ataque, por exemplo, se um provedor sob carga reutilizar aleatoriedade por engano em vez de má-fé?
A segurança do EOTS é puramente uma garantia de matemática, ou ela depende silenciosamente de provedores de finalidade também terem uma infraestrutura sólida de gerenciamento de chaves?
$BABY