El Protocolo de Consenso Stellar fue descrito por primera vez en David Mazieres en 2015. Es un "sistema de acuerdo federativo" que permite a redes informáticas descentralizadas, sin líderes, llegar a un consenso sobre cualquier decisión de manera efectiva. La red de pagos Stellar utiliza el Stellar Consensus Protocol (SCP) para mantener un historial de transacciones consensuado que es visible para todos los participantes.
Se considera que los protocolos de consenso son difíciles de entender. SCP es más simple que la mayoría de ellos, pero aún así comparte esta reputación, en parte debido a la idea errónea de que la "votación federativa", que se aborda en la primera mitad del artículo científico, es SCP. ¡Pero no es así! Es solo un bloque de construcción importante que se utiliza en la segunda mitad del artículo para crear el protocolo de consenso Stellar.
En este artículo, explicaremos brevemente qué es un "sistema de acuerdos", qué puede hacer que sea "bizantino" y por qué hacer que un sistema bizantino sea "federativo". Luego explicaremos el procedimiento de votación federativa descrito en el artículo sobre SCP y, finalmente, explicaremos el propio protocolo SCP.
Sistemas de acuerdos
Un sistema de acuerdos permite a un grupo de participantes llegar a un consenso sobre algún tema, por ejemplo, qué pedir para almorzar.
En Interstellar hemos implementado nuestro propio sistema de acuerdos sobre almuerzos: pedimos lo que dice nuestro gerente operativo, John. Es un sistema simple y efectivo de acuerdos. Todos confiamos en John y creemos que encontrará algo interesante y nutritivo cada día.
Pero, ¿qué pasaría si John abusara de nuestra confianza? Podría decidir unilateralmente que todos debemos ser veganos. Después de una o dos semanas, probablemente lo derrocaríamos y pasaríamos el poder a Elizabeth. Pero, ¿y si a ella le encanta el aguacate con anchoas y piensa que todos deberían ser así? El poder corrompe. Por lo tanto, es mejor encontrar un método más democrático: alguna forma de asegurarse de que se tengan en cuenta diferentes preferencias, mientras se proporciona un resultado claro y oportuno, para que no termine sucediendo que nadie pida almuerzo o cinco personas hagan diferentes pedidos, o que la discusión se prolongue hasta la noche.
Aparentemente, la solución es simple: ¡realizar una votación! Pero esta es una impresión engañosa. ¿Quién se encargará de recoger las boletas y comunicar los resultados? ¿Y por qué los demás deberían creer lo que él diga? Quizás podamos primero votar por un líder en quien confiamos para dirigir la votación, pero ¿quién se encargará de esta primero votación? ¿Qué sucede si no podemos ponernos de acuerdo sobre un líder? ¿O si llegamos a un acuerdo, pero este líder se atora en una reunión o se enferma?
Problemas similares ocurren en redes informáticas distribuidas. Todos los participantes o nodos deben consensuar alguna decisión, como quién debe actualizar un archivo compartido o recoger una tarea de la cola de procesamiento. En una red de criptomonedas, los nodos a menudo deben elegir cómo se verá la historia completa entre varias versiones posibles que a veces entran en conflicto. Este consenso de red garantiza al receptor que la moneda es (a) válida (no falsa) y (b) aún no se ha gastado en otro lugar. También garantiza que podrá gastar las monedas en el futuro, porque el nuevo receptor tendrá las mismas garantías por las mismas razones.
Cualquier sistema de consenso en una red informática distribuida debe ser tolerante a fallos: debe ofrecer resultados consistentes a pesar de errores como líneas de comunicación lentas, nodos que no responden y un orden incorrecto de los mensajes. El sistema de consenso bizantino es aún más resistente a errores «bizantinos»: nodos que proporcionan información falsa, ya sea por error o en un intento deliberado de socavar el sistema o obtener alguna ventaja. La tolerancia a fallos «bizantina» — la capacidad de confiar en una decisión grupal, incluso cuando algunos miembros del grupo pueden mentir o de alguna manera no seguir las reglas de toma de decisiones — recibe su nombre de , que intentaban coordinar un ataque. se encuentra en Anthony Stevens.
Consideremos a Alice, la propietaria de la criptomoneda, quien debe elegir entre comprar un helado delicioso de Bob o pagar la deuda de Carol. Puede que Alice quiera pagar a ambos a la vez, gastando fraudulentamente la misma moneda. Para ello, debe convencer a la computadora de Bob de que la moneda nunca fue pagada a Carol, y convencer a la computadora de Carol de que la moneda nunca fue pagada a Bob. Un sistema bizantino de acuerdos hace que esto sea prácticamente imposible, utilizando una forma de regla de mayoría llamada quórum. Un nodo en tal red se niega a hacer la transición a una versión específica de la historia hasta que no vea que un número suficiente de nodos pares —el quórum— está de acuerdo con dicha transición. Una vez que esto ocurra, formarán un bloque electoral lo suficientemente grande como para forzar a los nodos restantes de la red a aceptar su decisión. Alice puede hacer que algunos nodos mientan en su nombre, pero si la red es lo suficientemente grande, su intento será reprimido por las voces de los nodos honestos.
¿Cuántos nodos se requieren para un quórum? Al menos una mayoría, o más precisamente, una mayoría calificada para combatir errores y fraudes. Pero para contar la mayoría, es necesario conocer el número total de participantes. En una oficina de Interstellar o en unas elecciones locales, estas cifras son fáciles de obtener. Pero si su grupo es una red débilmente definida, en la que los nodos pueden entrar y salir a voluntad sin consultar con un centro, entonces se necesita un sistema federado de acuerdo bizantino, capaz de determinar los quórums no a partir de una lista de nodos predefinida, sino de manera dinámica, a partir de una instantánea constantemente cambiante e inevitablemente incompleta de nodos en un momento determinado.
Puede parecer imposible crear un quórum desde la perspectiva de un nodo en una extensa red, pero es posible. Tal quórum incluso puede garantizar resultados de votación descentralizada. El documento técnico SCP muestra cómo hacerlo mediante un procedimiento llamado votación federada.
Para los impacientes
El resto del artículo describe con más detalle la votación federada y el protocolo de consenso Stellar. Si no te interesan los detalles, aquí tienes un resumen general del proceso.
- Los nodos realizan rondas de votación federal sobre los «nominados». La ronda de votación federal significa:
- El nodo vota sobre una afirmación, por ejemplo, «Propongo el valor V»;
- El nodo escucha las voces de los pares hasta que encuentra una que pueda «aceptar»;
- El nodo busca un «quórum» para esta afirmación. El quórum «confirma» al nominado.
- Una vez que el nodo puede confirmar uno o varios nominados, intenta «preparar» la «boleta» a través de varias rondas de votación federal.
- Una vez que el nodo puede verificar la preparación de la boleta, intenta comprometerla mediante aún más rondas de votación federal.
- Una vez que el nodo puede confirmar el compromiso de la boleta, puede «externalizar» el valor de esta boleta, utilizándola como resultado del consenso.
Estos pasos incluyen varias rondas de votación federal, que en conjunto forman una ronda SCP. Veamos en detalle qué sucede en cada paso.
Votación federal
La votación federal es el procedimiento para determinar si la red puede consensuar una propuesta. En la ronda de votación, cada nodo debe elegir uno de muchos valores potencialmente posibles. No puede hacerlo hasta que esté seguro de que otros nodos en la red no eligirán otro resultado. Para estar seguros, los nodos intercambian una avalancha de mensajes hacia adelante y hacia atrás, para que cada confirmó, que quórum de nodos toma sea el mismo solución. El resto de esta sección explica los términos en esta afirmación y cómo se lleva a cabo todo el procedimiento.
Quórums y cortes de quórum
Empecemos por definir el quórum. Como discutimos anteriormente, en una red descentralizada con membresía dinámica, es imposible saber de antemano cuántos nodos hay y, por lo tanto, cuántos se necesitan para una mayoría. La votación federal aborda este problema al presentar una nueva idea corte de quórum (quorum slice): un pequeño conjunto de nodos entre pares en los que un nodo confía para transmitir información sobre el estado de la votación al resto de la red. Cada nodo define su propio corte de quórum (del cual se convierte en miembro de facto).
La formación de quórum comienza con el corte de quórum. Para cada nodo, se añaden los nodos de su corte. Luego se añaden miembros de los cortes. nodos y así sucesivamente. A medida que avanzamos, encontraremos más nodos que no se pueden agregar porque ya están incluidos en el corte. Cuando ya no haya más nodos nuevos para agregar, el proceso se detiene: hemos formado un quórum a través del «cierre transitivo» del corte del nodo inicial.
Para encontrar un quórum a partir de un nodo dado…
… agregamos miembros de su corte…
… luego agregamos miembros de los cortes de estos nodos.
Continuamos hasta que no queden nodos para agregar.
No quedan nodos para agregar. Este es el quórum.
En realidad, cada nodo puede estar en más de un corte. Para formar un quórum, selecciona solo uno de los cortes y agrega miembros; luego elige cualquier corte para cada uno de los miembros y agrega miembros del esto corte y así sucesivamente. Esto significa que cada nodo es miembro de un conjunto de posibles quorum.
Selecciona solo un corte de quórum en cada paso.
Un quórum posible. O una alternativa…
… elegimos otros cortes…
… (cuando sea posible)…
… crea otro quórum.
¿Cómo sabe un nodo en qué cortes están otros nodos? De la misma manera que otra información sobre otros nodos: de las transmisiones que cada nodo emite en la red cuando su estado de votación cambia. Cada transmisión incluye información sobre los cortes del nodo emisor. En el documento técnico SCP no se especifica el mecanismo de comunicación. Las implementaciones generalmente utilizan para garantizar la transmisión de mensajes en toda la red.
Recordemos que en el sistema de acuerdos bizantino no federativo, el quórum se define como la mayoría de todos los nodos. El sistema de acuerdos bizantino se ha desarrollado en términos de la pregunta: ¿cuántos nodos deshonestos puede soportar el sistema? En un sistema de N nodos, diseñado para sobrevivir a f fallos (engaños), un nodo debe ser capaz de avanzar al recibir respuestas de N−f pares, ya que f de ellos pueden no estar funcionando. Sin embargo, al recibir respuestas de N−f pares, se puede suponer que todos los f pares (de los que el nodo no recibió respuesta) son en realidad honestos. Así, f de los N−f pares (de los que se recibió respuesta) son perjudiciales. Para que los nodos lleguen a un consenso, la mayoría de los demás nodos debe ser honesta, es decir, necesitamos que N−f sea mayor que 2f o N > 3f. Así que, generalmente, un sistema diseñado para sobrevivir a f fallos tendrá un total de N=3f+1 nodos y un tamaño de quórum de 2f+1. Una vez que la propuesta supera el umbral del quórum, los demás miembros de la red están convencidos de que cualquier propuesta competidora fracasará. Así, la red converge en un resultado.
Pero en el sistema de acuerdos bizantino federativo no puede haber una mayoría (porque nadie conoce el tamaño total de la red), ¡y el concepto de mayoría es completamente inútil! Si la membresía en el sistema es abierta, alguien puede obtener una mayoría simplemente llevando a cabo un ataque de Sibil, uniéndose a la red múltiples veces a través de varios nodos. Entonces, ¿por qué se puede llamar al cierre transitivo del corte? quórum, y cómo es capaz de suprimir propuestas competidoras?
Técnicamente, ¡no hay forma! Imagina una red de seis nodos, donde dos tríos están aislados en los cortes de quórum entre sí. El primer subgrupo puede tomar decisiones de las que el segundo nunca escuchará, y viceversa. Para esta red, no hay forma de alcanzar consenso (salvo por azar).
Por lo tanto, el SCP requiere que para la votación federativa (y para aplicar importantes teoremas del artículo), la red debe poseer una propiedad llamada intersección de quórumsEn una red con esta propiedad, cualquier par de quorums que se puedan construir siempre se intersectan en al menos un nodo. Para determinar las opiniones predominantes de la red, esto es tan bueno como tener una mayoría. Intuitivamente, esto significa que si algún quorum está de acuerdo con la afirmación X, ningún otro quorum podrá estar de acuerdo con algo diferente, porque necesariamente incluirá algún nodo del primer quorum que ya ha votado por X.
Si en la red hay intersecciones de quorums...
... entonces cualquier par de quorums que puedas construir...
... siempre se cruzarán.
(Por supuesto, los nodos que se cruzan pueden ser bizantinos, mentirosos o defectuosos de otras maneras. En este caso, la intersección de quorums no ayuda a la red a alcanzar un consenso en absoluto. Por esta razón, muchos resultados en el documento técnico de SCP se basan en supuestos explícitos, como que en la red aún queda intersección de quorums, incluso después de eliminar nodos defectuosos.Para simplificar, dejaremos estos supuestos implícitos en el resto del artículo).
Puede parecer poco razonable esperar que en una red de nodos independientes sea posible la intersección confiable de quorums. Pero hay dos razones por las cuales esto es así.
La primera razón es la existencia misma de internet. Internet es un ejemplo perfecto de una red de nodos independientes con intersección de quorums. La mayoría de los nodos en internet solo están conectados a unos pocos otros nodos locales, pero estos pequeños conjuntos se superponen lo suficiente para que cada nodo sea accesible desde cualquier otro nodo a través de alguna ruta.
La segunda razón es específica para la red de pagos Stellar (la aplicación más común del SCP). Cada activo en la red Stellar tiene un emisor, y las recomendaciones de Stellar requieren que cada emisor designe uno o más nodos en la red para procesar las solicitudes de redención. Es en su interés incluir directa o indirectamente esos nodos en los cortes de quórum para cada activo de su interés. Así, los quórums para todos los nodos interesados en un activo determinado se superpondrán al menos en esos nodos de redención. Los nodos interesados en múltiples activos incluirán en sus cortes de quórum todos los nodos de redención de los emisores correspondientes, y se esforzarán por agrupar todos los activos juntos. Además, cualquier activo que no esté vinculado de esta manera a otros en la red y no debe estar vinculado — está diseñado para que no haya superposición de quórums en esta red (por ejemplo, los bancos de la zona del dólar a veces quieren comerciar con bancos de la zona del euro y bancos de la zona del peso, por lo que están en una misma red, pero a ninguno de ellos le importa la red separada de niños que comercian tarjetas de béisbol).
Por supuesto, la expectativa de superposición de quórums no es una garantía. Otras sistemas de acuerdos bizantinos deben su complejidad en gran parte a la garantía de los quórums. Una innovación importante del SCP es que desplaza la responsabilidad de crear quórums del propio algoritmo de consenso al nivel de la aplicación. Por lo tanto, aunque la votación federativa es bastante general para votar sobre cualquier asunto, su fiabilidad depende críticamente de un sentido más amplio de estos significados. Algunos usos hipotéticos pueden resultar menos convenientes para crear redes bien conectadas que otros.
La votación, la aceptación y la confirmación
En la ronda de votación federativa, un nodo opcionalmente comienza a votar por algún valor V. Esto significa la transmisión a la red del mensaje: 'Soy el nodo N, mis cortes de quórum Q, y voto por V'. Cuando un nodo vota de esta manera, promete que nunca ha votado en contra de V y que nunca lo hará.
En las transmisiones de nodos entre pares, cada nodo ve cómo votan los demás. Una vez que un nodo recopila suficientes mensajes, puede rastrear los quórums y tratar de encontrarlos. Si ve un quórum de pares que también votan por V, puede proceder a aceptar V y transmitir este nuevo mensaje a la red: «Yo soy el nodo N, mis cortes de quórum Q, y acepto V». La aceptación proporciona una garantía más fuerte que simplemente votar. Cuando un nodo vota por V, nunca puede votar por otras opciones. Pero si un nodo acepta V, ningún nodo en la red aceptará otra opción (la Teorema 8 en el documento técnico SCP lo prueba).
Por supuesto, hay una alta probabilidad de que no se encuentre de inmediato un quórum de nodos que estén de acuerdo con V. Otros nodos pueden votar por otros valores. Pero para un nodo hay otra forma de pasar de simplemente votar a aceptar. N puede aceptar otro valor W, incluso si no ha votado por él, y incluso si no ve un quórum para él. Para decidir cambiar su voto, solo necesita ver un conjunto bloqueador de nodos que aceptaron W. Un conjunto bloqueador consiste en un nodo de cada uno de los cortes de quórum de N. Como su nombre indica, es capaz de bloquear cualquier otro valor. Si todos los nodos en tal conjunto aceptan W, entonces (según la Teorema 8) nunca se podrá formar un quórum que acepte otro valor, y por lo tanto es seguro para N aceptar W.
El nodo N con tres cortes de quórum.
B-D-F es el conjunto bloqueador para N: incluye un nodo de cada uno de los cortes de N.
B-E también es un conjunto bloqueador para N, porque E aparece en dos cortes de N.
Pero un conjunto bloqueador no es un quórum. Sería demasiado fácil engañar al nodo N para que aceptara el valor deseado si solo se necesitara comprometer un nodo en cada uno de los cortes de N. Por lo tanto, aceptar un valor no es el final de la votación. En cambio, N debe confirmar el valor, es decir, ver un quórum de nodos que lo acepten. Si llega tan lejos, entonces, como prueba el documento técnico SCP (en la Teorema 11), el resto de la red también terminará eventualmente confirmando el mismo valor, por lo que N concluirá la votación federativa con un valor determinado como resultado.
Votación federativa.
El proceso de votación, aceptación y confirmación consiste en una ronda completa de votación federativa. El protocolo de consenso Stellar combina muchas de estas rondas para crear un sistema de consenso completo.
Protocolo de consenso Stellar
Las dos propiedades más importantes de un sistema de consenso son seguridad y resiliencia. Un algoritmo de consenso es "seguro" si nunca puede dar diferentes resultados a diferentes participantes (la copia de la historia de Bob nunca contradice a Carol). "Resiliencia" significa que el algoritmo siempre producirá un resultado, es decir, no quedará atascado.
El procedimiento de votación federativa descrito es seguro en el sentido de que si un nodo confirma el valor V, ningún otro nodo confirmará un valor diferente. Pero "no confirmar un valor diferente" no significa que necesariamente confirmará algo. Los participantes pueden votar por un número tan grande de valores diferentes que nada alcance el umbral de aceptación. Esto significa que en la votación federativa hay ausencia de resiliencia.
El protocolo de consenso Stellar utiliza la votación federativa de tal manera que garantiza tanto la seguridad como la resiliencia. (Las garantías de seguridad y resiliencia del SCP tienen un límite teórico. La construcción elige una garantía de seguridad muy fuerte, sacrificando una leve disminución de la resiliencia, pero dado un tiempo suficiente, el consenso se alcanzará con alta probabilidad). En pocas palabras, la idea es llevar a cabo varias votaciones federativas sobre varios valores hasta que uno de ellos pase completamente por todas las fases de votación SCP, descritas a continuación.
Los valores a los que el SCP aspira a llegar a un consenso pueden ser el historial de transacciones o un pedido de almuerzo, o cualquier otra cosa, pero es importante señalar que no son esos valores los que se aceptan o confirman. En cambio, la votación federativa ocurre sobre declaraciones sobre esos valores.
Las primeras rondas de votación federativa ocurren en la etapa de nominación (nomination phase), en un conjunto de declaraciones como "Propongo V", posiblemente para muchos valores diferentes de V. El objetivo de la nominación es encontrar una o varias declaraciones que pasen por aceptación y confirmación.
Después de encontrar candidatos verificables, SCP avanza a la etapa de votación, donde el objetivo es identificar un boletín (es decir, un contenedor para el valor propuesto) y un quórum que pueda declarar commit para ello (commit). Si el quórum realiza el commit del boletín, su valor se acepta como consenso. Pero antes de que un nodo pueda votar por el commit del boletín, primero debe confirmar la anulación de todos los boletines con un valor de contador menor. Estos pasos: anular boletines para encontrar aquel para el que se puede confirmar el commit, incluyen varias rondas de votación federativa sobre múltiples declaraciones de boletines.
En las siguientes secciones se describen con más detalle la nominación y la votación.
Nominación
Al inicio de la etapa de nominación, cada nodo puede elegir espontáneamente un valor V y votar por la afirmación 'Nombro V'. El objetivo en esta etapa es confirmar la nominación de algún valor mediante votación federativa.
Es posible que un número suficiente de nodos vote por afirmaciones lo suficientemente diferentes, y ninguna nominación puede alcanzar el umbral de aceptación. Por lo tanto, además de transmitir sus propios votos de nominación, los nodos 'reflejan' las nominaciones de sus pares. Reflejar significa que si un nodo vota por la nominación V, pero ve un mensaje de un vecino que vota por la nominación W, entonces también comenzará a votar por la nominación tanto de V como de W. (No todos los votos de los pares se reflejan durante la nominación, ya que esto puede llevar a una explosión de diferentes nominados. SCP incluye un mecanismo para regular estos votos. En resumen, existe una fórmula para determinar la 'prioridad' de un par desde el punto de vista de un nodo, y solo se reflejan los votos de nodos de alta prioridad. Cuanto más tiempo dure la nominación, más bajo será el umbral, por lo que el nodo expande el conjunto de pares cuyos votos reflejará. La fórmula de prioridad, como uno de los datos de entrada, incluye el número de ranura, por lo que un nodo par de alta prioridad para una ranura puede ser de baja prioridad para otra, y viceversa).
Conceptualmente, la propuesta de V y W simultáneamente son voces federativas separadas, cada una capaz de alcanzar la aceptación o confirmación por sí sola. En la práctica, los mensajes del protocolo SCP empaquetan estas voces separadas juntas.
Aunque la votación para la propuesta de V es una promesa de nunca votar en contra de la propuesta de V, a nivel de aplicación — en este caso SCP — se define lo que significa "en contra". SCP no ve una afirmación que contradiga el voto "propongo X", es decir, no hay mensaje "me opongo a la propuesta de X", por lo que el nodo puede votar a favor de cualquier valor propuesto. Muchas de estas nominaciones no llevarán a nada, pero al final, el nodo podrá aceptar o confirmar uno o varios valores. Una vez que el nominado es confirmado, se convierte en candidato.
La propuesta de SCP utilizando votación federativa. Pueden haber muchos valores “B” propuestos por nodos de igual rango y “reflejados” por un nodo.
La propuesta de candidatos puede dar lugar a varios candidatos confirmables. Por lo tanto, SCP requiere que el nivel de aplicación proporcione algún método para fusionar candidatos en uno solo composite (composición). El método de fusión puede ser cualquier forma. Lo principal es que si este método es determinista, cada nodo fusionará los mismos candidatos. En el sistema de votación de almuerzo, la "fusión" puede significar simplemente renunciar a uno de los dos candidatos. (Pero de manera determinista: cada nodo debe seleccionar el mismo valor para el reinicio. Por ejemplo, elegir en orden alfabético más temprano). En la red de pagos Stellar, donde se lleva a cabo la votación sobre el historial de transacciones, fusionar dos nominados propuestos implica fusionar las transacciones que contienen y las últimas de sus dos marcas de tiempo.
La descripción técnica de SCP demuestra (teorema 12) que para el final de la fase de propuesta, la red eventualmente converge a una sola composición. Pero hay un problema: la votación federativa es un protocolo asincrónico (al igual que SCP). En otras palabras, los nodos no están coordinados por tiempo, sino solo por los mensajes que envían. Desde el punto de vista de un nodo, no está claro cuándo finalizó fase de propuesta. Y aunque todos los nodos eventualmente llegarán al mismo compuesto, pueden elegir diferentes rutas en el camino, creando diferentes candidatos compuestos a lo largo del camino, y nunca pueden decir cuál de ellos es el final.
Pero está bien. La propuesta es solo una preparación. Lo principal es limitar el número de candidatos para alcanzar un consenso, que ocurre en el proceso de votación (votación).
La votación
Un boletín es un par , donde counter es un número entero que comienza en 1 y value es un candidato de la etapa de propuesta. Este puede ser el candidato del nodo o un candidato de un nodo vecino aceptado por este nodo. En términos simples, durante la votación se hacen múltiples intentos para que la red logre un consenso sobre algún candidato en algún boletín mediante la realización de potencialmente muchas votaciones federativas sobre declaraciones de boletín. Los contadores en los boletines rastrean los intentos realizados, y los boletines con contadores más altos tienen prioridad sobre los boletines con contadores más bajos. Si el boletín se atasca, comienza una nueva votación, ahora sobre el boletín .
Es importante distinguir valores (por ejemplo, qué debe ser el pedido del almuerzo: pizza o ensaladas), boletines (par counter-value) y declaraciones sobre los boletines. La ronda SCP incluye varias rondas de votación federativa, en particular, sobre declaraciones tales como:
- «Estoy listo para el compromiso del boletín B» y
- «Declaro el compromiso del boletín B»
Desde la perspectiva de este nodo, se alcanza el consenso cuando encuentra el boletín B, para el cual puede confirmar (es decir, encontrar un quórum que acepte) la declaración «Declaro el compromiso del boletín B». A partir de este momento, se puede actuar de manera segura sobre el valor indicado en B, por ejemplo, hacer este pedido de almuerzo. Esto se llama externalización del valor. Una vez confirmado el compromiso del boletín, el nodo puede estar seguro de que cualquier otro nodo ha externalizado este mismo valor o lo hará necesariamente en el futuro.
Aunque conceptualmente muchas votaciones federativas se llevan a cabo sobre declaraciones de muchas boletas diferentes, intercambian no tantos mensajes, porque cada mensaje encapsula un conjunto de boletas. Así, un mensaje promueve el estado de muchas votaciones federativas a la vez, por ejemplo: «Acepto el compromiso de las boletas en el rango de a ».
¿Qué significan los términos «preparado» (prepared) y «compromiso» (commit)?
Un nodo vota para comprometer una boleta cuando está convencido de que otros nodos no harán commit de boletas con otros valores. Convencer a otros es el objetivo de preparar la declaración. Votación que dice: «Estoy listo para el compromiso de la boleta B» es una promesa de nunca comprometer una boleta menor que B, es decir, con un contador más bajo (SCP requiere que los valores en las boletas tengan un orden definido. Así, la boleta es menor que , si N1<N2, y también si N1=N2 y V1<V2). Estas boletas menores son «rechazadas» (aborted) durante la votación preparatoria, mientras que B se considera «preparado».
¿Por qué «Estoy listo para el compromiso de la boleta B» significa «Prometo nunca permitir el compromiso de boletas menores que B»? Porque SCP define abortar como la oposición a comprometerse. La votación para preparar una boleta también implica votar para rechazar algunas otras boletas, y como discutimos anteriormente, votar por algo es una promesa de nunca votar en contra de ello.
Antes de transmitir el compromiso, un nodo debe primero encontrar una boleta que pueda confirmar como preparada. En otras palabras, realiza una votación federativa sobre el tema «Estoy listo para el compromiso de la boleta B», posiblemente para muchas boletas diferentes, hasta que encuentre una que acepte el quórum.
¿De dónde provienen las boletas para la preparación de la votación? Primero, el nodo transmite la preparación para la votación de , donde C es el candidato compuesto, generado en la etapa de nominación. Sin embargo, incluso después de que comience la preparación para la votación, la nominación puede dar lugar a candidatos adicionales que se convertirán en nuevas boletas. Mientras tanto, los pares pueden tener diferentes candidatos, y pueden formar un conjunto bloqueante que acepta "Estoy listo para comprometer la boleta B2", lo que convencerá al nodo de también aceptarlo. Por último, hay un mecanismo de tiempo de espera que genera nuevas rondas de votación federativa en nuevas boletas con contadores más altos, si las boletas actuales están atascadas.
Una vez que el nodo encuentra la boleta B, que puede confirmar como preparada, entonces transmite un nuevo mensaje "Comprometer la boleta B". Esta votación le dice a los pares que el nodo nunca se apartará de B. De hecho, si B representa una boleta , entonces "Comprometer la boleta " significa un consentimiento incondicional para votar por la disposición de cada boleta desde hasta . Este valor adicional ayuda a otros nodos a ponerse al día con el par al comprometerse, si aún están en etapas más tempranas del protocolo.
En esta etapa, vale la pena reiterar que se trata de protocolos asíncronos. Solo porque un nodo envíe votos para un compromiso, no significa que sus pares también lo hagan. Algunos de ellos aún pueden estar votando sobre declaraciones para la preparación de la votación, otros pueden haber externalizado ya el valor. SCP explica cómo un nodo debe procesar cada tipo de mensaje de igual a igual independientemente de su fase.
Si el mensaje «Declaro compromiso <N,C>» no puede ser aceptado o confirmado, entonces existe la posibilidad de aceptar o confirmar el mensaje <N+1, C> o <N+2, C> — o, en cualquier caso, cualquier boletín con el valor C, y no otro, ya que el nodo ha prometido nunca revertir <N,C>. Para el momento en que el nodo transmite votos para el compromiso, esto será C o nada, dependiendo de cuán lejos llegue el consenso. Sin embargo, esto no es suficiente para que el nodo externalice C. Algunos piratas bizantinos (que constituyen menos del quórum, basándose en nuestras suposiciones de seguridad) pueden mentirle al nodo. Aceptar y luego confirmar algún boletín (o rango de boletines) es lo que le da al nodo la confianza para finalmente externalizar C.
Votación SCP a través de votación federativa. No se muestra: en cualquier momento se puede activar un temporizador, aumentando el contador en el boletín (y, posiblemente, produciendo un nuevo compuesto de candidatos adicionales postulados).
¡Y eso es todo! Una vez que la red llega a un consenso, está lista para hacerlo una y otra vez. En la red de pagos Stellar, esto ocurre aproximadamente cada 5 segundos: un logro que requiere tanto seguridad como resiliencia, garantizadas por SCP.
SCP puede lograr esto apoyándose en varios rondas de votación federativa. La votación federativa se hizo posible gracias al concepto de cortes de quórum: conjuntos de nodos entre pares, en los que cada nodo decidió confiar como parte de su quórum (subjetivo). Esta configuración significa que se puede llegar a un consenso incluso en una red de membresía abierta y engaños bizantinos.
Lectura adicional
- El documento técnico original de SCP se puede encontrar , y proyecto de especificaciones para su implementación.
- El autor original del protocolo SCP, David Mazieres, explica de manera simplificada (pero aún técnica) su .
- Es posible que se haya sorprendido al no encontrar en este artículo los términos «mining» o «prueba de trabajo». SCP no utiliza estos métodos, pero algunos otros algoritmos de consenso sí. Zain R. Weiszpfenning escribió una accesible .
- de una red simple, alcanzando consenso en una única ronda completa de SCP.
- Para los lectores interesados en implementaciones de SCP: vea. , utilizado por la red de pagos Stellar, o , que escribí para una mejor comprensión de SCP.
Fuente: habr.com
