Artículo del Blog
Autor
Stellar Development Foundation
Fecha de publicación
Protocolo de consenso Stellar
Prueba de acuerdo
Esta semana, la red de Stellar experimentó una bifurcación del libro mayor que está relacionada con un fallo del sistema de consenso subyacente de Ripple/Stellar. Estamos completando nuestra revisión del impacto, pero los informes preliminares indican que el impacto no fue mayor. Nos estamos comunicando con todos los gateways y exchanges conocidos para ver qué podemos hacer para ayudar.
Dado lo novedoso que son los sistemas de consenso y nuestra creencia de que debemos ser transparentes sobre la tecnología, lo que incluye sus fortalezas y debilidades, queríamos proporcionar algún contexto sobre la bifurcación del libro mayor y cómo ocurrió en Stellar.
Problema 1: Sacrificar la seguridad por la vivacidad y la tolerancia a fallos: potencial para dobles gastos
El resultado de imposibilidad de Fischer Lynch Paterson (FLP) establece que un sistema de consenso asincrónico determinista puede tener como máximo dos de las siguientes tres propiedades: seguridad (los resultados son válidos e idénticos en todos los nodos), terminación garantizada o vivacidad (los nodos que no fallan siempre producen un resultado) y tolerancia a fallos (el sistema puede sobrevivir a la falla de un nodo en cualquier momento). Este es un resultado probado. Cualquier sistema de consenso distribuido en Internet debe sacrificar una de estas características.
El algoritmo de consenso existente de Ripple/Stellar se implementa de manera que favorece la tolerancia a fallos y la terminación sobre la seguridad. Esto significa que prioriza el cierre de libros y la disponibilidad sobre que todos estén de acuerdo en qué es el libro, abriendo así varios escenarios de riesgo potenciales. Por ejemplo, puede haber situaciones en las que los nodos diverjan en diferentes libros y una persona no pueda estar segura de cuál libro decidirá finalmente tomar la red. Si la red cambia a otra cadena de libros, entonces las transacciones de la cadena descartada serán invalidadas, esto abre la red a posibles problemas de doble gasto.
Problema 2: Corrección demostrable
El Prof. David Mazières, jefe del Grupo de Computación Segura de Stanford, revisó el sistema de consenso Ripple/Stellar y llegó a la conclusión de que el algoritmo existente probablemente no sería seguro bajo todas las circunstancias. Basados en estos hallazgos, decidimos crear un nuevo sistema de consenso con corrección demostrable. Este esfuerzo, liderado por el Prof. Mazières, está en marcha. Se espera que su documento técnico y el código acompañante sean liberados en unos pocos meses.
La investigación del Prof. Mazières indicó cierto riesgo de que el consenso pudiera fallar, aunque no estábamos seguros si las circunstancias requeridas para tal fallo eran realistas. Esta semana, descubrimos la primera instancia de un fallo de consenso. El martes por la noche, los nodos en la red comenzaron a discrepar y causaron una bifurcación del libro mayor. La mayoría de la red estaba en la cadena de libros A. En algún momento, la red decidió cambiar a la cadena de libros B. Esto causó la reversión de unas pocas horas de transacciones que solo se habían registrado en la cadena A. Pudimos reproducir la mayoría de estas transacciones revertidas en la cadena B para minimizar el impacto. Sin embargo, en casos donde una cuenta ya había enviado una transacción en la cadena B, la repetición no fue posible.
Todavía estamos investigando los desencadenantes de este fallo de consenso, pero creemos que es causado por las debilidades innatas del sistema de consenso Ripple/Stellar descrito anteriormente, agravado por el número de cuentas en la red. Actualmente, tenemos aproximadamente 140,000 cuentas activas a la semana y más de 3 millones de cuentas totales, lo cual supera las aproximadamente 120,000 cuentas totales (activas e inactivas) que esta pila ha soportado previamente.
Nuestra monitorización de la red ha dejado claro que el sistema de consenso subyacente de Ripple/Stellar no está funcionando a este nivel de escala, que aún es pequeño en relación con el sistema financiero global. Para que tales protocolos funcionen a niveles del mundo real con el grado de seguridad esperado, este número de cuentas no debería ser un problema.
Si tienes preguntas sobre qué significa esto para tu implementación, no dudes en enviarnos un correo electrónico a [email protected].