Solana Sealevel: Motor de Processamento Paralelo

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

Os números de desempenho neste artigo exigem contexto. O número amplamente citado de 65.000 TPS é um benchmark teórico ou de teste controlado, não a taxa de transferência garantida na Mainnet. Uma meta de slot de aproximadamente 400 milissegundos não é o mesmo que finalidade de transação, e as taxas variam com assinaturas, uso de computação, configurações de prioridade e condições de rede.

A Ethereum processa aproximadamente 15 transações por segundo em sua camada base. A documentação da Solana historicamente citou até 65.000 TPS em condições teóricas ou controladas; a taxa de transferência real voltada para o usuário varia. Essa diferença não é sorte. O motor por trás disso é chamado Sealevel.

Sealevel é o runtime 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 ex-engenheiro da Qualcomm que fundou a Solana Labs (a empresa por trás do desenvolvimento do protocolo central da Solana) e escreveu o Whitepaper fundacional da Solana em 2017.

Imagine uma grande rodovia durante o horário de pico. A Solana (uma blockchain, ou ledger digital distribuído e à prova de adulteração) usa o Sealevel para construir centenas de pistas e classificar o tráfego de entrada por destino. Cada carro na Ethereum deve usar uma única pista. Os carros formam fila uns atrás dos outros e avançam um de cada vez. O Sealevel classifica os carros por destino: aqueles que vão para endereços diferentes viajam simultaneamente, sem esperar. Apenas carros que vão para o mesmo endereço exato precisam formar fila. Esse mecanismo de classificação é a visão arquitetural por trás da vantagem de velocidade da Solana.

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

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

• Sealevel é o runtime 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.
• Taxa de transferência: máximo teórico de ~65.000 TPS; transações reais de não voto normalmente atingem 2.000–4.000 TPS.
• vs. Ethereum: a Máquina Virtual Ethereum (EVM) processa transações uma de cada vez; o Sealevel processa as independentes simultaneamente.
• Limitação honesta: a 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 o cálculo, escreve o resultado, desbloqueia o estado e só então inicia a próxima transação. Cada etapa bloqueia a que vem depois dela. Não há sobreposição, nem concorrência, nem processamento simultâneo de trabalho independente.

O teto de taxa de transferência que isso cria é real. A Máquina Virtual Ethereum (EVM) da Ethereum processa aproximadamente 15–30 transações por segundo em sua rede Layer-1 (L1) sem rollups Layer-2 (L2), de acordo com a documentação da Ethereum Foundation. Esse número permaneceu aproximadamente constante por anos porque o gargalo é arquitetural.

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

O processamento paralelo oferece uma resposta diferente. Em vez de um único caixa para todos os clientes, imagine um supermercado com 500 caixas. Clientes comprando itens completamente diferentes (sem terminais de pagamento compartilhados, sem contas de fidelidade compartilhadas) podem pagar em todos os caixas simultaneamente. Apenas clientes que genuinamente precisam compartilhar um terminal devem esperar por ele. A taxa de transferência total da loja aumenta em ordens de magnitude, não porque qualquer caixa individual tenha ficado mais rápido, mas porque transações independentes pararam de se bloquear.

Um runtime de Smart Contract é o ambiente de software que executa o código de Smart Contract em uma blockchain. É a camada que pega o código do programa e o executa. Na Solana, os Smart Contracts são chamados de "programas" (o termo canônico na documentação da Solana, embora "Smart Contract" permaneça amplamente compreendido e seja usado de forma intercambiável aqui). Sealevel é o runtime da Solana: construído desde o início para executar milhares desses programas simultaneamente em vez de sequencialmente.

Entender como o Sealevel alcança isso com segurança, sem condições de corrida ou estado corrompido, requer entender o mecanismo arquitetural que torna o paralelismo seguro. Esse mecanismo é o modelo de conta da Solana.

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

O Sealevel alcança a execução paralela de forma segura por meio de dois recursos arquiteturais que trabalham juntos: o modelo de conta 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 seção explica ambos.

O Modelo de Conta da Solana: Separando Código de Estado

O Sealevel pode executar transações em paralelo porque o modelo de conta da Solana 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 em si. Estes são programas sem estado: carregam instruções, mas não mantêm 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 em nível arquitetural. É distinto do modelo da Ethereum, onde um Smart Contract armazena tanto seu código executável quanto seu estado em um único endereço de contrato.

Toda transação da Solana deve declarar antecipadamente de quais contas lerá e em quais escreverá, antes do início da execução. O Sealevel lê essas declarações para agendar a execução. Uma transação que omite esta etapa será rejeitada pelo runtime. Isso não é uma contabilidade opcional: é o pré-requisito estrutural que torna o paralelismo seguro possível.

Imagine dois chefs trabalhando em uma cozinha com seis bocas de fogão. O Chef A está fazendo massa e precisa das bocas um e dois. O Chef B está fazendo um salteado e precisa das bocas quatro e cinco. Eles podem trabalhar simultaneamente sem qualquer coordenação porque suas superfícies de trabalho não se sobrepõem. Nenhum deles precisa esperar pelo outro. Apenas se ambos os chefs precisarem da boca três ao mesmo tempo, um terá que esperar. O Sealevel aplica essa lógica exata às transações: aquelas que usam contas diferentes rodam em paralelo; aquelas que compartilham uma conta de escrita rodam em sequência.

Nota do desenvolvedor: O tempo de execução rejeitará transações que acessem contas não declaradas. O acesso à conta deve ser determinado no momento da construção da transação, não durante a execução. Essa 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 chega ao Sealevel, o processo de agendamento segue quatro etapas distintas.

1. Uma transação chega carregando um manifesto: a lista completa de contas que ela lerá e as contas nas quais ela escreverá.
2. O Sealevel constrói um gráfico de dependência (um mapa de quais transações compartilham contas) comparando os manifestos de todas as transações pendentes simultaneamente.
3. Transações que não compartilham contas de escrita são independentes. O Sealevel as despacha para núcleos de processador separados simultaneamente, executando-as em paralelo em todos os núcleos de CPU e GPU disponíveis.
4. 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 pelo PoH, enquanto todas as outras transações não conflitantes continuam sendo executadas em paralelo.

Essa abordagem é o paralelismo determinístico: o Sealevel identifica conflitos antes do início da execução, em vez de resolvê-los após o fato. Ele não executa transações especulativamente e reverte falhas. Isso o distingue de abordagens de concorrência otimista, como o Block-STM da Aptos, onde as transações são executadas especulativamente primeiro e reexecutadas em caso de conflito.

O Sealevel também pode rotear tarefas de verificação de assinatura para núcleos de GPU, semelhante a como uma GPU executa milhares de cálculos de shader simultaneamente em Gaming ou cargas de trabalho de IA. A Unidade de Processamento de Transações (TPU) da Solana usa pipelining para executar estágios de validação de transações simultaneamente em unidades de hardware, com o Sealevel lidando com o estágio de execução desse pipeline.

Sealevel vs. EVM da Ethereum: Uma comparação arquitetônica direta

A Solana é mais rápida que a Ethereum na camada base principalmente por causa do Sealevel, seu runtime de Smart Contract paralelo. Enquanto a EVM da Ethereum processa uma transação por vez em sequência estrita, o Sealevel processa milhares de transações independentes simultaneamente em vários núcleos de processador.

Comparação Sealevel vs. EVM

A EVM processa transações uma de cada vez porque sua arquitetura de contrato stateful torna arquitetonicamente difícil determinar com antecedência quais transações são seguras para paralelizar. Os Smart Contracts na Ethereum armazenam seu próprio estado. Quaisquer dois contratos podem teoricamente compartilhar estado e, sem saber antecipadamente quais transações são independentes, paralelizá-las corre o risco de corromper o estado. Isso não é uma falha no design da Ethereum; é uma consequência de sua arquitetura.

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 esse bytecode em velocidades quase nativas. O bytecode da EVM, por outro lado, roda em uma máquina virtual emulada por software customizado. A abordagem BPF fornece caminhos de otimização em nível de hardware que o formato customizado da EVM não oferece, contribuindo para a vantagem de throughput do Sealevel no nível de 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 stateless e contas de dados separadas vs. contratos stateful
• Abordagem de escalabilidade: execução paralela L1 vs. L2 Rollups e sharding
• Linguagem de desenvolvimento: Rust vs. Solidity

Para contextualizar como os modelos de conta diferem entre as arquiteturas de Blockchain de Camada 1, o contraste entre a abordagem de declaração antecipada da Solana e outros designs de armazenamento Na blockchain é instrutivo.

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 sua abordagem com o Block-STM da Aptos e o Monad, bem como com a Sui, revela as compensações distintas que cada design faz.

A Aptos usa Block-STM (Software Transactional Memory), uma abordagem de concorrência otimista. Ela executa transações de forma especulativa em paralelo sem exigir declaração antecipada de conta, depois valida os resultados e reexecuta quaisquer transações que produziram conflitos. A vantagem para os desenvolvedores: não há necessidade de declarar dependências de conta no momento da construção. A desvantagem: cargas de trabalho com muitos conflitos acionam a reexecução, o que custa tempo. O Sealevel evita a reexecução inteiramente porque identifica conflitos antes da execução.

O Monad visa a execução paralela da EVM com compatibilidade com Solidity da Ethereum. Ele canaliza estágios de execução e aplica paralelismo otimista sobre o modelo EVM. A aposta do Monad é que a compatibilidade com a EVM vale a sobrecarga arquitetônica. O Sealevel fez a escolha oposta: um modelo de conta limpo com maior paralelismo bruto, mas exigindo que os desenvolvedores adotem um novo paradigma de programação.

A Sui usa a propriedade baseada em objetos como sua unidade de paralelismo. Transações que tocam objetos independentes rodam em paralelo por definição, sem exigir declaração explícita. De acordo com a documentação atual, cada abordagem (o modelo determinístico do Sealevel, o modelo otimista do Block-STM, o modelo de propriedade de objeto da Sui) representa uma resposta diferente à mesma pergunta: como alcançar o paralelismo seguro em escala.

Nenhuma abordagem é universalmente superior. A declaração antecipada do Sealevel cria sobrecarga para o desenvolvedor. O modelo otimista do Block-STM incorre em custos de reexecução sob cargas pesadas de conflito. O Monad troca o espaço de desempenho bruto pela compatibilidade com Solidity. A escolha certa depende dos requisitos do caso de uso e do ecossistema de desenvolvedores em que uma equipe já está operando.

O papel do Sealevel na arquitetura de oito inovações da Solana

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

A arquitetura da Solana repousa sobre oito inovações projetadas em conjunto: PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, Archivers. Cada um lida com um estágio distinto do ciclo de vida da transação. O Sealevel é a camada de execução: o motor que roda os programas.

O 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 essa sequência de carimbo de data/hora. Quando as transações chegam ao Sealevel, a questão da ordenação já está resolvida. O Sealevel não coordena. Ele agenda.

Pense nisso como uma linha de montagem. O PoH é a esteira rolante que entrega itens de trabalho pré-classificados em sequência verificada. O Sealevel é a equipe de trabalhadores na linha que recolhe e processa itens não conflitantes simultaneamente. Os trabalhadores não precisam negociar qual item manipular em seguida porque a esteira já determinou a ordem. Sem a esteira, os trabalhadores parariam e se coordenariam constantemente, eliminando inteiramente o benefício do paralelismo.

Como o PoH pré-ordena as transações e o modelo de conta exige a declaração prévia do estado, o Sealevel identifica quais transações conflitam antes do início da execução. Os conflitos são resolvidos prospectivamente, e não após o fato, ao contrário dos modelos de concorrência otimista que executam primeiro e reexecutam em caso de colisão.

As demais inovações desempenham, cada uma, um papel de suporte. O Tower BFT (o mecanismo de consenso da Solana, uma variante otimizada por PoH do Practical Byzantine Fault Tolerance) valida os blocos que o Sealevel produz. O Gulf Stream (o protocolo de encaminhamento de transações sem mempool) envia as transações aos 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 (o banco de dados de contas) é co-projetado com o Sealevel para suportar leituras e gravações simultâneas em milhares de threads de execução paralela.

Desempenho no Mundo Real: O que o Sealevel Realmente Entrega (e Onde Ele Falha Short)

O Sealevel entrega ganhos reais de rendimento em relação a blockchains de execução sequencial, mas seu desempenho no mundo real fica bem abaixo do máximo teórico, e a rede passou por interrupções significativas. Ambos os fatos são importantes para uma avaliação honesta.

Rendimento Teórico vs. Mundo Real

Os números de rendimento da Solana exigem uma leitura cuidadosa porque o número comumente 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 geralmente incluem transações internas de votação de validadores, o que infla o número relatado. O TPS sem votação reflete o rendimento real de transações voltado para o usuário.

O valor de ~65.000 TPS é real como um teto de design arquitetônico. Ele descreve o que o Sealevel pode processar sob condições ideais com perfis de transação otimizados. O valor no mundo real é menor por vários motivos documentados: complexidade da transação, contenção de contas em programas Popular e restrições de nível de rede antes do próprio Sealevel. Mesmo assim, o rendimento da Mainnet da Solana supera substancialmente a camada base do Ethereum, que tem aproximadamente 15–30 TPS (documentação da Ethereum Foundation).

A capacidade de execução paralela do Sealevel é uma realidade arquitetônica documentada, não uma alegação de marketing. O número teórico de TPS reflete o design do tempo de execução; o número do mundo real reflete o ambiente operacional ao seu redor.

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

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

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

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

Eventos de cunhagem de Tokens Não-Fundíveis (NFT), onde milhares de usuários tentam cunhar simultaneamente, criaram alguns dos picos de carga mais intensos que a rede já enfrentou e expuseram o mesmo gargalo na camada de ingestão.

Desde então, a Solana implementou várias respostas de engenharia: o protocolo QUIC substituiu o UDP para a ingestão de transações (proporcionando melhor controle 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 Cripto, deve melhorar ainda mais o rendimento e a resiliência. Essas respostas mostram uma melhoria iterativa, mas nenhuma atualização elimina a tensão fundamental entre o envio 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 utilizem 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. Isso cria barreiras significativas à participação dos validadores e representa um trade-off de descentralização que os críticos da arquitetura da Solana identificam corretamente.

O Sealevel é um Fosso Competitivo Durável para a Solana (SOL)?

O Sealevel dá à Solana uma vantagem real de rendimento na camada base. Se essa vantagem constitui um fosso competitivo durável, requer separar os fatos arquitetônicos das variáveis do ecossistema.

O argumento para a durabilidade começa com a profundidade da integração. A arquitetura do Sealevel é estreitamente ligada aos outros componentes co-projetados da Solana. O PoH pré-ordena as transações antes que elas cheguem ao Sealevel. O Cloudbreak lida com as leituras de armazenamento simultâneas que as threads paralelas do Sealevel exigem. O Gulf Stream reduz o acúmulo de transações que o Sealevel deve processar. Replicar o desempenho do Sealevel isoladamente, sem essa pilha 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 desenvolvedores que construíram aplicações de produção em torno do paradigma do Sealevel. Arquiteturas de programas projetadas em torno da declaração prévia de contas, padrões PDA e o framework de desenvolvimento Anchor não são portados para redes EVM sem uma re-arquitetura significativa. A crescente biblioteca de ferramentas Rust, recursos do Anchor, serviços de auditoria e implementações de referência adicionam ainda 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 bases técnicas. O ecossistema L2 do Ethereum (Arbitrum, Optimism, Base) alcança alto rendimento por meio de execução fora da blockchain com quitação na blockchain, um caminho diferente para a escalabilidade que evita inteiramente as restrições do Sealevel. Para muitos casos de uso de Finanças Descentralizadas (DeFi) (incluindo formadores de mercado automatizados, ou AMMs, e corretoras descentralizadas, ou DEXs como Orca e Raydium), o rendimento do rollup L2 é suficiente sem exigir a mudança de paradigma do Sealevel.

Onde a vantagem do Sealevel é mais defensável estruturalmente é em casos de uso que exigem atualizações de estado na blockchain simultâneas e de alta frequência: livros de ordens on-chain, mecanismos de liquidação e grandes eventos de cunhagem de NFT, onde milhares de transações independentes devem ser quitadas simultaneamente. Esses casos de uso continuam arquitetonicamente difíceis em redes EVM, mesmo com soluções L2, porque a quitação em L2 ainda requer coordenação com a camada L1 para finalização.

O Sealevel representa um diferencial arquitetônico genuíno e documentado na camada base. Seu fosso competitivo é real, mas não permanente. Ele enfrenta pressão de redes paralelas emergentes e do ecossistema L2 em expansão do Ethereum. A durabilidade da posição da Solana depende tanto dos efeitos de rede (adoção de desenvolvedores, valor total bloqueado em DeFi, infraestrutura institucional) quanto da arquitetura técnica bruta do tempo de execução.

Para contexto sobre o posicionamento competitivo de Camada 1 em redes blockchain e como os trade-offs arquitetônicos se manifestam em diferentes designs de L1, os paralelos com as escolhas de design do Sealevel são instrutivos.

Esta seção serve apenas para fins informativos e educacionais e não constitui aconselhamento financeiro, de investimento ou de negociação. Os investimentos em criptomoeda envolvem riscos significativos, incluindo o risco de perda total. Consulte um consultor financeiro qualificado antes de tomar decisões de investimento.

Recursos Relacionados à Arquitetura da Solana

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

FAQ: Processamento Paralelo do Solana Sealevel

Estas perguntas frequentes abordam os pontos de confusão mais comuns sobre o modelo de execução paralela do Sealevel, os valores de rendimento e a relação com outras arquiteturas de blockchain.

O que é o Sealevel na Solana?

O Sealevel é o tempo de execução paralelo de contratos inteligentes da Solana: o motor de execução que processa milhares de transações independentes simultaneamente, em vez de uma por vez. Ao identificar quais transações não compartilham dependências de dados por meio do modelo de conta da Solana, o Sealevel as despacha para núcleos de processador separados ao mesmo tempo, permitindo um rendimento que a execução sequencial não consegue igualar.

Como o Sealevel permite o processamento paralelo de transações?

O Sealevel exige que cada transação declare antecipadamente quais contas ela lerá e gravará. Ele usa essas declarações para construir um gráfico de dependência, identificando quais transações não compartilham contas sobrepostas. Essas transações independentes são executadas simultaneamente em vários núcleos de processador. As transações que compartilham uma conta de gravação são serializadas e executadas em sequência, enquanto todas as outras transações que não conflitam continuam em paralelo.

Qual é a diferença entre o Sealevel da Solana e a Máquina Virtual Ethereum (EVM)?

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

Quantas transações por segundo a Solana pode processar com o Sealevel?

A Solana pode teoricamente processar até aproximadamente 65.000 TPS em condições ideais, de acordo com a documentação da Solana Labs. Na prática, o rendimento real da Mainnet para transações que não são de votação geralmente fica na faixa de 2.000 a 4.000 TPS, dependendo da complexidade da transação, contenção de contas e condições da rede. Isso permanece substancialmente superior ao rendimento da camada base da Ethereum, de aproximadamente 15 a 30 TPS.

Qual linguagem de programação é usada para construir no Sealevel?

Os programas da 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 implantados On-Chain. O framework Anchor é uma ferramenta de desenvolvimento baseada em Rust amplamente utilizada, abstraindo o gerenciamento de contas e reduzindo o código clichê para o desenvolvimento de programas na Solana.

Por que a Solana sofreu interrupções na rede se o Sealevel é tão rápido?

As interrupções de rede da Solana em 2021 e 2022 não foram causadas por falhas na lógica de execução paralela do Sealevel. Elas resultaram de fluxos 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 teto de TPS do Sealevel descreve quantas transações válidas ele pode processar; ele não torna a rede imune a ataques de inundação de transações no nível da ingestão.

Qual é a relação entre o Proof of History e o Sealevel?

O Proof of History (PoH) possibilita o Sealevel ao estabelecer uma ordem de transação confiável antes do início da execução. O PoH é um mecanismo de relógio criptográfico que produz uma sequência de carimbo de data/hora verificável com a qual todos os validadores concordam. Como a ordenação das transações é decidida antes do Sealevel receber as transações, o Sealevel não precisa pausar e coordenar com os validadores. Ele pode agendar imediatamente transações não conflitantes em 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 pergunta que toda blockchain enfrenta: como processar mais transações sem sacrificar a segurança ou a descentralização?

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

O lançamento do cliente validador Firedancer e o amadurecimento de redes paralelas concorrentes como a Monad tornarão o cenário competitivo mais acirrado nos próximos anos. A questão relevante não é mais se a execução paralela na camada base é alcançável. É qual abordagem arquitetônica melhor atende a cada caso de uso em escala.

Leituras Relacionadas

• Execução OTK_3 da Ethereum: Um framework de negociação em 5 etapas
• Como os modelos de conta funcionam em arquiteturas OTK_4
• Comparação de arquitetura OTK_5 da Camada 1: Near Protocol vs. FetchAI

Fontes