NEAR 账户模型详解：密钥与存储

NEAR 账户模型是 NEAR Protocol 用于管理账户身份、权限以及链上状态的协议级系统。NEAR 上的每个账户都拥有一个易于人类理解的账户 ID，可以持有多个具有不同权限范围的访问密钥，并能同时存储代币余额和部署智能合约。区块链通过不同的系统来管理价值和身份（比特币使用未花费交易输出，即 UTXO 模型，而以太坊和 NEAR 使用基于账户的模型，其中每个账户直接持有状态），而 NEAR 基于账户的设计正是使此处所涵盖的架构得以实现的关键。

NEAR Protocol 是一个质押证明 (PoS) Layer 1 区块链，于 2020 年启动其主网。它由 NEAR Inc.（现运营为 Pagoda）创建，这是一家开发者工具组织，继续维护 NEAR SDK 和核心协议基础设施。NEAR Protocol 使用 Nightshade 分片技术将网络划分为并行分片，账户 ID 在分片分配中发挥作用，这对于考虑跨合约调用模式的开发者来说很重要。

四大特性使 NEAR 账户模型有别于其他的 Layer 1 账户系统：

["- 账户ID是人类可读字符串，而不是随机十六进制序列","- 单个账户可以拥有无限数量的访问密钥，每个密钥都有其自身的权限范围","- 任何账户都可以持有代币余额和已部署的智能合约，在“用户账户”和“合约账户”之间没有架构上的区别","- 账户必须保持NEAR代币余额，该余额与其链上存储使用量成正比，这是一种称为存储质押的机制"]

本文将按顺序介绍以下各个组成部分：账户 ID 类型、访问密钥类型、存储质押、子账户、以太坊架构对比以及一个实际操作示例。

• NEAR 账户 ID：命名账户与隐式账户
• NEAR 访问密钥：账户权限如何运作
• 存储质押：NEAR 如何将代币余额与链上存储关联起来
• NEAR 子账户：分层账户命名空间
• NEAR 账户模型与以太坊：主要架构差异
• NEAR 统一账户架构的实际意义
• 关于 NEAR 账户模型的常见问题解答
• 要点总结与下一步行动

NEAR 账户 ID：命名账户与隐式账户

每个 NEAR 账户都由一个唯一的账户 ID 标识。与以太坊不同（其账户由派生自公钥的 42 位十六进制地址标识），NEAR 账户 ID 有两种结构截然不同的形式：命名账户和隐式账户。理解两者之间的区别是使用 NEAR 账户系统的基础。

命名账户：人类可读的标识符

命名账户是注册在顶级域名下的可读账户 ID：主网上的 .near，以及测试网络上的 .testnet。命名账户的操作类似于互联网用户名或域名：它们是唯一的，由注册人选择，且易于分享和记忆。示例包括 alice.near、myprotocol.near 和 nft.myprotocol.near。与用户名不同，命名账户是一个协议层级的对象，它持有 NEAR 代币余额，可以部署智能合约，并控制加密访问密钥。

注册具名账户需要支付少量的 NEAR 代币充值。若要创建账户，请访问兼容 NEAR 的钱包界面（例如 MyNEARWallet 或 Meteor Wallet），选择您的账户 ID 并支付注册所需的充值金额。具名账户还可以在其命名空间内创建子账户（例如，alice.near 可以创建 app.alice.near），这一主题将在下方的子账户章节中详细介绍。

命名账户是直接构建在 NEAR 协议账户模型中的原生协议功能。它们并非叠加在协议之上的外部命名服务，这与以太坊域名服务 (ENS) 在以太坊上的运作方式不同。ENS 是一个独立的智能合约系统；而 NEAR 命名账户则是协议本身的核心组成部分。

隐式账户：源自公钥

隐式账户（Implicit Account）是一个由 Ed25519 公钥确定性推导出的 64 位十六进制账户 ID。隐式账户 ID 的示例如下：98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0。对于来自以太坊（Ethereum）的开发者来说，这是结构上最熟悉的账户类型，因为其推导过程类似于以太坊地址从公钥计算得出的方式。

隐式账户（Implicit accounts）的创建机制与命名账户（Named accounts）在一个关键方面有所不同：无需注册交易。当有人向其账户 ID 发送 NEAR 代币时，隐式账户就会立即激活。这使得隐式账户非常适合用于程序化账户创建、交易所充值地址以及对人类可读性要求不高的场景。

“隐式”描述符是指其创建机制，而非匿名性。隐式账户完全由派生出账户 ID 的私钥持有者拥有和控制。还有一个区别：隐式账户 ID 是从公钥派生出来的，但它与公钥本身并不完全相同。账户 ID 是原始公钥字节的小写十六进制表示。熟悉地址派生的以太坊开发者会识别出这种模式，但不应假设这两种表示形式是相同的。

命名账户与隐式账户：并排比较

这两种账户 ID 类型在五个维度上有所不同：

命名账户（Named accounts）适用于注重可读性的用户钱包和协议部署。隐式账户（Implicit accounts）则适用于交易所、程序化工具以及无需用户干预即可批量创建账户的场景。

NEAR 访问密钥：账户权限的工作原理

NEAR 访问密钥是账户模型的授权层。每个 NEAR 账户可以同时持有多个访问密钥，且每个密钥都具有不同的权限范围。一个 NEAR 账户可以同时持有无限数量的访问密钥。每个密钥都是一个独立的 Ed25519 加密密钥对，您可以在不创建新账户的情况下添加或移除密钥。密钥是通过由现有的完全访问密钥签名的交易来添加的，可以使用 NEAR CLI (near add-key) 或通过 SDK 以编程方式进行。

这与以太坊不同，以太坊的每个地址由一个私钥控制。NEAR 的多密钥设计能够实现更细粒度的权限控制，同时不影响账户的连续性。NEAR 支持两种密钥类型：完全访问密钥和函数调用访问密钥。有关完整技术规范，请参阅 NEAR Protocol 上的访问密钥文档)。

完全访问密钥：主凭证

全权访问密钥是一种对账户拥有无限制权限的访问密钥。它可以授权代币转账、智能合约部署、添加或移除其他密钥以及删除账户。将全权访问密钥想象成您房屋的总钥匙：它可以打开所有门。与房屋钥匙不同，全权访问密钥是一种在 NEAR 区块链上签名交易的加密密钥对，因此需要遵循相同的安全实践。将它存储在硬件钱包或离线，出于和以太坊用户保护其助记词同样的原因。

一个 NEAR 账户可以拥有多个全权访问密钥（Full Access Keys）。每个设备一个密钥是常见的模式，每个密钥都拥有相同的完全权限级别。这是一个重要的架构点：它不像以太坊（Ethereum）账户那样拥有单一的“主私钥”。多个全权访问密钥可以同时并存于同一个账户中。

开发者须知：被入侵的函数调用存取密钥不会授予完全存取权限。权限范围在协议层面上是架构上独立的。吊销一个函数调用存取密钥不会影响同一账户上的任何完全存取密钥，反之亦然。

函数调用存取密钥：dApp 的范围化权限

函数调用访问密钥（Function Call Access Key）是一种限定范围的访问密钥，仅可调用特定合约上的指定方法，并可设置可选的 NEAR 代币限额来约束该密钥可消耗的 Gas 总量。你可以将其类比为会话令牌（session token）或有范围限制的 OAuth 权限：它授予特定应用程序代表你执行特定操作的权利，而无需访问你的完整账户。与 OAuth 令牌不同，函数调用访问密钥是存储在链上的加密密钥对，其权限界限是由协议层强制执行的，而非由应用程序决定。

当您将 NEAR 账户连接到去中心化应用程序 (dApp) 并批准函数调用访问密钥 (Function Call Access Key) 时，该 dApp 即可自动提交某些交易，而无需为每笔交易触发钱包确认弹窗。这为游戏、DeFi 协议和社交应用实现了基于会话的用户体验 (UX)。在以太坊上，这些交互中的每一次都需要单独的 MetaMask 确认。而在 NEAR 上，用户只需批准一次密钥，dApp 即可在会话期间的该范围内运行。

函数调用访问密钥（Function Call Access Keys）可以携带一个可选的 NEAR 代币限额，这限制了该密钥允许消耗的总 Gas 量。一旦限额耗尽，在用户为其充值或签发新密钥之前，该密钥将无法再提交交易。

常见误解： 授予 DApp 函数调用访问密钥并不会让 DApp 控制你的账户。该密钥严格限制在已定义的合约方法和 Gas 限额范围内。它不能转账你的 NEAR 代币余额，不能部署合约，也不能添加或移除你账户上的其他密钥。

开发者说明： Function Call Access Keys 使得 dApp 能够实现会话密钥模式。用户可以授权一个密钥用于游戏会话或 DeFi 交易会话，应用程序将在该范围内运行，而无需每次交易都获得批准。这是在 NEAR 上开发与在以太坊上开发之间，最受开发者关注的用户体验差异之一。

完全访问密钥 vs. Function Call Access Key：主要区别

全权限密钥和函数调用访问密钥在六个维度上有所不同：

全权限密钥属于账户所有者，应离线保存或存放在硬件中。函数调用访问密钥则签发给应用程序，账户所有者可随时将其撤销。

存储质押：NEAR 如何将代币余额与链上存储相关联

存储质押是 NEAR 账户架构的一个组成部分，大多数区块链教育资源都会忽略这一点，但它对于每一位在 NEAR 上构建的开发者以及每一位管理账户的用户都具有直接的实际影响。

为什么 NEAR 的存储需要持有代币余额

定义： 存储质押（在一些NEAR文档中也称为状态质押）是NEAR账户的要求，即维持与所存储的链上数据量成正比的NEAR代币余额。这笔锁定的余额充当可退还的押金，而不是费用。

存储质押的工作原理类似于租房时的安全充值。您的 NEAR 代币将根据您占用的存储空间按比例锁定，并在您删除这些存储数据时退还。与支付租金不同，代币不会转移给任何人；它们仍保留在您的账户中，只是针对您所占用的存储空间进行预留。

值得澄清的一个区别：存储质押与验证者质押并不相同。这两种机制都会锁定 NEAR 代币，但它们的用途完全不同。验证者质押锁定代币是为了参与区块生产并赚取共识奖励。存储质押则是根据链上存储使用量比例锁定代币，以防止状态膨胀，并将存储成本与使用存储的实体挂钩。它们是具有不同用途的独立锁定余额。

存储质押也与 Gas 费分开。Gas 费是以 NEAR 代币支付的逐笔交易执行成本，并在每笔交易后销毁。存储质押是一项持续的余额要求，与账户持有的数据量挂钩，而不是与发送的交易数量挂钩。

存储质押实践：对账户和合约意味着什么

存储质押从三个层面影响账户：

• 账户创建： 需要最低 NEAR 代币余额。当前费率约为每字节状态 0.00182 NEAR（在做出开发决策之前，请在 官方 NEAR 存储质押文档) 中核实当前费率，因为协议治理可能会调整此数字）。
• 合约部署： 需要根据已编译合约的大小按比例增加的充值。合约的 WASM 字节码作为账户状态的一部分存储在链上，存储充值会随该大小而变化。
• 合约状态数据： 存储在合约状态中的数据（例如代币合约中的用户余额或链上游戏中的游戏状态）需要由控制合约账户的任何人持续维护余额。

若 NEAR 账户余额低于其存储要求，该账户在余额被补充之前将无法发送出站交易。账户不会被删除，其数据也不会丢失；它仅在存入足够的 NEAR 代币之前，对出站交易会处于非活动状态。

开发者笔记： 及早决定您的应用程序是在用户首次注册时先行支付存储押金，还是要求用户自行维持余额。许多协议会承担存储成本以减少阻力。这是一个影响用户获取的真实的首次注册经济学决策，因此在启动前将其纳入您的 dApp 成本模型。

NEAR 子账户：层级式账户命名空间

NEAR 子账户是指其 ID 以父账户 ID 为后缀的账户。例如，app.alice.near 是 alice.near 的子账户，且只有 alice.near 可以在该命名空间中创建账户。

有一点需要精确说明：子账户创建后，父账户对其不享有控制权。子账户是完全独立的：它拥有自己的访问密钥、自己的 NEAR 代币余额以及自己的链上状态。父账户唯一特殊的权限是能在其命名空间内创建子账户。除了创建这一行为之外，这两个账户之间没有任何持续的控制关系。

命名层级类似于网站域名和子域名。alice.near 就像一个域名，而 app.alice.near 就像一个子域名。正如注册域名并不会让您对其子域名上托管的内容拥有持续控制权，创建子账户也并不会赋予父账户对该子账户后续使用方式的权限。

协议团队的典型使用模式如下所示：

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

每个子账户在创建后均受独立控制。每个子账户都拥有各自的访问密钥、持有各自的余额，并且可以部署独立的智能合约。创建过程由主账户发起，可通过 NEAR CLI 或通过合约调用以编程方式完成。交易完成后，控制权将完全转移给持有该新子账户访问密钥的一方。

常见误解： 主账户在创建后并不管理子账户。子账户是完全自主的协议层级账户。命名惯例反映的是谁创建了它们，而不是谁控制它们。

开发者说明： 子账户是模块化协议架构的标准模式。将不同的合约部署到独立的子账户中，可让每个模块拥有独立的访问密钥管理、独立的升级路径以及更清晰的权限隔离。许多上线运行的 NEAR 协议都在代币合约、治理模块和质押逻辑中使用这种模式。

--- ## NEAR 账户模型对比以太坊：主要架构差异

NEAR 账户模型和以太坊账户模型在处理相同问题时采用了不同的架构方法：如何识别账户、如何授权交易以及如何部署智能合约。对于将 NEAR 评估为开发平台的开发者来说，理解这些差异是做出明智架构决策的前提条件。

以太坊将账户分为两种类型：外部拥有账户 (EOA) 和合约账户。EOA 由单个私钥控制，且无法托管已部署的代码。合约账户由代码控制，且没有私钥。这种分离意味着，如果您希望一个以太坊地址同时持有 ETH 并执行智能合约逻辑，您需要两个独立的账户对象协同工作。

NEAR 使用统一模型。任何 NEAR 账户都可以同时持有代币余额并部署智能合约。没有单独的“合约账户”类型。账户 alice.near 可以持有 NEAR 代币、运行已部署的 WASM 合约，并拥有多个具有不同权限范围的访问密钥，这一切都作为一个单一协议对象。任何 NEAR 账户都可以同时持有智能合约、代币余额和多个访问密钥。

以太坊的每个账户都由一个私钥控制。NEAR 账户支持具有不同权限范围的多个访问密钥，从而能够实现以太坊账户模型在协议层面原生不支持的会话密钥和多设备密钥管理等模式。

请注意：兼容以太坊的智能合约可以通过 Aurora 在 NEAR 上运行，Aurora 是部署在 NEAR 上的一个 EVM 兼容层智能合约。Aurora 是一个独立的层；原生 NEAR 开发使用从 Rust 或 JavaScript 编译而成的 WebAssembly (WASM)，而不是 Solidity。请参阅 以太坊账户模型文档) 以了解完整的以太坊账户规范。

NEAR 统一账户架构的实际意义

NEAR 账户模型的组成部分（账户 ID、访问密钥、存储质押和子账户）形成一个统一的系统，在应用程序的行为以及用户体验方面产生实际的差异。

以一个 NEAR 账户 alice.near 为例。Alice 的账户可以同时：

["1. 持有 NEAR 代币余额","2. 部署了从 Rust 编译成 WebAssembly (WASM) 的智能合约","3. 拥有三个访问密钥：一个存储在其硬件钱包中的完全访问密钥，一个在其笔记本电脑上的完全访问密钥，以及一个授予 DeFi dApp 用于基于会话的交易的函数调用访问密钥","4. 拥有两个子账户（app.alice.near 用于一个已部署的游戏合约，vault.alice.near 用于一个储蓄合约），每个都独立控制"]

Alice 的账户 ID 易读且可分享。她无需通过复制 42 位十六进制字符串来接收代币或与合约进行交互。

对开发者而言，实际影响是巨大的。会话密钥模式消除了游戏和社交应用中每笔交易的钱包摩擦。子账户架构允许协议团队部署具有独立升级路径的模块化合约。存储质押为链上数据创建了一个可预测的成本模型，必须将其纳入用户引导经济学中。账户还可以与 Rainbow Bridge 交互，在 NEAR 和 Ethereum 之间转移资产，并通过 NEAR 兼容的钱包界面（如 MyNEARWallet 或 Meteor Wallet）进行管理。

对于终端用户而言，账户模型转化为了类似于用户名的易读账户 ID、不会因钱包弹窗干扰体验的 dApp 会话，以及无需依赖单一助记词即可实现账户恢复的密钥轮换模型。

NEAR 账户模型常见问题解答

NEAR 上的命名账户和隐式账户有什么区别？

命名账户是注册在顶级域名下的人类可读标识符（例如 alice.near），在注册时需要少量 NEAR 代币充值，并由用户选择。隐式账户是源自 Ed25519 公钥的64位十六进制ID，无需注册，且在 NEAR 代币发送到账户ID时自动激活。命名账户通常用于用户钱包和协议部署；隐式账户常用于交易所和程序化工具。请参阅上方的命名账户 vs 隐式账户对比表，以获取完整的并排对比。### NEAR 账户可以有多少个访问密钥？

一个 NEAR 账户可以同时持有无限数量的访问密钥。每个密钥都有各自的权限范围：要么是拥有无限制权限的“全权访问密钥”，要么是权限范围仅限于特定合约方法的“函数调用访问密钥”。这允许用户在无需创建新账户的情况下，为不同的设备或 dApp 保留独立的密钥。您可以随时添加或撤销单个密钥，而不会影响其他密钥。有关每种密钥类型的详细信息，请参阅访问密钥部分。

什么是 NEAR 协议上的存储质押？

存储质押是 NEAR 账户必须根据其存储的链上数据量，维持相应比例的 NEAR 代币余额的要求。代币作为充值被锁定，而非被消耗，并在删除存储数据时释放。该机制可防止网络状态膨胀，并确保存储使用者承担其占用的资源成本。存储质押与 Gas 费（每次交易都会被销毁）以及验证者质押（用于维护网络共识）是分开的。请参阅 存储质押部分 以获取完整说明。

NEAR 账户可以持有智能合约吗？

是的。任何 NEAR 账户都可以部署智能合约。与以太坊将外部账户（无法持有代码的用户账户）与合约账户（持有代码但没有私钥的账户）区分开来不同，NEAR 采用了统一的账户模型，任何账户都可以同时持有 NEAR 代币余额和已部署的合约代码。NEAR 上的合约是由 Rust 或 JavaScript 源代码编译成 WebAssembly (WASM) 的，而非 Solidity。请参阅以太坊对比部分以了解完整的架构解析。

如果我的 NEAR 账户余额低于存储要求会发生什么？

如果 NEAR 账户余额低于其存储使用所需的最低限额，则该账户将无法发送出站交易，直至余额得到补充。该账户不会被删除，其数据也不会丢失；它仅会暂时停用出站交易功能，直到存入足够的 NEAR 代币为止。存储的数据在链上保持完整。有关余额要求的详细信息，请参阅 实际的存储质押部分。

NEAR 上的子账户是什么，由谁控制？

NEAR 子账户是其 ID 以父账户 ID 为前缀的账户。例如，app.alice.near 是 alice.near 的子账户，并且只有 alice.near 才能在该命名空间内创建账户。创建后，父账户不再控制子账户。子账户完全独立，拥有自己的访问密钥、自己的 NEAR 代币余额以及自己的链上状态。父账户的命名权限仅限于创建行为。有关完整解释，请参阅 子账户部分。

NEAR Protocol 在账户方面与以太坊有何不同？

核心架构差异在于账户结构。以太坊有两种独立的账户类型：外部拥有账户（由单一私钥控制，无代码）和合约账户（由代码控制，无私钥）。NEAR 采用统一的账户模型，任何 NEAR 账户都可以同时持有代币余额和部署的智能合约。NEAR 账户还支持具有不同权限范围的多个访问密钥，而以太坊账户则各自由单一私钥控制。NEAR 账户 ID 可以是易于辨识的命名账户，而以太坊地址始终是十六进制字符串。请参阅完整对比表以获取详细对比。

什么是 NEAR 上的全权限密钥（Full Access Key）与函数调用访问密钥（Function Call Access Key）？

全权访问密钥对账户拥有无限制的权限：它可以授权代币转账、合约部署，以及添加或移除其他密钥。全权访问密钥是账户所有者的最高信任凭证，应存储在硬件钱包或离线状态。函数调用访问密钥则限制为调用特定合约的特定方法，并可选 NEAR 代币作为 Gas 额度。它无法转账代币余额或修改其他密钥。全权访问密钥适用于账户所有者；而函数调用访问密钥则发放给 dApp，以便实现类似会话的交互，而无需完整的账户访问权限。有关完整的细则，请参阅 密钥对比表。

NEAR 账户 ID 看起来是怎样的？

NEAR 账户 ID 有两种形式。命名账户看起来像可读的用户名或域名：alice.near、myprotocol.near、app.alice.near。隐式账户是源自公钥的 64 个字符的十六进制字符串，在视觉格式上类似于以太坊地址但更长：例如 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0。命名账户在主网上使用 .near 后缀，在测试网上使用 .testnet。请参阅 账户 ID 部分 以获取完整的细分和比较表。

NEAR Protocol 是否为权益证明？

NEAR Protocol 使用一种权益证明 (PoS) 共识机制。验证者通过质押 NEAR 代币来参与区块生产并赚取协议奖励。验证者账户是部署了质押合约的标准 NEAR 账户，这实际展示了统一账户模型的应用。验证者质押是独立于存储质押的机制；两者都锁定 NEAR 代币，但目的完全不同。

关键要点与后续步骤

NEAR 账户模型将账户身份、权限和链上存储管理统一在一个单一架构中。NEAR 不是将用户账户与合约账户分开，也不是将每个账户限制为单个私钥，而是将灵活性和作用域权限直接构建到账户层中。

关键要点：

• NEAR 账户 ID 是人类可读的命名账户（例如 alice.near）或源自公钥的 64 位字符隐式账户，而非十六进制地址
• 命名账户在注册时需要充值 NEAR 代币；隐式账户在首次收到代币时自动激活
• 每个 NEAR 账户可以同时持有多个访问密钥，每个密钥都具有不同的权限范围
• 全权访问密钥（Full Access Keys）授权所有账户操作，归账户所有者所有；函数调用访问密钥（Function Call Access Keys）仅限于特定的合约方法，并签发给应用程序
• 任何 NEAR 账户都可以同时持有 NEAR 代币余额和已部署的智能合约。不存在单独的合约账户类型
• 存储质押需要根据链上存储消耗量锁定成比例的 NEAR 代币余额。这是一笔可退还的充值，而非手续费，且与 Gas 费和验证者质押均不相同
• 子账户遵循分层命名规范，但父账户在创建后并不控制子账户。每个子账户都是完全自治的

准备在 NEAR 上进行开发的开发者可以从 NEAR Protocol 账户模型文档,) 开始，其中提供了技术规范和 SDK 参考。对于存储质押的详细信息和当前费率参数，请在做出架构决策前查阅 官方 NEAR 存储质押文档)，因为协议参数可能会通过治理发生变化。创建首个 NEAR 账户的用户可以通过 NEAR 兼容的钱包界面进行操作，例如 MyNEARWallet 或 Meteor Wallet。

技术准确性说明： NEAR Protocol 是一条活跃且不断演进的区块链。各项技术规范，包括存储质押率和账户创建要求，可能会随着协议的更新而发生变化。在做出开发决策之前，请务必参考 NEAR Protocol 官方文档以核实当前的规范。