Introducción al Quórum (2): Consenso del Quórum
A diferencia del entorno de la cadena pública, todos los miembros de la cadena empresarial o de la cadena de alianza que tienen umbrales de acceso en realidad han obtenido cierto reconocimiento y permiso al unirse, por lo que los miembros de la cadena empresarial/cadena de alianza tienen una cierta base de confianza. En la cadena empresarial, no necesitamos utilizar POW o POS, lo cual es un desperdicio de potencia informática o conocimiento de transacciones ineficiente.
Quorum proporciona una variedad de * * * conocimientos para que los usuarios los adopten:
Antes de hablar de Raft, es necesario mencionar el algoritmo Paxos, que fue propuesto por Leslie Lamport en 1990. Algoritmo de consenso basado en mensajes. Pero como el algoritmo era difícil de entender, al principio no llamó mucho la atención. El autor lo publicó en la ACM ocho años después, en 1998. Sin embargo, los algoritmos no se toman en serio porque son difíciles de entender. Posteriormente, el autor volvió a publicar el artículo "Paxos Made Simple" de una manera más aceptable.
Se puede ver que el algoritmo de Paxos es difícil de entender. Aunque ahora se invierte en muchas universidades, muchos estudiantes y profesores todavía informan que el algoritmo de Paxos es difícil de entender. Al mismo tiempo, el algoritmo Paxos también es difícil de implementar en aplicaciones prácticas. Esta es también la razón por la que más tarde se propuso el algoritmo Raft.
Raft es un algoritmo para implementar conocimiento distribuido y se utiliza principalmente para gestionar la coherencia de la replicación de registros. Tiene la misma funcionalidad que Paxos, pero en comparación con Paxos, el algoritmo Raft es más fácil de entender y aplicar a sistemas reales. El algoritmo Raft es también el *algoritmo de conocimiento utilizado por la cadena de alianza.
Raft I * * * tiene tres estados de función:
Cada nodo tiene un tiempo de espera de elección y el tiempo varía aleatoriamente entre 150 ms y 300 ms. Hay varias situaciones en las que se restablecerá el tiempo de espera:
En un sistema distribuido, la "sincronización horaria" es un gran problema, porque cada máquina puede tener diferentes grados de inconsistencia del reloj debido a factores como la ubicación geográfica, entorno de la máquina, etc., pero para identificar la "información caducada", la información de tiempo es esencial.
El algoritmo Raft utiliza el concepto de Término ($Término) para dividir el tiempo en $Término (al mismo tiempo, cada nodo también mantendrá el término actual localmente), lo que puede considerarse como tiempo lógico, como se muestra en la figura siguiente.
El comienzo de cada mandato es una elección de liderazgo, donde uno o más candidatos intentarán convertirse en líder. Si una persona gana las elecciones, se convierte en líder por el resto del mandato ($TERM). En algunos casos, es posible que se cuenten los votos y que el líder no sea elegido (como t3), luego comenzará otro mandato y la siguiente elección comenzará inmediatamente. El algoritmo Raft garantiza que haya al menos un líder en determinadas condiciones.
Manejo de situaciones especiales
En Ethereum, el nodo en sí no tiene ninguna función, por lo que cuando utilizamos el conocimiento de Raft***, llamamos al nodo líder nodo minero:
El mecanismo de conocimiento Raft*** en sí mismo garantiza que haya como máximo un líder al mismo tiempo, por lo que cuando se utiliza en el modelo Ethereum, solo habrá un bloqueador, evitando el bloqueo simultáneo o el desperdicio de potencia informática.
A nivel de transacción única, Quorum todavía sigue el mecanismo de transmisión p2p de Ethereum y solo utiliza el mecanismo de transmisión Raft a nivel de bloque.
Cabe señalar que en Ethereum, un nodo retendrá una cuenta inmediatamente después de recibir un bloque, mientras que en el modelo Quorum, el registro de un bloque debe cumplir con el protocolo Raft. Después de que cada nodo recibe el bloque del líder, debe informar al líder para confirmar la recepción, y luego el líder notifica a todos los nodos que envíen datos (registros).
En el modelo Quorum, es probable que la información del nuevo bloque sea inconsistente con la información del encabezado del bloque existente. Lo más probable es que ocurra el reemplazo de votantes (reemplazo de nodos mineros). que se describe a continuación:
Supongamos que hay dos nodos, nodo1 y nodo2, el nodo1 es el líder existente, el último bloque de la cadena existente es 0xbeda y su bloque principal es 0xacaa.
El marcado de bloques como "extendido" o "no operativo" se realiza en un nivel superior y no lo implementa el propio mecanismo de registro de Raft. Porque dentro de Raft, no hay distinción entre información válida e inválida. Solo en el nivel de blockchain puede haber significado entre bloques válidos y no válidos.
Cabe señalar que el mecanismo de contabilidad de Quorum es completamente diferente al propio LVC (mecanismo de cadena más larga) de Ethereum.
De forma predeterminada, la frecuencia del bloque de arbitraje es de 50 milisegundos y se puede configurar mediante el parámetro -raftblocktime.
El bloqueo especulativo no es uno de los mecanismos centrales necesarios para que Ethereum comprenda estrictamente Raft, pero es una forma eficaz de mejorar la eficiencia del bloqueo.
En realidad, a un bloque le lleva algún tiempo pasar por todo el proceso de la balsa, desde la generación hasta la grabación real. Si comenzamos a generar el siguiente bloque después de que el último bloque se haya registrado en el libro mayor, llevará más tiempo registrar correctamente una transacción.
En la eliminación especulativa, permitimos que se generen nuevos fragmentos antes de que se registren los fragmentos principales. Por analogía, con el tiempo se generará una "cadena de especulación". Antes de que el bloque antecesor se registre en el libro mayor, se ha formado secuencialmente un nuevo bloque en segmentos de cadena temporales, en espera de ser registrado.
Para las transacciones que se han registrado en el bloque de especulación, las marcaremos como "transacciones sugeridas" en el grupo de transacciones.
Hemos dicho antes que es posible que dos nodos mineros compitan por bloques y contabilicen bajo el mecanismo de balsa, por lo que es muy probable que un bloque en medio de una cadena especulativa no se registre en el libro mayor. En este caso, también modificaremos el estado de la transacción en el grupo de transacciones. (Evento InvalidRaftOrdering)
Actualmente, Quorum no limita la longitud de la cadena de especulación, pero mencionó en sus planes futuros que se agregará al proceso de desarrollo como un elemento de optimización del rendimiento. Finalmente, incluso si un nodo minero no está conectado a la capa de conocimiento de la balsa***, siempre se puede proteger para que no esté fuera de línea y genere su propia cadena de especulación.
La cadena especulativa consta de las siguientes partes:
En la transmisión en bloque, utilizamos la transmisión http predeterminada de etcd Raft. Por supuesto, también es posible utilizar la transferencia p2p de Ethereum, pero el equipo de Quorum descubrió que ETH p2p no funciona tan bien como raft p2p bajo cargas elevadas.
Quorum utiliza el puerto 50400 como puerto de escucha predeterminado de la capa de transporte Raft, que también se puede configurar mediante el parámetro -raftport.
El número máximo predeterminado de nodos en un clúster es 25, que se puede configurar con -maxpeers N, donde N es el número máximo de nodos.
El IBFT de Quorum es en realidad PBFT, pero JP Morgan llama a su PBFT IBFT, por lo que los principios básicos de IBFT son los mismos que los de PBFT. La diferencia es que IBFT combina las tres etapas del conocimiento.
Istanbul BFT es una mejora del algoritmo PBFT e incluye tres etapas: preparación previa, preparación y envío. En una red con N nodos, este algoritmo puede tolerar hasta f nodos defectuosos, donde N=3F+1.
Los bloques en el algoritmo BFT de Estambul son deterministas, lo que significa que la cadena no está bifurcada y debe haber un bloque legítimo en la cadena. Para evitar que los nodos maliciosos generen cadenas diferentes, cada validador debe colocar una firma de confirmación 2F+1 en el campo de datos externos del encabezado del bloque antes de insertar el bloque en la cadena. Por tanto, el bloque es autoverificante (porque está firmado) y soportado por clientes ligeros.
Sin embargo, los extraData dinámicos también pueden causar problemas de cálculo de hash de bloque. Debido a que un bloque puede ser verificado por diferentes validadores, tendrá firmas diferentes y, por lo tanto, el mismo bloque tendrá hashes diferentes. La solución es excluir las firmas de confirmación al calcular el hash del bloque. Por lo tanto, aún podemos verificar el conocimiento y al mismo tiempo garantizar la coherencia del hash del bloque.
Dado que se han introducido muchos conocimientos sobre Ethereum POA*** en línea, el autor no los presentará en detalle aquí. Solo clasificaré e introduciré las características importantes y el flujo de trabajo de POA.