Modelo de Conta NEAR Explicado: Chaves e Armazenamento

O Modelo de Conta NEAR é o sistema em nível de protocolo do NEAR Protocol para gerenciamento de identidade e permissões de contas, juntamente com o estado na blockchain. Cada conta na NEAR possui um ID de conta legível por humanos, pode conter várias chaves de acesso com escopos de permissão diferentes e pode armazenar simultaneamente um saldo de Token e um Smart Contract implantado. As blockchains gerenciam valor e identidade por meio de diferentes sistemas (o Bitcoin usa um modelo de Saída de Transação Não Gasta, ou UTXO, enquanto o Ethereum e a NEAR usam um modelo baseado em contas onde cada conta detém o estado diretamente), e o design baseado em contas da NEAR é o que torna possível a arquitetura abordada aqui.

O NEAR Protocol é uma blockchain de Camada 1 proof-of-stake (PoS) que lançou sua Mainnet em 2020. Foi criado pela NEAR Inc. (que agora opera como Pagoda), uma organização de ferramentas para desenvolvedores que continua a manter o SDK da NEAR e a infraestrutura principal do protocolo. O NEAR Protocol utiliza o sharding Nightshade para particionar a rede em shards paralelos, e os IDs de conta desempenham um papel na atribuição de shards, o que é relevante para desenvolvedores ao considerar padrões de chamadas entre contratos.

Quatro propriedades diferenciam o Modelo de Conta NEAR de outros sistemas de contas de camada 1:

• IDs de conta são strings legíveis por humanos, não sequências hexadecimais aleatórias
• Uma única conta pode conter um número ilimitado de chaves de acesso, cada uma com seu próprio escopo de permissão
• Qualquer conta pode conter tanto um saldo de Token quanto um Smart Contract implantado, sem distinção arquitetônica entre "contas de usuário" e "contas de contrato"
• As contas devem manter um saldo de Token NEAR proporcional ao seu uso de armazenamento na blockchain, um mecanismo chamado storage staking

Este artigo aborda cada um desses componentes em sequência: tipos de ID de conta, tipos de chave de acesso, staking de armazenamento, subcontas, a comparação arquitetônica com a Ethereum e um exemplo prático detalhado.

Pule para uma seção:

• IDs de Conta NEAR: Contas Nomeadas e Contas Implícitas
• Chaves de Acesso NEAR: Como Funcionam as Permissões de Conta
• Armazenamento Staking: Como a NEAR Vincula o Saldo de Token ao Armazenamento na blockchain
• Subcontas NEAR: Namespaces Hierárquicos de Contas
• Modelo de Conta NEAR vs. Ethereum: Principais Diferenças Arquitetônicas
• O Que a Arquitetura de Conta Unificada da NEAR Significa na Prática
• Perguntas Frequentes Sobre o Modelo de Conta NEAR
• Principais Conclusões e Próximos Passos

IDs de Conta NEAR: Contas Nomeadas e Contas Implícitas

Toda conta NEAR é identificada por um ID de conta exclusivo. Ao contrário da Ethereum, onde as contas são identificadas por um endereço hexadecimal de 42 caracteres derivado de uma Chave pública, os IDs de conta NEAR apresentam-se em duas formas estruturalmente distintas: contas nomeadas e contas implícitas. Compreender a diferença entre elas é a base para trabalhar com o sistema de contas da NEAR.

Contas Nomeadas: Identificadores Legíveis por Humanos

Uma conta nomeada é um ID de conta legível por humanos registrado sob um domínio de nível superior: .near na mainnet, .testnet na rede de testes. Contas nomeadas funcionam como nomes de usuário da internet ou nomes de domínio: são únicas, escolhidas pelo registrador e fáceis de compartilhar e lembrar. Exemplos incluem alice.near, myprotocol.near e nft.myprotocol.near. Diferente de um nome de usuário, uma conta nomeada é um objeto em nível de protocolo que possui um NEAR token balance, pode ter um Smart Contract implantado nela e controla chaves de acesso criptográficas.

O registro de uma conta nomeada requer um pequeno depósito de Token NEAR. Para criar uma, visite uma interface de carteira compatível com NEAR, como MyNEARWallet ou Meteor Wallet, escolha seu ID de conta e financie o depósito de registro. Contas nomeadas também podem criar subcontas dentro de seu namespace (por exemplo, alice.near pode criar app.alice.near), um tópico abordado integralmente na seção de subcontas abaixo.

Contas nomeadas são uma funcionalidade nativa do protocolo integrada diretamente ao modelo de contas do NEAR Protocol. Elas não são um serviço de nomenclatura externo adicionado sobre o protocolo, que é como o Ethereum Name Service (ENS) funciona no Ethereum. ENS é um sistema de smart contract separado; contas nomeadas NEAR são uma parte de primeira classe do próprio protocolo.

Contas Implícitas: Derivadas de Chaves Públicas

Uma conta implícita é um ID de conta hexadecimal de 64 caracteres derivado deterministicamente de uma chave pública Ed25519. Um exemplo de ID de conta implícita é: 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Para desenvolvedores vindos do Ethereum, este é o tipo de conta com a estrutura mais familiar, pois o processo de derivação é análogo a como os endereços do Ethereum são calculados a partir de chaves públicas.

A mecânica de criação de contas implícitas difere das contas nomeadas em um aspecto fundamental: nenhuma transação de registro é necessária. Uma conta implícita torna-se ativa no momento em que alguém envia tokens NEAR para o seu ID de conta. Isso torna as contas implícitas ideais para a criação programática de contas, endereços de depósito em exchanges e cenários onde a legibilidade humana não é uma prioridade.

O descritor "implícito" refere-se ao mecanismo de criação, não ao anonimato. As contas implícitas são totalmente de propriedade e controladas pelo detentor da chave privada da qual o ID da conta foi derivado. Mais uma distinção: um ID de conta implícita é derivado de uma chave pública, mas não é idêntico à própria chave pública. O ID da conta é uma representação hex em letras minúsculas dos bytes brutos da chave pública. Desenvolvedores Ethereum familiarizados com a derivação de endereços reconhecerão o padrão, mas não devem presumir que as duas representações sejam as mesmas.

Contas Nomeadas vs. Implícitas: Uma Comparação Lado a Lado

Os dois tipos de ID de conta se distinguem por cinco dimensões:

Contas nomeadas (Named accounts) são adequadas para carteiras de usuários e implantações de protocolo onde a legibilidade é importante. Contas implícitas (Implicit accounts) são adequadas para corretoras, ferramentas programáticas e cenários onde as contas são criadas em massa sem interação do usuário.

Chaves de Acesso NEAR: Como Funcionam as Permissões de Conta

As chaves de acesso NEAR são a camada de autorização do modelo de conta. Cada conta NEAR pode conter várias chaves de acesso simultaneamente, e cada chave possui um escopo de permissão distinto. Uma conta NEAR pode conter um número ilimitado de chaves de acesso ao mesmo tempo. Cada chave é um par de chaves criptográficas Ed25519 independente, e você pode adicionar ou remover chaves sem criar uma nova conta. As chaves são adicionadas por meio de uma transação assinada por uma Chave de Acesso Total existente, usando a CLI da NEAR (near add-key) ou programaticamente por meio do SDK.

Isso difere do Ethereum, onde uma única chave privada controla cada endereço. O design de múltiplas chaves da NEAR permite um controle de permissão mais granular sem comprometer a continuidade da conta. A NEAR suporta dois tipos de chave: Chaves de Acesso Completo e Chaves de Acesso a Chamada de Função. Consulte a documentação do NEAR Protocol sobre chaves de acesso) para a especificação técnica completa.

Chaves de Acesso Completo: Credenciais Mestre

Uma Chave de Acesso Total é uma chave de acesso com permissões irrestritas sobre uma conta. Ela pode autorizar transferências de Token, a implantação de Smart Contract, a adição ou remoção de outras chaves e a exclusão da conta. Pense em uma Chave de Acesso Total como uma chave mestra da sua casa: ela abre todas as portas. Diferente de uma chave de casa, uma Chave de Acesso Total é um par de chaves criptográficas que assina transações na Blockchain NEAR, portanto, as mesmas práticas de segurança se aplicam. Armazene-a em uma hardware wallet ou offline, pelos mesmos motivos que os usuários de Ethereum protegem suas seed phrases.

Uma conta NEAR pode ter várias Chaves de Acesso Total. Uma por dispositivo é um padrão comum, com cada chave possuindo o mesmo nível de permissão total. Este é um ponto arquitetônico importante: não existe uma única "chave privada mestre" da maneira que as contas Ethereum possuem. Múltiplas Chaves de Acesso Total podem coexistir simultaneamente em uma única conta.

Nota do Desenvolvedor: Uma Chave de Acesso de Chamada de Função comprometida não concede permissões de Chave de Acesso Total. Os escopos de permissão são arquiteturalmente separados no nível do protocolo. A revogação de uma Chave de Acesso de Chamada de Função não afeta nenhuma Chave de Acesso Total na mesma conta, e vice-versa.

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

Uma Function Call Access Key (Chave de Acesso para Chamada de Função) é uma chave de acesso com escopo definido que pode chamar apenas métodos específicos em um contrato específico, com uma permissão opcional de Token NEAR que limita a quantidade de gás que a chave pode gastar. Pense nela como um token de sessão ou uma permissão OAuth com escopo: ela concede a um aplicativo específico o direito de realizar ações específicas em seu nome, sem dar acesso total à sua conta. Ao contrário de um token OAuth, uma Function Call Access Key é um par de chaves criptográficas armazenado na blockchain, e seus limites de permissão são aplicados no nível do protocolo, não pelo aplicativo.

Quando você conecta sua conta NEAR a um aplicativo descentralizado (dApp) e aprova uma Chave de Acesso de Chamada de Função, o dApp pode enviar certas transações automaticamente sem acionar um pop-up de confirmação da carteira para cada uma. Isso permite uma experiência do usuário (UX) baseada em sessão em jogos, protocolos DeFi e aplicativos sociais. No Ethereum, cada uma dessas interações exigiria uma confirmação separada da MetaMask. No NEAR, o usuário aprova a chave uma vez, e o dApp opera dentro desse escopo durante a sessão.

As Chaves de Acesso para Chamada de Função (Function Call Access Keys) podem carregar uma permissão opcional de NEAR Token, que limita o gás total que a chave tem permissão para gastar. Assim que essa permissão for esgotada, a chave não poderá mais enviar transações até que o usuário a recarregue ou emita uma nova chave.

Equívoco Comum: Conceder uma Chave de Acesso de Chamada de Função a um dApp não dá ao dApp o controle da sua conta. A chave é restrita estritamente a métodos de contrato definidos e a um limite de gas. Ela não pode transferir seu saldo de token NEAR, não pode implantar contratos e não pode adicionar ou remover outras chaves da sua conta.

Nota do Desenvolvedor: As Chaves de Acesso para Chamada de Função permitem padrões de chave de sessão em dApps. Um usuário pode autorizar uma chave para uma sessão de jogo ou uma sessão de negociação DeFi, e o aplicativo opera dentro desse escopo sem exigir aprovações por transação. Esta é uma das diferenças de UX (Experiência do Usuário) mais relevantes para desenvolvedores entre construir no NEAR e no Ethereum.

Chave de Acesso Completa vs. Chave de Acesso para Chamada de Função: Principais Diferenças

As Chaves de Acesso Total e as Chaves de Acesso para Chamada de Função diferem em seis dimensões:

As Chaves de Acesso Total pertencem ao proprietário da conta e devem ser mantidas offline ou em hardware. As Chaves de Acesso de Chamada de Função são emitidas para aplicativos e podem ser revogadas pelo proprietário da conta a qualquer momento.

Armazenamento Staking: Como NEAR Relaciona o Saldo Token ao Armazenamento Na blockchain

O staking de armazenamento é um componente da arquitetura de conta da NEAR que a maioria dos recursos educacionais de blockchain ignora, mas possui implicações práticas diretas para cada desenvolvedor que constrói na NEAR e para cada usuário que gerencia uma conta.

Por que a NEAR exige um saldo de Token para armazenamento

Definição: Storage staking (também chamado de state staking em algumas documentações da NEAR) é o requisito para que as contas da NEAR mantenham um saldo de Token NEAR proporcional à quantidade de dados on-chain que elas armazenam. Esse saldo bloqueado atua como um depósito reembolsável, não como uma taxa.

O Staking de armazenamento funciona como um depósito de segurança em um apartamento. Seus tokens NEAR são bloqueados proporcionalmente ao armazenamento que você ocupa e são devolvidos quando você exclui os dados armazenados. Ao contrário de um pagamento de aluguel, os tokens não são transferidos para ninguém; eles permanecem em sua conta, apenas reservados em relação ao armazenamento que você possui.

Uma distinção que vale a pena esclarecer: o storage staking não é o mesmo que o staking de validador. Ambos os mecanismos bloqueiam tokens NEAR, mas servem a propósitos completamente diferentes. O staking de validador bloqueia tokens para participar da produção de blocos e ganhar recompensas de consenso. O storage staking bloqueia tokens proporcionalmente ao uso de armazenamento na blockchain para evitar o inchaço do estado e alinhar o custo de armazenamento com as entidades que o consomem. São saldos bloqueados separados com propósitos distintos.

O staking de armazenamento também é separado das taxas de gás. As taxas de gás são custos de execução por transação pagos em tokens NEAR e queimados após cada transação. O staking de armazenamento é um requisito de saldo contínuo vinculado à quantidade de dados que uma conta mantém, e não ao número de transações que ela envia.

Staking de armazenamento na prática: o que isso significa para contas e contratos

O Staking de armazenamento afeta as contas em três níveis:

• Criação de conta: Requer um saldo mínimo de token NEAR. A taxa atual é de aproximadamente 0.00182 NEAR por byte de estado (verifique as taxas atuais na documentação oficial de staking de armazenamento NEAR) antes de tomar decisões de desenvolvimento, pois a governança do protocolo pode ajustar este valor).
• Implantação de contrato: Requer um depósito proporcionalmente maior com base no tamanho do contrato compilado. O bytecode WASM do contrato é armazenado na blockchain como parte do estado da conta, e o depósito de armazenamento escala com esse tamanho.
• Dados do estado do contrato: Dados armazenados no estado do contrato (como saldos de usuários em um contrato de token ou estado de jogo em um jogo on-chain) requerem um saldo contínuo mantido por quem controla a conta do contrato.

Se o saldo de uma conta NEAR cair abaixo do seu requisito de armazenamento, a conta não poderá enviar transações de saída até que o saldo seja reabastecido. A conta não é excluída e seus dados não são perdidos; ela simplesmente se torna inativa para transações de saída até que tokens NEAR suficientes sejam depositados.

Nota do Desenvolvedor: Decida cedo se seu aplicativo irá cobrir o depósito de armazenamento para usuários durante o onboarding ou exigir que os usuários mantenham seu próprio saldo. Muitos protocolos absorvem os custos de armazenamento para reduzir o atrito. Esta é uma decisão real de economia de onboarding que afeta a aquisição de usuários, portanto, considere-a no modelo de custo do seu dApp antes do lançamento.

Subcontas NEAR: Namespaces Hierárquicos de Contas

Uma subconta NEAR é uma conta cujo ID é prefixado pelo ID de uma conta pai. Por exemplo, app.alice.near é uma subconta de alice.near, e apenas alice.near pode criar contas nesse namespace.

Um detalhe importante para ser preciso: após a criação de uma subconta, a conta principal NÃO a controla. A subconta é totalmente independente: ela possui suas próprias chaves de acesso, seu próprio saldo de Token NEAR e seu próprio estado na blockchain. A única autoridade especial da conta principal é a capacidade de criar subcontas em seu namespace. Além desse ato de criação, as duas contas não possuem nenhuma relação de controle contínuo.

A hierarquia de nomes é semelhante a domínios e subdomínios da web. alice.near é como um domínio, e app.alice.near é como um subdomínio. Assim como registrar um domínio não lhe confere controle contínuo sobre o conteúdo hospedado em seus subdomínios, criar uma subconta não dá à conta pai autoridade sobre como essa subconta será usada posteriormente.

Um padrão de uso típico para equipes de protocolo se parece com este:

myprotocol.near → token.myprotocol.near → staking.myprotocol.near → dao.myprotocol.near

Cada subconta é controlada de forma independente após a criação. Cada uma possui suas próprias chaves de acesso, mantém seu próprio saldo e pode ter um Smart Contract separado implantado nela. A criação é iniciada pela conta pai, seja por meio do NEAR CLI ou programaticamente via uma chamada de contrato. Após essa transação, o controle passa inteiramente para quem possuir as chaves de acesso da nova subconta.

Equívoco Comum: A conta pai não governa as subcontas após a criação. As subcontas são contas totalmente autônomas em nível de protocolo. A convenção de nomenclatura reflete quem as criou, não quem as controla.

Nota do Desenvolvedor: Sub-accounts são um padrão comum para arquitetura de protocolos modulares. A implantação de contratos separados em sub-accounts distintas oferece a cada módulo um gerenciamento independente de chaves de acesso, caminhos de atualização independentes e uma isolação de permissões mais limpa. Muitos protocolos NEAR em produção utilizam esse padrão para contratos de Token, módulos de governança e lógica de Staking.

--- ## Modelo de Conta NEAR vs. Ethereum: Principais Diferenças Arquiteturais

O Modelo de Conta da NEAR e o modelo de conta da Ethereum adotam abordagens arquiteturais diferentes para os mesmos problemas: como identificar contas, como autorizar transações e como implantar contratos inteligentes. Para desenvolvedores que avaliam a NEAR como uma Plataforma de construção, compreender essas diferenças é um pré-requisito para tomar decisões de arquitetura fundamentadas.

O Ethereum separa as contas em dois tipos: Contas Externamente Controladas (EOAs) e Contas de Contrato. Uma EOA é controlada por uma única Chave privada e não pode conter código implantado. Uma Conta de Contrato é controlada por código e não possui Chave privada. Essa separação significa que, se você deseja que um endereço Ethereum armazene ETH e execute a lógica de um Smart Contract, precisará de dois objetos de conta distintos trabalhando juntos.

A NEAR utiliza um modelo unificado. Qualquer conta NEAR pode manter um saldo de tokens e ter um Smart Contract implantado nela simultaneamente. Não existe um tipo de "conta de contrato" separado. A conta alice.near pode conter tokens NEAR, executar um contrato WASM implantado e manter múltiplas chaves de acesso com diferentes escopos de permissão, tudo como um único objeto de protocolo. Qualquer conta NEAR pode conter um Smart Contract, um saldo de tokens e múltiplas chaves de acesso ao mesmo tempo.

As contas Ethereum são cada uma controlada por uma chave privada. As contas NEAR suportam múltiplas chaves de acesso com escopos de permissão diferentes, permitindo padrões como chaves de sessão e gerenciamento de chaves multi-dispositivo que o modelo de conta do Ethereum não suporta nativamente no nível do protocolo.

Nota: Smart Contracts compatíveis com Ethereum podem ser executados na NEAR via Aurora, uma camada de compatibilidade EVM implementada como um Smart Contract na NEAR. O Aurora é uma camada separada; o desenvolvimento nativo na NEAR utiliza WebAssembly (WASM) compilado a partir de Rust ou JavaScript, não Solidity. Consulte a documentação do modelo de conta Ethereum) para a especificação completa da conta Ethereum.

O que a Arquitetura de Conta Unificada da NEAR Significa na Prática

Os componentes do Modelo de Conta da NEAR (IDs de conta, chaves de acesso, storage staking e subcontas) formam um sistema unificado que produz diferenças concretas na forma como os aplicativos se comportam e em como os usuários os experienciam.

Considere uma única conta NEAR, alice.near. A conta da Alice pode simultaneamente:

1. Manter um saldo de token NEAR
2. Ter um Smart Contract implantado nele, compilado para WebAssembly (WASM) a partir de Rust
3. Possuir três chaves de acesso: uma Chave de Acesso Total armazenada em sua carteira de hardware, uma Chave de Acesso Total em seu laptop e uma Chave de Acesso por Chamada de Função concedida a um dApp DeFi para negociação baseada em sessão
4. Possuir duas subcontas (app.alice.near para um contrato de jogo implantado e vault.alice.near para um contrato de investimento), cada uma controlada independentemente

O ID da conta da Alice é legível e compartilhável. Ela nunca copia uma string hexadecimal de 42 caracteres para receber tokens ou interagir com um contrato.

Para desenvolvedores, as implicações práticas são substanciais. Os padrões de chaves de sessão eliminam o atrito da carteira por transação em jogos e aplicativos sociais. A arquitetura de subcontas permite que as equipes de protocolo implementem contratos modulares com caminhos de atualização independentes. O Staking de armazenamento cria um modelo de custo previsível para dados na blockchain que deve ser considerado na economia de integração. As contas também podem interagir com a Rainbow Bridge para transferir ativos entre a NEAR e a Ethereum, e são gerenciadas por meio de interfaces de carteiras compatíveis com a NEAR, como MyNEARWallet ou Meteor Wallet.

Para usuários finais, o modelo de conta se traduz em IDs de conta legíveis que funcionam como nomes de usuário, sessões de dApp que não interrompem a experiência com pop-ups de carteira e um modelo de rotação de chaves que permite a recuperação da conta sem depender de uma única frase de recuperação.

Perguntas frequentes sobre o modelo de conta da NEAR

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

Contas nomeadas são identificadores legíveis por humanos (como alice.near) registrados sob um domínio de nível superior, exigem um pequeno depósito de token NEAR no momento do registro e são escolhidos pelo usuário. Contas implícitas são IDs hexadecimais de 64 caracteres derivados de uma chave pública Ed25519, não exigem registro e ativam automaticamente quando tokens NEAR são enviados para o ID da conta. Contas nomeadas são típicas para carteiras de usuário e implementações de protocolo; contas implícitas são comuns para exchanges e ferramentas programáticas. Veja a tabela de comparação de contas nomeadas vs. implícitas acima para uma análise completa lado a lado.

Quantas chaves de acesso uma conta NEAR pode ter?

Uma conta NEAR pode conter um número ilimitado de chaves de acesso simultaneamente. Cada chave tem seu próprio escopo de permissão: uma Chave de Acesso Total (Full Access Key) com permissões irrestritas, ou uma Chave de Acesso para Chamada de Função (Function Call Access Key) limitada a métodos de contrato específicos. Isso permite que os usuários mantenham chaves separadas para diferentes dispositivos ou dApps sem criar novas contas. Você pode adicionar ou revogar chaves individuais a qualquer momento sem afetar as outras. Veja a seção de chaves de acesso para detalhes sobre cada tipo de chave.

O que é storage staking no NEAR Protocol?

O staking de armazenamento é o requisito para que as contas NEAR mantenham um saldo de Token NEAR proporcional à quantidade de dados on-chain que armazenam. Os tokens são bloqueados como um depósito, não gastos, e são liberados se os dados armazenados forem excluídos. Esse mecanismo evita o inchaço do estado na rede e garante que os consumidores de armazenamento arquem com o custo dos recursos que ocupam. O staking de armazenamento é separado das taxas de gás (que são queimadas por transação) e do staking de validador (que garante o consenso da rede). Veja a seção de staking de armazenamento para a explicação completa.

Uma conta NEAR pode hospedar um Smart Contract?

Sim. Qualquer conta NEAR pode ter um Smart Contract implantado nela. Ao contrário do Ethereum, que separa Contas de Propriedade Externa (contas de usuário que não podem conter código) de Contas de Contrato (contas que contêm código sem Chave privada), a NEAR utiliza um modelo de conta unificado onde qualquer conta pode simultaneamente manter um saldo de Token NEAR e código de contrato implantado. Os contratos na NEAR são compilados para WebAssembly (WASM) a partir de código-fonte Rust ou JavaScript, não Solidity. Veja a seção de comparação com o Ethereum para a análise arquitetural completa.

O que acontece se o saldo da minha conta NEAR cair abaixo do requisito de armazenamento?

Se o saldo de uma conta NEAR cair abaixo do mínimo exigido para o seu uso de armazenamento, a conta não poderá enviar transações de saída até que o saldo seja reabastecido. A conta não é excluída e seus dados não são perdidos; ela simplesmente se torna inativa para transações de saída até que tokens NEAR suficientes sejam depositados. Os dados armazenados permanecem intactos na rede. Consulte a seção de storage staking na prática para detalhes sobre os requisitos de saldo.

O que é uma subconta na NEAR e quem a controla?

Uma subconta NEAR é uma conta cujo ID é prefixado pelo ID de uma conta pai. Por exemplo, app.alice.near é uma subconta de alice.near, e apenas alice.near pode criar contas nesse namespace. Após a criação, a conta pai NÃO controla a subconta. A subconta é totalmente independente, com suas próprias chaves de acesso, seu próprio saldo de Token NEAR e seu próprio estado na blockchain. A autoridade de nomeação do pai é limitada ao ato de criação. Consulte a seção de subcontas para a explicação completa.

Como o NEAR Protocol é diferente do Ethereum em termos de contas?

A diferença arquitetural principal é a estrutura de conta. Ethereum possui dois tipos de conta separados: Contas de Propriedade Externa (controladas por uma única Chave privada, sem código) e Contas de Contrato (controladas por código, sem Chave privada). NEAR usa um modelo de conta unificado onde qualquer conta NEAR pode deter um saldo de Token e um Smart Contract implantado simultaneamente. As contas NEAR também suportam múltiplas chaves de acesso com escopos de permissão diferentes, enquanto as contas Ethereum são cada uma controlada por uma única Chave privada. Os IDs de conta NEAR podem ser contas nomeadas legíveis por humanos, enquanto os endereços Ethereum são sempre strings hexadecimais. Veja a tabela de comparação completa para um detalhamento lado a lado.

O que é uma Chave de Acesso Total vs. uma Chave de Chamada de Função no NEAR?

Uma Full Access Key (chave de acesso total) possui permissões irrestritas sobre uma conta: ela pode autorizar transferências de Token, implantação de contratos e a adição ou remoção de outras chaves. Uma Full Access Key é a credencial de maior confiança do proprietário da conta e deve ser armazenada em uma hardware wallet ou offline. Uma Function Call Access Key (chave de acesso para chamada de função) é restrita a chamar métodos específicos em um contrato específico, com uma permissão opcional de Token NEAR para taxas de gas. Ela não pode transferir saldos de Token ou modificar outras chaves. Full Access Keys são para os proprietários das contas; Function Call Access Keys são emitidas para dApps para permitir interações semelhantes a sessões sem exigir acesso total à conta. Consulte a tabela de comparação de chaves para obter um detalhamento completo.

Como é o formato de um ID de conta NEAR?

Os IDs de conta da NEAR vêm em duas formas. As contas nomeadas se parecem com nomes de usuário legíveis ou nomes de domínio: alice.near, myprotocol.near, app.alice.near. As contas implícitas são strings hexadecimais de 64 caracteres derivadas de uma Chave pública, semelhantes em formato visual aos endereços Ethereum, mas mais longas: por exemplo, 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. As contas nomeadas usam o sufixo .near na Mainnet e .testnet na rede de teste. Veja a seção de IDs de conta para a análise completa e tabela de comparação.

O NEAR Protocol é proof of stake?

Sim. O NEAR Protocol usa um mecanismo de consenso proof-of-stake (PoS). Validadores investem tokens NEAR em staking para participar da produção de blocos e ganhar recompensas do protocolo. Contas de validador são contas NEAR padrão com contratos de staking implantados nelas, o que ilustra o modelo de conta unificado na prática. O staking de validadores é um mecanismo separado do staking de armazenamento; ambos bloqueiam tokens NEAR, mas servem a propósitos totalmente diferentes.

Principais Pontos e Próximos Passos

O Modelo de Conta da NEAR unifica a identidade da conta com permissões e gerenciamento de armazenamento na blockchain em uma única arquitetura. Em vez de separar as contas de usuário das contas de contrato, ou limitar cada conta a uma única chave privada, a NEAR incorpora flexibilidade e permissões com escopo diretamente na camada da conta.

Principais conclusões:

• IDs de conta NEAR são contas nomeadas legíveis por humanos (ex: alice.near) ou contas implícitas de 64 caracteres derivadas de uma chave pública, não endereços hexadecimais
• Contas nomeadas exigem um depósito de token NEAR no momento do registro; contas implícitas são ativadas automaticamente ao receber o primeiro token
• Toda conta NEAR pode conter várias chaves de acesso simultaneamente, cada uma com um escopo de permissão distinto
• Chaves de Acesso Total autorizam todas as ações da conta e pertencem ao proprietário da conta; Chaves de Acesso de Chamada de Função são restritas a métodos específicos de Smart Contract e emitidas para aplicativos
• Qualquer conta NEAR pode possuir tanto um saldo de token NEAR quanto um Smart Contract implantado. Não existe um tipo de conta de contrato separado
• O Staking de armazenamento exige um saldo de token NEAR bloqueado proporcional ao consumo de armazenamento on-chain. É um depósito reembolsável, não uma taxa, e é distinto tanto das taxas de gás quanto do Staking de validador
• Subcontas seguem uma convenção de nomenclatura hierárquica, mas a conta pai não controla as subcontas após a criação. Cada subconta é totalmente autônoma

Desenvolvedores prontos para construir na NEAR podem começar com a documentação do modelo de conta do Protocolo NEAR, que fornece a especificação técnica e referências de SDK. Para especificidades de storage staking e parâmetros de taxas atuais, consulte a documentação oficial de storage staking da NEAR antes de tomar decisões de arquitetura, pois os parâmetros do protocolo podem mudar por meio de governança. Usuários criando sua primeira conta NEAR podem fazê-lo através de uma interface de carteira compatível com a NEAR, como MyNEARWallet ou Meteor Wallet.

Nota de precisão técnica: O NEAR Protocol é uma blockchain ativa e em evolução. Especificações técnicas, incluindo taxas de staking de armazenamento e requisitos de criação de conta, podem mudar à medida que o protocolo é atualizado. Verifique as especificações atuais na documentação oficial do NEAR Protocol antes de tomar decisões de desenvolvimento.