Arquitectura de Solana en Detalle
Solana no es una bolsa de características no relacionadas. Es un único pipeline de validador de alto rendimiento: programar un líder, pre-reenviar transacciones, ordenarlas con un reloj verificable, ejecutarlas en paralelo, distribuir el resultado y dejar que el resto del clúster las reproduzca y vote.
Esta página es el mapa conceptual de los componentes centrales de la arquitectura. Úselo para ubicar PoH, Turbine, Gulf Stream, Sealevel, TPU/TVU y el programa del líder en un solo mapa antes de profundizar en cada subsistema.
Resumen
Solana apunta a ranuras cortas (aproximadamente 400 ms) con un programa de líder ponderado por participación (stake-weighted). Los clientes y RPC envían transacciones a los líderes próximos en lugar de esperar en un mempool global clásico. Esa ruta de pre-reenvío es Gulf Stream.
El líder actual ejecuta una Unidad de Procesamiento de Transacciones (TPU): ingesta, verificación de firmas, banca y producción. El orden se basa en Proof of History (PoH), una cadena de hash secuencial que actúa como una función de retardo verificable y una línea de tiempo de eventos.
La ejecución utiliza Sealevel: las transacciones declaran cada cuenta que tocan, por lo que los bloqueos de cuentas no superpuestos pueden ejecutarse en paralelo. El estado de la cuenta reside en AccountsDB, diseñada para acceso concurrente al estilo Cloudbreak en lugar de un bloqueo global.
Las entradas producidas se fragmentan (shredded) y propagan con el fanout del árbol de Turbine. Otros validadores reciben a través de la ruta de la Unidad de Validación de Transacciones (TVU), reproducen y votan. Gossip transporta la información de membresía y contacto para que los nodos sepan con quién hablar.
Para los desarrolladores, la arquitectura se manifiesta en tasas de aterrizaje, costos de CU, puntos calientes de cuentas y calidad de RPC. Este es un modelo conceptual, no un manual de operaciones.
Fundamentos
¿Qué problema resuelve el pipeline?
Las blockchains deben acordar el orden y el estado bajo el retraso de la red. Los diseños ingenuos serializan todo y hablan de todos a todos sobre el tiempo y la membresía de las transacciones.
Solana separa las preocupaciones. El tiempo y el orden obtienen PoH. La propagación obtiene Turbine. La presión del mempool obtiene Gulf Stream. La CPU paralela obtiene Sealevel y bloqueos de cuentas explícitos. La concurrencia de almacenamiento obtiene el diseño estilo AccountsDB/Cloudbreak. El descubrimiento del clúster obtiene Gossip. Quién produce cuándo obtiene el programa del líder.
Programa del líder y ranuras (slots)
El tiempo se divide en ranuras. Cada ranura tiene un líder designado de un programa ponderado por participación (stake-weighted) calculado para una época.
El líder debe producir el progreso del ledger para esa ventana. El tiempo objetivo de la ranura es de ~400 ms, por lo que el liderazgo rota rápidamente. Conocer a los líderes próximos permite a la red enrutar el trabajo antes de que llegue la ranura.
Proof of History en una frase
PoH es una secuencia verificable de hashes que prueba el paso del tiempo entre eventos y proporciona una columna vertebral de ordenación compartida sin sincronización de reloj de pared de todos a todos.
PoH no es consenso por sí solo. El consenso (históricamente Tower BFT; el trabajo continúa en la era Alpenglow) todavía decide qué bifurcación (fork) es canónica. PoH hace que el historial ordenado sea barato de verificar y difícil de reescribir sin rehacer el trabajo secuencial.
Roles del pipeline de un vistazo
| Pieza | Rol en el pipeline |
|---|---|
| Programa del líder | Quién produce cada ranura |
| Gulf Stream | Reenvía transacciones hacia los líderes próximos (sin mempool en comparación con diseños clásicos) |
| TPU | Ingesta, verificación de firmas, banca/ejecución, producción del lado del líder |
| PoH | Columna vertebral de ordenación y temporización verificable para entradas |
| Sealevel | Ejecución paralela de programas a través de bloqueos de cuentas declarados |
| Cloudbreak / AccountsDB | Almacenamiento concurrente de cuentas bajo carga |
| Turbine | Fanout de fragmentos (shreds) de bloques a través del clúster |
| TVU | Recepción, reconstrucción, reproducción, preparación para votar del lado del validador |
| Gossip | Membresía, información de contacto, diseminación del plano de control |
Mecánicas
Piensa en la vida de una transacción como un pipeline de izquierda a derecha. Las etapas se superponen en muchas transacciones porque los validadores son máquinas en pipeline, no scripts de un solo hilo.
Pipeline ASCII de extremo a extremo
Cliente / wallet / bot
|
| tx firmada (hash de bloque reciente, metadatos de cuenta, presupuesto de CU)
v
+-----------+
| RPC / | puede retransmitir, simular, estimar tarifas
| gateway |
+-----------+
|
| Gulf Stream: reenvío hacia líderes actuales y próximos
v
[ Líder TPU ]
obtener / verificar firmas / banca
|
| Ticks de PoH + entradas ordenadas
v
[ Ejecución Sealevel ]
tx paralelas si los bloqueos de cuentas no se superponen
secuencial cuando los bloqueos entran en conflicto
|
| CuentasDB / acceso concurrente a cuentas estilo Cloudbreak
v
[ Producir entradas / fragmentos (shreds) ]
|
| Fanout de árbol de Turbine (fragmentos saltan peer-to-peer)
v
[ Otros validadores TVU ]
recibir fragmentos -> reconstruir -> reproducir -> votar
|
v
Confirmación del clúster (votos / elección de bifurcación)
Etapa 1 - Cliente a red
Un cliente crea una transacción que enumera cada cuenta, marca la intención de lectura/escritura, incluye un hash de bloque reciente y lleva firmas. Las instrucciones de Presupuesto de Cómputo pueden establecer el límite de CU y el precio de prioridad.
El cliente envía a un RPC u otra entrada. Ese salto importa: un RPC saludable que entiende el programa del líder y la topología mejora las posibilidades de aterrizaje.
Etapa 2 - Gulf Stream
Gulf Stream impulsa transacciones no confirmadas hacia nodos que liderarán pronto, en lugar de aparcar todo en un mempool global compartido hasta que un proponente lo extraiga.
En comparación con los mempools clásicos, Solana pretende estar sin mempool en el sentido cotidiano: el trabajo se reenvía a lo largo de la ruta del líder en lugar de permanecer en una gran cola de subasta pública en cada nodo. La congestión, las tarifas de prioridad y la capacidad siguen importando. Piensa en "reenviar a los próximos productores", no en "cola pública infinita".
Etapa 3 - Líder TPU
En el líder, la TPU es el pipeline de producción:
- Ingesta de transacciones de la red.
- Verificación de firmas (a menudo en lotes paralelos).
- Banca/ejecución contra AccountsDB.
- Confirmación de resultados ordenados en entradas vinculadas a PoH.
- Entrega de fragmentos (shreds) a la ruta de difusión de Turbine.
El pipelining significa que la etapa N+1 de un lote puede ejecutarse mientras la etapa N trabaja en el siguiente. Es por eso que Solana enfatiza el pipelining TPU/TVU en lugar de una única función monolítica de "procesar bloque".
Etapa 4 - Orden PoH
A medida que el líder produce, PoH continúa hasheando. Los eventos (transacciones, ticks) se mezclan en esa secuencia para que el ledger lleve una historia criptográfica del orden.
Los validadores verifican la secuencia contra las reglas de PoH de manera más económica que reconstruir el tiempo del reloj de pared a partir de marcas de tiempo de todos a todos. PoH ordena y marca el tiempo; los votos y la elección de bifurcación finalizan qué rama sigue el clúster.
Etapa 5 - Ejecución Sealevel
Sealevel es la idea de tiempo de ejecución paralelo de Solana. Dado que cada transacción declara sus cuentas y su conjunto de escritura por adelantado, el planificador puede ejecutar transacciones no conflictivas de forma concurrente.
Si dos transacciones escriben en la misma cuenta, se serializan. Las cuentas "calientes" (mentas populares, bóvedas compartidas, contadores globales) se convierten en cuellos de botella incluso cuando el hardware es bueno. Las unidades de cómputo miden el trabajo por transacción; el paralelismo no elimina tu factura de CU.
Etapa 6 - Fanout Turbine
Las entradas se dividen en fragmentos (shreds) y se envían a través de Turbine. Los pares forman un árbol de fanout para que el líder no envíe el bloque completo a cada validador por unicast. Cada salto retransmite a los hijos, intercambiando algo de latencia multi-salto por escalado de ancho de banda.
Los fragmentos faltantes se reparan bajo petición. Trata a Turbine como el plano de datos del bloque, distinto del plano de control de Gossip.
Etapa 7 - TVU valida y vota
Los no líderes ejecutan la ruta TVU: reciben fragmentos, reconstruyen entradas, reproducen la ejecución y actualizan el estado local si el bloque es válido.
Después de la reproducción, los validadores votan según las reglas de consenso. Los niveles de confirmación del cliente (processed, confirmed, finalized) reflejan cuánto ha progresado el acuerdo, no simplemente que un líder emitió fragmentos.
Dónde encajan Gossip y Cloudbreak
Gossip es cómo los nodos aprenden la membresía, la información de contacto y algunos metadatos del clúster. Sin ese sustrato, los árboles de Turbine y el enrutamiento del líder no pueden formarse.
Cloudbreak (nombre histórico del enfoque de la base de datos de cuentas concurrentes de Solana) y la moderna AccountsDB responden cómo almacenar y actualizar millones de cuentas bajo ejecución multihilo. El paralelismo de ejecución es inútil si cada acceso a la cuenta colisiona en un solo bloqueo de almacenamiento.
Implicaciones para los desarrolladores que surgen del pipeline
- Contención de cuentas - Las cuentas escribibles compartidas fuerzan la ejecución serial de Sealevel. Particiona el estado con PDAs cuando necesites paralelismo.
- Unidades de cómputo - Los programas pesados fallan o aterrizan mal bajo carga. Mide las CU y establece presupuestos deliberadamente.
- Frescura del hash de bloque - Los hashes de bloque expirados mueren en el límite de la TPU. Refresca y re-firma rápidamente.
- Tarifas de prioridad - Durante la congestión, los mercados de tarifas influyen en qué transacciones reenviadas incluye el líder.
- Calidad de RPC y proximidad al líder - Gulf Stream solo ayuda si tu transacción llega a una ruta de líder útil a tiempo.
- Simulación vs. aterrizaje - La simulación verifica la ejecución contra una vista del estado; no garantiza la inclusión o la propagación bajo contención.
Avanzado
Use esta tabla al depurar "¿qué capa es el cuello de botella?" en lugar de "¿es Solana rápido en abstracto?".
| Subsistema | Objetivo principal de optimización | Lo que no resuelve por sí solo | Señal para el desarrollador |
|---|---|---|---|
| PoH | Orden verificable / secuenciación temporal | Elección de bifurcación, finalidad económica | Estructura de ranura; no el diseño de bloqueo de tu aplicación |
| Programa del líder | Ventanas de producción predecibles | Inclusión justa bajo spam | Quién lidera pronto para expectativas de enrutamiento |
| Gulf Stream | Latencia al líder; reduce el desperdicio del mempool | Capacidad infinita | Sensibilidad de aterrizaje a RPC y temporización |
| TPU | Rendimiento del lado del líder a través de etapas en pipeline | Costo de reproducción del validador | Límites de verificación de firmas y banca bajo carga |
| Sealevel | Cómputo paralelo a través de cuentas no superpuestas | Actualizaciones de una sola cuenta "caliente" | Contención en escrituras compartidas |
| Medición de CU | Trabajo limitado por transacción | Equidad entre aplicaciones | Errores de presupuesto excedido; mercados de tarifas |
| Cloudbreak / AccountsDB | E/S concurrente de almacenamiento de cuentas | Diseño de cuenta deficiente | Crecimiento del estado, diseños con muchos bloqueos |
| Turbine | Propagación de bloques eficiente en ancho de banda | Votos de consenso | Confirmaciones lentas si la propagación/reparación tiene problemas |
| TVU | Reproducción y ruta de validación eficientes | Abstracciones de UX del cliente | La producción puede superar la reproducción lenta |
| Gossip | Membresía e información del plano de control | Transferencia de bloques masiva | Problemas de topología/pares (orientado a operaciones) |
Latencia vs. ancho de banda vs. cómputo paralelo
- Ruta sensible a la latencia: cliente -> Gulf Stream -> ingesta TPU del líder. Los milisegundos y la calidad del enrutamiento aparecen primero aquí.
- Ruta sensible al ancho de banda: fanout de fragmentos de Turbine y reparación. El tamaño del bloque y la topología de red dominan aquí.
- Ruta sensible al cómputo paralelo: Sealevel + AccountsDB. El bloqueo de cuentas y las CU del programa dominan aquí.
El alto rendimiento requiere los tres. Optimizar solo una dimensión produce mesetas sorprendentes.
Cómo se componen las piezas (no compiten)
Un error común es clasificar un subsistema como "la razón por la que Solana es rápido" por sí solo. El rendimiento es multiplicativo a lo largo de un pipeline.
Líderes rápidos sin Turbine no pueden alimentar a los validadores. Turbine sin Sealevel todavía se serializa en conflictos. Sealevel sin almacenamiento concurrente deja hambrientos a los hilos. Gulf Stream sin un programa de líder no tiene a dónde enviar el trabajo de manera inteligente. PoH sin votos es solo un candidato a registro ordenado, no una cadena finalizada.
Conceptos erróneos comunes
Concepto erróneo: PoH es el consenso de Solana. PoH es un mecanismo de ordenación y retardo verificable. El consenso requiere votos y elección de bifurcación. Una entrada vinculada a PoH no es finalidad económica.
Concepto erróneo: Solana no tiene mempool, por lo que no puede existir congestión. Gulf Stream cambia dónde esperan las tareas no confirmadas. No crea inclusión infinita. Los líderes todavía seleccionan bajo capacidad, tarifas y reglas de validez.
Concepto erróneo: Sealevel significa que cada transacción siempre se ejecuta en paralelo. Solo los bloqueos de cuentas no conflictivos se paralelizan. Una cuenta "caliente" escribible puede serializar una gran fracción del tráfico.
Concepto erróneo: Turbine es Gossip. Turbine es la propagación de bloques/fragmentos con fanout estructurado. Gossip es la comunicación de membresía y del plano de control.
Concepto erróneo: TPU y TVU son el mismo pipeline. TPU es la producción del líder. TVU es la recepción y reproducción del validador. Mismo estado final cuando es honesto y está sincronizado; roles y cuellos de botella diferentes.
Concepto erróneo: Una simulateTransaction exitosa significa que la tx aterrizará.
La simulación verifica la ejecución contra una instantánea. No reserva capacidad del líder, gana un mercado de tarifas ni garantiza la propagación de fragmentos.
Concepto erróneo: El conocimiento de la arquitectura es solo para validadores. Los desarrolladores sienten la arquitectura a través del diseño de cuentas, CU, tarifas, hashes de bloque y comportamiento de RPC.
Concepto erróneo: El tiempo de ranura garantiza el tiempo de confirmación visible para el usuario. Los objetivos de ranura describen la cadencia de producción. La confirmación depende de los votos, las bifurcaciones, el nivel de compromiso y la salud de la red.
Preguntas frecuentes
¿Cuál es la descripción precisa más corta de la arquitectura de Solana?
Un pipeline de líder programado por participación que pre-reenvía transacciones, las ordena con PoH, ejecuta trabajo no conflictivo en paralelo, distribuye bloques con Turbine, y hace que los validadores reproduzcan y voten.
¿Es Proof of History un reloj o un algoritmo de consenso?
Trata PoH como una secuencia verificable que soporta afirmaciones de ordenación y temporización. El consenso todavía depende de los votos del validador y las reglas de elección de bifurcación.
¿Por qué el programa del líder está ponderado por participación (stake-weighted)?
Los líderes se asignan proporcionalmente a la participación para que los derechos de producción de bloques sigan la seguridad económica a lo largo del programa de una época, no una carrera libre cada ranura.
¿Qué significa "sin mempool" para Gulf Stream?
El reenvío a los líderes próximos es la ruta principal, no un mempool global grande y clásico en cada nodo. No significa inclusión ilimitada y gratuita.
¿Cuál es la diferencia entre TPU y TVU?
TPU es el procesamiento del lado del líder y la producción de bloques. TVU es la recepción, reconstrucción, reproducción y preparación para votar del lado del validador.
¿Cómo sabe Sealevel qué transacciones se pueden ejecutar en paralelo?
Las transacciones declaran todas las cuentas y cuáles son escribibles. Los conjuntos de bloqueo disjuntos se ejecutan concurrentemente; los conflictos se serializan.
¿Por qué las cuentas "calientes" perjudican el rendimiento?
Los conflictos de escritura fuerzan la serialización en Sealevel. Muchos usuarios que tocan una cuenta global se convierten en una fila única.
¿Qué está optimizando Turbine?
Propagación de bloques eficiente en ancho de banda a través de fanout de árbol de fragmentos (shreds), para que los líderes no necesiten enviar por unicast la carga completa a cada par.
¿Dónde encaja Cloudbreak si Sealevel ya paraleliza?
Sealevel planifica la ejecución paralela. El almacenamiento estilo AccountsDB/Cloudbreak sirve acceso concurrente a cuentas por debajo sin un bloqueo global.
¿Para qué se utiliza Gossip en este modelo mental?
Membresía del clúster, información de contacto y datos del plano de control que permiten a los líderes, Turbine y los pares encontrarse.
¿Cómo se relacionan las unidades de cómputo con la arquitectura?
Las CU limitan el trabajo por transacción durante la ejecución de Sealevel. El paralelismo del clúster y tu presupuesto de transacciones están relacionados pero no son el mismo control.
¿Por qué la calidad de RPC afecta el aterrizaje si la cadena está descentralizada?
Tu transacción aún debe ingresar a la ruta Gulf Stream/TPU a tiempo con un hash de bloque válido. El enrutamiento y la posición de RPC afectan ese salto.
¿Significa el pipelining que las etapas son microservicios independientes?
No necesariamente. El pipelining es procesamiento estructurado por etapas dentro de los validadores y a través de saltos. Las etapas se superponen en el tiempo como un único pipeline de ledger.
¿Cómo debo mapear las fallas visibles para el usuario a este modelo?
Hash de bloque expirado o nunca recibido: ingesta/Gulf Stream/TPU. Problemas de CU o bloqueo: Sealevel/diseño del programa. Confirmaciones lentas: Turbine, reproducción o votos. Problemas de pares: Gossip/operaciones.
¿Es esta página suficiente para operar un validador?
No. Este es un paraguas conceptual para desarrolladores y arquitectos, no un manual de operaciones.
Relacionados
- Descripción general de la arquitectura - mapa pieza por pieza de la misma pila
- Proof of History (PoH) - secuencia verificable y rol de ordenación
- Turbine - fanout de fragmentos (shreds) y propagación de bloques
- Gulf Stream - reenvío de transacciones hacia los líderes
- Sealevel - tiempo de ejecución paralelo y bloqueos de cuentas
- Pipelining (TPU/TVU) - rutas de producción del líder vs. reproducción del validador
- Programa del líder y producción de bloques - ranuras, líderes y cadencia de producción
- Cloudbreak y Accounts DB - almacenamiento concurrente de cuentas
- Gossip y comunicación del clúster - membresía y plano de control
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.