Reexaminando la arquitectura técnica de Solana: ¿está a punto de迎来第二春吗?

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 transacciones. Todo esto forma parte del diseño arquitectónico de Solana para lograr un alto rendimiento, pero también ha traído algunos problemas, como caídas de red, fallos en las transacciones, problemas de MEV, crecimiento excesivo del estado y problemas de centralización, que también abordamos en este artículo.

El ecosistema de Solana está en rápido desarrollo, con varios 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 de consumo. La alta TPS de Solana, su estrategia orientada a aplicaciones de consumo y un entorno ecológico con un efecto de marca relativamente débil ofrecen ricas oportunidades empresariales para emprendedores y desarrolladores. En el ámbito de aplicaciones de consumo, Solana ha demostrado su visión para impulsar la aplicación de la tecnología blockchain en áreas más amplias. Al apoyar iniciativas como Solana Mobile y construir SDK diseñados para aplicaciones de consumo, Solana se está comprometida a integrar la tecnología blockchain en aplicaciones cotidianas, mejorando así la aceptación y conveniencia para los usuarios. Por ejemplo, aplicaciones como Stepn ofrecen a los usuarios experiencias innovadoras de fitness y sociales al combinar blockchain y tecnología móvil. Aunque actualmente muchas aplicaciones de consumo 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 son, sin duda, un respaldo sólido para estos intentos innovadores. Con el desarrollo continuo de la tecnología y la madurez del mercado, Solana tiene el potencial de lograr más avances y casos de éxito en el ámbito de las aplicaciones de consumo.

A pesar de que Solana ha ganado una participación 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 posible competidor en el ecosistema EVM, está viendo un rápido crecimiento en el número de direcciones activas en su cadena, mientras que el TVL total de Solana en el ámbito DeFi, aunque ha alcanzado un nuevo máximo histórico de (, también está perdiendo rápidamente cuota de mercado frente a competidores como Base, cuyo financiamiento en el ecosistema ha superado 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 innovar y mejorar continuamente para hacer frente a 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 desacelerar el crecimiento del estado, Solana necesita optimizar continuamente su arquitectura técnica y protocolos de red para mantener su posición de liderazgo en la industria de blockchain.

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

Arquitectura técnica

Solana es conocida por su algoritmo POH, el mecanismo de consenso Tower BFT, así como por su red de transmisión de datos Trubine y la máquina virtual SVM, que proporcionan un alto TPS y rápida finalización. Vamos a presentar brevemente cómo funcionan sus diferentes componentes, cómo logran su objetivo de alto rendimiento en el diseño arquitectónico y las desventajas y problemas derivados que surgen bajo este diseño arquitectónico.

) 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 técnica POH proviene de la tecnología criptográfica básica SHA256. SHA256 se utiliza normalmente para calcular la integridad de los datos; dado un input X, hay y solo hay una salida Y única, 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 aplicando el 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 ese bloque quedan determinadas; cualquier modificación provocará un cambio en el valor hash. Luego, este hash del bloque se utilizará como parte de X en la siguiente función sha256, añadiendo el hash del siguiente bloque, de modo que tanto el bloque anterior como el siguiente quedan determinados, y cualquier modificación resultará en un nuevo Y diferente.

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

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

En el diagrama de arquitectura del 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. Este nodo líder recopila las transacciones, las ordena y ejecuta, generando una secuencia POH, y luego genera un bloque que se propaga a otros nodos.

Para evitar que se produzca un fallo puntual en el nodo líder, 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. En cada slot, el sistema de rotación asignará un nodo líder, y el nodo líder debe publicar el bloque(400ms) dentro del tiempo asignado para ese slot; de lo contrario, se saltará este slot y se reeleccionará el nodo líder para el siguiente slot.

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

( Mecanismo de consenso Tower BFT

El protocolo de consenso Tower BFT proviene del algoritmo de consenso BFT, siendo una implementación específica de este. Este algoritmo sigue estando relacionado con el algoritmo POH. Al votar sobre un bloque, si el voto del validador en sí mismo es 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?])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 considerarse confirmado. La ventaja de este mecanismo es que ahorra una gran cantidad de memoria, ya que solo es necesario 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 que recibe un bloque 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 traída por la centralización de los nodos líderes, así como al tiempo de Slot de 400 ms, esto ha llevado a un tamaño de bloque general y una frecuencia de bloques especialmente alta. Cuando los bloques grandes se propagan, también pueden causar una gran presión en la red. Solana utiliza el mecanismo Turbine para resolver el problema de la propagación de bloques grandes.

( Turbine

El nodo líder divide el bloque en subbloques llamados shreds a través de un proceso denominado Sharding, cuyo tamaño de especificación es la unidad máxima de transmisión MTU), que es la cantidad máxima de datos que se puede enviar de un nodo al siguiente sin necesidad de dividirlo en unidades más pequeñas, con ### como unidad. Luego, se garantiza la integridad y disponibilidad de los datos mediante el uso de un esquema de código de borrado de Reed-Solomon.

Al dividir el bloque en cuatro Data Shreds, y para evitar 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. 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 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 retransmite múltiples veces en caso de pérdida de paquetes, lo que reduce drásticamente la velocidad de transmisión y el rendimiento. Con Reed-Solomon, este esquema puede aumentar significativamente el rendimiento de Solana; en un entorno real, el rendimiento puede aumentar hasta 9 veces.

Después de que Turbine fragmenta los datos, utiliza un mecanismo de difusión multicapa para la propagación. El nodo líder entregará el bloque a cualquier validador de bloques antes de que termine cada Slot, luego ese validador fragmentará el bloque en Shreds y generará un código de corrección de errores. Ese validador luego iniciará la propagación de Turbine. Primero se propagará al 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 recopilará todos los validadores activos en una lista, y luego los ordenará según el capital de cada validador en la red, (, que es la cantidad de SOL en staking, ). Los de mayor peso estarán 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: Al dividir los nodos en capas desde la parte superior de la lista, se puede determinar la forma aproximada de todo el árbol al establecer dos valores: profundidad y amplitud. Este parámetro afectará la tasa 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 anticipadamente. En este momento, se puede recuperar el bloque completo, mientras que los nodos en niveles posteriores, 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 le pedirá al Líder que retransmita directamente. En este caso, la transmisión de datos se realizará 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 los niveles posteriores completen la construcción del bloque, más tiempo tomará la votación.

La idea de este mecanismo es similar a la de un nodo líder en un mecanismo de nodo único. Durante el proceso de propagación del bloque, también existen algunos nodos prioritarios que primero reciben 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 (Finality) 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, el consenso Tower BFT y el mecanismo de propagación de datos Turbine. Sin embargo, SVM, como máquina virtual de transición de estado, si el nodo líder es lento en la ejecución de transacciones, la velocidad de procesamiento de SVM hará que el rendimiento general del sistema disminuya. Por lo tanto, para SVM, Solana ha propuesto el motor de ejecución paralela Sealevel para acelerar la velocidad de ejecución de las transacciones.

En SVM, las instrucciones se componen de 4 partes, que incluyen el ID del programa, las instrucciones del programa y la lista de cuentas para leer/escribir datos. Al determinar si la cuenta actual está en estado de lectura o escritura y si las operaciones que realizan 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, cada instrucción se representa con el ID del programa. Y esta es también una de las razones por las cuales los requisitos para los validadores de Solana son tan altos, ya que se requiere que la GPU/CPU del validador pueda soportar SIMD) instrucciones de un solo dato múltiple### y capacidades de AVX de extensión vectorial avanzada.

Desarrollo ecológico