Solana Sealevel: Motor de Processamento Paralelo

O Processamento Paralelo Solana Sealevel permite que o ambiente de execução execute transações não conflitantes ao mesmo tempo quando essas transações declaram as contas que irão ler e escrever. O Sealevel é, portanto, um modelo de execução, não um Mecanismo de consenso independente ou uma garantia de que cada carga de trabalho será executada em paralelo.

Os números de desempenho neste artigo requerem contexto. O valor de 65.000 TPS amplamente citado é um benchmark teórico ou de teste controlado, não throughput garantido em Mainnet. Uma meta de slot de aproximadamente 400 milissegundos não é o mesmo que finalidade de transação, e as taxas variam com as assinaturas, uso de computação, configurações de prioridade e condições da rede.

A Ethereum processa aproximadamente 15 transações por segundo na sua camada base. A documentação da Solana tem historicamente citado até 65.000 TPS sob condições teóricas ou controladas; o throughput real voltado para o utilizador varia. Essa lacuna não é sorte. O motor por trás dela chama-se Sealevel.

Sealevel é o ambiente de tempo de execução de Smart Contract paralelo da Solana: o motor de execução que processa milhares de transações independentes simultaneamente em vez de uma de cada vez. Foi concebido por Anatoly Yakovenko, um antigo engenheiro da Qualcomm que fundou a Solana Labs (a empresa por trás do desenvolvimento do protocolo principal da Solana) e que escreveu o Whitepaper fundamental da Solana em 2017.

Imagine uma autoestrada principal durante a hora de ponta. A Solana (uma blockchain, ou livro razão digital distribuído e à prova de adulteração) usa o Sealevel para construir centenas de faixas e organizar o tráfego de entrada por destino. Cada carro na Ethereum tem de usar uma única faixa. Os carros formam fila uns atrás dos outros e avançam um de cada vez. O Sealevel organiza os carros por destino: aqueles que se dirigem a endereços diferentes viajam simultaneamente, sem esperar. Apenas os carros que se dirigem exatamente ao mesmo endereço precisam de esperar. Esse mecanismo de organização é a visão arquitetural por trás da vantagem de velocidade da Solana.

Este explicador aborda o que é Sealevel, como funciona mecanicamente o seu paralelismo baseado em contas, como se compara ao ambiente de execução da Ethereum, onde falha e o que essas capacidades significam para os desenvolvedores e investidores que avaliam Solana.

Processamento Paralelo Solana Sealevel: Visão Geral Rápida

• Sealevel é o ambiente de tempo de execução de Smart Contract paralelo da Solana, processando milhares de transações simultaneamente.
• Como funciona: as transações declaram dependências de contas antecipadamente; o Sealevel executa as não conflitantes em paralelo.
• Throughput: máximo teórico de ~65.000 TPS; transações reais não de voto tipicamente atingem 2.000–4.000 TPS.
• vs. Ethereum: a EVM da Ethereum processa transações uma de cada vez; o Sealevel processa as independentes simultaneamente.
• Limitação honesta: Solana sofreu interrupções de rede em 2021 e 2022 devido a falhas de ingestão a montante do Sealevel.

Execução Sequencial vs. Paralela: O Problema Central que o Sealevel Resolve

Execução sequencial e paralela são duas abordagens fundamentalmente diferentes para processar transações de blockchain, e a distinção explica a maior parte da lacuna de desempenho entre Solana e Ethereum.

Execução sequencial significa que uma transação é concluída inteiramente antes que a próxima comece. Uma transação chega, a blockchain bloqueia o estado relevante, executa a computação, grava o resultado, desbloqueia o estado e só então inicia a próxima transação. Cada etapa bloqueia a que vem atrás. Não há sobreposição, nem concorrência, nem processamento simultâneo de trabalho independente.

O teto de throughput que isso cria é real. A Máquina Virtual Ethereum (EVM) da Ethereum processa aproximadamente 15–30 transações por segundo na sua cadeia base de Camada 1 (L1) sem Rollups de Camada 2 (L2), de acordo com a documentação da Ethereum Foundation. Esse valor permaneceu aproximadamente constante durante anos porque o gargalo é arquitetural.

O desafio mais amplo é capturado pelo trilema de escalabilidade amplamente citado, a observação de que as blockchains historicamente lutam para maximizar a descentralização e a segurança, ao mesmo tempo que alcançam alta escalabilidade. A execução sequencial é a principal restrição de escalabilidade. Adicionar hardware mais rápido não o resolve porque o modelo de execução, por si só, serializa todo o trabalho através de um único pipeline.

O processamento paralelo oferece uma resposta diferente. Em vez de um caixa para todos os clientes, imagine um supermercado com 500 filas de checkout. Clientes a comprar itens completamente diferentes (sem terminais de pagamento partilhados, sem contas de fidelidade partilhadas) podem fazer o checkout em todas as filas simultaneamente. Apenas os clientes que realmente precisam de partilhar um terminal precisam de esperar por ele. O throughput total da loja aumenta em ordens de magnitude, não porque qualquer caixa individual se tornou mais rápido, mas porque transações independentes pararam de se bloquear mutuamente.

Um ambiente de tempo de execução de Smart Contract é o ambiente de software que executa o código de Smart Contract numa blockchain. É a camada que pega no código do programa e o executa de facto. Na Solana, os Smart Contracts são chamados de "programas" (o termo canónico na documentação da Solana, embora "Smart Contract" continue a ser amplamente compreendido e usado de forma intercambiável aqui). O Sealevel é o ambiente de tempo de execução da Solana: construído de raiz para executar milhares destes programas simultaneamente em vez de em sequência.

Compreender como o Sealevel consegue isto de forma segura, sem condições de corrida ou estado corrompido, requer a compreensão do mecanismo arquitetural que torna o paralelismo seguro. Esse mecanismo é o modelo de contas da Solana.

Como Funciona o Sealevel: O Modelo de Contas e a Declaração de Estado Antecipada

O Sealevel alcança execução paralela segura através de duas características arquiteturais que trabalham em conjunto: o modelo de contas da Solana e a pré-ordenação de transações fornecida pelo Proof of History (PoH), um mecanismo de relógio criptográfico que cria um carimbo de data/hora verificável para cada evento na rede Solana. Esta secção explica ambos.

O Modelo de Contas da Solana: Separar Código de Estado

O Sealevel pode executar transações em paralelo porque o modelo de contas da Solana lhe fornece as informações necessárias para fazê-lo com segurança antes do início da execução.

Na Solana, os programas contêm apenas código executável e não armazenam dados por si. Estes são programas sem estado: carregam instruções mas não detêm o seu próprio estado. Os dados residem em objetos de conta separados dos quais os programas podem ler ou para os quais podem escrever. Este design separa o código do estado a nível arquitetural. É distinto do modelo da Ethereum, onde um Smart Contract armazena tanto o seu código executável como o seu estado num único endereço de contrato.

Cada transação Solana deve declarar antecipadamente de quais contas irá ler e para quais irá escrever, antes do início da execução. O Sealevel lê estas declarações para agendar a execução. Uma transação que omita este passo será rejeitada pelo ambiente de execução. Isto não é uma contabilidade opcional: é o pré-requisito estrutural que torna o paralelismo seguro possível.

Imagine dois chefs a trabalhar numa cozinha com seis fogões. O Chef A está a fazer massa e precisa dos fogões um e dois. O Chef B está a fazer um refogado e precisa dos fogões quatro e cinco. Eles podem trabalhar simultaneamente sem qualquer coordenação porque as suas superfícies de trabalho não se sobrepõem. Nenhum precisa de esperar pelo outro. Apenas se ambos os chefs precisarem do fogão três ao mesmo tempo, um terá de esperar. O Sealevel aplica esta lógica exata às transações: aquelas que usam contas diferentes são executadas em paralelo; aquelas que partilham uma conta de escrita são executadas em sequência.

Nota do programador: O ambiente de execução rejeitará transações que acedam a contas não declaradas. O acesso às contas tem de ser determinado no momento da construção da transação e não durante a execução. Esta restrição é o mecanismo de design que permite o agendamento paralelo descrito abaixo.

Como o Sealevel Agenda a Execução Paralela

Quando uma transação atinge o Sealevel, o processo de agendamento segue quatro etapas distintas.

1. Uma transação chega acompanhada de um manifesto: a lista completa de contas que irá ler e das contas em que irá escrever.
2. O Sealevel constrói um grafo de dependência (um mapa das transações que partilham contas) comparando simultaneamente os manifestos de todas as transações pendentes.
3. As transações que não partilham contas de escrita são independentes. O Sealevel envia-as para núcleos de processador distintos simultaneamente, executando-as em paralelo em todos os núcleos de CPU e GPU disponíveis.
4. As transações que declaram uma dependência de escrita na mesma conta estão em conflito. O Sealevel serializa essas transações específicas, executando-as uma após a outra na ordem estabelecida pela PoH, enquanto todas as outras transações não conflituosas continuam a ser executadas em paralelo.

Esta abordagem é paralelismo determinístico: o Sealevel identifica conflitos antes do início da execução, em vez de os resolver a posteriori. Não executa transações especulativamente nem desfaz falhas. Isto distingue-o de abordagens de concorrência otimista como o Aptos Block-STM, onde as transações são executadas primeiro especulativamente e reexecutadas em caso de conflito.

O Sealevel também pode encaminhar tarefas de verificação de assinaturas para núcleos de GPU, de forma semelhante a como uma GPU executa milhares de cálculos de shader em simultâneo em cargas de trabalho de jogos ou IA. A Unidade de Processamento de Transações (TPU) da Solana utiliza 'pipelining' para executar fases de validação de transações em simultâneo em unidades de hardware, com o Sealevel a gerir a fase de execução desse 'pipeline'.

Sealevel vs. a EVM do Ethereum: Uma Comparação Arquitetural Direta

A Solana é mais rápida do que a Ethereum na camada base, principalmente devido ao Sealevel, o seu runtime de execução paralela de contratos inteligentes. Enquanto a EVM da Ethereum processa uma transação de cada vez numa sequência rigorosa, o Sealevel processa milhares de transações independentes simultaneamente através de múltiplos núcleos de processamento.

Comparação Sealevel vs. EVM

A EVM processa transações uma a uma porque a sua arquitetura de contratos com estado torna arquiteturalmente difícil determinar antecipadamente quais as transações que podem ser paralelizadas em segurança. Os contratos inteligentes na Ethereum armazenam o seu próprio estado. Dois contratos quaisquer podem, teoricamente, partilhar estado, e sem saber antecipadamente quais as transações independentes, paralelizar transações acarreta o risco de corromper o estado. Isto não é uma falha no design da Ethereum; é uma consequência da sua arquitetura.

A Solana compila programas para o bytecode eBPF (extended Berkeley Packet Filter) modificado da Solana: um conjunto de instruções compacto adaptado de um formato nativo de Linux bem estabelecido. O Sealevel executa este bytecode a velocidades quase nativas. Em contrapartida, o bytecode da EVM é executado numa máquina virtual personalizada emulada por software. A abordagem BPF proporciona caminhos de otimização ao nível do hardware que o formato personalizado da EVM não oferece, contribuindo para a vantagem de débito do Sealevel ao nível da execução de instruções.

O que torna a Solana arquitetonicamente diferente da Ethereum:

• Modelo de execução: paralelo determinístico (Sealevel) vs. sequencial (EVM)
• Arquitetura de estado: programas sem estado e contas de dados separadas vs. contratos com estado
• Abordagem de escalabilidade: execução paralela em L1 vs. rollups de L2 e sharding
• Linguagem de desenvolvimento: Rust vs. Solidity

Para contextualizar como os modelos de conta diferem entre as arquiteturas de blockchain de Layer-1, o contraste entre a abordagem de declaração antecipada da Solana e outros designs de armazenamento on-chain é elucidativo.

Sealevel vs. Aptos Block-STM e Monad: Como as Abordagens de Execução Paralela Diferem

O Sealevel não é a única arquitetura de execução paralela em produção. Comparar a sua abordagem com a do Block-STM da Aptos e da Monad, bem como da Sui, revela os compromissos distintos que cada design assume.

A Aptos utiliza Block-STM (Memória Transacional de Software), uma abordagem de concorrência otimista. Executa transações especulativamente em paralelo sem exigir declaração prévia de contas, valida os resultados e reexecuta quaisquer transações que apresentaram conflitos. A vantagem para os programadores: não é necessário declarar dependências de contas no momento da criação. A contrapartida: cargas de trabalho com elevada incidência de conflitos desencadeiam a reexecução, o que consome tempo. O Sealevel evita totalmente a reexecução porque identifica conflitos antes da sua execução.

A Monad visa a execução paralela da EVM com compatibilidade com Solidity da Ethereum. Canaliza as fases de execução e aplica paralelismo otimista no modelo EVM. A aposta da Monad é que a compatibilidade com a EVM compensa o overhead arquitetural. A Sealevel fez a escolha oposta: um modelo de conta totalmente novo com maior paralelismo bruto, mas que exige que os programadores adotem um novo paradigma de programação.

A Sui utiliza a propriedade baseada em objetos como a sua unidade de paralelismo. As transações que tocam em objetos independentes são executadas em paralelo por definição, sem exigir uma declaração explícita. De acordo com a documentação atual, cada abordagem (o modelo determinístico de Sealevel, o modelo otimista de Block-STM, o modelo de propriedade de objetos de Sui) representa uma resposta diferente para a mesma questão: como alcançar um paralelismo seguro à escala.

Nenhuma abordagem é universalmente superior. A declaração antecipada da Sealevel cria sobrecarga para o programador. O modelo otimista da Block-STM incorre em custos de re-execução sob cargas com elevado nível de conflito. A Monad troca margem de desempenho bruto por compatibilidade com Solidity. A escolha correta depende dos requisitos do caso de utilização e do ecossistema de programadores em que a equipa já opera.

O Papel do Sealevel na Arquitetura de Oito Inovações da Solana

O paralelismo do Sealevel só é seguro porque a Proof of History (PoH) já estabeleceu uma ordem de transação confiável antes de a execução começar. Compreender esta dependência revela como o Sealevel se integra na arquitetura mais ampla de oito inovações da Solana e porque é que os componentes não podem ser avaliados isoladamente.

A arquitetura da Solana assenta em oito inovações co-projetadas: PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, Archivers. Cada uma gere uma etapa distinta do ciclo de vida da transação. O Sealevel é a camada de execução: o motor que executa programas.

PoH é um mecanismo de relógio criptográfico que cria um carimbo de data/hora verificável para cada evento na rede Solana. Todos os validadores concordam com esta sequência de carimbos de data/hora. Quando as transações chegam ao Sealevel, a questão da ordem já está resolvida. O Sealevel não coordena. Ele agenda.

Pense nisto como uma linha de montagem. O PoH é o tapete rolante que entrega itens de trabalho pré-ordenados numa sequência verificada. O Sealevel é a equipa de trabalhadores na linha que recolhe e processa itens não conflituantes em simultâneo. Os trabalhadores não precisam de negociar qual o próximo item a tratar, porque o tapete já determinou a ordem. Sem o tapete, os trabalhadores parariam e coordenar-se-iam constantemente, eliminando inteiramente o benefício do paralelismo.

Como o PoH pré-encomenda transações e o modelo de conta requer declaração de estado antecipada, o Sealevel identifica quais transações entram em conflito antes do início da execução. Os conflitos são resolvidos prospectivamente, não após o facto, ao contrário dos modelos de concorrência otimista que executam primeiro e reiniciam em caso de colisão.

As inovações restantes desempenham um papel de suporte. A Tower BFT (o mecanismo de consenso da Solana, uma variante otimizada para PoH da Practical Byzantine Fault Tolerance) valida os blocos que o Sealevel produz. O Gulf Stream (o protocolo de encaminhamento de transações sem mempool) envia transações para os validadores antes da confirmação do bloco, para que o Sealevel possa começar a processar o próximo lote enquanto o bloco atual é finalizado. O Cloudbreak (a base de dados de contas) é co-projetado com o Sealevel para suportar leituras e escritas concorrentes em milhares de threads de execução paralelos.

Desempenho no Mundo Real: O Que o Sealevel Entrega (e Onde Falha Short)

O Sealevel oferece ganhos reais de taxa de transferência em comparação com blockchains de execução sequencial, mas o seu desempenho no mundo real fica bem abaixo do máximo teórico, e a rede sofreu interrupções significativas. Ambos os factos são importantes para uma avaliação honesta.

Taxa de Transferência Teórica vs. Real

Os números de taxa de transferência da Solana requerem leitura atenta porque o número frequentemente citado, aproximadamente 65.000 Transações Por Segundo (TPS), descreve um teto arquitetónico teórico, não o desempenho típico da mainnet.

Os números de TPS publicados frequentemente incluem transações internas de voto de validador, que inflacionam o número reportado. O TPS sem voto reflete a taxa de transferência real das transações dirigidas ao utilizador.

O número de ~65.000 TPS é real como um teto de design arquitetónico. Descreve o que o Sealevel pode processar em condições ideais com perfis de transação ótimos. O número do mundo real é inferior por várias razões documentadas: complexidade das transações, contenção de contas em programas populares e restrições a nível de rede a montante do próprio Sealevel. Mesmo assim, a taxa de transferência da mainnet da Solana supera substancialmente a camada base da Ethereum, com aproximadamente 15–30 TPS (documentação Ethereum Foundation).

A capacidade de execução paralela do Sealevel é uma realidade arquitetónica documentada, não uma afirmação de marketing. O número de TPS teórico reflete o design do runtime; o número do mundo real reflete o ambiente operacional à sua volta.

Interrupções e Congestionamento da Rede: Uma Avaliação Honesta

A Solana sofreu várias interrupções importantes da rede em 2021 e 2022, e qualquer tratamento honesto do Sealevel deve explicar por que razão essas interrupções ocorreram apesar da capacidade de processamento paralelo do runtime.

Um incidente em setembro de 2021 durou aproximadamente 17 horas. Uma botnet que tentava obter vantagem num lançamento de tokens inundou a camada de ingestão de transações da rede com spam, sobrecarregando-a. Interrupções significativas adicionais ocorreram em janeiro de 2022 e em vários pontos ao longo de 2022. Estes são eventos históricos documentados com relatórios post-mortem publicados.

As interrupções não foram falhas da lógica de execução paralela do Sealevel. Foram falhas da infraestrutura de ingestão de transações a montante do Sealevel. A capacidade de ~65.000 TPS do Sealevel descreve quantas transações válidas pode processar; não torna a rede imune a inundações de transações. Uma autoestrada com 100 faixas ainda fica congestionada quando um bilião de carros tentam entrar na rampa de acesso simultaneamente. O teto de processamento e a resistência a spam são problemas de engenharia separados.

Eventos de mint de Token Não Fungível (NFT), onde milhares de utilizadores tentam fazer mint simultaneamente, criaram alguns dos picos de carga mais intensos que a rede enfrentou e expuseram o mesmo gargalo da camada de ingestão.

A Solana implementou desde então várias respostas de engenharia: o protocolo QUIC substituiu o UDP para ingestão de transações (proporcionando melhor controlo de congestionamento), mercados de taxas locais permitem que as aplicações definam taxas de prioridade sob carga, e o cliente validador Firedancer desenvolvido pela Jump Crypto deverá melhorar ainda mais a taxa de transferência e a resiliência. Estas respostas mostram melhoria iterativa, mas nenhuma atualização elimina a tensão fundamental entre a submissão de transações de acesso aberto e a capacidade de processamento limitada.

A execução paralela multi-core do Sealevel também exige que os validadores executem hardware de alta especificação: processadores multi-core rápidos, grandes alocações de RAM e conexões de rede de alta largura de banda. Isto cria barreiras significativas à participação do validador e representa uma troca de descentralização que os críticos da arquitetura da Solana identificam corretamente.

O Sealevel é uma Vantagem Competitiva Duradoura para a Solana (SOL)?

O Sealevel confere à Solana uma vantagem real de taxa de transferência na camada base. Se essa vantagem constitui uma vantagem competitiva duradoura requer a separação dos factos arquitetónicos das variáveis do ecossistema.

O argumento a favor da durabilidade começa com a profundidade de integração. A arquitetura do Sealevel está intimamente ligada a outros componentes co-projetados da Solana. O PoH pré-encomenda transações antes de chegarem ao Sealevel. O Cloudbreak gere leituras de armazenamento concorrentes que as threads paralelas do Sealevel exigem. O Gulf Stream reduz o backlog de transações que o Sealevel tem de processar. Replicar o desempenho do Sealevel isoladamente, sem esta stack completa, não reproduz a vantagem. Essa integração é uma barreira genuína à replicação: não absoluta, mas não trivial.

O modelo de conta também cria custos de mudança reais para os programadores que construíram aplicações de produção em torno do paradigma do Sealevel. As arquiteturas de programa concebidas em torno da declaração de contas antecipada, padrões PDA e o framework de desenvolvimento Anchor não são portadas para cadeias EVM sem re-arquitetura significativa. A biblioteca crescente de ferramentas Rust, recursos Anchor, serviços de auditoria e implementações de referência adiciona mais inércia.

O argumento contra a durabilidade permanente é igualmente real. Aptos e Monad demonstram que arquiteturas de execução paralela podem ser construídas sobre diferentes fundações técnicas. O ecossistema L2 da Ethereum (Arbitrum, Optimism, Base) alcança alta taxa de transferência através de execução fora da blockchain com liquidação na blockchain, um caminho diferente para a escalabilidade que contorna inteiramente as restrições do Sealevel. Para muitos casos de uso de Finanças Descentralizadas (DeFi) (incluindo market makers automatizados, ou AMMs, e exchanges descentralizadas, ou DEXs como Orca e Raydium), a taxa de transferência do rollup L2 é suficiente sem exigir a mudança de paradigma do Sealevel.

Onde a vantagem do Sealevel é mais estruturalmente defensável é em casos de uso que exigem atualizações de estado na blockchain simultâneas e de alta frequência: livros de ordens na blockchain, motores de liquidação e grandes eventos de mint NFT onde milhares de transações independentes devem ser liquidadas simultaneamente. Estes casos de uso permanecem arquiteturalmente difíceis em cadeias EVM mesmo com soluções L2, porque a liquidação L2 ainda requer coordenação com a camada L1 para finalidade.

O Sealevel representa um diferenciador arquitetónico genuíno e documentado na camada base. A sua vantagem competitiva é real, mas não permanente. Enfrenta pressão de cadeias paralelas emergentes e do ecossistema L2 em expansão da Ethereum. A durabilidade da posição da Solana depende tanto dos efeitos de rede (adoção de programadores, valor total bloqueado DeFi, infraestrutura institucional) como da arquitetura técnica bruta do runtime.

Para contexto sobre posicionamento competitivo de Camada-1 em redes blockchain e como as trocas arquitetónicas se desenrolam em diferentes designs L1, os paralelos às escolhas de design do Sealevel são instrutivos.

Esta secção destina-se apenas a fins informativos e educacionais e não constitui aconselhamento financeiro, de investimento ou de negociação. Investimentos em criptomoedas acarretam riscos significativos, incluindo o risco de perda total. Consulte um consultor financeiro qualificado antes de tomar decisões de investimento.

Recursos Relacionados da Arquitetura Solana

O Sealevel depende do modelo de conta da Solana e é uma parte da arquitetura de velocidade mais ampla da Solana. Os leitores de mercado podem consultar a página de preços SOL. O Contrato Perpétuo SOLUSDT é um derivado alavancado e acarreta risco de liquidação; não é uma medida do desempenho técnico do Sealevel.

FAQ: Processamento Paralelo do Sealevel da Solana

Estas perguntas frequentes abordam os pontos de confusão mais comuns sobre o modelo de execução paralela do Sealevel, figuras de débito (throughput) e a relação com outras arquiteturas de blockchain.

O Sealevel é o runtime de contratos inteligentes paralelos da Solana: o motor de execução que processa milhares de transações independentes simultaneamente em vez de uma de cada vez. Ao identificar quais transações não partilham dependências de dados através do modelo de conta da Solana, o Sealevel as envia para núcleos de processador separados ao mesmo tempo, permitindo um débito que a execução sequencial não consegue igualar.

O Sealevel exige que cada transação declare antecipadamente quais contas lerá e escreverá. Utiliza estas declarações para construir um grafo de dependência que identifica quais transações não têm contas sobrepostas. Essas transações independentes são executadas simultaneamente em múltiplos núcleos de processador. Transações que partilham uma conta de escrita são serializadas e executadas em sequência, enquanto todas as outras transações não conflituantes continuam em paralelo.

A Máquina Virtual Ethereum (EVM) processa transações sequencialmente, uma de cada vez, porque a arquitetura de contratos com estado da Ethereum torna arquiteturalmente difícil determinar antecipadamente quais transações são seguras para paralelizar. O Sealevel processa transações não conflituantes simultaneamente porque o modelo de conta da Solana exige que as transações declarem as suas dependências de estado antecipadamente, dando ao Sealevel a informação necessária para paralelizar com segurança antes do início da execução.

A Solana pode processar teoricamente até ~65.000 TPS em condições ideais, de acordo com a documentação da Solana Labs. Na prática, o débito real na Mainnet para transações não de voto geralmente situa-se na gama de 2.000–4.000 TPS, dependendo da complexidade da transação, da contenção de contas e das condições da rede. Isto permanece substancialmente superior ao débito da camada base da Ethereum de aproximadamente 15–30 TPS.

Os programas Solana são escritos principalmente na linguagem de programação Rust, embora C e C++ também sejam suportados. Todos os programas são compilados para o formato de bytecode eBPF (extended Berkeley Packet Filter) modificado da Solana antes de serem implementados na blockchain. O framework Anchor é uma ferramenta de desenvolvimento amplamente utilizada baseada em Rust, abstraindo a gestão de contas e reduzindo o código repetitivo para o desenvolvimento de programas Solana.

As interrupções da rede Solana em 2021 e 2022 não foram causadas por falhas na lógica de execução paralela do Sealevel. Resultaram de inundações de spam e transações malformadas que sobrecarregaram a camada de ingestão de transações da rede, um sistema separado a montante do Sealevel. O limite de TPS do Sealevel descreve quantas transações válidas pode processar; não torna a rede imune a ataques de inundação de transações a nível de ingestão.

O Proof of History (PoH) habilita o Sealevel ao estabelecer uma ordem de transações confiável antes do início da execução. O PoH é um mecanismo de relógio criptográfico que produz uma sequência de timestamps verificáveis sobre a qual todos os validadores concordam. Como a ordem das transações é resolvida antes do Sealevel receber as transações, este não precisa de pausar e coordenar-se com os validadores. Pode agendar imediatamente transações não conflituantes através de threads de processamento paralelo.

Conclusão: O Que o Sealevel Significa para o Futuro da Solana

O Sealevel é a resposta mais clara que a Solana tem para a questão que todas as blockchains enfrentam: como processar mais transações sem sacrificar a segurança ou a descentralização?

A execução paralela do Sealevel é uma capacidade arquitetural real e documentada que separa o modelo de execução da Solana de todas as blockchains de execução sequencial na Camada-1. O seu débito no mundo real é significativo, bem acima da camada base da Ethereum, mas permanece abaixo dos máximos teóricos e está sujeito a restrições na camada de ingestão que produziram interrupções na rede. A sua durabilidade como vantagem competitiva depende do desenvolvimento do ecossistema e do ritmo de arquiteturas de execução paralela concorrentes, tanto quanto do próprio design do runtime.

O lançamento do cliente validador Firedancer e a maturação de cadeias paralelas concorrentes como a Monad irão acentuar o quadro competitivo nos próximos anos. A questão relevante já não é se a execução paralela na camada base é alcançável. É qual abordagem arquitetural serve melhor cada caso de uso em escala.

Leitura Relacionada

• Execução na Ethereum Smart Contract: Um Framework de Negociação em 5 Passos
• Como os Modelos de Conta Funcionam em Arquiteturas Blockchain
• Comparação da Arquitetura de Camada-1 Blockchain: Near Protocol vs. FetchAI

Fontes

1. Anatoly Yakovenko, "Solana: A new architecture for a high performance blockchain v0.8.13," 2017. https://solana.com/solana-whitepaper.pdf
2. Documentação para programadores Solana: Modelo de programação e modelo de conta. https://docs.solana.com/developing/programming-model/accounts
3. Documentação de programas na blockchain Solana. https://docs.solana.com/developing/on-chain-programs/overview
4. Ethereum Foundation: Documentação da Máquina Virtual Ethereum (EVM). https://ethereum.org/en/developers/docs/evm/
5. Relatórios de interrupções e desempenho da rede Solana. https://solana.com/news/
6. Documentação de execução paralela Aptos Block-STM. https://aptoslabs.com/developer