Skip to main content

O que é Solana

Nota: Este documento é uma tradução automática da versão original em inglês.

O que é Solana

Solana é uma blockchain Layer 1 de alta vazão projetada para velocidade e baixos custos de transação. Lançada em 2020, a Solana adota uma abordagem arquitetural fundamentalmente diferente da Ethereum: em vez de depender da EVM e da execução sequencial de transações, a Solana usa um runtime próprio, processamento paralelo de transações e um mecanismo de temporização inovador chamado Proof of History (PoH) para alcançar uma vazão capaz de lidar com milhares de transações por segundo.

A Solana tornou-se uma das redes mais ativas para projetos de cripto IA, particularmente aqueles que precisam de interações onchain rápidas, taxas baixas e responsividade em tempo real. Sua arquitetura troca parte da profundidade do ecossistema e das ferramentas testadas em batalha da Ethereum por desempenho bruto — um trade-off que molda quais tipos de projetos escolhem construir sobre ela.

Em resumo: a Solana é uma blockchain L1 de alta velocidade — e quando um cartão de projeto do DecAIHub mostra Main chain: Solana, significa que o projeto roda em uma rede otimizada para vazão e transações de baixo custo.

Como a Solana funciona

A arquitetura da Solana difere da Ethereum de várias maneiras fundamentais. Entender essas diferenças ajuda a avaliar por que certos projetos de IA escolhem a Solana e o que essa escolha implica.

Proof of History combinado com Proof of Stake

O modelo de consenso da Solana combina dois mecanismos: Proof of History (PoH) e Proof of Stake (PoS).

O Proof of History não é um mecanismo de consenso por si só. É um relógio criptográfico — uma forma de criar um registro verificável e ordenado do tempo antes que os validadores precisem concordar sobre os blocos. O PoH funciona executando uma cadeia contínua de hashes SHA-256 em que cada hash depende da saída anterior. Isso produz uma sequência que prova a passagem do tempo entre eventos sem exigir que os validadores se comuniquem de ida e volta para estabelecer a ordenação.

Pense nisso como um timestamp que não pode ser falsificado: cada entrada na sequência do PoH está criptograficamente ligada à anterior, e produzir a sequência exige tempo computacional real. Os validadores podem verificar a ordenação de forma independente reproduzindo a cadeia de hashes.

O Proof of Stake cuida do consenso propriamente dito — os validadores fazem stake de SOL (o token nativo da Solana) para participar da produção e validação de blocos. O componente PoS funciona de forma semelhante a outras redes PoS: os validadores são selecionados para produzir blocos com base em seu peso de stake e ganham recompensas pela participação honesta. O mau comportamento pode levar ao slashing (perda do SOL em stake).

A combinação é o que dá à Solana sua vantagem de velocidade. Os sistemas PoS tradicionais gastam tempo significativo sincronizando relógios e estabelecendo a ordenação de transações entre os validadores. O PoH pré-ordena as transações antes de o consenso começar, reduzindo drasticamente a sobrecarga de comunicação e permitindo tempos de bloco de aproximadamente 400 milissegundos.

Execução paralela com Sealevel

A maioria das blockchains executa as transações de smart contract de forma sequencial — uma após a outra. O motor de runtime Sealevel da Solana permite a execução paralela: transações que não tocam nas mesmas contas ou estado podem ser processadas simultaneamente em múltiplos núcleos.

Isso é possível porque a Solana exige que as transações declarem antecipadamente de quais contas elas lerão e nas quais escreverão. O runtime usa essa informação para identificar transações independentes e agendá-las para processamento paralelo. As transações que de fato entram em conflito (tocando na mesma conta) são serializadas, mas a vazão geral permanece muito maior do que a dos sistemas apenas sequenciais.

Para cargas de trabalho de IA que envolvem muitas operações independentes — atribuições de tarefas a diferentes nós de computação, requisições de inferência independentes, submissões de dados paralelas — a execução paralela significa que a rede consegue lidar com altos volumes sem os gargalos de congestionamento comuns nas chains sequenciais.

Programas e contas

Na arquitetura da Solana, os smart contracts são chamados de programs. Diferentemente da Ethereum, onde os contratos contêm tanto código quanto estado, a Solana os separa:

  • Os programs contêm a lógica executável (código) e são stateless. O próprio program não armazena dados de usuário.
  • As accounts contêm o estado (dados). Cada account é de propriedade de um program e armazena os dados que o program lê e modifica.

Essa separação permite a execução paralela descrita acima, porque o runtime consegue determinar com precisão as dependências em nível de conta. Também significa que os programs da Solana são projetados de forma diferente dos smart contracts da Ethereum — os desenvolvedores escrevem em Rust (a linguagem principal), C ou C++ em vez de Solidity, e o modelo de programação exige gerenciamento explícito de contas.

Tokens SPL

Na Ethereum, os tokens fungíveis seguem o padrão ERC-20. Na Solana, o equivalente é o padrão de token SPL (Solana Program Library). Os tokens SPL são criados e gerenciados por meio de um program padronizado da Solana. Qualquer projeto que lance um token na Solana o emite como um token SPL.

Os tokens SPL herdam as características de desempenho da Solana: as transferências de token são rápidas (confirmação em menos de um segundo) e baratas (frações de centavo). Para projetos de IA que precisam de micropagamentos frequentes — pagar provedores de computação por chamada de inferência, recompensar contribuidores de dados por submissão, distribuir taxas por uma rede — o custo de uma transferência individual de token SPL é tipicamente uma fração de centavo.

Custos de transação e vazão

As taxas de transação da Solana estão entre as mais baixas de qualquer grande blockchain: tipicamente menos de US$ 0,01 por transação, e frequentemente frações de centavo. Isso é ordens de magnitude mais barato do que a mainnet da Ethereum, onde transações complexas podem custar dezenas de dólares durante picos de demanda. Dito isso, durante períodos de alta demanda, as priority fees podem elevar temporariamente o custo de uma transação na Solana.

A capacidade de vazão teórica da rede está na faixa de milhares de transações por segundo (TPS), com vazão real sustentada significativamente maior do que a da mainnet da Ethereum. A Solana alcança isso por meio da combinação de PoH, execução paralela, um tempo de bloco curto (~400ms) e requisitos de validador otimizados por hardware.

O trade-off é que os validadores da Solana precisam de hardware substancialmente mais potente do que os validadores da Ethereum. A filosofia de design da Solana prioriza o desempenho ao custo de maiores barreiras de hardware à entrada — uma escolha de design que afeta o perfil de descentralização da rede.

Características-chave

Propriedade Valor
Type Layer 1
Consensus Proof of Stake + Proof of History
Native token SOL
Token standard SPL
Compatível com EVM Não (baseada em SVM)
Block time ~400 milissegundos
Smart contracts Rust, C (via programs BPF/SBF)

Por que isso importa para projetos de cripto IA

A arquitetura da Solana cria vantagens específicas para projetos cripto orientados a IA.

Responsividade em tempo real. Aplicações de IA que atendem usuários em tempo real — agentes fazendo trades de DeFi, APIs de inferência respondendo a consultas, sistemas de recomendação processando dados ao vivo — se beneficiam dos tempos de bloco abaixo de um segundo e da alta vazão da Solana. A latência entre enviar uma transação e tê-la confirmada é medida em centenas de milissegundos, não em minutos.

Economia de micropagamentos. Muitos projetos de IA operam com modelos de micropagamento: os usuários pagam pequenas quantias por chamada de inferência, os provedores de computação ganham por tarefa concluída, os contribuidores de dados recebem recompensas por ponto de dado rotulado. Na mainnet da Ethereum, o custo de gas de uma transação de pagamento pode exceder o próprio pagamento. Na Solana, o custo de transação é tipicamente uma fração de centavo, tornando os pagamentos por unidade economicamente viáveis.

Operações onchain de alta frequência. Marketplaces de computação de IA, protocolos de coordenação de dados e frameworks de agentes frequentemente exigem atualizações de estado onchain frequentes — registrar tarefas, gravar conclusões, atualizar pontuações, distribuir recompensas. A vazão da Solana lida com essas operações de alta frequência sem o congestionamento e a escalada de custos que ocorrem em chains de menor vazão.

Ecossistema de IA em crescimento. A Solana atraiu um número significativo e crescente de projetos de IA. A combinação de desempenho, baixos custos e uma comunidade de desenvolvedores ativa fez dela uma alternativa principal à Ethereum para o desenvolvimento cripto focado em IA. Várias redes de computação de IA proeminentes, plataformas de inferência e frameworks de agentes de IA escolheram a Solana como sua chain principal.

Trade-offs diretos. Escolher a Solana em vez da Ethereum ou de suas L2s envolve trade-offs que são relevantes para avaliar um projeto:

  • O ecossistema da Solana, embora em crescimento, é menor que o da Ethereum em termos de liquidez de DeFi, protocolos auditados e ferramentas para desenvolvedores.
  • A Solana é non-EVM: os contratos são escritos em Rust, não em Solidity, e não são diretamente portáveis para chains EVM.
  • Os requisitos de hardware dos validadores da Solana são mais altos, o que afeta o número e a distribuição geográfica dos validadores.
  • A Solana sofreu interrupções de rede em sua história, levantando questões sobre a estabilidade da rede sob condições extremas.

Nenhum desses trade-offs é automaticamente positivo ou negativo. São escolhas de design com consequências que dependem dos requisitos específicos de cada projeto.

Onde isso aparece nos cartões de projeto do DecAIHub

Ao ler um cartão de projeto do DecAIHub, a Solana aparece em vários campos:

  • Main chain — Solana indica que os programs principais (smart contracts) do projeto estão implantados na rede Solana. Isso indica que o projeto opera no ambiente de desempenho e custo da Solana.
  • Type — projetos na Solana normalmente têm Type: non-EVM (o ambiente de execução da Solana não é baseado em EVM). Papéis como dApp, protocolo ou infra são refletidos no campo Category, não em Type.
  • Token standard — projetos na Solana usam o token standard SPL. Assim como o ERC-20 na Ethereum, o SPL descreve o formato técnico do token, não sua utilidade.
  • Consensus — para a própria rede Solana, o modelo de consenso envolve PoH + PoS. Projetos que constroem na Solana herdam esse mecanismo de consenso.

O campo Main chain: Solana indica o ambiente de execução do projeto e as características de desempenho que ele herda. Não indica se o AI component do projeto é real, se o token cumpre uma função necessária ou se a integração onchain é significativa. Esses aspectos são avaliados pelos campos AI reality, Token necessity e Onchain necessity no resumo do componente DecAI Fit do cartão de projeto.

Ler Main chain: Solana ao lado dos campos AI reality e Onchain necessity é particularmente informativo: um projeto que escolheu a Solana pela velocidade, mas roda toda a lógica de IA offchain em servidores centralizados, pode não estar aproveitando as vantagens da Solana de forma significativa.

O que a Solana, por si só, não prova

Construir na Solana é uma escolha de infraestrutura, não evidência da qualidade do projeto. Implantar na Solana não demonstra:

  • AI reality — um projeto pode implantar programs na Solana sem nenhum AI component real. A Solana fornece a camada de execução, não a inteligência. Se a IA é real depende de evidência Tier-1 — código, modelos, benchmarks, endpoints de inferência implantados e documentação.

  • Profundidade de descentralização — embora a Solana seja uma rede descentralizada, um projeto construído sobre ela pode centralizar toda a tomada de decisão significativa offchain. Usar a Solana para transferências de token enquanto roda todo o resto em um servidor privado não constitui uma aplicação descentralizada.

  • Necessidades de escalabilidade — escolher uma chain de alta vazão não significa que o projeto realmente gere altos volumes de transações. Alguns projetos escolhem a Solana por posicionamento narrativo, e não porque sua carga de trabalho exige. A atividade onchain real do projeto (verificável por meio dos exploradores da Solana) conta a verdadeira história.

  • Token necessity — emitir um token SPL na Solana é tecnicamente simples e barato. A existência de um token baseado na Solana não significa que o token tenha um papel funcional na arquitetura do projeto.

  • Confiabilidade da rede — as interrupções de rede passadas da Solana significam que construir na Solana aceita implicitamente o risco de indisponibilidade temporária. Para aplicações de IA que exigem disponibilidade contínua, esta é uma consideração relevante, embora a estabilidade da rede tenha melhorado ao longo do tempo.

Não confundir com

  • SOL — SOL é a criptomoeda nativa da Solana, usada para pagar taxas de transação, fazer stake para validação e participar da governança. "Solana" refere-se à rede e ao protocolo; "SOL" refere-se ao token.

  • Ethereum — a Ethereum é uma blockchain L1 separada, com uma arquitetura diferente (EVM, execução sequencial, PoS sem PoH). Projetos na Solana e projetos na Ethereum operam em ambientes técnicos fundamentalmente diferentes. Eles não são intercambiáveis, embora alguns projetos sejam implantados em ambos.

  • SPL — o padrão de token SPL é o equivalente da Solana ao ERC-20 da Ethereum. O SPL descreve o formato do token, não a rede. Um projeto que usa tokens SPL está na Solana, mas SPL e Solana são conceitos diferentes (padrão versus rede).

  • Layer 2 — a Solana é uma blockchain L1, não uma Layer 2. Ela não liquida transações em outra chain. Tem seu próprio conjunto de validadores, consenso e modelo de segurança. As L2s da Ethereum, como Base ou Arbitrum One, herdam a segurança da Ethereum; a Solana fornece sua própria segurança.

  • Rust — Rust é a linguagem de programação usada principalmente para escrever programs da Solana. Rust é uma linguagem de propósito geral usada em muitos contextos fora da blockchain. Conhecer Rust e conhecer o desenvolvimento na Solana são habilidades relacionadas, mas distintas.

Perguntas frequentes

Por que alguns projetos de IA escolhem a Solana em vez da Ethereum?

Velocidade e custo. Cargas de trabalho de IA que envolvem operações onchain frequentes — requisições de inferência, atribuições de tarefas de computação, micropagamentos a contribuidores — precisam de uma chain onde cada transação seja rápida e barata. Os tempos de bloco abaixo de um segundo e as taxas muito baixas da Solana tornam a economia por operação viável. Os custos mais altos da mainnet da Ethereum empurram projetos semelhantes para as L2s da Ethereum, mas a Solana oferece essas características nativamente em sua L1, sem exigir uma camada de escalabilidade separada.

A Solana é centralizada?

A Solana é mais centralizada que a Ethereum por várias métricas comuns: tem menos validadores, maiores requisitos de hardware para operar um validador e uma distribuição geográfica menor de nós. No entanto, ainda é uma rede permissionless onde qualquer um que atenda aos requisitos de hardware pode operar um validador. O grau de descentralização é um espectro, não algo binário. Para um leitor de cartão de projeto do DecAIHub, a pergunta relevante não é se a Solana é "centralizada" ou "descentralizada" no abstrato, mas se o uso específico da Solana pelo projeto contribui para, ou prejudica, a verificabilidade e a minimização da confiança.

Qual linguagem de programação é usada na Solana?

Os programs da Solana são escritos principalmente em Rust, com suporte para C e C++. Frameworks de mais alto nível como o Anchor simplificam o desenvolvimento na Solana ao fornecer abstrações semelhantes às disponíveis no ecossistema Solidity da Ethereum. Isso é diferente do ecossistema da Ethereum, onde o Solidity é a linguagem dominante. A diferença de linguagem significa que o desenvolvimento na Solana e o desenvolvimento na Ethereum exigem conjuntos de habilidades e ferramentas diferentes.

A Solana já sofreu indisponibilidade?

Sim. A Solana sofreu várias interrupções de rede e episódios de desempenho degradado, particularmente durante períodos de alta demanda. Esses eventos envolveram a rede interrompendo a produção de blocos por horas, exigindo reinicializações coordenadas dos validadores. Os incidentes motivaram melhorias no protocolo e esforços de diversidade de clientes. Ao avaliar um projeto na Solana, esse histórico é um contexto relevante: o projeto herda tanto as vantagens de desempenho da Solana quanto seu histórico de confiabilidade.

Um projeto pode estar tanto na Solana quanto na Ethereum?

Sim. Alguns projetos são implantados em múltiplas chains para alcançar bases de usuários e pools de liquidez diferentes. Um projeto pode rodar suas operações de IA de alta frequência na Solana enquanto mantém contratos de governança ou bridges de token na Ethereum. Nos cartões de projeto do DecAIHub, o campo Main chain indica a chain principal, mas chains adicionais podem ser mencionadas na descrição do projeto ou em campos multi-chain.

"Main chain: Solana" significa que o projeto é rápido?

Significa que o projeto tem acesso à velocidade e à vazão da Solana. Se o projeto de fato utiliza essa capacidade depende de sua arquitetura e da atividade onchain real. Um projeto na Solana que processa poucas transações ganha pouco com as características de desempenho da rede. Os dados de atividade onchain dos exploradores da Solana fornecem evidência concreta de se o projeto usa as capacidades da chain de forma significativa.

Referências externas

Ver também

No comments to display

Back to top