英文:
How named accounts works in NEAR
问题
似乎NEAR中的命名账户由near和register智能合约管理。然而，这引发了一个问题，即NEAR是否原生支持命名账户。目前不清楚智能合约是否仅维护了隐式账户与其对应名称之间的映射，或者命名账户在区块链层面是否原生支持。有人知道它是如何工作的吗？
英文:
It appears that named accounts in NEAR are being managed by the near and register smart contracts. However, this raises the question of whether NEAR natively supports named accounts. it's unclear if the smart contracts simply maintain a mapping between implicit accounts and their corresponding names or if named accounts are natively supported at the blockchain layer. anyone knows how it works?
答案1
得分: 3
NEAR账户具有以下特点：
-
本地支持的命名账户。NEAR名称由协议本身支持，而不是智能合约。一个账户可以创建其直接子账户。例如，
near可以创建alice.near，alice.near可以创建hi.alice.near。目前，我们可以创建.near账户，因为账户 near 部署了一个允许任何人创建其子账户的合约。特别地，顶级账户 registrar 是唯一可以创建其他顶级账户长度小于 32 的账户，registrar 不部署任何合约，并由NEAR基金会控制。隐式账户由私钥计算，本质上也是一个长度为 64 的顶级账户。当您向隐式账户转移 $NEAR 时，如果不存在，它将自动创建，但如果您向一个不存在的命名账户转移 $NEAR，转移将失败并退还 $NEAR。 -
抽象账户。NEAR协议不区分合约账户和普通账户。您可以将合约部署到现有账户。
-
多密钥模型。您可以将多个公钥绑定到一个账户（包括隐式账户）。这些密钥有两种权限类型，FullAccess 和 FunctionCall，您可以在这里查看。如果从一个账户中删除了所有FullAccess公钥，该账户将成为一个锁定账户，只有部署在该账户上的智能合约才能完全控制该账户。
英文:
NEAR account has follow features:
-
Native supported named account. NEAR name is supported by protocol itself, not smart contract. An account can create its immediate sub-account. For example,
nearcan createalice.near,alice.nearcan createhi.alice.near. Currently we can create.nearaccount because the account near has deployed a contract that allow anybody to create its sub-account. Specially, top-level account registrar is the only account that can create other top-level account with length < 32, registrar doesn't deploy any contract and it is controlled by NEAR Fundation. A implicit account is calculated by a private key, essentially, it is also a top-level account with a length of 64. When you transfer $NEAR to a implicit account, it will auto created if not exists, but if you transfer $NEAR to a named account which is not exists, transfer will failed and refund the $NEAR. -
Abstract account. NEAR protocol does not distinguish between contract accounts and regular accounts. You can deploy contract to a exist account.
-
Multiple key pair model. You can bind multiple public key to an account (including implicit account). There are two permission kind of the key, FullAccess and FunctionCall, you can check here. If you delete all FullAccess public keys from an account, the account will be a locked account, only smart contract deployed on that account can fully control that account.
答案2
得分: 2
NEAR协议提供了一种独特的账户识别方法。在NEAR中，命名账户得到了本地支持，并且是协议设计的一个基本部分。
在NEAR中，账户ID是一个可读的名称，类似于电子邮件地址。账户ID可以是分层的，意味着它们可以是其他账户的子名称，类似于子域名。
例如，如果有一个ID为“example.near”的账户，你可以在该账户下创建一个子账户，如“sub.example.near”。在这个层次结构中，只有“example.near”账户可以创建以“.example.near”结尾的子账户。
然而，账户ID不是由智能合约管理的。NEAR协议本身处理这些账户的创建、删除和管理。账户及其关联的状态（如账户余额和合约状态）存储在NEAR协议的底层状态树中，这是一个用于存储区块链状态的默克尔树。
你提到的“near”合约可能是基于基本账户系统的特定应用合约。
英文:
NEAR Protocol provides a unique approach to account identification. Named accounts in NEAR are natively supported and are a fundamental part of the protocol’s design.
In NEAR, an account ID is a human-readable name, similar to an email address. Account IDs can be hierarchical, meaning they can be subnames of other accounts, akin to subdomains.
For example, if there’s an account with ID “example.near”, you can create a subaccount under this account, like “sub.example.near”. In this hierarchy, only the “example.near” account can create subaccounts that end with “.example.near”.
However, the account IDs are not managed by smart contracts. The NEAR protocol itself handles the creation, deletion, and management of these accounts. Accounts and their associated state (like account balance and contract state) are stored in the NEAR Protocol’s underlying state trie, a merkle tree that is used for storing the blockchain’s state.
The “near” contract you mentioned might be application-specific contracts that work on top of the basic account system.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论