Análise da Arquitetura Técnica e Desenvolvimento do Ecossistema Solana

Solana é uma plataforma de blockchain de alto desempenho, que utiliza uma arquitetura tecnológica única para alcançar alta taxa de transferência 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. Todos esses são elementos do design de arquitetura de alto desempenho da Solana, mas também trouxeram alguns problemas, como interrupções na rede, falhas nas transações, problemas MEV, crescimento excessivo do estado e questões 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/AI e aplicações para consumidores. A alta TPS da Solana e a sua estratégia voltada para aplicações para consumidores, juntamente com um ambiente ecológico com efeitos de marca relativamente fracos, oferecem ricas oportunidades de empreendedorismo para empreendedores e desenvolvedores. No que diz respeito às aplicações para consumidores, a Solana demonstrou a sua visão para impulsionar a aplicação da tecnologia blockchain em áreas mais amplas. Através do apoio a iniciativas como a Solana Mobile e a construção de SDKs especificamente para aplicações para consumidores, a Solana está empenhada em integrar a tecnologia blockchain nas aplicações do dia a dia, aumentando assim a aceitação e a conveniência para os utilizadores.

Embora a Solana tenha conquistado uma quota de mercado significativa na indústria de blockchain devido à sua alta capacidade de processamento e baixos custos de transação, também enfrenta uma concorrência acirrada de outras blockchains emergentes. A Base, como um concorrente potencial dentro do ecossistema EVM, está vendo um rápido crescimento no número de endereços ativos na sua cadeia. Ao mesmo tempo, embora o total bloqueado no DeFi da Solana tenha atingido um novo recorde histórico com (TVL), concorrentes como a Base também estão rapidamente conquistando participação de mercado, e o volume de financiamento no ecossistema da Base superou pela primeira vez a da Solana no segundo trimestre.

Apesar de a Solana ter alcançado certos sucessos em termos de tecnologia e aceitação no mercado, ela precisa de inovação e melhorias constantes para enfrentar os desafios de concorrentes como a Base. Em particular, no que diz respeito a aumentar a estabilidade da rede, reduzir a taxa de falhas nas transações, resolver o problema do MEV e desacelerar a taxa de 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

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 tecnologia POH origina-se da mais básica criptografia SHA256. A SHA256 é geralmente utilizada para calcular a integridade dos dados, dado uma entrada X, há e somente há uma saída Y única, 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 aplicando o algoritmo sha256, o que também determina a integridade das transações contidas. Por exemplo, se empacotarmos as transações em um bloco e gerarmos o valor hash sha256 correspondente, as transações dentro desse bloco são então confirmadas; qualquer alteração resultará em uma mudança no valor hash. Em seguida, esse hash do bloco será utilizado como parte do X da próxima função sha256, adicionando o hash do próximo bloco. Assim, tanto o bloco anterior quanto o próximo são confirmados, e qualquer alteração resultará em um novo Y diferente.

No diagrama 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ó Leader entre todos os validadores da cadeia, que coleta as transações, realiza a ordenação e execução, gerando a sequência POH, e, em seguida, gera um bloco que é propagado para outros nós.

Para evitar falhas 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, e em cada slot, o sistema de rotação alocará um nó Leader, que deve publicar o bloco)400ms( dentro do tempo do slot designado, caso contrário, esse slot será pulado e o próximo nó Leader para o slot será reeleito.

De uma forma geral, o nó Leader que utiliza o mecanismo POH permite que todas as transações históricas sejam confirmadas. A unidade básica de tempo da Solana é o Slot, e o nó Leader precisa transmitir o bloco 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, em seguida, executa para gerar o bloco, que é propagado para outros validadores. Os validadores precisam alcançar um consenso através de um mecanismo para concordar com 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 vem do algoritmo de consenso BFT, sendo uma implementação concreta deste. Este algoritmo ainda está relacionado com o algoritmo POH. Quando se vota em um bloco, se o voto do validador for em si uma transação, então o hash do bloco formado pela transação do usuário e pela transação do validador também pode servir como prova histórica, podendo ser confirmados de forma única os detalhes da transação de cada usuário e os detalhes do voto do validador.

![Revisitar a arquitetura técnica da Solana: estará a caminho de uma segunda primavera?]###panews/images/90Jj8P8FH5.webp(

No algoritmo Tower BFT, é estipulado que se todos os validadores votarem no 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 hashes para confirmar o bloco. No entanto, nos mecanismos de consenso tradicionais, geralmente é utilizado o método de inundação de blocos, onde um validador que recebe um bloco o envia para os validadores ao redor, o que resulta em uma grande redundância na rede, pois um validador recebe o mesmo bloco mais de uma vez.

No Solana, devido à grande quantidade de transações de votação dos validadores e à eficiência trazida pela centralização dos nós líderes, bem como ao tempo de Slot de 400ms, isso resulta em um tamanho de bloco geral e uma frequência de produção de blocos particularmente altos. Blocos grandes, ao serem propagados, também podem causar uma grande pressão na rede. O Solana utiliza o mecanismo Turbine para resolver o problema de propagação de grandes blocos.

) Turbine

Os nós líder dividem os blocos em sub-blocos chamados shreds através de um processo denominado Sharding, cujo tamanho padrão é o MTU###, 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 seguida, utiliza-se o esquema de código de eliminação Reed-Solomon para garantir a integridade e a disponibilidade dos dados.

Ao dividir o bloco em quatro Data Shreds, e para prevenir a perda e danos durante a transmissão de dados, é utilizado o código Reed-Solomon para codificar os quatro pacotes em oito pacotes, permitindo uma tolerância de até 50% de taxa de perda. Nos testes práticos, a taxa de perda da Solana é de cerca de 15%, portanto, este esquema é bem compatível com a arquitetura atual da Solana.

Na transferência de dados em nível inferior, geralmente considera-se o uso de protocolos UDP/TCP. Devido à alta tolerância da Solana à taxa de perda de pacotes, o protocolo UDP é utilizado para a transmissão, cuja desvantagem é que não há retransmissão em caso de perda de pacotes, 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 significativamente a taxa de transmissão e a capacidade de processamento. Com a implementação de Reed-Solomon, esse sistema pode aumentar significativamente a capacidade de processamento da Solana, podendo aumentar em 9 vezes em ambientes reais.

Após o Turbine fragmentar os dados, utiliza um mecanismo de propagação em várias camadas para realizar a disseminaçã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 de erro. Depois, o validador iniciará a propagação do Turbine. Primeiro, precisa ser propagado até o nó raiz, e então esse nó raiz determinará quais validadores estão em qual camada. O processo é o seguinte:

1. Criar lista de nós: o nó raiz irá compilar todos os validadores ativos em uma lista e, em seguida, classificar com base na participação de cada validador na rede ), ou seja, na quantidade de SOL em stake (, com os pesos mais altos localizados na primeira camada, e assim por diante.

2. Agrupamento de nós: Em seguida, cada validador na primeira camada também criará sua própria lista de nós para construir sua própria primeira camada.

3. Formação de camadas: Dividir os nós em camadas a partir do topo da lista, determinando dois valores: profundidade e largura, pode determinar a forma geral da árvore. Este parâmetro afetará a taxa de propagação dos shreds.

![再解Solana技术架构：将要迎来第二春吗？])panews/images/iQ41c4b6DM.webp(

Os nós com uma alta proporção de direitos, ao serem classificados em níveis, estarão em um nível superior, permitindo que recebam os shreds completos antecipadamente. Nesse momento, será possível restaurar o bloco completo, enquanto os nós em níveis inferiores, devido à perda de transmissão, terão uma probabilidade reduzida de obter shreds completos. Se esses shreds não forem suficientes para construir fragmentos completos, o líder solicitará uma retransmissão direta. Nesse momento, a transmissão de dados ocorrerá internamente na árvore, enquanto os nós da primeira camada já terão confirmado a construção do bloco completo. Quanto mais tempo passar após os validadores dos níveis inferiores completarem a construção do bloco, mais tempo levará para votar.

A ideia deste mecanismo é semelhante à mecânica de um único nó do nó líder. Durante o processo de propagação de blocos, também existem alguns nós prioritários, que são os primeiros a receber os shreds para compor blocos completos a fim de 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, os primeiros níveis podem representar 2/3 dos nós, então o voto 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 transformação de estados, se o nó líder estiver executando transações e a SVM tiver uma velocidade de processamento mais lenta, isso reduzirá a taxa de transferência de todo o sistema. Portanto, em relação à SVM, a Solana propôs o motor de execução paralela Sealevel para acelerar a velocidade de execução das transações.

No SVM, as instruções são compostas por 4 partes, incluindo o ID do programa, instruções do programa e a lista de contas para leitura/escrita de dados. Ao determinar se a conta atual está em estado de leitura ou escrita e se as operações que devem ser realizadas para mudar o estado estão em conflito, é possível permitir a paralelização das instruções de transação da conta onde não há 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 do validador possa suportar SIMD### instrução única múltiplos dados( e a capacidade de extensões vetoriais avançadas AVX.

![Revisitar a arquitetura técnica da Solana: irá迎来第二春吗？])panews/images/Czi5MR4h94.webp(

Desenvolvimento Ecológico

No atual processo de desenvolvimento do ecossistema Solana, há uma crescente tendência 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 aplicações de consumo, em vez de uma competição infinita em infraestrutura. Com o desempenho suficiente da Solana atualmente, a variedade de aplicações é mais rica. No caso do Ethereum, devido ao seu TPS relativamente baixo, o ecossistema Ethereum ainda é predominantemente focado em infraestrutura e tecnologias de escalabilidade. Quando a infraestrutura não pode suportar aplicações, não é possível construir aplicações de consumo, 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 que ainda não emitiram tokens, incluindo Kamino### Primeiro Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora, entre outros. Devido à atmosfera de ecossistema unificada da Solana, geralmente um projeto evita lançar tokens ao mesmo tempo que outros projetos, a fim de atrair a atenção 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 Jupiter como principal.

É importante notar que cerca de 50% das transações da DEX são iniciadas por bots MEV, principalmente devido às suas baixas taxas e à atividade de transações Meme que favorecem a lucratividade do MEV. E isso também é uma das principais razões para a frequência de falhas nas transações em picos de usuários e quedas.

O protocolo DeFi na Solana acompanhou a subida do preço do SOL, e seu TVL nominal em USD também teve um aumento explosivo. A tendência de aumento do TVL ainda não parou, formando uma nova onda de tendência de alta.

![Revisitar a arquitetura técnica do Solana: estará a caminho de uma segunda primavera?])