@BabylonLabs_io
Eu continuei pensando que o mecanismo de slashing do Babylon era, em grande parte, sobre capturar um validador fazendo algo errado.
Então comecei a analisar o que realmente acontece quando um Provedor de Finalidade assina dois blocos conflitantes.
Foi aí que o design ficou mais interessante para mim.
O Babylon usa algo chamado Assinatura de Uma Vez Extraível, ou EOTS.
A ideia básica parece quase invertida à primeira vista.
Um Provedor de Finalidade compromete aleatoriedade antes de assinar.
Se depois eles usarem a mesma aleatoriedade para assinar dois blocos diferentes na mesma altura, o sistema pode extrair a chave privada EOTS deles.
Então o double-signing não é apenas uma evidência de que algo deu errado.
O próprio erro pode expor a chave que torna a consequência possível.
Isso me fez repensar o que “slashing” significa aqui.
Eu tinha imaginado como:
Alguém detecta uma conduta ruim → alguém decide puni-la.
Mas quanto mais eu olhava para o EOTS, mais eu via uma relação diferente.
As regras de assinatura são desenhadas de forma que certos comportamentos conflitantes gerem uma consequência criptográfica.
E essa era a parte que eu não tinha realmente apreciado.
A pergunta interessante não é apenas:
“Como o Babylon detecta um Provedor de Finalidade desonesto?”
É:
“O que acontece com a chave criptográfica quando esse provedor prova que violou as regras?”
Isso é um design muito mais interessante para mim.
Porque o Babylon não está apenas tentando dizer aos validadores “não dêem double-signing”.
Ele está criando um sistema em que o ato de double-signing pode se tornar parte do mecanismo que torna o slashing possível.
E agora eu estou me perguntando:
O mecanismo de slashing mais forte é aquele que pune o mau comportamento — ou o que, por si só, faz com que o mau comportamento crie a evidência necessária para puni-lo?
@BabylonLabs_io
#baby $BABY
Eu continuei pensando que o mecanismo de slashing do Babylon era, em grande parte, sobre capturar um validador fazendo algo errado.
Então comecei a analisar o que realmente acontece quando um Provedor de Finalidade assina dois blocos conflitantes.
Foi aí que o design ficou mais interessante para mim.
O Babylon usa algo chamado Assinatura de Uma Vez Extraível, ou EOTS.
A ideia básica parece quase invertida à primeira vista.
Um Provedor de Finalidade compromete aleatoriedade antes de assinar.
Se depois eles usarem a mesma aleatoriedade para assinar dois blocos diferentes na mesma altura, o sistema pode extrair a chave privada EOTS deles.
Então o double-signing não é apenas uma evidência de que algo deu errado.
O próprio erro pode expor a chave que torna a consequência possível.
Isso me fez repensar o que “slashing” significa aqui.
Eu tinha imaginado como:
Alguém detecta uma conduta ruim → alguém decide puni-la.
Mas quanto mais eu olhava para o EOTS, mais eu via uma relação diferente.
As regras de assinatura são desenhadas de forma que certos comportamentos conflitantes gerem uma consequência criptográfica.
E essa era a parte que eu não tinha realmente apreciado.
A pergunta interessante não é apenas:
“Como o Babylon detecta um Provedor de Finalidade desonesto?”
É:
“O que acontece com a chave criptográfica quando esse provedor prova que violou as regras?”
Isso é um design muito mais interessante para mim.
Porque o Babylon não está apenas tentando dizer aos validadores “não dêem double-signing”.
Ele está criando um sistema em que o ato de double-signing pode se tornar parte do mecanismo que torna o slashing possível.
E agora eu estou me perguntando:
O mecanismo de slashing mais forte é aquele que pune o mau comportamento — ou o que, por si só, faz com que o mau comportamento crie a evidência necessária para puni-lo?
@BabylonLabs_io
#baby $BABY