¿Cuál es el protocolo de consenso exacto que usa Ripple? [cerrado]

Ripple supuestamente incorpora transacciones en el libro mayor utilizando un protocolo de consenso. He estado buscando por todas partes una especificación clara, formal y precisa del protocolo y no pude encontrar ninguna.

Varias preguntas relacionadas, por ejemplo,

¿Cuáles son los pros y los contras del consenso de Ripple en comparación con la prueba de trabajo de Bitcoin?

y

¿Cómo resuelve Ripple el problema del doble gasto?

Solo proporcione una descripción vaga. Más específicamente, estoy tratando de entender la esencia del consenso: qué sucede si la red Ripple se divide por la mitad (por ejemplo, si todas las líneas de comunicación entre Europa y EE. UU. de repente dejan de funcionar) y cada mitad de la red aprueba un libro mayor. con una transacción en conflicto. ¿Qué sucede cuando la red se vuelve a conectar? ¿Cómo se resuelven los libros contables en conflicto?

Respuestas (1)

Si la red Ripple se divide por la mitad, cada mitad validará los libros de forma independiente, posiblemente con transacciones conflictivas. Si todos los servidores están correctamente configurados, no aceptarán ninguno de estos libros como completamente validados, ya que ninguno de ellos tendrá suficientes validaciones. Es posible que ambas partes piensen que están en minoría (si la división es cercana al 50/50).

Esto refleja un principio de diseño básico de Ripple: no le digas a las personas que pueden confiar en los resultados si los resultados no son confiables. Si las condiciones hacen imposible una operación confiable, es preferible no operar que dar a las personas resultados en los que no pueden confiar. Ripple está diseñado para detectar este tipo de condiciones.

Cuando la red se reincorpora, los servidores verán la otra cadena de contabilidad. Gradualmente irán a la cadena con más validaciones hasta que una u otra cadena tenga una gran mayoría de validadores confiables. En ese momento, la red vuelve a estar de acuerdo y todos pueden volver a confiar en los resultados de las transacciones.

¿Significa esto que en una división 80-20, el lado del 20% sabe que está en minoría y dejará de funcionar efectivamente (no afirmará que tiene libros contables confiables) hasta que se vuelva a unir donde funcionará el lado del 80% ¿como normal? Entonces, una división cercana al 50-50 es mala porque (si está configurada correctamente) ambos lados piensan que están en minoría y toda la red se detiene o (si está configurado incorrectamente) ambos lados pueden pensar que están en la mayoría e intentar continuar normalmente causando dolor. cuando se reincorpora?
@dchapes Exactamente. Si no es posible una operación confiable, no operar es mejor que operar de manera no confiable. Si no sabe que está en la mayoría, entonces no puede operar de manera confiable. Es difícil imaginar qué causaría una división cercana al 50-50 (¿desastre natural?), pero sí, eso ciertamente haría imposible una resolución confiable del problema del doble gasto.
Dos comentarios/preguntas: 1. su respuesta sugiere que las cosas que antes se consideraban en el libro mayor pueden eliminarse después de un tiempo (después de unirse a la red) (de manera similar a lo que sucede en Bitcoin). ¿Tengo razón? ¿Hay algún punto en el que una vez pueda decir que esto sucederá con baja probabilidad sin observar el estado completo de la red? 2. ¿El gráfico de confianza no puede ser tal que ambas partes piensen que son mayoría, manteniendo así la inconsistencia?
1. Sí. Si uno tiene un conjunto representativo de validadores en su UNL, una gran mayoría de validadores en su UNL han validado ese libro mayor, y una gran mayoría de validadores en su UNL han declarado que ellos también ven una gran mayoría (de los nodos en sus UNL) confirmando que mismo libro mayor. 2. Solo si el gráfico de confianza está muy roto. Se necesita muy poca superposición para asegurarse de que esto no suceda y aún menos para saber cuándo está en riesgo. (Puede hacer una pregunta sobre cómo planeamos evitar esto y puedo dar más detalles en una respuesta).