Análise da arquitetura técnica da Solana: virá a segunda primavera?
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 que aumentam a taxa de produção de blocos. O mecanismo Turbine otimiza a propagação de grandes blocos através da 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. Essas são todas as características do design da arquitetura de alto desempenho da Solana, mas ao mesmo tempo, também trouxeram alguns problemas, como quedas de rede, falhas de 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 de forma acentuada no primeiro semestre, especialmente nas áreas de DeFi, infraestrutura, GameFi/NFT, DePin/IA e aplicações para consumidores. A alta TPS da Solana e a sua estratégia voltada para aplicações de consumidores, juntamente com um ambiente ecológico com menor efeito de marca, oferecem ricas oportunidades de empreendedorismo para empreendedores e desenvolvedores. Na área de aplicações para consumidores, a Solana demonstrou a sua visão de promover a aplicação da tecnologia blockchain em áreas mais amplas. Ao apoiar iniciativas como a Solana Mobile e construir SDKs especificamente para aplicações de consumidores, 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 utilizadores.
Apesar de Solana ter conquistado uma quota de mercado significativa na indústria de blockchain com sua alta capacidade de processamento e baixos custos de transação, ela enfrenta uma competição intensa de outras novas blockchains. Base, como um potencial concorrente no ecossistema EVM, está rapidamente aumentando o número de endereços ativos na sua blockchain, enquanto o valor total bloqueado (TVL) de Solana no setor DeFi, embora tenha atingido um recorde histórico de (, enfrenta uma rápida competição de concorrentes como a Base, que também ultrapassou Solana pela primeira vez em financiamento 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, em áreas como a melhoria da estabilidade da rede, a redução da taxa de falhas nas transações, a resolução de problemas de MEV e a desaceleração do crescimento do estado, a Solana precisa otimizar continuamente sua arquitetura técnica e seus 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 e a rede de transmissão de dados Trubine e a máquina virtual SVM, que proporcionam alta TPS e rápida Finalidade. Vamos apresentar brevemente como cada um desses componentes funciona, como eles atingem o objetivo de alto desempenho na arquitetura de design e quais são as desvantagens e problemas decorrentes dessa arquitetura.
) algoritmo POH
POH###Prova de História( é uma técnica que determina o tempo global, não sendo um mecanismo de consenso, mas sim um algoritmo que determina a ordem das transações. A técnica POH origina-se da tecnologia criptográfica básica SHA256. A SHA256 é geralmente utilizada para calcular a integridade dos dados, dado um input X, existe e apenas existe uma saída única Y, portanto, qualquer alteração em X resultará em um Y completamente diferente.
Na sequência POH da Solana, a integridade de toda a sequência pode ser garantida através da aplicação do algoritmo sha256, o que também garante a integridade das transações. Por exemplo, se empacotarmos as transações em um bloco e gerarmos o hash sha256 correspondente, então as transações dentro desse bloco estão determinadas, qualquer alteração resultará em uma mudança no hash, e em seguida, esse hash do bloco será usado 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 estarão determinados, qualquer alteração resultará em um novo Y diferente.
Este é o significado central da sua tecnologia Proof of History, o hash do bloco anterior servirá como parte da próxima função sha256, semelhante a uma cadeia, o mais recente Y sempre contém a prova da história.
![Reinterpretar a arquitetura técnica da Solana: estará a caminho de uma segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
No diagrama da arquitetura de fluxo de transações da Solana, descreve-se o fluxo de transações sob o mecanismo POH. Em um mecanismo de rotação chamado Leader Rotation Schedule, é gerado um nó líder entre todos os validadores da cadeia. Este nó líder coleta transações, as ordena e executa, gerando uma sequência POH, e em seguida, um bloco é gerado e disseminado 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 400ms. Em cada slot, o sistema de rodízio alocará um nó Leader, que deve publicar um bloco(400ms) dentro do tempo do slot dado, caso contrário, esse slot será pulado e será reeleito um novo nó Leader para o próximo slot.
De um modo geral, os nós Leader que adotam o mecanismo POH conseguem confirmar todas as transações históricas. A unidade básica de tempo do 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 depois executa para gerar blocos, que são propagados para outros validadores. Os validadores precisam alcançar um consenso sobre as transações dentro do bloco e sua ordem, sendo que o mecanismo de consenso utilizado é o Tower BFT.
( Mecanismo de consenso Tower BFT
O protocolo de consenso Tower BFT é uma implementação concreta 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, permitindo a confirmação única dos detalhes da transação de cada usuário e dos detalhes do voto do validador.
![Revisitar a arquitetura técnica da Solana: está prestes a ter um segundo renascimento?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.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 muita memória, pois apenas é necessário votar na sequência de hash para confirmar o bloco. No entanto, nos mecanismos de consenso tradicionais, geralmente é utilizado o inundação de blocos, onde um validador que recebe um bloco o envia para os validadores ao seu redor, o que resulta em uma grande redundância na rede, pois um validador recebe o mesmo bloco mais de uma vez.
Em Solana, devido à existência de um grande número de transações de votação dos validadores e à eficiência trazida pela centralização dos nós Leader, bem como o tempo de Slot de 400ms, isso resulta em um tamanho de bloco geral e uma frequência de emissão de blocos particularmente alta. Blocos grandes, ao serem propagados, também exercem uma grande pressão na rede. Solana utiliza o mecanismo Turbine para resolver o problema de propagação de grandes blocos.
( Turbine
Os nós Leader dividem os blocos em sub-blocos chamados shreds através de um processo chamado Sharding, cuja especificação de tamanho é 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, em unidades de ###. Em seguida, a integridade e disponibilidade dos dados são garantidas através do uso do esquema de códigos de apagamento Reed-Solomon.
Ao dividir o bloco em quatro Data Shreds, e depois, para evitar perda e corrupção de dados durante a transmissão, utiliza-se a codificação Reed-Solomon para codificar os quatro pacotes em oito pacotes. Este esquema pode tolerar uma taxa de perda de até 50%. Nos testes reais, a taxa de perda do Solana é de cerca de 15%, portanto este esquema é bem compatível com a arquitetura atual do Solana.
Na transmissão de dados de baixo nível, geralmente se considera o uso dos protocolos UDP/TCP. Devido à alta tolerância à perda de pacotes do Solana, foi adotado o protocolo UDP para a transmissão. Seu ponto fraco é que, em caso de perda de pacotes, não há retransmissão, mas a vantagem é uma taxa de transmissão mais rápida. Em contrapartida, 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 o Reed-Solomon, este conjunto de soluções pode aumentar significativamente o throughput do Solana, sendo que em ambientes reais, o throughput pode aumentar 9 vezes.
Após o Turbine fragmentar os dados, ele utiliza 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. Após isso, o validador iniciará a propagação do Turbine. Primeiro, a propagação deve alcançar o nó raiz, que então determinará quais validadores estão em qual camada. O processo é mostrado a seguir:
Criar lista de nós: o nó raiz irá compilar todos os validadores ativos em uma lista, e depois classificar os validadores com base na participação de cada um na rede (, ou seja, na quantidade de SOL apostada ), com os pesos mais altos 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: A partir do topo da lista, os nós são divididos em camadas. Ao determinar dois valores, profundidade e largura, é possível determinar a forma geral da árvore. 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 níveis, ficam em um nível superior, podendo assim obter as shreds completas antecipadamente. Nesse momento, é possível recuperar o bloco completo, enquanto os nós em níveis inferiores, devido à perda de transmissão, terão uma menor probabilidade de obter shreds completas. Se essas shreds não forem suficientes para construir fragmentos completos, o líder solicitará uma retransmissão direta. Portanto, a transmissão de dados ocorrerá internamente na árvore, e os nós do primeiro nível já terão confirmado a construção do bloco completo, o que significa que quanto mais tempo passar até que os validadores dos níveis inferiores completem a construção do bloco e votem, mais tempo levará.
O pensamento por trás deste mecanismo é semelhante ao mecanismo de nó único do nó líder. Durante o processo de propagação de blocos, existem alguns nós prioritários; esses nós obtêm os fragmentos shreds primeiro para formar blocos completos e alcançar o processo de consenso de votação. Empurrar a redundância para níveis mais profundos pode acelerar significativamente a Finalidade e maximizar a capacidade e a eficiência. Porque, na verdade, as primeiras camadas podem representar 2/3 dos nós, então a votação dos nós subsequentes torna-se irrelevante.
( SVM
A Solana pode 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 processamento de todo o sistema. Portanto, para a SVM, a Solana propôs o motor de execução paralela Sealevel para acelerar a velocidade de execução das transações.
![Revisitar a arquitetura técnica do Solana: estará a caminho de uma segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.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 ler/escrever dados. Ao determinar se a conta atual está em estado de leitura ou escrita e se a operação que deve ser alterada de estado tem conflitos, pode-se permitir a paralelização de instruções de transação da conta que não têm conflitos de estado, com cada instrução representada pelo ID do Programa. E esta 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 dos validadores suporte capacidades SIMD( de única instrução múltiplos dados) e capacidades AVX de extensões vetoriais avançadas.
Desenvolvimento Ecológico
No atual processo de desenvolvimento do ecossistema Solana, há uma crescente inclinação para a utilidade prática, como Blinks, Actions e até mesmo Solana Mobile. A direção de desenvolvimento das aplicações apoiadas oficialmente também está mais voltada para programas de consumidor, em vez de uma infinita competição interna em relação à infraestrutura. Com o desempenho atual suficiente da Solana, a variedade de aplicações é mais rica. No caso do Ethereum, devido ao seu baixo TPS, o ecossistema Ethereum ainda é principalmente focado em infraestrutura e tecnologias de escalabilidade. Quando a infraestrutura não consegue suportar 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, existem muitos projetos sem token emitido, incluindo Kamino) primeiro Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, entre outros. Devido à atmosfera de união do ecossistema Solana, normalmente um projeto evita coincidir com o lançamento de tokens de outros projetos, a fim de atrair a atenção suficiente do mercado.
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.
17 Curtidas
Recompensa
17
10
Repostar
Compartilhar
Comentário
0/400
GateUser-2fce706c
· 08-01 04:55
Todos estão esperando por esta onda de fundo. Os que não entendem ainda estão hesitando. Já foi dito que agora é uma boa oportunidade para se posicionar.
Ver originalResponder0
MidsommarWallet
· 08-01 02:18
sol é difícil de falar, vamos deixar de lado o longo e curto.
Ver originalResponder0
SmartContractRebel
· 07-31 10:04
Fala-se muito, é melhor negociar mais moedas.
Ver originalResponder0
ApeWithNoChain
· 07-29 20:43
Estou muito otimista com o sol!
Ver originalResponder0
SigmaBrain
· 07-29 20:43
Bull, essa onda de dinheiro pode ser lucrativa.
Ver originalResponder0
MevHunter
· 07-29 20:41
Tsk tsk, ainda temos que deixar a tecnologia falar.
Ver originalResponder0
MiningDisasterSurvivor
· 07-29 20:33
Quando a exchange reiniciar, é melhor esperar pela liquidação.
Ver originalResponder0
WalletWhisperer
· 07-29 20:22
padrões de transação indicam que o sol atingiu o fundo... fase de acumulação detectada fr
Análise técnica do Solana e desenvolvimento do ecossistema: a arquitetura de alto desempenho pode ajudar a ressurgir novamente
Análise da arquitetura técnica da Solana: virá a segunda primavera?
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 que aumentam a taxa de produção de blocos. O mecanismo Turbine otimiza a propagação de grandes blocos através da 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. Essas são todas as características do design da arquitetura de alto desempenho da Solana, mas ao mesmo tempo, também trouxeram alguns problemas, como quedas de rede, falhas de 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 de forma acentuada no primeiro semestre, especialmente nas áreas de DeFi, infraestrutura, GameFi/NFT, DePin/IA e aplicações para consumidores. A alta TPS da Solana e a sua estratégia voltada para aplicações de consumidores, juntamente com um ambiente ecológico com menor efeito de marca, oferecem ricas oportunidades de empreendedorismo para empreendedores e desenvolvedores. Na área de aplicações para consumidores, a Solana demonstrou a sua visão de promover a aplicação da tecnologia blockchain em áreas mais amplas. Ao apoiar iniciativas como a Solana Mobile e construir SDKs especificamente para aplicações de consumidores, 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 utilizadores.
Apesar de Solana ter conquistado uma quota de mercado significativa na indústria de blockchain com sua alta capacidade de processamento e baixos custos de transação, ela enfrenta uma competição intensa de outras novas blockchains. Base, como um potencial concorrente no ecossistema EVM, está rapidamente aumentando o número de endereços ativos na sua blockchain, enquanto o valor total bloqueado (TVL) de Solana no setor DeFi, embora tenha atingido um recorde histórico de (, enfrenta uma rápida competição de concorrentes como a Base, que também ultrapassou Solana pela primeira vez em financiamento 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, em áreas como a melhoria da estabilidade da rede, a redução da taxa de falhas nas transações, a resolução de problemas de MEV e a desaceleração do crescimento do estado, a Solana precisa otimizar continuamente sua arquitetura técnica e seus 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 e a rede de transmissão de dados Trubine e a máquina virtual SVM, que proporcionam alta TPS e rápida Finalidade. Vamos apresentar brevemente como cada um desses componentes funciona, como eles atingem o objetivo de alto desempenho na arquitetura de design e quais são as desvantagens e problemas decorrentes dessa arquitetura.
) algoritmo POH
POH###Prova de História( é uma técnica que determina o tempo global, não sendo um mecanismo de consenso, mas sim um algoritmo que determina a ordem das transações. A técnica POH origina-se da tecnologia criptográfica básica SHA256. A SHA256 é geralmente utilizada para calcular a integridade dos dados, dado um input X, existe e apenas existe uma saída única Y, portanto, qualquer alteração em X resultará em um Y completamente diferente.
Na sequência POH da Solana, a integridade de toda a sequência pode ser garantida através da aplicação do algoritmo sha256, o que também garante a integridade das transações. Por exemplo, se empacotarmos as transações em um bloco e gerarmos o hash sha256 correspondente, então as transações dentro desse bloco estão determinadas, qualquer alteração resultará em uma mudança no hash, e em seguida, esse hash do bloco será usado 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 estarão determinados, qualquer alteração resultará em um novo Y diferente.
Este é o significado central da sua tecnologia Proof of History, o hash do bloco anterior servirá como parte da próxima função sha256, semelhante a uma cadeia, o mais recente Y sempre contém a prova da história.
![Reinterpretar a arquitetura técnica da Solana: estará a caminho de uma segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
No diagrama da arquitetura de fluxo de transações da Solana, descreve-se o fluxo de transações sob o mecanismo POH. Em um mecanismo de rotação chamado Leader Rotation Schedule, é gerado um nó líder entre todos os validadores da cadeia. Este nó líder coleta transações, as ordena e executa, gerando uma sequência POH, e em seguida, um bloco é gerado e disseminado 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 400ms. Em cada slot, o sistema de rodízio alocará um nó Leader, que deve publicar um bloco(400ms) dentro do tempo do slot dado, caso contrário, esse slot será pulado e será reeleito um novo nó Leader para o próximo slot.
De um modo geral, os nós Leader que adotam o mecanismo POH conseguem confirmar todas as transações históricas. A unidade básica de tempo do 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 depois executa para gerar blocos, que são propagados para outros validadores. Os validadores precisam alcançar um consenso sobre as transações dentro do bloco e sua ordem, sendo que o mecanismo de consenso utilizado é o Tower BFT.
( Mecanismo de consenso Tower BFT
O protocolo de consenso Tower BFT é uma implementação concreta 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, permitindo a confirmação única dos detalhes da transação de cada usuário e dos detalhes do voto do validador.
![Revisitar a arquitetura técnica da Solana: está prestes a ter um segundo renascimento?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.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 muita memória, pois apenas é necessário votar na sequência de hash para confirmar o bloco. No entanto, nos mecanismos de consenso tradicionais, geralmente é utilizado o inundação de blocos, onde um validador que recebe um bloco o envia para os validadores ao seu redor, o que resulta em uma grande redundância na rede, pois um validador recebe o mesmo bloco mais de uma vez.
Em Solana, devido à existência de um grande número de transações de votação dos validadores e à eficiência trazida pela centralização dos nós Leader, bem como o tempo de Slot de 400ms, isso resulta em um tamanho de bloco geral e uma frequência de emissão de blocos particularmente alta. Blocos grandes, ao serem propagados, também exercem uma grande pressão na rede. Solana utiliza o mecanismo Turbine para resolver o problema de propagação de grandes blocos.
( Turbine
Os nós Leader dividem os blocos em sub-blocos chamados shreds através de um processo chamado Sharding, cuja especificação de tamanho é 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, em unidades de ###. Em seguida, a integridade e disponibilidade dos dados são garantidas através do uso do esquema de códigos de apagamento Reed-Solomon.
Ao dividir o bloco em quatro Data Shreds, e depois, para evitar perda e corrupção de dados durante a transmissão, utiliza-se a codificação Reed-Solomon para codificar os quatro pacotes em oito pacotes. Este esquema pode tolerar uma taxa de perda de até 50%. Nos testes reais, a taxa de perda do Solana é de cerca de 15%, portanto este esquema é bem compatível com a arquitetura atual do Solana.
Na transmissão de dados de baixo nível, geralmente se considera o uso dos protocolos UDP/TCP. Devido à alta tolerância à perda de pacotes do Solana, foi adotado o protocolo UDP para a transmissão. Seu ponto fraco é que, em caso de perda de pacotes, não há retransmissão, mas a vantagem é uma taxa de transmissão mais rápida. Em contrapartida, 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 o Reed-Solomon, este conjunto de soluções pode aumentar significativamente o throughput do Solana, sendo que em ambientes reais, o throughput pode aumentar 9 vezes.
Após o Turbine fragmentar os dados, ele utiliza 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. Após isso, o validador iniciará a propagação do Turbine. Primeiro, a propagação deve alcançar o nó raiz, que então determinará quais validadores estão em qual camada. O processo é mostrado a seguir:
Criar lista de nós: o nó raiz irá compilar todos os validadores ativos em uma lista, e depois classificar os validadores com base na participação de cada um na rede (, ou seja, na quantidade de SOL apostada ), com os pesos mais altos 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: A partir do topo da lista, os nós são divididos em camadas. Ao determinar dois valores, profundidade e largura, é possível determinar a forma geral da árvore. 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 níveis, ficam em um nível superior, podendo assim obter as shreds completas antecipadamente. Nesse momento, é possível recuperar o bloco completo, enquanto os nós em níveis inferiores, devido à perda de transmissão, terão uma menor probabilidade de obter shreds completas. Se essas shreds não forem suficientes para construir fragmentos completos, o líder solicitará uma retransmissão direta. Portanto, a transmissão de dados ocorrerá internamente na árvore, e os nós do primeiro nível já terão confirmado a construção do bloco completo, o que significa que quanto mais tempo passar até que os validadores dos níveis inferiores completem a construção do bloco e votem, mais tempo levará.
O pensamento por trás deste mecanismo é semelhante ao mecanismo de nó único do nó líder. Durante o processo de propagação de blocos, existem alguns nós prioritários; esses nós obtêm os fragmentos shreds primeiro para formar blocos completos e alcançar o processo de consenso de votação. Empurrar a redundância para níveis mais profundos pode acelerar significativamente a Finalidade e maximizar a capacidade e a eficiência. Porque, na verdade, as primeiras camadas podem representar 2/3 dos nós, então a votação dos nós subsequentes torna-se irrelevante.
( SVM
A Solana pode 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 processamento de todo o sistema. Portanto, para a SVM, a Solana propôs o motor de execução paralela Sealevel para acelerar a velocidade de execução das transações.
![Revisitar a arquitetura técnica do Solana: estará a caminho de uma segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.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 ler/escrever dados. Ao determinar se a conta atual está em estado de leitura ou escrita e se a operação que deve ser alterada de estado tem conflitos, pode-se permitir a paralelização de instruções de transação da conta que não têm conflitos de estado, com cada instrução representada pelo ID do Programa. E esta 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 dos validadores suporte capacidades SIMD( de única instrução múltiplos dados) e capacidades AVX de extensões vetoriais avançadas.
Desenvolvimento Ecológico
No atual processo de desenvolvimento do ecossistema Solana, há uma crescente inclinação para a utilidade prática, como Blinks, Actions e até mesmo Solana Mobile. A direção de desenvolvimento das aplicações apoiadas oficialmente também está mais voltada para programas de consumidor, em vez de uma infinita competição interna em relação à infraestrutura. Com o desempenho atual suficiente da Solana, a variedade de aplicações é mais rica. No caso do Ethereum, devido ao seu baixo TPS, o ecossistema Ethereum ainda é principalmente focado em infraestrutura e tecnologias de escalabilidade. Quando a infraestrutura não consegue suportar 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, existem muitos projetos sem token emitido, incluindo Kamino) primeiro Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora, entre outros. Devido à atmosfera de união do ecossistema Solana, normalmente um projeto evita coincidir com o lançamento de tokens de outros projetos, a fim de atrair a atenção suficiente do mercado.
Atualmente em todo o DEX