No início, assumi que “checkpointado para o Bitcoin” significava que um bloco da Babylon se torna essencialmente Bitcoin-final no momento em que recebe um carimbo de data/hora, imutável assim que é publicado na cadeia. Ao ler o próprio texto da Babylon sobre o unbonding rápido, percebi que o modelo de segurança real tem uma janela mais estreita do que essa forma de apresentar sugere. Os validadores assinam cabeçalhos de blocos Genesis e os enviam ao Bitcoin aproximadamente uma vez por hora, e a regra de escolha de fork diz que vence o fork que tiver o carimbo de data/hora do Bitcoin mais antigo. Isso é uma proteção genuinamente forte contra ataques que se iniciam a partir de um histórico antigo, já “enterrado”. Mas a própria documentação da Babylon descreve um cenário mais específico: se validadores adversariais esperarem até que suas solicitações de retirada sejam liberadas e, então, fizerem um fork da cadeia bem quando os blocos deles ganham um carimbo de data/hora fresco, e depois conspirarem com mineradores do Bitcoin para substituir aquele carimbo de data/hora por um posterior antes que fique suficientemente profundo para ser economicamente irreversível, o ataque ainda pode funcionar. A defesa contra isso não é o checkpoint existir, e sim o checkpoint envelhecer—acumulando prova de trabalho suficiente por cima dele para que reescrevê-lo fique caro demais para valer a pena. Então, na verdade, estão sendo descritos dois níveis de segurança diferentes sob uma mesma expressão. Um checkpoint que acabou de ser publicado é dependente da maioria honesta e, teoricamente, contestável. Um checkpoint que já está “parado” há algum tempo é Bitcoin-hard e, de fato, final. O discurso fala da segurança do Bitcoin como se fosse um único interruptor que liga a cada compromisso feito a cada hora. A garantia real é mais parecida com um dial que só trava completamente depois que passa tempo suficiente para a prova de trabalho do próprio Bitcoin tornar uma reversão não valer a tentativa.
@BabylonLabs_io $BABY #baby