Al principio asumí que "checkpointed to Bitcoin" significaba que un bloque de Babylon se vuelve esencialmente Bitcoin-final en el mismo momento en que se le asigna una marca de tiempo, inmutable en cuanto aterriza en la cadena. Leyendo el propio documento de Babylon sobre el desunbonding rápido, el modelo de seguridad real tiene una ventana más estrecha de lo que esa formulación sugiere. Los validadores firman los encabezados de los bloques génesis y los envían a Bitcoin aproximadamente una vez cada hora, y la regla de fork-choice indica que gana el fork cuya marca de tiempo en Bitcoin es más temprana. Esa protección es realmente fuerte contra ataques que comienzan desde un historial antiguo, ya enterrado. Pero la propia documentación de Babylon describe un escenario más específico: si los validadores adversarios esperan hasta que sus solicitudes de retirada se liberen, entonces bifurcan la cadena justo cuando sus bloques obtienen una marca de tiempo nueva, y luego se confabulan con mineros de Bitcoin para reemplazar esa marca de tiempo por una posterior antes de que quede lo bastante profunda como para ser económicamente irreversible, el ataque aún puede funcionar. La defensa contra eso no es que exista el checkpoint, sino que el checkpoint envejece: se acumula suficiente prueba de trabajo encima de él como para que reescribirlo sea demasiado costoso como para molestarse. Así que, en realidad, se describen dos niveles de seguridad distintos bajo una sola frase. Un checkpoint que acaba de llegar depende de la mayoría honesta y, teóricamente, puede ser impugnado. Un checkpoint que lleva un tiempo asentado es Bitcoin-hard y, de hecho, es final. La propuesta habla de la seguridad de Bitcoin como si fuera un único interruptor que se activa en cada compromiso horario. La garantía real está más cerca de un dial que solo se bloquea completamente después de que haya pasado el tiempo suficiente para que la prueba de trabajo de Bitcoin haga que intentar revertir no valga la pena.
@BabylonLabs_io $BABY #baby