Algoritmo de consenso distribuido ondulado

¿Qué tipo de algoritmos de consenso utiliza Ripple? ¿Es un algoritmo de consenso distribuido líder o sin líder? ¿Y que?

Respuestas (1)

Es sin líder.

Un validador comienza una ronda de consenso cuando tiene al menos una transacción sin confirmar que cree que es válida, el tiempo de inactividad ha expirado o ve que suficientes validadores en los que confía han comenzado una ronda de consenso. Cada validador participante hace una propuesta inicial que enumera las transacciones que cree que deberían aplicarse en la ronda actual. Los servidores avalancha de consenso.

Si hay transacciones en conflicto, se manejan todos los casos. Si solo uno entra en la ronda, se aplica y el otro es inválido para siempre. Si ambos lo hacen, un algoritmo determinista determina cuál se aplica primero y el otro falla. Si ninguno lo hace, un algoritmo determinista determina cuál se anuncia en la siguiente ronda, por lo que debe haber un acuerdo en esa ronda.

Debido a que la falla bizantina es posible, los validadores construyen el siguiente libro mayor al final de la ronda y luego transmiten una validación firmada de ese libro mayor. Ver a una gran mayoría de validadores de confianza firmar validaciones para el mismo libro mayor asegura que se alcanzó un consenso real. (Si no hubo un consenso real debido a una falla bizantina, la red simplemente vuelve a intentarlo).

El algoritmo de avalancha está diseñado para que se requiera una mínima superposición de confianza. Esencialmente, si no hay razón para no incluir una transacción, todos los nodos honestos deberían estar de acuerdo en incluirla. Si hay alguna razón por la que una transacción no debería incluirse, no hay ningún problema en excluirla. (Siempre que se incluya en la siguiente ronda si aún es válido).

Según mi conocimiento, es muy difícil lograr el rendimiento en el algoritmo de consenso, ya que todos los nodos de verificación deben contribuir con sus propios votos. ¿Cómo proporciona Ripple el rendimiento de la verificación de transacciones?
Los tiempos de propagación de la red son bastante rápidos. La mayoría de las veces, no hay desacuerdo de todos modos. (Todos proponen, todos esperan dos segundos para la propagación, todos se dan cuenta de que no hay un desacuerdo significativo. Listo). Y la red está dispuesta a tolerar una ronda de consenso fallida a cambio de velocidad el 99,5 % del tiempo. Además, un algoritmo de "rechazo" permite que los nodos de bajo rendimiento eviten causar problemas. La red equilibra no ser tan lenta como el nodo más lento (por razones de rendimiento) con no ser tan rápida como el nodo más rápido (por razones de seguridad).
¿Por qué no puede usar un algoritmo como Paxos que tiene un líder?
¿Cómo elegirías a un líder en el que todos estuvieran de acuerdo? ¿Cómo evitaría que alguien juegue con la selección del líder y evite que la red progrese? ¿Qué pasaría con los nodos que el líder no desea escuchar? ¿Serían excluidos de una ronda completa?
@Gracchus Hay dos esperas de un mínimo de 2 segundos, una para darle a cada servidor la oportunidad de hacer una propuesta inicial (para que nadie declare que se llegó a un consenso sin escuchar a todos) y otra para darle a cada servidor la oportunidad de procesar la propuesta final. conjunto de transacciones de consenso (para evitar que los servidores se queden atrás). Sin embargo, estos son solo mínimos, el tiempo real es adaptativo.
Algoritmo de consenso distribuido ondulado
RespuestasAquíPolítica de privacidad1y, 0v