Arquitectura de Solana: 8 Innovaciones Detrás de la Velocidad de SOL

Nota de precisión: El rendimiento de la red, el número de validadores, las comisiones, las características del protocolo, el soporte de billeteras y las integraciones de terceros cambian con el tiempo. Trata las cifras fechadas como instantáneas históricas y verifica la documentación actual de fuente primaria.

La arquitectura de Solana se explica comúnmente a través de ocho ideas de diseño de sus primeros materiales técnicos. Algunas siguen siendo centrales, mientras que otras son propuestas históricas o han evolucionado, por lo que este artículo distingue el modelo original de las afirmaciones de implementación actuales.

Los primeros materiales de Solana agruparon la arquitectura en ocho ideas destinadas a soportar la ejecución de alto rendimiento. El rendimiento actual, la propiedad de la implementación, los componentes de software y los roles organizacionales evolucionan, por lo que este artículo trata el marco de "ocho innovaciones" como un modelo explicativo histórico en lugar de una especificación actual completa.

Puntos Clave

La arquitectura de Solana se basa en ocho pilares, cada uno resolviendo un cuello de botella de rendimiento específico:

1. Proof of History (PoH): reloj criptográfico que marca el tiempo de los eventos antes de que se ejecute el consenso

2. Tower BFT: Mecanismo de Consenso que utiliza marcas de tiempo PoH en la votación

3. Turbine: propagación de bloques que divide los bloques en paquetes más pequeños

4. Gulf Stream: reenvío de transacciones basado en líderes programados

5. Sealevel: tiempo de ejecución paralelo de contratos inteligentes

6. Pipelining: procesamiento de transacciones por etapas

7. Cloudbreak: base de datos de cuentas diseñada para acceso concurrente

8. Archivers: una propuesta histórica de almacenamiento distribuido

Nota de rendimiento: El TPS teórico histórico, el tiempo de slot objetivo, la confirmación, la finalidad, las comisiones base y las comisiones de prioridad son mediciones diferentes. Verifica las métricas actuales y fechadas y la metodología detrás de ellas.

Compromiso honesto: Solana ha experimentado interrupciones de red documentadas desde el lanzamiento de Mainnet en marzo de 2020, y sus requisitos de hardware de validador (se recomiendan 128+ GB de RAM) crean presión de centralización. Estos son compromisos arquitectónicos conocidos, no problemas incidentales.

El Problema que Solana Fue Diseñada para Resolver

Las blockchains se enfrentan tradicionalmente a una limitación fundamental: el Trilema Blockchain, un concepto popularizado por Vitalik Buterin, afirma que una red puede lograr simultáneamente como máximo dos de tres propiedades. Esas propiedades son escalabilidad (alto rendimiento), seguridad (resistencia a ataques) y descentralización (control distribuido). Piensa en ello como un triángulo donde empujar una esquina más allá siempre atrae a las otras dos hacia adentro. Bitcoin procesa ~7 TPS con tiempos de bloque de 10 minutos, priorizando seguridad y descentralización a costa del rendimiento. Ethereum procesaba ~15–30 TPS en su capa base antes de que se añadieran soluciones de escalado, priorizando también seguridad y descentralización.

Anatoly Yakovenko, un antiguo ingeniero de sistemas distribuidos en Qualcomm, abordó esta limitación de manera diferente. En noviembre de 2017, publicó un Whitepaper titulado Proof of History: A Clock for Blockchain, describiendo un mecanismo criptográfico de cronometraje que podría reducir drásticamente la sobrecarga de comunicación en los algoritmos de consenso. Greg Fitzgerald se unió como cofundador y CTO, y juntos construyeron el protocolo que se convirtió en Solana. Solana Labs, la empresa con ánimo de lucro que cofundaron, lidera el desarrollo del protocolo principal. La Fundación Solana, una entidad separada sin ánimo de lucro con sede en Ginebra, financia subvenciones para el ecosistema, programas de descentralización de validadores e iniciativas educativas.

La arquitectura de ocho pilares de Solana fue diseñada para empujar el límite de escalabilidad lo más lejos posible dentro de esas limitaciones del trilema. El diseño acepta deliberadamente requisitos de hardware de validador más altos como coste de ese rendimiento. Solana no resuelve el trilema; ocupa una Posición inusualmente agresiva en el eje de escalabilidad. Esos compromisos tienen costes reales, examinados en la sección de compromisos arquitectónicos a continuación.

Los Ocho Pilares Arquitectónicos de Solana: Una Visión General

El marco histórico de ocho partes cubre Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak y Archivers. No todos los elementos deben considerarse subsistemas desplegados por separado en la actualidad, en particular la propuesta de Archivers.

1. Proof of History: una cadena de hash SHA-256 secuencial que crea un registro de marca de tiempo verificable antes de que se ejecute el consenso
2. Tower BFT: un Mecanismo de Consenso tolerante a fallos bizantinos mejorado con PoH que utiliza marcas de tiempo PoH para votar eficientemente
3. Turbine: un protocolo de propagación de bloques inspirado en BitTorrent que divide los bloques en pequeños paquetes con codificación de borrado llamados "shreds"
4. Gulf Stream: un protocolo de reenvío de transacciones sin Mempool que dirige las transacciones directamente a los líderes validadores próximos
5. Sealevel: un tiempo de ejecución de ejecución paralela de contratos inteligentes que ejecuta miles de programas no conflictivos simultáneamente
6. Pipelining: un sistema de Optimización de Validación de Transacciones (TVO) que procesa transacciones a través de cuatro etapas de hardware concurrentes
7. Cloudbreak: una base de datos de cuentas escalada horizontalmente que utiliza archivos mapeados en memoria para soportar lecturas y escrituras concurrentes
8. Archivers: una propuesta histórica para el almacenamiento de Ledger distribuido utilizando conceptos de prueba de replicación

Cada pilar se cubre en profundidad en las secciones siguientes.

Proof of History (PoH): El Motor de Cronometraje de Solana

Proof of History (PoH) es una cadena de hash SHA-256 secuencial que crea un registro verificable y ordenado cronológicamente de eventos antes de que se ejecute el consenso, actuando como un reloj criptográfico compartido para toda la red. PoH no es el Mecanismo de Consenso de Solana; ese papel pertenece a Tower BFT. PoH es la capa de cronometraje que hace que Tower BFT sea rápido.

Piensa en PoH como un cronómetro criptográfico que prueba cuánto tiempo ha pasado entre eventos, sin requerir que cada validador de la red verifique los relojes de los demás primero. En las redes blockchain tradicionales, los validadores deben intercambiar mensajes de marca de tiempo entre sí durante cada ronda de consenso, lo que añade una sobrecarga de comunicación que crece con el tamaño del conjunto de validadores. PoH elimina por completo ese intercambio.

Técnicamente, PoH es una cadena de hash SHA-256 secuencial donde cada salida se convierte en la entrada para la siguiente computación. Dado que SHA-256 no se puede paralelizar en esta forma encadenada, la longitud de la cadena es un registro a prueba de manipulaciones del tiempo transcurrido. Un validador que produce una cadena de N hashes ha demostrado haber empleado el tiempo necesario para computar N operaciones de hash secuenciales. No existe un atajo. Anatoly Yakovenko describió por primera vez este mecanismo en su Whitepaper de noviembre de 2017, Proof of History: A Clock for Blockchain.

PoH funciona como una Función de Retraso Verificable (VDF): un cálculo que requiere una cantidad de tiempo predecible y secuencial para computarse, pero que puede verificarse de forma casi instantánea. Esta asimetría entre el tiempo de computación y el tiempo de verificación es lo que hace que la PoH sea práctica. Los validadores pueden difundir la salida de la PoH y cualquier observador puede verificar su autenticidad en microsegundos, a pesar de que producirla requirió tiempo real transcurrido. Esta es la propiedad que los investigadores académicos y los analistas de protocolos reconocerán como el fundamento teórico de las propiedades de seguridad de la PoH.

Al establecer una referencia de ordenación verificable, la PoH puede reducir parte de la coordinación temporal. No elimina los mensajes de consenso ni garantiza directamente un slot, una confirmación o un tiempo de finalidad determinados.

Una aclaración crítica: a veces se describe a Solana como una "Blockchain de Proof of History", lo que implica que la PoH reemplaza a Proof of Stake (PoS). Esto es incorrecto. Solana es una blockchain de Proof of Stake en su capa de seguridad económica. Los validadores hacen que sus SOL participen en staking como garantía y se enfrentan al slashing por comportamiento deshonesto. La PoH es el reloj criptográfico que hace que el consenso PoS de Solana, implementado a través de Tower BFT, sea más rápido y eficiente. Ambas capas son necesarias; ninguna reemplaza a la otra.

Tower BFT: El Mecanismo de Consenso de Solana

Tower BFT es el Mecanismo de Consenso de Solana: una variante de la Tolerancia a Faltas Bizantinas Práctica (pBFT) mejorada con PoH que utiliza el registro de marcas de tiempo de PoH como un reloj compartido, lo que permite a los validadores votar sobre el estado del libro mayor sin intercambiar mensajes de sincronización de reloj.

La Tolerancia a Faltas Bizantinas (BFT) describe la propiedad de un sistema distribuido que le permite alcanzar el consenso correctamente incluso cuando algunos participantes se comportan de forma maliciosa o impredecible, llamada así por el problema de los generales bizantinos en la computación distribuida. Los algoritmos pBFT tradicionales requieren un intercambio extensivo de mensajes entre nodos para establecer una visión común del tiempo, lo que los hace poco prácticos a escala. Tower BFT sustituye ese intercambio de mensajes por el registro de PoH. Los validadores ya comparten el reloj de PoH; no necesitan negociar las marcas de tiempo.

Los validadores son participantes de la red que hacen que sus SOL participen en staking, validan transacciones, producen bloques cuando son seleccionados como líderes y votan sobre el estado del libro mayor. Emiten votos bloqueados por tiempo que crecen exponencialmente en los Forks. Cuanto más tiempo vote un validador en un Fork concreto, más SOL corre el riesgo de perder a través del slashing (el mecanismo de penalización que elimina los tokens en staking por comportamiento deshonesto o inconsistente) si ese Fork se abandona. Este mecanismo de bloqueo de votos crea fuertes incentivos económicos para la participación honesta sin requerir rondas de comunicación adicionales.

Tower BFT tolera que hasta un tercio del conjunto de validadores se comporte de forma bizantina. Si menos de un tercio de los validadores actúan de forma maliciosa, la red alcanza un consenso correcto. Este umbral se deriva de los requisitos matemáticos del problema de los generales bizantinos, formalizado originalmente por Lamport, Shostak y Pease en 1982. El linaje del consenso para los investigadores: pBFT (Castro y Liskov, 1999) estableció el algoritmo fundamental; las variantes posteriores, incluyendo HotStuff y Tendermint, lo mejoraron; Tower BFT (2017) da el paso adicional de eliminar la sobrecarga de sincronización de reloj a través de PoH.

Un tiempo de slot objetivo no debe presentarse como una garantía de finalidad. Las aplicaciones deben distinguir entre los niveles de compromiso procesado, confirmado y finalizado, y seleccionar las reglas de confirmación en función de su modelo de riesgo.

Turbine: Propagación de bloques a escala

Difundir un bloque completo a cada validador a 65.000 TPS teóricos crearía un cuello de botella en el ancho de banda que crecería linealmente con el tamaño de la red. Turbine soluciona esto de la misma manera que BitTorrent soluciona la distribución de archivos grandes: dividiendo los datos en trozos pequeños y repartiendo la carga de propagación por toda la red.

Turbine es el protocolo de propagación de bloques de Solana, inspirado en el modelo de distribución basado en fragmentos de BitTorrent. En lugar de que un líder difunda un bloque completo a todos los validadores simultáneamente, Turbine divide los bloques en pequeños paquetes con código de borrado llamados shreds y los distribuye a través de una red de validadores estructurada en árbol.

Los shreds utilizan código de borrado para la redundancia. Cada nodo del árbol de propagación recibe un subconjunto de shreds, los retransmite a la siguiente capa y reconstruye el bloque completo a partir del subconjunto que recibe. El código de borrado significa que, aunque se pierdan algunos shreds en la transmisión, el bloque puede reconstruirse a partir de los paquetes restantes. Los requisitos de ancho de banda escalan logarítmicamente en lugar de linealmente con el tamaño de la red, porque cada validador maneja solo una fracción de los datos totales del bloque.

Ampliar el conjunto de validadores no aumenta proporcionalmente los requisitos de ancho de banda por nodo. Una red con 2.000 validadores no requiere que cada validador maneje 2.000 veces el ancho de banda de un sistema centralizado. El árbol de propagación distribuye la carga. La estructura de shreds de Turbine es relevante para los operadores de validadores al planificar la recepción de datos y la capacidad de reconstrucción de bloques.

Gulf Stream: Reenvío de transacciones sin Mempool

Gulf Stream utiliza un reenvío que conoce al líder en lugar de un mempool global compartido convencional. Esto cambia el modelo de colas, pero no elimina la congestión ni los incentivos de ordenación de transacciones.

En Ethereum, las transacciones no confirmadas esperan en el mempool: el grupo compartido de transacciones no confirmadas que esperan ser incluidas en un bloque. Durante los períodos de alta demanda, este grupo se convierte en una fuente de congestión, escalada de comisiones y Valor Máximo Extraíble (MEV), el beneficio extraído al reordenar, insertar o censurar transacciones dentro del mempool antes de que finalicen. Los usuarios de Ethereum presentan una Oferta de gas más alta para priorizar sus transacciones, razón por la cual las comisiones históricamente alcanzaron los 5-50 $ o más durante el pico de uso.

El diseño utiliza el calendario de líderes conocido de Solana para reenviar las transacciones a los próximos líderes en lugar de difundirlas a un grupo global convencional. Los validadores pueden preparar las transacciones antes de que les toque producir bloques, lo que puede reducir la latencia de las colas, mientras que la congestión, la competencia por las comisiones, las caídas y el MEV siguen siendo preocupaciones distintas.

El reenvío de transacciones que conoce al líder cambia la forma en que las transacciones llegan a los líderes programados, pero no elimina la congestión, la competencia por las comisiones de prioridad, el MEV, las transacciones descartadas o la presión sobre los recursos de los validadores. Las comisiones base y de prioridad actuales deben medirse directamente en lugar de convertirse a una cantidad fija en USD.

La ausencia de un mempool cambia los patrones de envío de transacciones para los desarrolladores que construyen en Solana. Las transacciones tienen una ruta de reenvío predecible, lo que permite una confirmación optimista antes de la finalidad completa. El área de superficie de MEV en Solana es sustancialmente menor que en Ethereum, aunque no es cero; la ordenación de transacciones ponderada por la participación en staking crea su propia dinámica que los diseñadores de dApps deberían estudiar antes de construir.

Sealevel: Ejecución paralela de contratos inteligentes

Sealevel es el entorno de ejecución paralela de contratos inteligentes de Solana, el motor que ejecuta programas On-Chain (el término de Solana para lo que Ethereum llama contratos inteligentes). A diferencia de la EVM de Ethereum, que ejecuta contratos de forma secuencial uno a uno, Sealevel ejecuta miles de programas que no entran en conflicto simultáneamente a través de los núcleos de GPU y CPU disponibles.

La EVM de Ethereum procesa los contratos inteligentes como una única caja en un supermercado: una transacción cada vez, y cada comprador espera detrás del anterior. Sealevel abre veinte cajas simultáneamente, ejecutando transacciones que no entran en conflicto en paralelo. Esta es la principal razón arquitectónica por la que el rendimiento de Solana supera al de Ethereum en la capa base.

El paralelismo es posible porque el modelo de programación de Solana requiere que cada transacción declare, en el momento de su envío, qué cuentas (los objetos de estado que almacenan datos en Solana) leerá y escribirá. Sealevel analiza estas listas de acceso a cuentas para identificar transacciones que no entren en conflicto: aquellas que afecten a cuentas completamente diferentes pueden ejecutarse simultáneamente sin producir cambios de estado contradictorios. Las transacciones que comparten cuentas deben ejecutarse de forma secuencial. El tiempo de ejecución de Sealevel utiliza esta declaración para programar la ejecución paralela o secuencial a través de los núcleos de hardware disponibles.

Los programas en cadena se escriben principalmente en Rust, se compilan a bytecode Berkeley Packet Filter (BPF) y se ejecutan en el runtime Sealevel. La ejecución paralela en núcleos de GPU y CPU es lo que hace que 65.000 TPS teóricos sean físicamente alcanzables a nivel de hardware.

Qué significa esto para los desarrolladores

Cuando implementas un programa en Solana, debes declarar todas las cuentas que tu programa leerá y escribirá en el momento de envío de la transacción. Esta lista de acceso a cuentas no es opcional; es el mecanismo que Sealevel utiliza para programar la ejecución paralela. Omitir o declarar cuentas de forma incorrecta provoca fallos en las transacciones.

Los programas que comparten estado con otros programas (al escribir en las mismas cuentas) no pueden beneficiarse del paralelismo y siempre se ejecutarán de forma secuencial. Diseñe la estructura de cuentas de su programa para minimizar el estado compartido siempre que sea posible. Los programas con patrones de acceso a cuentas estrechos y que no se solapan son los que más se benefician del planificador paralelo de Sealevel.

El framework Anchor, un kit de herramientas basado en Rust que proporciona macros y abstracciones que simplifican patrones de programas comunes, es el kit de herramientas de desarrollo más utilizado para programas de Solana. Para obtener documentación completa sobre el modelo de cuentas, las direcciones derivadas de programas y el tiempo de ejecución de Sealevel, consulta la documentación para desarrolladores de Solana.

Canalización: Validación de transacciones como una línea de montaje

Una línea de montaje de automóviles no fabrica un coche por completo antes de empezar el siguiente. Cada estación (soldadura, pintura, montaje interior) trabaja en un coche diferente de forma simultánea. Solana aplica esta misma lógica a la validación de transacciones a través de la Optimización de la Validación de Transacciones (TVO).

La canalización en Solana se refiere a TVO, una aplicación de la arquitectura de canalización de CPU al procesamiento de transacciones en blockchain. El proceso de validación de transacciones se divide en cuatro etapas discretas, cada una gestionada por una unidad de hardware separada que opera de forma concurrente. Mientras un lote de transacciones avanza por una etapa, el siguiente lote ya se encuentra en la etapa anterior.

Las cuatro etapas son:

1. Obtener: una unidad en el espacio del kernel recupera datos de transacciones entrantes de la red
2. Verificación de firmas (SigVerify): la GPU verifica firmas criptográficas en todo el lote en paralelo
3. Banca: la CPU procesa la lógica de las transacciones, comprueba los saldos de las cuentas y actualiza el estado de la cuenta
4. Confirmación de escritura: el disco escribe los cambios de estado finalizados

Mientras el lote A está en el proceso de banca (Banking), el lote B está en SigVerify y el lote C se está recuperando. Ningún componente de hardware permanece inactivo esperando a que finalice el lote anterior. Esta puesta en escena continua elimina el tiempo de inactividad de la CPU entre las etapas de procesamiento que, de lo contrario, limitaría el rendimiento.

El pipelining es uno de los tres pilares, junto con Sealevel y Gulf Stream, que en conjunto producen la capacidad total de procesamiento de transacciones de Solana. Solana extrae más rendimiento del mismo hardware manteniendo todos los componentes de procesamiento funcionando en todo momento, en lugar de dejar que cualquier etapa permanezca inactiva entre lotes.

Cloudbreak: Base de datos de cuentas con escalado horizontal

Cloudbreak es el sistema de archivos que permite a los procesadores en paralelo de Solana leer y escribir datos de cuentas simultáneamente sin necesidad de colas. Sin él, la capa de almacenamiento serializaría todas las lecturas y escrituras de cuentas, y las mejoras de paralelismo de Sealevel se evaporarían en el límite de la base de datos.

Cloudbreak es la base de datos de cuentas de Solana escalada horizontalmente: la estructura de datos que almacena el estado de cada cuenta en la red. Utiliza archivos mapeados en memoria y estructuras de datos optimizadas para SSD para admitir lecturas y escrituras concurrentes en múltiples hilos simultáneamente.

Las cuentas se distribuyen en varias estructuras de datos accesibles en paralelo. La E/S de mapeo de memoria del sistema operativo permite a Cloudbreak tratar los datos de cuenta residentes en disco como si estuvieran en RAM, eliminando la latencia de búsqueda y permitiendo el acceso concurrente a nivel de hilo. Cuando Sealevel programa 10.000 transacciones paralelas, Cloudbreak atiende 10.000 lecturas y escrituras de cuentas simultáneas sin serializar las solicitudes en una cola.

La arquitectura de la base de datos y el entorno de ejecución son interdependientes: ninguno proporciona rendimiento sin el otro. Los patrones de E/S de Cloudbreak requieren unidades SSD NVMe de alto rendimiento. Las unidades de disco giratorio estándar no pueden mantener el rendimiento de lectura/escritura aleatoria que exige el modelo de acceso concurrente de Cloudbreak. Comprender el modelo de cuentas de Cloudbreak es fundamental para el diseño de programas de Solana: todo el estado reside en objetos de cuenta discretos, los programas operan sin estado sobre esas cuentas y las decisiones sobre la disposición de las cuentas afectan directamente al rendimiento de lectura/escritura del entorno de ejecución.

Archivadores: Una propuesta de almacenamiento histórico

El concepto Archivers aparece en materiales de arquitectura inicial de Solana, pero no debe presentarse como un subsistema de producción desplegado actualmente sin evidencia de fuentes primarias vigentes.

Los materiales de diseño iniciales proponían a los Archivers (también denominados Replicadores en algunas descripciones) como participantes ligeros que almacenaban fragmentos de los datos históricos del libro mayor y acreditaban dicho almacenamiento. Esto explica el planteamiento original ante el crecimiento del libro mayor, pero no debe describirse como una red de producción activa sujeta a recompensas sin contar con una confirmación actual de fuentes primarias. La infraestructura de archivo y retención del libro mayor actual debe documentarse por separado.

Con los ocho pilares arquitectónicos en su lugar, el sistema combinado produce puntos de referencia de rendimiento que separan a Solana de la mayoría de las otras blockchains públicas, lo que se cuantifica en la siguiente sección.

Benchmarks de Rendimiento de Solana: TPS, Comisiones y Finalidad de Bloque

~65.000 TPS en benchmarks teóricos históricos es el máximo teórico de Solana en condiciones óptimas de laboratorio, no una cifra real sostenida. La distinción es importante para cualquiera que utilice estas cifras en análisis de inversión o diseño de sistemas.

Utilizar fuentes primarias actuales y una metodología de medición consistente para comparaciones de desempeño.

El rendimiento de la red principal en el mundo real es inferior al máximo teórico por varias razones. No todas las ranuras de transacción se llenan completamente durante la demanda normal. Los mecanismos de filtrado de spam rechazan las transacciones de baja calidad antes de que lleguen a la etapa de procesamiento. Las condiciones de la red afectan el tiempo de propagación. Acercarse al límite teórico requiere una demanda pico sostenida combinada con la utilización completa del hardware en todo el conjunto de validadores, condiciones que ocurren durante eventos específicos de alto tráfico en lugar de continuamente.

El perfil de rendimiento de Solana proviene de varias fuentes arquitectónicas que trabajan en conjunto. PoH proporciona una referencia de ordenación verificable que puede reducir la sobrecarga de coordinación temporal. Sealevel ejecuta tareas que no entran en conflicto en paralelo. El reenvío consciente del líder (leader-aware forwarding) puede organizar las transacciones antes de que se abra un intervalo de bloque (block slot), lo que reduce parte de la cola convencional en el Mempool sin eliminar la latencia de red.

El ecosistema de Capa 2 de Ethereum (que incluye Arbitrum y Optimism) y las futuras actualizaciones de fragmentación (sharding) aumentan el rendimiento efectivo de Ethereum mucho más allá de su cifra de capa base. Cualquier comparación completa debería tener en cuenta esa capacidad ampliada al evaluar las dos plataformas para un caso de uso específico.

De la arquitectura a la aplicación: cómo el diseño de Solana habilita casos de uso reales

Las decisiones arquitectónicas de Solana producen resultados específicos y medibles para las aplicaciones creadas sobre ellas, no cifras de rendimiento abstractas.

NFT: Las tarifas generalmente bajas de Solana y la ejecución en paralelo pueden admitir el minado de alto volumen, pero las tarifas de prioridad, los costes de aplicación, la congestión, los fallos y los estándares de activos siguen siendo importantes. Gulf Stream no elimina la competencia por las tarifas.

DeFi: El tiempo de ejecución de Solana puede procesar transacciones que no entran en conflicto en paralelo, mientras que las tarifas generalmente bajas pueden admitir interacciones frecuentes. La latencia y el coste reales del intercambio incluyen el enrutamiento, el deslizamiento, las tarifas de prioridad, las transacciones fallidas, el cómputo del programa y las condiciones del mercado. Gulf Stream no elimina el MEV ni el riesgo de front-running.

GameFi y microtransacciones: Las tarifas generalmente bajas pueden admitir acciones de poco valor, pero los costes integrales de la aplicación y las transacciones fallidas siguen siendo importantes. Los costes de L1 y L2 de Ethereum deben compararse por separado utilizando datos actuales.

Pagos: Las aplicaciones de pago basadas en Solana pueden aspirar a un Feedback rápido del usuario, pero la aprobación de la billetera, la confirmación optimista, la finalidad arraigada, la tolerancia al riesgo del comerciante y las operaciones Off-Chain son etapas independientes. La autorización de una tarjeta de crédito no equivale a la liquidación en una blockchain pública.

Las mismas decisiones arquitectónicas que habilitan estas aplicaciones también conllevan compromisos documentados, que la siguiente sección examina sin rodeos.

Compromisos arquitectónicos: fiabilidad de la red, descentralización y velocidad

Solana ha experimentado interrupciones de red documentadas desde el lanzamiento de la Mainnet en marzo de 2020, causadas principalmente por inundaciones de transacciones generadas por bots que saturaron la memoria de los validadores y provocaron que estos perdieran el consenso.

Interrupciones de red

El diseño de alto rendimiento de Solana procesa las transacciones con un filtrado previo mínimo, lo que crea una vulnerabilidad específica. Cuando los bots inundan la red con transacciones de spam, los validadores pueden agotar la memoria disponible antes de que las transacciones lleguen a la etapa de filtrado, lo que provoca paradas en el consenso. Entre las principales interrupciones documentadas se incluyen una en septiembre de 2021 que duró aproximadamente 17 horas, provocada por un aumento en el volumen de transacciones de un evento IDO impulsado por un Bot, y una interrupción en enero de 2022 relacionada con un exceso de transacciones duplicadas de los validadores. En 2022 y 2023 se produjeron otras interrupciones más breves.

Solana Labs ha implementado dos mitigaciones arquitectónicas principales. El protocolo de red QUIC sustituyó al UDP para la ingesta de transacciones, proporcionando un control de flujo a nivel de conexión que limita cuántas transacciones puede enviar una única fuente. La Calidad de Servicio (QoS) ponderada por participación (Stake) prioriza el reenvío de transacciones de validadores con mayores participaciones en SOL, lo que hace que la inundación de spam por parte de fuentes con poco Stake sea menos efectiva. Los mercados de tarifas por unidades de cómputo crean una fricción económica contra el spam en volúmenes altos. La frecuencia de las interrupciones ha disminuido desde que se implementaron estas mitigaciones. El historial de interrupciones sigue siendo un factor de riesgo conocido para las aplicaciones que requieren una alta disponibilidad continua.

Preocupaciones sobre la centralización de los validadores

Los validadores de Solana requieren un hardware significativo. Según la documentación para validadores de la Fundación Solana,), la especificación recomendada incluye más de 128 GB de RAM, un SSD NVMe de alto rendimiento y conectividad a internet de banda ancha. Verifique las especificaciones actuales en el momento de la lectura, ya que los requisitos evolucionan con las actualizaciones del protocolo. Estos requisitos superan sustancialmente lo que los validadores de Ethereum necesitan para participar en el consenso PoS.

La barrera del hardware reduce el grupo potencial de validadores a operadores con una inversión de capital significativa. Los requisitos de hardware cumplen un propósito de ingeniería real: son de lo que dependen los objetivos actuales de rendimiento. También son una barrera genuina para una participación más amplia de los validadores. La Fundación Solana financia programas de descentralización de validadores y subvenciones para operadores más pequeños, pero la tensión entre los objetivos de rendimiento y los costes de hardware es una característica estructural del diseño, no un problema de política incidental.

Posicionamiento en el Trilema Blockchain

Solana no elimina el trilema blockchain. Su arquitectura representa una elección deliberada para priorizar la escalabilidad y mantener la seguridad, aceptando al mismo tiempo requisitos de hardware de validador más altos que crean presión sobre la descentralización. Ethereum prioriza la descentralización y la seguridad, abordando la escalabilidad a través de soluciones de Capa 2. Bitcoin prioriza la seguridad y la descentralización a costa de un rendimiento mínimo. Cada cadena ocupa una posición de ingeniería diferente dentro del mismo trilema, y no existe una configuración que maximice las tres dimensiones simultáneamente.

El historial de interrupciones, las presiones de centralización derivadas de los requisitos de hardware de los validadores y el posicionamiento en el trilema son aportaciones materiales para cualquier evaluación técnica rigurosa de la red Solana.

Solana vs. Ethereum vs. Bitcoin: comparación de arquitecturas

Los puntos de referencia históricos otorgan a Solana un perfil de rendimiento en la capa base más alto que el de la Mainnet de Ethereum, pero las mediciones no son comparables directamente. PoH proporciona una ordenación previa al consenso, Sealevel ejecuta tareas que no entran en conflicto de forma concurrente y el reenvío consciente del líder cambia el enrutamiento de las transacciones. Las cifras de ~65.000 y ~15–30 TPS citadas a menudo son puntos de referencia anticuados que dependen de la metodología, en lugar de propiedades permanentes de la red.

Modelo de ejecución y rendimiento

La EVM de Ethereum ejecuta los contratos secuencialmente, uno a la vez por bloque. Sealevel ejecuta miles de contratos que no entran en conflicto simultáneamente. Esta es la fuente principal de la brecha de TPS. Ethereum aborda el rendimiento mediante el escalado de Capa 2: los Rollups, incluidos Arbitrum y Optimism, procesan transacciones Off-Chain y liquidan lotes comprimidos en la capa base de Ethereum, aumentando sustancialmente la capacidad efectiva. El enfoque de Solana es el escalado horizontal en la Capa 1, evitando la complejidad adicional que las arquitecturas de Capa 2 introducen para desarrolladores y usuarios.

Comparación de plataformas para desarrolladores

El ecosistema de desarrolladores de Ethereum (Solidity, herramientas de EVM, protocolos DeFi establecidos con años de código auditado) es más grande y maduro que el de Solana. El modelo de Rust y Sealevel de Solana ofrece un mayor rendimiento en la capa base y tarifas más bajas, pero requiere comprender el modelo de cuentas y el requisito de declaración de acceso a cuentas, que no tiene un equivalente directo en Ethereum. Las aplicaciones donde el rendimiento y el coste de las tarifas son las limitaciones principales se adaptan bien a la arquitectura de Solana. Las aplicaciones que priorizan la compatibilidad con EVM, el grupo de talentos de desarrollo más amplio o la máxima descentralización de la capa base encajan mejor en la capa base de Ethereum o en su ecosistema L2.

Bitcoin como tercer punto de referencia

La arquitectura de Bitcoin prioriza la seguridad y la descentralización por encima del rendimiento. Con ~7 TPS y tiempos de bloque de 10 minutos, Bitcoin no está diseñado para aplicaciones de alta frecuencia. Su consenso de Prueba de Trabajo (Proof of Work) es computacionalmente intensivo por diseño: seguridad a través del gasto de energía en lugar de participar en staking económico. Tanto Solana como Ethereum ofrecen plataformas de contratos inteligentes programables que Bitcoin no admite de forma nativa. La posición arquitectónica de Bitcoin lo convierte en una categoría diferente de sistema en lugar de un competidor directo para el despliegue de aplicaciones.

Para la comparación completa de datos en las cinco dimensiones, consulte la tabla de puntos de referencia de rendimiento anterior.

Preguntas Frecuentes Sobre la Arquitectura de Solana

¿Qué es Proof of History en Solana?

Proof of History (PoH) es una cadena de hash SHA-256 secuencial que crea un registro verificable y ordenado cronológicamente de eventos antes de que se ejecute el consenso. Actúa como un reloj criptográfico compartido en la red de validadores, lo que permite a los validadores procesar transacciones sin intercambiar mensajes de marca de tiempo. PoH no es el Mecanismo de Consenso de Solana. Tower BFT se encarga del consenso, utilizando las marcas de tiempo de PoH como su referencia de tiempo compartida.

Los materiales históricos citan rangos teóricos y observados de TPS, pero el rendimiento en vivo depende de la mezcla de transacciones, la contabilidad de votos, el filtrado, la congestión, el software del validador y la metodología de medición. Utilice datos actuales de fuente primaria y defina qué se está contando.

Solana fue cofundada por Anatoly Yakovenko y Greg Fitzgerald. Yakovenko, un exingeniero de Qualcomm que trabajó en sistemas distribuidos y sincronización de relojes, describió por primera vez el mecanismo Proof of History en un whitepaper de noviembre de 2017. Solana Labs, la empresa de desarrollo con ánimo de lucro que cofundaron, lidera la ingeniería de protocolos. La Solana Foundation, una organización sin ánimo de lucro separada con sede en Ginebra, apoya el desarrollo del ecosistema.

Varias capas arquitectónicas contribuyen a la diferencia de rendimiento. PoH proporciona una referencia de ordenamiento verificable que puede reducir parte de la sobrecarga de coordinación, Sealevel ejecuta trabajo no conflictivo en paralelo y el reenvío consciente del líder cambia la forma en que las transacciones llegan a los validadores programados. Las cifras históricas de TPS dependen de la metodología y no deben tratarse como propiedades permanentes de ninguna de las redes.

Los materiales iniciales agrupan la arquitectura en Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak y Archivers. Este es un marco explicativo histórico, no una prueba de que cada elemento nombrado —especialmente Archivers— siga siendo un subsistema implementado por separado hoy en día.

Tower BFT es el mecanismo de votación ponderada por stake y elección de fork de Solana, construido en torno a las ranuras de PoH y el aumento de los bloqueos de votos. No asuma una implementación particular de slashing automático ni cuente los validadores por igual: los umbrales bizantinos se ponderan por stake, y las suposiciones de seguridad y viabilidad requieren un tratamiento más preciso.

Gulf Stream describe el reenvío de transacciones consciente del líder en lugar de una mempool global convencional. Puede reducir parte de la cola, pero no elimina la competencia por tarifas prioritarias, la congestión, las caídas de transacciones, el MEV o el riesgo de front-running. El comportamiento de red actual debe verificarse en la documentación de implementación.

Sealevel es el entorno de ejecución de contratos inteligentes paralelos de Solana. A diferencia de la EVM de Ethereum, que ejecuta contratos uno a la vez, Sealevel ejecuta miles de programas no conflictivos simultáneamente en los núcleos de CPU y GPU disponibles. El paralelismo se habilita exigiendo que cada transacción declare las cuentas a las que accederá en el momento de la presentación, de modo que el entorno de ejecución pueda identificar operaciones no conflictivas y programarlas de forma concurrente.

Sí. Solana utiliza Proof of Stake (PoS) como su capa de seguridad económica. Los validadores participan en staking con SOL como garantía y se enfrentan a penalizaciones de slashing por comportamiento deshonesto o inconsistente. Proof of History es un mecanismo de cronometraje criptográfico separado que hace que el Mecanismo de Consenso PoS de Solana sea más rápido. PoH no reemplaza a PoS; mejora la eficiencia de Tower BFT, el Mecanismo de Consenso basado en PoS.

Las interrupciones documentadas de Solana han sido causadas principalmente por inundaciones de transacciones generadas por bots que sobrecargan la memoria de los validadores, lo que provoca que los validadores caigan fuera del consenso. El diseño de alto rendimiento de la arquitectura procesa transacciones con un filtrado mínimo previo, lo que crea una vulnerabilidad a ataques de spam a gran volumen. Solana Labs implementó la red QUIC y QoS ponderada por stake como mitigaciones arquitectónicas que redujeron la frecuencia de las interrupciones. Consulte la sección de compensaciones arquitectónicas para conocer eventos documentados específicos.

Las diferencias arquitectónicas fundamentales son el modelo de ejecución (Sealevel paralelo frente a EVM secuencial), el enrutamiento de transacciones (Gulf Stream sin mempool frente a mempool global), el lenguaje de programación (Rust frente a Solidity) y el rendimiento de la capa base (~65 000 TPS teóricos frente a ~15-30 TPS). Las blockchains Bot utilizan Proof of Stake para la seguridad económica. El mayor ecosistema de desarrolladores de Ethereum y las Options de Capa 2 sirven bien a los proyectos compatibles con EVM; el rendimiento de la capa base y la estructura de tarifas de Solana sirven a las aplicaciones donde el volumen de transacciones y el coste son las principales restricciones.

No existe una solución completa al Trilema Blockchain; Solana realiza compensaciones en su lugar. La arquitectura prioriza la escalabilidad y mantiene la seguridad, al tiempo que acepta requisitos de hardware de validador más elevados que generan una presión medible sobre la descentralización. Esta es una Posición de ingeniería específica dentro del trilema, no una eliminación del mismo. La Posición de Solana es inusualmente agresiva en el eje de la escalabilidad en comparación con otras blockchains importantes.

Los programas On-Chain de Solana se escriben principalmente en Rust, se compilan a bytecode Berkeley Packet Filter (BPF) y se ejecutan en el entorno de ejecución Sealevel. También se admiten C y C++. El framework Anchor, un kit de herramientas basado en Rust que proporciona macros y abstracciones que simplifican patrones de programas comunes, es el kit de herramientas de desarrollo más utilizado. Para conocer las herramientas actuales del ecosistema, consulte la documentación para desarrolladores de Solana.

El coste de una transacción de Solana incluye una tarifa base y puede incluir costes de priorización y relacionados con la computación. El valor en USD cambia con el precio de SOL, mientras que la congestión y el comportamiento de la aplicación afectan al coste de ejecución total. Gulf Stream no elimina la competencia de tarifas.

En el momento de escribir estas líneas, Solana tiene más de 1.000 validadores activos. Verifique el recuento y la distribución actuales a través de las estadísticas de validadores de la Solana Foundation.). Los validadores requieren una inversión significativa en hardware, incluyendo más de 128 GB de RAM y SSD NVMe de alto rendimiento, lo que crea una barrera de entrada más alta que en la mayoría de las otras cadenas Proof of Stake y es la fuente principal de preocupaciones de descentralización continuas.

Explore SOL en Bybit

Los lectores pueden consultar la información actual del mercado de SOL) o el mercado spot SOL/USDT.). Estos enlaces proporcionan acceso al mercado y no demuestran que Solana, una billetera o un protocolo de Tercero sea adecuado para todos los lectores.

La arquitectura de Solana combina varias decisiones de diseño interconectadas. PoH proporciona una referencia de ordenamiento, Sealevel paraleliza la ejecución no conflictiva, el reenvío consciente del líder cambia el enrutamiento de transacciones, y pipelining, Cloudbreak y Turbine abordan el procesamiento, el almacenamiento y la propagación. El historial de interrupciones documentado y los requisitos de recursos de los validadores pertenecen a la misma evaluación técnica que los beneficios de rendimiento.

Para los desarrolladores que eligen una plataforma, Solana ofrece el mayor rendimiento de capa base y unas de las comisiones de transacción más bajas de cualquier blockchain de producción importante. El modelo de cuentas y el requisito de Rust añaden complejidad de diseño en comparación con la EVM de Ethereum. El requisito de declaración de acceso a cuentas cambia la forma en que se estructura el estado del programa, y el modelo de ejecución paralela recompensa los diseños de programas que minimizan el estado compartido.

Para los investigadores, el Prueba de Historia: Un Reloj para Blockchain original de Anatoly Yakovenko (noviembre de 2017) sigue siendo la fuente primaria fundamental para el diseño de PoH. Solana Labs mantiene la documentación arquitectónica actual en docs.solana.com. La Solana Foundation publica estadísticas de la red de validadores en solana.org/validators. Los datos de red en tiempo real están disponibles a través de Solana Beach.

Con una comprensión de los ocho pilares arquitectónicos de Solana, ahora está equipado para evaluar las afirmaciones de rendimiento de la red, sus compensaciones y su trayectoria a largo plazo en sus propios términos.

Aviso legal: Este artículo tiene fines meramente informativos y educativos. No constituye asesoramiento financiero, asesoramiento de inversión ni una recomendación para comprar, vender o mantener SOL o cualquier otra criptomoneda. Todas las cifras de rendimiento están sujetas a cambios. Consulte a un asesor financiero cualificado antes de tomar decisiones de inversión.

Lectura relacionada

• Prueba de Historia de Solana
• Mecanismo de Consenso de Solana
• SolanaVM
• Velocidad de Solana