¿Qué es el protocolo de consenso HotStuff y cómo funciona?

¿Qué es el protocolo de consenso HotStuff?

HotStuff es un protocolo de consenso BFT que permite que un grupo fijo de validadores acuerde un único orden definitivo de transacciones u otras órdenes, incluso si una parte de ese grupo comete errores o envía deliberadamente mensajes engañosos.

BFT significa Byzantine Fault Tolerance. Esto significa que el protocolo es resistente a validadores que se caen, no responden, mienten o envían mensajes diferentes a participantes distintos. HotStuff garantiza que los validadores que funcionan correctamente sigan, aun así, la misma versión de la blockchain o del registro compartido.

HotStuff funciona con un grupo de validadores conocido. Por tanto, el protocolo no determina por sí mismo quién puede ser validador, cómo está configurado el staking o cómo un criptoactivo de red abierto selecciona participantes. Ese tipo de reglas quedan fuera de HotStuff. El protocolo se centra en la pregunta: ¿cómo alcanza esta agrupación de validadores un acuerdo de forma segura?

El modelo original parte de un grupo de validadores con n = 3f + 1 participantes. Aquí, n es el número total de validadores y f es el número máximo de validadores que pueden comportarse de forma incorrecta o maliciosa. En términos simples: mientras menos de un tercio de los validadores sea poco fiable, el sistema seguirá funcionando correctamente. Con 4 validadores, como máximo 1 puede ser poco fiable. Los otros 3 validadores aún pueden tomar conjuntamente una decisión segura. Con 7 validadores, como máximo 2 validadores pueden ser poco fiables. Para una decisión válida, al menos 5 validadores deben estar de acuerdo. Para ello, HotStuff utiliza un quorum certificate, a menudo abreviado como QC. Un QC es una prueba criptográfica compacta de que suficientes validadores han votado a favor de la misma propuesta. Un quórum es la cantidad mínima de apoyo necesaria para tomar una decisión. En el modelo original, ese quórum consiste en n − f, es decir, 2f + 1 votos.

Con 4 validadores, eso son 3 votos. Con 7 validadores, eso son 5 votos. Este umbral elevado evita que un grupo pequeño de validadores poco fiables pueda, por sí solo, lograr la aprobación de un bloque en conflicto.

HotStuff está diseñado para una red parcialmente síncrona. Esto significa que los mensajes pueden sufrir retrasos fuertes de forma temporal, pero que la red debe volver a estabilizarse finalmente lo suficiente como para entregar los mensajes a tiempo. La seguridad se mantiene, incluso durante grandes retrasos. El progreso, como la finalización de nuevos bloques, solo se garantiza cuando la red es lo suficientemente estable.

Puntos clave

• HotStuff es un protocolo de consenso BFT para un grupo fijo de validadores.
• Los validadores establecen conjuntamente un orden de transacciones u órdenes.
• Un quorum certificate prueba criptográficamente que suficientes validadores apoyan la misma propuesta.
• El modelo original tolera menos de un tercio de validadores bizantinos.
• HotStuff mantiene la seguridad ante retrasos de red, pero necesita una red estable para el progreso.

¿Cómo funciona el protocolo de consenso HotStuff?

HotStuff funciona en rondas sucesivas en las que un líder temporal coordina una propuesta y los validadores votan sobre ella. A una ronda así se la denomina view. El líder no es un productor de bloques permanente, sino que solo tiene un papel de coordinación durante esa view específica.

En la variante original Basic HotStuff se requieren tres fases de votación antes de que una decisión sea definitiva: prepare, pre-commit y commit. Cada fase aporta a los validadores una seguridad adicional de que no podrá finalizarse una propuesta en conflicto.

Una forma práctica posterior, Chained HotStuff, permite que estas fases se solapen a lo largo de bloques consecutivos. De este modo, un nuevo bloque puede aportar simultáneamente prueba del progreso de bloques anteriores. Las reglas básicas sobre votación, quórums y seguridad siguen siendo las mismas.

¿Qué papel desempeñan los validadores y el líder?

Los validadores comprueban si la propuesta del líder es segura antes de votar. Entre otras cosas, revisan si la propuesta se construye sobre los bloques previos correctos y si encaja en las reglas de seguridad del protocolo. Si es así, envían un voto firmado digitalmente al líder.

El líder recopila los votos. En cuanto el líder tiene suficientes votos, los agrupa en un único QC. En lugar de reenviar constantemente todos los votos individuales, el líder puede difundir una prueba compacta que muestra que un quórum ha aprobado.

Los validadores también utilizan un lock, es decir, un bloqueo. Un lock es una regla que evita que un validador apoye más tarde, sin más, una rama en conflicto. Por lo general, un validador solo vota por una propuesta que amplía su rama bloqueada. Se permite una excepción cuando un QC de una view superior demuestra, según las reglas de seguridad, que un siguiente paso es seguro.

Cuando una view no progresa, por ejemplo porque el líder está desconectado, los validadores pasan a una nueva view. Entonces envían un mensaje new-view al siguiente líder. En él se incluye su prepareQC más alto conocido, es decir, la prueba más sólida que conocen en ese momento.

El nuevo líder elige el QC más alto recibido como highQC. Este es el punto de partida para una nueva propuesta segura. Una rotación conocida de antemano puede determinar quién es el siguiente líder. Un pacemaker, un mecanismo con time-outs, garantiza que los validadores no esperen indefinidamente a un líder que no funciona.

¿Cómo se desarrolla el proceso de consenso?

En Basic HotStuff, la toma de decisiones avanza paso a paso a través de tres fases de votación. La siguiente descripción muestra cómo una propuesta pasa de inicio a decisión definitiva.

1. El nuevo líder recopila información. En un cambio de view, el nuevo líder recibe mensajes new-view de un quórum de validadores. El líder elige el QC más alto que aparece en ellos. Esto evita que el líder proponga algo que entre en conflicto con un bloque anterior continuado de forma segura.

2. El líder presenta una propuesta. El líder construye un nuevo bloque sobre la rama justificada por el highQC y lo envía a todos los validadores. Por tanto, la propuesta también contiene la prueba de por qué esta es la ruta de continuación segura.

3. Los validadores verifican y votan en la fase prepare. Cada validador comprueba si el bloque cumple las reglas de seguridad. Si la propuesta las cumple, el validador envía un voto prepare de vuelta al líder.

4. El líder forma pruebas para prepare y pre-commit. Tras 2f + 1 votos prepare, el líder crea un prepareQC y lo difunde para la fase pre-commit. Después, los validadores vuelven a recopilar votos. Con otros 2f + 1 votos, el líder forma un precommitQC.

5. Los validadores bloquean y hacen commit de la propuesta. Los validadores fijan un lock basándose en el precommitQC y votan en la fase commit. A continuación, el líder agrupa 2f + 1 votos commit en un commitQC. Un mensaje decide posterior hace que la propuesta sea ejecutable y definitiva.

Ejemplo: Suponga que un grupo consta de 4 validadores. Un líder propone un bloque. Al menos 3 validadores deben votar en cada fase requerida antes de que el líder pueda formar un QC. Por lo tanto, un validador defectuoso no puede obligar al proceso a hacer definitivo un bloque diferente.

Chained HotStuff hace este método más eficiente al combinar fases de distintos bloques. Según la three-chain commit rule, el bloque más antiguo de una serie se vuelve definitivo cuando tres bloques consecutivos están vinculados entre sí mediante QCs válidos conforme a las reglas del protocolo. Esa cadena aporta la prueba de commit para el bloque más antiguo relevante.

¿Cómo gestiona HotStuff los fallos bizantinos?

HotStuff limita el daño de los fallos bizantinos combinando un umbral de voto alto, votos firmados, locks y reglas claras para los cambios de view. Un validador bizantino es un validador que se comporta de forma impredecible o maliciosa, por ejemplo, mintiendo, no respondiendo o enviando propuestas diferentes a distintos validadores.

El límite de fallos es inferior a un tercio de los validadores en un grupo no ponderado. Con n = 3f + 1 participantes, como máximo f validadores pueden ser bizantinos. Un QC requiere 2f + 1 votos, lo que equivale a n − f.

La consecuencia importante es que dos quórums siempre se superponen. Con 7 validadores, por ejemplo, se necesitan 5 votos para un QC. Dos grupos de 5 votos deben tener como mínimo 3 validadores en común. Dado que como máximo 2 validadores pueden ser bizantinos, en esa superposición siempre hay al menos un validador correcto.

Un validador correcto no vota dos veces por propuestas en conflicto en la misma fase y view. Por ello, no pueden surgir dos QCs en conflicto para la misma fase y view. Además, los locks y la regla safeNode, la comprobación de si una nueva propuesta se apoya de forma segura en pruebas conocidas, garantizan que los validadores no cambien posteriormente sin más a una rama en conflicto.

Esto protege la safety. Aquí, safety significa que dos bloques en conflicto no pueden hacerse definitivos ambos por validadores que funcionan correctamente. En caso de incertidumbre, la red prefiere esperar antes que hacer definitivas dos historias distintas.

La liveness trata del progreso: la capacidad de hacer definitivos nuevos bloques. HotStuff no promete ese progreso durante una partición de red prolongada o retrasos grandes y persistentes. En cuanto la red vuelve a ser lo suficientemente estable y un líder correcto dirige la misma view durante el tiempo necesario, los validadores pueden formar de nuevo quórums y continuar.

En variantes de proof-of-stake, este umbral suele expresarse en peso de voto en lugar de únicamente en número de validadores. Entonces, no todos los validadores cuentan por igual. Las garantías de seguridad y progreso solo se aplican mientras menos de un tercio del peso de voto relevante sea bizantino.

¿Para qué se utiliza el protocolo de consenso HotStuff?

HotStuff se utiliza para permitir que un grupo de servidores o validadores fije un único orden definitivo de órdenes. Esto se denomina state machine replication: varios ordenadores ejecutan las mismas órdenes en el mismo orden, de modo que mantengan el mismo resultado y el mismo registro compartido.

En una blockchain, esa tarea puede consistir en ordenar y finalizar bloques con transacciones. Después de que los validadores hayan fijado el orden, otras partes de la red pueden ejecutar las transacciones y actualizar el ledger. Por tanto, HotStuff determina principalmente el orden y la finalidad de las decisiones.

DiemBFT fue una familia de consenso basada en HotStuff para la histórica blockchain Diem. Esta familia de protocolos ordenaba y finalizaba transacciones dentro de un grupo de validadores configurable.

Aptos utiliza AptosBFT, un protocolo de consenso BFT basado en Jolteon. El protocolo funciona con poder de voto ponderado por stake y puede aplicar selección de líder basada en reputación, en la que el comportamiento y el rendimiento de los validadores influyen en la elección de líderes. En ese contexto, el peso de voto de los validadores puede diferir en función del stake.

Flow utiliza la familia de consenso HotStuff y migró en enero de 2023 a Jolteon. Jolteon es una variante optimizada de HotStuff. Por tanto, estos sistemas no necesariamente usan la especificación original de HotStuff exactamente tal como fue diseñada; detalles como la selección de líderes y el procesamiento pueden diferir.

¿Cuáles son las ventajas de HotStuff?

HotStuff tiene como ventaja importante que organiza la comunicación entre validadores de forma más eficiente que los protocolos en los que todos deben comunicarse constantemente con todos los demás.

• Pruebas compactas: El líder agrupa los votos de los validadores con threshold signatures en un único QC. Las threshold signatures son firmas digitales agregadas que prueban que suficientes validadores han votado. Por ello, un validador no necesita recibir cada vez todos los votos individuales para verificar el quórum.

• Comunicación lineal con un líder correcto: En el modelo original, la carga de comunicación y autenticación por líder correcto crece aproximadamente en proporción al número de validadores, en lugar de crecer mucho más rápido. Esto no indica automáticamente cuántas transacciones puede procesar una blockchain completa, porque la ejecución, el almacenamiento, el hardware y la difusión de transacciones también pueden ser limitantes.

• Cambios de líder más eficientes: HotStuff está diseñado para requerir menos comunicación que PBFT incluso cuando se produce un fallo del líder. Esto es importante cuando un líder falla o no difunde una propuesta utilizable.

• Pipelining en Chained HotStuff: Las nuevas propuestas pueden contribuir a finalizar bloques anteriores. Esto evita que la red tenga que completar cada fase por separado antes de empezar con la siguiente propuesta.

• Finalidad determinista: Un bloque comprometido (committed) es definitivo dentro de las suposiciones de seguridad. La finalidad determinista significa que los validadores que funcionan correctamente no pueden aceptar más adelante también un bloque en conflicto como definitivo.

Además, HotStuff tiene optimistic responsiveness. Después de que la red se haya estabilizado, un líder correcto no necesita esperar siempre a un retraso máximo de red preestablecido si los mensajes necesarios ya se han recibido antes. Esto puede mejorar el progreso en condiciones de red favorables.

¿Cuáles son las limitaciones de HotStuff?

HotStuff no ofrece protección ilimitada ni progreso garantizado en todas las circunstancias. Su funcionamiento depende de suposiciones claras sobre los validadores, la comunicación de red y la implantación elegida.

• Límites de tolerancia a fallos: El análisis formal de seguridad se aplica cuando menos de un tercio de los validadores o del peso de voto es bizantino. Con una fracción no fiable mayor, las garantías de seguridad y progreso quedan fuera del modelo.

• Sin progreso en una partición persistente: La safety se mantiene con retrasos de red ilimitados, pero HotStuff no hace definitivos nuevos bloques de forma garantizada mientras la red permanezca dividida o inestable durante un periodo prolongado.

• Dependencia del líder: Un líder deficiente, caído o inalcanzable puede hacer que una view falle. El pacemaker y la rotación de líderes ayudan a que la red se recupere con el tiempo cuando vuelve a cumplirse la suposición de sincronía, pero primero provocan retrasos adicionales.

• Grupo fijo de validadores como punto de partida: El protocolo original parte de un grupo de validadores conocido y autenticado y de threshold signatures. HotStuff no determina por sí mismo cómo una red abierta elige validadores, distribuye stake o sanciona conductas económicas indebidas.

• Varias fases para la finalidad: Basic HotStuff necesita tres fases de votación antes de que una propuesta sea definitiva. Chained HotStuff incrementa el rendimiento mediante pipelining, pero el tiempo hasta la finalidad de los primeros bloques y el comportamiento en cambios de líder siguen dependiendo de los retrasos de red, los time-outs y la implantación.

Por tanto, el líder reduce la cantidad de comunicación entre pares, pero también se convierte en un punto de coordinación temporal importante. Ese líder debe recopilar a tiempo los votos de quórum y difundir nuevas pruebas.

¿Cómo se compara HotStuff con otros protocolos de consenso?

HotStuff pertenece a la familia de protocolos BFT basados en líder, pero difiere en cómo organiza la votación, los quórums y los cambios de líder. No existe una jerarquía directa: los protocolos toman decisiones diferentes sobre grupos de validadores, condiciones de red y finalidad.

En comparación con PBFT, HotStuff está diseñado para reducir la comunicación durante el progreso normal y en un cambio de view. En la comparación original, la complejidad de autenticadores de HotStuff crece de forma lineal con el número de validadores tanto con un líder correcto como con un fallo del líder. En PBFT, esa carga crece más rápido en la misma comparación. La complejidad de autenticadores se refiere específicamente a la cantidad de información de autenticación que debe procesarse dentro del protocolo, no directamente a transacciones por segundo ni a la latencia del usuario.

Tendermint y Casper comparten con HotStuff el enfoque BFT con líderes temporales, quórums y finalidad. En la comparación original, las variantes de Tendermint y Casper de entonces tienen una carga de comunicación más alta. Las optimizaciones técnicas, como las threshold signatures, pueden cambiar esos costes en implantaciones específicas.

HotStuff difiere claramente del consenso de Nakamoto, como Bitcoin. HotStuff funciona con un grupo de validadores conocido y puede finalizar de manera determinista decisiones comprometidas dentro del umbral de fallos. Bitcoin utiliza un modelo permissionless de proof-of-work en el que los participantes pueden unirse libremente y la finalidad es probabilística. Esto significa que la probabilidad de reversión disminuye a medida que se añaden más bloques, en lugar de que un momento único otorgue finalidad absoluta dentro de las reglas del protocolo.

En comparación con los protocolos BFT completamente asíncronos, HotStuff elige la sincronía parcial. Gracias a ello, el protocolo puede avanzar de forma receptiva una vez que la red se estabiliza, pero no promete liveness durante una partición de red persistente.

Variantes posteriores se basan en las ideas de HotStuff. DiemBFTv4 adapta el enfoque con un steady-state commit en dos pasos, mientras que Flow utiliza Jolteon como variante optimizada de HotStuff. Estos derivados pueden tener propiedades distintas de las del protocolo original.

Reflexión final

HotStuff es un protocolo de consenso BFT que ayuda a un grupo fijo de validadores a fijar de forma segura un único orden de transacciones u órdenes. El líder temporal recopila votos, mientras que los quorum certificates demuestran que suficientes validadores han verificado y respaldado la misma propuesta.

La combinación de umbrales de voto altos, firmas digitales, locks y cambios de view evita que un grupo pequeño de validadores bizantinos pueda hacer definitivos dos bloques en conflicto. HotStuff sigue siendo seguro durante grandes retrasos de red, pero solo puede garantizar progreso cuando la red vuelve a ser lo suficientemente estable y un líder correcto permanece activo.

La agregación eficiente de votos y la posibilidad de pipelining convierten a HotStuff en una base importante para variantes BFT modernas. Al mismo tiempo, sigue siendo esencial comprender que HotStuff no es un modelo de consenso completamente abierto ni un sistema económico: la selección de validadores, el stake y los incentivos se gestionan por la blockchain o la implantación que lo rodea.