Análise da Arquitetura Técnica e Desenvolvimento do Ecossistema Solana
Solana é uma plataforma de blockchain de alto desempenho, que utiliza uma arquitetura técnica única para alcançar alta capacidade de processamento e baixa latência. Suas tecnologias principais incluem o algoritmo Proof of History (POH) que garante a ordem das transações e um relógio global, o cronograma de rotação de líderes e o mecanismo de consenso Tower BFT para aumentar a taxa de produção de blocos. O mecanismo Turbine otimiza a propagação de grandes blocos através de codificação Reed-solomon. A Solana Virtual Machine (SVM) e o motor de execução paralela Sealevel aceleram a velocidade de execução das transações. Todas essas são concepções arquitetônicas que permitem à Solana alcançar um alto desempenho, mas também trazem alguns problemas, como quedas de rede, falhas em transações, problemas de MEV, crescimento rápido do estado e problemas de centralização.
O ecossistema Solana está a desenvolver-se rapidamente, com vários indicadores de dados a crescerem rapidamente no primeiro semestre, especialmente nas áreas de DeFi, infraestrutura, GameFi/NFT, DePin/IA e aplicações de consumo. A alta TPS da Solana e a sua estratégia voltada para aplicações de consumo, juntamente com um ambiente ecológico com efeito de marca relativamente fraco, oferecem ricas oportunidades de empreendedorismo para empreendedores e desenvolvedores. Na área de aplicações de consumo, a Solana demonstrou a sua visão de promover a aplicação da tecnologia blockchain em áreas mais amplas. Ao apoiar iniciativas como o Solana Mobile e ao construir SDKs especificamente para aplicações de consumo, a Solana está empenhada em integrar a tecnologia blockchain em aplicações do dia-a-dia, aumentando assim a aceitação e conveniência para os usuários.
Embora Solana tenha conquistado uma participação de mercado significativa na indústria de blockchain com sua alta capacidade de processamento e baixos custos de transação, também enfrenta uma competição acirrada de outras blockchains emergentes. Base, como um potencial concorrente no ecossistema EVM, está rapidamente aumentando o número de endereços ativos na sua rede, enquanto o valor total bloqueado (TVL) no setor DeFi da Solana, (TVL), embora tenha atingido um novo recorde histórico, concorrentes como a Base também estão rapidamente conquistando participação de mercado, com o volume de financiamento do ecossistema Base superando pela primeira vez o da Solana no segundo trimestre.
Apesar de a Solana ter alcançado alguns sucessos em termos de tecnologia e aceitação no mercado, ela precisa continuar a inovar e a melhorar para enfrentar os desafios de concorrentes como a Base. Em particular, no que diz respeito ao aumento da estabilidade da rede, à redução da taxa de falhas nas transações, à resolução do problema do MEV e à desaceleração do crescimento do estado, a Solana precisa otimizar continuamente sua arquitetura técnica e protocolos de rede para manter sua posição de liderança na indústria de blockchain.
Arquitetura Técnica
A Solana é conhecida por seu algoritmo POH, mecanismo de consenso Tower BFT, rede de transmissão de dados Trubine e máquina virtual SVM, que proporcionam altas TPS e rápida finalização. Como cada componente funciona, como eles desempenham seus objetivos de alto desempenho para o design da arquitetura, bem como as desvantagens e problemas derivados trazidos por esse design arquitetônico.
algoritmo POH
POH(Proof of History) é uma tecnologia que determina o tempo global, que não é um mecanismo de consenso, mas sim um algoritmo que determina a ordem das transações. A tecnologia POH origina-se da mais básica criptografia SHA256. A SHA256 é normalmente usada para calcular a integridade dos dados; dado uma entrada X, existe e somente existe uma saída Y única, portanto, qualquer alteração em X levará a uma Y completamente diferente.
Na sequência POH da Solana, a aplicação do algoritmo sha256 garante a integridade de toda a sequência, assim como a integridade das transações nela. Por exemplo, se agrupássemos as transações em um bloco e gerássemos o valor hash sha256 correspondente, as transações dentro desse bloco estariam determinadas, qualquer alteração resultaria em uma mudança no valor hash. Em seguida, esse hash do bloco serviria como parte do X da próxima função sha256, adicionando o hash do próximo bloco, assim o bloco anterior e o próximo bloco estariam ambos determinados, qualquer alteração resultaria em um novo Y diferente.
Este é o significado central da sua tecnologia Proof of History, onde o hash do bloco anterior é utilizado como parte da próxima função sha256, semelhante a uma corrente, o mais recente Y, sempre contém a prova histórica.
No diagrama de fluxo de transações da Solana, é descrito o fluxo de transações sob o mecanismo POH, onde, em um mecanismo de rotação chamado Leader Rotation Schedule, é escolhido um nó Líder entre todos os validadores da cadeia, que coleta transações, as ordena e executa, gerando uma sequência POH, e em seguida gera um bloco que é propagado para outros nós.
Para evitar a falha de ponto único no nó Leader, foi introduzido um limite de tempo. No Solana, a unidade de tempo é dividida em epochs, cada epoch contém 432.000 slots(, cada slot dura 400 ms. Em cada slot, o sistema de rodízio atribuirá um nó Leader, que deve publicar o bloco)400ms( dentro do tempo dado do slot; caso contrário, esse slot será pulado e o nó Leader do próximo slot será reeleito.
No geral, o nó Leader que utiliza o mecanismo POH pode garantir a determinação de todas as transações históricas. A unidade básica de tempo da Solana é o Slot, e o nó Leader precisa transmitir blocos dentro de um slot. Os usuários enviam transações ao Leader através de nós RPC, o nó Leader empacota e ordena as transações e então executa a geração de blocos, que são propagados para outros validadores. Os validadores precisam alcançar um consenso através de um mecanismo para concordar sobre as transações e a ordem dentro do bloco, e o consenso utilizado é o mecanismo de consenso Tower BFT.
) Mecanismo de consenso Tower BFT
O protocolo de consenso Tower BFT é uma implementação específica do algoritmo de consenso BFT, que ainda está relacionado ao algoritmo POH. Ao votar em um bloco, se o voto do validador for em si uma transação, então o hash do bloco formado pelas transações do usuário e do validador também pode servir como prova histórica, onde os detalhes da transação de cada usuário e os detalhes do voto do validador podem ser confirmados de forma única.
![Reanálise da arquitetura técnica da Solana: está prestes a ter um segundo renascimento?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
No algoritmo Tower BFT, é estipulado que, se todos os validadores votarem nesse bloco e mais de 2/3 dos validadores votarem a favor, então esse bloco pode ser confirmado. A vantagem desse mecanismo é que economiza uma quantidade significativa de memória, pois apenas é necessário votar na sequência de hash para confirmar o bloco. No entanto, nos mecanismos de consenso tradicionais, geralmente se utiliza a inundação de blocos, onde um validador que recebe um bloco o envia para os validadores ao seu redor, o que causa uma grande redundância na rede, já que um validador recebe o mesmo bloco mais de uma vez.
Em Solana, devido à grande quantidade de transações de votação dos validadores, e à eficiência trazida pela centralização dos nós líderes e ao tempo de Slot de 400ms, isso resulta em um tamanho de bloco total e uma frequência de mineração especialmente altos. Blocos grandes, ao serem propagados, também impõem uma grande pressão à rede. Solana utiliza o mecanismo Turbine para resolver o problema da propagação de grandes blocos.
) Turbine
O nó Leader divide o bloco em subblocos chamados shreds através de um processo denominado Sharding, cujo tamanho padrão é a unidade máxima de transmissão MTU###, que é a quantidade máxima de dados que pode ser enviada de um nó para o próximo sem precisar ser dividida em unidades menores, expressa em (. Em seguida, garante-se a integridade e a disponibilidade dos dados utilizando o esquema de código de apagamento Reed-Solomon.
Dividindo o bloco em quatro Data Shreds, e depois, para evitar a perda e danos de dados durante a transmissão, utiliza-se a codificação Reed-Solomon para codificar os quatro pacotes em oito pacotes. Este conjunto de soluções pode tolerar até 50% de taxa de perda. Nos testes reais, a taxa de perda do Solana é de cerca de 15%, portanto, este conjunto de soluções é muito compatível com a arquitetura atual do Solana.
Na transmissão de dados de baixo nível, geralmente considera-se o uso do protocolo UDP/TCP. Devido à alta tolerância da Solana à taxa de perda de pacotes, foi adotado o protocolo UDP para a transmissão. Sua desvantagem é que em caso de perda de pacotes não há retransmissão, mas sua vantagem é uma taxa de transmissão mais rápida. Em contraste, o protocolo TCP retransmite várias vezes em caso de perda de pacotes, o que reduz drasticamente a taxa de transmissão e a capacidade de throughput. Com a Reed-Solomon, esse conjunto de soluções pode aumentar significativamente o throughput da Solana, podendo aumentar em 9 vezes em ambientes reais.
![Reanálise da arquitetura técnica da Solana: estará a chegar a segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Após a fragmentação dos dados pelo Turbine, é utilizado um mecanismo de propagação em múltiplas camadas para a transmissão. O nó líder entregará o bloco a qualquer validador de bloco antes do final de cada Slot, e então esse validador fragmentará o bloco em Shreds e gerará códigos de correção. Em seguida, esse validador iniciará a propagação do Turbine. Primeiro, deve ser propagado até o nó raiz, e então esse nó raiz determinará quais validadores estão em qual camada. O processo é como segue:
Criar lista de nós: O nó raiz reunirá todos os validadores ativos em uma lista e, em seguida, os ordenará com base na participação de cada validador na rede, que é a quantidade de SOL em staking ), sendo que os de maior peso ficarão na primeira camada, e assim por diante.
Agrupamento de nós: em seguida, cada validador localizado na primeira camada também criará sua própria lista de nós para construir sua própria primeira camada.
Formação de Camadas: Dividir os nós em camadas a partir do topo da lista, determinando dois valores: profundidade e largura, pode definir a forma geral da árvore, e este parâmetro afetará a taxa de propagação dos shreds.
Os nós com uma alta proporção de participação, ao serem classificados em camadas, estarão em um nível superior, o que lhes permitirá receber os shreds completos antecipadamente. Nesse momento, será possível recuperar o bloco completo, enquanto os nós das camadas inferiores, devido à perda de transmissão, terão uma probabilidade reduzida de obter shreds completos. Se esses shreds forem insuficientes para construir fragmentos completos, exigirá que o Líder retransmita diretamente. Assim, a transmissão de dados ocorrerá internamente na árvore, e os nós da primeira camada já terão construído a confirmação do bloco completo. Quanto mais tempo levar para os validadores das camadas inferiores completarem a construção do bloco, mais tempo demorará para a votação.
A ideia deste mecanismo é semelhante ao mecanismo de um único nó do nó líder. No processo de propagação do bloco, existem também alguns nós prioritários, que são os primeiros a receber os shreds para formar blocos completos e alcançar o processo de consenso de votação. Levar a redundância a um nível mais profundo pode acelerar significativamente a realização da Finalidade e maximizar a taxa de transferência e a eficiência. Porque, na verdade, as primeiras camadas podem representar 2/3 dos nós, então o voto dos nós subsequentes se torna irrelevante.
( SVM
A Solana consegue processar milhares de transações por segundo, principalmente devido ao seu mecanismo POH, ao consenso Tower BFT e ao mecanismo de propagação de dados Turbine. No entanto, como a SVM é a máquina virtual para a transição de estados, se o nó líder estiver executando transações e a velocidade de processamento da SVM for lenta, isso diminuirá a capacidade de throughput de todo o sistema. Portanto, em relação à SVM, a Solana propôs o motor de execução paralelo Sealevel para acelerar a velocidade de execução das transações.
![Revisit the Solana technical architecture: Will it迎来第二春吗？])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp###
No SVM, as instruções consistem em 4 partes, incluindo o ID do programa, instruções do programa e uma lista de contas para leitura/gravação de dados. Ao determinar se a conta atual está em estado de leitura ou gravação e se as operações que vão mudar o estado conflitam, é possível permitir a paralelização das instruções de transação da conta onde não há conflito de estado, cada instrução é representada pelo Program ID. E essa é também uma das razões pelas quais os requisitos para os validadores da Solana são tão altos, pois exige que a GPU/CPU do validador suporte SIMD( instruções múltiplas de dados únicas) e capacidades AVX de extensões vetoriais avançadas.
Desenvolvimento Ecológico
No atual processo de desenvolvimento do ecossistema Solana, há uma tendência crescente para a utilidade prática, como Blinks e Actions, até mesmo Solana Mobile, enquanto a direção de desenvolvimento das aplicações apoiadas oficialmente também se inclina mais para aplicativos de consumo, em vez da infinita competição em torno da infraestrutura. Com o desempenho atual da Solana sendo suficiente, a variedade de aplicações é mais rica. No caso do Ethereum, devido ao seu TPS mais baixo, o ecossistema Ethereum ainda é dominado por infraestrutura e tecnologias de escalabilidade; quando a infraestrutura não pode suportar as aplicações, não é possível construir aplicações para o consumidor, o que resulta em um estado de desequilíbrio, onde há um investimento excessivo em infraestrutura, mas um investimento insuficiente em aplicações.
( DeFi
Nos protocolos DeFi na Solana, há uma grande quantidade de projetos que ainda não emitiram tokens, incluindo Kamino) primeiro Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, entre outros. Devido à atmosfera de união do ecossistema da Solana, geralmente, quando um projeto está prestes a emitir tokens, outros projetos tentam evitar o mesmo período para atrair atenção suficiente do mercado.
Atualmente, a competição em todo o DEX é intensa, e seu líder também passou por várias migrações, de Raydium, Orca até agora um certo DEX dominando.
É importante notar que cerca de 50% das transações DEX são realizadas por bots MEV.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
19 Curtidas
Recompensa
19
6
Compartilhar
Comentário
0/400
staking_gramps
· 07-16 11:08
o desempenho do sol é realmente bom
Ver originalResponder0
0xSunnyDay
· 07-15 15:18
O rei do downtime ainda está a falar de desempenho?
Ver originalResponder0
CoconutWaterBoy
· 07-14 03:35
Está a falar de sol novamente?
Ver originalResponder0
SandwichTrader
· 07-14 03:21
Bloquear não é tão bom quanto desobstruir, só de pensar já dá uma pane.
Análise da arquitetura técnica da Solana e estado atual do desenvolvimento do ecossistema
Análise da Arquitetura Técnica e Desenvolvimento do Ecossistema Solana
Solana é uma plataforma de blockchain de alto desempenho, que utiliza uma arquitetura técnica única para alcançar alta capacidade de processamento e baixa latência. Suas tecnologias principais incluem o algoritmo Proof of History (POH) que garante a ordem das transações e um relógio global, o cronograma de rotação de líderes e o mecanismo de consenso Tower BFT para aumentar a taxa de produção de blocos. O mecanismo Turbine otimiza a propagação de grandes blocos através de codificação Reed-solomon. A Solana Virtual Machine (SVM) e o motor de execução paralela Sealevel aceleram a velocidade de execução das transações. Todas essas são concepções arquitetônicas que permitem à Solana alcançar um alto desempenho, mas também trazem alguns problemas, como quedas de rede, falhas em transações, problemas de MEV, crescimento rápido do estado e problemas de centralização.
O ecossistema Solana está a desenvolver-se rapidamente, com vários indicadores de dados a crescerem rapidamente no primeiro semestre, especialmente nas áreas de DeFi, infraestrutura, GameFi/NFT, DePin/IA e aplicações de consumo. A alta TPS da Solana e a sua estratégia voltada para aplicações de consumo, juntamente com um ambiente ecológico com efeito de marca relativamente fraco, oferecem ricas oportunidades de empreendedorismo para empreendedores e desenvolvedores. Na área de aplicações de consumo, a Solana demonstrou a sua visão de promover a aplicação da tecnologia blockchain em áreas mais amplas. Ao apoiar iniciativas como o Solana Mobile e ao construir SDKs especificamente para aplicações de consumo, a Solana está empenhada em integrar a tecnologia blockchain em aplicações do dia-a-dia, aumentando assim a aceitação e conveniência para os usuários.
Embora Solana tenha conquistado uma participação de mercado significativa na indústria de blockchain com sua alta capacidade de processamento e baixos custos de transação, também enfrenta uma competição acirrada de outras blockchains emergentes. Base, como um potencial concorrente no ecossistema EVM, está rapidamente aumentando o número de endereços ativos na sua rede, enquanto o valor total bloqueado (TVL) no setor DeFi da Solana, (TVL), embora tenha atingido um novo recorde histórico, concorrentes como a Base também estão rapidamente conquistando participação de mercado, com o volume de financiamento do ecossistema Base superando pela primeira vez o da Solana no segundo trimestre.
Apesar de a Solana ter alcançado alguns sucessos em termos de tecnologia e aceitação no mercado, ela precisa continuar a inovar e a melhorar para enfrentar os desafios de concorrentes como a Base. Em particular, no que diz respeito ao aumento da estabilidade da rede, à redução da taxa de falhas nas transações, à resolução do problema do MEV e à desaceleração do crescimento do estado, a Solana precisa otimizar continuamente sua arquitetura técnica e protocolos de rede para manter sua posição de liderança na indústria de blockchain.
Arquitetura Técnica
A Solana é conhecida por seu algoritmo POH, mecanismo de consenso Tower BFT, rede de transmissão de dados Trubine e máquina virtual SVM, que proporcionam altas TPS e rápida finalização. Como cada componente funciona, como eles desempenham seus objetivos de alto desempenho para o design da arquitetura, bem como as desvantagens e problemas derivados trazidos por esse design arquitetônico.
algoritmo POH
POH(Proof of History) é uma tecnologia que determina o tempo global, que não é um mecanismo de consenso, mas sim um algoritmo que determina a ordem das transações. A tecnologia POH origina-se da mais básica criptografia SHA256. A SHA256 é normalmente usada para calcular a integridade dos dados; dado uma entrada X, existe e somente existe uma saída Y única, portanto, qualquer alteração em X levará a uma Y completamente diferente.
Na sequência POH da Solana, a aplicação do algoritmo sha256 garante a integridade de toda a sequência, assim como a integridade das transações nela. Por exemplo, se agrupássemos as transações em um bloco e gerássemos o valor hash sha256 correspondente, as transações dentro desse bloco estariam determinadas, qualquer alteração resultaria em uma mudança no valor hash. Em seguida, esse hash do bloco serviria como parte do X da próxima função sha256, adicionando o hash do próximo bloco, assim o bloco anterior e o próximo bloco estariam ambos determinados, qualquer alteração resultaria em um novo Y diferente.
Este é o significado central da sua tecnologia Proof of History, onde o hash do bloco anterior é utilizado como parte da próxima função sha256, semelhante a uma corrente, o mais recente Y, sempre contém a prova histórica.
No diagrama de fluxo de transações da Solana, é descrito o fluxo de transações sob o mecanismo POH, onde, em um mecanismo de rotação chamado Leader Rotation Schedule, é escolhido um nó Líder entre todos os validadores da cadeia, que coleta transações, as ordena e executa, gerando uma sequência POH, e em seguida gera um bloco que é propagado para outros nós.
Para evitar a falha de ponto único no nó Leader, foi introduzido um limite de tempo. No Solana, a unidade de tempo é dividida em epochs, cada epoch contém 432.000 slots(, cada slot dura 400 ms. Em cada slot, o sistema de rodízio atribuirá um nó Leader, que deve publicar o bloco)400ms( dentro do tempo dado do slot; caso contrário, esse slot será pulado e o nó Leader do próximo slot será reeleito.
No geral, o nó Leader que utiliza o mecanismo POH pode garantir a determinação de todas as transações históricas. A unidade básica de tempo da Solana é o Slot, e o nó Leader precisa transmitir blocos dentro de um slot. Os usuários enviam transações ao Leader através de nós RPC, o nó Leader empacota e ordena as transações e então executa a geração de blocos, que são propagados para outros validadores. Os validadores precisam alcançar um consenso através de um mecanismo para concordar sobre as transações e a ordem dentro do bloco, e o consenso utilizado é o mecanismo de consenso Tower BFT.
) Mecanismo de consenso Tower BFT
O protocolo de consenso Tower BFT é uma implementação específica do algoritmo de consenso BFT, que ainda está relacionado ao algoritmo POH. Ao votar em um bloco, se o voto do validador for em si uma transação, então o hash do bloco formado pelas transações do usuário e do validador também pode servir como prova histórica, onde os detalhes da transação de cada usuário e os detalhes do voto do validador podem ser confirmados de forma única.
![Reanálise da arquitetura técnica da Solana: está prestes a ter um segundo renascimento?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
No algoritmo Tower BFT, é estipulado que, se todos os validadores votarem nesse bloco e mais de 2/3 dos validadores votarem a favor, então esse bloco pode ser confirmado. A vantagem desse mecanismo é que economiza uma quantidade significativa de memória, pois apenas é necessário votar na sequência de hash para confirmar o bloco. No entanto, nos mecanismos de consenso tradicionais, geralmente se utiliza a inundação de blocos, onde um validador que recebe um bloco o envia para os validadores ao seu redor, o que causa uma grande redundância na rede, já que um validador recebe o mesmo bloco mais de uma vez.
Em Solana, devido à grande quantidade de transações de votação dos validadores, e à eficiência trazida pela centralização dos nós líderes e ao tempo de Slot de 400ms, isso resulta em um tamanho de bloco total e uma frequência de mineração especialmente altos. Blocos grandes, ao serem propagados, também impõem uma grande pressão à rede. Solana utiliza o mecanismo Turbine para resolver o problema da propagação de grandes blocos.
) Turbine
O nó Leader divide o bloco em subblocos chamados shreds através de um processo denominado Sharding, cujo tamanho padrão é a unidade máxima de transmissão MTU###, que é a quantidade máxima de dados que pode ser enviada de um nó para o próximo sem precisar ser dividida em unidades menores, expressa em (. Em seguida, garante-se a integridade e a disponibilidade dos dados utilizando o esquema de código de apagamento Reed-Solomon.
Dividindo o bloco em quatro Data Shreds, e depois, para evitar a perda e danos de dados durante a transmissão, utiliza-se a codificação Reed-Solomon para codificar os quatro pacotes em oito pacotes. Este conjunto de soluções pode tolerar até 50% de taxa de perda. Nos testes reais, a taxa de perda do Solana é de cerca de 15%, portanto, este conjunto de soluções é muito compatível com a arquitetura atual do Solana.
Na transmissão de dados de baixo nível, geralmente considera-se o uso do protocolo UDP/TCP. Devido à alta tolerância da Solana à taxa de perda de pacotes, foi adotado o protocolo UDP para a transmissão. Sua desvantagem é que em caso de perda de pacotes não há retransmissão, mas sua vantagem é uma taxa de transmissão mais rápida. Em contraste, o protocolo TCP retransmite várias vezes em caso de perda de pacotes, o que reduz drasticamente a taxa de transmissão e a capacidade de throughput. Com a Reed-Solomon, esse conjunto de soluções pode aumentar significativamente o throughput da Solana, podendo aumentar em 9 vezes em ambientes reais.
![Reanálise da arquitetura técnica da Solana: estará a chegar a segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Após a fragmentação dos dados pelo Turbine, é utilizado um mecanismo de propagação em múltiplas camadas para a transmissão. O nó líder entregará o bloco a qualquer validador de bloco antes do final de cada Slot, e então esse validador fragmentará o bloco em Shreds e gerará códigos de correção. Em seguida, esse validador iniciará a propagação do Turbine. Primeiro, deve ser propagado até o nó raiz, e então esse nó raiz determinará quais validadores estão em qual camada. O processo é como segue:
Criar lista de nós: O nó raiz reunirá todos os validadores ativos em uma lista e, em seguida, os ordenará com base na participação de cada validador na rede, que é a quantidade de SOL em staking ), sendo que os de maior peso ficarão na primeira camada, e assim por diante.
Agrupamento de nós: em seguida, cada validador localizado na primeira camada também criará sua própria lista de nós para construir sua própria primeira camada.
Formação de Camadas: Dividir os nós em camadas a partir do topo da lista, determinando dois valores: profundidade e largura, pode definir a forma geral da árvore, e este parâmetro afetará a taxa de propagação dos shreds.
Os nós com uma alta proporção de participação, ao serem classificados em camadas, estarão em um nível superior, o que lhes permitirá receber os shreds completos antecipadamente. Nesse momento, será possível recuperar o bloco completo, enquanto os nós das camadas inferiores, devido à perda de transmissão, terão uma probabilidade reduzida de obter shreds completos. Se esses shreds forem insuficientes para construir fragmentos completos, exigirá que o Líder retransmita diretamente. Assim, a transmissão de dados ocorrerá internamente na árvore, e os nós da primeira camada já terão construído a confirmação do bloco completo. Quanto mais tempo levar para os validadores das camadas inferiores completarem a construção do bloco, mais tempo demorará para a votação.
A ideia deste mecanismo é semelhante ao mecanismo de um único nó do nó líder. No processo de propagação do bloco, existem também alguns nós prioritários, que são os primeiros a receber os shreds para formar blocos completos e alcançar o processo de consenso de votação. Levar a redundância a um nível mais profundo pode acelerar significativamente a realização da Finalidade e maximizar a taxa de transferência e a eficiência. Porque, na verdade, as primeiras camadas podem representar 2/3 dos nós, então o voto dos nós subsequentes se torna irrelevante.
( SVM
A Solana consegue processar milhares de transações por segundo, principalmente devido ao seu mecanismo POH, ao consenso Tower BFT e ao mecanismo de propagação de dados Turbine. No entanto, como a SVM é a máquina virtual para a transição de estados, se o nó líder estiver executando transações e a velocidade de processamento da SVM for lenta, isso diminuirá a capacidade de throughput de todo o sistema. Portanto, em relação à SVM, a Solana propôs o motor de execução paralelo Sealevel para acelerar a velocidade de execução das transações.
![Revisit the Solana technical architecture: Will it迎来第二春吗？])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp###
No SVM, as instruções consistem em 4 partes, incluindo o ID do programa, instruções do programa e uma lista de contas para leitura/gravação de dados. Ao determinar se a conta atual está em estado de leitura ou gravação e se as operações que vão mudar o estado conflitam, é possível permitir a paralelização das instruções de transação da conta onde não há conflito de estado, cada instrução é representada pelo Program ID. E essa é também uma das razões pelas quais os requisitos para os validadores da Solana são tão altos, pois exige que a GPU/CPU do validador suporte SIMD( instruções múltiplas de dados únicas) e capacidades AVX de extensões vetoriais avançadas.
Desenvolvimento Ecológico
No atual processo de desenvolvimento do ecossistema Solana, há uma tendência crescente para a utilidade prática, como Blinks e Actions, até mesmo Solana Mobile, enquanto a direção de desenvolvimento das aplicações apoiadas oficialmente também se inclina mais para aplicativos de consumo, em vez da infinita competição em torno da infraestrutura. Com o desempenho atual da Solana sendo suficiente, a variedade de aplicações é mais rica. No caso do Ethereum, devido ao seu TPS mais baixo, o ecossistema Ethereum ainda é dominado por infraestrutura e tecnologias de escalabilidade; quando a infraestrutura não pode suportar as aplicações, não é possível construir aplicações para o consumidor, o que resulta em um estado de desequilíbrio, onde há um investimento excessivo em infraestrutura, mas um investimento insuficiente em aplicações.
( DeFi
Nos protocolos DeFi na Solana, há uma grande quantidade de projetos que ainda não emitiram tokens, incluindo Kamino) primeiro Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, entre outros. Devido à atmosfera de união do ecossistema da Solana, geralmente, quando um projeto está prestes a emitir tokens, outros projetos tentam evitar o mesmo período para atrair atenção suficiente do mercado.
Atualmente, a competição em todo o DEX é intensa, e seu líder também passou por várias migrações, de Raydium, Orca até agora um certo DEX dominando.
É importante notar que cerca de 50% das transações DEX são realizadas por bots MEV.