Modelo de Conta NEAR: Nomes, Chaves e Armazenamento

["O que é o Protocolo NEAR? Uma Breve Introdução","Resumo: O Modelo de Conta NEAR Numa Vista Geral","O que é o Modelo de Conta NEAR?","Contas Nomeadas e Contas Implícitas: Como o NEAR Identifica Utilizadores","Subcontas: Organização Hierárquica de Contas no NEAR","Chaves de Acesso NEAR: Permissões de Acesso Total vs. Chamada de Função","Armazenamento Staking: Porquê as Contas NEAR Requerem um Saldo Mínimo","Modelo de Conta NEAR vs. Ethereum: Uma Comparação Lado a Lado","Primeiros Passos: Criar e Gerir a Sua Conta NEAR","Perguntas Frequentes: Modelo de Conta NEAR","Conclusão: O que o Modelo de Conta NEAR Significa para Desenvolvedores e Utilizadores"]

O que é o NEAR Protocol? (Uma Breve Introdução)

O NEAR Protocol é uma blockchain de Camada 1 (Layer-1), proof-of-stake, construída para a acessibilidade dos programadores, com taxas de transação baixas e previsíveis e uma arquitetura de sharding concebida para escalar sem sacrificar a usabilidade. Cofundado por Illia Polosukhin e Alexander Skidanov, o NEAR Protocol foi concebido desde o início com a experiência do programador e a acessibilidade do utilizador final como objetivos principais, em vez de adaptar a usabilidade a uma arquitetura construída para outros fins.

A NEAR escala através do sharding Nightshade, um mecanismo que distribui o estado das contas e a computação por cadeias de processamento paralelas, permitindo que a rede lide com volumes elevados de transações sem um aumento proporcional das taxas. O protocolo suporta contratos inteligentes compilados para WebAssembly e mantém os custos de gás baixos por conceção, em contraste com blockchains onde a volatilidade das taxas cria atrito tanto para os programadores como para os utilizadores. O desenvolvimento do ecossistema é supervisionado pela NEAR Foundation, o órgão de governação sem fins lucrativos que anteriormente operava a NEAR Wallet oficial antes de transitar para alternativas mantidas pela comunidade.

A expressão mais clara desta filosofia que prioriza os desenvolvedores é o modelo de conta da NEAR, um conceito que repensa como funcionam a identidade e a gestão de permissões na blockchain a partir do zero.

Resumo: Visão Geral do Modelo de Conta da NEAR

Resumo rápido para quem lê na diagonal:

• As contas NEAR utilizam nomes legíveis por humanos (ex.: alice.near) em vez de sequências de hashes criptográficos como os endereços 0x742d35Cc... do Ethereum.
• Cada conta pode ter várias chaves de acesso simultaneamente, cada uma com o seu próprio nível de permissão, desde o controlo total até interações de Smart Contract de âmbito limitado.
• Qualquer conta NEAR pode implementar um Smart Contract; não existe um tipo de conta de contrato separado como no Ethereum.
• As subcontas seguem um espaço de nomes hierárquico (ex.: contract.myapp.near sob myapp.near), funcionando como subdomínios para contas Blockchain.
• As contas devem manter um saldo mínimo de Token NEAR proporcional à sua utilização de armazenamento On-Chain, um mecanismo designado por storage Staking.
• O sistema nativo de permissões multichave da NEAR atinge muitos dos objetivos que o Ethereum procura alcançar com a abstração de conta (EIP-4337), mas através de uma abordagem arquitetural diferente, integrada desde a sua conceção.

Qual é o Modelo de Conta da NEAR?

O modelo de conta NEAR é a arquitetura de identidade e permissões na blockchain que define como as contas são nomeadas, que estado armazenam, como o acesso é gerido através de permissões de chave granulares e como se relacionam com contratos inteligentes na blockchain NEAR.

No contexto da blockchain, um "modelo de conta" refere-se ao sistema que um protocolo utiliza para representar os participantes na blockchain: o que uma conta contém, como é identificada, como autoriza transações e se pode executar código. O Ethereum utiliza um modelo de conta; o Bitcoin utiliza um paradigma totalmente diferente (o modelo UTXO, onde os saldos são rastreados como saídas de transações não gastas em vez de saldos de conta). O NEAR utiliza um modelo baseado em contas, mas a sua implementação difere significativamente da do Ethereum em aspetos que importam tanto para a usabilidade como para o desenvolvimento de aplicações.

Uma conta NEAR detém cinco elementos em simultâneo: um ID de conta único, um saldo de tokens NEAR, o estado da conta (armazenamento de dados na blockchain), um smart contract opcional implementado e compilado para WebAssembly (WASM, permitindo contratos escritos em Rust ou JavaScript) e uma ou mais chaves de acesso com níveis de permissão distintos. Esta estrutura unificada significa que não existe uma separação entre "contas de utilizador" e "contas de smart contract" como no Ethereum. Qualquer conta NEAR pode, opcionalmente, alojar um smart contract sem se tornar uma categoria de objeto diferente. As contas sem contratos implementados funcionam como contas de utilizador comuns; as contas com contratos implementados são, simultaneamente, contas de utilizador e anfitriões de contratos.

O contexto prático para entender por que isto é importante é a aplicação descentralizada (dApp), uma aplicação de software que corre numa rede Blockchain em vez de servidores centralizados. A arquitetura de contas da NEAR foi concebida para tornar as interações de dApp mais seguras e acessíveis do que os modelos de contas Blockchain existentes permitem. O sistema de ID de conta é onde esta filosofia de design é mais imediatamente visível, e é aí que começa a visita arquitetónica.

Para a especificação técnica completa, consulte a documentação do modelo de conta do NEAR Protocol em docs.near.org/concepts/basics/accounts/model.

Contas Nomeadas e Contas Implícitas: Como o NEAR Identifica os Utilizadores

O NEAR identifica utilizadores e aplicações na blockchain através de dois formatos de conta: contas nomeadas, que utilizam strings legíveis por humanos como alice.near, e contas implícitas, que são strings hexadecimais de 64 caracteres derivadas de uma chave pública.

Contas Nomeadas: Identidades Legíveis por Humanos Blockchain

As contas nomeadas na NEAR são identificadores de conta legíveis por humanos que seguem uma estrutura semelhante a um domínio, terminando em .near na Mainnet e em .testnet na testnet, substituindo as sequências de hash criptográfico utilizadas por blockchains como a Ethereum.

O contraste é imediato: alice.near versus 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Ambos são identificadores de blockchain válidos, mas um é legível e o outro exige uma verificação cuidadosa ao copiar e colar. Pense numa conta nomeada da NEAR como um endereço de e-mail: legível e associada a uma identidade, em vez de uma sequência aleatória de caracteres que exige uma comparação carácter a carácter para verificação.

As contas nomeadas seguem regras de nomenclatura específicas: os IDs de conta são sequências alfanuméricas, podem utilizar pontos como separadores, devem ter entre 2 e 64 caracteres e devem terminar em .near na Mainnet ou .testnet na rede de teste. A estrutura separada por pontos cria uma hierarquia semelhante a um domínio: myapp.near é uma conta nomeada de nível superior, e contract.myapp.near é uma subconta dependente desta (mais informações sobre subcontas na secção seguinte).

A lógica de UX por trás das contas nomeadas vai para além da estética. Identificadores legíveis reduzem o risco de enviar transações para contas erradas, tornam os endereços de contratos detetáveis e diminuem o esforço cognitivo da gestão de identidades na blockchain. Para quem já verificou três vezes um endereço MetaMask antes de enviar uma transação, o apelo de alice.near face a uma string hexadecimal de 42 caracteres é concreto e não abstrato. Os utilizadores registam e gerem contas nomeadas através da MyNEARWallet em mynearwallet.com, a principal interface de conta mantida pela comunidade (a wallet.near.org original, operada pela NEAR Foundation, foi descontinuada).

Contas Implícitas: O Formato de Conta Alternativo

Contas implícitas são o segundo formato de conta no NEAR: sequências hexadecimais em minúsculas com 64 caracteres derivadas diretamente de uma Chave pública, que passam a existir assim que os tokens NEAR são enviados para esse ID de conta, sem exigir qualquer ação de uma conta existente.

A principal distinção prática: uma conta nomeada requer uma conta existente on-chain para patrocinar o seu registo através de uma transação, enquanto uma conta implícita passa a existir automaticamente quando os fundos chegam ao ID da conta derivada. Isto torna as contas implícitas úteis em contextos onde é necessário um arranque do zero, ou onde nomes legíveis por humanos são desnecessários. As corretoras de criptomoedas utilizam tipicamente contas implícitas ao creditar depósitos NEAR a utilizadores, gerando um ID de conta único a partir da chave pública do utilizador sem exigir uma conta on-chain pré-existente.

Uma desambiguação que vale a pena referir claramente: as contas implícitas não são anónimas. São derivadas de forma determinística a partir de uma chave pública e são totalmente transparentes na blockchain. A palavra "implícita" refere-se à forma como o ID da conta é derivado (a partir da própria chave, sem um passo de registo explícito) e não a qualquer propriedade de privacidade.

Contas nomeadas e implícitas definem como a NEAR identifica os participantes na blockchain. As contas podem também conter outras contas sob o seu namespace, e essa estrutura hierárquica é onde entram as subcontas.

--- ## Subcontas: Organização Hierárquica de Contas na NEAR

Subcontas na NEAR funcionam como subdomínios na web: tal como docs.myapp.com e api.myapp.com são endereços distintos sob o domínio myapp.com, token.myapp.near e staking.myapp.near são contas blockchain distintas sob o namespace myapp.near.

Uma subconta é uma conta cujo ID existe sob o namespace de uma conta principal. A conta contract.myprotocol.near é uma subconta de myprotocol.near. Apenas a conta principal pode criar uma subconta: myprotocol.near pode criar contract.myprotocol.near, mas nenhuma outra conta pode criar uma conta sob esse namespace sem a autorização da conta principal.

Importante: Uma conta principal não pode aceder aos fundos ou ao estado de uma subconta após a criação desta. As subcontas são contas totalmente independentes que apenas partilham um espaço de nomes, não sendo subsidiárias controladas por uma conta principal.

Esta independência é um ponto comum de confusão. A relação pai-filho aplica-se apenas no momento da criação. Uma vez que contract.myprotocol.near exista, possui as suas próprias chaves de acesso, o seu próprio saldo de Token NEAR e o seu próprio estado na blockchain. A conta pai myprotocol.near não tem privilégios especiais sobre ela.

Para desenvolvedores de dApps, as subcontas fornecem um padrão de arquitetura prático. Como qualquer conta NEAR pode implementar um smart contract (compilado para WASM), as subcontas tornam-se uma forma natural de dar a cada componente do contrato um ID de conta legível e organizado. Um protocolo DeFi poderá implementar token.myprotocol.near para o seu contrato de Token, staking.myprotocol.near para o seu contrato de Staking, e governance.myprotocol.near para o seu contrato de governança. Cada um é uma conta distinta com o seu próprio contrato, o seu próprio estado e a sua própria gestão de chaves, mas o namespace torna a relação entre os componentes imediatamente legível para qualquer pessoa que consulte a cadeia. Para instruções passo a passo sobre a criação de subcontas, consulte a documentação de subcontas NEAR em docs.near.org/concepts/basics/accounts/model#named-accounts.)

Compreender como as contas são denominadas e organizadas prepara o terreno para a próxima camada arquitetónica: como são protegidas e têm permissões através de chaves de acesso.

Chaves de Acesso NEAR: Acesso Completo vs. Permissões de Chamada de Função

Chaves de acesso NEAR são a camada de permissão que controla que ações podem ser tomadas numa conta NEAR, e a característica arquitetónica mais distintiva do sistema: uma única conta NEAR pode conter múltiplos pares de chaves independentes simultaneamente, cada um com o seu próprio nível de permissão.

Como Funciona o Sistema Multi-Chave da NEAR

Ao contrário da maioria das contas Blockchain, em que uma Chave privada controla tudo, uma única conta NEAR pode conter múltiplos pares de chaves independentes, cada um atribuído a um tipo de permissão específico, desde controlo irrestrito a interações de contrato com âmbito restrito.

As chaves de acesso da NEAR utilizam pares de chaves Ed25519 por predefinição (com secp256k1 também suportado para compatibilidade com a cadeia de ferramentas de Ethereum). O sistema de permissões construído sobre estes pares de chaves é o que torna o modelo da NEAR arquiteturalmente distinto. Pense nele como um porta-chaves: uma Chave de Acesso Total (Full Access Key) é a chave-mestra que abre todas as fechaduras; uma Chave de Acesso a Chamadas de Funções (Function Call Access Key) é uma chave concebida para um fim específico que apenas abre uma porta específica. Cada transação assinada por qualquer chave de acesso numa conta consome gás pago em tokens NEAR, mas as taxas de transação da NEAR são baixas e previsíveis por design, em contraste com o histórico de preços de gás variáveis de Ethereum.

Para obter detalhes sobre como adicionar e gerir chaves de acesso programaticamente, consulte a documentação de referência sobre chaves de acesso NEAR em docs.near.org/concepts/basics/accounts/access-keys (https://docs.near.org/concepts/basics/accounts/access-keys).)

Chaves de Acesso Total: Controlo Irrestrito da Conta

Uma Chave de Acesso Completo na NEAR é um par de chaves que pode executar qualquer ação na conta a que está associada: transferir tokens, implementar contratos inteligentes, criar subcontas, adicionar ou remover outras chaves e eliminar a própria conta.

Como uma Chave de Acesso Total controla toda a conta, esta apresenta o mesmo perfil de risco que uma palavra-passe mestra. As Chaves de Acesso Total nunca devem ser partilhadas com aplicações de Terceiros e devem ser guardadas em armazenamento a frio (carteira de hardware ou armazenamento offline) para qualquer conta que detenha fundos significativos. Se uma Chave de Acesso Total for comprometida, o atacante terá o controlo total da conta sem qualquer mecanismo de recuperação nativo, a menos que tenha sido configurado um previamente.

A comparação com o Ethereum é instrutiva aqui. No Ethereum, a sua única chave privada de uma Conta de Propriedade Externa (EOA) funciona como uma Chave de Acesso Total: controla tudo, e não existe uma forma nativa de conceder a uma dApp uma chave com permissões reduzidas para uma interação específica com contratos. Cada ligação de dApp através da MetaMask expõe a sua chave completa da conta ao fluxo de assinatura de transações. Essa limitação de chave única é precisamente o problema que a abstração de conta EIP-4337 foi concebida para resolver no Ethereum. No NEAR, a solução foi integrada no modelo de conta base.

Chaves de Acesso a Chamadas de Função: Permissões com Âmbito Definido para Segurança de dApps

Uma Chave de Acesso a Chamada de Função é uma chave restrita que só pode chamar métodos especificados num único smart contract designado, com um limite opcional de alocação de gas que limita a despesa total de taxas.

Onde uma Chave de Acesso Completo é irrestrita, uma Chave de Acesso a Chamada de Função é precisamente delimitada. A chave especifica: um ID de conta de contrato que tem permissão para chamar, quais métodos nesse contrato pode invocar (ou todos os métodos públicos, se não houver mais restrições), e uma autorização opcional de Token NEAR que limita a quantidade de 'gas' que a chave pode gastar antes de necessitar de reposição. Assim que a autorização for esgotada, a chave não pode assinar transações adicionais até ser reabastecida ou substituída.

O caso de uso de autenticação baseada em sessão é onde as Function Call Access Keys mostram o seu valor prático para o desenvolvimento de dApps. Quando liga uma dApp à sua conta NEAR, a dApp solicita uma Function Call Access Key com âmbito definido para o seu próprio contrato. Esta chave é armazenada na sessão do seu browser. A partir desse momento, a dApp pode submeter transações em seu nome (aprovar um Trade, cunhar um NFT, interagir com um contrato de jogo) sem lhe pedir para assinar cada ação individual. A sua Full Access Key nunca sai da sua carteira segura. Se a dApp estiver comprometida ou for maliciosa, o dano é limitado: o atacante apenas pode chamar os métodos de contrato específicos para os quais a chave foi definida, e apenas até ao montante da permissão. Uma Function Call Access Key funciona como um Token de sessão numa aplicação web: concede acesso temporário e delimitado a ações específicas sem expor as credenciais completas da conta.

As chaves de acesso controlam que ações uma conta pode realizar. O staking de armazenamento rege o que uma conta deve deter para existir na blockchain.

Armazenamento Staking: Por que as Contas NEAR Exigem um Saldo Mínimo

O Staking de armazenamento na NEAR é o mecanismo pelo qual cada conta deve manter um saldo mínimo de Token NEAR proporcional à quantidade de armazenamento na blockchain (estado) que a conta utiliza.

O mecanismo funciona da seguinte forma: A NEAR aloca armazenamento na blockchain medido em bytes. Por cada byte de estado armazenado numa conta (registos de saldo, código de contrato, dados armazenados, chaves de acesso), um montante correspondente de tokens NEAR deve ser mantido no saldo da conta. Esses tokens não são gastos nem destruídos; são reservados como um saldo bloqueado contra a pegada de armazenamento. Se reduzir o armazenamento da sua conta eliminando dados de estado ou de contrato, os tokens correspondentes são desbloqueados e devolvidos ao seu saldo disponível. O armazenamento em staking funciona como um depósito de segurança reembolsável: bloqueia um montante proporcional de tokens NEAR para o armazenamento que a sua conta utiliza, e recebe esses tokens de volta se reduzir a sua pegada de armazenamento.

O objetivo deste design é económico: impede o inchaço do estado, garantindo que a parte que beneficia do armazenamento na blockchain suporta o custo desse armazenamento. Sem um mecanismo como este, uma rede blockchain pode acumular quantidades ilimitadas de estado inativo de contas ou contratos abandonados, degradando o desempenho para todos os participantes.

Em termos concretos, a taxa de staking de armazenamento é de aproximadamente 1 NEAR token por cada 10 KB de armazenamento na blockchain, e uma conta NEAR vazia recém-criada requer um saldo mínimo de aproximadamente 0,00182 NEAR para cobrir a sua pegada de estado base. Verifique os valores atuais na documentação de storage staking da NEAR em docs.near.org/concepts/storage/storage-staking antes de confiar nestes números para o planeamento do desenvolvimento, visto que os parâmetros do protocolo mudam com as atualizações.

Para os programadores de Smart Contract, a implicação de storage Staking exige um planeamento ativo. Quando uma conta NEAR implementa um contrato, o próprio código do contrato ocupa armazenamento no estado da conta. Um binário de contrato maior requer um saldo reservado proporcionalmente maior. Se o seu contrato armazenar dados significativos (registos de utilizadores, saldos de Token, votos de governação), a conta que aloja esse contrato deve manter um saldo suficientemente grande para cobrir tanto o código do contrato como o estado acumulado. Este é um requisito de capital que escala com a utilização da aplicação e deve ser tido em conta no seu modelo económico antes da implementação.

O Staking de armazenamento cria um requisito real de bloqueio de capital. Alguns desenvolvedores consideram isto restritivo em comparação com cadeias que não exigem saldos de armazenamento reservados. A contrapartida é deliberada: a restrição impede que o estado da rede cresça sem limites, e os tokens são recuperáveis. Mas a restrição é real e deve ser planeada em vez de descoberta após a implementação.

Staking de armazenamento vs. staking de validador: Estes são dois mecanismos distintos na NEAR. O Staking de armazenamento bloqueia tokens NEAR face à pegada de dados da sua conta na blockchain; esses tokens atuam como um saldo reservado proporcional ao armazenamento utilizado. O Staking de validador bloqueia tokens NEAR face ao mecanismo de consenso, onde os validadores investem tokens em staking para participar na produção de blocos e ganhar recompensas de staking. Este artigo abrange apenas o staking de armazenamento. Não confunda estas duas utilizações da palavra "staking".

As taxas de gás (custos de execução de transação) diferem do Staking de armazenamento. As taxas de gás são consumidas por transação e pagas em tokens NEAR no momento da assinatura; o Staking de armazenamento é um saldo reservado que persiste na conta enquanto o estado associado existir.

Compreender o staking de armazenamento completa o quadro de como as contas NEAR funcionam isoladamente. A próxima questão é como esta arquitetura se compara à da Ethereum.

Modelo de Conta NEAR vs. Ethereum: Uma Comparação Lado a Lado

O NEAR e o Ethereum adotam abordagens fundamentalmente diferentes para a arquitetura de contas na blockchain, e as diferenças são consequentes para a forma como os programadores constroem aplicações descentralizadas e como os utilizadores gerem as suas identidades on-chain.

O Sistema de Duas Contas do Ethereum vs. O Modelo de Conta Unificado do NEAR

A tabela abaixo contrasta os dois modelos de conta em oito dimensões arquiteturais. A diferença mais significativa é que o Ethereum separa as contas de utilizador (Externally Owned Accounts ou EOAs) das contas de Smart Contract em dois tipos distintos, enquanto a NEAR utiliza um único tipo de conta unificado para ambas.

A separação entre EOA (Conta Externa Controlada) e Conta de Contrato na Ethereum cria atrito na prática. A maioria das interações de dApps requerem uma EOA para chamar uma Conta de Contrato, o que significa que os utilizadores têm de gerir ambos os tipos como entidades distintas. Uma EOA é controlada por uma única Chave privada, sem forma nativa de definir o âmbito das permissões: qualquer dApp ligada a uma conta MetaMask pode solicitar assinaturas que exponham a chave da conta completa ao fluxo da transação. O modelo da Ethereum tem uma justificação de design clara e serviu bem os seus objetivos originais, mas a limitação da chave única tornou-se aparente à medida que as interações de dApps se tornaram mais frequentes e variadas.

O tipo de conta unificado da NEAR elimina a separação entre EOA (Conta de Propriedade Externa) e contrato. Cada conta NEAR é potencialmente um anfitrião de contrato, e o sistema de múltiplas chaves com Chaves de Acesso para Chamadas de Função (Function Call Access Keys) aborda a limitação de chave única sem necessitar de uma camada de protocolo separada. Tanto a NEAR como a Ethereum operam no paradigma baseado em contas, em contraste com o modelo UTXO da Bitcoin, onde os saldos são rastreados como saídas de transação não gastas (unspent transaction outputs) em vez de estado da conta; a diferença entre a NEAR e a Ethereum reside na forma como essas contas são estruturadas e nas permissões concedidas, não no paradigma fundamental.

Modelo de Conta da NEAR e Abstração de Conta da Ethereum (EIP-4337)

EIP-4337 (abstração de conta) representa o esforço da Ethereum para dotar os EOA com o tipo de permissões programáveis e capacidades de chave de sessão que o modelo de conta da NEAR foi projetado para incluir desde o início.

O EIP-4337 é um standard Ethereum ativo (não uma proposta teórica) que permite que carteiras Smart Contract funcionem como cidadãos de primeira classe, suportando validação programável de transações, chaves de sessão, recuperação social e transações patrocinadas. Requer uma infraestrutura de bundler específica para operar e está ativamente implementado em todo o ecossistema Ethereum, embora não seja uma atualização universal aplicada automaticamente a todas as contas.

O paralelismo com as Chaves de Acesso para Chamadas de Função do NEAR é real: ambas as abordagens abordam o problema de conceder às dApps acesso com permissões limitadas e escopo definido para interações específicas sem expor a chave de conta completa. Um programador familiarizado com as chaves de sessão EIP-4337 irá considerar as Chaves de Acesso para Chamadas de Função do NEAR conceitualmente familiares. A nuance importante é que estas são implementações arquiteturalmente distintas de ideias sobrepostas, não sistemas idênticos. O modelo de permissão multi-chave do NEAR é nativo do protocolo base; o EIP-4337 adiciona lógica de carteira de Smart Contract por cima do modelo EOA existente do Ethereum. Os problemas que abordam sobrepõem-se significativamente; os mecanismos diferem. Para a especificação completa do EIP-4337, consulte a especificação de abstração de conta EIP-4337 em eips.ethereum.org/EIPS/eip-4337.

Para desenvolvedores Ethereum que avaliam NEAR, duas pontes de ecossistema merecem destaque. Aurora em aurora.dev, um ambiente compatível com EVM construído em NEAR, permite que desenvolvedores Ethereum implementem contratos Solidity na infraestrutura NEAR enquanto contas NEAR servem como camada de identidade subjacente. Desenvolvedores que trabalham em ambos os ecossistemas podem usar Rainbow Bridge em rainbowbridge.app para transferir ativos entre contas NEAR e endereços Ethereum sem depender de custódia centralizada.

Agora que a arquitetura está clara, eis o que a criação e a gestão de uma conta NEAR implicam na prática.

Primeiros Passos: Criar e Gerir a Sua Conta NEAR

Pode criar a sua primeira conta NEAR através de MyNEARWallet em mynearwallet.com, a interface principal mantida pela comunidade para o registo de contas NEAR e gestão de chaves. Verifique a recomendação de carteira canónica atual no momento em que lê isto, uma vez que o ecossistema de carteiras NEAR continua a evoluir; existem outras aplicações de carteira compatíveis para além da MyNEARWallet.

Se vem do Ethereum e do MetaMask, a diferença conceptual vale a pena ser compreendida antes de começar. Uma carteira MetaMask é primariamente um gestor de chaves e um assinante de transações para EOAs Ethereum: ela guarda a sua chave privada e apresenta-a às dApps para assinatura de transações. Uma conta NEAR é uma identidade completa na blockchain com um nome legível, armazenamento de estado na blockchain, permissões de chave programáveis e hospedagem de contrato opcional. A aplicação de carteira (MyNEARWallet) é a interface; a conta NEAR é o objeto na blockchain. São coisas diferentes, e a distinção importa para a forma como pensa na gestão de chaves.

Criar uma conta NEAR requer um pequeno saldo inicial de Token NEAR para cobrir o requisito base de staking de armazenamento (aproximadamente 0.00182 NEAR para uma conta vazia, conforme abordado na secção Armazenamento Staking acima). Este saldo inicial cobre a pegada de estado base de uma conta nova.

Há três riscos que deve conhecer antes de começar. Primeiro, se perder a sua Chave de Acesso Total sem ter configurado um mecanismo de recuperação, a conta é irrecuperável. Guarde a sua Chave de Acesso Total em armazenamento a frio (cold storage) e configure quaisquer Opções de recuperação disponíveis antes de precisar delas. Segundo, os tokens NEAR reservados para storage Staking ficam bloqueados enquanto o estado associado existir; isto é um compromisso de capital e não uma taxa. Terceiro, a eliminação de conta na NEAR é irreversível. Para um guia passo a passo completo sobre a criação de conta, consulte a documentação para programadores da NEAR em docs.near.org/concepts/basics/accounts/model.

As perguntas mais comuns sobre o modelo de conta NEAR são respondidas abaixo.

Perguntas Frequentes: Modelo de Conta NEAR

As perguntas abaixo abordam os pontos de confusão mais comuns sobre o modelo de conta do NEAR, com referências cruzadas para as secções relevantes acima para leitores que pretendem uma cobertura completa.

Qualquer conta NEAR pode implementar um Smart Contract?

Sim. No NEAR, qualquer conta pode opcionalmente implementar um Smart Contract compilado para WebAssembly (WASM). Não existe um tipo de conta de contrato separado, ao contrário do Ethereum, onde a implementação de um contrato requer a criação de uma Conta de Contrato distinta. Uma conta sem um contrato implementado funciona como uma conta de utilizador padrão; uma conta com um contrato implementado funciona como ambas simultaneamente. Consulte a secção O que é o Modelo de Conta NEAR acima para obter a explicação completa da arquitetura.

Como é que as chaves de acesso da NEAR tornam as dApps mais seguras de utilizar?

As Chaves de Acesso a Chamadas de Função restringem uma dApp a métodos de contrato específicos com um limite opcional de gasto de gás. Quando se liga a uma dApp utilizando uma Chave de Acesso a Chamadas de Função com âmbito para o contrato dessa dApp, a sua Chave de Acesso Total (e o saldo total da sua conta) nunca é exposta à aplicação de Terceiros. Se a dApp for comprometida, o dano fica limitado à margem permitida e ao contrato especificado. Consulte a secção de Chaves de Acesso NEAR para obter a análise completa.

O que acontece se eu perder a minha Chave de Acesso Total?

A perda de uma Full Access Key sem um mecanismo de recuperação pré-configurado torna a conta permanentemente irrecuperável. Não pode redefinir ou recuperar uma Full Access Key da mesma forma que redefine uma palavra-passe, porque não existe uma autoridade central que controle a conta. Guarde sempre as Full Access Keys em armazenamento a frio (cold storage) seguro e configure quaisquer opções de recuperação de conta disponíveis através da sua aplicação de carteira antes de precisar delas. Algumas carteiras oferecem configurações de recuperação social ou de recuperação multi-chave.

As taxas de gás são o mesmo que storage staking?

Não. As taxas de gás são custos de execução por transação consumidos no momento em que uma transação é assinada; são pagas em tokens NEAR e não persistem após a conclusão da transação. O staking de armazenamento é um saldo mínimo reservado de tokens NEAR que persiste com a conta enquanto o estado associado na blockchain existir. Ambos envolvem tokens NEAR, mas operam como mecanismos totalmente separados. Consulte a secção Armazenamento Staking para uma explicação completa.

Como é que o modelo de conta da NEAR se relaciona com a abstração de conta da Ethereum (EIP-4337)?

O sistema nativo de permissões multi-chave da NEAR alcança muitos dos objetivos que a EIP-4337 foi concebida para adicionar ao Ethereum, incluindo permissões baseadas em sessões com escopo definido para interações com dApps e lógica de chave programável. As duas são implementações arquitetonicamente distintas de ideias que se sobrepõem: a abordagem da NEAR é nativa do protocolo base, enquanto a EIP-4337 sobrepõe a lógica de carteira de Smart Contract ao modelo EOA existente do Ethereum. Elas resolvem problemas semelhantes através de arquiteturas diferentes. Consulte a secção de comparação NEAR vs. Ethereum para a análise detalhada.

Qual é a diferença entre uma conta nomeada e uma conta implícita na NEAR?

As contas nomeadas são identificadores fáceis de ler (ex: alice.near) registadas através de uma transação de uma conta já existente, terminando em .near na Mainnet e .testnet na testnet. As contas implícitas são strings hexadecimais de 64 caracteres derivadas diretamente de uma Chave pública, que passam a existir automaticamente quando os tokens NEAR são enviados para esse ID de conta, sem necessidade de transação de registo. Consulte a secção Contas Nomeadas e Contas Implícitas para obter a tabela de comparação completa.

Quantas chaves de acesso pode uma única conta NEAR ter?

Uma conta NEAR pode conter múltiplas chaves de acesso simultaneamente, com cada chave a ter o seu próprio tipo de permissão (Chave de Acesso Total ou Chave de Chamada de Função) e, para Chaves de Chamada de Função, o seu próprio âmbito de contrato e limite de gás. Não existe um limite documentado rígido no número de chaves por conta. Esta capacidade multi-chave é o que distingue o modelo de permissões da NEAR da abordagem da Ethereum de uma chave por EOA. Consulte a secção Chaves de Acesso NEAR para obter detalhes.

O staking de armazenamento significa que perco os meus tokens NEAR?

Não. Tokens NEAR reservados para staking de armazenamento estão bloqueados mas não gastos. Permanecem na sua conta como um saldo reservado e são devolvidos ao seu saldo disponível se reduzir a pegada de dados na blockchain da sua conta eliminando estado. Os tokens são um depósito contra o uso de armazenamento, não uma taxa. Consulte a Secção de armazenamento Staking para o mecanismo e os valores atuais.

Conclusão: O que o Modelo de Conta NEAR Significa para Programadores e Utilizadores

O modelo de conta NEAR reflete um conjunto de escolhas arquitetónicas deliberadas: nomes de conta legíveis por humanos diminuem a barreira de entrada e reduzem erros de transação; um sistema de permissões multi-chave reduz o risco de segurança para interações de dApps, ao delimitar o acesso de Terceiros sem expor as chaves mestras; o storage Staking cria um alinhamento económico entre o uso de recursos e o custo; e uma estrutura unificada de conta-contrato elimina a separação EOA/contrato que adiciona atrito ao desenvolvimento Ethereum.

O requisito mínimo de saldo para Staking de armazenamento é uma restrição genuína a ter em conta, não uma nota de rodapé. Se a sua aplicação armazena um estado significativo na blockchain, o requisito de saldo reservado escala com esse estado. Orçamente para ele no modelo económico da sua aplicação antes da implementação, não depois.

Próximos passos por persona:

• Desenvolvedores: Comece a construir no NEAR Protocol em docs.near.org/develop
• Utilizadores: Crie a sua conta NEAR em MyNEARWallet em mynearwallet.com
• Investigadores: Aprofunde-se na especificação completa do modelo de contas em Documentação do modelo de contas do NEAR Protocol em docs.near.org/concepts/basics/accounts/model

As especificações técnicas neste artigo refletem o NEAR Protocol à data da sua redação. O NEAR Protocol encontra-se em desenvolvimento ativo; verifique os valores atuais em docs.near.org antes de confiar em valores numéricos específicos para o desenvolvimento ou planeamento operacional. Este conteúdo serve apenas para fins informativos e não constitui aconselhamento financeiro ou de investimento.