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 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 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 paralela Sealevel aceleran la velocidad de ejecución de las 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 excesivo del estado y problemas de centralización.
El ecosistema de Solana se está desarrollando rápidamente, con todos los indicadores de datos experimentando un crecimiento notable 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, ofrecen numerosas 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 áreas más amplias. Al apoyar iniciativas como Solana Mobile y construir SDKs 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.
Aunque Solana ha logrado una participación de mercado significativa en la industria 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 rival 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 de Solana en el ámbito DeFi ha alcanzado un máximo histórico de (, competidores como Base también están ocupando rápidamente cuota de mercado, y la financiación del ecosistema Base ha superado por primera vez a Solana en el segundo trimestre.
A pesar de que Solana ha logrado ciertos avances en tecnología y aceptación en el mercado, necesita innovar y mejorar continuamente para enfrentar los desafíos de competidores como Base. En particular, 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 del crecimiento del estado, Solana debe seguir optimizando 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 y la red de transmisión de datos Trubine y la máquina virtual SVM que ofrecen un alto TPS y una rápida finalidad. Cómo funcionan cada uno de los componentes, cómo logran su objetivo de alto rendimiento para el diseño arquitectónico, así como las desventajas y problemas derivados que surgen bajo este diseño arquitectónico.
) algoritmo POH
POH###Prueba de Historia( es una tecnología 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 comúnmente para calcular la integridad de los datos; dado un input X, hay y solo hay una salida única Y, por lo que cualquier cambio en X dará como resultado un Y completamente diferente.
En la secuencia POH de Solana, se puede asegurar la integridad de toda la secuencia aplicando el algoritmo sha256, lo que también 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 están determinadas; cualquier cambio resultará en una modificación del valor hash. Luego, este hash del bloque se utilizará como parte de X en la próxima función sha256, sumando el hash del siguiente bloque, de modo que tanto el bloque anterior como el siguiente queden determinados; 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 utiliza como parte de la siguiente función sha256, similar a una cadena, el más reciente Y siempre contiene la prueba de la historia.
![¿Un nuevo renacer para la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-83781275d369bad28954d579213dd93e.webp(
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 de líderes 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 ejecuta, generando una secuencia POH, y luego genera un bloque que se propaga a otros nodos.
Para evitar el fallo de un punto único en el nodo Leader, 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 Leader, que debe publicar el bloque( dentro del tiempo del slot dado de 400 ms), de lo contrario, se saltará este slot y se elegirá nuevamente el nodo Leader del siguiente slot.
En general, el nodo líder utiliza el mecanismo POH para asegurar que todas las transacciones históricas estén completamente confirmadas. La unidad de tiempo básica de Solana es el Slot, el nodo líder necesita difundir el bloque dentro de un slot. Los usuarios envían transacciones al líder a través de nodos RPC, el nodo líder empaqueta las transacciones, las ordena y luego ejecuta para generar el bloque, el bloque se propaga a otros validadores, quienes 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 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 ingenieril específica de este. Este algoritmo todavía está 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.
![¿Volverá a florecer la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.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 utiliza la inundación de bloques, donde un validador recibe el bloque y luego 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 junto con un tiempo de slot de 400 ms, esto provoca que tanto el tamaño general del bloque como 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 llamado Sharding, cuyo tamaño especificado es de 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, ### como unidad. 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 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 considerará el uso de 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 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 conjunto de soluciones 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 llevar a cabo la propagació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á códigos 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:
Crear una lista de nodos: el nodo raíz compila todos los validadores activos en una lista y luego los ordena según la participación de cada validador en la red (, es decir, la cantidad de SOL apostada ), donde los de mayor peso se ubican en la primera capa, y así sucesivamente.
Agrupación de nodos: luego cada validador situado en la primera capa también creará su propia lista de nodos para construir su propia primera capa.
Formación de capas: Dividir los nodos en capas desde la parte superior de la lista, mediante la determinación de dos valores, 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 derechos, al dividirse en niveles, estarán en un nivel superior, lo que les permitirá obtener los shreds completos por adelantado; en este momento, podrán reconstruir el bloque completo. Por otro lado, los nodos en niveles inferiores, debido a la pérdida de transmisión, tendrán una menor probabilidad de obtener shreds completos. Si estos shreds son insuficientes para construir fragmentos completos, se solicitará 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 inferiores completen la construcción del bloque, más tiempo tardarán en votar.
La idea de este mecanismo es similar a la mecánica de un único nodo del nodo líder. Durante el proceso de propagación del bloque, también hay algunos nodos prioritarios; estos nodos son los primeros en recibir los fragmentos shreds para construir bloques completos y lograr 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, de hecho, las primeras capas podrían representar 2/3 de los nodos, entonces la votación de los nodos posteriores no sería relevante.
( 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 para la transformación de estado, si el nodo líder es lento en la ejecución de transacciones, disminuirá la capacidad total del sistema. Por lo tanto, para SVM, Solana propuso el motor de ejecución paralela Sealevel para acelerar la velocidad de ejecución de las transacciones.
![¿Volverá a florecer la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp###
En SVM, las instrucciones se componen 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 las operaciones que realizan cambios de estado tienen conflictos, 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 Program ID. Y esta es también una de las razones por las que los requisitos para los validadores de Solana son muy altos, ya que se requiere que la GPU/CPU del validador pueda soportar SIMD( instrucciones de múltiples datos de una sola instrucción) y capacidades de AVX de extensiones de vectores avanzadas.
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. Además, la dirección de desarrollo de las aplicaciones apoyadas oficialmente también se orienta más hacia aplicaciones para consumidores, en lugar de una competencia infinita en infraestructura. Con el rendimiento actual suficiente de Solana, la variedad de aplicaciones es más rica. En el caso de Ethereum, debido a su bajo TPS, el ecosistema de Ethereum sigue centrado en la infraestructura y las 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 donde hay demasiada inversión en infraestructura pero muy poca en aplicaciones.
( DeFi
En los protocolos DeFi en Solana, hay una gran cantidad de proyectos que aún no han emitido tokens, incluyendo Kamino) Primer Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, etc. Debido a la atmósfera de unidad en el ecosistema de Solana, generalmente un proyecto evitará lanzar tokens en la misma fecha que otros proyectos 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 algún DEX que ocupa la posición dominante.
Es importante destacar que aproximadamente el 50% de las transacciones en DEX son realizadas por bots MEV.
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.
19 me gusta
Recompensa
19
6
Compartir
Comentar
0/400
staking_gramps
· 07-16 11:08
el rendimiento de sol es realmente atractivo
Ver originalesResponder0
0xSunnyDay
· 07-15 15:18
¿El rey de las caídas aún presume de rendimiento?
Ver originalesResponder0
CoconutWaterBoy
· 07-14 03:35
¿Otra vez hablando de sol?
Ver originalesResponder0
SandwichTrader
· 07-14 03:21
Bloquear no es mejor que despejar, solo pensar en ello causa un fallo.
Análisis de la arquitectura técnica de Solana y estado actual del desarrollo ecológico
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 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 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 paralela Sealevel aceleran la velocidad de ejecución de las 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 excesivo del estado y problemas de centralización.
El ecosistema de Solana se está desarrollando rápidamente, con todos los indicadores de datos experimentando un crecimiento notable 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, ofrecen numerosas 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 áreas más amplias. Al apoyar iniciativas como Solana Mobile y construir SDKs 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.
Aunque Solana ha logrado una participación de mercado significativa en la industria 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 rival 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 de Solana en el ámbito DeFi ha alcanzado un máximo histórico de (, competidores como Base también están ocupando rápidamente cuota de mercado, y la financiación del ecosistema Base ha superado por primera vez a Solana en el segundo trimestre.
A pesar de que Solana ha logrado ciertos avances en tecnología y aceptación en el mercado, necesita innovar y mejorar continuamente para enfrentar los desafíos de competidores como Base. En particular, 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 del crecimiento del estado, Solana debe seguir optimizando 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 y la red de transmisión de datos Trubine y la máquina virtual SVM que ofrecen un alto TPS y una rápida finalidad. Cómo funcionan cada uno de los componentes, cómo logran su objetivo de alto rendimiento para el diseño arquitectónico, así como las desventajas y problemas derivados que surgen bajo este diseño arquitectónico.
) algoritmo POH
POH###Prueba de Historia( es una tecnología 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 comúnmente para calcular la integridad de los datos; dado un input X, hay y solo hay una salida única Y, por lo que cualquier cambio en X dará como resultado un Y completamente diferente.
En la secuencia POH de Solana, se puede asegurar la integridad de toda la secuencia aplicando el algoritmo sha256, lo que también 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 están determinadas; cualquier cambio resultará en una modificación del valor hash. Luego, este hash del bloque se utilizará como parte de X en la próxima función sha256, sumando el hash del siguiente bloque, de modo que tanto el bloque anterior como el siguiente queden determinados; 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 utiliza como parte de la siguiente función sha256, similar a una cadena, el más reciente Y siempre contiene la prueba de la historia.
![¿Un nuevo renacer para la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-83781275d369bad28954d579213dd93e.webp(
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 de líderes 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 ejecuta, generando una secuencia POH, y luego genera un bloque que se propaga a otros nodos.
Para evitar el fallo de un punto único en el nodo Leader, 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 Leader, que debe publicar el bloque( dentro del tiempo del slot dado de 400 ms), de lo contrario, se saltará este slot y se elegirá nuevamente el nodo Leader del siguiente slot.
En general, el nodo líder utiliza el mecanismo POH para asegurar que todas las transacciones históricas estén completamente confirmadas. La unidad de tiempo básica de Solana es el Slot, el nodo líder necesita difundir el bloque dentro de un slot. Los usuarios envían transacciones al líder a través de nodos RPC, el nodo líder empaqueta las transacciones, las ordena y luego ejecuta para generar el bloque, el bloque se propaga a otros validadores, quienes 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 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 ingenieril específica de este. Este algoritmo todavía está 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.
![¿Volverá a florecer la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.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 utiliza la inundación de bloques, donde un validador recibe el bloque y luego 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 junto con un tiempo de slot de 400 ms, esto provoca que tanto el tamaño general del bloque como 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 llamado Sharding, cuyo tamaño especificado es de 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, ### como unidad. 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 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 considerará el uso de 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 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 conjunto de soluciones 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 llevar a cabo la propagació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á códigos 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:
Crear una lista de nodos: el nodo raíz compila todos los validadores activos en una lista y luego los ordena según la participación de cada validador en la red (, es decir, la cantidad de SOL apostada ), donde los de mayor peso se ubican en la primera capa, y así sucesivamente.
Agrupación de nodos: luego cada validador situado en la primera capa también creará su propia lista de nodos para construir su propia primera capa.
Formación de capas: Dividir los nodos en capas desde la parte superior de la lista, mediante la determinación de dos valores, 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 derechos, al dividirse en niveles, estarán en un nivel superior, lo que les permitirá obtener los shreds completos por adelantado; en este momento, podrán reconstruir el bloque completo. Por otro lado, los nodos en niveles inferiores, debido a la pérdida de transmisión, tendrán una menor probabilidad de obtener shreds completos. Si estos shreds son insuficientes para construir fragmentos completos, se solicitará 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 inferiores completen la construcción del bloque, más tiempo tardarán en votar.
La idea de este mecanismo es similar a la mecánica de un único nodo del nodo líder. Durante el proceso de propagación del bloque, también hay algunos nodos prioritarios; estos nodos son los primeros en recibir los fragmentos shreds para construir bloques completos y lograr 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, de hecho, las primeras capas podrían representar 2/3 de los nodos, entonces la votación de los nodos posteriores no sería relevante.
( 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 para la transformación de estado, si el nodo líder es lento en la ejecución de transacciones, disminuirá la capacidad total del sistema. Por lo tanto, para SVM, Solana propuso el motor de ejecución paralela Sealevel para acelerar la velocidad de ejecución de las transacciones.
![¿Volverá a florecer la arquitectura técnica de Solana?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp###
En SVM, las instrucciones se componen 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 las operaciones que realizan cambios de estado tienen conflictos, 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 Program ID. Y esta es también una de las razones por las que los requisitos para los validadores de Solana son muy altos, ya que se requiere que la GPU/CPU del validador pueda soportar SIMD( instrucciones de múltiples datos de una sola instrucción) y capacidades de AVX de extensiones de vectores avanzadas.
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. Además, la dirección de desarrollo de las aplicaciones apoyadas oficialmente también se orienta más hacia aplicaciones para consumidores, en lugar de una competencia infinita en infraestructura. Con el rendimiento actual suficiente de Solana, la variedad de aplicaciones es más rica. En el caso de Ethereum, debido a su bajo TPS, el ecosistema de Ethereum sigue centrado en la infraestructura y las 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 donde hay demasiada inversión en infraestructura pero muy poca en aplicaciones.
( DeFi
En los protocolos DeFi en Solana, hay una gran cantidad de proyectos que aún no han emitido tokens, incluyendo Kamino) Primer Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, etc. Debido a la atmósfera de unidad en el ecosistema de Solana, generalmente un proyecto evitará lanzar tokens en la misma fecha que otros proyectos 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 algún DEX que ocupa la posición dominante.
Es importante destacar que aproximadamente el 50% de las transacciones en DEX son realizadas por bots MEV.