NEAR Validação Stateless: Fase 2 Sharding

A validação sem estado do NEAR é a atualização da Fase 2 do framework de sharding Nightshade do NEAR Protocol, na qual os validadores de fragmentos já não mantêm uma cópia local persistente do estado do fragmento. Em vez disso, o produtor de fragmentos empacota todos os dados de estado necessários num testemunho de estado, uma estrutura de dados criptográfica contendo cada saldo de conta, entrada de armazenamento de contrato e chave de acesso necessários para executar um fragmento específico, e entrega-o juntamente com o fragmento aos validadores. Este design desacopla os requisitos de hardware dos validadores do tamanho do estado da rede, permitindo que o NEAR escale horizontalmente adicionando mais fragmentos sem forçar aumentos proporcionais nos custos de armazenamento sobre o seu conjunto de validadores.

Este artigo abrange o que é o NEAR Protocol, como funciona o sharding Nightshade, a mecânica precisa da validação sem estado (stateless validation), incluindo o ciclo de vida da prova de estado (state witness) e a hierarquia de funções dos validadores, os benefícios para a descentralização e escalabilidade, uma comparação direta com o roteiro de statelessness da Ethereum e as implicações para validadores, stakers, programadores e qualquer pessoa que avalie a NEAR para a implementação de dApps.

O que é o Protocolo NEAR?

O NEAR Protocol é um blockchain de camada 1, prova de participação, que utiliza o sharding Nightshade (o framework de sharding proprietário da NEAR) para dividir o processamento de transações entre múltiplos shards paralelos, permitindo uma elevada taxa de transferência com taxas de transação quase zero. A NEAR foi concebida para implementar aplicações descentralizadas em escala, com ferramentas para programadores e uma arquitetura de consenso construída em torno da suposição de que o número de shards irá crescer ao longo do tempo.

Arquitetura Central da NEAR

A NEAR opera como uma rede proof-of-stake em que os validadores investem em staking tokens NEAR para participar no consenso e são atribuídos aleatoriamente a shards a cada época, um período de tempo fixo aproximadamente equivalente a meio dia. O NEAR Protocol foi cofundado por Illia Polosukhin, coautor do influente artigo de aprendizagem automática "Attention Is All You Need", e Alexander Skidanov; a NEAR Foundation supervisiona o desenvolvimento contínuo do protocolo e as subvenções para o ecossistema.

O Token NEAR tem duas funções principais: pagar taxas de gás para transações e execução de contratos, e staking como garantia para validadores para ganhar o direito de participar no consenso. Os contratos inteligentes NEAR compilam para WebAssembly (WASM), um formato binário portátil que permite que contratos escritos em Rust ou JavaScript executem num ambiente de execução determinístico. O processamento de transações na NEAR segue um modelo baseado em 'chunks', onde cada fragmento ('shard') produz um 'chunk' (um bloco a nível de fragmento processado em paralelo) em cada intervalo de bloco, e todos os 'chunks' são agregados num único bloco canónico.

O que torna a NEAR diferente de outras L1 Blockchains?

NEAR distingue-se de outras blockchains de camada 1 principalmente através do seu modelo de sharding de execução, que divide tanto o estado como o processamento de transações entre shards, em vez de tratar toda a execução numa única cadeia. Os principais diferenciadores incluem:

• Fragmentação de execução Nightshade: A NEAR fragmenta tanto o estado quanto a computação, e não apenas a disponibilidade de dados. Isto difere da abordagem Danksharding da Ethereum (EIP-4844), que visa a fragmentação da disponibilidade de dados para Rollups de Camada 2 em vez da fragmentação de execução.
• Validação sem estado (Fase 2): Os validadores de blocos (chunks) operam sem armazenamento de estado local, uma escolha de design com implicações diretas na descentralização e na escalabilidade de fragmentos, abordada em profundidade neste artigo.
• Runtime de Smart Contract WASM: Os contratos são executados numa sandbox WASM, suportando Rust e JavaScript como as principais linguagens de desenvolvimento.
• Nomes de conta legíveis por humanos: As contas NEAR utilizam identificadores nomeados em vez de hashes de Chave pública simples.
• Modelo de Staking de armazenamento: Os contratos pagam pelo armazenamento On-Chain através do Staking de tokens NEAR, associando os custos de armazenamento ao colateral em Staking em vez de taxas por byte.
• Taxas de transação próximas de zero: A estrutura de taxas da NEAR foi concebida para permanecer acessível mesmo sob uma carga de rede moderada.

A Solana escala através do paralelismo numa única cadeia, utilizando o seu tempo de execução Sealevel; a NEAR escala através de sharding em fragmentos paralelos independentes. Estas são diferentes respostas arquitetónicas para o mesmo problema de débito. A comparação com a Ethereum recebe um tratamento dedicado mais adiante neste artigo.

O Que É Validação sem estado?

A validação sem estado é um modelo de validação de Blockchain em que os validadores processam transações sem manter uma cópia local persistente do estado da rede, recebendo todos os dados de estado necessários como parte de cada bloco ou fragmento que validam. A palavra "sem estado" refere-se à relação do validador com o armazenamento de estado, e não ao estado da Blockchain em si, que continua a existir e a crescer. Do ponto de vista do validador, cada tarefa de validação chega pré-embalada com tudo o que é necessário para a completar.

Validação com Estado vs. Sem Estado: A Diferença Chave

A diferença entre validação stateful e stateless reside em onde os dados de estado residem durante a execução: com o validador ou com a tarefa.

Na validação com estado (stateful), o validador é o guardião do estado: este possui uma cópia dos dados da respetiva shard e consulta-os durante cada transação. Na validação sem estado (stateless), os dados de estado acompanham o trabalho. O validador recebe exatamente o que precisa, utiliza-o e descarta-o.

Por que razão a NEAR precisou da validação sem estado (Stateless Validation)

Sob a arquitetura original com estado da NEAR, cada validador de blocos (chunk validator) atribuído a uma shard tinha de manter uma cópia local completa do estado dessa shard e, à medida que o número de shards da NEAR crescia, cresciam também os requisitos de hardware de armazenamento para cada validador na rede. Cada nova shard adicionava obrigações de armazenamento proporcionais para os validadores a ela atribuídos. Isto criou uma ligação direta entre as ambições de escalabilidade da NEAR e a barreira de custos de hardware para a participação de validadores. À medida que a rede adicionava shards para aumentar o rendimento (throughput), elevava simultaneamente o custo para se tornar um validador, concentrando a participação entre operadores com grandes infraestruturas de armazenamento.

A validação sem estado quebra este acoplamento. Um validador de chunks já não armazena qualquer estado de shard. Recebe exatamente os dados de estado necessários para cada chunk que valida, executa transações com base nesses dados e elimina-os. Adicionar mais shards aumenta o débito da rede sem aumentar os requisitos de armazenamento por validador. Isto aborda uma das tensões centrais no trilema da escalabilidade da Blockchain: a NEAR pode adicionar shards para escalar o débito sem forçar a centralização de hardware, enquanto a integridade criptográfica do testemunho de estado preserva a segurança.

Compreender o Sharding: O Alicerce da Escalabilidade da NEAR

A validação sem estado da NEAR opera no âmbito da arquitetura de sharding Nightshade, que divide o estado global da rede e o processamento de transações entre múltiplos shards paralelos. A compreensão desta arquitetura é um pré-requisito para a explicação do mecanismo que se segue, uma vez que a validação sem estado é uma atualização específica à forma como os validadores participam na estrutura Nightshade.

Como Funciona o Sharding Nightshade na NEAR

Nightshade é o framework de sharding do NEAR Protocol, no qual o estado global da Blockchain é dividido por múltiplos shards, cada um produzindo um 'chunk' (um bloco ao nível do shard) em cada intervalo de blocos. Múltiplos 'chunks' são produzidos em paralelo em todos os shards ativos e agregados num único bloco canónico pelo produtor de blocos para esse intervalo.

O princípio de design fundamental por trás do Nightshade é que todos os shards são tratados como componentes de uma blockchain lógica, e não como cadeias separadas. Cada bloco NEAR contém um chunk por cada shard ativo. Isto significa que o livro-razão global permanece unificado, mesmo quando o processamento de transações é distribuído. As transações entre shards são geridas através de um mecanismo de recibos assíncrono que transmite mensagens entre shards.

Os validadores são atribuídos aleatoriamente a fragmentos em cada época, o que limita o risco de o conjunto de validadores de qualquer fragmento individual ser atacado ou capturado seletivamente. Um validador não detém permanentemente uma atribuição de fragmento; esta roda com cada época, distribuindo tanto a responsabilidade como o risco por toda a rede.

A implementação completa do Nightshade decorre em três fases. A Fase 1 estabeleceu o sharding básico com processamento de blocos, onde os validadores mantinham cópias completas do estado local. A Fase 2 é a validação sem estado, o tema deste artigo. A Fase 3 é o redimensionamento dinâmico de shards, que dá ao NEAR a capacidade de ajustar automaticamente a sua contagem de shards com base na procura em tempo real da rede. Para obter documentação técnica completa sobre o modelo de sharding do NEAR, consulte docs.near.org/concepts/advanced/sharding.

Como funciona a Validação Sem Estado da NEAR

A validação sem estado da NEAR funciona porque os dados de estado necessários para validar um chunk viajam com o próprio chunk, empacotados pelo produtor de chunks como uma testemunha de estado. Os validadores de chunks recebem o chunk e a sua testemunha de estado em conjunto, executam todas as transações utilizando apenas os dados da testemunha e nunca consultam uma base de dados de estado local. O resultado é que a classe mais numerosa de validadores na rede da NEAR pode operar com requisitos de armazenamento de estado quase nulos.

O Que É uma Testemunha de Estado?

Uma testemunha de estado é uma estrutura de dados criptográfica gerada pelo produtor de "chunks" que contém toda a informação de estado necessária para executar as transações num "chunk" específico, incluindo saldos de conta afetados, entradas de armazenamento de contratos, chaves de acesso e código de contrato.

Pense numa testemunha de estado como um processo judicial preparado por um funcionário judicial antes de uma audiência: contém todos os documentos de que o juiz necessita para chegar a um veredicto, reunidos antecipadamente para que o juiz não precise de procurar nos arquivos do tribunal a meio do processo. Na arquitetura da NEAR, a testemunha de estado é esse processo judicial. O validador de chunk recebe-o juntamente com o chunk e executa todas as transações utilizando apenas o seu conteúdo, sem nunca consultar uma base de dados de estado local.

O ciclo de vida da testemunha do estado abrange cinco fases distintas:

1. Conteúdo: A testemunha de estado inclui os saldos das contas, as entradas de armazenamento de contrato, as chaves de acesso e o código do contrato para cada conta afetada pelas transações no fragmento. Apenas o estado que é efetivamente lido ou escrito durante a execução é incluído; o estado completo do fragmento não é empacotado.

2. Geração: O produtor de blocos (chunk producer), a função de validador responsável pela construção do bloco, lê as entradas de estado relevantes da sua cópia local do estado do shard e agrupa-as no testemunho de estado (state witness). O produtor de blocos retém o seu estado local porque deve ser capaz de gerar testemunhos para blocos futuros.

3. Transmissão: O produtor de chunk transmite o chunk e a sua testemunha de estado conjuntamente aos validadores de chunks designados aleatoriamente para essa shard para o intervalo de blocos atual.

4. Execução: Cada validador de blocos (chunks) executa as transações do bloco utilizando exclusivamente os dados da testemunha de estado (state witness). Não ocorre qualquer consulta ao estado local em momento algum. Após a execução, o validador do bloco produz uma atestação que confirma a validade do bloco.

5. Eliminar: Após a conclusão da validação, o validador de blocos (chunk validator) elimina a prova de estado (state witness). A prova não é retida, não é armazenada e não é utilizada para atualizar qualquer base de dados de estado local.

A estrutura de testemunha de estado é especificada formalmente como uma Proposta de Melhoria NEAR (NEP). Para a especificação precisa e o número atual da NEP, consulte o repositório NEAR NEPs no GitHub. Para detalhes de implementação no cliente do protocolo principal, consulte o repositório nearcore no GitHub.

O Papel dos Validadores de Chunk vs. Produtores de Blocos

A arquitetura de validação da NEAR, sob validação sem estado, envolve três papéis distintos: produtores de 'chunks', validadores de 'chunks' e produtores de blocos, cada um com responsabilidades e requisitos de armazenamento de estado diferentes.

A perspetiva estrutural fundamental é que os validadores de 'chunks' constituem a classe mais numerosa na rede e, sob validação sem estado, já não necessitam de hardware de armazenamento dispendioso. Apenas os produtores de 'chunks', um conjunto muito menor, mantêm o requisito de armazenamento de estado porque precisam de ler o estado local para gerar a prova ('witness') de cada 'chunk'. Esta assimetria é o que permite que o conjunto de validadores cresça sem aumentar proporcionalmente os custos totais de armazenamento em toda a rede. Os ganhos de descentralização concentram-se precisamente na maior classe de validadores.

O Fluxo de Validação Sob Validação sem Estado

Os passos seguintes descrevem o que acontece desde o momento em que um novo intervalo de bloco se inicia até ao momento em que um bloco validado é finalizado na NEAR.

1. Produção de blocos: O produtor de blocos atribuído a cada shard ativo constrói um bloco (um bloco a nível de shard) contendo as transações pendentes a serem processadas neste intervalo de blocos.

2. Geração de testemunhas de estado: O produtor de fragmentos lê as entradas de estado relevantes da sua cópia local do estado do fragmento e empacota-as numa testemunha de estado, que contém todos os saldos de conta, entradas de armazenamento de contrato e chaves de acesso tocadas pelas transações no fragmento.

3. Transmissão para validadores de blocos (chunks): O produtor do bloco transmite o bloco e o respetivo testemunho de estado aos validadores de blocos atribuídos aleatoriamente a esse shard para este intervalo de bloco.

4. Execução sem estado (stateless): Cada validador de blocos (chunks) executa as transações do bloco utilizando apenas os dados da testemunha de estado (state witness), sem qualquer consulta ao estado local em momento algum. Após a execução, o validador de blocos atesta a validade do bloco e descarta a testemunha de estado.

5. Montagem do bloco: O produtor de blocos deste intervalo recolhe os pedaços (chunks) atestadores de todos os shards ativos, agrega-os num único bloco canónico e transmite-o à rede para finalização.

Em nenhum momento nas etapas 3 e 4 um validador de fragmento necessita de armazenamento de estado local. A testemunha de estado fornece todo o acesso ao estado necessário durante a operação de validação.

Benefícios da Validação Sem Estado da NEAR

A validação 'Stateless' (sem estado) proporciona três categorias de melhorias à rede da NEAR: reduz os requisitos de hardware para a classe mais numerosa de validadores, remove o limite de escalabilidade que a validação 'stateful' impunha ao número de 'shards' e ao rendimento, e melhora as condições de infraestrutura para os desenvolvedores que criam aplicações Descentralizadas sobre a rede.

Requisitos de Hardware Mais Baixos e Maior Descentralização

A consequência mais direta da validação sem estado para o conjunto de validadores da NEAR é a remoção do armazenamento de estado do shard como requisito de hardware para os validadores de chunk. Sob validação com estado, as exigências de armazenamento para os validadores de chunk cresceram com o tamanho do estado do shard ao longo do tempo, escalando de centenas de gigabytes para terabytes à medida que a rede processava mais transações e acumulava mais estado. Isto criou uma barreira progressiva de custo de hardware.

A validação sem estado elimina completamente este fardo para os validadores de partes. Os requisitos de armazenamento para esta função reduzem-se a quase zero para infraestruturas relacionadas com o estado, restando apenas os requisitos de processamento e largura de banda de rede para a execução de transações e transmissão de atestações dentro dos limites de tempo de bloco.

O efeito de descentralização decorre diretamente desta alteração de hardware. Custos de armazenamento mais baixos reduzem o custo operacional total de execução de um validador de chunks, baixando a barreira económica efetiva à participação. Isto permite um conjunto de validadores maior e mais geograficamente diversificado, o que, por sua vez, reduz o risco de concentração de validadores. Uma rede cujos validadores mais numerosos podem ser executados em hardware comum é estruturalmente mais resistente à centralização do que uma onde a elegibilidade do validador exige despesas de capital significativas em infraestrutura de armazenamento. As especificações atuais dos requisitos de hardware para validadores de chunks sob validação sem estado são mantidas em docs.near.org/validator; consulte essa documentação para obter os valores atuais.

Escalabilidade Sem Sacrificar a Segurança

A validação sem estado desacopla a contagem de shards da NEAR dos requisitos de hardware dos validadores, o que remove o teto de escalabilidade que a validação com estado impunha à taxa de transferência da rede. No modelo anterior com estado, duplicar o número de shards teria exigido que cada validador atribuído a esses novos shards providenciasse armazenamento adicional proporcional, tornando contagens de shards elevadas economicamente restritivas. A validação sem estado quebra esta relação: adicionar shards aumenta a capacidade da rede sem aumentar as obrigações de armazenamento por validador.

O rendimento da rede na NEAR escala de forma aproximadamente proporcional ao número de shards. Mais shards ativos significam mais chunks processados em paralelo por intervalo de bloco, o que aumenta o número de transações que a rede consegue confirmar por segundo. A validação sem estado (stateless validation) é o pré-requisito para que a NEAR atinja contagens de shards mais elevadas em escala. A documentação da NEAR Foundation fornece valores de rendimento atuais à medida que são atualizados; para dados de TPS atuais associados a configurações de shards específicas, consulte docs.near.org.

Isto aborda diretamente o pilar da escalabilidade do trilema de escalabilidade da blockchain. A tensão histórica entre escalabilidade e descentralização em redes fragmentadas surge porque adicionar capacidade tipicamente aumenta os custos de hardware dos validadores, reduzindo a descentralização. A validação sem estado remove o mecanismo que causou este compromisso, permitindo que a NEAR prossiga com aumentos no número de fragmentos sem a correspondente pressão de centralização. O modelo de escalabilidade atinge a sua expressão máxima na Fase 3, o re-sharding dinâmico, onde a NEAR ganha a capacidade de ajustar automaticamente o número de fragmentos com base na procura da rede em tempo real, sem qualquer coordenação manual.

O que isto significa para os programadores que desenvolvem na NEAR

Se está a avaliar a NEAR como uma Plataforma de implementação, a validação sem estado (stateless validation) afeta as suas aplicações na camada de infraestrutura, não na camada de contrato. Existem quatro implicações práticas que vale a pena compreender antes de se comprometer com uma decisão arquitetural:

Não são necessárias alterações aos contratos. A validação stateless é uma alteração ao nível do protocolo. Os seus smart contracts não requerem qualquer modificação para beneficiarem da mesma. Os contratos já implementados na NEAR operam automaticamente na rede atualizada e mais escalável. Não existe qualquer etapa de migração, requisito de nova implementação nem alterações na API.

Maior rendimento à medida que o número de shards cresce. À medida que a NEAR adiciona mais shards possibilitados pela validação sem estado, a capacidade total de transações da rede aumenta. Para a sua dApp, isto significa uma menor probabilidade de congestionamento durante períodos de elevada procura e custos de transação mais estáveis e previsíveis à medida que a rede escala.

Infraestrutura mais resiliente. Um conjunto de validadores mais descentralizado, resultante de barreiras de hardware mais baixas para a participação de validadores de chunks, reduz o risco de interrupções de rede relacionadas com a centralização. As dApps em produção beneficiam de uma rede de validadores que é mais difícil de interromper através da concentração de operadores ou de falhas de hardware agrupadas num pequeno número de validadores com elevados recursos.

Caminho do programador Ethereum. A NEAR suporta a Aurora, um ambiente de execução compatível com EVM que permite aos programadores de Ethereum implementar contratos Solidity na NEAR sem os reescrever em Rust ou JavaScript. Esses contratos são executados na mesma rede subjacente e beneficiam das mesmas melhorias na infraestrutura de validação sem estado.

Validação Sem Estado da NEAR vs. o Roadmap Sem Estado da Ethereum

Desenvolvedores familiarizados com o roteiro de clientes stateless da Ethereum verão que a validação stateless da NEAR aborda o mesmo problema subjacente: desacoplar o hardware de validadores e nós do tamanho do estado da rede. As duas abordagens operam em diferentes níveis arquitetónicos e através de diferentes mecanismos, moldadas pelas estruturas fundamentalmente diferentes das duas redes. Não são designs concorrentes, mas sim respostas paralelas ao fardo de hardware do crescimento do estado da Blockchain.

Ambas as abordagens empacotam os dados de estado de que um validador ou cliente necessita juntamente com o bloco ou fragmento a ser validado, pelo que a parte executora nunca necessita de uma base de dados de estado local. A diferença estrutural é que a validação sem estado da NEAR aplica-se dentro de um sistema segmentado, visando os validadores a nível de fragmento que formam a maioria da sua rede. O roteiro sem estado da Ethereum visa os nós completos numa camada de execução monolítica, onde o estado da cadeia inteira deve, eventualmente, ser endereçável através de testemunhas de árvore Verkle em vez de uma trie de estado local.

No que diz respeito especificamente ao sharding: o framework Nightshade da NEAR é um design de sharding de execução, dividindo tanto o estado como a computação entre as shards. A proposta Danksharding da Ethereum visa o sharding de disponibilidade de dados para Rollups de Camada 2 e não é um design de sharding de execução. Estes são objetivos arquiteturalmente diferentes que servem estruturas de rede distintas, e comparações diretas entre Nightshade e Danksharding requerem o reconhecimento de que resolvem problemas diferentes.

Onde se Enquadra a Validação Sem Estado no Roadmap da NEAR?

A Fase 2 do Nightshade consiste na validação sem estado (stateless validation). Vale a pena declarar esta equivalência de forma clara, pois a documentação da NEAR e as discussões na comunidade utilizam por vezes "Fase 2" e "validação sem estado" de forma intermutável, e compreender qual a fase atual indica o estado da arquitetura de escalabilidade da rede.

As Três Fases do Nightshade Explicadas

A implementação completa do Nightshade decorre em três fases distintas, cada uma a basear-se na anterior e a estabelecer os pré-requisitos para a seguinte.

Fase 1: Sharding Básico (Completa)

A NEAR dividiu o estado da sua rede por múltiplos shards, com cada shard a processar transações em paralelo. Os validadores mantinham cópias locais completas do estado do seu shard atribuído. Os produtores de blocos agregavam 'chunks' de todos os shards em blocos canónicos únicos. A Fase 1 estabeleceu a arquitetura baseada em 'chunks' Nightshade, mas deixou os requisitos de hardware diretamente acoplados ao tamanho do estado do shard, o que criou o teto de escalabilidade que a Fase 2 aborda.

Fase 2: Validação Stateless (Fase Atual)

Os validadores de fragmentos já não mantêm o estado local do fragmento. Os produtores de fragmentos geram testemunhos de estado e entregam-nos juntamente com os fragmentos. Isto desacopla os requisitos de hardware dos validadores de fragmentos do tamanho do estado do fragmento e permite que a rede escale para mais fragmentos sem aumentar proporcionalmente os custos de hardware dos validadores. À data da redação, a Fase 2 foi ativada na Mainnet da NEAR; para a data exata de ativação e o Status atual da rede, consulte o blog da NEAR Foundation) e o docs.near.org, uma vez que as fases do protocolo são ativadas progressivamente e a documentação é atualizada em conformidade.

Fase 3: Resharding Dinâmico (Planeado)

O NEAR ganhará a capacidade de aumentar ou diminuir automaticamente a sua contagem de fragmentos (shards) com base na procura da rede em tempo real, sem coordenação manual ou atualizações de hardware do validador. A validação sem estado (stateless validation) é um pré-requisito direto para o reparticionamento dinâmico (dynamic resharding): sem a Fase 2 ativa, adicionar fragmentos forçaria aumentos proporcionais de custos de armazenamento aos validadores, tornando o ajuste automatizado de fragmentos economicamente impraticável. A Fase 3 é o passo arquitetural que permite o dimensionamento horizontal teoricamente ilimitado no NEAR.

Em conjunto, as três fases representam a progressão da NEAR de uma Blockchain com fragmentação (sharding), atribuições de fragmentos fixas e validadores com estado, para uma rede dinamicamente escalável que ajusta a sua própria capacidade de processamento sem exigir que o seu conjunto de validadores cresça proporcionalmente em custos de hardware.

Validação Sem Estado da NEAR: Implicações para Validadores e Stakers

Para os validadores de 'chunks', a validação sem estado remove o maior fator de custo de hardware na arquitetura anterior da NEAR: a necessidade de manter uma cópia local completa do estado do 'shard'. Isto tem implicações diretas para a economia da operação de validadores e para a acessibilidade prática da participação de validadores.

Anteriormente, um validador de fragmentos necessitava de capacidade de armazenamento proporcional ao tamanho do estado da sua shard atribuída, e esse requisito aumentava à medida que a rede acumulava mais contas, dados de contrato e histórico de transações. O custo operacional de um validador de fragmentos incluía não só processamento e largura de banda, mas também infraestrutura de armazenamento contínua que escalava com o crescimento da rede.

Os validadores de chunk que operam sob validação sem estado deixam de prever o armazenamento de estado. Os seus requisitos de hardware passam para a capacidade de computação para a execução de transações e largura de banda de rede para a receção de testemunhos de estado e transmissão de atestações dentro do tempo do bloco. Este é um perfil de custo fundamentalmente diferente: estável em vez de crescente, e inferior para qualquer número de shards do que no modelo anterior.

A validação stateless altera os requisitos de hardware para os validadores de chunks, mas não altera a mecânica fundamental do contrato de staking. Os validadores continuam a investir em staking de tokens NEAR acima do limiar de lugar para participar no consenso, e permanecem sujeitos a slashing por comportamento inadequado do validador. O custo de hardware para cumprir esse requisito de participação diminui para os validadores de chunks, o que expande direcionalmente o conjunto de participantes que podem operar um nó validador de chunks com custos operacionais economicamente viáveis. Para especificações de hardware atuais e limiares de lugares de staking, consulte docs.near.org/validator.

Tenha em atenção que os produtores de chunks continuam a necessitar do estado completo da shard local para gerar testemunhos de estado. A redução de hardware aplica-se aos validadores de chunks, a função mais numerosa na rede. Os produtores de chunks mantêm os seus requisitos de armazenamento de estado, embora representem uma parte menor do número total de validadores.

Para se tornar um validador na NEAR, um participante faz stake de tokens NEAR acima do limiar de lugar atual e executa o software de validador. Para obter instruções de configuração completas e as especificações de hardware atuais, atualizadas para refletir os requisitos de validação sem estado, consulte docs.near.org/validator diretamente.

Perguntas Frequentes

Para que é utilizado o NEAR Protocol?

O NEAR Protocol é uma blockchain de camada 1 concebida para implementar aplicações descentralizadas, incluindo protocolos DeFi, plataformas NFT, aplicações de Gaming e ferramentas para programadores. Utiliza o sharding Nightshade para processar transações em várias shards paralelas, permitindo alta capacidade de processamento com taxas de transação quase nulas. O Token NEAR paga taxas de gás para a execução de transações e contratos, e os validadores investem em staking Tokens NEAR como garantia para participar no consenso.

Como funciona o NEAR Protocol?

No seu núcleo, o NEAR opera como uma blockchain de prova de participação dividida em múltiplos shards, cada um a processar transações em paralelo. Cada shard produz um chunk (um bloco ao nível do shard) em cada intervalo de blocos; um produtor de blocos agrega estes chunks num único bloco canónico. Os validadores são atribuídos aleatoriamente a shards a cada época e são responsáveis por executar e atestar as transações no chunk do seu shard atribuído, permitindo a validação sem estado que os validadores de chunk desempenhem esta função sem manter o estado local do shard.

O que é o sharding Nightshade?

Nightshade é a estrutura de sharding do NEAR Protocol, na qual o estado global da rede e o processamento de transações são divididos por múltiplos fragmentos (shards) paralelos. Ao contrário de modelos que tratam cada fragmento como uma Blockchain separada, o Nightshade trata todos os fragmentos como componentes de uma única Blockchain lógica, em que cada bloco contém um chunk por fragmento ativo. O Nightshade é implementado em três fases: sharding básico (Fase 1), validação sem estado (Fase 2) e resharding dinâmico (Fase 3).

O que é uma testemunha de estado (state witness) em Blockchain?

Uma testemunha de estado é uma estrutura de dados criptográfica que contém todos os dados de estado necessários para validar um bloco ou fragmento específico, empacotada e entregue aos validadores para que não precisem de aceder a uma base de dados de estado local durante a execução. No NEAR Protocol, a testemunha de estado para um fragmento inclui os saldos das contas, as entradas de armazenamento de contratos e as chaves de acesso tocadas pelas transações nesse fragmento. O produtor de fragmentos gera a testemunha de estado e transmite-a juntamente com o fragmento aos validadores de fragmentos, que executam transações utilizando os dados da testemunha e depois descartam-na após produzirem a sua atestação.

Como funcionam os validadores NEAR?

Os validadores da NEAR operam em três funções distintas sob a validação sem estado (stateless validation): produtores de chunks, validadores de chunks e produtores de blocos. Os produtores de chunks constroem chunks (blocos ao nível da shard) e geram testemunhos de estado ao ler o estado relevante da sua Copiar local do estado da shard. Os validadores de chunks recebem o chunk e o testemunho de estado, executam transações utilizando apenas os dados do testemunho sem armazenamento de estado local, atestam a validade do chunk e eliminam o testemunho. Os produtores de blocos agregam os chunks atestados de todas as shards ativas num único bloco canónico. Os validadores devem Investir em staking tokens NEAR acima de um limite de entrada (seat threshold) para participar no consenso e são atribuídos aleatoriamente a shards em cada época.

Como é que a validação sem estado melhora a escalabilidade?

A validação sem estado melhora a escalabilidade ao desacoplar a contagem de shards dos requisitos de hardware dos validadores. Com a validação com estado, adicionar mais shards exigia que os validadores atribuídos a cada novo shard mantivessem armazenamento local proporcional, criando um limite de hardware para quantos shards a rede poderia suportar na prática. Com a validação sem estado, os validadores de chunks recebem todos os dados de estado necessários por chunk como uma testemunha de estado e descartam-na após a utilização, pelo que adicionar shards não aumenta os requisitos de armazenamento por validador, permitindo que a NEAR escale horizontalmente ao aumentar a contagem de shards para processar mais transações em paralelo.

A NEAR é uma boa blockchain para programadores?

O NEAR Protocol oferece aos programadores contratos inteligentes baseados em WASM que podem ser escritos em Rust ou JavaScript, um modelo de Staking de armazenamento que vincula os custos de armazenamento de contratos a tokens NEAR em staking, compatibilidade com Aurora EVM para programadores de Ethereum que implementam contratos Solidity, e nomes de conta legíveis por humanos. A validação sem estado (stateless validation) é uma melhoria de infraestrutura ao nível do protocolo que beneficia todos os contratos implementados automaticamente, sem exigir quaisquer alterações de código. À medida que o número de shards aumenta, a capacidade de processamento da rede cresce e os contratos beneficiam de uma congestão reduzida. Os programadores que avaliam a NEAR para a implementação de dApps em produção devem consultar docs.near.org para obter as especificações atuais do SDK e a documentação de ferramentas.

A validação sem estado da NEAR já está ativa?

A Fase 2 do Nightshade, que corresponde à validação sem estado (stateless validation), foi ativada na Mainnet da NEAR. As fases do protocolo são implementadas progressivamente e a documentação é atualizada pela NEAR Foundation à medida que cada fase atinge a ativação total. Para consultar o Status de implementação mais recente, incluindo a data precisa de ativação e quaisquer notas específicas da fase, consulte o blog da NEAR Foundation e a documentação oficial do NEAR Protocol.