Visão geral executiva da Solana

Introdução

A Solana é uma blockchain de alto desempenho e baixa latência, reconhecida por sua velocidade, eficiência e foco na experiência do usuário. Sua arquitetura integrada e exclusiva permite milhares de transações por segundo em uma rede globalmente descentralizada. Com tempo de bloco de 400 milissegundos e taxas de transação que correspondem a frações de centavo, ela oferece velocidade e ótimo custo-benefício. Este relatório explora os detalhes do design e da operação da Solana, examinando os principais mecanismos e a topologia de rede que contribuem para seus recursos.

A Solana adota uma abordagem integrada para o desenvolvimento de blockchain, aproveitando as décadas de experiência da equipe fundadora na criação de sistemas distribuídos. Um dos princípios centrais da Solana é que o software nunca deve limitar o hardware. Isso significa que o software aproveita ao máximo qualquer hardware em que é executado e escala com ele. Como um ecossistema unificado, todas as aplicações criadas sobre essa única blockchain herdam a capacidade de composição, o que permite que interajam e se desenvolvam umas sobre as outras de forma integrada. Essa arquitetura também garante uma experiência de usuário simples e intuitiva, sem a necessidade de pontes, IDs de cadeia separados ou fragmentação de liquidez.

A Solana está evoluindo rapidamente, com desenvolvimentos recentes que incluem rollups da SVM e ZK Compression como importantes soluções de escalabilidade. Embora esses projetos possam um dia moldar nossa percepção futura da Solana, atualmente eles estão nos estágios iniciais de desenvolvimento ou adoção e não serão abordados neste relatório.

Ciclo de vida da transação

Nossa principal perspectiva para compreender a Solana ao longo deste relatório será o ciclo de vida de uma transação típica. Para criar um modelo básico de compreensão das transações da Solana, podemos descrever o processo da seguinte forma: 

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

As próximas seções deste relatório expandirão esse modelo e explorarão esse processo com muito mais detalhes, começando pelos principais participantes: os usuários.

Seis etapas

Usaremos como referência ao longo deste relatório o diagrama de seis etapas exibido acima, pois ele oferece uma estrutura consistente para compreender as relações entre os principais elementos da Solana.

Os primeiros capítulos estão organizados de acordo com essas seis etapas. Os capítulos finais — Gossip, Arquivo, Economia e Jito — concluem os tópicos restantes. É importante observar que alguns capítulos abrangerão várias etapas e que algumas etapas aparecerão em vários capítulos.

Essa sobreposição é inevitável porque a estrutura de seis etapas tem suas limitações. Na prática, a Solana é um sistema distribuído complexo, com muitos elementos interdependentes.

Usuários

A jornada de um usuário geralmente começa com a configuração e o depósito de fundos em uma aplicação de carteira. Há várias aplicações de carteira populares disponíveis para a Solana, seja como aplicações móveis nativas ou extensões de navegador.

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

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Uma chave privada — também conhecida como chave secreta — pode ser considerada a senha ou chave de acesso que concede permissão para acessar e modificar a conta. A assinatura com chaves privadas é a forma como as blockchains gerenciam a autorização. O conhecimento da chave privada concede autoridade absoluta sobre a conta. As chaves privadas da 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 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]

As chaves privadas também podem ser derivadas de frases-semente mnemônicas, geralmente compostas por 12 ou 24 palavras. Esse formato é frequentemente usado em carteiras para facilitar o backup e a recuperação. Várias chaves podem ser derivadas de forma determinística a partir de uma única frase-semente.

A Solana utiliza o Ed25519, um algoritmo de assinatura digital de curva elíptica amplamente adotado, para suas necessidades de criptografia de chave pública. O Ed25519 é valorizado pelo tamanho reduzido das chaves e assinaturas, pela rapidez de processamento e pela imunidade a muitos ataques comuns. Cada endereço de carteira da Solana representa um ponto na curva elíptica Ed25519.

O usuário assina as transações com sua chave privada. Essa assinatura é incluída nos dados da transação e pode ser verificada por outros participantes usando a chave pública do remetente. Esse processo garante que a transação não tenha sido adulterada e que tenha sido autorizada pelo proprietário da chave privada correspondente. A assinatura também funciona como um identificador exclusivo da transação.

Transações da Solana‍

Enviar uma transação é a única maneira de alterar o estado na Solana. Toda operação de escrita é realizada por meio de uma transação, e as transações são atômicas: ou tudo o que a transação tenta fazer acontece, ou ela falha. Uma transação, formalmente conhecida como uma "mensagem de transação", é composta por quatro seções: um cabeçalho, uma lista de endereços de contas, um hash de bloco recente e instruções.

Cabeçalho

O cabeçalho contém referências à lista de endereços de contas, indicando quais contas devem assinar a transação.

Endereços de contas

Essa lista inclui todas as contas que serão lidas ou gravadas durante a transação. Criar uma lista desse tipo para cada transação é um requisito exclusivo da Solana e pode ser desafiador para os desenvolvedores. No entanto, saber antecipadamente com quais partes do estado uma transação interagirá permite otimizações que não são possíveis em muitas outras blockchains.

Hash de bloco recente

Ele é usado para impedir transações duplicadas e obsoletas. Um hash de bloco recente expira após 150 blocos, cerca de 1 minuto. Por padrão, os RPCs tentam encaminhar as transações a cada 2 segundos até que a transação seja finalizada ou o hash de bloco recente expire, momento em que a transação é descartada.

Instruções

Elas formam a parte central da transação. Cada instrução representa uma operação específica, como transferir, emitir, queimar, criar uma conta ou encerrar uma conta. Cada instrução especifica o programa a ser executado, as contas necessárias e os dados exigidos para sua execução.

O número de instruções em uma transação é limitado primeiro pelo tamanho dela, que pode chegar a 1.232 bytes. Também há limites para o 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 usados no processamento de transações.

O custo em SOL para executar uma transação é dividido em 2 partes: uma taxa-base e uma taxa de priorização. A taxa-base tem um custo fixo de 5.000 lamports por assinatura, independentemente da complexidade da transação. Normalmente, há 1 assinatura por transação.

As taxas de priorização são tecnicamente opcionais, mas tornam-se necessárias durante períodos de alta demanda por espaço em bloco. Essas taxas são precificadas em microlamports, milionésimos de um lamport, por unidade de computação. Sua finalidade é atuar como um sinal de preço, tornando as transações economicamente mais atraentes para inclusão nos blocos pelos nós validadores. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

Atualmente, 50% de todas as taxas relacionadas a transações são queimadas, removendo permanentemente esse SOL de circulação, enquanto os 50% restantes vão para o produtor do bloco. Uma nova mudança (SIMD 96) será introduzida em breve, permitindo que 100% das taxas de priorização sejam destinadas ao produtor do bloco. As taxas-base permanecem inalteradas.

Envio de transações

O usuário conecta sua carteira à aplicação, permitindo que ela leia a chave pública do usuário. A chave privada permanece criptografada e isolada com segurança em um ambiente separado da aplicação.

A aplicação cria 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, ele especificaria a quantidade de tokens a comprar, os tokens correspondentes a vender e uma derrapagem aceitável para a transação.

Quando a mensagem de transação está pronta, ela é enviada à carteira para ser assinada com a chave privada do usuário. Nesse momento, uma janela pop-up solicita que o usuário confirme se deseja realizar a transação. Essa janela pode incluir uma simulação dos resultados da transação. Depois de assinadas, a mensagem de transação e a assinatura são devolvidas à aplicação, que pode encaminhar a transação a um provedor de RPC de sua escolha, seja um provedor próprio ou o provedor da carteira.

Os provedores de RPC (Remote Procedure Call) atuam como intermediários entre as aplicações e os validadores que criam blocos. Eles fornecem um serviço essencial que permite às aplicações enviar ou simular transações assinadas e recuperar dados on-chain com eficiência. As aplicações que desejam interagir com a rede fazem isso por meio de um endpoint JSON-RPC ou WebSocket (documentação).

Gulf Stream

RPCs (Remote Procedure Calls) referem-se a nós RPC. Esses nós podem ser considerados gateways para interagir com a rede e ler seus dados. Eles executam o mesmo software que os validadores completos, mas com configurações diferentes, o que permite simular transações com precisão e manter uma visão atualizada do estado atual. No momento em que este texto foi escrito, havia mais de 4.000 nós RPC na rede Solana.

Ao contrário dos nós validadores completos, os nós RPC não têm nenhuma participação em staking na rede. Sem stake, eles não podem votar nem criar blocos. Essa configuração é diferente da maioria das outras blockchains, nas quais os nós validadores e RPC geralmente são os mesmos. Como os nós RPC não recebem recompensas de staking, a economia de sua operação é diferente daquela dos validadores, e muitos funcionam como um serviço pago para desenvolvedores que executam aplicações na Solana.

A Solana se destaca porque foi projetada desde o início para operar sem uma mempool. Ao contrário das blockchains tradicionais, que usam protocolos de gossip para propagar transações de forma aleatória e ampla pela rede, a Solana encaminha todas as transações a um validador principal predeterminado, conhecido como líder, em cada slot.

Quando um RPC recebe uma mensagem de transação que deve ser incluída em um bloco, ele precisa encaminhá-la ao líder. Uma programação de líderes é produzida 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. Os validadores com stake maior serão escolhidos com mais frequência para se tornarem líderes em cada época. Durante cada slot, as mensagens de transação são encaminhadas ao líder, que tem a oportunidade de produzir um bloco. Quando chega a vez de um validador, ele muda para o "modo líder", começa a processar transações ativamente e transmite blocos para o restante da rede.

Qualidade de serviço ponderada por stake — SWQoS

No início de 2024, a Solana introduziu um novo mecanismo destinado a impedir spam e aumentar a resistência a ataques Sybil, conhecido como qualidade de serviço ponderada por stake (SWQoS). Esse sistema permite que os líderes priorizem mensagens de transação encaminhadas por outros validadores com stake. Nesse modelo, validadores com um stake maior recebem uma capacidade proporcionalmente maior para transmitir pacotes de mensagens de transação ao líder. Essa abordagem reduz efetivamente os ataques Sybil de nós sem stake em toda a rede.

‍Nesse modelo, os validadores também podem firmar acordos para alugar sua capacidade ponderada por stake a nós RPC. Em troca, os nós RPC obtêm mais largura de banda, o que permite alcançar taxas maiores de inclusão de transações nos blocos. É importante destacar que 80% da capacidade de um líder, ou 2.000 conexões, são reservados para SWQoS. Os 20% restantes, ou 500 conexões, são alocados para mensagens de transação provenientes de nós sem stake. Essa estratégia de alocação é semelhante às faixas expressas de rodovias, nas quais os motoristas pagam um pedágio para evitar o trânsito.

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

Uma observação sobre QUIC

No fim de 2022, a Solana adotou o protocolo de rede QUIC para gerenciar a transmissão de mensagens de transação ao líder. Essa transição foi motivada por interrupções na rede causadas por bots que enviavam spam durante a emissão de NFTs on-chain. O QUIC permite uma comunicação rápida e assíncrona.

‍Desenvolvido inicialmente pelo Google em 2012, o QUIC busca oferecer o melhor dos dois mundos. Ele possibilita uma comunicação rápida e assíncrona, semelhante ao UDP, mas com as sessões seguras e as estratégias avançadas de controle de fluxo do TCP. Isso permite impor limites a fontes individuais de tráfego para que a rede possa se concentrar no processamento de transações legítimas. Ele também inclui o conceito de streams separados. Assim, se uma transação for descartada, ela não precisará bloquear as demais. Em resumo, o QUIC pode ser entendido como uma tentativa de combinar as melhores características do TCP e do UDP.

Criação de blocos

Muitas redes blockchain constroem blocos inteiros antes de transmiti-los, em um processo conhecido como criação discreta de blocos. A Solana, por outro lado, usa a criação contínua de blocos, que envolve montar e transmitir blocos dinamicamente à medida que são criados durante um slot de tempo alocado, reduzindo significativamente a latência.

Cada slot dura 400 milissegundos, e cada líder recebe quatro slots consecutivos, ou 1,6 segundo, antes da rotação para o próximo líder. Para que um bloco seja aceito, todas as transações contidas nele 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 a próxima carga de trabalho. Durante esse intervalo, o tráfego de entrada aumenta drasticamente e ultrapassa um gigabyte por segundo, à medida que toda a rede direciona pacotes ao líder que está prestes a assumir.

Após o recebimento, as mensagens de transação entram na Unidade de Processamento de Transações (TPU), a lógica central do validador responsável pela produção de blocos. Nela, a sequência de processamento de transações começa no estágio Fetch, em que as transações são recebidas via QUIC. Depois, as transações avançam para o estágio SigVerify, onde passam por verificações rigorosas de validação. Nesse ponto, o validador verifica a validade das assinaturas, confere se há o número correto de assinaturas e elimina transações duplicadas.

‍Estágio bancário

O estágio bancário pode ser descrito como o estágio de criação do bloco. É o estágio mais importante da TPU, que recebe esse nome por causa do “banco”. Um banco é simplesmente o estado em um determinado bloco. Para cada bloco, a Solana tem um banco usado para acessar o estado naquele bloco. Quando um bloco é finalizado após receber votos de validadores suficientes, as atualizações de contas são transferidas do banco para o disco, tornando-se permanentes. O estado final da cadeia é o resultado de todas as transações confirmadas. Esse estado sempre pode ser recriado de forma determinística a partir do histórico da blockchain.‍

As transações são processadas em paralelo e agrupadas em “entradas” do ledger, que são lotes de 64 transações sem conflito. O processamento paralelo de transações na Solana é facilitado porque cada transação deve incluir uma lista completa de todas as contas que serão lidas e gravadas. Essa decisão de design aumenta a responsabilidade dos desenvolvedores, mas permite que o validador evite condições de corrida ao selecionar facilmente apenas transações sem conflito para execução em cada entrada. Há conflito entre transações quando ambas tentam gravar na mesma conta, com duas gravações, ou quando uma tenta ler e a outra tenta gravar na mesma conta, com leitura + gravação. Assim, as transações conflitantes são colocadas em entradas diferentes e executadas sequencialmente, enquanto as transações sem conflito são executadas em paralelo.

Há seis threads processando transações em paralelo: quatro dedicadas a transações normais e duas exclusivamente destinadas a transações de voto, que são parte integrante do mecanismo de consenso da Solana. Toda a paralelização do processamento é realizada por meio de vários núcleos de CPU. Os validadores não exigem GPUs (documentação).‍

Depois que as transações são agrupadas em entradas, elas ficam prontas para serem executadas pela Solana Virtual Machine (SVM). As contas necessárias para a transação são bloqueadas, e verificações são executadas para confirmar que a transação é recente, mas ainda não foi processada. As contas são carregadas e a lógica da transação é executada, atualizando o estado das contas. Um hash da entrada é enviado ao serviço de Proof of History para ser registrado, como veremos em mais detalhes na próxima seção. Se o processo de registro for bem-sucedido, todas as mudanças serão confirmadas no banco e os bloqueios aplicados a cada conta na primeira etapa serão removidos. A execução é feita pela SVM, uma máquina virtual criada com o fork da Solana do rBPF, uma biblioteca para trabalhar com compilação JIT e máquinas virtuais para programas eBPF. Vale observar que a Solana não determina como os validadores devem ordenar as transações dentro de um bloco. Essa flexibilidade é um ponto crucial ao qual retornaremos mais adiante, na seção Economia + Jito deste relatório.‍

Clientes

A Solana é uma rede composta por milhares de nós operados de forma independente que colaboram para manter um único ledger unificado. Cada nó consiste em uma máquina de alto desempenho que executa o mesmo software de código aberto, conhecido como “cliente”.

A Solana foi lançada com um único software cliente de validador — originalmente o cliente Solana Labs, agora conhecido como cliente Agave — escrito em Rust. Desde então, ampliar a diversidade de clientes tornou-se uma prioridade que realmente se concretizará com o lançamento do cliente Firedancer. O Firedancer é uma reescrita completa do cliente original, desenvolvida do zero na linguagem de programação C. Criado por uma equipe experiente da empresa de negociação de alta frequência Jump, ele promete ser o cliente de validador com melhor desempenho entre todas as blockchains.

Prova de História

A Prova de História (PoH) é o ingrediente secreto da Solana. Ela funciona como um relógio especial em cada validador, facilitando a sincronização em toda a rede. A PoH estabelece uma fonte confiável da verdade sobre a ordem dos eventos e a passagem do tempo. Mais importante ainda, ela garante o cumprimento da programação de líderes. Apesar dos nomes semelhantes, a Prova de História não é um algoritmo de consenso como a Prova de Trabalho.

‍A sobrecarga de comunicação entre os nós normalmente aumenta à medida que as redes crescem, e a coordenação se torna cada vez mais complexa. A Solana reduz esse problema substituindo a comunicação entre nós 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. Carimbos de data e hora confiáveis nas mensagens garantem que os validadores não se sobreponham nem iniciem seus blocos antes da hora.

A PoH se baseia nas propriedades exclusivas dos algoritmos de hash, especificamente o SHA256:

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

Em cada cliente validador, um "serviço de Prova de História" dedicado executa continuamente o algoritmo de hash SHA256, criando uma cadeia de hashes. A entrada de cada hash é a saída do hash anterior. Essa cadeia funciona como uma função de atraso verificável, pois o trabalho de hashing precisa ser realizado em sequência e os resultados dos hashes futuros não podem ser conhecidos antecipadamente. Se o serviço de PoH criar uma cadeia de mil hashes, sabemos que passou o tempo necessário para calcular cada hash sequencialmente — isso pode ser entendido como uma “microprova de trabalho”. Ainda assim, outros validadores podem verificar a exatidão dos mil hashes em paralelo, muito mais rápido do que eles foram produzidos, pois a entrada e a saída de cada hash foram transmitidas à rede. Portanto, a PoH é difícil de produzir, mas fácil de verificar.

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

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

Em um único bloco, há 800.000 hashes. O stream de PoH também inclui "ticks", que são entradas vazias que indicam que o líder está ativo e a passagem de 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 executam continuamente o relógio de PoH, mesmo quando não são o líder, pois ele desempenha um papel essencial no processo de sincronização entre os nós.

Modelo de contas

Em um validador da Solana, o estado global é mantido no banco de dados de contas conhecido como AccountsDB. Esse banco de dados é responsável por armazenar todas as contas, tanto na memória quanto em disco. A principal estrutura de dados do índice de contas é um hashmap, o que torna o AccountsDB essencialmente um enorme armazenamento de chave-valor. Nesse caso, a chave é o endereço da conta e o valor são os dados da conta.

Com o tempo, o número de contas da Solana cresceu para centenas de milhões. Esse grande volume se deve, em parte, ao que os desenvolvedores da Solana gostam de dizer: "Tudo na Solana é uma conta!"

Contas da Solana

Uma conta é um contêiner que armazena dados de forma persistente, semelhante a um arquivo em um computador. Há vários tipos:

• Contas de usuário: Essas contas têm uma chave privada e normalmente 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: São contas maiores que contêm bytecode executável, de certa forma equivalentes a um arquivo .exe no Windows ou .app no Mac.
• Contas de programas nativos: São contas especiais de programas pré-implantados que executam várias funcionalidades essenciais da rede. Os exemplos incluem o Vote Program e o BPF Loader.

Todas as contas têm os seguintes campos:

Programas‍

As contas de programas da Solana contêm apenas lógica executável. Isso significa que, quando um programa é executado, ele altera o estado de outras contas, mas permanece inalterado. Essa separação entre código e estado diferencia a Solana de outras blockchains e sustenta muitas de suas otimizações. Os desenvolvedores escrevem esses programas principalmente em Rust, uma linguagem de programação de uso geral conhecida pelo forte foco em segurança e desempenho. Além disso, há vários SDKs em TypeScript e Python disponíveis para facilitar a criação de front-ends de aplicações e permitir a interação programática com a rede.

Muitas funcionalidades comuns são fornecidas de fábrica por programas nativos. Por exemplo, a Solana não exige 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 configura 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 fechar contas e reduzir o inchaço do estado. Para criar uma nova conta, ela deve manter um saldo mínimo de SOL, conhecido como valor "isento de aluguel". Isso pode ser considerado um custo de armazenamento para manter a conta ativa na memória de um validador. Se o tamanho dos dados da conta aumentar, o saldo mínimo exigido para o aluguel cresce proporcionalmente. Quando uma conta não é mais necessária, ela pode ser fechada e o aluguel é devolvido ao proprietário. 

Por exemplo, se um usuário possui uma stablecoin denominada em dólar, esse estado é armazenado em uma conta de token. Atualmente, o valor isento de aluguel de uma conta de token é de 0,002 SOL. Se o usuário transferir todo o saldo da stablecoin para um amigo, a conta de token poderá ser fechada e o usuário receberá de volta seus 0,002 SOL. Os programas geralmente cuidam do fechamento de contas automaticamente para os usuários. Várias aplicações ajudam os usuários a limpar contas antigas e não utilizadas e a recuperar as pequenas quantidades de SOL armazenadas nelas.

Propriedade

Embora todos possam ler os dados de uma conta, o modelo de propriedade da Solana aumenta a segurança ao restringir exatamente quem pode modificar (escrever) os dados de uma conta. Esse conceito é essencial para aplicar regras e permissões na blockchain da Solana. Toda conta tem um programa "proprietário". O proprietário de uma conta é responsável por controlá-la, garantindo que apenas programas autorizados possam alterar seus dados. Uma exceção importante a essa regra é a transferência de lamports, a menor unidade de SOL: aumentar o saldo de lamports de uma conta é permitido a todos, independentemente da propriedade.

Armazenamento de estado

Como são arquivos executáveis somente leitura, os programas da Solana precisam armazenar o estado usando “Program Derived Addresses” (PDAs). PDAs são tipos especiais de contas associadas a um programa e pertencentes a ele, e não a um usuário específico. Enquanto os endereços normais de usuários da 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 — geralmente palavras-chave ou outros endereços de contas — junto com o ID (endereço) do programa proprietário.

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

Turbine

Durante a etapa bancária, as transações são organizadas em entradas e enviadas ao stream da Prova de História para receber carimbos de data e hora. O banco do bloco é atualizado, e as entradas ficam prontas para a próxima fase: Turbine.

Turbine é o processo pelo qual o líder propaga seu bloco para o restante da rede. Inspirado no BitTorrent, ele 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.

‍O Turbine faz isso dividindo os dados das transações em "shreds" por meio de um processo chamado "shredding". Shreds são pequenos pacotes de dados, de até 1.280 bytes, semelhantes a quadros individuais em um stream de vídeo. Quando remontados, esses shreds permitem que os validadores reproduzam o bloco inteiro. Os shreds são enviados pela internet entre validadores usando UDP e utilizam codificação de apagamento para lidar com a perda ou o descarte mal-intencionado de pacotes. A codificação de apagamento, um esquema de detecção e correção de erros baseado em polinômios, garante a integridade dos dados. Mesmo que alguns shreds sejam perdidos, o bloco ainda poderá ser reconstruído.

Os shreds são agrupados em lotes conhecidos como lotes de correção antecipada de erros (FEC). Por padrão, esses lotes consistem em 64 shreds (32 shreds de dados + 32 shreds de recuperação). A recuperação de dados ocorre por lote FEC, o que significa que até metade dos pacotes de um lote pode ser perdida ou corrompida e, ainda assim, todos os dados podem ser recuperados. Cada lote de 64 shreds é organizado em uma árvore de Merkle, cuja raiz é assinada pelo líder e encadeada ao lote anterior. Esse processo garante que os shreds possam ser obtidos com segurança de qualquer nó da rede que os possua, pois a cadeia de raízes de Merkle fornece um caminho verificável de autenticidade e integridade.

Inicialmente, o líder transmite para um único nó raiz, que distribui os shreds para todos os outros nós validadores. Esse nó raiz muda a cada shred. Os validadores são organizados em camadas, formando a "árvore Turbine". Os validadores com uma quantidade maior em staking normalmente ficam mais próximos do topo da árvore, enquanto aqueles com menos staking ficam mais próximos da base.

‍A árvore normalmente abrange dois ou três saltos, dependendo do número de validadores ativos. Para simplificar a visualização, a ilustração acima mostra uma ramificação de 3, mas o valor real de ramificação da Solana está atualmente definido como 200. Por motivos de segurança, a ordem da árvore é alternada a cada novo lote de shreds.

O principal objetivo desse sistema é reduzir a pressão da saída de dados sobre o líder e os nós raiz. Com um sistema de transmissão e retransmissão, a carga é distribuída entre o líder e os retransmissores, reduzindo a pressão sobre qualquer nó individual.

Consenso

Depois que um validador recebe um novo bloco do líder via Turbine, ele precisa validar todas as transações em cada entrada. Isso envolve reproduzir o bloco inteiro, validar os hashes de PoH em paralelo, recriar as transações na sequência determinada pela PoH e atualizar seu banco local. 

‍Esse processo é conduzido pela Transaction Validation Unit (TVU), análoga à Transaction Processing Unit (TPU) do líder, que atua como a lógica central responsável pelo processamento de shreds e pela validação de blocos. Assim como na TPU, o fluxo da TVU é dividido em várias etapas, começando pela Shred Fetch Stage, em que os shreds são recebidos pelo Turbine. Na Shred Verify Leader Signature Stage seguinte, os shreds passam por várias verificações de integridade, principalmente a verificação da assinatura do líder, o que garante que os shreds recebidos vieram dele. ‍

Na Retransmit Stage, o validador encaminha os shreds aos validadores posteriores apropriados de acordo com sua posição na árvore Turbine. Na Replay Stage, o validador recria cada transação com exatidão e na ordem correta enquanto atualiza sua versão local do banco.

A Replay Stage é análoga à etapa bancária da TPU. É a etapa mais importante e pode ser descrita mais diretamente como a etapa de validação do bloco. A reprodução é um loop de processo de thread única que coordena várias operações essenciais, incluindo votação, redefinição do relógio de PoH e troca de bancos. 

Consenso

Para alcançar consenso, a Solana usa o Tower BFT (TBFT), uma implementação personalizada do conhecido algoritmo de Tolerância Prática a Falhas Bizantinas (PBFT), amplamente usado pela maioria das blockchains para chegar a um acordo sobre o estado da cadeia. Como todas as blockchains, a Solana pressupõe a presença de nós mal-intencionados na rede. Portanto, o sistema precisa resistir não só a falhas de nós, mas também a determinados níveis de ataque.

O Tower BFT se diferencia de outras cadeias por aproveitar o relógio sincronizado fornecido pela Prova de História. Enquanto o PBFT tradicional exige várias rodadas de comunicação para chegar a um acordo sobre a ordem das transações, os nós da Solana usam a ordem preestabelecida dos eventos, reduzindo significativamente a sobrecarga de mensagens.

Votação

‍Para participar do consenso e ganhar recompensas, os validadores enviam votos para blocos que consideram válidos, ou seja, sem problemas como gastos duplos ou assinaturas incorretas, e que 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 junto com as transações comuns dos usuários. Por isso, as transações da Solana são frequentemente classificadas como transações de voto e sem voto. Quando os validadores enviam um voto correto e bem-sucedido, eles recebem um crédito. Esse mecanismo incentiva os validadores a votar no fork que acreditam ter a maior chance de ser incluído, ou seja, o fork “mais pesado”.

Forks

Uma parte do design da Solana que a torna tão rápida é o fato de a rede não esperar 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 sejam vinculados ao mesmo bloco pai, criando forks.

Os validadores da Solana precisam votar nesses forks e usar um algoritmo de consenso para determinar qual deles adotar. Quando há forks concorrentes, apenas um deles acaba sendo finalizado pela rede, enquanto os blocos dos forks descartados são abandonados.

Cada slot tem um líder predeterminado, e somente o bloco desse líder será aceito. Não pode haver dois blocos propostos para um único slot. Portanto, o número de forks possíveis é limitado a uma lista de omissões do tipo "presente/ausente", que pode surgir nos limites dos slots de rotação de líderes. Depois que um validador escolhe um fork, ele permanece comprometido com ele até o término do período de bloqueio, o que significa que deve manter sua escolha por um período mínimo.

‍A "taxa de omissão" da Solana — a porcentagem de slots em que nenhum bloco foi produzido — varia de 2% a 10%, e os forks são o principal motivo desses slots omitidos. Outros motivos possíveis incluem o início de uma nova época, um líder offline ou a produção de um bloco inválido.

Lembre-se:

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

• Processada: A transação foi incluída em um bloco.
• Confirmada: O bloco da transação recebeu votos de uma supermaioria de dois terços.
• Finalizada: Mais de 31 blocos foram construídos sobre o bloco da transação.

Até hoje, nunca houve um caso na história da Solana em que um bloco confirmado de forma otimista não tenha sido finalizado.‍

Para cada bloco, a Solana usa um banco para acessar o estado naquele bloco. Quando um banco é finalizado, as atualizações de contas desse banco e de seus ancestrais são gravadas em disco. Além disso, todas as atualizações de contas de bancos anteriores que não sejam ancestrais do banco finalizado são removidas. Esse processo permite que a Solana mantenha vários estados possíveis com eficiência.

Gossip + Arquivamento

Gossip

A rede gossip pode ser entendida como o plano de controle da rede Solana. Ao contrário do plano de dados, que lida com os fluxos de transações, o plano de controle distribui metadados essenciais sobre o estado da blockchain, como informações de contato, altura do ledger e informações de votação. Sem gossip, validadores e RPCs não saberiam quais endereços e portas estão abertos para comunicação entre os vários serviços. Novos nós também dependem do gossip para entrar na rede.

O protocolo gossip da Solana usa comunicação informal ponto a ponto com uma abordagem de transmissão em árvore inspirada em um algoritmo PlumTree modificado. Esse método propaga informações com eficiência sem depender de nenhuma fonte central.

O gossip funciona de forma relativamente isolada, independente da maioria dos outros componentes do validador. Validadores e RPCs compartilham objetos de dados assinados a cada 0,1 segundo por UDP via gossip, garantindo a disponibilidade das informações em toda a rede. Todas as mensagens de gossip devem ter tamanho menor ou igual à unidade máxima de transmissão (MTU) de 1.280 bytes, chamada de "packet struct" na base de código.

Os registros de gossip são os objetos de dados efetivamente compartilhados entre os nós. Há aproximadamente 10 tipos diferentes de registros, cada um com uma finalidade distinta. Os registros de gossip são assinados, versionados e recebem carimbos de data e hora para garantir integridade e atualidade.

Há quatro tipos de mensagens de gossip:‍

1. Push: As mensagens mais comuns, que compartilham informações com um subconjunto de "peers de push".
2. Pull e resposta de pull: Verificam periodicamente se há mensagens perdidas, e as respostas de pull retornam as informações que os nós não têm.
3. Prune: Permite que os nós reduzam seletivamente o número de conexões mantidas.
4. Ping e Pong: Verificações de integridade dos nós — quando um ping é enviado, espera-se um pong como resposta, indicando que o nó peer continua ativo.

Os dados de gossip são armazenados em um Cluster Replicated Data Store (CrdsTable). Essa estrutura de dados pode crescer muito e precisa ser limpa periodicamente.

Arquivamento

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

Atualmente, os arquivos são gerenciados por "nós de armazenamento", operados por provedores profissionais de serviços RPC, pela Solana Foundation e por outros participantes do ecossistema interessados em garantir a disponibilidade do histórico de transações. Os nós de armazenamento normalmente mantêm um ou ambos os itens a seguir:

1. Arquivo do ledger: Faz upload do ledger bruto e de snapshots do AccountsDB adequados para reprodução desde o início.
2. Instância do Google Bigtable: Armazena dados de blocos desde o bloco gênese, formatados para atender a solicitações RPC.

Economia + Jito

A Solana usa a inflação para distribuir recompensas de staking, gerando novos tokens SOL a cada época. Esse processo reduz a participação na rede de quem não faz staking em relação à de quem faz, resultando em uma transferência de riqueza para os participantes de staking. A inflação começou no início de 2021 com uma taxa inicial de 8%, que diminui 15% ao ano até se estabilizar em uma taxa de longo prazo de 1,5%.

‍Qualquer pessoa que possua tokens SOL pode ganhar recompensas e ajudar a proteger a rede fazendo staking dos 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 nele. No entanto, isso não concede ao validador a propriedade nem o controle dos tokens. Todas as ações de staking, retirada de staking e delegação são executadas no início da próxima época.

Recompensas de votação

‍Quando um validador envia um voto, ele recebe 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 de prioridade. As despesas de votação chegam a aproximadamente 1 SOL por dia por validador, sendo o principal custo operacional para manter um validador. Ao longo de uma época, os validadores acumulam créditos por votar e podem trocá-los por uma parcela da inflação ao final da época.

Os validadores com melhor desempenho votam com sucesso em aproximadamente 90% dos slots. Vale observar que a porcentagem de slots sem blocos, ou taxa de slots omitidos, varia de 2% a mais de 10%, e não é possível votar nesses slots. Em média, um validador vota com sucesso em cerca de 80% dos slots, obtendo 345.600 créditos em uma época de 432.000 slots.

O total da inflação é primeiro dividido com base nos créditos obtidos durante a época. A parcela de um validador no total de créditos, ou seja, seus créditos divididos pela soma dos créditos de todos os validadores, determina sua recompensa proporcional. Esse valor também é ponderado pelo staking.

Portanto, um validador com 1% do total em staking deve receber aproximadamente 1% da inflação total se tiver uma quantidade média de créditos. Se tiver uma quantidade de créditos acima ou abaixo da média, suas recompensas variarão de acordo.‍

As diferenças no desempenho da votação são um dos motivos pelos quais variam os retornos, medidos em APY, que os validadores oferecem aos participantes de staking. Outro fator é a taxa de comissão cobrada pelos validadores, que corresponde a uma porcentagem do total das recompensas de inflação direcionadas ao validador. Além disso, um validador offline ou dessincronizado da blockchain, condição conhecida como inadimplência, afeta significativamente os retornos.

Recompensas de bloco

Os validadores designados como líderes de um bloco específico recebem recompensas adicionais de bloco. Essas recompensas correspondem a 50% das taxas básicas e 50% das taxas de prioridade de todas as transações no bloco, enquanto as taxas restantes são queimadas. Somente o validador que produziu o bloco recebe essas recompensas. Ao contrário das recompensas de staking, 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 do staking de seus SOL, normalmente em um pool de staking que delega os tokens entre vários validadores. Os novos tokens LST recebidos representam a participação do usuário nos SOL em staking. Esses tokens podem ser negociados, usados em aplicações ou transferidos para outras pessoas enquanto continuam gerando recompensas de staking. A principal vantagem desse sistema é o aumento significativo da eficiência do capital.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

No staking nativo tradicional, o participante acumula diretamente mais SOL ao longo do tempo. Já no staking líquido, as recompensas são reinvestidas no pool, aumentando o valor justo do LST. Enquanto houver um mecanismo para resgatar LSTs pelos SOL subjacentes em staking, os traders de arbitragem garantirão que o preço do token permaneça racional.

Jito

No momento da redação, mais de 80% (fonte) do staking na Solana utiliza o software cliente validador Jito. Esse cliente, um fork do cliente Agave original, introduz um leilão de espaço de bloco fora do protocolo que oferece aos validadores incentivos econômicos adicionais por meio de gorjetas. Esse incentivo extra é um dos principais fatores para a ampla adoção do cliente Jito entre os validadores.

Quando os líderes usam o cliente validador Jito, suas transações são inicialmente direcionadas ao Jito-Relayer. Esse software de código aberto funciona como um roteador proxy de transações. Os outros nós da rede não sabem da existência do Jito-Relayer, pois simplesmente enviam transações para a configuração de endereço e porta que o líder anunciou na rede gossip como seu ingress_socket, supondo que pertença ao líder.

‍O relayer retém todas as transações por 200 milissegundos antes de encaminhá-las ao líder. Esse mecanismo de "redutor de velocidade" atrasa as mensagens de transações recebidas, criando uma breve janela para a realização de leilões. Após 200 milissegundos, o relayer libera as transações de forma otimista, independentemente dos resultados do leilão.

Os leilões de espaço de bloco ocorrem off-chain por meio do Jito Block Engine, permitindo que buscadores e aplicações enviem grupos de transações executadas atomicamente, conhecidos como bundles. Esses bundles geralmente contêm transações sensíveis ao tempo, como arbitragens ou liquidações. A Jito cobra uma taxa de 5% sobre todas as gorjetas, com uma gorjeta mínima de 10.000 lamports. As gorjetas operam totalmente fora do protocolo, separadas das taxas básicas e de prioridade internas ao protocolo. Anteriormente, a Jito operava um serviço canônico de mempool fora do protocolo, que agora foi descontinuado.