NEAR 账户模型：名称、密钥与存储

• 什么是 NEAR Protocol？
• TL;DR：NEAR 账户模型概览
• 什么是 NEAR 账户模型？
• 命名账户和隐式账户：NEAR 如何识别用户
• 子账户：NEAR 上的分层账户组织
• NEAR 访问密钥：完全访问权限 vs. 函数调用权限
• 存储质押：为什么 NEAR 账户需要最低余额
• NEAR 账户模型与以太坊：并排比较
• 入门：创建和管理您的 NEAR 账户
• 常见问题解答：NEAR 账户模型
• 结论：NEAR 账户模型对开发者和用户意味着什么

什么是 NEAR Protocol？（简介）

NEAR Protocol 是一个第一层（Layer-1）权益证明（PoS）区块链，专为开发者的可访问性而构建，具有低且可预测的交易费用，以及旨在不牺牲可用性的情况下进行扩展的分片架构。NEAR Protocol 由 Illia Polosukhin 和 Alexander Skidanov 共同创立，其从一开始的设计就以开发者体验和最终用户的可访问性为主要目标，而不是在为其他目的而构建的架构上加装可用性。

NEAR 通过 Nightshade 分片进行扩展，这是一种将账户状态和计算分配到并行处理链的机制，使网络能够处理高交易量而不会成比例地增加费用。该协议支持编译到 WebAssembly 的智能合约，并通过设计将 Gas 费用保持在低水平，这与费用波动会给开发者和用户带来阻碍的区块链形成对比。生态系统的发展由 NEAR 基金会监督，该基金会是一个非营利治理机构，此前曾运营官方 NEAR 钱包，之后才过渡到社区维护的替代方案。

这种开发者优先理念最清晰的体现是 NEAR 的账户模型，该设计从底层彻底重新思考了区块链身份和权限管理的工作方式。

简而言之：NEAR 账户模型概览

快速摘要，方便快速浏览：

• NEAR 账户使用人类可读的名称（例如 alice.near），而不是像以太坊那样使用加密哈希字符串（如 0x742d35Cc... 地址）。
• 每个账户可以同时持有多个访问密钥，每个密钥都有自己的权限级别，从无限制的控制到狭窄范围的合约交互。
• 任何 NEAR 账户都可以部署一个智能合约；与以太坊不同，没有单独的合约账户类型。
• 子账户遵循分层命名空间（例如，myapp.near 下的 contract.myapp.near），就像区块链账户的子域名一样。
• 账户必须维持最低限度的 NEAR 代币余额，该余额与它们的链上存储使用量成正比，这种机制称为存储质押。
• NEAR 原生的多密钥权限系统实现了以太坊通过账户抽象（EIP-4337）正在努力实现的目标，但通过一种从一开始就内置的不同架构方法。

什么是 NEAR 账户模型？

NEAR 账户模型是链上身份和权限架构，它定义了账户的命名方式、存储的状态、如何通过细粒度的密钥权限管理访问，以及它们与 NEAR 区块链上的智能合约之间的关系。

在区块链语境中，“账户模型”是指协议用于在链上表示参与者的系统：账户包含什么内容、如何被识别、如何授权交易以及是否可以执行代码。以太坊使用一种账户模型；比特币则使用完全不同的范式（UTXO 模型，其余额被追踪为未花费的交易输出，而非账户余额）。NEAR 使用基于账户的模型，但其实现方式与以太坊有显著不同，这些差异在可用性和应用程序开发方面都至关重要。

一个 NEAR 账户同时包含五项内容：一个唯一的账户 ID、一个 NEAR 代币余额、账户状态（链上数据存储）、一个可选的已部署的智能合约（编译为 WebAssembly，即 WASM，支持用 Rust 或 JavaScript 编写的合约），以及一个或多个具有不同权限级别的访问密钥。这种统一的结构意味着，不像以太坊那样，不存在“用户账户”和“智能合约账户”之间的区别。任何 NEAR 账户都可以选择托管一个智能合约，而无需成为一个不同类别的对象。没有部署合约的账户充当普通的ErrorClazz accounts; 部署了合约的账户同时也是用户账户和合约托管者。

理解这为何重要的实际背景是去中心化应用程序 (dApp)，一款运行在区块链网络而非中心化服务器上的软件应用程序。NEAR 的账户架构旨在使 dApp 交互比现有区块链账户模型更安全、更易于访问。账户 ID 系统是这种设计理念最直接可见之处，也是架构之旅的起点。

有关完整的技术规范，请参阅 NEAR Protocol account model documentation at docs.near.org/concepts/basics/accounts/model.

具名账户与隐式账户：NEAR 如何识别用户

NEAR 链上通过两种账户格式识别用户和应用程序：命名账户，使用人类可读的字符串，例如 alice.near，和 隐式账户，即源自公钥的 64 个字符的十六进制字符串。

命名账户：人类可读的区块链身份

NEAR 上的命名账户是人性化的账户标识符，遵循类似域名的结构，在主网上以 .near 结尾，在测试网上以 .testnet 结尾，取代了以太坊等区块链所使用的加密哈希字符串。

对比立竿见影：alice.near 对比 0x742d35Cc6634C0532925a3b844Bc454e4438f44e。两者都是有效的区块链标识符，但一个可读，而另一个则需要仔细的复制粘贴验证。您可以将 NEAR 命名账户想象成电子邮箱地址：它可读且与身份绑定，而不是一串需要逐个字符对比验证的随机字符串。

具名账户遵循特定的命名规则：账户 ID 是字母数字字符串，可以使用圆点作为分隔符，长度必须在 2 到 64 个字符之间，且在主网上必须以 .near 结尾，在测试网上则必须以 .testnet 结尾。这种以圆点分隔的结构创建了一个类似于域名的层级结构：myapp.near 是一个顶级具名账户，而 contract.myapp.near 是其下的一个子账户（有关子账户的更多内容将在下一节中介绍）。

命名账户背后的用户体验（UX）原因，不仅仅是为了美观。可读标识符可以降低将交易发送到错误账户的风险，使合约地址更易于查找，并降低管理链上身份的认知负担。对于任何曾在发送交易前反复检查 MetaMask 地址的人来说，alice.near 相较于 42 个字符的十六进制字符串的吸引力是具体的而非抽象的。用户通过 my-near-wallet.com 上的 MyNEARWallet 注册和管理命名账户，这是主要的社区维护的账户界面（NEAR Foundation 运营的原始 wallet.near.org 已被弃用）。

隐式账户：替代账户格式

隐含账户是 NEAR 的第二种账户格式：即直接从公钥派生的64个字符的小写十六进制字符串。只要将 NEAR 代币发送到该账户 ID，该账户就会自动创建，无需任何现有账户执行操作。

关键的实际区别：命名账户需要现有的链上账户通过交易来赞助其注册，而隐式账户在资金到达派生的账户 ID 时会自动产生。这使得隐式账户在需要从零开始引导，或者不需要人类可读名称的情况下非常有用。加密货币交易所通常在处理用户的 NEAR 充值入账时使用隐式账户，通过用户的公钥生成唯一的账户 ID，而无需预先存在的链上账户。

有一点值得明确说明：隐式账户并非匿名的。它们是由公钥确定性地派生出来的，并在链上是完全透明的。“隐式”一词是指账户 ID 的派生方式（即直接源自公钥本身，而无需经过显式的注册步骤），而不是指任何隐私属性。

具名帐户和隐式帐户确立了 NEAR 在链上识别参与者的方式。帐户还可以在其命名空间下包含其他帐户，而这种层级结构正是子帐户的由来。

子账户：NEAR 上的层级化账户组织

NEAR 上的子账户运行方式类似于网络上的子域名：正如 docs.myapp.com 和 api.myapp.com 是 myapp.com 域名下的不同地址一样，token.myapp.near 和 staking.myapp.near 则是 myapp.near 命名空间下不同的区块链账户。

子账户（Sub-account）是指其 ID 存在于母账户命名空间下的账户。例如，contract.myprotocol.near 是 myprotocol.near 的一个子账户。只有母账户可以创建子账户：myprotocol.near 可以创建 contract.myprotocol.near，但未经母账户授权，任何其他账户都不能在该命名空间下创建账户。

重要提示：父账户在创建子账户后，无法访问子账户的资金或状态。子账户是完全独立的账户，仅共享命名空间，并非由父账户控制的子公司。

这种独立性是一个常见的混淆点。父子关系仅在创建时适用。一旦 contract.myprotocol.near 存在，它就拥有自己的访问密钥、其自身的 NEAR 代币余额以及其链上状态。父账户 myprotocol.near 对其没有特殊权限。

对于 dApp 开发者而言，子账户提供了一种实用的架构模式。由于任何 NEAR 账户都可以部署一个智能合约（编译为 WASM），子账户便成为为每个合约组件提供一个可读、有条理的账户 ID 的自然方式。一个 DeFi 协议可能会为其代币合约部署 token.myprotocol.near，为其质押合约部署 staking.myprotocol.near，以及为其治理合约部署 governance.myprotocol.near。每个都是一个独立的账户，拥有自己的合约、自己的状态和自己的密钥管理，但该命名空间使得任何链上读取者都能一目了然地理解组件之间的关系。有关创建子账户的分步说明，请参阅 NEAR 子账户文档 docs.near.org/concepts/basics/accounts/model#named-accounts.

理解账户的命名与组织方式，为下一架构层——即如何通过访问密钥来确保账户安全及分配权限——奠定了基础。

NEAR 访问密钥：完全访问与函数调用权限

NEAR 访问密钥 是控制 NEAR 账户可执行操作的权限层，也是该系统在架构上最独特的特性：一个 NEAR 账户可同时持有多个独立的密钥对，每个密钥对都拥有自己的权限级别。

NEAR 多密钥系统的工作原理

与大多数区块链账户（一个私钥即可控制一切）不同，单个 NEAR 账户可以持有多个独立的密钥对，每个密钥对都被分配了特定的权限类型，范围涵盖从不受限的控制到特定范围的合约交互。

NEAR 访问密钥默认使用 Ed25519 密钥对（并支持 secp256k1 以兼容以太坊工具链）。建立在这些密钥对之上的权限系统，是 NEAR 模型在架构上独特之处。将其想象成一个密钥环：完全访问密钥是打开所有锁的主密钥；函数调用访问密钥是专门用于打开某个特定门的密钥。由任何访问密钥签署的交易都会消耗以 NEAR 代币支付的 Gas，但 NEAR 的交易费用设计上低廉且可预测，这与以太坊历史上易变的 Gas 定价形成对比。

有关以编程方式添加和管理访问密钥的详情，请参阅位于 docs.near.org/concepts/basics/accounts/access-keys 的 NEAR 访问密钥参考文档.

全权访问密钥：无限制的账户控制

NEAR 上的完全访问密钥是一种密钥对，可以对其关联的账户执行任何操作：转账代币、部署智能合约、创建子账户、添加或删除其他密钥，以及删除账户本身。

由于全权限密钥可以控制整个账户，其风险状况与主密码相同。全权限密钥绝不应与第三方应用程序共享；对于存有大额资金的任何账户，应将其保存在冷存储（硬件钱包或离线存储）中。如果全权限密钥泄露，攻击者将完全控制该账户，且除非预先进行了配置，否则没有任何原生恢复机制。

此处与以太坊的比较具有启发性。在以太坊中，您用于外部拥有账户 (EOA) 的单个私钥充当完全访问密钥：它控制一切，并且没有原生方法可以授予 dApp 用于特定合约交互的较低权限密钥。通过 MetaMask 的每次 dApp 连接都会将您的完整账户密钥暴露给交易签名流程。这种单密钥限制正是 EIP-4337 账户抽象旨在解决以太坊上的问题。而在 NEAR 上，该解决方案已内置于基础账户模型中。

函数调用访问密钥：dApp 安全的作用域权限

功能调用访问密钥是一种受限密钥，它只能调用指定智能合约上的指定方法，并可选设置燃气额度上限，以限制总费用支出。

全能访问密钥不受限制，而功能调用访问密钥则界定明确。该密钥指定：一个它被允许调用的合约账户ID，该合约上的哪些方法（如果未进一步限制，则为所有公共方法），以及一个可选的NEAR代币额度，该额度限制了密钥在需要补充之前可以花费的gas量。一旦额度耗尽，该密钥在补充或替换之前将无法签署进一步的交易。

基于会话的认证用例正是函数调用访问密钥在 dApp 开发中展现其实际价值的场景。当您将 dApp 连接到您的 NEAR 账户时，该 dApp 会请求一个作用域限定在其自身合约上的函数调用访问密钥。该密钥将存储在您的浏览器会话中。从那时起，dApp 便能代表您提交交易（例如批准一笔交易、铸造一个 NFT、与游戏合约进行交互），而无需提示您签署每个单独的操作。您的完全访问密钥（Full Access Key）将始终安全地保留在您的钱包中。如果 dApp 被攻破或存在恶意行为，造成的损害也是有限的：攻击者只能调用该密钥被限定的特定合约方法，且额度也受限于其权限。函数调用访问密钥的授权金额。函数调用访问密钥的功能类似于 Web 应用程序中的会话令牌：它授予对特定操作的临时、作用域限定的访问权限，而不会暴露完整的账户凭据。

访问密钥控制账户可以执行的操作。存储质押规定了账户在链上存在必须持有的资产。

存储质押：NEAR 账户为何需要最低余额

NEAR 上的存储质押（Storage staking）是一项机制，要求每个账户必须维持与其所使用的链上存储（状态）量成正比的最低 NEAR 代币余额。

该机制的工作原理如下：NEAR 分配以字节为单位的链上存储空间。账户中存储的每一字节状态（余额记录、合约代码、存储数据、访问密钥）都需要在账户余额中持有相应数量的 NEAR 代币。这些代币不会被花费或销毁；它们被保留作为抵押存储占用空间的锁定余额。如果您通过删除状态或合约数据来减少账户的存储空间，相应代币将被解锁并退还至您的可用余额。存储质押类似于可退还的押金：您为账户使用的存储空间锁定相应比例的 NEAR 代币，如果您减少存储占用空间，这些代币将返还给您。

这种设计的目的是出于经济考量：它通过确保从链上存储中获益的一方承担该存储的成本，来防止状态膨胀。如果没有这种机制，区块链网络可能会积累大量来自弃置账户或合约的死状态，从而降低所有参与者的性能。

具体而言，存储质押率约为每 10 KB 链上存储 1 个 NEAR 代币，而一个新创建的空 NEAR 账户需要大约 0.00182 NEAR 的最低余额，以涵盖其基础状态占用空间。在根据这些数据进行开发规划之前，请在 docs.near.org/concepts/storage/storage-staking 上的 NEAR 存储质押文档 核对当前数据，因为协议参数会随着升级而变化。

对于智能合约开发者而言，存储质押的影响需要积极规划。当 NEAR 账户部署一个合约时，合约代码本身会占用账户状态中的存储空间。一个更大的合约二进制文件需要按比例更大的预留余额。如果您的合约存储了大量数据（用户记录、代币余额、治理投票），托管该合约的账户必须维持足够的余额，以覆盖合约代码和累积的状态。这是一项随应用程序使用而扩展的资本要求，并且在部署之前需要在您的经济模型中加以考虑。

存储质押（Storage staking）会产生实际的资本锁仓需求。与那些不需要预留存储余额的区块链相比，一些开发者发现这种做法具有一定的局限性。这种权衡是经过深思熟虑的：这种限制可以防止网络状态无止境地增长，且代币是可回收的。然而，这种限制是真实存在的，应当在部署前进行规划，而不是在部署后才发现。

存储质押与验证者质押： 这是 NEAR 上的两种不同机制。存储质押会根据您账户的链上数据占用量锁定 NEAR 代币；这些代币作为与所使用的存储空间成比例的保留余额。验证者质押则是针对共识机制锁定 NEAR 代币，验证者通过质押代币来参与区块生产并赚取质押奖励。本文仅涵盖存储质押。请勿混淆“质押”一词的这两种用法。

Gas 费（交易执行成本）与存储质押是分开的。Gas 费按每笔交易消耗，并在签署时以 NEAR 代币支付；存储质押是一项预留余额，只要相关的状态存在，该余额就会保留在账户中。

理解存储质押，使我们对 NEAR 账户的独立运作有了更完整的认识。下一个问题是，这种架构与以太坊相比如何。

NEAR 账户模型与以太坊：全面对比

NEAR 和以太坊在链上账户架构方面采取了根本上不同的方法，这些差异对开发者如何构建去中心化应用以及用户如何管理他们的链上身份有着深远的影响。

以太坊的双账户系统 vs. NEAR 的统一账户模型

下表在八个架构维度上对比了两种账户模型。最显著的区别在于，以太坊将用户账户（外部拥有账户，简称 EOA）与智能合约账户分为两种不同的类型，而 NEAR 则为两者使用单一的统一账户类型。

以太坊的外部拥有账户（EOA）和合约账户的区分在实践中造成了不便。大多数去中心化应用（dApp）的交互都需要外部拥有账户（EOA）来调用合约账户，这意味着用户必须将这两种类型视为独立的实体来管理。外部拥有账户（EOA）由单个私钥控制，且没有原生方式来限制权限范围：任何连接到 MetaMask 账户的 dApp 都可以请求签名，这些签名会将完整的账户密钥暴露给交易流程。以太坊的模型有清晰的设计理念，并且很好地服务了其最初的目标，但随着 dApp 交互的频率和多样性的增加，这种单一密钥的限制变得显而易见。

NEAR 的统一账户类型消除了 EOA（外部账户）与合约之间的分离。每个 NEAR 账户都有可能成为合约宿主，而其带有函数调用访问密钥 (Function Call Access Keys) 的多密钥系统在无需额外协议层的情况下，解决了单密钥的局限性。NEAR 和以太坊都运作于基于账户的范式中，这与比特币的 UTXO 模型形成对比；在 UTXO 模型中，余额是以未花费交易输出而非账户状态的形式进行追踪。NEAR 与以太坊的区别在于这些账户的结构和权限配置方式，而非根本范式的差异。

NEAR 的账户模型与以太坊账户抽象 (EIP-4337)

EIP-4337（账户抽象） 是以太坊的一项努力，旨在为 EOA 提供可编程权限和会话密钥功能，而 NEAR 的账户模型在设计之初就已包含了这些功能。

EIP-4337 是一项现行的以太坊标准（而非理论提案），它使智能合约钱包能够作为“一等公民”运行，支持可编程交易验证、会话密钥、社交恢复以及赞助交易。它需要特定的打包器 (Bundler) 基础设施才能运作，并已在整个以太坊生态系统中积极部署，尽管它并非自动应用于所有账户的通用升级。

NEAR 的函数调用访问密钥与此确实存在相似之处：这两种方法都解决了授予 dApp 用于特定交互的、有范围的、有限权限的访问而无需暴露完整账户密钥的问题。熟悉 EIP-4337 会话密钥的开发者会发现 NEAR 的函数调用访问密钥在概念上很熟悉。重要的细微差别在于，它们是架构上不同的实现，代表了重叠的想法，而不是相同的系统。NEAR 的多密钥权限模型是基础协议的原生功能；EIP-4337 则是在以太坊现有 EOA 模型之上添加了智能合约钱包逻辑。它们解决的问题有显著重叠；机制则有所不同。有关完整的 EIP-4337 规范，请参阅 EIP-4337 账户抽象规范，网址为 eips.ethereum.org/EIPS/eip-4337.

对于正在评估 NEAR 的以太坊开发者来说，有两个生态桥值得关注。Aurora，网址为 aurora.dev 是一个在 NEAR 上构建的 EVM 兼容环境，它允许以太坊开发者在 NEAR 基础设施上部署 Solidity 合约，并以 NEAR 账户作为底层身份层。在两个生态系统中开展工作的开发者可以使用 Rainbow Bridge，网址为 rainbowbridge.app 在 NEAR 账户和以太坊地址之间转移资产，而无需依赖中心化托管。

既然架构已经清晰，以下是实际创建和管理 NEAR 账户所涉及的具体内容。

入门：创建和管理您的 NEAR 账户

您可以创建您的第一个NEAR账户，通过 MyNEARWallet 位于 mynearwallet.com，这是用于NEAR账户注册和密钥管理的主要社区维护界面。请核实您阅读时当前官方推荐的钱包，因为NEAR钱包生态系统仍在不断发展；其他兼容的钱包应用程序也与MyNEARWallet并存。

如果您是从以太坊和 MetaMask 过来的，在您开始之前，概念上的区别值得了解。MetaMask 钱包主要是一个以太坊 EOA 的密钥管理器和交易签名器：它持有您的私钥，并将其提供给 dApps 进行交易签名。NEAR 账户是一个完整的链上身份，具有可读名称、链上状态存储、可编程的密钥权限以及可选的合约托管。钱包应用程序 (MyNEARWallet) 是接口；NEAR 账户是链上对象。这是不同的概念，区别在于您如何看待密钥管理。

创建 NEAR 账户需要少量的初始 NEAR 代币余额，以支付基础存储质押要求（空账户大约需要 0.00182 NEAR，如上文 存储质押部分 所述）。此初始余额涵盖了新账户的基础状态占用。

在您开始之前，有三个风险值得您了解。首先，如果您丢失了您的完整访问密钥且未配置任何恢复机制，该账户将无法恢复。请将您的完整访问密钥存储在冷存储中，并在您需要它们之前配置任何可用的恢复选项。其次，用于存储质押的NEAR代币将一直被锁定，直到关联的状态被删除；这是一项资本承诺，而非费用。第三，NEAR上的账户删除是不可逆的。有关完整的账户创建分步指南，请参阅NEAR开发者文档：docs.near.org/concepts/basics/accounts/model.)

NEAR 账户模型最常见的问题解答如下。

常见问题：NEAR 账户模型

以下问题针对 NEAR 账户模型中最常见的困惑点，并为想要全面了解的读者提供了上文相关章节的交叉引用。

任何 NEAR 账户都可以部署智能合约吗？

是的。在 NEAR 中，任何账户都可以选择部署一个编译到 WebAssembly (WASM) 的智能合约。它没有独立的合约账户类型，不像以太坊那样，部署合约需要创建一个专门的合约账户。没有部署合约的账户可作为标准用户账户运行；部署了合约的账户则可同时作为这两种账户运行。有关完整的架构解释，请参阅上方的 NEAR 账户模型是什么 section。

NEAR 访问密钥如何使 dApp 更安全使用？

函数调用访问密钥将 dApp 限制在特定的合约方法，并可选择设置 Gas 限制额度。当您使用针对该 dApp 合约的函数调用访问密钥连接到 dApp 时，您的全权限访问密钥（以及您的完整账户余额）绝不会暴露给第三方应用程序。如果该 dApp 被入侵，损失将仅限于该额度和指定的合约。请参阅 NEAR 访问密钥章节以获取完整解析。

如果我丢失了全权限访问密钥会怎样？

如果没有预先配置的恢复机制，全权访问密钥的丢失将导致账户永久无法恢复。您无法像重置密码那样重置或恢复全权访问密钥，因为没有中央机构控制该账户。务必将全权访问密钥存储在安全的冷存储中，并在您需要它们之前，通过您的钱包应用程序配置任何可用的账户恢复选项。一些钱包提供社交恢复或多密钥恢复配置。

燃气费与质押费是否相同？

不。Gas 费是签署交易时产生的单次交易执行成本；它们以 NEAR 代币支付，并在交易完成后不再持续存在。存储抵押（Storage staking）是只要相关的链上状态存在，就必须在账户中保留的最低 NEAR 代币余额。虽然两者都涉及 NEAR 代币，但它们的运作机制完全不同。欲了解详细说明，请参阅 存储抵押部分。

NEAR 的账户模型与以太坊的账户抽象 (EIP-4337) 有何关系？

NEAR 的原生多密钥权限系统实现了许多 EIP-4337 旨在为以太坊增加的目标，包括针对 dApp 交互的范围限定会话权限和可编程密钥逻辑。两者在重叠想法的实现架构上截然不同：NEAR 的方法是基础协议原生的，而 EIP-4337 在以太坊现有的 EOA 模型之上叠加了智能合约钱包逻辑。它们通过不同的架构解决类似的问题。有关详细分析，请参阅 NEAR 与以太坊对比部分。

NEAR 上的具名账户 (Named Account) 和隐式账户 (Implicit Account) 有什么区别？

命名账户是通过现有账户的交易注册的人类可读标识符（例如 alice.near），在主网上以 .near 结尾，在测试网上以 .testnet 结尾。隐式账户是直接从公钥派生的 64 位十六进制字符串，当 NEAR 代币发送到该账户 ID 时，它们会自动生成，无需注册交易。有关完整对比表，请参阅命名账户和隐式账户部分。

一个 NEAR 账户可以持有多少个访问密钥？

一个 NEAR 账户可以同时持有多个访问密钥，每个密钥都分配有自己的权限类型（完全访问密钥或函数调用访问密钥）；对于函数调用访问密钥，还拥有各自的合约范围和 Gas 限额。目前没有关于每个账户密钥数量的明确记录硬性限制。这种多密钥能力是将 NEAR 的权限模型与以太坊每个 EOA 仅限单个密钥的方法区分开来的关键。有关详细信息，请参阅 NEAR 访问密钥部分。

存储质押是否意味着我会失去我的 NEAR 代币？

NEAR 代币为质押存储预留的已被锁定但未被花费。它们以预留余额的形式保留在您的账户中，如果您通过删除状态来减少账户的链上数据占用，这些代币将返还到您的可用余额中。这些代币是为存储使用而支付的押金，并非费用。请参阅 存储质押部分 了解机制和当前数据。

结语：NEAR 账户模型对开发者和用户的意义

NEAR 账户模型反映了一系列深思熟虑的架构选择：人类可读的账户名称降低了入门门槛并减少了交易错误；多密钥权限系统通过限定第三方访问范围而不暴露主密钥，从而降低了 dApp 交互的安全风险；存储质押在资源使用和成本之间创建了经济上的对齐；统一的账户-合约结构消除了 EOA/合约分离，这种分离增加了以太坊开发的摩擦。

存储质押最低余额要求是一个需要认真规划的实际限制，而不是一个可以忽略的附注。如果您的应用程序存储了大量的链上状态，保留余额的要求会随着该状态的增加而增加。请在部署应用程序的经济模型之前为其进行预算，而不是在部署之后。

各角色的后续步骤：

• 开发者： 在 NEAR Protocol 上开始构建 docs.near.org/develop)
• 用户： 在 myNEARWallet (myNEARWallet.com) 创建您的 NEAR 账户
• 研究人员： 深入了解完整的账户模型规范，请访问 NEAR Protocol 账户模型文档 (docs.near.org/concepts/basics/accounts/model))

本文中的技术规格反映了撰写本文时NEAR Protocol的情况。NEAR Protocol正在积极开发中；在依赖具体数值进行开发或运营规划之前，请在 docs.near.org 上核实当前数据。本内容仅供参考，不构成任何财务或投资建议。