No começo, assumi que a única coisa que poderia custar a posição de um Provedor de Finalidade era um comportamento abertamente malicioso: assinar dois blocos conflitantes, ser pego, ser reduzido (slashed), o binário clássico entre honesto ou desonesto. Lendo a documentação própria do módulo de Finalidade da Babylon, há um segundo caminho de falha, mais silencioso, que não tem nada a ver com honestidade. Antes mesmo de um Provedor de Finalidade poder votar em um bloco, ele precisa, de forma proativa, comprometer a aleatoriedade pública de EOTS para aquela altura futura específica, com antecedência, antes que o bloco seja sequer proposto. O sistema da Babylon acompanha separadamente duas categorias de provedores problemáticos: os que equivalenciam (equivocam), que são pegos assinando mensagens conflitantes, e os lentos, que simplesmente não aparecem a tempo. Ser lento não é a mesma violação que ser desonesto, mas ainda assim é registrado e penalizado como uma categoria própria. O que isso significa na prática é que um provedor pode ser totalmente honesto, nunca assinar nada conflitante, nunca tentar nada adversarial, e ainda assim perder a capacidade de voto para uma determinada altura apenas porque seu compromisso de aleatoriedade não acompanhou o avanço do topo (tip) da cadeia. Comprometer aleatoriedade não é uma etapa única de configuração; é um trabalho contínuo de previsão, mantendo-se à frente de uma cadeia que continua se movendo quer você esteja pronto ou não. Então, o modelo de segurança realmente descrito não é apenas honesto versus malicioso. É honesto-e-pontual versus todo o resto, incluindo provedores honestos que simplesmente ficaram para trás em um requisito de escalonamento que a maioria das pessoas apostando (staking) neles provavelmente nunca pensa em checar.
@BabylonLabs_io #baby $BABY