Análisis de la arquitectura técnica de Solana: ¿llega una segunda primavera?

Solana es una plataforma de blockchain de alto rendimiento que adopta una arquitectura técnica ú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 tasa de producción de bloques. El mecanismo Turbine optimiza la propagación de bloques grandes mediante codificación Reed-solomon. La Máquina Virtual de Solana (SVM) y el motor de ejecución paralela Sealevel aceleran la velocidad de ejecución de transacciones. Todo esto forma parte del diseño arquitectónico de alto rendimiento de Solana, pero también ha traído algunos problemas, como caídas de red, fallos en transacciones, problemas de MEV, crecimiento acelerado del estado y problemas de centralización.

El ecosistema de Solana se está desarrollando rápidamente, y todos los indicadores de datos han crecido rápidamente en la primera mitad del año, especialmente en las áreas de DeFi, infraestructura, GameFi/NFT, DePin/AI 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, ofrecen muchas oportunidades de emprendimiento para emprendedores y desarrolladores. En el ámbito de las aplicaciones para consumidores, Solana ha demostrado su visión de impulsar la aplicación de la tecnología blockchain en áreas más amplias. Al apoyar iniciativas como Solana Mobile y construir SDK específicamente para aplicaciones para consumidores, Solana se dedica a integrar la tecnología blockchain en aplicaciones cotidianas, mejorando así la aceptación y conveniencia para los usuarios. Por ejemplo, aplicaciones como Stepn combinan blockchain y tecnología móvil para ofrecer a los usuarios experiencias novedosas en fitness y redes sociales. Aunque actualmente muchas aplicaciones para consumidores aún están explorando los mejores modelos de negocio y posicionamiento en el mercado, la plataforma tecnológica y el soporte del ecosistema que ofrece Solana, sin duda, respaldan poderosamente estos intentos innovadores. Con el desarrollo adicional de la tecnología y la madurez del mercado, Solana espera lograr más avances y casos de éxito en el ámbito de las aplicaciones para consumidores.

Aunque Solana ha ganado una cuota de mercado significativa en la industria de blockchain debido 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 competidor potencial 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 del sector DeFi de Solana ha alcanzado un nuevo máximo histórico de (, competidores como Base también están rápidamente ocupando cuota de mercado, y la financiación del ecosistema Base también superó por primera vez a Solana en el segundo trimestre.

A pesar de que Solana ha logrado ciertos éxitos en términos de tecnología y aceptación en el mercado, necesita seguir innovando y mejorando 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 del MEV y ralentizar la velocidad de crecimiento del estado, Solana debe optimizar continuamente su arquitectura técnica y protocolos de red para mantener su posición de liderazgo en la industria blockchain.

Arquitectura técnica

Solana es conocida por su algoritmo POH, mecanismo de consenso Tower BFT, así como por su red de transmisión de datos Trubine y la máquina virtual SVM, que ofrecen un alto TPS y una rápida finalización. A continuación, presentaremos brevemente cómo funcionan cada uno de sus componentes, cómo logran su objetivo de alto rendimiento en el diseño de arquitectura y los inconvenientes y problemas derivados de este diseño de arquitectura.

![¿Volverá a florecer la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(

) algoritmo POH

POH###Prueba de Historia( es una técnica que determina el tiempo global, que no es un mecanismo de consenso, sino un algoritmo que determina el orden de las transacciones. La tecnología POH proviene de la base más fundamental de la criptografía, la tecnología 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 dará lugar a un Y completamente diferente.

En la secuencia POH de Solana, se puede garantizar la integridad de toda la secuencia mediante la aplicación del algoritmo sha256, lo que también asegura la integridad de las transacciones en ella. Por ejemplo, si empaquetamos las transacciones en un bloque y generamos el valor hash sha256 correspondiente, entonces las transacciones dentro de este bloque quedan determinadas; cualquier cambio resultará en una modificación del valor hash. Luego, este hash del bloque se usará como parte de X para la próxima función sha256, añadiendo el hash del siguiente bloque. Así, tanto el bloque anterior como el siguiente quedan determinados, y cualquier cambio dará lugar a un nuevo Y diferente.

Este es el significado central de su tecnología Proof of History, el hash del bloque anterior servirá como parte de la siguiente función sha256, similar a una cadena, el más reciente Y, siempre incluye la prueba de la historia.

![Revisando la arquitectura técnica de Solana: ¿está a punto de迎来第二春吗？])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

En el diagrama 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 selecciona un nodo líder entre todos los validadores de la cadena, el cual recopila transacciones, las ordena y ejecuta, generando una secuencia POH. Después, se genera un bloque que se propaga a otros nodos.

Para evitar que el nodo Leader tenga un punto único de falla, se ha introducido un límite de tiempo. En Solana, la unidad de tiempo se divide en epochs, cada epoch contiene 432,000 slots), cada slot dura 400 ms, y en cada slot, el sistema de rotación asigna un nodo Leader, el nodo Leader debe publicar el bloque( dentro del tiempo asignado del slot de 400 ms), de lo contrario, se saltará este slot y se volverá a elegir el nodo Leader del siguiente slot.

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

( Mecanismo de consenso Tower BFT

El protocolo de consenso Tower BFT proviene del algoritmo de consenso BFT, que es una implementación específica de ingeniería de este. Este algoritmo sigue estando relacionado con el algoritmo POH. Al votar sobre un bloque, si la votación del validador es en sí misma una transacción, entonces el hash del bloque formado por la transacción del usuario y la transacción del validador también puede servir como prueba histórica, permitiendo la confirmación única de los detalles de la transacción de cada usuario y los detalles de la votación del validador.

![¿Volverá a renacer la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.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 emiten un voto de aprobación, entonces el 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 utiliza la inundación de bloques, donde un validador recibe un bloque y lo envía a los validadores circundantes, lo que genera 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 que trae la centralización de los nodos líderes, así como al tiempo de Slot de 400 ms, se produce un tamaño de bloque general y una frecuencia de generación de bloques muy 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 la propagación de bloques grandes.

( Turbine

Los nodos líderes dividen el bloque en subbloques llamados shreds mediante un proceso conocido como Sharding, cuyo tamaño de especificación está basado en la unidad máxima de transmisión MTU), que es 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, ###. Luego, se garantiza la integridad y disponibilidad de los datos utilizando un esquema de código 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 una tasa de pérdida de hasta el 50%. En las pruebas reales, la tasa de pérdida de Solana es de aproximadamente el 15%, por lo que este esquema se adapta muy 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. Debido a 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 radica en una mayor velocidad de transmisión. Por el contrario, el protocolo TCP retransmitirá varias veces en caso de pérdida de paquetes, lo que reducirá drásticamente la velocidad de transmisión y la capacidad de procesamiento. Con Reed-Solomon, este esquema puede aumentar significativamente la capacidad de procesamiento de Solana; en un entorno real, la capacidad de procesamiento puede aumentar hasta 9 veces.

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

1. Crear lista de nodos: el nodo raíz compila todos los validadores activos en una lista y luego ordena a cada validador en la red según su participación (, es decir, la cantidad de SOL apostada ), donde los de mayor peso se ubicaron en la primera capa, y así sucesivamente.

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

3. Formación de capas: Dividir los nodos en capas desde la parte superior de la lista, al determinar los valores de profundidad y amplitud, se puede determinar la forma general del árbol, este parámetro afectará la velocidad de propagación de los shreds.

Los nodos con una alta proporción de derechos, al dividirse en niveles, estarán en un nivel superior, lo que les permitirá obtener los shreds completos antes. En este momento, podrán recuperar el bloque completo, mientras que los nodos en los niveles inferiores, debido a la pérdida de 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 dirigirá hacia el interior del árbol, y los nodos de la primera capa ya habrán construido la confirmación del bloque completo, por lo que el tiempo que tardan los validadores de niveles posteriores en votar después de completar la construcción del bloque será mayor.

La idea de este mecanismo es similar a la mecánica de un nodo líder único. Durante el proceso de propagación de bloques, también existen algunos nodos prioritarios, que son los que 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 finalización y maximizar el rendimiento y la eficiencia. Porque, de hecho, 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 el mecanismo de propagación de datos Turbine. Sin embargo, SVM, como máquina virtual para la transición de estados, si el nodo líder es lento en la ejecución de transacciones, disminuirá la capacidad de procesamiento 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.

![Revisando la arquitectura técnica de Solana: ¿está a punto de迎来第二春吗？])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp###

En SVM, las instrucciones se componen 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 van a realizar cambios de estado tienen conflictos, se puede permitir la paralelización de las instrucciones de transacción de la cuenta que no tienen conflictos de estado, donde cada instrucción se representa con el Program ID. Y esta es también una de las razones por las cuales los requisitos para los validadores de Solana son altos, ya que se requiere que el GPU/CPU de los validadores pueda soportar SIMD( instrucciones de un solo dato en múltiples datos) así como la capacidad de extensiones de vectores avanzados AVX.

Desarrollo ecológico

En el actual proceso de desarrollo del ecosistema de Solana, se está inclinando cada vez más hacia la utilidad práctica, como Blinks y Actions e incluso Solana Mobile, mientras que la dirección de desarrollo de las aplicaciones apoyadas oficialmente también se está orientando más hacia aplicaciones de consumo, en lugar de hacia la infraestructura.