Análise da Arquitetura Técnica do Solana: Vem aí uma segunda primavera?

Solana é uma plataforma de blockchain de alto desempenho, que adota uma arquitetura técnica única para alcançar alta taxa de transferência e baixa latência. Sua tecnologia central inclui o algoritmo Proof of History (POH) que garante a ordem das transações e um relógio global, o Leader Rotation Schedule 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. O Solana Virtual Machine (SVM) e o motor de execução paralela Sealevel aceleram a velocidade de execução das transações. Estes são todos os designs de arquitetura de alta performance do Solana, mas também trouxeram alguns problemas, como quedas de rede, falhas de transações, problemas de MEV, crescimento excessivo do estado e problemas de centralização.

O ecossistema Solana está se desenvolvendo rapidamente, com vários indicadores de dados crescendo rapidamente no primeiro semestre, especialmente nas áreas de DeFi, infraestrutura, GameFi/NFT, DePin/AI e aplicações para consumidores. A alta TPS da Solana e sua estratégia voltada para aplicações para consumidores, 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 para consumidores, a Solana demonstrou sua visão de promover a aplicação da tecnologia blockchain em uma gama mais ampla de campos. Ao apoiar iniciativas como Solana Mobile e construir SDKs especificamente para aplicativos de consumidores, a Solana está se comprometendo a integrar a tecnologia blockchain em aplicações do dia a dia, aumentando assim a aceitação e conveniência para os usuários. Por exemplo, aplicativos como Stepn oferecem experiências inovadoras de fitness e sociais aos usuários ao combinar blockchain e tecnologia móvel. Embora atualmente muitos aplicativos para consumidores ainda estejam explorando os melhores modelos de negócios e posicionamento no mercado, a plataforma tecnológica e o suporte do ecossistema oferecido pela Solana sem dúvida fornecem um forte respaldo para essas tentativas inovadoras. Com o avanço contínuo da tecnologia e a maturação do mercado, a Solana deve alcançar mais avanços e casos de sucesso na área de aplicações para consumidores.

Embora a Solana tenha conquistado uma participação de mercado significativa na indústria de blockchain devido à sua alta capacidade de processamento e baixos custos de transação, ela também enfrenta uma intensa concorrência de outras novas blockchains. A Base, como um potencial concorrente no ecossistema EVM, está vendo um rápido crescimento no número de endereços ativos na cadeia, enquanto o valor total bloqueado (TVL) no setor DeFi da Solana, (TVL), embora tenha alcançado um recorde histórico, também enfrenta concorrência rápida de rivais como a Base, que pela primeira vez superou a Solana em termos de volume de financiamento no ecossistema no segundo trimestre.

Apesar de a Solana ter alcançado certos feitos em termos de tecnologia e aceitação no mercado, ela precisa continuar inovando e melhorando para enfrentar os desafios de concorrentes como a Base. Especialmente nas áreas de 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

Solana é conhecida por seu algoritmo POH, mecanismo de consenso Tower BFT, rede de transmissão de dados Trubine e pela alta TPS e rápida Finalidade proporcionadas pela máquina virtual SVM. Vamos apresentar brevemente como cada componente funciona, como eles desempenham seu objetivo de alto desempenho para o design de arquitetura, bem como as desvantagens e problemas derivados dessa arquitetura.

algoritmo POH

POH(Prova de História) é 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 é derivada da tecnologia criptográfica mais básica, SHA256. SHA256 é geralmente usado 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 aplicação do algoritmo sha256 garante a integridade de toda a sequência, o que também determina a integridade das transações nela. Por exemplo, se embalarmos as transações em um bloco e gerarmos o valor hash sha256 correspondente, as transações dentro desse bloco são então determinadas; qualquer alteração resultará em uma alteração no valor hash. 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 os blocos anterior e seguinte estarão determinados, e qualquer alteração resultará em um novo Y diferente.

Este é o significado central da sua tecnologia Proof of History, o hash do bloco anterior será parte da próxima função sha256, semelhante a uma cadeia, o mais recente Y sempre contém a prova da história.

No diagrama de fluxo de transações da Solana, é descrito o processo de transação 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, realiza a ordenação e execução, gerando a sequência POH, e em seguida, cria 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 400ms. Em cada slot, o sistema de rotação atribui um nó Leader, que deve publicar o bloco)400ms( dentro do tempo do slot dado, caso contrário, esse slot será pulado e o próximo nó Leader para o próximo slot será reeleito.

Em geral, os nós Leader que adotam o mecanismo POH podem garantir todas as transações históricas. A unidade básica de tempo do Solana é o Slot, e os nós Leader precisam transmitir blocos dentro de um slot. Os usuários enviam transações para o Leader através de nós RPC, o nó Leader empacota as transações, ordena e executa para gerar blocos, que são então propagados para outros validadores. Os validadores precisam alcançar um consenso através de um mecanismo, concordando com as transações e a ordem dentro do bloco; o consenso utilizado é o mecanismo de consenso Tower BFT.

) Mecanismo de consenso Tower BFT

O protocolo de consenso Tower BFT deriva do algoritmo de consenso BFT, sendo uma implementação específica desse algoritmo, que ainda está relacionado ao algoritmo POH. Ao votar em um bloco, se o voto do validador for, por si só, uma transação, então o hash do bloco formado pela transação do usuário e pela transação do validador pode também 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.

![Revisão da arquitetura técnica da Solana: está a caminho de uma segunda primavera?]###https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp(

No algoritmo Tower BFT é estipulado que, se todos os validadores votarem neste 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 grande quantidade de memória, pois apenas é necessário votar na sequência de hashes para confirmar o bloco. Porém, nos mecanismos de consenso tradicionais, geralmente é utilizada a inundação de blocos, onde um validador que recebeu o bloco o envia para os validadores ao redor, o que causa uma grande redundância na rede, já que 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 o tempo de Slot de 400ms, isso resulta em um tamanho de bloco total e uma frequência de criação de blocos especialmente altas. 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 da propagação de grandes blocos.

) Turbine

O nó líder divide o bloco em subblocos chamados shreds através de um processo denominado Sharding, com o tamanho especificado em 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, com uma unidade de (. Em seguida, utiliza-se o esquema de código de apagamento Reed-Solomon para garantir a integridade e a disponibilidade dos dados.

Ao dividir o bloco em quatro Data Shreds, e para evitar a perda e danos durante a transmissão de dados, utiliza-se a codificação Reed-Solomon para codificar os quatro pacotes em oito pacotes, permitindo tolerar até 50% de taxa de perda. Nos testes reais, a taxa de perda do Solana é de aproximadamente 15%, portanto, este esquema é bem compatível com a arquitetura atual do Solana.

![Revisitar a arquitetura técnica da Solana: estará a caminho de uma segunda primavera?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Na transmissão de dados subjacente, 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. Sua desvantagem é 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 processamento. Com a Reed-Solomon, esse conjunto de soluções pode aumentar significativamente a capacidade de processamento do Solana, podendo aumentar em até 9 vezes em ambientes reais.

Após dividir os dados, o Turbine utiliza um mecanismo de propagação em várias camadas para disseminá-los. O nó líder entregará o bloco a qualquer validador de bloco antes do final de cada slot, e então esse validador dividirá o bloco em Shreds e gerará códigos de correção. Após isso, o 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 é mostrado a seguir:

1. Criar lista de nós: O nó raiz irá compilar todos os validadores ativos em uma lista, e depois irá classificá-los com base na participação de cada validador na rede ), ou seja, a quantidade de SOL em stake (, onde os que têm maior peso estarão na primeira camada, e assim por diante.

2. 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.

3. 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, este parâmetro afetará a taxa de propagação dos shreds.

Os nós com uma alta proporção de direitos, ao serem classificados em níveis, estarão em um nível superior, podendo assim obter os shreds completos antecipadamente. Nesse momento, será possível recuperar o bloco completo. Por outro lado, os nós em níveis inferiores, devido à perda durante a 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 caso, a transmissão de dados ocorrerá internamente na árvore, enquanto os nós do primeiro nível já terão construído a confirmação do bloco completo, aumentando assim o tempo necessário para que os validadores de níveis inferiores concluam a construção do bloco e votem.

A ideia deste mecanismo é semelhante ao mecanismo 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 obter os shreds para formar blocos completos e alcançar o consenso de votação. Aumentar a redundância em níveis mais profundos pode acelerar significativamente a Finalidade e maximizar a capacidade de processamento e eficiência. Na verdade, as primeiras camadas podem representar 2/3 dos nós, tornando a votação dos nós subsequentes 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 reduzirá a capacidade de todo o sistema. Portanto, em relação à SVM, a Solana apresentou o motor de execução paralela Sealevel para acelerar a velocidade de execução das transações.

![Revisitando a arquitetura técnica da Solana: estará a caminho de uma segunda primavera?]###https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp(

No SVM, as instruções são compostas por 4 partes, incluindo o ID do programa, as instruções do programa e a lista de contas que leem/escrevem dados. Ao determinar se a conta atual está em estado de leitura ou escrita e se as operações que estão a ser realizadas para alterar o estado têm conflitos, é possível permitir a paralelização das 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 elevados, pois exige que os GPUs/CPUs dos validadores suportem SIMD) de instrução única e múltiplos dados( e a capacidade de extensão vetorial avançada AVX.

Desenvolvimento Ecológico

No atual processo de desenvolvimento do ecossistema Solana, está cada vez mais voltado 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 está mais voltada para aplicações voltadas para o consumidor, e não para a infraestrutura.