Análisis de la arquitectura técnica de Solana: ¿se avecina una nueva primavera?

Solana es una plataforma de blockchain de alto rendimiento que utiliza 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 aumenta la tasa de producción de bloques. El mecanismo Turbine optimiza la propagación de grandes bloques mediante codificación Reed-solomon. La Solana Virtual Machine (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 alto rendimiento de Solana, pero también plantea algunos problemas, como caídas de red, fallos en las transacciones, problemas de MEV, 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 de manera explosiva 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, así como un entorno ecológico con un efecto de marca relativamente débil, ofrecen a emprendedores y desarrolladores abundantes oportunidades de emprendimiento. 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 un ámbito más amplio. Al apoyar iniciativas como Solana Mobile y construir SDK específicamente para aplicaciones de consumidores, Solana se está comprometido a integrar la tecnología blockchain en aplicaciones cotidianas, aumentando así la aceptación y comodidad para los usuarios. Por ejemplo, aplicaciones como Stepn combinan la tecnología blockchain y móvil para ofrecer a los usuarios experiencias novedosas de ejercicio y socialización. A pesar de que 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 apoyo del ecosistema que ofrece Solana sin duda brindan 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 para consumidores.

A pesar de que Solana ha ganado una cuota de mercado significativa en la industria de blockchain gracias a su alta capacidad de procesamiento y bajos costos de transacción, también enfrenta una feroz competencia de otras cadenas de bloques 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, mientras que el valor total bloqueado (TVL) en el ámbito DeFi de Solana, que alcanzó un nuevo récord histórico (TVL), también está siendo rápidamente superado por competidores como Base, cuyo volumen de financiamiento en el ecosistema 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 innovar y mejorar constantemente para hacer frente a los desafíos de competidores como Base. Especialmente en la mejora de la estabilidad de la red, la reducción de la tasa de fallos en las transacciones, la solución de problemas de MEV y la desaceleración de 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

Solana es conocida por su algoritmo POH, el mecanismo de consenso Tower BFT, así como por la red de transmisión de datos Trubine y la máquina virtual SVM, que ofrecen un alto TPS y una rápida finalización. Vamos a presentar brevemente cómo funcionan sus diferentes componentes, cómo alcanzan su objetivo de alto rendimiento en el diseño de arquitectura, así como 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 para determinar el orden de las transacciones. La tecnología POH proviene de la técnica criptográfica más básica, SHA256. SHA256 se utiliza generalmente para calcular la integridad de los datos; dado un input X, siempre hay una única salida Y, por lo tanto, cualquier cambio en X dará lugar a un Y completamente diferente.

En la secuencia POH de Solana, se puede asegurar la integridad de toda la secuencia mediante la aplicación del algoritmo sha256, lo que también garantiza 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 este bloque quedan determinadas; cualquier modificación causará un cambio en el valor hash. Luego, este hash del bloque servirá como parte de X para la siguiente función sha256, y se añadirá el hash del siguiente bloque. Así, tanto el bloque anterior como el siguiente quedan determinados, y cualquier cambio 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 contiene la prueba de la historia.

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

Para evitar que se produzca un punto único de fallo 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, el nodo líder debe publicar un bloque)400 ms( dentro del tiempo del slot dado, de lo contrario, se saltará este slot y se reelegirá al nodo líder del 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 los nodos Leader deben difundir bloques 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 y luego ejecuta la generación del bloque, que se propaga a otros validadores. Los validadores deben alcanzar un consenso a través de un mecanismo sobre las transacciones dentro del bloque y su orden, y el mecanismo de 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, que es una implementación de ingeniería 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í mismo 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, donde los detalles de la transacción de cada usuario y los detalles del voto del validador pueden ser confirmados de manera única.

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 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 que recibe el bloque lo envía a los validadores cercanos, lo que genera una gran redundancia en la red, ya que un validador recibe el mismo bloque más de una vez.

![Reanalizando la arquitectura técnica de Solana: ¿está a punto de recibir una segunda primavera?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

En Solana, debido a la gran cantidad de transacciones de votación de validadores y a la eficiencia que aporta la centralización de los nodos líderes junto con un tiempo de Slot de 400 ms, esto ha llevado a que el tamaño total del bloque y la frecuencia de creación de bloques sean especialmente 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

El nodo líder divide el bloque en subbloques llamados shreds a través de un proceso denominado Sharding, cuyo tamaño especificado es la unidad máxima de transmisión MTU###, que permite enviar la máxima cantidad de datos de un nodo al siguiente sin necesidad de dividirlo en unidades más pequeñas, siendo ( la unidad. Luego, se garantiza la integridad y disponibilidad de los datos mediante el uso del esquema de códigos de borrado 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 hasta un 50% de tasa de pérdida de paquetes. En las pruebas reales, la tasa de pérdida de paquetes de Solana es de aproximadamente el 15%, por lo que este esquema es muy compatible con la arquitectura actual de Solana.

En la transmisión de datos a nivel de base, generalmente se considera el uso de 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 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 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 propagación de múltiples capas para la difusión. El nodo líder entregará el bloque a cualquier validador 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 propagará al nodo raíz, y luego ese nodo raíz determinará qué validadores se encuentran en qué capa. El proceso es el siguiente:

1. Crear lista de nodos: el nodo raíz agregará todos los validadores activos en una lista, y luego los ordenará según la participación de cada validador en la red, ) que es la cantidad de SOL en staking (, los que tienen un 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 primera capa.

3. Formación de capas: Dividir los nodos desde la parte superior de la lista en capas, al determinar los valores de profundidad y amplitud, se puede determinar la forma aproximada de todo el árbol. Este parámetro afectará la tasa de propagación de los shreds.

Los nodos con una alta proporción de participación, al dividirse en niveles, estarán en un nivel superior, por lo que podrán obtener los shreds completos con anticipación. En este momento, podrán reconstruir el bloque completo, mientras que los nodos de 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 pedirá al líder que retransmita directamente. En este momento, 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 para que los validadores de niveles posteriores completen la construcción del bloque y voten, más tiempo tomará.

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

La idea de este mecanismo es similar a la del mecanismo de un solo nodo del nodo líder. 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 lograr el proceso de consenso de votación. Llevar la redundancia a un nivel más profundo puede acelerar significativamente el proceso de 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 de transición de estado, si el nodo líder tiene una velocidad de procesamiento lenta durante la ejecución de transacciones, eso reducirá el rendimiento de todo el sistema. 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 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 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 múltiples datos ( y capacidad de AVX de extensión de vector avanzado.

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

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, Actions e incluso Solana Mobile, y la dirección de desarrollo de las aplicaciones apoyadas oficialmente también se orienta más hacia las aplicaciones para consumidores, en lugar de una competencia infinita en la infraestructura. Dado que en la actualidad el rendimiento de Solana es suficiente, la variedad de aplicaciones es más rica. En el caso de Ethereum, debido a su baja TPS, por lo tanto,