Una cosa me hizo dejar de desplazarme. No fue el propio error. Fue la línea que decía que la ventana de carrera solo existe entre una lectura de base de datos y una escritura en base de datos. Eso parecía un detalle de implementación diminuto hasta que empecé a pensar en lo que dice sobre el modelo de ejecución de Babylon.
Dejé de buscar a un atacante y empecé a buscar el flujo. Volví para comparar la ruta de validación y pasé un rato rastreando dónde los cambios de estado realmente se vuelven definitivos. Luego agarré un café y releí de nuevo la secuencia. Cuanto más lo miraba, menos esto me parecía un problema de seguridad únicamente. Me parecía una elección de diseño sobre cuánto riesgo de temporización el protocolo está dispuesto a tolerar.
Lo que poco a poco se volvió evidente es que la protección no está construida para hacer que la carrera sea imposible. Está construida para que la oportunidad sea extremadamente pequeña. Son dos ideas distintas. La primera elimina la condición. La segunda reduce la probabilidad. Esa diferencia es fácil de pasar por alto porque ambas pueden parecer seguras desde fuera.
Esa es la parte que nadie incluye en la presentación. Babylon depende de que validadores y servicios procesen el estado en un orden predecible, aceptando al mismo tiempo que todavía existe una pequeña brecha de ejecución. El protocolo, en la práctica, está diciendo que el costo operativo de eliminar cada posible carrera es mayor que el riesgo restante de dejar una sola ventana estrecha.
Quizá ese sea el intercambio correcto para el rendimiento. Quizá la exposición restante sea tan pequeña que añadir más sincronización crearía problemas mayores en otro lugar.
Lo que aún no puedo decidir es dónde Babylon traza la línea entre una suposición de temporización aceptable y una garantía de protocolo que jamás debería depender de la temporización.
@BabylonLabs_io
#baby $BABY
Dejé de buscar a un atacante y empecé a buscar el flujo. Volví para comparar la ruta de validación y pasé un rato rastreando dónde los cambios de estado realmente se vuelven definitivos. Luego agarré un café y releí de nuevo la secuencia. Cuanto más lo miraba, menos esto me parecía un problema de seguridad únicamente. Me parecía una elección de diseño sobre cuánto riesgo de temporización el protocolo está dispuesto a tolerar.
Lo que poco a poco se volvió evidente es que la protección no está construida para hacer que la carrera sea imposible. Está construida para que la oportunidad sea extremadamente pequeña. Son dos ideas distintas. La primera elimina la condición. La segunda reduce la probabilidad. Esa diferencia es fácil de pasar por alto porque ambas pueden parecer seguras desde fuera.
Esa es la parte que nadie incluye en la presentación. Babylon depende de que validadores y servicios procesen el estado en un orden predecible, aceptando al mismo tiempo que todavía existe una pequeña brecha de ejecución. El protocolo, en la práctica, está diciendo que el costo operativo de eliminar cada posible carrera es mayor que el riesgo restante de dejar una sola ventana estrecha.
Quizá ese sea el intercambio correcto para el rendimiento. Quizá la exposición restante sea tan pequeña que añadir más sincronización crearía problemas mayores en otro lugar.
Lo que aún no puedo decidir es dónde Babylon traza la línea entre una suposición de temporización aceptable y una garantía de protocolo que jamás debería depender de la temporización.
@BabylonLabs_io
#baby $BABY