Modelo de Conta NEAR: Nomes, Chaves e Armazenamento

Conteúdo

• O que é a NEAR Protocol?
• TL;DR: Visão Geral do Modelo de Contas da NEAR
• O que é o Modelo de Contas da NEAR?
• Contas Nomeadas e Contas Implícitas: Como a NEAR Identifica os Usuários
• Subcontas: Organização Hierárquica de Contas na NEAR
• Chaves de Acesso NEAR: Acesso Total vs. Permissões de Chamada de Função
• Staking de Armazenamento: Por Que as Contas NEAR Exigem um Saldo Mínimo
• Modelo de Contas da NEAR vs. Ethereum: Uma Comparação Lado a Lado
• Primeiros Passos: Criando e Gerenciando Sua Conta NEAR
• Perguntas Frequentes: Modelo de Contas da NEAR
• Conclusão: O Que o Modelo de Contas da NEAR Significa para Desenvolvedores e Usuários

O Que É o NEAR Protocol? (Uma Breve Introdução)

NEAR Protocol é um blockchain de camada 1, prova de participação (proof-of-stake), construído para acessibilidade de desenvolvedores, com taxas de transação baixas e previsíveis e uma arquitetura de sharding projetada para escalar sem sacrificar a usabilidade. Co-fundado por Illia Polosukhin e Alexander Skidanov, o NEAR Protocol foi projetado desde o início com a experiência do desenvolvedor e a acessibilidade do usuário final como objetivos principais, em vez de adaptar a usabilidade a uma arquitetura construída para outros fins.

O NEAR escala por meio do sharding Nightshade, um mecanismo que distribui o estado das contas e o processamento entre cadeias de processamento paralelo, permitindo que a rede lide com altos volumes de transações sem aumentar as taxas proporcionalmente. O protocolo suporta contratos inteligentes compilados em WebAssembly e mantém os custos de gas baixos por design, em contraste com blockchains onde a volatilidade das taxas cria atrito tanto para desenvolvedores quanto para usuários. O desenvolvimento do ecossistema é supervisionado pela NEAR Foundation, o órgão de governança sem fins lucrativos que operava anteriormente a carteira oficial NEAR Wallet antes da transição para alternativas mantidas pela comunidade.

A expressão mais clara dessa filosofia voltada para desenvolvedores é o modelo de conta da NEAR, um conceito que repensa como a identidade na Blockchain e o gerenciamento de permissões funcionam de raiz.

TL;DR: Visão Geral do Modelo de Conta NEAR

Resumo rápido para leitores que buscam informações essenciais:

• Contas NEAR usam nomes legíveis por humanos (ex: alice.near) em vez de strings de hash criptográfico como os endereços 0x742d35Cc... do Ethereum.
• Cada conta pode ter múltiplas chaves de acesso simultaneamente, cada uma com seu próprio nível de permissão, desde controle irrestrito até interações de contrato com escopo limitado.
• Qualquer conta NEAR pode implantar um smart contract; não há um tipo de conta de contrato separado como no Ethereum.
• Subcontas seguem um namespace hierárquico (ex: contract.myapp.near sob myapp.near), funcionando como subdomínios para contas na blockchain.
• Contas devem manter um saldo mínimo de Token NEAR proporcional ao seu uso de armazenamento na blockchain, um mecanismo chamado storage staking.
• O sistema nativo de permissões multi-chave da NEAR atinge muitos dos objetivos que o Ethereum está construindo com a abstração de contas (EIP-4337), mas através de uma abordagem arquitetural diferente construída desde o início.

O que é o modelo de conta da NEAR?

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

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

Uma conta NEAR contém cinco elementos simultaneamente: um ID de conta exclusivo, um saldo de token NEAR, o estado da conta (armazenamento de dados na blockchain), um Smart Contract opcional implantado e compilado para WebAssembly (WASM, permitindo contratos escritos em Rust ou JavaScript) e uma ou mais chaves de acesso com diferentes níveis de permissão. Essa estrutura unificada significa que não há separação entre "contas de usuário" e "contas de Smart Contract", como ocorre no Ethereum. Qualquer conta NEAR pode, opcionalmente, hospedar um Smart Contract sem se tornar uma categoria diferente de objeto. Contas sem contratos implantados funcionam como contas de usuário comuns; contas com contratos implantados são simultaneamente contas de usuário e hosts de contrato.

O contexto prático para entender por que isso importa é o aplicativo descentralizado (dApp), um aplicativo de software que roda em uma rede blockchain em vez de servidores centralizados. A arquitetura de conta da NEAR foi projetada para tornar as interações de dApp mais seguras e acessíveis do que os modelos de conta blockchain existentes permitem. O sistema de ID de conta é onde essa filosofia de design é mais imediatamente visível, e é aí que o tour pela arquitetura começa.

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

Contas Nomeadas e Contas Implícitas: Como o NEAR Identifica Usuários

NEAR identifica usuários e aplicações na blockchain através de dois formatos de conta: contas nomeadas, que usam 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

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 .testnet na testnet, substituindo as strings de hash criptográfico usadas 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 requer verificação cuidadosa de copiar e colar. Pense em uma conta nomeada NEAR como um endereço de e-mail: legível e associada a uma identidade, em vez de uma string aleatória de caracteres que requer comparação caractere por caractere para verificar.

Contas nomeadas seguem regras de nomenclatura específicas: os IDs de conta são strings alfanuméricas, podem usar 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 vinculada a ela (mais sobre subcontas na próxima seção).

A justificativa de UX por trás das contas nomeadas vai além da estética. Identificadores legíveis reduzem o risco de enviar transações para contas erradas, tornam os endereços de contrato mais fáceis de encontrar e diminuem a sobrecarga cognitiva de gerenciar 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 em vez de uma string hexadecimal de 42 caracteres é concreto em vez de abstrato. Os usuários registram e gerenciam contas nomeadas através da MyNEARWallet em mynearwallet.com, a interface de conta principal mantida pela comunidade (o wallet.near.org original operado pela NEAR Foundation foi descontinuado).

Contas Implícitas: O Formato Alternativo de Conta

Contas implícitas são o segundo formato de conta na NEAR: strings hexadecimais de 64 caracteres em minúsculas derivadas diretamente de uma chave pública, que entram em existência assim que tokens NEAR são enviados para esse ID de conta, sem exigir nenhuma ação de uma conta existente.

A principal distinção prática: uma conta nomeada exige uma conta on-chain existente para patrocinar seu registro via uma transação, ao passo que uma conta implícita passa a existir automaticamente quando os fundos chegam ao ID de conta derivado. Isso torna as contas implícitas úteis em contextos onde a inicialização do zero é necessária ou onde nomes legíveis por humanos são desnecessários. As corretoras de criptomoeda geralmente usam contas implícitas ao creditar depósitos de NEAR aos usuários, gerando um ID de conta exclusivo a partir da chave pública do usuário sem exigir uma conta on-chain pré-existente.

Uma desambiguação que vale a pena declarar abertamente: contas implícitas não são anônimas. Elas são derivadas deterministicamente de uma chave pública e são totalmente transparentes na blockchain. A palavra "implícita" refere-se a como o ID da conta é derivado (da própria chave, sem uma etapa de registro explícita), e não a qualquer propriedade de privacidade.

Contas nomeadas e implícitas estabelecem como o NEAR identifica os participantes na blockchain. Contas também podem conter outras contas sob 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: assim 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 de Blockchain distintas sob o namespace myapp.near.

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

Importante: Uma conta principal não pode acessar os fundos ou o estado de uma subconta após a subconta ser criada. As subcontas são contas totalmente independentes que compartilham apenas um namespace, não sendo subsidiárias controladas por uma conta principal.

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

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

Compreender como as contas são nomeadas e organizadas prepara o cenário para a próxima camada arquitetural: como elas são protegidas e recebem permissões por meio de chaves de acesso.

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

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

Como funciona o sistema de múltiplas chaves da NEAR

Diferente da maioria das contas blockchain, onde uma única chave privada controla tudo, uma conta NEAR pode conter múltiplos pares de chaves independentes, cada um atribuído a um tipo específico de permissão, desde controle irrestrito até interações de contrato com escopo limitado.

As chaves de acesso da NEAR utilizam pares de chaves Ed25519 por padrão (com secp256k1 também suportado para compatibilidade com o conjunto de ferramentas do Ethereum). O sistema de permissões construído sobre esses pares de chaves é o que torna o modelo da NEAR arquitetonicamente distinto. Pense nisso como um chaveiro: uma Chave de Acesso Total é a chave mestra que abre todas as fechaduras; uma Chave de Acesso para Chamada de Função é uma chave criada com um propósito específico que abre apenas uma porta determinada. Cada transação assinada por qualquer chave de acesso em uma 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 a precificação de gás historicamente variável do Ethereum.

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

Chaves de Acesso Total: Controle de Conta Irrestrito

Uma Chave de Acesso Total na NEAR é um par de chaves que pode realizar qualquer ação na conta à qual está vinculada: transferir tokens, implantar contratos inteligentes, criar subcontas, adicionar ou excluir outras chaves e excluir a própria conta.

Como uma Chave de Acesso Total controla toda a conta, ela carrega o mesmo perfil de risco que uma senha mestra. Chaves de Acesso Total nunca devem ser compartilhadas com aplicativos de Terceiros e devem ser mantidas em armazenamento frio (carteira de hardware ou armazenamento offline) para qualquer conta que possua fundos significativos. Se uma Chave de Acesso Total for comprometida, o invasor terá controle total da conta sem nenhum mecanismo de recuperação nativo, a menos que um tenha sido configurado antecipadamente.

A comparação com a Ethereum é instrutiva aqui. Na Ethereum, sua chave privada única para uma Conta de Propriedade Externa (EOA) funciona como uma Chave de Acesso Total: ela controla tudo, e não há uma maneira nativa de conceder a um dApp uma chave com menor permissão para uma interação de contrato específica. Cada conexão de dApp via MetaMask expõe sua chave de conta completa 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 projetada para resolver na Ethereum. Na NEAR, a solução foi integrada ao modelo de conta base.

Chaves de Acesso de Chamada de Função: Permissões com Escopo para Segurança de dApps

Uma Chave de Acesso de Chamada de Função é uma chave restrita que só pode invocar métodos especificados em um único smart contract designado, com um limite opcional de subsídio de gás que restringe o gasto total com taxas.

Onde uma Chave de Acesso Completo é irrestrita, uma Chave de Acesso para Chamada de Função é rigorosamente limitada. A chave especifica: um ID de conta de contrato que ela tem permissão para chamar, quais métodos nesse contrato ela pode invocar (ou todos os métodos públicos, se não houver restrições adicionais), e uma permissão opcional de Token NEAR que limita quanto gás a chave pode gastar antes que precise de recarga. Uma vez que a permissão for esgotada, a chave não poderá assinar mais transações até que seja reabastecida ou substituída.

O caso de uso de autenticação baseada em sessão é onde as Chaves de Acesso de Chamada de Função mostram seu valor prático para o desenvolvimento de dApps. Quando você conecta um dApp à sua conta NEAR, o dApp solicita uma Chave de Acesso de Chamada de Função com escopo para seu próprio contrato. Esta chave é armazenada na sua sessão do navegador. A partir desse momento, o dApp pode enviar transações em seu nome (aprovando uma Trade, mintando um NFT, interagindo com um contrato de jogo) sem solicitar que você assine cada ação individual. Sua Chave de Acesso Completo nunca sai da sua carteira segura. Se o dApp for comprometido ou malicioso, o dano é limitado: o atacante só pode chamar os métodos de contrato específicos para os quais a chave foi definida, e apenas até o valor da permissão. Uma Chave de Acesso de Chamada de Função funciona como um token de sessão em um aplicativo web: ela concede acesso temporário e com escopo a ações específicas sem expor as credenciais completas da conta.

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

Armazenamento Staking: Por que as contas NEAR exigem um saldo mínimo

Staking de armazenamento no NEAR é o mecanismo pelo qual toda 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: NEAR aloca armazenamento on-chain medido em bytes. Para cada byte de estado armazenado em uma conta (registros de saldo, código de contrato, dados armazenados, chaves de acesso), uma quantidade correspondente de tokens NEAR deve ser mantida no saldo da conta. Esses tokens não são gastos nem destruídos; eles são reservados como um saldo bloqueado em relação à pegada de armazenamento. Se você reduzir o armazenamento da sua conta excluindo estado ou dados de contrato, os tokens correspondentes serão desbloqueados e retornados ao seu saldo disponível. O Staking de armazenamento funciona como um depósito de segurança reembolsável: você bloqueia uma quantidade proporcional de tokens NEAR para o armazenamento que sua conta utiliza, e você recebe esses tokens de volta se reduzir sua pegada de armazenamento.

O propósito deste design é econômico: ele evita o inchaço do estado, garantindo que a parte que se beneficia do armazenamento na blockchain arque com 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 Token NEAR por 10 KB de armazenamento na blockchain, e uma conta NEAR recém-criada e vazia requer um saldo mínimo de aproximadamente 0,00182 NEAR para cobrir sua pegada de estado base. Verifique os números atuais em relação à documentação de staking de armazenamento NEAR em docs.near.org/concepts/storage/storage-staking antes de confiar nesses números para o planejamento de desenvolvimento, pois os parâmetros do protocolo mudam com as atualizações.

Para desenvolvedores de smart contract, a implicação de storage staking exige planejamento 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 armazena dados significativos (registros de usuários, saldos de Token, votos de governança), a conta que hospeda esse contrato deve manter um saldo grande o suficiente para cobrir tanto o código do contrato quanto o estado acumulado. Este é um requisito de capital que escala com o uso da aplicação e precisa ser considerado em seu modelo econômico antes da implementação.

O Staking de armazenamento cria um requisito real de bloqueio de capital. Alguns desenvolvedores consideram isso limitante em comparação com redes que não exigem saldos de armazenamento reservados. O Trade-off é deliberado: a restrição evita que o estado da rede cresça sem limites, e os tokens são recuperáveis. No entanto, a restrição é real e deve ser planejada, em vez de ser descoberta após a implantação.

Staking de armazenamento vs. staking de validador: Estes são dois mecanismos distintos na NEAR. Staking de armazenamento trava tokens NEAR contra a pegada de dados na blockchain da sua conta; esses tokens funcionam como um saldo reservado proporcional ao armazenamento utilizado. Staking de validador trava tokens NEAR contra o mecanismo de consenso, onde validadores investem em staking tokens para participar da produção de blocos e ganhar recompensas de staking. Este artigo cobre apenas o staking de armazenamento. Não confunda esses dois usos da palavra "staking".

As taxas de Gas (custos de execução de transação) são separadas do storage staking. As taxas de Gas são consumidas por transação e pagas em tokens NEAR no momento da assinatura; o storage staking é um saldo reservado que permanece com a conta enquanto o estado associado existir.

Entender o staking de armazenamento completa o panorama de como as contas NEAR funcionam isoladamente. A próxima pergunta é como essa arquitetura se compara à do Ethereum.

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

NEAR e Ethereum adotam abordagens fundamentalmente diferentes para a arquitetura de contas on-chain, e as diferenças têm consequências significativas na forma como os desenvolvedores constroem aplicações descentralizadas e como os usuários gerenciam suas identidades na blockchain.

O Sistema de Duas Contas da Ethereum vs. O Modelo de Conta Unificada da NEAR

A tabela abaixo contrasta os dois modelos de conta em oito dimensões arquitetônicas. A diferença mais significativa é que o Ethereum separa as contas de usuário (Contas de Propriedade Externa, ou EOAs) das contas de Smart Contract em dois tipos distintos, enquanto a NEAR utiliza um único tipo de conta unificado para ambos.

A separação entre EOA e Conta de Contrato do Ethereum cria fricção na prática. A maioria das interações com dApps exige que uma EOA chame uma Conta de Contrato, o que significa que os usuários devem gerenciar ambos os tipos como entidades distintas. Uma EOA é controlada por uma única chave privada, sem uma forma nativa de definir o escopo das permissões: qualquer dApp conectado a uma conta MetaMask pode solicitar assinaturas que expõem a chave completa da conta ao fluxo da transação. O modelo do Ethereum possui uma lógica de design clara e atendeu bem aos seus objetivos originais, mas a limitação de chave única tornou-se evidente à medida que as interações com dApps tornaram-se mais frequentes e variadas.

O tipo de conta unificada da NEAR elimina a separação entre Conta Externa (EOA) e contrato. Cada conta NEAR é potencialmente um host de contrato, e o sistema multi-chave com Chaves de Acesso para Chamadas de Função (Function Call Access Keys) aborda a limitação de chave única sem exigir uma camada de protocolo separada. Tanto a NEAR quanto a Ethereum operam no paradigma baseado em contas, em contraste com o modelo UTXO do Bitcoin, onde os saldos são rastreados como saídas de transação não gastas (UTXOs) em vez de estado da conta; a diferença entre NEAR e Ethereum reside em como essas contas são estruturadas e autorizadas, 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) é o esforço da Ethereum para conferir aos EOAs o tipo de permissão programável e capacidades de chave de sessão que o modelo de conta da NEAR foi projetado para incluir desde o início.

EIP-4337 é um padrão 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. Ele requer infraestrutura específica de bundler para operar e está ativamente implantado em todo o ecossistema Ethereum, embora não seja uma atualização universal aplicada a todas as contas automaticamente.

O paralelo com as Function Call Access Keys da NEAR é real: ambas as abordagens resolvem o problema de conceder às dApps acesso com escopo e permissão limitada para interações específicas, sem expor a chave de conta completa. Um desenvolvedor familiarizado com as chaves de sessão do EIP-4337 achará as Function Call Access Keys da 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 da NEAR é nativo do protocolo base; o EIP-4337 adiciona camadas de lógica de carteira de Smart Contract sobre o modelo EOA existente do Ethereum. Os problemas que eles abordam se sobrepõem significativamente; os mecanismos diferem. Para a especificação completa do EIP-4337, veja a especificação de abstração de conta do EIP-4337 em eips.ethereum.org/EIPS/eip-4337.

Para desenvolvedores Ethereum que avaliam a NEAR, vale a pena notar duas pontes do ecossistema. Aurora em aurora.dev, um ambiente compatível com EVM construído na NEAR, permite que desenvolvedores Ethereum implementem contratos Solidity na infraestrutura NEAR, enquanto as contas NEAR servem como a camada de identidade subjacente. Desenvolvedores que trabalham em ambos os ecossistemas podem usar a 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, vejamos o que a criação e o gerenciamento de uma conta NEAR realmente envolvem na prática.

Primeiros passos: Criando e gerenciando sua conta NEAR

Você pode criar sua primeira conta NEAR por meio da MyNEARWallet em mynearwallet.com, a principal interface mantida pela comunidade para o registro de contas NEAR e gerenciamento de chaves. Verifique a recomendação atual da carteira oficial no momento em que ler isto, pois o ecossistema da carteira NEAR continua evoluindo; outros aplicativos de carteira compatíveis existem paralelamente à MyNEARWallet.

Se você está vindo do Ethereum e da MetaMask, vale a pena entender a diferença conceitual antes de começar. Uma carteira MetaMask é principalmente um gerenciador de chaves e um assinante de transações para EOAs do Ethereum: ela armazena sua chave privada e a apresenta aos dApps para assinatura de transações. Uma conta NEAR é uma identidade on-chain completa com um nome legível, armazenamento de estado na blockchain, permissões de chaves programáveis e hospedagem opcional de contratos. O aplicativo da carteira (MyNEARWallet) é a interface; a conta NEAR é o objeto on-chain. Essas são coisas diferentes, e a distinção é importante para a forma como você pensa sobre o gerenciamento de chaves.

Criar uma conta NEAR exige um pequeno saldo inicial de tokens NEAR para cobrir o requisito de staking de armazenamento base (aproximadamente 0.00182 NEAR para uma conta vazia, conforme abordado na seção Armazenamento Staking acima). Este saldo inicial cobre o espaço base do estado de uma nova conta.

Três riscos são importantes de conhecer antes de começar. Primeiro, se você perder sua Chave de Acesso Completa sem nenhum mecanismo de recuperação configurado, a conta é irrecuperável. Armazene sua Chave de Acesso Completa em armazenamento a frio e configure quaisquer opções de recuperação disponíveis antes de precisar delas. Segundo, os tokens NEAR reservados para staking de armazenamento ficam bloqueados enquanto o estado associado existir; este é um compromisso de capital, não uma taxa. Terceiro, a exclusão de conta na NEAR é irreversível. Para um guia completo passo a passo de criação de conta, consulte a documentação do desenvolvedor NEAR em docs.near.org/concepts/basics/accounts/model (https://docs.near.org/concepts/basics/accounts/model).

As perguntas mais frequentes 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 da NEAR, com referências cruzadas para as seções relevantes acima para os leitores que desejam uma cobertura completa.

Qualquer conta NEAR pode implantar um Smart Contract?

Sim. No NEAR, qualquer conta pode opcionalmente implantar um Smart Contract compilado para WebAssembly (WASM). Não existe um tipo de conta de contrato separado, diferente do Ethereum, onde a implantação de um contrato exige a criação de uma Conta de Contrato distinta. Uma conta sem um contrato implantado funciona como uma conta de usuário padrão; uma conta com um contrato implantado funciona como ambas simultaneamente. Veja a Seção O Que É o Modelo de Conta NEAR acima para a explicação arquitetônica completa.

Como as chaves de acesso NEAR tornam os dApps mais seguros de usar?

As Chaves de Acesso de Chamada de Função restringem um dApp a métodos de contrato específicos com um limite opcional de cota de gás. Quando você se conecta a um dApp usando uma Chave de Acesso de Chamada de Função restrita ao contrato desse dApp, sua Chave de Acesso Total (e o saldo total da sua conta) nunca é exposta ao aplicativo de Terceiros. Se o dApp for comprometido, o dano é limitado à cota e ao contrato especificado. Consulte a seção de Chaves de Acesso da NEAR para obter o detalhamento completo.

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

A perda da Chave de Acesso Completo sem um mecanismo de recuperação pré-configurado torna a conta permanentemente irrecuperável. Você não pode redefinir ou recuperar uma Chave de Acesso Completo da mesma forma que redefine uma senha, pois não há uma autoridade central que controle a conta. Sempre armazene as Chaves de Acesso Completo em armazenamento frio seguro e configure quaisquer opções de recuperação de conta disponíveis através do seu aplicativo de carteira antes de precisar delas. Algumas carteiras oferecem configurações de recuperação social ou recuperação multi-chave.

As taxas de gás são as mesmas que Staking de armazenamento?

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; elas 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. Veja a seção Armazenamento Staking para a explicação completa.

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

O sistema de permissões multichave nativo da NEAR alcança muitos dos objetivos que o EIP-4337 foi projetado para adicionar à Ethereum, incluindo permissões baseadas em sessões com escopo para interações de dApps e lógica de chaves programável. Os dois são implementações arquitetonicamente distintas de ideias que se sobrepõem: a abordagem da NEAR é nativa do protocolo base, enquanto o EIP-4337 sobrepõe a lógica de carteira de Smart Contract ao modelo EOA existente da Ethereum. Eles resolvem problemas semelhantes por meio de arquiteturas diferentes. Veja a seçã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?

Contas nomeadas são identificadores legíveis por humanos (por exemplo, alice.near) registradas por meio de uma transação de uma conta existente, terminando em .near na Mainnet e .testnet na testnet. Contas implícitas são strings hexadecimais de 64 caracteres derivadas diretamente de uma Chave pública, que passam a existir automaticamente quando tokens NEAR são enviados para esse ID de conta, sem a necessidade de uma transação de registro. Consulte a seção Contas Nomeadas e Contas Implícitas para ver a tabela de comparação completa.

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

Uma conta NEAR pode conter múltiplas chaves de acesso simultaneamente, com cada chave atribuída ao seu próprio tipo de permissão (Chave de Acesso Total ou Chave de Acesso de Chamada de Função) e, para Chaves de Acesso de Chamada de Função, seu próprio escopo de contrato e limite de gas. Não há um limite rígido documentado para o número de chaves por conta. Essa capacidade de múltiplas chaves é o que diferencia o modelo de permissão da NEAR da abordagem de chave única por EOA da Ethereum. Veja a seção de Chaves de Acesso da NEAR para mais detalhes.

O storage staking significa que eu perco meus tokens NEAR?

Não. Os tokens NEAR reservados para staking de armazenamento são bloqueados, mas não gastos. Eles permanecem em sua conta como um saldo reservado e são liberados de volta ao seu saldo disponível se você reduzir a pegada de dados na blockchain da sua conta ao excluir o estado. Os tokens são um depósito pelo uso de armazenamento, não uma taxa. Consulte a seção de Staking de armazenamento para conhecer o mecanismo e os valores atuais.

Conclusão: O que o modelo de conta NEAR significa para desenvolvedores e usuários

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ão de múltiplas chaves reduz o risco de segurança para interações de dApps, limitando o acesso de Terceiros sem expor as chaves mestras; o Staking de armazenamento cria 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 de saldo mínimo de staking de armazenamento é uma restrição real a ser planejada, não uma mera nota de rodapé. Se a sua aplicação armazena um estado significativo na blockchain, o requisito de saldo reservado escala proporcionalmente a esse estado. Planeje o orçamento para isso no modelo econômico da sua aplicação antes da implantação, não depois.

Próximos passos por persona:

• Desenvolvedores: Comece a construir no NEAR Protocol em docs.near.org/develop
• Usuários: Crie sua conta NEAR em MyNEARWallet em mynearwallet.com
• Pesquisadores: Mergulhe profundamente na especificação completa do modelo de conta na documentação do modelo de conta do NEAR Protocol em docs.near.org/concepts/basics/accounts/model

As especificações técnicas contidas neste artigo refletem o NEAR Protocol no momento da redação. O NEAR Protocol é desenvolvido ativamente; verifique os valores atuais em docs.near.org antes de confiar em valores numéricos específicos para desenvolvimento ou planejamento operacional. Este conteúdo é apenas para fins informativos e não constitui aconselhamento financeiro ou de investimento.