Análisis de la arquitectura técnica y el desarrollo del ecosistema de Solana

Solana es una plataforma de blockchain de alto rendimiento que utiliza una arquitectura tecnológica única para lograr un alto rendimiento y baja latencia. Su tecnología central incluye el algoritmo Proof of History (POH) que asegura el orden de las transacciones y un reloj global, el Programa de Rotación de Líderes y el mecanismo de consenso Tower BFT que aumentan la velocidad de generación de bloques. El mecanismo Turbine optimiza la propagación de grandes bloques a través de la codificación Reed-solomon. La Máquina Virtual de Solana (SVM) y el motor de ejecución paralelo Sealevel aceleran la velocidad de ejecución de las transacciones. Todo esto es parte del diseño arquitectónico de Solana para lograr un alto rendimiento, pero también ha traído algunos problemas, como interrupciones en la red, fallos en las transacciones, problemas de MEV, un crecimiento excesivo del estado y problemas de centralización.

El ecosistema de Solana se está desarrollando rápidamente, con indicadores de datos que han crecido rápidamente en la primera mitad del año, especialmente en los campos de DeFi, infraestructura, GameFi/NFT, DePin/IA y aplicaciones para consumidores. La alta TPS de Solana y su estrategia orientada a aplicaciones para consumidores, junto con un entorno ecológico con un efecto de marca relativamente débil, brindan ricas oportunidades de emprendimiento para emprendedores y desarrolladores. En el ámbito de las aplicaciones para consumidores, Solana ha demostrado su visión para impulsar la aplicación de la tecnología blockchain en campos más amplios. Al apoyar iniciativas como Solana Mobile y construir SDKs específicamente para aplicaciones de consumidores, Solana se está esforzando por integrar la tecnología blockchain en aplicaciones diarias, aumentando así la aceptación y conveniencia para los usuarios.

Solana, aunque ha ganado una participación de mercado significativa en la industria blockchain gracias a su alta capacidad de procesamiento y bajos costos de transacción, también enfrenta una intensa competencia de otras cadenas públicas emergentes. Base, como un posible competidor en el ecosistema EVM, está viendo un rápido crecimiento en el número de direcciones activas en su cadena. Al mismo tiempo, aunque el TVL total de Solana en el ámbito DeFi ha alcanzado un nuevo máximo histórico de (, competidores como Base también están rápidamente tomando participación de mercado, y la financiación del ecosistema de Base también superó por primera vez a Solana en el segundo trimestre.

A pesar de que Solana ha logrado ciertos avances en términos de tecnología y aceptación en el mercado, necesita innovar y mejorar constantemente para enfrentar los desafíos de competidores como Base. En particular, en áreas como mejorar la estabilidad de la red, reducir la tasa de fallos en las transacciones, abordar el problema de MEV y ralentizar la velocidad de crecimiento del estado, Solana debe optimizar continuamente su arquitectura técnica y sus protocolos de red para mantener su posición de liderazgo en la industria blockchain.

Arquitectura técnica

) algoritmo POH

POH###Proof of History( es una técnica que determina el tiempo global, no es un mecanismo de consenso, sino un algoritmo que determina el orden de las transacciones. La tecnología POH proviene de la tecnología criptográfica básica SHA256. SHA256 se utiliza generalmente para calcular la integridad de los datos, dado un input X, hay y solo hay una salida única Y, por lo tanto, cualquier cambio en X resultará en un Y completamente diferente.

En la secuencia POH de Solana, se puede garantizar la integridad de toda la secuencia aplicando el algoritmo sha256, lo que a su vez determina la integridad de las transacciones dentro de ella. Por ejemplo, si empaquetamos las transacciones en un bloque y generamos el valor hash sha256 correspondiente, entonces las transacciones dentro de ese bloque se determinan, cualquier cambio causará una modificación en el valor hash. Luego, este hash del bloque se utilizará como parte del X en la siguiente función sha256, y se añadirá el hash del siguiente bloque, de modo que tanto el bloque anterior como el siguiente quedan determinados; cualquier cambio resultará en un nuevo Y diferente.

En el diagrama de la arquitectura de flujo de transacciones de Solana, se describe el proceso de transacciones bajo el mecanismo POH. En un mecanismo de rotación de líderes llamado Leader Rotation Schedule, se genera un nodo líder entre todos los validadores de la cadena. Este nodo líder recoge las transacciones, las ordena y las ejecuta, generando una secuencia POH, y luego genera un bloque que se propagará a otros nodos.

![¿Volverá a florecer la arquitectura técnica de Solana?])panews/images/R5AS3PT13L.webp(

Para evitar que el nodo Leader sufra un fallo de punto único, se introdujo un límite de tiempo. En Solana, las unidades de tiempo se dividen en epochs, cada epoch contiene 432,000 slots), cada slot dura 400 ms. En cada slot, el sistema de rotación asigna un nodo Leader dentro de cada slot, el nodo Leader debe publicar el bloque(400ms) dentro del tiempo asignado de ese slot, de lo contrario, se saltará este slot y se volverá a elegir el nodo Leader para el siguiente slot.

En general, los nodos Leader que utilizan el mecanismo POH pueden confirmar todas las transacciones históricas. La unidad de tiempo básica de Solana es el Slot, y el nodo Leader necesita transmitir el bloque dentro de un slot. Los usuarios envían transacciones al Leader a través de nodos RPC, el nodo Leader empaqueta y ordena las transacciones, luego ejecuta la generación del bloque, el bloque se difunde a otros validadores, quienes necesitan alcanzar un consenso a través de un mecanismo, logrando consenso sobre las transacciones dentro del bloque y su orden, el consenso utilizado es el mecanismo de consenso Tower BFT.

( Mecanismo de consenso BFT de Tower

El protocolo de consenso Tower BFT proviene del algoritmo de consenso BFT, que es una implementación ingenieril concreta de este. Este algoritmo sigue estando relacionado con el algoritmo POH. Al votar sobre un bloque, si el voto del validador es en sí una transacción, entonces el hash del bloque formado por la transacción del usuario y la del validador también puede servir como prueba histórica, donde los detalles de la transacción de cada usuario y los detalles del voto del validador pueden ser confirmados de manera única.

![¿Volverá a florecer la arquitectura técnica de Solana: ¿una segunda primavera?])panews/images/90Jj8P8FH5.webp###

En el algoritmo Tower BFT se establece que si todos los validadores votan por el bloque y más de 2/3 de los validadores votan a favor, entonces este bloque puede ser confirmado. La ventaja de este mecanismo es que ahorra una gran cantidad de memoria, ya que solo se necesita votar sobre la secuencia de hash para confirmar el bloque. Sin embargo, en los mecanismos de consenso tradicionales, generalmente se emplea la inundación de bloques, donde un validador que recibe un bloque lo envía a los validadores circundantes, lo que provoca una gran redundancia en la red, ya que un validador recibe el mismo bloque más de una vez.

En Solana, debido a la gran cantidad de transacciones de votación de validadores y a la eficiencia derivada de la centralización de los nodos líderes, así como al tiempo de Slot de 400 ms, esto ha llevado a que el tamaño total de los bloques y la frecuencia de generación de bloques sean particularmente altos. Los bloques grandes, al propagarse, también ejercen una gran presión sobre la red. Solana utiliza el mecanismo Turbine para resolver el problema de propagación de bloques grandes.

( Turbine

Los nodos Leader dividen los bloques en subbloques llamados shreds a través de un proceso denominado Sharding, cuyo tamaño específico es la unidad máxima de transmisión MTU), es decir, la cantidad máxima de datos que se puede enviar de un nodo a otro sin necesidad de dividirlo en unidades más pequeñas es ###. Luego, se garantiza la integridad y disponibilidad de los datos mediante el uso de un esquema de códigos de borrado de Reed-Solomon.

Al dividir el bloque en cuatro Data Shreds, y luego para prevenir la pérdida y daño de datos durante la transmisión, se utiliza la codificación Reed-solomon para codificar los cuatro paquetes en ocho paquetes, este esquema puede tolerar hasta un 50% de tasa de pérdida. En las pruebas reales, la tasa de pérdida de Solana es aproximadamente del 15%, por lo que este esquema se adapta bien a la arquitectura actual de Solana.

En la transmisión de datos a nivel de base, generalmente se considera el uso de los protocolos UDP/TCP. Dado que Solana tiene una alta tolerancia a la tasa de pérdida de paquetes, se utiliza el protocolo UDP para la transmisión. Su desventaja es que no retransmite en caso de pérdida de paquetes, pero su ventaja es una mayor velocidad de transmisión. Por el contrario, el protocolo TCP retransmite múltiples veces en caso de pérdida de paquetes, lo que reduce significativamente la velocidad de transmisión y el rendimiento. Con Reed-Solomon, este esquema puede aumentar significativamente el rendimiento de Solana, logrando en un entorno real un aumento de hasta 9 veces.

Después de fragmentar los datos con Turbine, se utiliza un mecanismo de propagación en múltiples capas para llevar a cabo la difusión. El nodo líder entregará el bloque a cualquier validador de bloques antes de que termine cada Slot, y luego ese validador fragmentará el bloque en Shreds y generará un código de corrección de errores. Después, el validador iniciará la propagación de Turbine. Primero se propagará hasta el nodo raíz, y luego ese nodo raíz determinará qué validadores se encuentran en qué capa. El proceso es el siguiente:

1. Crear una lista de nodos: el nodo raíz recopilará todos los validadores activos en una lista y luego los ordenará según la cantidad de SOL apostados en la red, (, que es el derecho de cada validador, ). Los que tengan un mayor peso estarán en la primera capa, y así sucesivamente.

2. Agrupación de nodos: luego, cada validador en la primera capa también creará su propia lista de nodos para construir su propia primera capa.

3. Formación de capas: Divida los nodos en capas desde la parte superior de la lista; al determinar dos valores, profundidad y amplitud, se puede definir la forma general del árbol. Este parámetro afectará la tasa de propagación de los shreds.

Los nodos con una alta proporción de derechos ocupan un nivel superior en la jerarquía, lo que les permite obtener shreds completos con anticipación. En este momento, pueden recuperar el bloque completo, mientras que los nodos en niveles inferiores, debido a la pérdida en la transmisión, tendrán una menor probabilidad de obtener shreds completos. Si estos shreds no son suficientes para construir fragmentos completos, se pedirá al líder que retransmita directamente. En este caso, la transmisión de datos se llevará a cabo hacia el interior del árbol, y los nodos de la primera capa ya habrán construido la confirmación del bloque completo, lo que significa que cuanto más tiempo pase después de que los validadores de niveles inferiores completen la construcción del bloque, más tiempo habrá para votar.

La idea de este mecanismo es similar a la mecánica de un solo nodo del nodo líder. Durante el proceso de propagación de bloques, también hay algunos nodos prioritarios; estos nodos obtienen primero los fragmentos (shreds) para formar bloques completos y alcanzar el proceso de consenso de votación. Llevar la redundancia a un nivel más profundo puede acelerar significativamente la Finalidad y maximizar el rendimiento y la eficiencia. Porque en realidad, las primeras capas pueden representar ya 2/3 de los nodos, por lo que la votación de los nodos posteriores se vuelve irrelevante.

( SVM

Solana puede procesar miles de transacciones por segundo, principalmente debido a su mecanismo POH, consenso Tower BFT y mecanismo de propagación de datos Turbine. Sin embargo, SVM, como máquina virtual para la transición de estado, si el nodo líder es lento en la ejecución de transacciones, la velocidad de procesamiento de SVM reducirá el rendimiento de todo el sistema. Por lo tanto, para SVM, Solana propuso el motor de ejecución paralelo Sealevel para acelerar la velocidad de ejecución de las transacciones.

En SVM, las instrucciones constan de 4 partes, que incluyen el ID del programa, las instrucciones del programa y la lista de cuentas que leen/escriben datos. Al determinar si la cuenta actual está en estado de lectura o escritura y si las operaciones que realizan cambios de estado entran en conflicto, se permite la paralelización de las instrucciones de transacción de la cuenta que no tienen conflictos de estado, cada instrucción se representa con el ID del Programa. Y esta es también una de las razones por las que los requisitos para los validadores de Solana son tan altos, ya que se requiere que la GPU/CPU del validador soporte SIMD) instrucciones múltiples de un solo dato### y capacidades de AVX de extensión de vector avanzado.

Desarrollo ecológico

En el actual proceso de desarrollo del ecosistema de Solana, se está haciendo cada vez más hincapié en la utilidad práctica, como Blinks y Actions, e incluso Solana Mobile. Además, la dirección del desarrollo de aplicaciones respaldadas oficialmente también tiende más hacia aplicaciones para consumidores, en lugar de una competencia infinita en infraestructura. Con el rendimiento actual de Solana siendo suficiente, hay una mayor diversidad de tipos de aplicaciones. En el caso de Ethereum, debido a su bajo TPS, el ecosistema de Ethereum sigue centrado en infraestructura y tecnologías de escalado. Cuando la infraestructura no puede soportar aplicaciones, no se pueden construir aplicaciones para consumidores, lo que ha llevado a un estado de desequilibrio en el que hay una inversión excesiva en infraestructura, pero una inversión insuficiente en aplicaciones.

( DeFi

En los protocolos DeFi en Solana, hay una gran cantidad de proyectos sin emisión de tokens, incluyendo Kamino), Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, etc. Debido a la atmósfera de unidad en el ecosistema de Solana, generalmente un proyecto evitará la fecha de emisión de tokens de otro proyecto, para atraer suficiente atención del mercado.

Actualmente, la competencia en todo el DEX es intensa, y su líder ha experimentado múltiples migraciones, desde Raydium, Orca hasta ahora Jupiter como el principal.

Es importante señalar que aproximadamente el 50% de las transacciones en DEX son iniciadas por bots MEV, principalmente debido a sus bajas tarifas y a la actividad de trading de memes que fomentan la rentabilidad de MEV. Y esta también es una de las principales razones por las que los usuarios experimentan fallos frecuentes en transacciones de pico y caídas del sistema.

Los protocolos DeFi en Solana han experimentado un aumento explosivo en su TVL nominal en USD junto con el aumento del precio de SOL. La tendencia de aumento de su TVL aún no se ha detenido, formando una nueva ola de tendencia al alza.

![¿Volverá a florecer la arquitectura técnica de Solana?](