Introdução

“Nós sabíamos que menor, mais rápido, mais barato era melhor do que qualquer outra pessoa no mundo, e agora estamos aplicando esses conceitos à blockchain.” — Greg Fitzgerald, co-fundador da Solana

Solana é uma blockchain de alto desempenho e baixa latência, conhecida por sua velocidade, eficiência e foco na experiência do usuário. Sua arquitetura integrada única permite milhares de transações por segundo em uma rede descentralizada global. Com um tempo de bloco de 400 milissegundos e taxas de transação que são frações de um centavo, ela oferece tanto velocidade quanto custo-efetividade. Este relatório analisa as complexidades do design e operação da Solana, explorando os mecanismos-chave e a topologia de rede que contribuem para suas capacidades.

Solana adota uma abordagem integrada para o desenvolvimento de blockchain, aproveitando as décadas de experiência da equipe fundadora na construção de sistemas distribuídos. Um dos princípios fundamentais da Solana é que o software nunca deve atrapalhar o hardware. Isso significa que o software explora ao máximo o hardware em que é executado e escala com ele. Como um ecossistema unificado, todas as aplicações construídas nesta única blockchain herdam a composabilidade, permitindo que interajam e se desenvolvam mutuamente de forma contínua. Essa arquitetura também garante uma experiência do usuário direta e intuitiva, sem a necessidade de pontes, IDs de cadeias separadas ou fragmentação de liquidez.

Solana está evoluindo rapidamente, com desenvolvimentos recentes, incluindo agrupamentos SVM eCompressão ZKcomo soluções de escalabilidade importantes. Embora esses projetos possam um dia moldar nossa percepção futura da Solana, eles estão atualmente em estágios muito iniciais de desenvolvimento ou adoção e não serão abordados neste relatório.

Ciclo de Vida da Transação

Nossa principal lente para entender Solana ao longo deste relatório será o ciclo de vida de uma transação típica. Para construir um modelo básico para entender as transações Solana, podemos delinear o processo da seguinte forma:

• Os usuários iniciam transações, todas as quais são enviadas ao produtor de bloco líder atual (conhecido como o líder). O líder compila essas transações em um bloco, executando-as e, assim, atualizando seu estado local.
• Este bloco de transações é então propagado por toda a rede para que outros validadores executem e confirmem.

As seções subsequentes deste relatório irão expandir este modelo e aprofundar-se neste processo com muito mais detalhes, começando pelos participantes chave - os usuários.

Lembrar

Mudanças substanciais no protocolo central Solana passam por um processo formal e transparenteprocessode submeter um Documento de Melhoria da Solana (SIMD) que membros da comunidade e engenharia central irão criticar publicamente. Os SIMDs são então votados pela rede.

Seis estágios

Vamos fazer referência à visualização de seis etapas mostrada acima ao longo deste relatório, pois nos oferece um quadro consistente para entender as relações entre os elementos principais da Solana.

Os capítulos anteriores são organizados de acordo com essas seis etapas. Os capítulos finais - Fofoca, Arquivo, Economia e Jito - amarram quaisquer pontas soltas. É importante notar que alguns capítulos abrangerão várias etapas e algumas etapas aparecerão em vários capítulos.

Essa sobreposição é inevitável porque o framework de seis estágios tem suas limitações. Na realidade, Solana é um sistema distribuído complexo com muitos elementos interdependentes.

Usuários

“Solana tem o potencial de ser o Apple das criptomoedas” — Raj Gokal, co-fundador da Solana

A jornada de um usuário geralmente começa configurando e financiando um aplicativo de carteira. Várias aplicações de carteira populares estão disponíveis para Solana, seja como aplicativos móveis nativos ou extensões de navegador.

As carteiras geram criptograficamente pares de chaves do usuário, compostos por chaves pública e privada. A chave pública atua como o identificador único de sua conta e é conhecida por todos os participantes na rede. A conta de um usuário na Solana pode ser considerada uma estrutura de dados que contém informações e estado relacionados às suas interações com o blockchain da Solana. Dessa forma, uma chave pública é semelhante a um nome de arquivo: assim como um nome de arquivo identifica de forma única um arquivo dentro de um sistema de arquivos, uma chave pública da Solana identifica de forma única uma conta na blockchain da Solana. As chaves públicas na Solana são representadas como strings codificadas em Base58 de 32 bytes.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Uma chave privada - também conhecida como chave secreta - pode ser considerada como a senha ou chave de acesso que concede permissão para acessar e modificar a conta. Assinar com chaves privadas é como as blockchains lidam com autorização. O conhecimento da chave privada confere autoridade absoluta sobre a conta. As chaves privadas Solana também têm 32 bytes de comprimento. Os pares de chaves são combinações de 64 bytes de chaves públicas (primeira metade) e chaves privadas (segunda metade). Exemplos:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Chaves privadas também podem ser derivadas de frases semente mnemônicas, geralmente com 12 ou 24 palavras. Esse formato é frequentemente utilizado em carteiras para facilitar o backup e a recuperação. Múltiplas chaves podem ser derivadas de forma determinística a partir de uma única frase semente.

Solana utilizaEd25519, um algoritmo de assinatura digital de curva elíptica amplamente utilizado, para suas necessidades de criptografia de chave pública. Ed25519 é favorecido por seu pequeno tamanho de chave, pequeno tamanho de assinatura, cálculo rápido e imunidade a muitos ataques comuns. Cada endereço da carteira Solana representa um ponto na curva elíptica Ed25519.

O usuário assina transações com sua chave privada. Esta assinatura é incluída com os dados da transação e pode ser verificada por outros participantes usando a chave pública do remetente. Este processo garante que a transação não foi adulterada e é autorizada pelo proprietário da chave privada correspondente. A assinatura também age como um identificador único para a transação.

Transações Solana

Enviar uma transação é a única maneira de mutar o estado no Solana. Qualquer operação de escrita é realizada através de uma transação, e as transações são atômicas - ou tudo o que a transação tenta fazer acontece ou a transação falha. Uma transação, mais formalmente conhecida como uma "mensagem de transação," compreende quatro seções: um cabeçalho, uma lista de endereços de contas, um blockhash recente e instruções.

• Cabeçalho: O cabeçalho contém referências à lista de endereços da conta, indicando quais contas devem assinar a transação.
• Endereços de Conta: Esta lista inclui todas as contas que serão lidas ou escritas durante a transação. Construir essa lista para cada transação é um requisito único do Solana e pode ser desafiador para os desenvolvedores. No entanto, saber antecipadamente com quais partes do estado uma transação irá interagir permite otimizações não possíveis em muitas outras blockchains.
• Recente Blockhash: Isso é usado para evitar transações duplicadas e obsoletas. Um recente blockhash expira após 150 blocos (cerca de 1 minuto). Por padrão, as RPCs tentam encaminhar transações a cada 2 segundos até que a transação seja finalizada ou o recente blockhash expire, momento em que a transação é descartada.
• Instruções: Estas constituem a parte central da transação. Cada instrução representa uma operação específica (por exemplo, transferência, cunhagem, queima, criar conta, fechar conta). Cada instrução especifica o programa a ser executado, as contas necessárias e os dados necessários para a execução da instrução.

O número de instruções em uma transação é limitado primeiramente pelo seu tamanho, que pode ser de até 1.232 bytes. Também existem limites em relação ao número de contas que podem ser referenciadas. Por fim, há limites para a complexidade de uma transação medida em unidades de computação (CUs). As CUs quantificam os recursos computacionais gastos no processamento de transações.

Lembrar

A menor unidade de SOL é conhecida como um "lamport", equivalente a uma bilionésima de SOL, semelhante a um satoshi no Bitcoin. O lamport é nomeado apósLeslie Lamport, um cientista da computação e matemático cuja pesquisa estabeleceu muitos fundamentos teóricos dos sistemas distribuídos modernos.

O custo em SOL para executar uma transação é separado em 2 partes - uma taxa base e uma taxa de priorização. A taxa base é uma taxa fixa de 5000 lamports por custo de assinatura, independentemente da complexidade da transação - geralmente, há 1 assinatura por transação.

As taxas de priorização são tecnicamente opcionais, mas durante períodos de alta demanda por espaço de bloco, tornam-se necessárias. Essas taxas são precificadas em micro-lamports (um milionésimo de um lamport) por unidade de computação. Seu objetivo é agir como um sinal de preço, tornando as transações mais economicamente convincentes para os nós validadores incluírem em seus blocos.

taxa total = taxa de priorização + taxa base

taxa de priorização = preço da unidade de computação (micro-lamports) x limite da unidade de computação

Atualmente, 50% de todas as taxas relacionadas a transações são queimadas, removendo permanentemente esse SOL de circulação, sendo os 50% restantes destinados ao produtor de blocos. Uma nova alteração (SIMD 96) em breve será introduzida permitindo que 100% das taxas de priorização sejam destinadas ao produtor de blocos. As taxas básicas permanecem inalteradas.

‍

Enviando transações

Um usuário conecta sua carteira ao aplicativo, permitindo que o aplicativo leia a chave pública do usuário. A chave privada permanece criptografada e segura em um ambiente separado do aplicativo.

O aplicativo constrói os parâmetros da mensagem de transação com base nas interações do usuário. Por exemplo, se um usuário quisesse trocar dois tokens, eles especificariam a quantidade de tokens a comprar, os tokens correspondentes a vender e uma variação de transação aceitável.

Uma vez que a mensagem de transação está pronta, ela é enviada para a carteira para ser assinada com a chave privada do usuário. Neste ponto, o usuário é solicitado com um pop-up para confirmar sua vontade de transacionar. Este pop-up pode incluir uma simulação dos resultados da transação. Uma vez assinada, a mensagem de transação e a assinatura são devolvidas ao aplicativo, que pode então encaminhar a transação para um provedor RPC de sua escolha, seja o próprio ou usando o provedor da carteira.

Provedores de RPC (Chamada de Procedimento Remoto) atuam como intermediários entre aplicativos e os validadores que constroem blocos. Eles são um serviço essencial que permite que aplicativosenviarou simular transações assinadas e recuperar eficientemente dados on-chain. Aplicativos que desejam interagir com a rede o fazem através de um ponto de extremidade JSON-RPC ou WebSocket ( docs).

Lembrar

O termo “transação falhada” na Solana é enganoso e tem causado confusão considerável. Essas transações incorrem em taxas e são executadas com sucesso pelo tempo de execução exatamente como o signatário pretendia. Elas “falham” devido à lógica própria da transação exigir que isso aconteça. +80% das transações “falhadas” vêm do código de erro 0x1771, o código para exceder a quantidade de derrapagem.dados). Notavelmente, 95% dessas transações são enviadas por apenas 0,1% dos endereços ativos da Solana, principalmente por bots automatizados tentando aproveitar oportunidades de arbitragem de preço sensíveis ao tempo.

Corrente do Golfo

“Literalmente, o objetivo da Solana é realizar transações tão rapidamente quanto as notícias se espalham pelo mundo - tão rápido quanto a luz viaja através da fibra. Com quem estamos competindo é a NASDAQ e a Bolsa de Valores de Nova York.” - Anatoly Yakovenko, co-fundador da Solana

As RPCs (Chamadas de Procedimento Remoto) referem-se a nós RPC. Esses nós podem ser considerados como gateways para interagir e ler dados da rede. Eles executam o mesmo software que os validadores completos, mas com configurações diferentes, permitindo-lhes simular com precisão transações e manter uma visão atualizada do estado atual. Até o momento desta escrita, existem mais de 4.000 nós RPC na rede Solana.

Ao contrário dos nós validadores completos, os nós RPC não possuem nenhuma participação na rede. Sem participação, eles não podem votar ou construir blocos. Essa configuração difere da maioria das outras blockchains, onde os nós validadores e RPC são tipicamente os mesmos. Como os nós RPC não recebem recompensas de stake, a economia de executar nós RPC é distinta da dos validadores, com muitos operando como um serviço pago para desenvolvedores que executam aplicações Solana.

Solana destaca-se porque foi projetada desde o início para operar sem um mempool. Ao contrário das blockchains tradicionais que usam protocolos de gossip para propagar transações aleatoriamente e amplamente pela rede, Solana encaminha todas as transações para um validador líder predeterminado, conhecido como o líder, para cada slot.

Chamada

Solana opera quatro clusters: Localnet, Testnet, Devnet e Mainnet-Beta. Quando as pessoas se referem ao Solana ou à rede Solana, quase sempre se referem ao Mainnet-Beta. O Mainnet-Beta é o único cluster onde os tokens possuem valor real, enquanto os outros clusters são usados exclusivamente para fins de teste.

Uma vez que um RPC recebe uma mensagem de transação para ser incluída em um bloco, ela deve ser encaminhada para o líder. Um cronograma de líder é produzido antes de cada época (aproximadamente a cada dois dias). A próxima época é dividida em slots, cada um fixado em 400 milissegundos, e um líder é escolhido para cada slot. Validadores com uma participação maior serão escolhidos com mais frequência para se tornar líder dentro de cada época. Durante cada slot, mensagens de transação são encaminhadas para o líder, que tem a oportunidade de produzir um bloco. Quando é a vez de um validador, ele muda para o modo de “líder”, começa a processar ativamente transações e a transmitir blocos para o restante da rede.

Ponderação de Qualidade de Serviço de Stake - PQS

No início de 2024, a Solana introduziu um novo mecanismo com o objetivo de prevenir spam e melhorar a resistência a Sybil, conhecido como "Qualidade de Serviço Ponderada por Stake" (SWQoS). Esse sistema permite aos líderes priorizar mensagens de transações que são transmitidas por outros validadores apostados. Aqui, os validadores com uma aposta maior recebem uma capacidade proporcionalmente maior de transmitir pacotes de mensagens de transações para o líder. Essa abordagem mitiga efetivamente os ataques de Sybil de nós não apostados em toda a rede.

Sob este modelo, os validadores também podem celebrar acordos para alugar sua capacidade ponderada de participação para nós de RPC. Em troca, os nós de RPC ganham largura de banda aumentada, permitindo-lhes alcançar maiores taxas de inclusão de transações nos blocos. Notavelmente, 80% da capacidade de um líder (2.000 conexões) é reservada para SWQoS. Os 20% restantes (500 conexões) são alocados para mensagens de transação de nós não apostados. Esta estratégia de alocação reflete faixas prioritárias em rodovias, onde os motoristas pagam pedágio para evitar o trânsito.

SWQoS impactou o ecossistema Solana ao elevar os requisitos para encaminhar transações para o líder e reduzir a eficácia dos ataques de spam. A mudança incentivou as aplicações de alto tráfego a integrar verticalmente suas operações. Ao executar seus próprios nós validadores, ou ao ter acesso a conexões staked, as aplicações podem garantir acesso privilegiado ao líder, melhorando assim suas capacidades de processamento de transações.

Uma Nota Rápida

No final de 2022, Solana adotou oprotocolo de rede QUICpara gerenciar a transmissão de mensagens de transação para o líder. Essa transição foi motivada por interrupções na rede causadas por bots spamming em mints de NFT on-chain. QUIC facilita a comunicação rápida e assíncrona.

Inicialmente desenvolvido porGoogleEm 2012, o QUIC tenta oferecer o melhor dos dois mundos. Ele facilita a comunicação rápida e assíncrona semelhante ao UDP, mas com as sessões seguras e estratégias avançadas de controle de fluxo do TCP. Isso permite impor limites às fontes individuais de tráfego para que a rede possa se concentrar no processamento de transações genuínas. Ele também tem o conceito de fluxos separados; assim, se uma transação for perdida, não é necessário bloquear as restantes. Em resumo, o QUIC pode ser considerado como uma tentativa de combinar as melhores características do TCP e do UDP.

Caixa de destaque

A ponderação do stake é um princípio recorrente encontrado em todo o sistema da Solana, abrangendo recompensas de votação, árvores de turbina, agendas de líderes, Gulf Stream e a rede de fofocas. Validadores com maior stake são concedidos maior confiança e papéis prioritários na rede.

Construção de Blocos

“Consideramos o SVM (Solana Virtual Machine) o melhor em termos de tecnologia de máquina virtual atualmente.” — Andre Cronje, Fantom Foundation

Muitas redes blockchain constroem blocos inteiros antes de transmiti-los, conhecido como construção de bloco discreta. Solana, por outro lado, utiliza a construção contínua de blocos que envolve a montagem e transmissão dinâmica de blocos à medida que são criados durante um intervalo de tempo alocado, reduzindo significativamente a latência.

Cada slot dura 400 milissegundos, e cada líder é atribuído quatro slots consecutivos (1,6 segundos) antes de passar para o próximo líder. Para que um bloco seja aceito, todas as transações dentro dele devem ser válidas e reproduzíveis por outros nós.

Dois slots antes de assumir a liderança, um validador interrompe o encaminhamento de transações para se preparar para sua próxima carga de trabalho. Durante este intervalo, o tráfego de entrada aumenta, atingindo mais de um gigabyte por segundo, à medida que toda a rede direciona pacotes para o líder entrante.

Após o recebimento, as mensagens de transação entram na Unidade de Processamento de Transações (TPU), a lógica principal do validador responsável pela produção de blocos. Aqui, a sequência de processamento de transações começa com o Estágio de Busca, onde as transações são recebidas via QUIC. Posteriormente, as transações avançam para o Estágio SigVerify, passando por rigorosas verificações de validação. Aqui, o validador verifica a validade das assinaturas, verifica o número correto de assinaturas e elimina transações duplicadas.

Estágio Bancário

A fase bancária pode ser descrita como a fase de construção de blocos. É a fase mais importante do TPU, que recebe seu nome do “banco“. Um banco é apenas o estado em um determinado bloco. Para cada bloco, o Solana tem um banco que é usado para acessar o estado naquele bloco. Quando um bloco se torna finalizado depois que bastantes validadores votam nele, eles irão descarregar as atualizações de conta do banco para o disco, tornando-as permanentes. O estado final da cadeia é o resultado de todas as transações confirmadas. Este estado pode sempre ser recriado a partir da história do blockchain de forma determinística.

As transações são processadas em paralelo e empacotadas em "entradas" de ledger, que são lotes de 64 transações não conflitantes. O processamento paralelo de transações na Solana é facilitado porque cada transação deve incluir uma lista completa de todas as contas que ela irá ler e escrever. Esta escolha de design coloca um fardo sobre os desenvolvedores, mas permite que o validador evite condições de corrida selecionando facilmente apenas transações não conflitantes para execução dentro de cada entrada. Transações conflitantes ocorrem se ambas tentarem escrever na mesma conta (duas escritas) ou se uma tentar ler e a outra escrever na mesma conta (leitura + escrita). Assim, transações conflitantes vão para entradas diferentes e são executadas sequencialmente, enquanto as transações não conflitantes são executadas em paralelo.

Existem seis threads processando transações em paralelo, com quatro dedicados a transações normais e dois exclusivamente lidando com transações de voto que são integrais ao mecanismo de consenso da Solana. Toda a paralelização do processamento é alcançada através de múltiplos núcleos de CPU; os validadores não têm requisitos de GPUdocs).

Uma vez que as transações tenham sido agrupadas em entradas, elas estão prontas para serem executadas pela Máquina Virtual Solana (SVM). As contas necessárias para a transação estão bloqueadas; verificações são realizadas para confirmar se a transação é recente, mas ainda não foi processada. As contas são carregadas e a lógica da transação é executada, atualizando os estados das contas. Um hash da entrada será enviado ao serviço de Prova de História para ser registrado (mais sobre isso na próxima seção). Se o processo de registro for bem-sucedido, todas as alterações serão confirmadas no banco e os bloqueios de cada conta colocados na primeira etapa são removidos. A execução é feita pela SVM, uma máquina virtual construída usando o fork SolanarBPF, uma biblioteca para trabalhar com compilação JIT e máquinas virtuais para programas eBPF. Note-se que Solana não exige como os validadores escolhem ordenar as transações dentro de um bloco. Essa flexibilidade é um ponto crucial para o qual voltaremos mais tarde na seção de Economia + Jito deste relatório.

Lembrar

O termo SVM pode ser ambíguo, pois pode se referir tanto à “Máquina Virtual Solana” quanto à “Máquina Virtual Sealevel.” Ambos os termos descrevem o mesmo conceito, sendo Sealevel o nome do ambiente de execução da Solana. O termo SVM continua sendo usado de forma vaga, apesar dos esforços recentes para ser precisodefinir seus limites.

Clientes

Solana é uma rede composta por milhares de nós operados de forma independente colaborando para manter um único livro-razão unificado. Cada nó constitui uma máquina de alto desempenho executando o mesmo software de código aberto conhecido como um “cliente”.

Solana lançou com um único software de cliente validador — originalmente o cliente Solana Labs, agora conhecido como ocliente Agave— escrito em Rust. Expandir a diversidade de clientes tem sido uma prioridade desde então e uma que realmente se concretizará com o lançamento docliente FiredancerFiredancer é uma reescrita completa do cliente original na linguagem de programação C. Construído por uma equipe experiente da empresa de negociação de alta frequência Jump, promete ser o cliente validador mais performático em qualquer blockchain.

Prova de História

“Tomei dois cafés e uma cerveja, e fiquei acordado até as 4:00 da manhã. Tive esse momento de insight que o quebra-cabeça similar à prova de trabalho usando a mesma função hash resistente a pré-imagem SHA-256... Eu sabia que tinha essa seta do tempo.” — Anatoly Yakovenko, co-fundador da Solana

A Prova de História (PoH) é o ingrediente secreto da Solana, funcionando como um relógio especial em cada validador que facilita a sincronização em toda a rede. A PoH estabelece uma fonte confiável da verdade para a ordem dos eventos e a passagem do tempo. Mais criticamente, ela garante a adesão ao cronograma do líder. Apesar dos nomes semelhantes, a Prova de História não é um algoritmo de consenso como o Prova de Trabalho.

A sobrecarga de comunicação entre os nós normalmente aumenta à medida que as redes se expandem, e a coordenação se torna cada vez mais complicada. A Solana mitiga isso substituindo a comunicação de nó para nó por uma computação local de PoH. Isso significa que os validadores podem se comprometer com um bloco com apenas uma rodada de votação. Timestamps confiáveis em mensagens garantem que os validadores não possam ultrapassar uns aos outros e iniciar seus blocos prematuramente.

Os PoH subjacentes são as propriedades únicas dos algoritmos de hash, especificamente SHA256:

• Determinístico: A mesma entrada sempre produzirá o mesmo hash.
• Tamanho Fixo: Independentemente do tamanho de entrada, o hash de saída é sempre de 256 bits.
• Eficiente: É rápido calcular o hash para qualquer entrada dada.
• Resistência de pré-imagem: Encontrar a entrada original a partir da saída do hash é computacionalmente inviável.
• Efeito Avalanche: Uma pequena mudança na entrada (mesmo um único bit) resulta em um hash significativamente diferente, uma propriedade conhecida como o efeito avalanche.
• Resistência à colisão: É inviável encontrar duas entradas diferentes que produzam a mesma saída de hash.

Dentro de cada cliente validador, um serviço dedicado de "Prova de História" é executado continuamente o algoritmo de hash SHA256 criando uma cadeia de hashes. A entrada de cada hash é a saída do hash anterior. Essa cadeia atua da mesma forma que uma função de atraso verificável, dado que o trabalho de hash deve ser feito em sequência e os resultados de hashes futuros não podem ser conhecidos antecipadamente. Se o serviço de PoH cria uma cadeia de mil hashes, sabemos que o tempo passou para calcular cada hash sequencialmente — isso pode ser pensado como um "micro prova de trabalho." No entanto, outros validadores podem verificar a correção dos mil hashes em paralelo a uma taxa muito mais rápida do que foram produzidos, uma vez que a entrada e a saída de cada hash foram transmitidas para a rede. Portanto, a PoH é difícil de produzir, mas fácil de verificar.

A gama de desempenho na computação SHA-256 em diferentes CPUs é surpreendentemente estreita, com apenas pequenas diferenças entre as máquinas mais rápidas. Um limite superior comum já foi atingido, apesar do tempo e esforço significativos investidos na otimização dessa função, em grande parte devido à dependência do Bitcoin a ela.

Durante o slot de um líder, o serviço PoH receberá entradas recém-processadas da etapa bancária. O hash atual do PoH mais um hash de todas as transações na entrada são combinados no próximo hash do PoH. Isso serve como um carimbo de data/hora que insere a entrada na cadeia de hashes, comprovando a sequência em que as transações foram processadas. Esse processo não apenas confirma a passagem do tempo, mas também serve como um registro criptográfico das transações.

Em um único bloco, existem 800.000 hashes. O fluxo de PoH também inclui "ticks," que são entradas vazias indicando a vivacidade do líder e a passagem do tempo aproximando uma pequena fração de segundo. Um tick ocorre a cada 6,25 milissegundos, resultando em 64 ticks por bloco e um tempo total de bloco de 400 milissegundos.

Os validadores continuam a executar o relógio PoH mesmo quando não são os líderes, pois desempenha um papel fundamental no processo de sincronização entre os nós.

Lembrar

O principal benefício do PoH é garantir que o cronograma correto do líder deve ser seguido, mesmo que um produtor de blocos esteja offline - um estado conhecido como "delinquente". O PoH impede que um validador malicioso produza blocos antes de ser sua vez.

Modelo de Contas

"Separar código e estado no SVM foi a melhor decisão de design. Abençoados são os desenvolvedores de sistemas embarcados que religiosamente martelaram esse conceito em meu cérebro." - Anatoly Yakovenko, co-fundador da Solana

Dentro de um validador Solana, o estado global é mantido no banco de dados de contas conhecido como AccountsDB. Este banco de dados é responsável por armazenar todas as contas, tanto na memória quanto no disco. A estrutura de dados principal no índice de contas é um hashmap, tornando o AccountsDB essencialmente um vastarmazenamento de chave-valorAqui, a chave é o endereço da conta e o valor é os dados da conta.

Com o tempo, o número de contas Solana disparou para centenas de milhões. Esse grande número é em parte porque, como os desenvolvedores da Solana gostam de dizer, “Tudo na Solana é uma conta!”

contas Solana

Uma conta é um recipiente que mantém persistentemente dados, semelhante a um arquivo em um computador. Eles vêm em várias formas:

• Contas de usuário: Essas contas têm uma chave privada e geralmente são geradas por um software de carteira para um usuário.
• Contas de dados: Essas contas armazenam informações de estado, como a quantidade de um token específico que um usuário possui.
• Contas de programa: Estas são contas maiores que contêm bytecode executável, algo equivalente a um arquivo .exe no Windows ou a um arquivo .app no Mac.
• Contas de programa nativas: Estas são contas de programa pré-implementadas especiais que realizam várias funcionalidades principais da rede.Exemplosinclua o Programa de Votação e o Carregador BPF.

Todas as contas têm os seguintes campos:

Programas

Contas de programa Solana contêm apenas lógica executável. Isso significa que quando um programa é executado, ele muta o estado de outras contas, mas permanece inalterado. Essa separação de código e estado diferencia Solana de outras blockchains e suporta muitas de suas otimizações. Os desenvolvedores escrevem principalmente esses programas em Rust, uma linguagem de programação de propósito geralconhecidopor seu forte foco em segurança e desempenho. Além disso, vários SDKs em TypeScript e Python estão disponíveis para facilitar a criação de interfaces de aplicativos e permitir a interação programática com a rede.

Muitas funcionalidades comuns são fornecidas prontas para uso por programas nativos. Por exemplo, Solana não requer que os desenvolvedores implantem código para criar um token. Em vez disso, instruções são enviadas a um programa nativo pré-implantado que configurará uma conta para armazenar os metadados do token, criando efetivamente um novo token.

Aluguel

O aluguel é um mecanismo projetado para incentivar os usuários a fecharem contas e reduzirem a expansão do estado. Para criar uma nova conta, um saldo mínimo de SOL, conhecido como o valor "isento de aluguel", deve ser mantido pela conta. Isso pode ser considerado um custo de armazenamento incorrido para manter a conta viva na memória de um validador. Se o tamanho dos dados da conta aumentar, o requisito de aluguel do saldo mínimo aumenta proporcionalmente. Quando uma conta não é mais necessária, ela pode ser fechada e o aluguel é devolvido ao proprietário da conta.

Por exemplo, se um usuário possui uma stablecoin denominada em dólares, este estado é armazenado em uma conta de token. Atualmente, o valor isento de aluguel para uma conta de token é de 0,002 SOL. Se o usuário transferir todo o saldo de sua stablecoin para um amigo, a conta de token pode ser fechada e o usuário receberá de volta seus 0,002 SOL. Os programas frequentemente lidam com o fechamento de contas automaticamente para os usuários. Várias aplicações estão disponíveis para ajudar os usuários a limpar contas antigas e não utilizadas e recuperar as pequenas quantidades de SOL armazenadas nelas.

Propriedade

Embora a leitura de dados de conta seja universalmente permitida, o modelo de propriedade da Solana aumenta a segurança, restringindo exatamente quem pode modificar (gravar) os dados de uma conta. Esse conceito é crucial para aplicar regras e permissões no blockchain Solana. Cada conta tem um "dono" do programa. O proprietário de uma conta é responsável por governá-la, garantindo que apenas programas autorizados possam alterar os dados da conta. Uma exceção notável a essa regra é a transferência de lamports (a menor unidade de SOL) — aumentar o saldo de lamports de uma conta é universalmente permitido, independentemente da propriedade.

Armazenamento de Estado

Os programas Solana, sendo arquivos executáveis somente leitura, devem armazenar o estado usando “Endereços Derivados de Programa” (PDAs). PDAs são tipos especiais de contas associadas a e de propriedade de um programa, em vez de um usuário específico. Enquanto os endereços de usuário normais do Solana são derivados da chave pública de um par de chaves Ed25519, os PDAs não têm uma chave privada. Em vez disso, sua chave pública é derivada de uma combinação de parâmetros — frequentemente palavras-chave ou outros endereços de contas — juntamente com o ID do programa proprietário (endereço).

Os endereços de PDA existem fora da curva, o que significa que não estão na curva Ed25519 como os endereços normais. Apenas o programa que possui o PDA pode gerar programaticamente assinaturas para ele, garantindo que seja o único que pode modificar o estado do PDA.

Acima: As contas de token Solana são exemplos específicos de Endereços Derivados de Programa (PDAs). Elas são usadas para manter tokens e ficam “fora da curva”. O programa de Conta de Token Associada (ATA) garante que cada carteira possa ter apenas uma conta de token associada para cada tipo de token, fornecendo uma maneira padronizada de gerenciar contas de token.

Turbina

“A parte mais interessante sobre Solana não é a paralelização, o SVM, ou os tweets do Tóly. É algo que provavelmente você não ouviu falar: Turbine.” — Mert Mumtaz, Helius

Durante a fase bancária, as transações são organizadas em entradas e enviadas para o fluxo de Prova de História para carimbo de data/hora. O banco do bloco é atualizado, e as entradas estão agora prontas para a próxima fase - Turbina.

Turbina é o processo pelo qual o líder propaga seu bloco para o resto da rede. Inspirado porBitTorrent, foi projetado para ser rápido e eficiente, reduzindo a sobrecarga de comunicação e minimizando a quantidade de dados que um líder precisa enviar.

A Turbine consegue isso ao decompor dados de transações em “fragmentos” por meio de um processo chamado “fragmentação”. Fragmentos são pequenos pacotes de dados, de até 1280 bytes, semelhantes a quadros individuais em um fluxo de vídeo. Quando reagrupados, esses fragmentos permitem que validadores repliquem o bloco inteiro. Os fragmentos são enviados pela internet entre validadores usando UDP e utilizam codificação por apagamento para lidar com a perda de pacotes ou a eliminação maliciosa de pacotes.Codificação de apagamento, apolinômioEsquema de detecção e correção de erros baseado, garante integridade dos dados. Mesmo que alguns fragmentos sejam perdidos, o bloco ainda pode ser reconstruído.

Os fragmentos são agrupados em lotes conhecidos como lotes de correção de erros para frente (FEC). Por padrão, esses lotes consistem em 64 fragmentos (32 fragmentos de dados + 32 fragmentos de recuperação). A recuperação de dados ocorre por lote FEC, o que significa que até metade dos pacotes em um lote podem ser perdidos ou corrompidos, e todos os dados ainda podem ser recuperados. Cada lote de 64 fragmentos é merkelizado, com a raiz sendo assinada pelo líder e encadeada ao lote anterior. Esse processo garante que os fragmentos possam ser obtidos com segurança de qualquer nó na rede que os possua, já que a cadeia de raízes de Merkle fornece um caminho verificável de autenticidade e integridade.

O líder inicialmente transmite para um único nó raiz, que dissemina os fragmentos para todos os outros nós validadores. Este nó raiz muda com cada fragmento. Os validadores são organizados em camadas, formando a “Árvore Turbina.” Validadores com uma quantidade maior de participação geralmente são posicionados no topo da árvore, enquanto aqueles com participações menores são colocados na parte inferior.

A árvore geralmente abrange dois ou três saltos, dependendo do número de validadores ativos. Para simplificação visual, um fanout de 3 é representado acima, mas o valor real do fanout do Solana está atualmente definido como 200. Por motivos de segurança, a ordem da árvore é rotacionada para cada novo lote de fragmentos.

O objetivo principal de tal sistema é aliviar a pressão de saída de dados nos nós líder e raiz. Ao utilizar um sistema de transmissão e retransmissão, a carga é distribuída entre o líder e os retransmissores, reduzindo a tensão em qualquer nó único.

Consensus

"Algumas pessoas inteligentes me dizem que há uma comunidade séria de desenvolvedores inteligentes em Solana... Espero que a comunidade tenha sua chance justa de prosperar" — Vitalik Buterin, cofundador da Ethereum

Uma vez que um validador recebe um novo bloco do líder via Turbine, ele deve validar todas as transações dentro de cada entrada. Isso envolve reexecutar todo o bloco, validando os hashes de PoH em paralelo, recriando as transações na sequência ditada por PoH e atualizando seu banco local.

Esse processo é tratado pela Unidade de Validação de Transações (TVU), que é análoga à Unidade de Processamento de Transações do líder (TPU), servindo como a lógica central responsável pelo processamento de fragmentos e validação de blocos. Assim como a TPU, o fluxo da TVU é dividido em várias etapas, começando pela Etapa de Busca de Fragmentos onde os fragmentos são recebidos pelo Turbine. Na etapa subsequente de Verificação de Assinatura do Líder de Fragmentos, os fragmentos passam por múltiplas verificações de sanidade, sendo a verificação mais notável a da assinatura do líder, que garante que os fragmentos recebidos tenham origem no líder.

Na Etapa de Retransmissão, o validador, com base em sua localização na árvore da Turbina, encaminha os fragmentos para os validadores downstream apropriados. Na Etapa de Replay, o validador recria cada transação exatamente e na ordem correta, atualizando sua versão local do banco.

A Etapa de Repetição é análoga à etapa bancária no TPU; é a etapa mais importante e pode ser mais diretamente descrita como a etapa de validação de blocos. A Repetição é um loop de processo de uma única thread que orquestra muitas operações-chave, incluindo votação, redefinição do relógio PoH e troca de bancos.

Acima: o estágio de replay é responsável por mudar o validador para o modo líder e iniciar a produção de blocos. Visual original: Justin Starry, Anza

Consenso

Para alcançar consenso, Solana usa Tower BFT (TBFT), uma implementação personalizada do bem conhecido PracticalFalha BizantinaAlgoritmo de tolerância ao falhas bizantinas (PBFT), comumente usado pela maioria das blockchains para concordar com o estado da cadeia. Como todas as blockchains, Solana assume a presença de nós maliciosos na rede, então o sistema deve resistir não apenas a falhas de nós, mas também a certos níveis de ataques.

A Tower BFT diferencia-se de outras cadeias ao alavancar o relógio sincronizado fornecido pela Prova de História. Enquanto o PBFT tradicional requer múltiplas rodadas de comunicação para concordar com a ordem de transação, os nós da Solana utilizam a ordem pré-estabelecida dos eventos, reduzindo significativamente o overhead de mensagens.

Votação

Para participar do consenso e ganhar recompensas, os validadores enviam votos para os blocos que acreditam ser válidos (ou seja, livres de problemas como gastos duplos ou assinaturas incorretas) e devem ser considerados canônicos. Os validadores pagam uma taxa de transação por esses votos, que são processados pelo líder e incluídos em um bloco juntamente com as transações regulares do usuário. Por isso, as transações da Solana são frequentemente categorizadas em transações de voto e não voto. Quando os validadores enviam um voto correto e bem-sucedido, eles ganham um crédito. Esse mecanismo incentiva os validadores a votar no fork que acreditam ter a melhor chance de ser incluído, ou seja, o fork “mais pesado”.

Garfos

Parte do design da Solana, que a torna tão rápida, é que a rede não espera que todos os validadores concordem com um bloco recém-produzido antes de produzir o próximo. Como resultado, não é incomum que dois blocos diferentes estejam ligados ao mesmo bloco pai, criando forks.

Os validadores do Solana devem votar nessas bifurcações e usar um algoritmo de consenso para determinar qual adotar. Quando existem bifurcações concorrentes, apenas uma será finalizada pela rede, enquanto os blocos nas bifurcações descartadas são abandonados.

Cada vaga tem um líder pré-determinado para o qual apenas o bloco desse líder será aceito; não pode haver dois blocos propostos para um único slot. Portanto, o número de bifurcações potenciais é limitado a uma lista de pulos "lá/não-lá" de bifurcações que podem surgir nos limites dos slots de rotação de líderes. Uma vez que um validador escolhe uma bifurcação, ele é comprometido com essa bifurcação até que um tempo de bloqueio expire, o que significa que ele deve manter sua escolha por um período mínimo.

A "taxa de "pular" da Solana - a porcentagem de slots nos quais um bloco não foi produzido - varia de 2% a 10%, sendo os forks a principal razão para esses slots pulados. Outras possíveis razões para slots pulados incluem o início de uma nova época, um líder offline ou a produção de um bloco inválido.

Lembrar

O status de uma transação na Solana varia dependendo de sua etapa atual no processo de consenso:

• Processado: A transação foi incluída em um bloco.

• Confirmado: O bloco da transação foi votado por uma supermaioria de dois terços.

• Finalizado: Mais de 31 blocos foram construídos em cima do bloco da transação.

Até o momento, nunca houve uma instância na história da Solana em que um bloco confirmado (de forma otimista) não tenha sido finalizado.

Para cada bloco, Solana usa um banco para acessar o estado naquele bloco. Quando um banco é finalizado, as atualizações da conta desse banco e seus ancestrais são gravadas no disco. Além disso, quaisquer atualizações de conta de bancos anteriores que não sejam ancestrais do banco finalizado são podadas. Esse processo permite que Solana mantenha vários estados potenciais de forma eficiente.

Fofoca + Arquivo

“Um blockchain requer uma combinação inteligente de criptografia, sistemas distribuídos, sistemas operacionais e linguagens de programação. O superpoder da Solana foi a disposição de fugir gritando dos problemas mais interessantes em cada disciplina.” — Greg Fitzgerald, co-fundador da Solana

Fofoca

A rede de fofocas pode ser considerada como oplano de controlepara a rede Solana. Ao contrário do plano de dados, que lida com fluxos de transações, o plano de controle dissemina metadados cruciais sobre o estado do blockchain, como informações de contato, altura do livro-razão e informações de votação. Sem fofoca, os validadores e RPCs não saberiam quais endereços e portas estão abertos para comunicação entre vários serviços. Novos nós também dependem de fofocas para ingressar na rede.

O protocolo de fofocas da Solana usa comunicação informal de peer-to-peer com uma abordagem de transmissão de árvore inspirada em um algoritmo PlumTree modificado. Este método propaga informações de forma eficiente sem depender de nenhuma fonte central.

A fofoca funciona de certa forma como um sistema isolado, independente da maioria dos outros componentes do validador. Validadores e RPCs compartilham objetos de dados assinados a cada 0,1 segundos via UDP através da fofoca, garantindo a disponibilidade de informações em toda a rede. Todas as mensagens de fofoca devem ter menos ou igual à unidade máxima de transmissão (MTU) de 1280 bytes, referido como a "estrutura de pacote" no código-fonte.

Registros de fofocas são os objetos de dados reais compartilhados entre os nós. Existem aproximadamente 10 tipos diferentes de registros, cada um servindo a propósitos diferentes. Os registros de fofocas são assinados, versionados e carimbados com data e hora para garantir integridade e atualidade.

Existem quatro tipos de mensagens de fofoca:

• Push: As mensagens mais comuns, compartilhando informações com um subconjunto de “push peers.”
• Pull & Pull Response: Verifica periodicamente mensagens perdidas, com respostas de pull enviando de volta as informações que os nós não possuem.
• Poda: Permite que os nós reduzam seletivamente o número de conexões que mantêm.
• Ping & Pong: a integridade verifica se há nós — se um ping for enviado, um pong é esperado de volta, indicando que o nó de mesmo nível ainda está ativo.

Os dados de fofoca são armazenados em um Armazenamento de Dados Replicado em Cluster (CrdsTable). Essa estrutura de dados pode crescer muito e precisa ser podada periodicamente.

Arquivo

Solana destaca-se de outras blockchains por não exigir a história inteira para determinar o estado atual de uma conta. O modelo de conta da Solana garante que o estado em qualquer slot dado seja conhecido, permitindo que validadores armazenem o estado atual de cada conta sem processar todos os blocos históricos. RPCs e validadores, por design, não mantêm o registro histórico completo. Em vez disso, eles normalmente armazenam apenas dados de transações de 1 ou 2 épocas (2-4 dias), o que é suficiente para validar a ponta da cadeia.

Os arquivos são atualmente gerenciados por “nós de depósito”, operados por provedores de serviços RPC profissionais, a Fundação Solana e outros participantes do ecossistema interessados em garantir que o histórico de transações esteja disponível. Os nós de depósito geralmente mantêm um ou ambos os seguintes:

1. Arquivo do Ledger: Carrega snapshots brutos do ledger e do AccountsDB adequados para reprodução do zero.

2. Instância do Google Bigtable: Armazena dados de bloco desde o bloco genesis em diante, formatados para atender solicitações RPC.

Economia + Jito

“As pessoas estão percebendo que Solana é a única cadeia disponível hoje que suportará aplicativos de consumo mainstream.” — Ted Livingston, fundador Code

Solana emprega a inflação para distribuir recompensas de staking gerando novos tokens SOL a cada época. Esse processo faz com que a participação na rede dos não-stakers diminua em relação aos stakers, levando a uma transferência de riqueza dos não-stakers para os stakers. A inflação começou no início de 2021 a uma taxa inicial de 8%, que diminui 15% anualmente até se estabilizar em uma taxa de longo prazo de 1,5%.

Qualquer detentor de token SOL pode ganhar recompensas e ajudar a garantir a rede ao apostar tokens em um ou mais validadores. A atribuição de tokens a um validador é conhecida como delegação. Delegar tokens a um validador indica confiança no validador. No entanto, não dá ao validador propriedade ou controle sobre os tokens. Todas as ações de aposta, desaposta e delegação são executadas no início da próxima nova época.

‍

Recompensas de Votação

Quando um validador envia um voto, ele ganha um crédito se o voto for preciso e bem-sucedido. As transações de votação custam 0.000005 SOL e são isentas de taxas prioritárias. As despesas de votação chegam a cerca de 1 SOL por dia por validador, tornando-se o principal custo operacional de manter um validador. Ao longo de uma época, os validadores acumulam créditos por meio de votações, que podem trocar por uma parcela da inflação no final da época.

Os validadores de melhor desempenho votam com sucesso em aproximadamente 90% dos slots. Note que a porcentagem de slots sem blocos (taxa de slot pulado) varia de 2% a mais de 10%, e esses slots não podem ser votados. O validador médio vota com sucesso em cerca de 80% dos slots, ganhando 345.600 créditos em um período de 432.000 slots.

O pote total de inflação é primeiro dividido com base nos créditos ganhos para a época. A participação de um validador no total de créditos (seus créditos divididos pela soma de todos os créditos dos validadores) determina sua recompensa proporcional. Isso é ainda ponderado pela participação.

Portanto, um validador com 1% do total de participação deve ganhar aproximadamente 1% da inflação total se tiver um número médio de créditos. Se tiver acima ou abaixo do número médio de créditos, suas recompensas flutuarão de acordo.

Diferenças no desempenho de votação são uma das razões pelas quais os retornos (medidos em APY) que os validadores oferecem aos stakers variam. Outro fator é a taxa de comissão cobrada pelos validadores, que é uma porcentagem das recompensas totais de inflação direcionadas ao seu validador. Além disso, um validador estar offline ou fora de sincronia com o blockchain (conhecido como inadimplência) impacta significativamente os retornos.

Recompensas por bloco

Validadores designados como líder para um bloco específico recebem recompensas adicionais de bloco. Essas recompensas compreendem 50% das taxas base e 50% das taxas de prioridade de todas as transações dentro do bloco, com as taxas restantes sendo queimadas. Apenas o validador que produziu o bloco recebe essas recompensas. Ao contrário das recompensas de staking, que são distribuídas por época, as recompensas de bloco são creditadas instantaneamente na conta de identidade do validador quando o bloco é produzido.

Staking líquido

O staking líquido tornou-se uma alternativa popular ao staking nativo. Os participantes recebem um token, conhecido como Liquid Staking Token (LST) ou Liquid Staking Derivative (LSD), em troca de apostar seus SOL, geralmente em um pool de apostas que delega seus tokens entre vários validadores. Os tokens LST recém-recebidos representam a participação do usuário no SOL apostado. Esses tokens podem ser negociados, usados em aplicativos ou transferidos para outros, enquanto ainda recebem recompensas de staking. A grande vantagem desse sistema é que ele melhora significativamente a eficiência de capital.

Preço do LST = (SOL total apostado no pool * preço do SOL) / LST total cunhado

Com o staking nativo tradicional, ao longo do tempo, o staker acumulará diretamente mais SOL. Enquanto isso, com o staking líquido, as recompensas são reinvestidas de volta no pool, aumentando o valor justo do LST. Desde que haja um mecanismo para resgatar LSTs pelo SOL staked subjacente, os traders de arbitragem garantirão que o preço do token permaneça racional.

Jito

No momento da escrita, mais de 80% (fonte) do stake na Solana utiliza o software do validador Jito client. Este cliente, um fork do cliente original Agave, introduz um leilão de espaço de bloco fora do protocolo que fornece aos validadores incentivos econômicos adicionais através de dicas. Este incentivo extra é um fator importante na adoção generalizada do cliente Jito entre os validadores.

Quando os líderes usam o cliente validador Jito, suas transações são inicialmente direcionadas para o Jito-Relayer. Este software de código aberto funciona como um roteador proxy de transações. Outros nós da rede permanecem inconscientes da existência do Jito-Relayer, pois simplesmente enviam transações para o endereço e configuração de porta que o líder anunciou na rede de fofocas como seu ingress_socket, assumindo que seja do líder.

O relayer retém todas as transações por 200 milissegundos antes de enviá-las para o líder. Esse mecanismo de "quebra-molas" atrasa as mensagens de transação recebidas, proporcionando uma breve janela para a realização de leilões. Após 200 milissegundos, o relayer libera otimisticamente as transações, independentemente dos resultados do leilão.

Os leilões de espaço de bloco ocorrem off-chain via o Jito Block Engine, permitindo que buscadores e aplicativos enviem grupos de transações atomicamente executadas conhecidas como pacotes. Esses pacotes geralmente contêm transações sensíveis ao tempo, como arbitragens ou liquidações. Jito cobra uma taxa de 5% sobre todas as gorjetas, com uma gorjeta mínima de 10.000 lamports. As gorjetas operam inteiramente fora do protocolo, separadas das taxas de base e de prioridade do protocolo. Anteriormente, o Jito operava um serviço canônico de mem-pool fora do protocolo, que agora foi descontinuado.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Solanahelius]. Todos os direitos autorais pertencem ao autor original [Perdido]. Se houver objeções a esta reimpressão, entre em contato com oGate Aprenderequipe e eles lidarão com isso prontamente.
2. Isenção de Responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.