Segmentación de transacciones de Solana: pipeline de 4 etapas de la TPU

Esta guía técnica explica el pipeline de 4 etapas de la TPU para la segmentación de transacciones de Solana y cómo admite el procesamiento en paralelo.

Solana produce un nuevo bloque aproximadamente cada 400 milisegundos. La mayoría de las blockchains procesan las transacciones de una en una, esperando a que cada una se complete antes de comenzar la siguiente. Solana no lo hace.

La segmentación de transacciones de Solana es el método mediante el cual la Unidad de Procesamiento de Transacciones de Solana mueve las transacciones entrantes a través de cuatro etapas secuenciales: Fetch, SigVerify, Banking y Writing. Múltiples lotes de transacciones pasan por estas etapas simultáneamente, de modo que mientras un lote se escribe en el ledger, el siguiente ya se está validando y un tercero ya se está recuperando. Este procesamiento en paralelo es lo que permite a Solana (SOL), el activo nativo de la blockchain de Solana (el Ledger distribuido en el que se registran todas las transacciones), alcanzar cifras de rendimiento que superan con creces a la mayoría de las redes Layer-1.

Solana fue creada por Anatoly Yakovenko, un antiguo ingeniero de Qualcomm que publicó el Whitepaper de Proof of History en 2017, introduciendo el mecanismo de reloj criptográfico que hace posible la velocidad del pipeline. Solana Labs, la organización con sede en San Francisco que desarrolló el protocolo, implementó la segmentación como una característica central del cliente validador. El resultado es una red que se ha convertido en una plataforma líder para aplicaciones de finanzas descentralizadas (DeFi), incluidos exchanges descentralizados, protocolos de préstamo y mercados de derivados On-Chain que requieren una finalidad de transacción de menos de un segundo.

El ampliamente citado Trilema Blockchain de Blockchain sostiene que las blockchains pueden priorizar solo dos de tres propiedades: escalabilidad, seguridad y descentralización. La segmentación de transacciones de Solana es su respuesta arquitectónica a la dimensión de la escalabilidad. Este artículo cubre qué es la segmentación, cómo funcionan mecánicamente las cuatro etapas de la TPU, cómo Proof of History permite el pipeline, cómo Gulf Stream y Turbine envuelven la entrada y salida del pipeline, cómo Sealevel extiende el principio de segmentación a la ejecución de contratos inteligentes, cómo se compara Solana con Ethereum arquitectónicamente y dónde se encuentran las compensaciones y los límites documentados del pipeline.

Contenido

1. ¿Qué es la segmentación de transacciones de Solana? (Y por qué es importante para SOL)
2. Cómo funciona el pipeline de la TPU de Solana: las cuatro etapas explicadas
3. Proof of History: el reloj criptográfico que hace posible la segmentación
4. Gulf Stream: cómo entran las transacciones en el pipeline antes de que esté listo
5. La analogía del pipeline de la CPU: por qué la arquitectura de Solana resultará familiar a los ingenieros
6. Turbine: cómo llega la salida del pipeline a la red
7. Sealevel: segmentación extendida a la ejecución de contratos inteligentes
8. Solana frente a Ethereum: una comparativa de arquitectura de pipeline
9. Limitaciones, congestión y las compensaciones reales de la arquitectura de pipeline de Solana
10. Preguntas frecuentes sobre la segmentación de transacciones de Solana
11. La segmentación de transacciones de Solana y la tesis de inversión en SOL

¿Qué es la segmentación de transacciones de Solana? (Y por qué es importante para SOL)

La segmentación (pipelining) de transacciones de Solana es la técnica de dividir el procesamiento de transacciones en distintas etapas y ejecutar esas etapas de forma concurrente a través de múltiples lotes de transacciones, de modo que ninguna pieza del hardware del validador permanezca inactiva esperando a que termine otra etapa. Piense en ello como una línea de montaje de coches: diferentes vehículos se encuentran en diferentes estaciones simultáneamente, y la línea nunca se detiene para que un coche se complete totalmente antes de que entre el siguiente.

Solana tomó esta idea prestada de los procesadores de ordenador. Las CPU modernas logran un alto rendimiento mediante la segmentación a nivel de instrucción: mientras se ejecuta una instrucción, la siguiente se está decodificando y la posterior ya se está recuperando. Solana aplica la misma lógica a las transacciones a nivel de validador. El mapeo completo de las etapas de la CPU a las etapas de la TPU de Solana se trata en la sección de analogía de la CPU más abajo, pero el principio básico es idéntico: mantener cada etapa ocupada en todo momento.

La mayoría de las blockchains procesan las transacciones de forma secuencial, lo que significa que un validador debe completar todo el procesamiento de una transacción (o lote) antes de comenzar la siguiente. Este modelo secuencial crea un techo de rendimiento determinado enteramente por la rapidez con la que puede ejecutarse una sola cadena de operaciones. La segmentación rompe ese techo al ejecutar múltiples operaciones en paralelo a través de componentes de hardware dedicados, reduciendo la latencia de confirmación (el tiempo entre el envío de una transacción y la recepción de la finalización) sin requerir que cada etapa individual se ejecute más rápido.

El TPS teórico de Solana, según la documentación técnica de Solana, es de aproximadamente 65.000 transacciones por segundo. Esto representa el máximo del pipeline en condiciones ideales. El TPS real que no es de voto es sustancialmente menor, oscilando típicamente entre 2.000 y 4.000 TPS dependiendo de la carga de la red y la composición de las transacciones. Solana cuenta las transacciones de voto de los validadores por separado de las transacciones generadas por el usuario (no de voto); la cifra total de TPS, incluidos los votos, es mayor pero menos significativa como métrica de rendimiento de cara al usuario. A modo de comparación, Ethereum procesa aproximadamente entre 15 y 30 transacciones por segundo en Layer-1, y Bitcoin procesa aproximadamente 7 transacciones por segundo.

Estadísticas clave

El pipeline de la TPU de Solana produce un nuevo bloque cada ~400 ms, aproximadamente 30 veces más rápido que el tiempo de bloque de ~12 segundos de Ethereum. TPS teórico: ~65.000. TPS real sin voto: ~2.000-4.000 (varía según la carga de la red).

Nota sobre la metodología de TPS: La cifra de ~65.000 es el máximo teórico de la documentación técnica de Solana. El rendimiento real sin voto varía según las condiciones de la red. Las transacciones de voto se excluyen de la cifra de 2.000-4.000. Las cifras de Ethereum representan el rendimiento de Layer-1 y excluyen las soluciones de Layer-2.

El mecanismo que hace esto posible es la Transaction Processing Unit (TPU) de Solana, un pipeline de cuatro etapas que se ejecuta dentro de cada validador líder. La siguiente sección explica cómo funciona mecánicamente ese pipeline.

Cómo funciona el pipeline de la TPU de Solana: las cuatro etapas explicadas

El mecanismo detrás de la velocidad de Solana es un pipeline de cuatro etapas alojado en la Transaction Processing Unit (TPU), que se ejecuta dentro del validador líder para cada slot, procesando múltiples lotes de transacciones simultáneamente a través de hardware dedicado en cada etapa.

¿Qué es la Transaction Processing Unit (TPU)?

En Solana, la Transaction Processing Unit (TPU) es el motor de segmentación dentro de cada nodo validador que ejecuta físicamente el procesamiento de transacciones. Este es el término específico del dominio de Solana y no está relacionado con la Unidad de Procesamiento de Tensores (TPU) de Google utilizada en el aprendizaje automático.

La TPU se ejecuta exclusivamente en el validador líder durante cada franja de tiempo (slot) de aproximadamente 400 ms. Los validadores que no son líderes ejecutan la Unidad de Validación de Transacciones (TVU), que reproduce y verifica los bloques producidos por el líder. Solana determina qué validador actúa como líder a través de un programa de líderes determinista, publicado con antelación para cada época (aproximadamente de 2 a 3 días), que asigna las franjas de líder de cada validador en función de su peso en participación (staked weight). Este programa es lo que hace posible el enrutamiento previo de transacciones de Gulf Stream, como se analiza en la sección de Gulf Stream más adelante.

Para obtener detalles técnicos sobre la arquitectura de la TPU, consulte la documentación oficial de la TPU de Solana) y la documentación sobre el tiempo de las franjas de Solana.).

Las cuatro etapas del proceso (pipeline) de la TPU de Solana

El proceso de la TPU procesa las transacciones a través de cuatro etapas secuenciales, cada una gestionada por hardware dedicado, y cada una pasa su salida a la siguiente etapa mientras recibe simultáneamente nuevas entradas de la etapa anterior.

1. Fetch (Captura): La pila de red recibe paquetes de transacciones sin procesar a través de QUIC (un protocolo de transporte moderno que reemplazó la conexión UDP original para mejorar el control de la congestión). La etapa Fetch es el muelle de entrada del proceso. Extrae las transacciones del búfer precargado que Gulf Stream ya ha ejecutado (filled) antes de que comenzara la franja, y pasa los paquetes verificados a SigVerify.

2. SigVerify: La GPU verifica las firmas criptográficas en las transacciones entrantes. Cada transacción de Solana incluye una o más firmas digitales que deben validarse antes de que pueda ocurrir cualquier cambio de estado. La aceleración por GPU permite que miles de verificaciones de firmas se ejecuten en paralelo dentro de esta única etapa. SigVerify es el punto de control de autenticación: las transacciones que pasan se mueven a Banking; las transacciones que fallan se descartan.

3. Banking: La CPU aplica las transacciones validadas al estado del libro mayor, ejecutando los cargos y abonos de las cuentas y procesando los cambios de estado de los contratos inteligentes. Banking es el departamento de contabilidad del proceso y la etapa computacionalmente más intensiva. También es el principal cuello de botella bajo carga alta: cuando el volumen de transacciones supera la capacidad de procesamiento de Banking, el proceso comienza a descartar transacciones en lugar de ponerlas en cola.

4. Writing (Escritura): Las unidades SSD NVMe escriben las entradas confirmadas del libro mayor en el disco, y la etapa transmite los datos de los bloques resultantes al resto de la red a través de Turbine. Writing es la etapa de despacho y registro: una vez que se completa, el bloque existe On-Chain y comienza la propagación.

La mecánica central del proceso segmentado opera en las cuatro etapas simultáneamente. Mientras el lote N está en Banking, el lote N-1 ya está en Writing y el lote N+1 ya está en SigVerify. Ninguna etapa espera a que otra etapa termine su lote actual antes de comenzar el siguiente. Así es como el proceso logra un rendimiento paralelo: cada pieza de hardware está ocupada en cada momento de la franja.

[SE NECESITA DIAGRAMA: DIAGRAM-01] Proceso de cuatro etapas que muestra los lotes A, B, C, D en diferentes etapas simultáneamente. Lote A: Writing (SSD NVMe). Lote B: Banking (CPU). Lote C: SigVerify (GPU). Lote D: Fetch (red). Flechas que muestran la progresión de cada lote a través de las etapas Y la operación simultánea en las cuatro etapas.

¿Quién ejecuta el proceso? Los validadores y el programa de líderes

Los validadores de Solana son los operadores de nodos que ejecutan físicamente el proceso de la TPU. Cada validador es un servidor dedicado que ejecuta el software de Solana, responsable ya sea de producir bloques (si es el líder actual) o de verificar y reproducir bloques producidos por el líder (utilizando la TVU).

El programa de líderes asigna qué validador ejecuta la TPU para cada franja de aproximadamente 400 ms. El programa se calcula de forma determinista a partir del conjunto de validadores ponderados por su participación al inicio de cada época, por lo que los validadores conocen sus próximas franjas de líder con días de antelación. Esta previsibilidad permite que Gulf Stream enrute previamente las transacciones al próximo líder antes de que comience su franja, asegurando que el búfer de la etapa Fetch esté lleno cuando comience la franja.

Ejecutar el proceso de la TPU exige hardware de nivel empresarial: una GPU dedicada para la etapa SigVerify, una CPU con un alto número de núcleos para la etapa Banking, unidades SSD NVMe empresariales para la etapa Writing y redes de gran ancho de banda para la etapa Fetch. Estos requisitos son sustancialmente más altos que los umbrales de hardware de los validadores de Ethereum, lo que crea un compromiso de centralización cubierto en la sección de limitaciones. Para conocer las especificaciones actuales de hardware de los validadores, consulte la documentación de requisitos de los validadores de Solana.).

Proof of History: El reloj criptográfico que hace posible el procesamiento segmentado

Proof of History (PoH) es el mecanismo criptográfico que permite que el proceso de Solana se ejecute tan rápido como el hardware lo permita, sin requerir que los validadores se comuniquen entre sí para acordar el cronometraje de cada lote de transacciones antes de avanzar a la siguiente etapa.

El mecanismo funciona de la siguiente manera. PoH produce una secuencia continua de hashes SHA-256, donde cada hash toma el hash anterior como entrada. Debido a que el cómputo de SHA-256 toma una cantidad de tiempo medible y verificable, la secuencia de hashes resultante constituye una prueba criptográfica de que ha pasado una cantidad específica de tiempo entre dos eventos grabados en la cadena. Cada validador puede verificar esta secuencia de forma independiente sin contactar con otros validadores.

La conexión con el procesamiento segmentado es directa. Sin PoH, el proceso tendría que pausarse en cada etapa y esperar a que la red llegue a un consenso sobre el orden del lote de transacciones actual antes de que pudiera comenzar la siguiente etapa. Ese viaje de ida y vuelta de la comunicación entre nodos sería el factor de latencia dominante, lo que haría imposible tiempos de franja de 400 ms a escala de red. PoH elimina esta espera al proporcionar un reloj compartido y verificable que todos los validadores pueden consultar localmente. El proceso avanza basándose en el reloj PoH, no en los viajes de ida y vuelta de los mensajes de la red.

Anatoly Yakovenko introdujo Proof of History en el Whitepaper de Proof of History) publicado en 2017, basándose en su experiencia en sistemas distribuidos durante su tiempo en Qualcomm.

PoH no es Proof of Stake.

Proof of History NO es el Mecanismo de Consenso de Solana. Es un reloj criptográfico que secuencia eventos y prueba el tiempo transcurrido. Solana utiliza Proof of Stake (específicamente Tower BFT, su implementación de Practical Byzantine Fault Tolerance) para el consenso, el cual determina qué validadores son económicamente elegibles para participar y cuál lidera cada franja. PoH proporciona orden y tiempo. Proof of Stake proporciona seguridad económica y resistencia ante ataques Sybil. Estas son funciones distintas.

Para obtener una explicación completa de cómo funciona Proof of History, incluida su construcción criptográfica y su relación con el mecanismo de consenso de Solana, consulte nuestro [explicativo dedicado a Proof of History].

PoH proporciona el reloj. Gulf Stream asegura que la bandeja de entrada del proceso esté siempre llena.

Gulf Stream: Cómo entran las transacciones al proceso antes de que esté listo

Gulf Stream es el protocolo de reenvío de transacciones de Solana, y es lo que asegura que la etapa Fetch del proceso nunca esté inactiva esperando a que lleguen las transacciones. La mayoría de las blockchains mantienen las transacciones no confirmadas en una Mempool global, donde esperan a que cualquier validador las recoja. Solana no tiene una Mempool global. Gulf Stream reemplaza este modelo con un enrutamiento previo determinista.

El mecanismo funciona en cuatro pasos:

1. El Programa de Líderes de Solana publica, con antelación, qué validador liderará cada próxima franja de aproximadamente 400 ms.
2. Cuando un usuario o aplicación envía una transacción, Gulf Stream la enruta directamente al validador que liderará la siguiente franja relevante, no a un grupo compartido.
3. Para cuando comienza la franja de líder de ese validador, su búfer de la etapa Fetch ya está precargado con transacciones.
4. La etapa Fetch extrae del búfer precargado en lugar de esperar a que las transacciones lleguen durante la franja.

Este diseño sin mempool produce tres beneficios medibles: reduce la latencia de confirmación porque las transacciones pasan menos tiempo esperando, elimina la sobrecarga de memoria que las mempools globales imponen a cada validador y reduce sustancialmente los requisitos de memoria por validador.

La contrapartida es importante: como no hay un búfer de transacciones persistente, las transacciones que no se procesan rápidamente se descartan en lugar de ponerse en cola. Los usuarios reciben un Error de "transacción caducada" y deben reenviarla. Bajo alta carga de red, este comportamiento es uno de los mecanismos que contribuye a los eventos de congestión, como se discute en la sección de limitaciones.

Gulf Stream se conecta directamente a la etapa Fetch.

Gulf Stream pre-enruta las transacciones al próximo líder utilizando el Horario de Líderes determinista. Cuando se activa la etapa Fetch de la TPU de un validador, esta extrae de un búfer precargado, no de una mempool global. Es por esto que la tubería de Solana rara vez espera por entrada en la etapa Fetch bajo condiciones normales.

Si Gulf Stream es el mecanismo de entrada de la tubería, Turbine es el mecanismo de salida.

La Analogía de la Tubería de CPU: Por Qué la Arquitectura de Solana Debería Sonarle Familiar a los Ingenieros

La tubería de transacciones de Solana toma prestado el mismo principio arquitectónico que hace rápidas a las CPUs modernas: el pipelining a nivel de instrucción. Esto no es una metáfora. El diseño está arquitectónicamente inspirado en la misma técnica de rendimiento descrita en el texto fundamental de Patterson y Hennessy Computer Organization and Design.

Una tubería de instrucciones de CPU funciona de la siguiente manera. En lugar de esperar a que una instrucción complete todas las etapas de procesamiento antes de buscar la siguiente, una CPU divide la ejecución en etapas secuenciales (Fetch, Decode, Execute, Write-back) y ejecuta esas etapas simultáneamente en diferentes instrucciones. Mientras la instrucción N se está ejecutando, la instrucción N+1 se está decodificando y la instrucción N+2 ya se está buscando. El resultado es que el rendimiento aumenta en proporción al número de etapas de la tubería, sin requerir que ninguna etapa individual funcione más rápido.

La tubería de TPU de Solana aplica este mismo principio a las transacciones. El mapeo etapa por etapa es directo:

[SE NECESITA DIAGRAMA: DIAGRAMA-02]

Diagrama de comparación lado a lado. Lado izquierdo: tubería de instrucciones de CPU con etapas Fetch, Decode, Execute, Write-back y flechas onduladas que muestran el procesamiento concurrente de instrucciones. Lado derecho: tubería de TPU de Solana con etapas Fetch, SigVerify, Banking, Writing y flechas onduladas que muestran el procesamiento concurrente de lotes. Líneas de mapeo entre etapas análogas.

Dónde la analogía se mantiene: Ambas arquitecturas logran ganancias de rendimiento al mantener todas las etapas ocupadas simultáneamente. Ninguna espera a que un elemento se complete antes de comenzar el siguiente. Ambas procesan elementos en oleadas, con múltiples elementos en diferentes etapas en cualquier momento dado. La idea fundamental es idéntica: el procesamiento secuencial desperdicia capacidad de hardware; el paralelismo de tubería elimina ese desperdicio.

Dónde la analogía falla: Tres diferencias importantes distinguen la tubería de Solana de una tubería de CPU.

Primero, la tubería de Solana opera a través de componentes de hardware distribuidos conectados por una red, no dentro de un solo chip. Las condiciones de red afectan el rendimiento de la tubería de maneras que no tienen análogo en la CPU.

Segundo, los modos de fallo difieren. Los peligros de la tubería de CPU incluyen dependencias de datos (una instrucción necesita la salida de una instrucción previa que aún no se ha completado) y predicciones erróneas de bifurcación (el procesador buscó instrucciones por el camino equivocado). Los peligros de la tubería de Solana son diferentes en tipo: el spam de transacciones actúa como un peligro estructural al sobrecargar la etapa de Banking más allá de su capacidad de procesamiento, y la congestión de la red actúa como una condición de bloqueo que ralentiza las etapas Fetch y Writing. Estos son peligros externos, impulsados por la demanda, en lugar de peligros internos de dependencia de datos.

Tercero, la tubería de Solana no tiene un equivalente a la ejecución fuera de orden. El reloj Proof of History impone un estricto orden de transacciones dentro de cada lote, por lo que la tubería no puede reordenar transacciones para evitar conflictos de la misma manera que una CPU puede reordenar instrucciones para evitar peligros de datos.

Comprender esta analogía y sus límites es lo que separa el conocimiento superficial de la velocidad de Solana de la comprensión arquitectónica genuina.

Turbine: Cómo la Salida de la Tubería Llega a la Red

Turbine es el protocolo de propagación de bloques de Solana, y maneja lo que sucede después de que la etapa Writing de la tubería se completa. Si Gulf Stream asegura que la tubería siempre esté alimentada, Turbine asegura que la salida de la tubería llegue al resto de la red de la manera más eficiente posible.

Después de que la etapa Writing confirma un lote de transacciones confirmadas en el ledger, Turbine divide el bloque resultante en paquetes de datos más pequeños llamados shreds y los propaga a través de una red de validadores con estructura de árbol. En lugar de transmitir el bloque completo a todos los validadores simultáneamente (lo que requeriría un ancho de banda de enlace ascendente enorme del líder), Turbine distribuye la carga de propagación por la red. Cada validador en el árbol recibe un subconjunto de shreds y los reenvía a otros validadores más abajo en el árbol, similar en principio a cómo BitTorrent distribuye archivos al hacer que múltiples nodos compartan la carga de distribución. (Turbine usa un árbol estructurado en lugar de un enjambre peer-to-peer, lo cual es una distinción importante para la fiabilidad de la red).

El diseño compatible con pipelining es importante aquí: los shreds comienzan a propagarse al resto de la red mientras el validador líder ya está procesando el siguiente lote de transacciones a través de la tubería. La propagación de bloques y la producción de bloques se ejecutan de forma concurrente. La diseminación a nivel de red del bloque N no crea una pausa en la producción del bloque N+1.

El beneficio de ingeniería es que Solana logra un alto ancho de banda de bloques sin requerir un enlace ascendente de nivel empresarial en cada nodo validador. Solo el validador líder soporta la carga de producción completa; la propagación se distribuye por toda la red.

El envoltorio de entrada/salida alrededor de la tubería de TPU:

Gulf Stream: entrada de la tubería (pre-enruta transacciones al próximo líder antes de que comience el slot). Turbine: salida de la tubería (distribuye datos de bloque validados como shreds a través de una red de árboles de validadores). Juntos, aseguran que la tubería de TPU nunca esté inactiva en ninguno de sus extremos.

Turbine maneja la salida de la tubería a nivel de bloque. Sealevel extiende el principio de pipelining más profundamente, a la capa de ejecución de Contrato inteligente.

Sealevel: Pipelining Extendido a la Ejecución de Contratos Inteligentes

El pipelining de transacciones no se detiene en la TPU. Sealevel extiende el mismo principio de procesamiento paralelo a la ejecución de Contratos inteligentes, y es una de las ventajas arquitectónicas más infravaloradas de Solana.

Sealevel es el runtime paralelo de Contratos inteligentes de Solana. Permite que miles de Contratos inteligentes (llamados programas en la arquitectura de Solana, una distinción de la terminología de Ethereum que importa a los desarrolladores) se ejecuten simultáneamente en lugar de secuencialmente. El EVM de Ethereum (Ethereum Virtual Machine) procesa Contratos inteligentes en un solo hilo, lo que significa que solo un contrato puede ejecutarse a la vez por bloque. Sealevel utiliza todos los núcleos de CPU disponibles para ejecutar múltiples programas en paralelo.

El mecanismo depende del modelo de cuenta de Solana. Cada transacción de Solana debe declarar de antemano de qué cuentas leerá y en cuáles escribirá. Sealevel utiliza estas declaraciones para clasificar las transacciones en grupos que no se solapan: las transacciones que acceden a cuentas diferentes pueden ejecutarse simultáneamente sin riesgo de conflictos de estado, mientras que las transacciones que comparten cuentas deben procesarse secuencialmente para preservar la corrección.

Este requisito de declaración previa es una limitación de diseño que los desarrolladores de Solana deben tener en cuenta al diseñar programas. Los programas deben declarar previamente todas las cuentas a las que accederán, lo que difiere del modelo de acceso de estado más permisivo de Ethereum, donde el acceso al almacenamiento del contrato no se declara por adelantado.

El paralelismo con el procesamiento segmentado de la TPU es directo. Al igual que el proceso de la TPU mantiene ocupadas las cuatro etapas de hardware procesando diferentes lotes de transacciones en diferentes etapas simultáneamente, Sealevel mantiene ocupados todos los núcleos de CPU disponibles ejecutando programas no conflictivos simultáneamente. El principio de mantener todo el hardware ocupado en todo momento se aplica aquí en la capa de ejecución.

Para profundizar en cómo funcionan en la práctica las declaraciones de cuenta y el modelo de cuenta de Solana, consulte nuestro artículo [Explicación del modelo de cuenta de Solana].

Solana vs. Ethereum: Una comparativa de arquitectura segmentada

La diferencia de rendimiento entre Solana y Ethereum se remonta a una elección arquitectónica fundamental: el procesamiento segmentado en paralelo frente a la ejecución secuencial de transacciones.

La EVM de Ethereum procesa las transacciones en una cola de un solo hilo. Una transacción debe completarse antes de que comience la siguiente. Este diseño es intencionado: la ejecución secuencial simplifica la gestión del estado, hace que el comportamiento de los contratos inteligentes sea más fácil de razonar y permite a los validadores participar con hardware de consumo, produciendo un conjunto de validadores amplio y relativamente descentralizado. Ethereum cuenta actualmente con aproximadamente 900 000 validadores activos o más.

Por el contrario, el procesamiento segmentado de la TPU en paralelo de Solana procesa múltiples lotes de transacciones simultáneamente a través de cuatro etapas de hardware dedicadas. La GPU acelera la verificación de firmas. La CPU aplica cambios de estado simultáneamente en programas que no entran en conflicto a través de Sealevel. Los SSD NVMe gestionan las escrituras mientras que Turbine ejecuta la propagación en paralelo. Este diseño produce un rendimiento sustancialmente superior en la Capa 1, pero exige significativamente más hardware y crea un conjunto de validadores más concentrado de aproximadamente 2000 validadores activos.

Las cifras de rendimiento son concretas. El tiempo de bloque de Ethereum es de aproximadamente 12 segundos; el tiempo de slot de Solana es de aproximadamente 400 milisegundos. El TPS de la Capa 1 de Ethereum es de aproximadamente 15 a 30; el TPS real (que no son votos) de Solana es de aproximadamente 2000 a 4000, dependiendo de las condiciones de la red. (Bitcoin, como referencia de escala, procesa aproximadamente 7 transacciones por segundo). Las soluciones de Capa 2 de Ethereum, incluyendo Arbitrum y Optimism, aumentan drásticamente el rendimiento efectivo de Ethereum más allá de su base de Capa 1, un contexto importante al comparar cifras brutas de Capa 1.

Para obtener un desglose detallado de cómo se comparan estas arquitecturas en las dimensiones de inversión y desarrollo, consulte nuestra comparación completa de la arquitectura de Solana vs. Ethereum.

Ninguna arquitectura es categóricamente superior. Ambas representan compensaciones deliberadas dentro del ampliamente citado Trilema Blockchain. Ethereum sacrificó el rendimiento por la descentralización y un rico ecosistema de Capa 2. Solana sacrificó la descentralización por el rendimiento de la Capa 1. Qué compensación sirve mejor a una aplicación o tesis de inversión en particular depende de los requisitos específicos.

Limitaciones, congestión y las compensaciones honestas de la arquitectura segmentada de Solana

La arquitectura segmentada de Solana ofrece ventajas de rendimiento documentadas y conlleva compensaciones documentadas. Comprender ambas es necesario para cualquier evaluación seria de la red, ya sea para el desarrollo o para la inversión.

Cuando el procesamiento segmentado se ve desbordado: cómo funciona la congestión

La congestión del procesamiento segmentado ocurre cuando el volumen de transacciones supera la capacidad de procesamiento de la etapa Banking. La secuencia de eventos es específica. La etapa Banking se queda atrás respecto al volumen de transacciones entrantes. Debido a que el diseño Gulf Stream de Solana sin Mempool no mantiene un búfer de transacciones persistente, las transacciones que no se pueden procesar rápidamente se descartan en lugar de ponerse en cola. Los usuarios reciben errores de "transacción caducada" y deben volver a enviarlas. En niveles de congestión extremos, los validadores pueden quedar fuera del consenso porque el proceso no puede procesar las transacciones de voto lo suficientemente rápido en relación con el volumen total de transacciones, lo que provoca el estancamiento de la red.

Solana experimentó interrupciones importantes de la red en septiembre de 2021, enero de 2022 y mayo de 2022, entre otros períodos. Las causas no fueron uniformes. En algunos casos, el volumen excesivo de transacciones desbordó la capacidad de la etapa Banking. En otros, la causa fueron campañas coordinadas de spam de transacciones, errores de software o fallos de consenso no relacionados con los límites de rendimiento del proceso. Atribuir todas las interrupciones de Solana al procesamiento segmentado sería inexacto. Los límites de capacidad del proceso, cuando se superaron en condiciones específicas, contribuyeron a algunos eventos de interrupción, mientras que otras interrupciones tuvieron causas raíz independientes.

Para obtener un historial documentado de los eventos de la red de Solana y sus causas, consulte nuestro artículo [Interrupciones de la red de Solana: historia y lo que significan para los inversores].

Respuestas arquitectónicas de Solana a la congestión

Solana ha realizado varios cambios arquitectónicos desde 2022 para abordar la congestión del procesamiento segmentado:

• Adopción del protocolo QUIC: Solana reemplazó la conexión UDP original en la etapa Fetch por QUIC (un protocolo de transporte moderno que proporciona control de congestión y gestión de conexiones de los que carece UDP). QUIC permite que la etapa Fetch gestione la ingesta de transacciones de forma más inteligente bajo una carga alta, reduciendo la efectividad del spam de transacciones de bajo coste.
• Stake-Weighted Quality of Service (SWQoS): Solana introdujo la calidad de servicio ponderada por participación (SWQoS), que prioriza las transacciones reenviadas por validadores con mayor peso de participación. Esto reduce la capacidad de los actores con baja participación para inundar el proceso con transacciones basura que consumen la capacidad de la etapa Banking a expensas de las transacciones legítimas de los usuarios.
• Tarifas de prioridad: Los usuarios pueden añadir tarifas de prioridad a las transacciones, señalando su disposición a pagar por un procesamiento más rápido a través del proceso durante períodos de alta demanda.
• Firedancer: Firedancer, una implementación independiente del cliente validador desarrollada por Jump Cripto, está en desarrollo y tiene como objetivo aumentar sustancialmente el rendimiento del procesamiento segmentado y mejorar la resiliencia de la red al proporcionar un cliente alternativo que reduzca el riesgo de una única implementación.

La compensación de la centralización: altos requisitos de hardware

Los elevados requisitos de hardware para los validadores de Solana producen una compensación de centralización medible. La ejecución del pipeline de la TPU requiere una GPU empresarial para la etapa SigVerify, una CPU con un elevado número de núcleos para la etapa de Banking, unidades SSD NVMe empresariales para la etapa de Writing y redes de gran ancho de banda para Fetch y Turbine. Estas especificaciones crean barreras de coste significativas para los validadores domésticos.

El resultado es un conjunto de validadores más concentrado que el de Ethereum. Solana tiene aproximadamente 2.000 validadores activos; Ethereum tiene aproximadamente 900.000 o más (ambas cifras fluctúan y deben verificarse con los datos actuales de la red). Solana Labs y la Fundación Solana han reconocido esta compensación explícitamente: los requisitos de hardware son una consecuencia deliberada de la elección de un diseño que prioriza el rendimiento, lo que representa la Posición de Solana en el eje escalabilidad-descentralización del Trilema Blockchain. Si esta compensación es aceptable depende de lo que el evaluador priorice.

Preguntas frecuentes: Pipelining de transacciones en Solana

¿Qué es la Unidad de Procesamiento de Transacciones (TPU) de Solana?

La Unidad de Procesamiento de Transacciones (TPU) de Solana es el motor del pipeline dentro de un nodo validador que procesa físicamente las transacciones. Es un término propio de Solana, totalmente ajeno a la Unidad de Procesamiento de Tensores de Google utilizada en el aprendizaje automático. La TPU se ejecuta solo en el validador líder para cada slot de ~400 ms y opera a través de cuatro etapas: Fetch, SigVerify, Banking y Writing. Los validadores que no son líderes ejecutan la TVU (Unidad de Validación de Transacciones) para verificar y reproducir bloques en su lugar.

¿Qué es Proof of History y cómo se relaciona con el pipelining?

Proof of History (PoH) es un reloj criptográfico que produce una secuencia de hashes SHA-256 verificable y ordenada en el tiempo. El PoH permite el pipelining al eliminar la necesidad de que los validadores se comuniquen y acuerden el orden de las transacciones antes de avanzar en cada etapa del pipeline. Sin PoH, los retrasos en la comunicación entre nodos serían el cuello de botella dominante; con PoH, el pipeline avanza basándose en un reloj compartido y verificable localmente que no requiere comunicación de ida y vuelta por la red.

¿Qué es Gulf Stream en Solana?

Gulf Stream es el protocolo de reenvío de transacciones sin Mempool de Solana. En lugar de mantener las transacciones no confirmadas en un grupo global, Gulf Stream utiliza el Leader Schedule (programa de líderes) determinista para enrutar las transacciones directamente al próximo validador líder antes de que comience su slot. Cuando se activa la etapa Fetch del líder, este extrae las transacciones de un búfer precargado. Este enrutamiento previo es la razón por la que Solana puede mantener tiempos de slot de ~400 ms sin que la etapa Fetch tenga que esperar a que lleguen las transacciones.

¿Qué es Sealevel?

Sealevel es el entorno de ejecución de Contrato inteligente en paralelo de Solana. Permite que miles de contratos inteligentes (llamados programas en la arquitectura de Solana) se ejecuten simultáneamente al requerir que cada transacción declare de antemano qué cuentas leerá y escribirá. Sealevel identifica las transacciones que no se solapan y las ejecuta en paralelo en todos los núcleos de CPU disponibles, extendiendo el mismo principio de procesamiento paralelo desde el pipeline de la TPU hasta la capa de ejecución de los contratos inteligentes.

¿El pipelining de transacciones de Solana provoca caídas de la red?

La congestión del pipeline ha contribuido a algunas caídas de Solana, pero no a todas. Cuando el volumen de transacciones supera la capacidad de la etapa de Banking, el diseño sin Mempool hace que las transacciones se descarten en lugar de ponerse en cola y, en caso de congestión extrema, los validadores pueden perder el consenso. Solana también ha experimentado caídas causadas por errores de software, fallos de consenso y spam de transacciones coordinado no relacionado con los límites de rendimiento del pipeline. La adopción de QUIC y SWQoS ha reducido los fallos provocados por la congestión desde 2022.

¿Cuál es el TPS real de Solana?

El TPS teórico de Solana es de aproximadamente 65.000, lo que representa el máximo del pipeline en condiciones ideales según la documentación técnica de Solana. El TPS real que no es de voto suele oscilar entre 2.000 y 4.000, dependiendo de la carga de la red, la composición del tipo de transacción y el rendimiento del validador. Solana cuenta las transacciones de voto de los validadores por separado de las transacciones generadas por los usuarios; el total, incluyendo los votos, es mayor pero menos significativo como métrica de rendimiento de cara al usuario.

¿Cómo es Solana más rápida que Ethereum?

El pipeline de la TPU paralela de cuatro etapas de Solana procesa múltiples lotes de transacciones simultáneamente, mientras que la EVM de Ethereum procesa las transacciones de forma secuencial en un único hilo. El resultado: el tiempo de slot de Solana es de aproximadamente 400 milisegundos frente a los ~12 segundos de tiempo de bloque de Ethereum, y el TPS de Capa 1 de Solana es de aproximadamente 2.000 a 4.000 frente a los ~15 a 30 de Ethereum. Ambas arquitecturas representan decisiones de diseño deliberadas con diferentes compensaciones en el Trilema Blockchain.

¿Qué ocurre cuando el pipeline de Solana se congestiona?

Cuando el volumen de transacciones supera la capacidad de procesamiento de la etapa de Banking, Solana descarta las transacciones en lugar de ponerlas en cola, ya que el diseño Gulf Stream sin Mempool no mantiene un búfer persistente. Las transacciones afectadas devuelven un Error de "transacción caducada" y deben volver a enviarse. En caso de congestión grave, el procesamiento de las transacciones de voto puede retrasarse, lo que hace que los validadores pierdan el consenso. QUIC y SWQoS reducen el impacto de la congestión provocada por el spam, aunque el límite de capacidad subyacente sigue siendo una compensación arquitectónica conocida.

Explorar SOL en Bybit

Utiliza la página de precios de Solana para revisar los datos actuales del mercado de SOL, o accede al mercado de trading spot de SOL/USDT si el trading spot se ajusta a tus objetivos. La actividad de trading en la Bybit no es lo mismo que enviar una transacción On-Chain de Solana; es posible que se sigan aplicando comisiones de red al depositar o retirar SOL en la red Solana.

Los traders de Derivados experimentados también pueden revisar el mercado de Perpetuos SOLUSDT.. Los Derivados implican riesgos adicionales y no otorgan la propiedad de SOL spot.

El pipelining de transacciones de Solana y la tesis de inversión en SOL

El pipelining de transacciones de Solana es una auténtica innovación arquitectónica, no una afirmación de marketing. El pipeline de la TPU de cuatro etapas representa un enfoque de ingeniería coherente para el rendimiento de la Capa 1. El Proof of History proporciona el reloj criptográfico que permite que el pipeline avance sin retrasos por el consenso de la red. Gulf Stream precarga la entrada del pipeline. Turbine distribuye la salida del pipeline. Sealevel lleva el mismo principio de paralelismo hasta la ejecución del Contrato inteligente.

Para los inversores que poseen o evalúan Solana (SOL), entender el pipeline significa entender la base técnica de la diferenciación del rendimiento de Solana. La ventaja de velocidad de la arquitectura es estructural, no incidental. Deriva de decisiones de ingeniería específicas sobre cómo aplicar los principios de procesamiento paralelo en cada capa del ciclo de vida de la transacción.

Esas decisiones de ingeniería conllevan verdaderas compensaciones. Los eventos de congestión de 2021 y 2022 demostraron que el diseño sin Mempool y el techo de rendimiento de la etapa de Banking son limitaciones reales bajo condiciones de carga extrema o adversa. Los elevados requisitos de hardware para los validadores producen un conjunto de validadores más concentrado que el de Ethereum, lo que representa una Posición deliberada en el eje escalabilidad-descentralización del Trilema Blockchain. La evolución arquitectónica continua de Solana, incluida la adopción de QUIC, el despliegue de SWQoS y el cliente Firedancer en desarrollo por Jump Cripto, refleja un protocolo que trabaja activamente para elevar esos límites. Estos representan trayectorias de desarrollo, no problemas resueltos.

El rendimiento del pipeline de Solana la ha convertido en una Plataforma significativa para aplicaciones DeFi que requieren una finalidad de transacción inferior al segundo. Ethereum sigue siendo una opción arquitectónica válida con prioridades diferentes: una descentralización más amplia, un ecosistema de Capa 2 maduro y una base de desarrolladores más grande. Ambas redes ocupan posiciones distintas entre las blockchains de producción.

Aviso legal: Este artículo tiene únicamente fines educativos y no constituye asesoramiento de inversión, asesoramiento financiero, asesoramiento comercial ni ningún otro tipo de asesoramiento. Solana (SOL) es una criptomoneda. Las criptomonedas son activos altamente volátiles y conllevan un riesgo significativo de pérdida. Realiza siempre tu propia investigación y consulta a un asesor financiero cualificado antes de tomar decisiones de inversión.

Lecturas relacionadas de este grupo de temas:

• Solana vs. Ethereum: Comparativa completa de arquitectura: comparativa completa de arquitectura entre Solana y Ethereum