Reconectar e pronto — essa é a suposição.
Os provedores de finalidade da Babylon não podem simplesmente pular a fila assim. Os provedores de finalidade precisam comprometer a sua aleatoriedade pública com antecedência, para futuras alturas de bloco, em lotes. Isso não é um detalhe menor — é a base inteira para como as assinaturas EOTS funcionam. O parâmetro TimestampingDelayBlocks define com que antecedência esse compromisso precisa chegar, e o valor recomendado é acima de 10.000 blocos, porque a própria aleatoriedade só pode ser usada depois de ter sido carimbada com timestamp no Bitcoin.
Um FP que fique offline por mais tempo do que a sua janela pré-comprometida não apenas perde votos. Ele fica sem “pista” completamente.
Suponha que um provedor tenha uma aleatoriedade comprometida até a altura H, então fique offline, e só volte em H mais 100 — já passou do limite do que ele planejou. Ele não pode simplesmente começar a votar de novo. Ele precisa enviar um novo compromisso, e esse compromisso ainda precisa esperar até o carimbo de timestamp do BTC “alcançar” para então ser ativado. A indisponibilidade e a recuperação são dois atrasos separados, empilhados um sobre o outro.
No começo, isso pareceu ao contrário. Eu assumi que a disponibilidade era o problema inteiro — coloque seu nó novamente online, e pronto, você volta a operar. Mas, na prática, disponibilidade e elegibilidade para votação acabam sendo dois “relógios” diferentes aqui, e o segundo foi definido dias ou semanas antes, antes mesmo de qualquer indisponibilidade acontecer.
Então, a resiliência real de um operador não é apenas “quão rápido eu consigo reiniciar”. É “com que antecedência eu planejei antes de qualquer coisa dar errado” — uma decisão embutida em um valor de configuração muito antes de existir qualquer indisponibilidade para recuperar.
Se a sua capacidade de votar novamente após uma indisponibilidade foi decidida por um número que você definiu antes da indisponibilidade acontecer, quanto da reputação do operador de “alta disponibilidade confiável” na verdade é apenas uma aposta feita com antecedência, e quanto é resiliência genuína no momento?
@BabylonLabs_io #baby $BABY
Os provedores de finalidade da Babylon não podem simplesmente pular a fila assim. Os provedores de finalidade precisam comprometer a sua aleatoriedade pública com antecedência, para futuras alturas de bloco, em lotes. Isso não é um detalhe menor — é a base inteira para como as assinaturas EOTS funcionam. O parâmetro TimestampingDelayBlocks define com que antecedência esse compromisso precisa chegar, e o valor recomendado é acima de 10.000 blocos, porque a própria aleatoriedade só pode ser usada depois de ter sido carimbada com timestamp no Bitcoin.
Um FP que fique offline por mais tempo do que a sua janela pré-comprometida não apenas perde votos. Ele fica sem “pista” completamente.
Suponha que um provedor tenha uma aleatoriedade comprometida até a altura H, então fique offline, e só volte em H mais 100 — já passou do limite do que ele planejou. Ele não pode simplesmente começar a votar de novo. Ele precisa enviar um novo compromisso, e esse compromisso ainda precisa esperar até o carimbo de timestamp do BTC “alcançar” para então ser ativado. A indisponibilidade e a recuperação são dois atrasos separados, empilhados um sobre o outro.
No começo, isso pareceu ao contrário. Eu assumi que a disponibilidade era o problema inteiro — coloque seu nó novamente online, e pronto, você volta a operar. Mas, na prática, disponibilidade e elegibilidade para votação acabam sendo dois “relógios” diferentes aqui, e o segundo foi definido dias ou semanas antes, antes mesmo de qualquer indisponibilidade acontecer.
Então, a resiliência real de um operador não é apenas “quão rápido eu consigo reiniciar”. É “com que antecedência eu planejei antes de qualquer coisa dar errado” — uma decisão embutida em um valor de configuração muito antes de existir qualquer indisponibilidade para recuperar.
Se a sua capacidade de votar novamente após uma indisponibilidade foi decidida por um número que você definiu antes da indisponibilidade acontecer, quanto da reputação do operador de “alta disponibilidade confiável” na verdade é apenas uma aposta feita com antecedência, e quanto é resiliência genuína no momento?
@BabylonLabs_io #baby $BABY