Consenso en Profundidad
El consenso de Solana es el proceso que convierte un flujo de bloques producidos por el líder en una única historia en la que sus clientes pueden confiar con diferentes niveles de certeza.
//
Busca en todas las páginas de la documentación
El consenso de Solana es el proceso que convierte un flujo de bloques producidos por el líder en una única historia en la que sus clientes pueden confiar con diferentes niveles de certeza.
Los desarrolladores rara vez implementan algoritmos BFT, pero eligen niveles de compromiso, interpretan bifurcaciones y envían UX que debe sobrevivir a raras reorganizaciones y a la evolución del software del validador.
Esta página es el paraguas para esa vista de desarrollador: TowerBFT y Proof of History (PoH) históricamente, cuentas de votación y niveles de confirmación en RPC, y Alpenglow (Votor + Rotor) como ruta de actualización, sin tratar las piezas del roadmap como hechos del protocolo completamente activos.
procesado, confirmado y finalizado, mientras que los validadores producen y votan bloques ordenados en ranuras.El consenso responde a una pregunta práctica: ¿qué secuencia de ranuras es la cadena que su aplicación debe tratar como real?
Una ranura (slot) es una unidad de tiempo del líder en la que un validador programado puede producir un bloque.
Los líderes rotan según un horario; las transacciones se reenvían hacia los próximos líderes y se ordenan en bloques que otros validadores reciben y ejecutan.
Las bifurcaciones (forks) aparecen cuando la red tiene temporalmente más de un historial candidato, después de particiones, fallos del líder o bloques competidores.
Consenso no significa que todos los nodos vean siempre la misma punta instantáneamente; significa que las reglas ponderadas por participación eventualmente seleccionan una historia y hacen que abandonarla sea progresivamente más costoso.
Históricamente, el comportamiento del consenso de la red principal que los desarrolladores aprendieron en la era Agave se describe como TowerBFT trabajando con Proof of History.
PoH es una construcción de retraso/ordenación verificable: un reloj criptográfico que ayuda a los validadores a acordar el orden de los eventos sin esperar a que cada par difunda las marcas de tiempo del reloj de pared.
PoH no es consenso por sí solo; es la columna vertebral de ordenación que hace que la programación y la reproducción del líder de alto rendimiento sean eficientes.
TowerBFT es la capa BFT basada en votos: los validadores emiten votos sobre bifurcaciones, acumulan bloqueos y prefieren la torre ponderada por participación más pesada que respeta esos bloqueos.
A medida que los votos se apilan en una bifurcación, esa bifurcación se vuelve más difícil de cambiar; la historia para el desarrollador detrás de una confirmación más profunda.
Las cuentas de votación (vote accounts) registran la identidad de votación de un validador y su estado de voto reciente.
La participación delegada pondera los votos; los clientes observan el progreso agregado del voto como compromiso, no como una llamada separada a la API de programas en medio de la instrucción.
Los programas todavía se ejecutan dentro de Sealevel contra las cuentas listadas; el consenso decide qué bloques de resultados ejecutados son duraderos en el ledger que está leyendo.
El compromiso (commitment) es la compresión de todo lo anterior para el cliente en tres niveles comunes de RPC:
| Compromiso | Significado para el desarrollador (intuición de la era TowerBFT) | Postura de riesgo |
|---|---|---|
processed | Visto / ejecutado en un nodo en la punta actual; poco peso de voto todavía | Solo optimista |
confirmed | La supermayoría de la participación ha votado por un bloque que contiene la tx (clase de confirmación optimista) | Predeterminado para muchas acciones de UX |
finalized | El bloque está enraizado / bloqueado lo suficiente como para tratarlo como prácticamente irreversible en condiciones normales | Liquidaciones, puentes, efectos secundarios irreversibles |
Los umbrales y tiempos exactos pueden cambiar con el software y las condiciones del clúster; el significado del producto de la escalera se mantiene: optimista, fuertemente votado, enraizado.
Alpenglow es la ruta de rediseño del consenso de Solana, no una L2 separada ni un nuevo modelo de cuentas.
El trabajo de diseño y SIMD asocia dos piezas con nombre: Votor (votación / finalidad) y Rotor (propagación de bloques), dirigidos a un tiempo de finalidad mucho menor (comúnmente discutido en la clase de ~100-150 ms en buenas condiciones).
Trate Alpenglow como infraestructura en evolución: siga la activación de funciones, los clústeres de prueba y las notas de la versión de Agave en lugar de asumir que cada afirmación de diseño ya es un comportamiento universal de la red principal en cada RPC que golpea hoy.
De extremo a extremo, una transacción de usuario viaja por el consenso de la siguiente manera.
El cliente construye + firma la tx --> RPC acepta la presentación
|
v
Reenviado hacia el(los) líder(es) próximo(s)
|
v
El líder ordena las txs en un bloque para una ranura
(históricamente asistido por la ordenación PoH)
|
v
El bloque se propaga a otros validadores
(históricamente propagación Turbine; Rotor es el propagador en dirección Alpenglow)
|
v
Los validadores ejecutan / reproducen y emiten votos
(históricamente torres de votación TowerBFT + bloqueos;
Votor es el diseño de votación/finalidad en dirección Alpenglow)
|
v
El compromiso se profundiza para las txs de esa ranura:
processed -> confirmed -> finalized
|
v
El cliente consulta getSignatureStatuses / se suscribe
hasta que se alcance el compromiso elegidoLa producción del líder crea un historial candidato; sin votos, una punta procesada aún puede perder una carrera de bifurcaciones.
La propagación determina la rapidez con la que el resto de la participación puede ver un bloque para votar sobre él; una propagación lenta o con pérdidas extiende las colas de confirmación y aumenta el riesgo de orfandad bajo estrés.
La votación está ponderada por participación: un voto de supermayoría convierte "mi RPC lo vio" en "el clúster está comprometiendo participación en esta bifurcación".
En el marco de TowerBFT, los votos repetidos aumentan los bloqueos que penalizan el cambio casual de bifurcación, por lo que la finalidad se gana durante ranuras sucesivas en lugar de declararse mediante un único temporizador de reloj de pared en su aplicación.
Las cuentas de votación importan más para los operadores y los mercados de participación que para los autores de instrucciones de dapp ordinarias, pero explican los créditos de votación, los morosos y la concentración de participación en los exploradores.
Las cuentas de votación no saludables o la participación morosa cambian la calidad de la confirmación (cuánta participación real está votando), no el nombre del enumerador de compromiso en @solana/kit.
El compromiso del cliente es donde los desarrolladores toman la decisión irreversible del producto.
Esperar solo hasta que sendTransaction devuelva una firma no prueba casi nada sobre la durabilidad; la firma es un identificador para el seguimiento del estado.
Patrones de política típicos:
processed): mostrar estado "enviado" o especulativo; mantener una ruta de reversión fácil si la firma nunca se confirma.confirmed): saldos, acuñaciones, la mayoría de las actualizaciones dentro de la aplicación donde una bifurcación rara es aceptable si se reconcilia.finalized): salidas, acuñaciones/quemas de puentes, liberaciones de custodia, cualquier cosa que no pueda reenviar fuera de la cadena.La intención de diseño de Alpenglow es comprimir el tiempo entre esos peldaños, especialmente la finalidad sólida, rediseñando las rondas de votación (Votor) y cómo se distribuyen los bloques (Rotor).
Lo que no debería cambiar en su cableado: cuentas, propiedad del programa, atomicidad de la transacción y compromiso emparejado con el riesgo.
Lo que puede cambiar operativamente: latencias medianas y de cola para confirmed / finalized, patrones de tráfico de votos y qué características del validador están activas en una versión de clúster determinada.
Durante las ventanas de implementación, fije las versiones de Agave/RPC en los runbooks y reevalúe la latencia de confirmación en lugar de codificar valores de tiempo de espera de publicaciones antiguas.
El compromiso no es una configuración de vanidad; es un control de riesgo.
| Nivel | Latencia (cualitativa) | Exposición a reorganización | Bueno para | Malo para |
|---|---|---|---|---|
processed | Más bajo | El más alto de los tres | Prefetch, spinners optimistas, lecturas no críticas | Pagos, deducción de inventario, liquidación legal |
confirmed | Medio | Bajo pero no cero en casos extremos | La mayoría de las UX de "éxito" de dapp, estado del juego, intercambios minoristas | Acciones fuera de la cadena irrevocables de alto valor sin reconciliación |
finalized | Más alto (históricamente profundidad enraizada de varias ranuras) | El más bajo bajo supuestos de seguridad normales | Puentes, retiros, exportaciones de cumplimiento, transferencia entre sistemas | Juegos de latencia ultra baja que pueden reconciliarse más tarde |
A medida que los componentes de Alpenglow se activan y maduran, reevalúe las esperas de reloj de pared para finalized; no elimine el parámetro de compromiso porque el marketing dijo "finalidad de subsegundo".
Mantenga el razonamiento actual de la red principal separado de la ruta de actualización.
| Aspecto | TowerBFT + PoH (modelo histórico / de larga data para desarrolladores) | Dirección Alpenglow (Votor + Rotor) |
|---|---|---|
| Columna vertebral de ordenación | Ordenación de ranuras/bloques asistida por PoH | El rediseño moderniza el consenso en torno a la finalidad rápida (no asuma que PoH desaparece de todas las herramientas de la noche a la mañana) |
| Votación / finalidad | Votos de torre, bloqueos, raíz sobre ranuras sucesivas | Votor: rondas de votación/finalidad simplificadas dirigidas a la clase de finalidad de ~100-150 ms en buenas condiciones |
| Propagación | Propagación de fragmentos estilo Turbine | Rotor: propagación rediseñada para una entrega de bloques más rápida y eficiente |
| Enumeraciones RPC del cliente | processed / confirmed / finalized | Se espera la misma escalera de producto; los tiempos pueden cambiar |
| Modelo de cuentas de aplicación | Sin cambios | Sin cambios |
| Medición de CU de programas | Independiente del algoritmo de consenso | Sigue siendo independiente |
| Acción del desarrollador | Elegir compromiso; manejar hashes de bloque expirados; reintentar | Lo mismo, más reevaluar tiempos de espera por clúster/versión |
Su transacción todavía nombra cuentas, paga tarifas y se ejecuta atómicamente.
Las restricciones de Anchor 0.32.1, las semillas de PDA y las reglas de CPI no se vuelven "conscientes del consenso" solo porque la finalidad se acelera.
@solana/kit 7.0.0 todavía habla de compromiso en lecturas RPC y estado de firma; migre las suposiciones de latencia, no toda la arquitectura de la aplicación, a medida que avanza el software de consenso.
A los validadores les importa la preparación de votos, la salud de la participación y las puertas de funciones; a los proveedores de RPC les importa la rapidez con la que los nodos observan la supermayoría y la raíz.
Para la infraestructura crítica de liquidación, siga el estado del clúster, las notas de Agave y la activación de SIMD, no solo los anuncios sociales.
Las herramientas locales (Surfpool, LiteSVM) son fuertes para la lógica del programa y débiles para los SLO de finalidad; mida la finalidad en RPC de clúster real.
Codifique el compromiso por clase de acción en un módulo de política en lugar de dispersar cadenas mágicas.
Registre la firma, el compromiso alcanzado, la ranura y la hora de reloj para poder detectar regresiones después de las actualizaciones.
Trate "confirmado en RPC A, faltante en RPC B" como un desfase de bifurcación o indexación, no como fraude del usuario, hasta que finalized (o su política equivalente) esté de acuerdo.
confirmed y finalized son intercambiables si la UX es lo suficientemente rápida." Codifican un riesgo de reorganización diferente; la velocidad de la UX no borra la diferencia para puentes y retiros.Acuerdo ponderado por participación sobre qué bifurcación de ranuras producidas por el líder es canónica, expuesta a las aplicaciones principalmente como niveles de compromiso en RPC.
PoH proporciona una estructura de tiempo/ordenación verificable para ranuras y entradas; TowerBFT recopila votos ponderados por participación y bloqueos para que la red converja en una bifurcación y la enraíce con el tiempo.
Una cuenta en cadena vinculada a la identidad de votación de un validador y su estado de voto; la participación delegada pondera los votos de ese validador en el consenso.
Los bloqueos son la razón por la que la finalidad se profundiza a través de votos sucesivos: cambiar de bifurcación se vuelve costoso, lo que sustenta por qué finalized es más seguro que processed para acciones irreversibles.
processed es la visibilidad temprana de ejecución local del nodo; confirmed refleja el progreso del voto de supermayoría; finalized refleja un historial enraizado / profundamente bloqueado adecuado para efectos irreversibles.
Muchas acciones de producto usan confirmed para una UX receptiva; use finalized antes de efectos externos irreversibles; trate processed como solo optimista.
La ruta de actualización del consenso diseñada para modernizar la votación y la propagación para una finalidad mucho más rápida, discutida como Votor (votación/finalidad) más Rotor (propagación), sin reemplazar el modelo de programación de cuentas/transacciones.
No asuma una finalización universal de la red principal solo por los blogs de diseño; trate los componentes como escalonados y limitados por versión, y verifique contra las notas de la versión del clúster actual, el estado de las funciones y la versión de Agave de su proveedor de RPC (esta página fija Agave 4.1.1 como la pila de referencia).
Votor es la pieza del protocolo de votación y finalidad en dirección Alpenglow: rondas de votación más cortas y rápidas dirigidas a una finalidad sólida del orden de ~100-150 ms en buenas condiciones de red.
Rotor es el diseño de propagación de bloques en dirección Alpenglow destinado a entregar bloques al conjunto de validadores de manera más rápida y eficiente que solo la pila de propagación anterior.
Todavía selecciona el compromiso en los métodos RPC y el estado de la firma; reajuste los tiempos de espera y la copia de la UX a medida que mejora la finalidad medida, en lugar de inventar una nueva API de liquidación.
No para la lógica de negocio ordinaria: los programas Anchor 0.32.1 todavía validan cuentas y ejecutan instrucciones; el compromiso es una preocupación del cliente/indexador, no un nuevo pragma en cadena dentro de cada instrucción.
Los casos extremos de bifurcaciones raras son la razón por la que las acciones fuera de la cadena irreversibles deben esperar a finalized (o una política equivalente que acepte explícitamente); siempre vuelva a verificar el estado antes de los pagos.
Pruebe las unidades de la lógica del programa localmente; pruebe la integración del sondeo de compromiso contra RPC de devnet o mainnet con la misma política de compromiso que envía, y vuelva a ejecutar después de las actualizaciones del validador.
Comience con Fundamentos del Consenso para orientación, luego TowerBFT + PoH, Cuentas de Votación y Votación, Introducción a Alpenglow, Votor y Niveles de Compromiso en Clientes.
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.
Revisado por Chris St. John·Última actualización: 15 jul 2026