Hoy estaba leyendo una divulgación de GitHub en vez de un gráfico de precios, y me frenó más que cualquier número.
Un colaborador que responde a GrumpyLaurie55348 presentó un aviso de seguridad contra Babylon en diciembre. Los validadores podían enviar un voto dejando el campo del hash del bloque completamente fuera.
Protobuf trata ese campo como opcional, así que el voto aún se deserializa correctamente. El hash del bloque solo vuelve como nulo, y Babylon desreferencia ese puntero nulo dentro de la verificación del voto, lo que provoca un pánico en tiempo de ejecución.
Los límites de época ya son un punto sensible en cualquier cadena de Cosmos SDK. Varios validadores colapsando allí a la vez podrían ralentizar la producción de bloques en toda la red, no solo para un nodo.
Nadie lo explotó antes de que se publicara la corrección. Babylon corrigió el problema en la versión 4.2.0 después de que el aviso se hiciera público, y la cobertura de la divulgación se extendió durante enero.
Esa brecha entre presentar la información y la atención pública es la parte que se me quedó.
Me recordó a Polygon en 2021. Un investigador encontró una falla en el Plasma Bridge que permitía reenviar un retiro 223 veces, cada vez drenando la misma cantidad de nuevo, con aproximadamente 850 millones de dólares teóricamente expuestos.
Polygon lo confirmó en treinta minutos y pagó dos millones de dólares una vez que estuvo corregido de forma segura.
Babylon asegura miles de millones en Bitcoin nativo mediante código que todavía está tan joven. Un campo faltante en una extensión de voto es un detalle pequeño en el papel, pero está dentro del mecanismo exacto que mantiene a los validadores honestos.
No creo que una sola corrección de un bug me diga mucho por sí misma. Pero sí creo que lo rápido que se encuentra y se cierra algo me dice más sobre un protocolo que cualquier número de TVL.
@BabylonLabs_io #baby $BABY
Un colaborador que responde a GrumpyLaurie55348 presentó un aviso de seguridad contra Babylon en diciembre. Los validadores podían enviar un voto dejando el campo del hash del bloque completamente fuera.
Protobuf trata ese campo como opcional, así que el voto aún se deserializa correctamente. El hash del bloque solo vuelve como nulo, y Babylon desreferencia ese puntero nulo dentro de la verificación del voto, lo que provoca un pánico en tiempo de ejecución.
Los límites de época ya son un punto sensible en cualquier cadena de Cosmos SDK. Varios validadores colapsando allí a la vez podrían ralentizar la producción de bloques en toda la red, no solo para un nodo.
Nadie lo explotó antes de que se publicara la corrección. Babylon corrigió el problema en la versión 4.2.0 después de que el aviso se hiciera público, y la cobertura de la divulgación se extendió durante enero.
Esa brecha entre presentar la información y la atención pública es la parte que se me quedó.
Me recordó a Polygon en 2021. Un investigador encontró una falla en el Plasma Bridge que permitía reenviar un retiro 223 veces, cada vez drenando la misma cantidad de nuevo, con aproximadamente 850 millones de dólares teóricamente expuestos.
Polygon lo confirmó en treinta minutos y pagó dos millones de dólares una vez que estuvo corregido de forma segura.
Babylon asegura miles de millones en Bitcoin nativo mediante código que todavía está tan joven. Un campo faltante en una extensión de voto es un detalle pequeño en el papel, pero está dentro del mecanismo exacto que mantiene a los validadores honestos.
No creo que una sola corrección de un bug me diga mucho por sí misma. Pero sí creo que lo rápido que se encuentra y se cierra algo me dice más sobre un protocolo que cualquier número de TVL.
@BabylonLabs_io #baby $BABY