Introdução

“Nós sabíamos que menor, mais rápido, mais barato melhor do que qualquer outra pessoa no mundo, e agora estamos a aplicar 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 global descentralizada. 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 explora as complexidades do design e operação da Solana, explorando os mecanismos-chave e a topologia da 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 entre si de forma contínua. Esta arquitetura também garante uma experiência de usuário direta e intuitiva, sem a necessidade de pontes, IDs de cadeias separadas ou fragmentação de liquidez.

Solana está a evoluir rapidamente, com desenvolvimentos recentes que incluem rollups SVM eCompressão ZKcomo soluções de dimensionamento 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

A nossa lente principal para entender a 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 da Solana, podemos esboçar o processo da seguinte forma:

• Os utilizadores iniciam transações, todas enviadas para o produtor de bloco líder atual (conhecido como líder). O líder compila essas transações num bloco, executando-as e, assim, atualizando o seu estado local.
• Este bloco de transações é então propagado por toda a rede para outros validadores executarem e confirmarem.

As secções subsequentes deste relatório irão expandir este modelo e aprofundar este processo com muito mais detalhe, começando pelos participantes chave - os utilizadores.

Lembrar

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

Seis estágios

Vamos referir-nos à visualização de seis etapas mostrada acima ao longo deste relatório, pois nos oferece uma estrutura consistente para compreender as relações entre os elementos principais do Solana.

Os capítulos anteriores estão organizados de acordo com estas seis etapas. Os capítulos finais — Gossip, 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.

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

Utilizadores

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

A jornada de um utilizador normalmente começa por configurar e financiar uma aplicação de carteira. Existem várias aplicações de carteira populares disponíveis para Solana, quer como aplicações móveis nativas ou extensões de navegador.

As carteiras geram criptograficamente pares de chaves de utilizador, compostas por chaves públicas e privadas. A chave pública atua como o identificador único da sua conta e é conhecida por todos os participantes na rede. A conta de um utilizador na Solana pode ser considerada uma estrutura de dados que contém informações e estado relacionados com as suas interações com a blockchain da Solana. Desta forma, uma chave pública é semelhante a um nome de ficheiro: tal como um nome de ficheiro identifica unicamente um ficheiro dentro de um sistema de ficheiros, uma chave pública da Solana identifica unicamente 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 aceder e modificar a conta. Assinar com chaves privadas é como as blockchains lidam com a autorização. O conhecimento da chave privada confere autoridade absoluta sobre a conta. As chaves privadas do Solana também têm 32 bytes de comprimento. Os pares de chaves são combinações de 64 bytes das 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 mnemónicas, geralmente com 12 ou 24 palavras. Este formato é frequentemente utilizado em carteiras para facilitar o backup e 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, computação rápida e imunidade a muitos ataques comuns. Cada endereço da carteira Solana representa um ponto na curva elíptica Ed25519.

O utilizador assina transações com a sua chave privada. Esta assinatura é incluída nos dados da transação e pode ser verificada por outros participantes utilizando 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 funciona como um identificador único para a transação.

Transações Solana

Enviar uma transação é a única forma de mutar o estado na 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, conhecida de forma mais formal como uma “mensagem de transação,” compreende quatro secções: um cabeçalho, uma lista de endereços de conta, um recente bloco de hash, e instruções.

• Cabeçalho: O cabeçalho contém referências à lista de endereços de 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.
• Blockhash Recente: Este é usado para evitar transações duplicadas e obsoletas. Um blockhash recente 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 blockhash recente 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, criação de conta, encerramento de conta). Cada instrução especifica o programa a executar, as contas necessárias e os dados necessários para a execução da instrução.

O número de instruções numa transação é primeiro limitado pelo seu tamanho, que pode ser de até 1.232 bytes. Existem também limites em relação ao número de contas que podem ser referenciadas. Por último, existem 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 um bilionésimo de um 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 é dividido em 2 partes - uma taxa base e uma taxa de priorização. A taxa base é de 5000 lamports fixos 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. Estas taxas são precificadas em micro-lamports (milionésimo de um lamport) por unidade de cálculo. O seu propósito é atuar como um sinal de preço, tornando as transações mais economicamente atrativas para os nós validadores incluírem nos seus blocos.

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

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

Atualmente, 50% de todas as taxas relacionadas com transações são queimadas, removendo permanentemente este SOL da circulação, sendo que os restantes 50% vão para o produtor de blocos. Em breve será introduzida uma nova alteração (SIMD 96) permitindo que 100% das taxas de priorização vão para o produtor de blocos. As taxas base permanecem inalteradas.

‍

Envio de transações

Um utilizador conecta a sua carteira à aplicação, permitindo que a aplicação leia a chave pública do utilizador. A chave privada permanece encriptada e segura, isolada num ambiente separado da aplicação.

A aplicação constrói os parâmetros da mensagem de transação com base nas interações do utilizador. Por exemplo, se um utilizador quiser trocar dois tokens, terá de especificar a quantidade de tokens a comprar, os tokens correspondentes a vender e uma variação aceitável na transação.

Assim que a mensagem de transação estiver pronta, é enviada para a carteira para ser assinada com a chave privada do utilizador. Neste ponto, o utilizador é solicitado com uma janela pop-up para confirmar a sua vontade de transacionar. Esta janela 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 à aplicação, que pode então encaminhar a transação para um fornecedor RPC à sua escolha, seja próprio ou através do fornecedor da carteira.

Os fornecedores de RPC (Remote Procedure Call) atuam como intermediários entre as aplicações e os validadores que constroem blocos. Eles são um serviço essencial que permite às aplicaçõessubmeterou simular transações assinadas e recuperar eficientemente dados on-chain. As aplicações que desejam interagir com a rede fazem-no através de um ponto final JSON-RPC ou WebSocket (docs).

Lembrar

O termo "transação falhada" na Solana é enganador e tem causado considerável confusão. Estas 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 da própria transação que o exige. +80% das transações "falhadas" vêm do código de erro 0x1771, o código para exceder a quantidade de deslize.dados). É de salientar que 95% destas transações são submetidas apenas por 0.1% dos endereços Solana ativos, principalmente por bots automatizados que tentam aproveitar oportunidades de arbitragem de preços 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 através da fibra. Com quem estamos competindo é a NASDAQ e a Bolsa de Valores de Nova York." - Anatoly Yakovenko, co-fundador da Solana

RPCs (Chamadas de Procedimento Remoto) referem-se aos nós RPC. Esses nós podem ser pensados como portões 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 de RPC não possuem qualquer participação na rede. Sem participação, não podem votar nem construir blocos. Esta configuração difere da maioria das outras blockchains, onde os nós validadores e de RPC são tipicamente os mesmos. Uma vez que os nós de RPC não recebem recompensas de staking, a economia de executar nós de RPC é distinta da dos validadores, muitos dos quais operam como um serviço pago para os 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 utilizam 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 líder, para cada slot.

Chamada de atenção

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 têm 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 num bloco, ela deve ser encaminhada para o líder. Um cronograma do 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. Os validadores com uma participação maior serão escolhidos com mais frequência para se tornarem líderes dentro de cada época. Durante cada slot, as 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 líder”, começa a processar ativamente transações e a transmitir 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 prevenir spam e melhorar a resistência a Sybil, conhecido como "Qualidade de Serviço Ponderada por Stake" (SWQoS). Este sistema permite aos líderes priorizar mensagens de transação que são transmitidas através de outros validadores com stake. Aqui, os validadores com uma stake mais alta recebem uma capacidade proporcionalmente maior para transmitir pacotes de mensagens de transação para o líder. Esta abordagem mitiga eficazmente ataques de Sybil de nós não staked em toda a rede.

Sob este modelo, os validadores também podem celebrar acordos para alugar a sua capacidade ponderada por participação aos nós RPC. Em troca, os nós 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 restantes 20% (500 conexões) são alocados para mensagens de transação de nós não apostados. Esta estratégia de alocação espelha faixas prioritárias em autoestradas, onde os condutores pagam portagem para evitar o trânsito.

O 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 as suas operações. Ao executarem os seus próprios nós validadores, ou ao terem acesso a conexões com apostas, as aplicações podem garantir acesso privilegiado ao líder, melhorando assim as suas capacidades de processamento de transações.

Uma Nota Rápida

No final de 2022, a Solana adotou oprotocolo de rede QUICpara gerir a transmissão de mensagens de transação para o líder. Esta transição foi motivada por perturbações na rede causadas por bots a fazer spam nas cunhagens NFT on-chain. O QUIC facilita a comunicação rápida e assíncrona.

Inicialmente desenvolvido porGoogleem 2012, o QUIC tenta oferecer o melhor dos dois mundos. Facilita a comunicação rápida e assíncrona semelhante ao UDP, mas com as sessões seguras e estratégias avançadas de controlo de fluxo do TCP. Isso permite limitar as fontes individuais de tráfego para que a rede possa focar-se no processamento de transações genuínas. Também possui um conceito de fluxos separados; assim, se uma transação for perdida, não é necessário bloquear as restantes. Em suma, 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 de participação é 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 participação recebem maior confiança e papéis prioritários na rede.

Construção de Blocos

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

Muitas redes blockchain constroem blocos inteiros antes de os transmitir, conhecido como construção de bloco discreto. Solana, por outro lado, emprega 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 tem a duração de 400 milissegundos e cada líder é atribuído quatro slots consecutivos (1,6 segundos) antes de passar a liderança para o próximo líder. Para que um bloco seja aceite, todas as transações nele contidas 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 carga de trabalho iminente. Durante este intervalo, o tráfego de entrada aumenta abruptamente, 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 central do validador responsável pela produção de blocos. Aqui, a sequência de processamento de transações começa com a Etapa de Busca, onde as transações são recebidas via QUIC. Posteriormente, as transações avançam para a Etapa de Verificação de Assinaturas, 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.

Fase Bancária

A fase bancária pode ser descrita como a fase de construção de blocos. É a fase mais importante do TPU, que recebe o seu nome do “banco“. Um banco é apenas o estado num determinado bloco. Para cada bloco, o Solana tem um banco que é usado para aceder ao estado nesse bloco. Quando um bloco se torna finalizado depois de votação suficiente de validadores, eles vão fazer o flush das 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 da blockchain de forma determinística.

As transações são processadas em paralelo e agrupadas em “entradas” no livro-razão, que são lotes de 64 transações não conflituosas. O processamento de transações em paralelo no Solana é facilitado porque cada transação deve incluir uma lista completa de todas as contas que irá ler e escrever. Essa escolha de design coloca um fardo sobre os desenvolvedores, mas permite ao validador evitar condições de corrida ao selecionar facilmente apenas transações não conflituosas para execução dentro de cada entrada. As transações entram em conflito se ambas tentarem escrever na mesma conta (duas escritas) ou se uma tentar ler e a outra escrever na mesma conta (leitura + escrita). Assim, as transações conflituosas vão para entradas diferentes e são executadas sequencialmente, enquanto as transações não conflituosas são executadas em paralelo.

Existem seis threads a processar transações em paralelo, com quatro dedicados a transações normais e dois exclusivamente a lidar com transações de voto que são essenciais para o 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 GPU.docs).

Uma vez que as transações tenham sido agrupadas em entradas, estão prontas para serem executadas pela Máquina Virtual Solana (SVM). As contas necessárias para a transação estão bloqueadas; são realizadas verificações 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 os estados das contas. Um hash da entrada será enviado para o serviço de Prova de História para ser registado (mais sobre isso na próxima secção). Se o processo de registo for bem-sucedido, todas as alterações serão registadas no banco e os bloqueios em cada conta colocados no primeiro passo são levantados. A execução é feita pela SVM, uma máquina virtual construída usando o fork Solana derBPF, uma biblioteca para trabalhar com compilação JIT e máquinas virtuais para programas eBPF. Note que a Solana não impõe como os validadores escolhem ordenar transações dentro de um bloco. Essa flexibilidade é um ponto crucial ao qual voltaremos mais tarde na seção de Economia + Jito deste relatório.

Lembrar

O termo SVM pode ser ambíguo, pois pode referir-se tanto à “Máquina Virtual Solana” como à “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 a ser utilizado de forma vaga, apesar dos esforços recentes para precisamentedefinir os seus limites.

Clientes

Solana é uma rede composta por milhares de nós operados de forma independente que colaboram 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 o cliente Agave— escrita em Rust. A diversidade de clientes em expansão 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 eficiente em qualquer blockchain.

Prova de História

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

A Prova de História (PoH) é o segredo do 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 de verdade para a ordem dos eventos e a passagem do tempo. Mais criticamente, garante a adesão ao calendário do líder. 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 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. Os carimbos de hora confiáveis nas mensagens garantem que os validadores não possam se sobrepor uns aos outros e iniciar seus blocos prematuramente.

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

• 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 imagem prévia: Encontrar a entrada original a partir da saída do hash é computacionalmente inviável.
• Efeito Avalanche: Uma pequena alteração na entrada (mesmo que seja um único bit) resulta em um hash significativamente diferente, uma propriedade conhecida como efeito avalanche.
• Resistência a colisões: É inviável encontrar duas entradas diferentes que produzam a mesma saída de hash.

Dentro de cada cliente validador, um dedicado serviço de “Prova de História” executa continuamente o algoritmo de hash SHA256 criando uma cadeia de hashes. A entrada de cada hash é a saída do hash anterior. Esta 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 futuros hashes não podem ser conhecidos antecipadamente. Se o serviço PoH cria uma cadeia de mil hashes, sabemos que passou tempo para calcular cada hash sequencialmente — isto pode ser considerado 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 saída de cada hash foram transmitidas para a rede. Portanto, PoH é difícil de produzir, mas fácil de verificar.

A gama de desempenho ao calcular 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 significativo tempo e esforço investidos na otimização desta função, em grande parte devido à dependência do Bitcoin.

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

Num único bloco, existem 800.000 hashes. O fluxo de PoH também inclui "ticks," que são entradas vazias que indicam a vivacidade do líder e a passagem do tempo aproximando-se 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 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 agendamento correto do líder deve ser seguido, mesmo que um produtor de blocos esteja offline - um estado conhecido como sendo 'delinquente'. O PoH impede que um validador malicioso produza blocos antes de ser a 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 este conceito na minha cabeça." — Anatoly Yakovenko, co-fundador da Solana

Dentro de um validador Solana, o estado global é mantido na base de dados de contas conhecida como AccountsDB. Esta base de dados é responsável por armazenar todas as contas, tanto na memória como no disco. A estrutura de dados principal no índice de contas é um hashmap, tornando o AccountsDB essencialmente um vastoarmazenamento de chave-valor. Aqui, a chave é o endereço da conta e o valor são os dados da conta.

Com o tempo, o número de contas Solana disparou para centenas de milhões. Este 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 ficheiro num computador. Eles surgem em várias formas:

• Contas de utilizador: Estas contas têm uma chave privada e são tipicamente geradas por um software de carteira para um utilizador.
• Contas de dados: Estas contas armazenam informações de estado, como o número 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 ficheiro .exe no Windows ou a um ficheiro .app no Mac.
• Contas de programa nativas: Estas são contas de programa pré-implementadas especiais que executam várias funcionalidades principais da rede.Exemplosincluindo o Programa de Votação e o Carregador BPF.

Todas as contas têm os seguintes campos:

Programas

As contas de programa 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 de código e estado diferencia a 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 uso geralconhecidopela sua forte ênfase na segurança e desempenho. Além disso, múltiplos SDKs em TypeScript e Python estão disponíveis para facilitar a criação de interfaces de aplicação e permitir interação programática com a rede.

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

Alugar

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, 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 de 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 utilizador detém uma stablecoin denominada em dólares, este estado é armazenado numa conta de token. Atualmente, o valor isento de aluguer para uma conta de token é de 0,002 SOL. Se o utilizador transferir todo o seu saldo de stablecoin para um amigo, a conta de token pode ser encerrada, e o utilizador receberá de volta os seus 0,002 SOL. Os programas costumam lidar automaticamente com o encerramento de contas para os utilizadores. Várias aplicações estão disponíveis para ajudar os utilizadores a limpar contas antigas e não utilizadas e a recuperar as pequenas quantidades de SOL armazenadas nelas.

Propriedade

Ao ler dados da conta é universalmente permitido, o modelo de propriedade da Solana melhora a segurança ao restringir exatamente quem pode modificar (escrever) os dados de uma conta. Este conceito é crucial para impor regras e permissões na blockchain da Solana. Cada conta tem um “dono” de programa. O dono 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 esta 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

Programas Solana, sendo arquivos executáveis somente leitura, devem armazenar o estado usando “Endereços Derivados do Programa” (PDAs). PDAs são tipos especiais de contas associadas e de propriedade de um programa em vez de um usuário específico. Enquanto os endereços normais de usuário Solana são derivados da chave pública de um par de chaves Ed25519, as PDAs não possuem 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 conta—junto com o ID do programa (endereço) do programa proprietário.

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). São utilizadas para guardar tokens e funcionam "fora da curva". O programa de Conta de Token Associada (ATA) garante que cada carteira só possa ter uma conta de token associada para cada tipo de token, proporcionando uma forma padronizada de gerir contas de token.

Turbina

"A parte mais interessante sobre Solana não é a paralelização, o SVM ou os tweets de Toly. É algo que você provavelmente nunca ouviu falar: turbina." — Mert Mumtaz, Helius

Durante a fase bancária, as transações são organizadas em entradas e enviadas para a corrente 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 - a Turbina.

A turbina é o processo através do qual o líder propaga o seu bloco ao 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.

O Turbine consegue isso ao dividir os dados da transação em “fragmentos” através de um processo chamado “fragmentação”. Os fragmentos são pequenos pacotes de dados, até 1280 bytes, semelhantes a frames individuais em um fluxo de vídeo. Quando reagrupados, esses fragmentos permitem que os 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 descarte malicioso de pacotes.Codificação de apagamento, apolinômioEsquema de deteção e correção de erros baseado, garante a integridade dos dados. Mesmo que algumas partes estejam perdidas, o bloco ainda pode ser reconstruído.

Os fragmentos são agrupados em lotes conhecidos como lotes de correção de erros para a 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, pois a cadeia de raízes de Merkel fornece um caminho verificável de autenticidade e integridade.

O líder transmite inicialmente 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 da Turbina". Validadores com uma quantia de participação maior geralmente estã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 simplicidade visual, um fanout de 3 é representado acima, mas o valor real do fanout da Solana está atualmente definido como 200. Por razões de segurança, a ordem da árvore é rodada 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 pressão sobre qualquer nó único.

Consensus

“Algumas pessoas inteligentes me dizem que há uma comunidade de desenvolvedores inteligentes e dedicados na Solana... Espero que a comunidade tenha a chance justa de prosperar” — Vitalik Buterin, co-fundador da Ethereum

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

Este 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. Tal como o TPU, o fluxo da TVU é dividido em várias fases, começando com a Fase de Recolha de Fragmentos onde os fragmentos são recebidos através do Turbine. Na fase subsequente de Verificação da Assinatura do Líder do Fragmento, os fragmentos passam por várias verificações de sanidade, destacando-se a verificação da assinatura do líder, que garante que os fragmentos recebidos se originaram do líder.

No estágio de retransmissão, o validador, com base em sua localização na árvore da turbina, encaminha os fragmentos para os validadores a jusante apropriados. Na etapa de repetição, o validador recria cada transação exatamente e na ordem correta enquanto atualiza sua versão local do banco.

A fase de replay é análoga à fase bancária no TPU; é a fase mais importante e pode ser mais diretamente descrita como a fase de validação de bloco. O replay é um processo de loop 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 palco de repetição é responsável por colocar o validador no modo líder e iniciar a produção de blocos. Visual original: Justin Starry, Anza

Consensus

Para alcançar consenso, Solana usa Tower BFT (TBFT), uma implementação personalizada do conhecido PracticalFalha BizantinaO algoritmo de Tolerância a Falhas Bizantinas (PBFT), comumente usado pela maioria das blockchains para concordar com o estado da cadeia. Como todas as blockchains, Solana pressupõe 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 aproveitar o relógio sincronizado fornecido pelo Proof of History. Enquanto o PBFT tradicional requer múltiplas rondas de comunicação para concordar com a ordem das transações, os nós da Solana utilizam a ordem pré-estabelecida dos eventos, reduzindo significativamente a sobrecarga de mensagens.

Votação

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

Forks

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 nesses forks e usar um algoritmo de consenso para determinar qual adotar. Quando existem forks concorrentes, apenas um fork será finalizado pela rede, enquanto os blocos nos forks descartados 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 uma única ranhura. Portanto, o número de garfos potenciais é limitado a uma lista de pulos "lá/não-lá" de garfos 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 skip" da Solana - a percentagem de slots em que um bloco não foi produzido - varia de 2% a 10%, sendo as forks a razão principal para estes slots pulados. Outras razões possíveis 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 estado de uma transação na Solana varia dependendo da sua fase atual no processo de consenso:

• Processado: A transação foi incluída num 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é à data, nunca houve um caso na história da Solana em que um bloco confirmado (otimisticamente) não se tenha tornado finalizado.

Para cada bloco, Solana utiliza um banco para aceder ao estado nesse bloco. Quando um banco é finalizado, as atualizações da conta desse banco e dos seus antecessores são escritas no disco. Além disso, quaisquer atualizações de conta de bancos anteriores que não sejam antecessores do banco finalizado são podadas. Este processo permite que o Solana mantenha múltiplos estados potenciais de forma eficiente.

Fofoca + Arquivo

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

Fofoca

A rede de fofocas pode ser pensada 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 da blockchain, como informações de contato, altura do razão e informações de votação. Sem fofoca, os validadores e os 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 da fofoca para se juntar à rede.

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

Os rumores operam de certa forma como um sistema isolado, independente da maioria dos outros componentes de validação. Os validadores e RPCs partilham objetos de dados assinados a cada 0,1 segundos via UDP através de rumores, garantindo a disponibilidade de informações em toda a rede. Todas as mensagens de rumores devem ser inferiores ou iguais à unidade máxima de transmissão (MTU) de 1280 bytes, referida como a “estrutura de pacotes” na base de código.

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

Existem quatro tipos de mensagens de fofocas:

• Push: As mensagens mais comuns, partilhando informações com um subconjunto de "pares de push."
• Pull & Pull Response: Verifica periodicamente mensagens perdidas, com respostas de pull enviando de volta a informação 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: Verificações de saúde para nós - se for enviado um ping, espera-se um pong de volta, indicando que o nó peer ainda está ativo.

Os dados de fofocas são armazenados num Cluster Replicated Data Store (CrdsTable). Esta estrutura de dados pode crescer muito e precisa de ser podada periodicamente.

Arquivo

Solana destaca-se de outras blockchains por não exigir toda a história 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 os 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 ledger histórico inteiro. Em vez disso, eles geralmente armazenam apenas os 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 geridos por “nós de armazém,” operados por fornecedores 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 armazém normalmente mantêm um ou ambos os seguintes:

1. Arquivo de Ledger: Carrega instantâneos brutos do ledger e AccountsDB adequados para reprodução a partir do zero.

2. Instância do Google Bigtable: Armazena dados em bloco a partir do bloco gênesis, formatado para atender a pedidos RPC.

Economia + Jito

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

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

Qualquer detentor de token SOL pode ganhar recompensas e ajudar a proteger a rede apostando 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, ele não dá ao validador a propriedade ou controle sobre os tokens. Todas as ações de staking, unstaking e delegação são executadas no início da próxima nova época.

‍

Recompensas de Votação

Quando um validador submete um voto, ganham um crédito se o voto for preciso e bem-sucedido. As transações de voto custam 0,000005 SOL e estão isentas de taxas de prioridade. As despesas de voto ascendem a cerca de 1 SOL por dia por validador, tornando-se o principal custo operacional de executar um validador. Ao longo de um período, os validadores acumulam créditos a partir dos votos, que podem trocar por uma parte da inflação no final do período.

Os validadores com melhor desempenho votam com sucesso em aproximadamente 90% dos slots. Note que a percentagem de slots sem blocos (taxa de slots pulados) 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 total da potência da inflação é primeiro dividido com base nos créditos ganhos para a época. A quota do validador dos créditos totais (seus créditos divididos pela soma de todos os créditos dos validadores) determina a sua recompensa proporcional. Isso é ainda ponderado pela participação.

Portanto, um validador com 1% da participação total 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.

As 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 corresponde a uma percentagem das recompensas totais de inflação direcionadas para o seu validador. Além disso, um validador estar offline ou fora de sincronia com a blockchain (conhecido como negligência) impacta significativamente os retornos.

Recompensas em bloco

Os validadores designados como líderes para um bloco específico recebem recompensas adicionais em bloco. Essas recompensas incluem 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 em bloco são creditadas instantaneamente na conta de identidade do validador quando o bloco é produzido.

Liquid staking

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 dos seus SOL, geralmente numa pool de staking que delega os seus tokens por vários validadores. Os tokens LST recém-recebidos representam a participação do utilizador no SOL staked. Estes tokens podem ser negociados, usados em aplicações ou transferidos para outros, enquanto continuam a ganhar recompensas de staking. A principal vantagem deste sistema é que aumenta significativamente a eficiência de capital.

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

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

Jito

Neste momento, mais de 80% ( fonte) do stake na Solana utiliza o software de validação cliente Jito. 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 gorjetas. 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, as 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 de rede permanecem inconscientes da existência do Jito-Relayer, pois simplesmente enviam transações para o endereço e configuração da porta que o líder divulgou sobre a rede de gossip como seu ingress_socket, assumindo que seja do líder.

O relayer retém todas as transações durante 200 milissegundos antes de as encaminhar para o líder. Este mecanismo de "quebra-molas" atrasa as mensagens de transações recebidas, proporcionando uma breve janela para a realização de leilões. Após 200 milissegundos, o relayer liberta 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 pesquisadores e aplicações enviem grupos de transações atomicamente executadas conhecidas como bundles. Esses bundles normalmente contêm transações sensíveis ao tempo, como arbitragens ou liquidações. Jito cobra uma taxa de 5% em todas as gorjetas, com uma gorjeta mínima de 10.000 lamports. As gorjetas funcionam inteiramente fora do protocolo, separadas das taxas de prioridade e base do protocolo. Anteriormente, o Jito operava um serviço de mem-pool canônico fora do protocolo, que agora foi descontinuado.

Aviso legal：

1. Este artigo é reproduzido a partir de [helius]. Todos os direitos autorais pertencem ao autor original [Lostin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa e eles tratarão do assunto prontamente.
2. Aviso de responsabilidade: As 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. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.