Consenso en Solana

Conclusiones prácticas

• El papel de Proof-of-History (PoH) en la sincronización: PoH no es un algoritmo de consenso, sino una herramienta que el mecanismo de consenso de Solana utiliza para la sincronización. Del mismo modo, Proof-of-Stake (PoS) no es consenso, sino un mecanismo de resistencia a ataques Sybil.
• Las transacciones de voto son necesarias para el consenso: Los votos dentro de los bloques no son transacciones superfluas para aumentar artificialmente las métricas de TPS. Si los votos solo se propagaran mediante gossip (comunicación informal entre pares), podrían surgir discrepancias en la forma en que los validadores perciben el estado de la Tower (de votos).
• Solana tiene dos reglas principales de confirmación: una para seleccionar bifurcaciones a corto plazo (confirmación optimista) y otra para lograr la finalidad mediante el consenso PoS completo (finalizado/enraizado). Los clientes y usuarios pueden seguir estas reglas de confirmación para obtener las propiedades de seguridad deseadas y personalizar la UX. Esto se refleja en dos niveles de compromiso: “confirmado” y “finalizado”.
• Comprender el riesgo de censura: Los validadores y desarrolladores deben conocer los posibles ataques de censura, en los que un validador intenta alterar la secuencia de producción de bloques. También deben comprender la mecánica de estos ataques y el papel de la potencia de cómputo y el stake al ejecutarlos.
• Próximas actualizaciones del protocolo: Los validadores y desarrolladores deben prepararse activamente para los próximos cambios en el mecanismo de consenso de Solana, como la ejecución asíncrona y el slashing programático.

Introducción

A medida que aumenta la actividad en Solana, varias capas de su stack se ponen a prueba a niveles sin precedentes. Se ha escrito y debatido mucho sobre temas “candentes”, como los mercados locales de comisiones, pero el consenso en Solana se ha ignorado durante mucho tiempo. Sin embargo, el aumento de la actividad y el interés exige que la comunidad comprenda a fondo el consenso, ya que también aumentan los incentivos para realizar ataques maliciosos y las ganancias derivadas de posibles vulnerabilidades.

El consenso es uno de los aspectos más importantes de Solana que la comunidad debe comprender, ya que determina cómo miles de validadores acuerdan un orden canónico de las transacciones.

El consenso se ha estudiado durante muchos años en los sistemas distribuidos. El problema de los generales bizantinos, escrito por Lamport, Shostak y Pease, se publicó a principios de la década de 1980. Los algoritmos de consenso como RAFT se utilizan desde hace tiempo en web2. En el ámbito cripto, la mayoría de los algoritmos de consenso son implementaciones diferentes del consenso BFT, incluidos Gasper (Ethereum), Tendermint (Cosmos), MonadBFT (Monad), HotShot (Espresso) y Narwhal/Tusk (Sui). 

Este artículo no intenta demostrar formalmente el mecanismo de consenso de Solana (TowerBFT). Su objetivo es explicar a los desarrolladores y a la comunidad en general cómo funciona el consenso en Solana, ya que, hasta ahora, este tema se encuentra principalmente en la mente de los colaboradores de Solana Labs y Firedancer. También se comentan algunas ventajas, desventajas y limitaciones.

Breve introducción al consenso

El objetivo de un protocolo de consenso es lograr un acuerdo sobre las transacciones y su orden relativo dentro de un bloque. Existen dos tipos principales de protocolos de consenso para que los validadores de una red acuerden el orden canónico de las transacciones:

• Protocolos de cadena más larga: estos protocolos, como el consenso Nakamoto de Bitcoin, convierten en canónica la cadena cuya construcción ha requerido el mayor esfuerzo computacional. Aunque esto suele correlacionarse con la cadena que tiene más bloques, una descripción más precisa sería la cadena que acumula la mayor cantidad de trabajo o potencia de cómputo.
• Protocolos de tipo BFT: la mayoría de los protocolos PoS implementan alguna versión de un algoritmo de consenso BFT. Estos protocolos, como pBFT, dependen de umbrales de vitalidad y seguridad. La consistencia y la disponibilidad son dos garantías del teorema CAP, que establece que cualquier almacén de datos distribuido solo puede ofrecer dos de las siguientes tres garantías: consistencia, disponibilidad y tolerancia a particiones.

Tanto los protocolos de consenso de cadena más larga como los de tipo BFT obtienen su seguridad de sus respectivas reglas de confirmación. La seguridad, que comprende tanto la seguridad propiamente dicha como la vitalidad, se deriva de una regla de confirmación determinada y no es una propiedad de una cadena. Según la definición de Ethereum Foundation, una regla de confirmación es “un algoritmo que ejecutan los nodos y que indica si un bloque determinado está confirmado. Cuando lo está, se garantiza que el bloque nunca se reorganizará, bajo ciertos supuestos, principalmente sobre la sincronía de la red y el porcentaje de stake honesto”.

En última instancia, todo se sustenta en el consenso social, definido por las personas que escriben código de cliente para expresar qué constituye la seguridad mediante determinadas reglas de confirmación.

Proof-of-Stake agrega capas adicionales al modelo BFT y exige que los participantes aporten su propio stake. Los participantes reciben recompensas por respetar un conjunto de reglas, pero pueden sufrir slashing en casos de conducta indebida demostrada, como firmar dos veces. Esto se conoce como seguridad con rendición de cuentas y permite que el protocolo identifique y sancione a los nodos maliciosos sin causar efectos externos en los nodos honestos. No sustituye el mecanismo de seguridad fundamental de los protocolos de consenso BFT: la red sigue necesitando menos de un tercio de nodos deshonestos para evitar detenerse y menos de dos tercios para impedir la validación de transacciones falsas. El sistema basado en stake impone consecuencias a las acciones que podrían alterar o reducir la eficiencia de la red.

En una red BFT de este tipo existen dos umbrales críticos:

1. 1/3: Si los nodos deshonestos representan un tercio o más del total, la red puede “detenerse”. En este escenario, estos nodos podrían simplemente dejar de participar, lo que impediría que el resto alcanzara la supermayoría de dos tercios necesaria para el consenso. En consecuencia, la red no produce transacciones incorrectas, sino que deja de producir cualquier transacción. Una métrica popular, aunque rudimentaria, es el coeficiente de Nakamoto, que representa el número mínimo de nodos necesario para provocar una falla de vitalidad, es decir, detener la producción de bloques.
2. 2/3: Si los nodos deshonestos representan dos tercios o más del total, pueden conspirar para validar cualquier transacción que elijan. Este es el peor escenario posible: la red deja de funcionar correctamente y procesa las transacciones que dicta la supermayoría deshonesta. Si una parte adversaria controla más del 67% del stake, podría aislar un nodo honesto, como el nodo de un exchange importante (por ejemplo, Binance). Podría lograr este aislamiento conspirando con un centro de datos para restringir el tráfico de red del nodo. La entidad maliciosa podría hacer que este nodo aislado finalizara un bloque creado por ella y, al mismo tiempo, distribuir un bloque en conflicto al resto de la red. Este tipo de ataque aprovecha la perspectiva limitada del nodo aislado y puede provocar un doble gasto, ya que el resto de la red y el nodo aislado tienen visiones diferentes del estado on-chain.

Un ataque similar es posible incluso con un stake menor, superior al 33%, pero exigiría crear una partición de red en lugar de un simple aislamiento. En esta situación, el participante bizantino puede aprovechar la partición de red para manipular distintos segmentos con información contradictoria, lo que vuelve a generar el riesgo de doble gasto y otras fallas de seguridad.

Por lo general, un mayor número de nodos aumenta la dificultad para cualquier parte que intente corromper una proporción suficiente como para alcanzar estos umbrales, suponiendo que exista separación geográfica. Sin embargo, el objetivo de tener una red más grande suele entrar en conflicto con la eficiencia. Un mayor número de nodos puede ralentizar el consenso debido al aumento en las exigencias de transmisión de datos, ya que los votos tardan más en propagarse. Algunos protocolos incluso imponen un límite estricto al número máximo de nodos.

Proof-of-History (PoH)

Mientras Proof-of-Stake (PoS) garantiza el consenso en una red, Solana incorpora Proof-of-History (PoH) a su mecanismo de consenso PoS para permitir la sincronización necesaria para producir bloques de forma continua. Para lograrlo, Solana omite los slots cuyos líderes son lentos o no responden, sin esperar una ronda sincronizada de consenso. PoH no busca demostrar el momento exacto en que ocurrió un evento, sino probar la secuencia y el paso del tiempo entre eventos.

A diferencia de lo que suele creerse, Proof-of-History (PoH) no es por sí mismo un mecanismo ni un algoritmo de consenso. Aunque la implementación actual del consenso utiliza aspectos de PoH, en teoría sería posible eliminar PoH y hacer algunos cambios menores en la implementación para que el consenso en Solana siguiera funcionando.

El núcleo de PoH es un algoritmo de hash sencillo similar a una función de retardo verificable (VDF), aunque técnicamente no es una VDF. Solana lo implementa mediante una función de hash secuencial resistente a preimágenes (SHA-256) que se ejecuta continuamente y utiliza el resultado de una iteración como entrada de la siguiente. Este cálculo se ejecuta en un solo núcleo de cada validador.

Aunque la generación de la secuencia es secuencial y utiliza un único hilo, el resultado puede verificarse en paralelo. Esto permite una verificación eficiente en sistemas multinúcleo. Si bien existe un límite máximo para la velocidad de hash, las mejoras de hardware pueden ofrecer beneficios de rendimiento adicionales.

Consideremos un ejemplo con cuatro validadores de la red Solana: los validadores A, B, C y D. En este ejemplo, el calendario de líderes podría establecer la secuencia de producción de bloques A - B - C - D. El validador A comienza generando un bloque cuando llega su turno. Para ello, utiliza el mecanismo PoH, que ejecuta la función de hash SHA-256 de forma iterativa y crea una escala temporal de “ticks”. Este proceso de hash genera un registro único y verificable del tiempo transcurrido, lo que garantiza que el bloque del validador A refleje correctamente el paso del tiempo. Cuando el validador A completa su bloque, llega el turno del validador B y, después, el del validador C.

Supongamos que el validador C intenta alterar la secuencia emitiendo un bloque fuera de turno para seguir directamente al validador A y omitir al validador B. Para ocupar de forma convincente el lugar del validador B, tendría que replicar la secuencia de hashes PoH que este habría producido. Es decir, debe generar una secuencia de hashes que represente el tiempo que el validador B habría tardado en producir un bloque. Existe un máximo físico para el rendimiento de hash de un solo núcleo. Por tanto, sabemos que ha transcurrido cierta cantidad de tiempo porque una computadora solo puede generar un número máximo de hashes en un intervalo determinado.

El validador C puede intentar censurar al validador B en el calendario de líderes generando una cadena de bloques vacíos desde el final de un bloque legítimo anterior, el bloque del validador A, sin incluir ninguna transacción. Para censurar a B con éxito, C debe cumplir dos condiciones. Primero, necesita la potencia de cómputo para procesar la cadena PoH vacía. Segundo, debe distribuir rápidamente su bloque a una cantidad suficiente de nodos con stake para garantizar que lo acepten durante su propio slot asignado y así censurar a B. Este proceso es más rápido para un validador con gran peso de stake gracias a Turbine, que prioriza el flujo de información según el peso de stake del validador.

Este escenario de ataque es posible, pero la ventana para lograr censurar con éxito es limitada. Exige que el nodo atacante disponga de recursos computacionales considerables para calcular hashes SHA-256 y de una cantidad importante de stake, ya que el número de bloques que puede generar es proporcional a su stake.

Además de tener que llegar a la red más rápido que el nodo A, C también debe generar el hash a gran velocidad. Este ataque se enfoca principalmente en un escenario donde un validador designado como líder en el slot n busca censurar a validadores cuyos slots de líder son anteriores a n. El alcance de la censura que puede lograr depende de su stake, ya que su capacidad para crear slots de líder está directamente vinculada a la cantidad de stake que posee.

El mecanismo PoH también garantiza que los bloques se produzcan a un ritmo constante. Como cada validador puede verificar la secuencia PoH de manera independiente, no hace falta sincronizar el tiempo externamente. Ethereum, por ejemplo, utiliza Network Time Protocol (NTP) en cada bloque para el consenso. En Solana, cada validador verifica de manera independiente y endógena que cada bloque se haya producido en el slot correcto, sin usar un protocolo externo.

Tower BFT (el mecanismo de consenso de Solana)

Tower BFT, el mecanismo de consenso de Solana, opera después de que los shreds (bloques parciales) se propagan a otros validadores:

Como mencionamos antes, Solana ejecuta Tower BFT junto con Proof-of-History. Tower BFT es un algoritmo de consenso similar a pBFT, diseñado para aprovechar los cálculos de reloj sincronizado de Proof-of-History. Esto establece un reloj universal en toda la red y permite omitir de forma eficiente los slots asignados a líderes lentos o que no responden. Así, la red no necesita completar una ronda de consenso síncrona para cada slot y puede producir bloques de forma continua, pues los validadores no tienen que esperar a que lleguen los bloques anteriores antes de construir el siguiente.

Otra idea equivocada es que el mecanismo de consenso de Solana ya implementa el slashing programático. Aunque el slashing está previsto en la hoja de ruta, actualmente la red se detiene después de una infracción de seguridad y depende del consenso social para aplicar el slashing cuando sea necesario.

El mecanismo de consenso de Solana otorga distintos grados de influencia a los nodos. Los votos de la red no son iguales, sino que se ponderan según el stake de cada nodo, bajo los mismos principios de QoS ponderada por stake y Turbine. En igualdad de condiciones, un nodo con mayor stake influye más que uno con menor stake al determinar el consenso canónico.

Por ejemplo, en una red con cuatro nodos que poseen un total de 100 unidades de stake, la distribución y la influencia podrían ser las siguientes:

• El nodo A tiene 10 unidades de stake.
• El nodo B tiene 20 unidades de stake.
• El nodo C tiene 30 unidades de stake.
• El nodo D tiene 40 unidades de stake.

En esta configuración, la capacidad de cada grupo de nodos deshonestos varía. Un solo nodo, como el nodo D, podría detener la red aunque represente solo el 25% del número total de nodos, debido a su gran stake. Del mismo modo, una combinación como la de los nodos C y D podría aprobar transacciones incorrectas. Estos nodos representarían solo el 50% del total, pero tendrían suficiente stake para influir en el resultado.

El umbral de un tercio necesario para detener la red puede alcanzarse mediante nodos deshonestos, comprometidos o bloqueados. Sin embargo, el umbral de dos tercios para validar transacciones incorrectas exige una colusión activa y no puede alcanzarse solo bloqueando nodos honestos. Por tanto, alcanzar este segundo umbral es mucho más difícil. Requiere corromper o comprometer nodos para que participen activamente en el esquema deshonesto, en vez de limitarse a bloquear los nodos honestos.

Contexto dentro de los slots

En Solana, a los líderes de slot se les asignan cuatro slots consecutivos que duran aproximadamente 1.6 segundos en total (4 bloques x 400 ms por bloque). Los líderes se eligen al inicio de cada época (432,000 slots o ~2-3 días). El calendario de líderes se determina al azar en función del peso de stake de cada validador.

El líder debe construir y proponer un nuevo bloque para cada slot que se le asigne. No existe una separación entre proponente y constructor como en el ecosistema de Ethereum. Los demás validadores certifican la validez de un bloque determinado mediante transacciones de voto, para lo cual aplican la regla de elección de bifurcación a su propia visión local de la cabecera de la red Solana.

Los líderes deben publicar los bloques dentro de un rango determinado de ticks de PoH para que sean válidos. Todo bloque que no se publique dentro de este rango se considera omitido.

Tomemos como ejemplo el siguiente calendario de líderes con cuatro participantes (A, B, C y D), donde D intenta alterar la secuencia. Si D trata de intervenir durante el turno de C, debe crear una secuencia de ticks de PoH que omita efectivamente el bloque de C. Esto produciría una cadena con el siguiente aspecto:

A - B - [falta C] - D.

Si falta el bloque de C, un D honesto tendría que generar una secuencia PoH que cubra toda la duración del slot de C antes de iniciar el suyo. Esto haría que el bloque de D pareciera válido, ya que seguiría al bloque de B después del tiempo asignado al slot de C.

Mientras D produce la secuencia PoH correspondiente al slot de C, normalmente C transmitiría su bloque, conectado al de B mediante una secuencia PoH adecuada. Esto da lugar a dos posibles resultados:

• Si el cálculo de PoH de D no es más rápido que el de C: Cuando C complete su bloque casi al mismo tiempo que D empiece a transmitir el suyo, la red ya habrá visto el bloque de C y rechazará el de D.
• Si D calcula PoH más rápido que C: D comienza a transmitir su bloque antes de que C complete el suyo. Aun así, D tendría que ser considerablemente más rápido que C para afectar de forma significativa la secuencia. Esto es improbable, dada la alta velocidad y el límite máximo relativamente similar de las CPU que utilizan los validadores para calcular SHA-256.

En ambos casos, las probabilidades de que D sustituya a C son mínimas. Además, si el intento de D por sustituir a C fracasa, pierde la oportunidad de emitir un bloque en su propio slot. Emitir un bloque justo después de B e intentar emitir otro después de C constituye una infracción, pues se crearían dos bloques para el slot de D, y sería una conducta sujeta a slashing. Cada intento fallido provoca que D pierda su propia oportunidad de producir un bloque, por lo que es poco probable que adopte esta estrategia. 

Desde la perspectiva de la red, no es posible determinar las intenciones de D. Es difícil, si no imposible, diferenciar entre un D que simplemente no vio el bloque de C, sin intención de censurarlo, y un D que pretendía censurar a B. Por ello, la red no puede detectar ni sancionar fácilmente esta conducta.

Transacciones de voto

El mecanismo de consenso de Solana depende de las transacciones de voto para alcanzar el consenso. Estas transacciones se encuentran dentro de los bloques, pero tienen prioridad para evitar que las transacciones normales las desplacen. Actualmente, la mayoría de las transacciones de un bloque determinado son transacciones de voto:

Sin embargo, puede que esto no siempre sea así, ya que el porcentaje de transacciones de voto dentro de un bloque determinado representa la relación entre la actividad y el número de validadores que participan en el consenso. En el futuro, las transacciones de voto podrían ser minoritarias dentro de un bloque.

Las transacciones de voto son un requisito necesario para el consenso; no son transacciones superfluas destinadas a aumentar artificialmente las métricas de TPS. Si los votos solo se propagaran mediante gossip (comunicación informal entre pares), podrían surgir discrepancias en la forma en que los validadores perciben el estado de la Tower (de votos). Estas discrepancias podrían hacer que los validadores tuvieran perspectivas distintas sobre qué bifurcación tiene más probabilidades de ser la correcta. Esto podría provocar divergencias cuando los validadores tomen decisiones oportunistas basadas en información incompleta o inconsistente. La producción continua de bloques exige una votación constante, especialmente mientras los bloques anteriores siguen pendientes de confirmación. Esto requiere una visión confiable y consistente del estado de la Tower.

Al igual que las transacciones normales iniciadas por los usuarios, las transacciones de voto también deben pagar la comisión base (0.000005 SOL). La paga la identidad del validador, que debe estar en una hot wallet para firmar constantemente, mientras que la cuenta de voto se utiliza para consultar cuentas y delegar.

Cada voto, firmado por el validador, incluye la clave pública del validador y el hash del bloque por el que vota.

Cuando un validador recibe varios bloques para el mismo slot, realiza un seguimiento de todas las bifurcaciones posibles hasta determinar cuál es la “mejor”. Los validadores ejecutan localmente la función de transición de estado correspondiente, aunque esto cambiará con la ejecución asíncrona, y después votan por los nuevos bloques tras reproducirlos. Los validadores expresan su voto por una bifurcación determinada mediante transacciones de voto on-chain.

En cada transacción de voto, el validador publica votos con un periodo de bloqueo. Este bloqueo funciona como mecanismo de compromiso: vincula a los validadores con la bifurcación elegida e impone costos de oportunidad por sus decisiones. En la actualidad, el entorno de ejecución no aplica los bloqueos. Se aplican mediante consenso social, y es muy probable que las infracciones reiteradas de los bloqueos de voto se sancionen manualmente con slashing. Es probable que pronto se agregue slashing programático por infringir los periodos de bloqueo, ya que no recibir créditos de voto no supone un desincentivo suficiente.

El validador también firma un hash del bloque para cada bloque ancestro entre su voto anterior y los bloques enraizados/finalizados. Esto es necesario para detectar bloques duplicados. Si un líder enviara bloques distintos a cada nodo, cada nodo terminaría votando por un predecesor diferente para el mismo slot. Sin embargo, en una época compuesta por 65,000 slots, el tamaño de cada voto podría alcanzar hasta 2 MB en el escenario más extremo. Esto se debe a que podría requerir hashes de 32 bytes para cada uno de los 65,000 slots. Analizaremos este tema en mayor profundidad en una publicación futura.

Los validadores gestionan una “Tower de votos”, una pila secuencial de votos en la que cada voto refuerza una bifurcación y es ancestro de la bifurcación situada encima de él en la Tower. Cuando se agrega un nuevo voto a esta Tower, los bloqueos de todos los votos anteriores de la pila se duplican. Esto aumenta progresivamente el compromiso y el periodo de bloqueo de las decisiones anteriores. El propio proceso de votación se rige por varias comprobaciones: los validadores deben respetar los periodos de bloqueo de los votos anteriores; deben asegurarse de que una parte significativa de la red, normalmente dos tercios, también esté comprometida con la misma bifurcación; y necesitan una mayoría considerable, superior al 38%, de votos en bifurcaciones alternativas antes de cambiar a una nueva.

Para un bloque en el slot n, los votos ajenos al líder empiezan a aparecer on-chain desde n+1. No hay subcomités de voto: todos los validadores pueden votar por todos los bloques. Estos votos aparecen primero en bloques de otros validadores cercanos, a un salto de distancia, en el árbol de Turbine. Los votos del slot n pueden aparecer hasta el slot n+512, porque un validador puede votar por cualquier slot cuyo “hash de slot” aún sea conocido, y estos hashes se conservan durante 512 slots (gracias a Shinobi). No existe un límite superior predeterminado en un bloque concreto para el slot n. Sin embargo, los slots enraizados sobre los que se hayan construido al menos 32 bloques continuos dejarán de aceptar votos y se considerarán finalizados.

El esquema de votación presenta algunas peculiaridades que el entorno de ejecución no aplica por completo. Por ejemplo, actualmente se incentiva a los validadores a votar solo por slots “enraizados”, ignorando la punta de la cadena, y el consenso no sanciona esta conducta. Esto permite que un validador obtenga continuamente créditos de voto por bifurcaciones con una probabilidad extremadamente alta de convertirse en canónicas sin contribuir a la punta de la cadena para las operaciones reales de consenso. Esto ocurre actualmente: un validador tiene una “latencia de voto” promedio superior a 68 slots. Una función propuesta llamada Timely Vote Credits busca corregir este desajuste de incentivos.

Regla de elección de bifurcación de Solana

Al igual que Ethereum (LMD Ghost y Casper FFG), Solana tiene dos reglas de confirmación: una para seleccionar bifurcaciones a corto plazo y otra para lograr la finalidad mediante el consenso PoS completo. Esto permite que los usuarios y clientes personalicen la UX según las distintas reglas de confirmación. Se refleja en dos niveles de compromiso: “confirmado” y “finalizado”.

Los bloques “confirmados”, también conocidos como confirmación optimista, requieren que al menos 2/3 de los validadores hayan votado por un bloque concreto mediante transacciones de voto. Sería necesario aplicar slashing a ~4.6% del stake actual para que fueran posibles las infracciones de finalidad. Los bloques “finalizados” requieren votos en al menos 32 slots posteriores o una supermayoría (>2/3) de los votos. Un ataque malicioso requeriría aplicar slashing a más de 1/3 del stake. Esto tarda mucho más que los bloques “confirmados”, ya que debe esperar a que los bloques de 32 posiciones anteriores estén enraizados para lograr la finalidad completa.

Una regla de elección de bifurcación permite que la red alcance un consenso sobre la cabecera de la cadena. La implementación de Solana Labs gestiona principalmente la elección de bifurcación mediante un archivo de Rust de ~4600 líneas llamado acertadamente heaviest_subtree_fork_choice.rs. Este archivo proporciona la lógica necesaria para que los validadores determinen qué bifurcación tiene más probabilidades de convertirse en canónica. En una publicación futura analizaremos el código con más detalle, pero, a grandes rasgos, la mecánica de elección de bifurcación funciona así:

1. Los votos se agregan con add_votes():

Esto recorre los nuevos votos, resta el stake de las cuentas de voto de los slots anteriores cuando es necesario y agrega el stake a los nuevos slots votados.

2. Se llama a generate_update_operations() para crear un lote de operaciones de actualización de bifurcaciones:

Esto hace lo siguiente:

• Resta stake de la bifurcación anterior
• Agrega stake a la nueva bifurcación
• Acumula el stake de cada bifurcación hasta la raíz

3. process_update_operations():

• Llama a mark_fork_valid()/invalid() cuando es necesario
• Llama a aggregate_slot() en cada bifurcación para actualizar sus pesos
• Llama a add_slot_stake()/subtract_slot_stake() para actualizar los stakes

4. aggregate_slot():

• Suma el stake de todos los slots secundarios
• Busca la bifurcación secundaria de mayor peso según el peso de stake
• Busca la bifurcación secundaria más profunda según su altura
• Propaga estos valores hacia arriba para encontrar la bifurcación de mayor peso y la más profunda desde este slot

5. select_forks():

• Devuelve la bifurcación de mayor peso general para producir bloques
• Devuelve la bifurcación de mayor peso que desciende del último voto

El stake se suma o resta según los votos, la agregación recalcula los pesos de abajo hacia arriba para cada bifurcación y la raíz con el subárbol de mayor peso se elige como la mejor bifurcación sobre la cual construir y votar.

Probabilidad de inclusión

La probabilidad de inclusión de una transacción cambia a lo largo de su ciclo de vida después de cumplir los requisitos necesarios de las respectivas reglas de confirmación.

Aunque los slots pueden “omitirse”, por ejemplo, cuando el líder está desconectado, esa transacción puede incluirse en bloques futuros o no incluirse en absoluto.

Los slots que se muestran aquí son aproximaciones, pero buscan dar al lector una idea de cuándo suelen acumularse los votos. Además, el proceso es único para cada bloque: los bloques pueden alcanzar los niveles de confirmación “confirmado” o “finalizado” después de distintos periodos. El riesgo de reversión disminuye de forma monótona durante todo el ciclo de vida de la transacción. Incluso después de que un bloque se haya finalizado (enraizado), en teoría podría bifurcarse mediante consenso social y eliminarse de la cadena “canónica”.

Áreas de investigación futura y conclusión

Esta publicación ha destacado el funcionamiento interno de Tower BFT, el mecanismo de consenso de Solana, y otros mecanismos relevantes. Exploramos el papel de Proof-of-History, las transacciones de voto y la elección de bifurcaciones en el contexto de Solana para crear una bifurcación canónica que determine el orden de las transacciones.

Existen muchas otras líneas de investigación y formalización en torno a estos mecanismos que aún deben explorarse, como las siguientes:

• Los investigadores de Ethereum han cuantificado el valor de participar en Timing Games, donde los productores de bloques esperan hasta el final del slot para enviar sus bloques. ¿Cómo se ven cuantitativamente estos juegos en Solana y ocurren hoy?
• La ejecución asíncrona está prevista en la hoja de ruta como el principal cambio del protocolo para 2024. ¿Cuáles son los posibles vectores de ataque y las consideraciones de seguridad relevantes para los nodos que se limitan a votar por bifurcaciones existentes en lugar de calcular localmente las transiciones de estado?
• Actualmente, una minoría significativa de validadores (<20%) ejecuta modificaciones del cliente de Solana Labs o Jito-Solana. ¿Qué umbrales modifican que no estén regulados por el entorno de ejecución ni por las reglas de confirmación?
• Implementar el slashing programático. Actualmente, fuera del consenso social, existen pocos incentivos económicos para evitar ejecutar estrategias de trading muy rentables sin sufrir slashing.
• ¿Cómo es el rendimiento del mecanismo de consenso de Solana cuando se ejecutan dos clientes completamente distintos, aunque intenten regirse por las mismas reglas de confirmación?
• ¿Qué beneficios de rendimiento y reducción de estado se esperan de los subcomités de voto?
• ¿Cuáles son los posibles vectores de ataque al reiniciar desde un slot confirmado de forma optimista en vez de uno finalizado? ¿Cómo deberían abordar las soluciones off-chain de terceros, como los exchanges, el uso de la confirmación optimista o la finalidad completa?
• ¿Deben utilizarse los fondos sujetos a slashing como seguro para las transacciones incluidas en infracciones de seguridad? ¿Cuáles serían la mecánica y los incentivos de un fondo de seguros denominado en SOL?

En esta publicación, exploramos algunos de los mecanismos y umbrales que Solana implementa en su mecanismo de consenso y cómo se relacionan con la producción habitual de bloques por parte de los líderes dentro de determinados slots. El reciente aumento de actividad en Solana somete estos mecanismos a pruebas reales de vitalidad y seguridad, mientras aumentan los incentivos para realizar ataques maliciosos.

Gracias a anoushk (Tinydancer), dubbel06 (Overclock), Prithvi (Helius), Mert (Helius) y Jarry (Ellipsis Labs) por sus conversaciones y comentarios.