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.
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.
Resumen
- El consenso en Solana es un acuerdo ponderado por participación sobre qué bifurcación es la cadena canónica; los clientes observan ese acuerdo como
procesado,confirmadoyfinalizado, mientras que los validadores producen y votan bloques ordenados en ranuras. - Por Qué Importa: Las elecciones de compromiso incorrectas crean una interfaz de usuario de "éxito" falsa, ventanas de doble gasto en retiros y tiempos de espera frágiles; comprender la escalera (y lo que Alpenglow pretende cambiar) le permite dimensionar el riesgo correctamente a medida que evoluciona el software del validador.
- Conceptos Clave: slot (ranura), leader (líder), fork (bifurcación), PoH, TowerBFT, vote account (cuenta de votación), lockout (bloqueo), supermajority (supermayoría), commitment (compromiso), root (raíz), Alpenglow, Votor, Rotor.
- Cuándo Usar: Diseñar la UX de confirmación; depurar errores de "tx desapareció" o adyacentes a reorganizaciones; incorporar ingenieros que conocen cuentas/transacciones pero no votación; planificar presupuestos de latencia del cliente durante las actualizaciones de consenso.
- Limitaciones / Compensaciones: Los validadores locales, LiteSVM y muchos entornos de prueba no modelan el comportamiento completo de votación/finalidad; la latencia de confirmación depende del clúster y la versión; los detalles de Alpenglow y el estado de activación pueden moverse con los SIMD y las notas de la versión.
- Temas Relacionados: Fundamentos del consenso, TowerBFT + PoH, cuentas de votación, introducción a Alpenglow, Votor y niveles de confirmación del cliente.
Fundamentos
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.
Mecánicas e Interacciones
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 elegido
La 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:
- Interfaz de usuario optimista (
processed): mostrar estado "enviado" o especulativo; mantener una ruta de reversión fácil si la firma nunca se confirma. - Éxito de aplicación reversible (
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. - Efectos externos irreversibles (
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.
Consideraciones Avanzadas y Aplicaciones
Niveles de compromiso como superficie de control de ingeniería
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".
Comportamiento de la era TowerBFT vs dirección Alpenglow
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 |
Lo que permanece igual para clientes y autores de programas
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.
Lo que observan los operadores y los equipos de plataforma
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.
Patrones de diseño que envejecen bien a través de la actualización
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.
Conceptos Erróneos Comunes
- "Una firma de transacción devuelta significa que la transferencia es final." La firma es un ID para el seguimiento del estado; la durabilidad es el nivel de compromiso que espera después.
- "PoH es el algoritmo de consenso por sí solo." PoH ordena y marca el tiempo del historial; TowerBFT (históricamente) y Votor (dirección Alpenglow) son las capas de votación/finalidad que eligen qué historial ordenado gana.
- "Alpenglow ya es lo único que refleja cada RPC de la red principal, por lo que la vieja intuición de TowerBFT es inútil." Trate Alpenglow como la ruta de actualización con activación por etapas; mantenga las semánticas de confirmación de la era TowerBFT hasta que las notas de la versión y las mediciones de su clúster de destino digan lo contrario.
- "
confirmedyfinalizedson 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. - "Los cambios de consenso reescribirán cómo mi programa almacena el estado." El consenso selecciona bloques; los programas todavía poseen cuentas y todavía requieren metadatos de cuenta explícitos.
- "LiteSVM o un validador local prueban mis SLO de finalidad de producción." Las pilas locales omiten o simplifican la votación ponderada por participación real; use RPC de clúster público para la sincronización de confirmación.
Preguntas Frecuentes
¿Qué debería significar "consenso de Solana" para un desarrollador en una oración?
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.
¿Cómo funcionan juntos TowerBFT y PoH en el modelo histórico?
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.
¿Qué es una cuenta de votación?
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.
¿Por qué importan los bloqueos si nunca ejecuto un validador?
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.
¿Cuál es la diferencia práctica entre procesado, confirmado y finalizado?
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.
¿Qué compromiso debería usar mi dapp por defecto?
Muchas acciones de producto usan confirmed para una UX receptiva; use finalized antes de efectos externos irreversibles; trate processed como solo optimista.
¿Qué es Alpenglow en términos para desarrolladores?
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.
¿Está Alpenglow completamente activo en todas partes a partir de la fecha de fijación de la pila de esta página?
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).
¿Qué es Votor?
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.
¿Qué es Rotor?
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.
¿Qué cambia para los clientes de TypeScript en @solana/kit 7.0.0?
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.
¿Necesitan los programas Anchor código específico del consenso?
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.
¿Puede una transacción confirmarse y luego no finalizar?
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.
¿Cómo debo probar el comportamiento de confirmación?
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.
¿A dónde voy a continuación en esta sección?
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.
Relacionado
- Fundamentos del Consenso - orientación sobre bifurcaciones, confirmaciones y finalidad
- TowerBFT + PoH - BFT basado en votos con ordenación PoH en el modelo de la era Agave
- Cuentas de Votación y Votación - cómo votan los validadores y cómo funcionan los bloqueos
- Introducción a Alpenglow - Diseño de Votor + Rotor y objetivos de finalidad rápida
- Votor - el mecanismo de votación y finalidad en dirección Alpenglow
- Niveles de Compromiso en Clientes - compensaciones de procesado / confirmado / finalizado en el código de la aplicación
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.