Volviendo a analizar la arquitectura técnica de Solana: ¿llegará su segunda primavera?
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 garantiza 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 creación de bloques. El mecanismo Turbine optimiza la propagación de grandes bloques a través de 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 es parte del diseño arquitectónico de Solana para lograr un alto rendimiento, pero también conlleva algunos problemas, como caídas de la red, fallos de transacciones, problemas de MEV, crecimiento excesivo del estado y problemas de centralización, los cuales también se destacan en este artículo.
El ecosistema de Solana se está desarrollando rápidamente, 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/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 ricas oportunidades empresariales 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 campos más amplios. Al apoyar iniciativas como Solana Mobile y construir SDKs específicamente para aplicaciones de consumidores, Solana se está comprometiendo 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 experiencias novedosas en fitness y socialización. Aunque actualmente muchas aplicaciones para consumidores todavía están explorando los mejores modelos comerciales y posicionamiento en el mercado, la plataforma tecnológica y el apoyo del ecosistema que ofrece Solana sin duda brindan un fuerte respaldo a estos intentos innovadores. Con el desarrollo tecnológico continuo y la maduración del mercado, Solana tiene la esperanza de lograr más avances y casos de éxito en el campo de las aplicaciones para consumidores.
Solana, aunque ha ganado una cuota de mercado significativa en la industria de blockchain debido a su alto rendimiento y bajos costos de transacción, también enfrenta una intensa competencia de otras nuevas cadenas públicas emergentes. Una plataforma de intercambio, como un posible rival 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 total de valor bloqueado (TVL) en el campo DeFi de Solana ha alcanzado un máximo histórico, competidores como esa plataforma de intercambio también están ocupando rápidamente una cuota de mercado, y la financiación del ecosistema de esa plataforma de intercambio 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 continuamente para hacer frente a los desafíos de competidores como ciertos plataformas de intercambio. En particular, en aspectos 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, su 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. A continuación, presentaremos brevemente cómo funcionan sus diversos componentes, cómo logran su objetivo de alto rendimiento en el diseño de la arquitectura, así como las desventajas y problemas derivados de 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 tecnología 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 única Y, por lo tanto, cualquier cambio en X dará lugar a un Y completamente diferente.
En la secuencia POH de Solana, la aplicación del algoritmo sha256 puede garantizar la integridad de toda la secuencia, lo que también asegura 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 quedan determinadas; cualquier cambio resultará en un cambio del valor hash. Luego, este hash de bloque se utilizará como parte de X para la siguiente función sha256, añadiendo 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 último Y siempre incluye la prueba histórica.
En el diagrama de flujo de transacciones de Solana, se describe el proceso de transacción bajo el mecanismo POH. En un mecanismo de rotación llamado Leader Rotation Schedule, se genera un nodo líder entre todos los validadores de la cadena. Este nodo líder recopila las transacciones, las ordena y las ejecuta, generando una secuencia POH, y luego se genera un bloque que se propaga a otros nodos.
Para evitar fallos de punto único 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 para cada slot; el nodo líder debe publicar un bloque dentro del tiempo asignado del slot (400 ms), de lo contrario, se saltará este slot y se volverá a elegir un nodo líder para el siguiente slot.
En general, el nodo Leader utiliza el mecanismo POH para finalizar todas las transacciones históricas. La unidad de tiempo básica de Solana es Slot, y el nodo Leader necesita transmitir 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, luego ejecuta y genera el bloque, que se difunde a otros validadores. Los validadores necesitan llegar a un consenso sobre las transacciones y su orden dentro del bloque a través de un mecanismo, y el consenso que se utiliza 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 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í 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 recibe el bloque y luego lo envía a los validadores circundantes, lo que causa 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íder y el tiempo de Slot de 400 ms, esto resulta en un tamaño de bloque global y una frecuencia de generación de bloques especialmente alta. Los grandes bloques, 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 grandes bloques.
Turbine
Los nodos líderes dividen el bloque en subbloques llamados shreds a través de un proceso conocido como Sharding, cuyo tamaño se especifica en MTU (Unidad Máxima de Transmisión, que es la máxima cantidad 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ódigos de borrado de Reed-Solomon.
Al dividir el bloque en cuatro Data Shreds, y 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 es compatible con la arquitectura actual de Solana.
En la transmisión de datos a nivel de la capa inferior, 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 velocidad de transmisión más rápida. Por el contrario, el protocolo TCP retransmitirá múltiples veces en caso de pérdida de paquetes, lo que reducirá drásticamente la velocidad de transmisión y el rendimiento. Con la llegada de Reed-Solomon, este conjunto de soluciones puede aumentar significativamente el rendimiento de Solana, pudiendo mejorar hasta 9 veces en un entorno real.
Después de que Turbine divida 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 termine cada Slot, y luego ese validador dividirá el bloque en Shreds y generará códigos de corrección. Después, ese validador iniciará la propagación de Turbine. Primero se 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:
Crear lista de nodos: el nodo raíz resumirá todos los validadores activos en una lista y luego los ordenará según la participación de cada validador en la red (es decir, la cantidad de SOL apostada), con mayor peso en la primera capa, y así sucesivamente.
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.
Formación de capas: Desde la parte superior de la lista, se dividen los nodos en capas, y mediante la determinación de dos valores, 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 participación, al dividir por niveles, en un nivel superior, podrán obtener con anticipación los shreds completos. En ese momento, podrán restaurar el bloque completo, mientras que los nodos de los niveles inferiores, debido a la pérdida de transmisión, tendrán 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 ese momento, 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; cuanto más tiempo pase después de que los validadores de los niveles inferiores completen la construcción del bloque y voten, más tiempo tomará.
La idea de este mecanismo es similar a la mecánica de un nodo líder. Durante el proceso de propagación de bloques, también hay algunos nodos prioritarios que primero obtienen fragmentos de shreds para formar bloques completos y alcanzar un 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, 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, el SVM como la máquina virtual de transformación de estados, si el nodo líder tiene una velocidad de procesamiento lenta durante la ejecución de transacciones, esto reducirá el rendimiento general del sistema. Por lo tanto, en relación con el 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 constan de 4 partes, que incluyen el ID del programa, las instrucciones del programa y una lista de cuentas que leen/escriben datos. Al determinar si la cuenta actual está en estado de lectura o escritura y si hay conflictos en las operaciones que se van a realizar para cambiar el estado, se puede permitir la paralelización de las instrucciones de transacción de la cuenta que no tienen conflictos en el estado, con cada instrucción representada por 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 pueda soportar SIMD (una instrucción, múltiples datos) y AVX.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
13 me gusta
Recompensa
13
5
Compartir
Comentar
0/400
FancyResearchLab
· 07-30 11:46
Otra vez investigando qué función extravagante, de verdad duele por tu Billetera.
Ver originalesResponder0
FundingMartyr
· 07-28 11:16
La fe en sol ha impulsado lo que le pertenece.
Ver originalesResponder0
FarmHopper
· 07-28 11:15
¡Llega sol!
Ver originalesResponder0
ChainSauceMaster
· 07-28 11:13
sol es realmente bueno
Ver originalesResponder0
LuckyBlindCat
· 07-28 11:11
¿Esto se puede llamar una segunda primavera? Se ha alejado demasiado.
Análisis de la arquitectura técnica de Solana: alto rendimiento y desafíos coexistentes, el desarrollo del ecosistema enfrenta nuevas oportunidades.
Volviendo a analizar la arquitectura técnica de Solana: ¿llegará su segunda primavera?
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 garantiza 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 creación de bloques. El mecanismo Turbine optimiza la propagación de grandes bloques a través de 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 es parte del diseño arquitectónico de Solana para lograr un alto rendimiento, pero también conlleva algunos problemas, como caídas de la red, fallos de transacciones, problemas de MEV, crecimiento excesivo del estado y problemas de centralización, los cuales también se destacan en este artículo.
El ecosistema de Solana se está desarrollando rápidamente, 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/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 ricas oportunidades empresariales 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 campos más amplios. Al apoyar iniciativas como Solana Mobile y construir SDKs específicamente para aplicaciones de consumidores, Solana se está comprometiendo 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 experiencias novedosas en fitness y socialización. Aunque actualmente muchas aplicaciones para consumidores todavía están explorando los mejores modelos comerciales y posicionamiento en el mercado, la plataforma tecnológica y el apoyo del ecosistema que ofrece Solana sin duda brindan un fuerte respaldo a estos intentos innovadores. Con el desarrollo tecnológico continuo y la maduración del mercado, Solana tiene la esperanza de lograr más avances y casos de éxito en el campo de las aplicaciones para consumidores.
Solana, aunque ha ganado una cuota de mercado significativa en la industria de blockchain debido a su alto rendimiento y bajos costos de transacción, también enfrenta una intensa competencia de otras nuevas cadenas públicas emergentes. Una plataforma de intercambio, como un posible rival 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 total de valor bloqueado (TVL) en el campo DeFi de Solana ha alcanzado un máximo histórico, competidores como esa plataforma de intercambio también están ocupando rápidamente una cuota de mercado, y la financiación del ecosistema de esa plataforma de intercambio 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 continuamente para hacer frente a los desafíos de competidores como ciertos plataformas de intercambio. En particular, en aspectos 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, su 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. A continuación, presentaremos brevemente cómo funcionan sus diversos componentes, cómo logran su objetivo de alto rendimiento en el diseño de la arquitectura, así como las desventajas y problemas derivados de 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 tecnología 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 única Y, por lo tanto, cualquier cambio en X dará lugar a un Y completamente diferente.
En la secuencia POH de Solana, la aplicación del algoritmo sha256 puede garantizar la integridad de toda la secuencia, lo que también asegura 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 quedan determinadas; cualquier cambio resultará en un cambio del valor hash. Luego, este hash de bloque se utilizará como parte de X para la siguiente función sha256, añadiendo 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 último Y siempre incluye la prueba histórica.
En el diagrama de flujo de transacciones de Solana, se describe el proceso de transacción bajo el mecanismo POH. En un mecanismo de rotación llamado Leader Rotation Schedule, se genera un nodo líder entre todos los validadores de la cadena. Este nodo líder recopila las transacciones, las ordena y las ejecuta, generando una secuencia POH, y luego se genera un bloque que se propaga a otros nodos.
Para evitar fallos de punto único 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 para cada slot; el nodo líder debe publicar un bloque dentro del tiempo asignado del slot (400 ms), de lo contrario, se saltará este slot y se volverá a elegir un nodo líder para el siguiente slot.
En general, el nodo Leader utiliza el mecanismo POH para finalizar todas las transacciones históricas. La unidad de tiempo básica de Solana es Slot, y el nodo Leader necesita transmitir 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, luego ejecuta y genera el bloque, que se difunde a otros validadores. Los validadores necesitan llegar a un consenso sobre las transacciones y su orden dentro del bloque a través de un mecanismo, y el consenso que se utiliza 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 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í 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 recibe el bloque y luego lo envía a los validadores circundantes, lo que causa 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íder y el tiempo de Slot de 400 ms, esto resulta en un tamaño de bloque global y una frecuencia de generación de bloques especialmente alta. Los grandes bloques, 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 grandes bloques.
Turbine
Los nodos líderes dividen el bloque en subbloques llamados shreds a través de un proceso conocido como Sharding, cuyo tamaño se especifica en MTU (Unidad Máxima de Transmisión, que es la máxima cantidad 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ódigos de borrado de Reed-Solomon.
Al dividir el bloque en cuatro Data Shreds, y 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 es compatible con la arquitectura actual de Solana.
En la transmisión de datos a nivel de la capa inferior, 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 velocidad de transmisión más rápida. Por el contrario, el protocolo TCP retransmitirá múltiples veces en caso de pérdida de paquetes, lo que reducirá drásticamente la velocidad de transmisión y el rendimiento. Con la llegada de Reed-Solomon, este conjunto de soluciones puede aumentar significativamente el rendimiento de Solana, pudiendo mejorar hasta 9 veces en un entorno real.
Después de que Turbine divida 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 termine cada Slot, y luego ese validador dividirá el bloque en Shreds y generará códigos de corrección. Después, ese validador iniciará la propagación de Turbine. Primero se 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:
Crear lista de nodos: el nodo raíz resumirá todos los validadores activos en una lista y luego los ordenará según la participación de cada validador en la red (es decir, la cantidad de SOL apostada), con mayor peso en la primera capa, y así sucesivamente.
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.
Formación de capas: Desde la parte superior de la lista, se dividen los nodos en capas, y mediante la determinación de dos valores, 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 participación, al dividir por niveles, en un nivel superior, podrán obtener con anticipación los shreds completos. En ese momento, podrán restaurar el bloque completo, mientras que los nodos de los niveles inferiores, debido a la pérdida de transmisión, tendrán 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 ese momento, 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; cuanto más tiempo pase después de que los validadores de los niveles inferiores completen la construcción del bloque y voten, más tiempo tomará.
La idea de este mecanismo es similar a la mecánica de un nodo líder. Durante el proceso de propagación de bloques, también hay algunos nodos prioritarios que primero obtienen fragmentos de shreds para formar bloques completos y alcanzar un 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, 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, el SVM como la máquina virtual de transformación de estados, si el nodo líder tiene una velocidad de procesamiento lenta durante la ejecución de transacciones, esto reducirá el rendimiento general del sistema. Por lo tanto, en relación con el 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 constan de 4 partes, que incluyen el ID del programa, las instrucciones del programa y una lista de cuentas que leen/escriben datos. Al determinar si la cuenta actual está en estado de lectura o escritura y si hay conflictos en las operaciones que se van a realizar para cambiar el estado, se puede permitir la paralelización de las instrucciones de transacción de la cuenta que no tienen conflictos en el estado, con cada instrucción representada por 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 pueda soportar SIMD (una instrucción, múltiples datos) y AVX.