Vuelves a conectar y ya estás de vuelta. Esa es la suposición.
Los proveedores de finalización de Babylon no pueden saltarse la fila con tanta facilidad. Los proveedores de finalización tienen que comprometer su aleatoriedad pública con antelación, para futuras alturas de bloque, en lotes. Ese no es un detalle menor: es la base completa de cómo funcionan las firmas EOTS. TimestampingDelayBlocks define con cuánta antelación debe llegar ese compromiso, y el valor recomendado es más de 10.000 bloques, porque la aleatoriedad en sí no se puede usar hasta que haya sido datada con marca de tiempo en Bitcoin.
Si un proveedor (FP) se desconecta durante más tiempo del que cubre su ventana precomprometida, no solo se pierde votos. Se queda sin margen por completo.
Supongamos que un proveedor tiene aleatoriedad comprometida hasta la altura H, luego se desconecta, y vuelve en H + 100: ya pasó el límite de lo que planeó. No puede simplemente empezar a votar de nuevo. Tiene que enviar un nuevo compromiso, y ese compromiso todavía tiene que esperar a que la datación con marca de tiempo de BTC alcance el desfase antes de activarse. El tiempo de caída y el de recuperación son dos demoras separadas que se apilan una sobre la otra.
Eso se sintió al principio al revés. Asumí que el tiempo de actividad era el problema principal: vuelve a poner tu nodo en línea y vuelves a estar en funcionamiento. Pero resulta que el tiempo de actividad y la elegibilidad para votar son dos relojes distintos, y el segundo se configuró con días o semanas de antelación, antes incluso de que ocurriera la caída.
Así que la verdadera resiliencia de un operador no es solo “qué tan rápido puedo reiniciar”. Es “qué tan adelantado planeé todo antes de que ocurriera algo” — una decisión incorporada en un valor de configuración mucho antes de que hubiera cualquier caída de la que recuperarse.
Si tu capacidad para volver a votar después de una caída dependiera de un número que estableciste antes de que ocurriera la caída, ¿cuánta reputación de “tiempo de actividad confiable” de un operador es en realidad solo una apuesta hecha de antemano, y cuánta es resiliencia genuina en el momento?
@BabylonLabs_io #baby $BABY
Los proveedores de finalización de Babylon no pueden saltarse la fila con tanta facilidad. Los proveedores de finalización tienen que comprometer su aleatoriedad pública con antelación, para futuras alturas de bloque, en lotes. Ese no es un detalle menor: es la base completa de cómo funcionan las firmas EOTS. TimestampingDelayBlocks define con cuánta antelación debe llegar ese compromiso, y el valor recomendado es más de 10.000 bloques, porque la aleatoriedad en sí no se puede usar hasta que haya sido datada con marca de tiempo en Bitcoin.
Si un proveedor (FP) se desconecta durante más tiempo del que cubre su ventana precomprometida, no solo se pierde votos. Se queda sin margen por completo.
Supongamos que un proveedor tiene aleatoriedad comprometida hasta la altura H, luego se desconecta, y vuelve en H + 100: ya pasó el límite de lo que planeó. No puede simplemente empezar a votar de nuevo. Tiene que enviar un nuevo compromiso, y ese compromiso todavía tiene que esperar a que la datación con marca de tiempo de BTC alcance el desfase antes de activarse. El tiempo de caída y el de recuperación son dos demoras separadas que se apilan una sobre la otra.
Eso se sintió al principio al revés. Asumí que el tiempo de actividad era el problema principal: vuelve a poner tu nodo en línea y vuelves a estar en funcionamiento. Pero resulta que el tiempo de actividad y la elegibilidad para votar son dos relojes distintos, y el segundo se configuró con días o semanas de antelación, antes incluso de que ocurriera la caída.
Así que la verdadera resiliencia de un operador no es solo “qué tan rápido puedo reiniciar”. Es “qué tan adelantado planeé todo antes de que ocurriera algo” — una decisión incorporada en un valor de configuración mucho antes de que hubiera cualquier caída de la que recuperarse.
Si tu capacidad para volver a votar después de una caída dependiera de un número que estableciste antes de que ocurriera la caída, ¿cuánta reputación de “tiempo de actividad confiable” de un operador es en realidad solo una apuesta hecha de antemano, y cuánta es resiliencia genuina en el momento?
@BabylonLabs_io #baby $BABY