La semana pasada, cubrimos la Prueba de participación. Esta semana repasaremos el protocolo de consenso de Thunderella. Si bien este artículo es independiente, se recomienda encarecidamente que esté familiarizado con el contenido cubierto en nuestras preliminares y publicaciones de PBFT.
La principal innovación del protocolo de consenso de Thunderella es la combinación del consenso clásico con el consenso en cadena de Nakamoto, que ofrece lo mejor de ambos mundos.
Los protocolos clásicos son extremadamente rápidos a pequeña escala. Las transacciones se pueden confirmar a velocidades que se acercan a las implementaciones centralizadas. Sin embargo, estos protocolos pueden ser complejos, difíciles de implementar y no escalan en número de participantes. Por el contrario, los protocolos de Nakamoto son simples, tienen propiedades de robustez adicionales, pueden escalar en participantes indefinidamente, pero se necesitan minutos para confirmar transacciones con alta probabilidad.
Recuerde que en nuestra descripción de PBFT, se ejecuta un cambio de vista si no se ve ninguna propuesta de la primaria durante un período de tiempo suficientemente largo. Durante un cambio de vista, los nodos intercambian mensajes para acordar lo siguiente:
De hecho, ha ocurrido un cambio de vista Cuál es el estado de la red justo antes del cambio
En efecto, los nodos están llegando a un consenso sin un proponente principal. La observación clave para el protocolo Thunderella es que podemos confiar en una cadena lenta de prueba de trabajo para el consenso cuando se trata de 1. y 2. que llamaremos respaldo y recuperación respectivamente.
Suponga un conjunto previamente acordado de aceleradores y miembros del comité (lo mismo que los proponentes y votantes). Una versión simplificada del protocolo Thunderella, que crea bloques en la ruta rápida, se puede describir simplemente de la siguiente manera:
El acelerador activo firma una propuesta (bloque) para agregar a la cadena de bloques (registro ordenado linealmente) y la envía al comité.Cada miembro del comité vota sobre la propuesta firmándola si es una extensión válida de su cadena de bloques y devuelve su voto. al acelerador Al recoger ¾ de los votos del comité, el acelerador activo los combina en una notarización y la transmite, si se observa una notarización para una propuesta, esa propuesta se finaliza y forma parte de la historia inmutable de la cadena de bloques.
La cadena lenta es otra cadena de bloques de prueba de trabajo donde se garantizan la consistencia y la vitalidad. Aquí, cuando decimos que algo "se ve en la cadena lenta", queremos decir que es seguro asumir (por los supuestos de finalidad de la cadena de bloques de cadena lenta) que todos los participantes de la red también lo han visto. En la práctica, esto puede significar esperar unos bloques hasta la finalidad probabilística.
Cada 100 bloques de ruta rápida (digamos), se debe publicar un hash y una notarización del bloque en la cadena lenta de manera oportuna. Esto se llama un mensaje vivo. Esto se puede lograr incluyendo la carga útil del mensaje vivo en el campo de datos de transacción de cadena lenta (por ejemplo). Tenga en cuenta que cualquiera puede publicar este mensaje vivo y los mensajes vivos no se pueden falsificar ya que requieren una notarización del bloque.Cuando no se ve un nuevo mensaje vivo en la cadena lenta después de 20 bloques de cadena lenta (digamos), la vía rápida está inactiva y comienza la recuperación. Los miembros del comité dejan de firmar nuevas propuestas. La recuperación tiene una duración de 10 bloques de cadena lenta (por ejemplo) durante los cuales los participantes publicarán un hash de bloque visto más recientemente y una certificación notarial en la cadena lenta. Después de la recuperación, el siguiente acelerador elegido en función de una ronda La política de robin (por ejemplo) se conecta y propone desde el último bloque informado durante la fase de recuperación.
Como herramienta adicional para garantizar la resistencia a la censura y la vivacidad, Thunderella define los mensajes de gritos. Los mensajes de grito son transacciones de ruta rápida que se envían a la cadena lenta. Estas transacciones se incluyen en la vía rápida mediante reglas definidas por el protocolo (en lugar del proceso de proponer-notarizar para transacciones regulares). Por lo tanto, incluso durante la recuperación, un mensaje de grito finalizado en la cadena lenta también es una transacción de ruta rápida finalizada.
Un usuario puede envolver una transacción de ruta rápida firmada válida en un mensaje de grito (en el campo de datos de una transacción de cadena lenta, digamos) y publicar en la cadena lenta. Cuando se finaliza el bloque de cadena lenta que contiene el mensaje de grito, el comité los miembros esperan que esta transacción aparezca en la vía rápida. Si no aparece, se activa el respaldo y el protocolo entra en recuperación.Durante la recuperación, cada nodo de la red extiende su cadena de bloques desde el último bloque de ruta rápida en función de los mensajes de grito que ven en la cadena lenta de acuerdo con un conjunto determinista de normas. Dado que siempre podemos confiar en el consenso de PoW sobre la cadena lenta, cada nodo llega de forma independiente a la misma ruta rápida extendida. Tras la recuperación, el nuevo acelerador debe extenderse desde la cadena de ruta rápida extendida en el paso anterior.
En la descripción completa del protocolo, Thunderella va aún más rápido al permitir múltiples propuestas pendientes (bloques que no están notarizados). Este truco se llama canalización de propuestas y lo veremos nuevamente cuando cubramos PaLa más adelante. El protocolo completo de Thunderella se describe en el artículo literario de Thunderella.
Como Thunderella aprovecha una cadena de bloques de prueba de trabajo síncrona con ½ tolerancia a fallas para la ruta lenta, el umbral de votación es ¾, lo que brinda un 50% de tolerancia a fallas para la coherencia en la ruta rápida parcialmente síncrona. Por lo general, un parcialmente asincrónico podría lograr en el mejor de los casos ⅓ tolerancia a fallas para la vida, como se explicó anteriormente. Sin embargo, al aprovechar una cadena lenta síncrona para recuperarse de un acelerador fallido, Thunderella también logra ½ tolerancia a fallas para la vida. Tenga en cuenta que la cadena lenta no necesita ser una cadena de PoW. Sin embargo, la seguridad del protocolo hereda la seguridad de la cadena subyacente. Por ejemplo, el uso de una cadena lenta de consenso clásica parcialmente síncrona dará como resultado que el protocolo sea parcialmente síncrono y tenga hasta sólo ⅓ tolerancia a fallos.
En la práctica, Thunderella proporciona confirmación después de solo 1 ronda de votaciones. Con una cadena lenta de PoW como Ethereum, la recuperación puede llevar varios minutos cuando el progreso es lento y costoso. Si la vía rápida es confiable, la recuperación rara vez es necesaria. El problema de la recuperación lenta se puede abordar utilizando una cadena de bloques de consenso clásica más rápida para la cadena lenta. Aunque originalmente estaba destinado a ser utilizado como una solución de escalamiento de capa 1 para ThunderCore, Thunderella puede ser incluso más apropiado para una cadena lateral de capa 2 con un puente de cadena cruzada apropiado entre la vía rápida y la cadena lenta. Por ejemplo, varios operadores que no son de confianza (quizás elegidos mediante el replanteo de un token ERC20) podrían usar Thunderella como una cadena lateral de Plasma y tener una confirmación de ronda de mensaje durante la operación de ruta rápida.
