# 核心概念
## **命名空间**
命名空间是 BNS 中的顶级域（例如 .btc、.id）。它们具有以下生命周期：
* **预注册：** 将命名空间的加盐哈希与销毁支付一起提交
* **揭示：** 实际的命名空间被揭示，同时公开定价信息和命名空间的所有属性
在揭示期间会发生什么？
在揭示期间，创建者会设置： `生命周期` （名称在需要续期前可持续多久，0 表示无需续期）， `namespace-import` principal，以及完整的 `price-function` （16 个桶、base、coefficent、nonalpha-discount、no-vowel-discount）。这些都是决定命名空间永久行为的关键参数。
命名空间定价可以更新（通过 `namespace-update-price`），也可以永久冻结（通过 `namespace-freeze-price`）。一旦冻结，价格函数将永远无法更改。这些都是重要的治理决策。
另外，名称可以在上线前通过以下方式导入： `name-import`。这允许命名空间创建者在向公众开放注册之前预先填充名称（例如用于迁移或保留名称）。
* **上线：** 命名空间变为激活状态，允许名称注册
#### **非管理型与管理型命名空间**
BNS-V2 支持两种类型的命名空间： **非管理型** 和 **管理型**.
非管理型命名空间向任何人开放，任何人都可以在其中注册名称，但需遵守命名空间的定价规则。这些命名空间以完全去中心化的方式运行，对名称注册和管理的限制很少。
另一方面，管理型命名空间引入了额外一层控制和自定义。这些命名空间由指定的管理者监督，管理者拥有特殊权限和职责。管理型命名空间可以为名称注册、定价、转移和续期实现自定义规则。这使其适用于为特定社区创建命名空间、实现额外的验证流程或执行特定命名规范等场景。
非管理型和管理型命名空间的关键区别在于治理方式和灵活性。非管理型命名空间提供更开放、限制更少的环境，而管理型命名空间则提供更强的控制能力，以及根据特定需求或用例定制命名空间的能力。
#### 创建管理型命名空间
管理型命名空间是本版本 BNSv2 中最大的更新之一。其目的是让命名空间拥有更强的控制力和灵活性；“管理型”命名空间由单一 principal 控制（几乎总是一个 *合约* principal）。为了符合预期行为，你必须非常谨慎地设置这个合约 principal——如果设置不正确，可能会永久失去对该命名空间的控制。
创建管理型命名空间时需要做出几个重要决定：
* 管理者合约是否 *曾经* 需要更改？
* 你的铸造流程将如何工作？
* 管理者是否可以转移 *任何* 名称？
* 你的名称是否可以交易？
* 你的命名空间是否需要元数据？
这些都是在创建管理型命名空间时必须考虑的关键决定，以便为未来做好准备。对于第一个问题，几乎可以肯定你 *会* 需要更新或移除管理者合约，因此，至关重要的是管理者合约必须包含对 'mng-manager-transfer' 函数的访问权限。如果初始管理者合约不包含此函数，就不可能将命名空间更新或移交给新的管理者合约。
管理型命名空间不需要为名称注册销毁 STX。 `mng-name-register` 函数会在预注册中设置 `stx-burned: u0` 。定价完全由管理者合约处理（可以是免费的、代币门控的、基于 STX 的，取决于管理者自身逻辑等）。这与非管理型命名空间有着根本区别。
接下来，管理型命名空间中的铸造流程可定制性大得多。从高层来看，管理型命名空间可使用与名称注册相同的两条路径：两步流程 / mng-name-preorder + mng-name-register，或单步流程 / fast-claim。管理型合约 **必须** 能够访问其中一个或两个函数，才能在命名空间中成功铸造名称；此外，铸造流程可以高度定制，以支持：免费铸造、代币门控铸造、可变定价、sip-10 代币支持等……
一旦铸造完成，你必须特别注意实现三个标准的 sip-09 市场函数：list、unlist 和 buy。管理型命名空间 *默认情况下并不* 可交易，它们 *必须* 包含对 BNSv2 中 list、unlist 和 buy 函数的封装调用，因为这些函数会专门检查 'contract-caller'（即管理合约）。
最后，允许管理型命名空间合约 *本身* 转移任何名称的能力是一个关键决定。几乎可以肯定你 **不** 希望允许这样做，因为这会让合约把任何名称转移给任何 principal；不过，在某些用例中，需要更细粒度的控制。
管理型命名空间中的名称不会过期。 `mng-name-register` 函数会在预注册中设置 `renewal-height: u0`，这意味着没有自动续期要求。管理者控制整个生命周期。
***
## **名称**
名称是命名空间内的单个标识符（例如 alice.btc）。它们具有以下属性：
* 在其命名空间内唯一
* 以 NFT 形式表示
* 可以转移和续期
* 与 zonefile 关联，zonefile 会在单独的 `zonefile-resolver` 合约
中存储与名称相关的附加信息
```
<名称>.<命名空间>
```
示例：
```
alice.id
```
* `alice` → 名称
* `id` → 命名空间
命名空间定义名称注册的规则和定价。
***
## 所有权
名称归一个 Stacks principal 所有。
所有权允许持有人：
* 更新记录
* 将名称设为主名称
* 在内置市场上将名称挂牌出售
* 转移名称
* 续期名称
* 配置解析数据
所有权完全由智能合约逻辑强制执行。
***
## Zonefile
每个名称都可以存储结构化记录。zonefile JSON 支持：所有者地址、BTC 地址、自我介绍、网站、PFP、名称、位置、社交链接（X、Telegram 等）、多链地址（BTC 支付、BTC Ordinal、ETH 等）、任意键值元数据以及子域定义。
这些记录可能包括：
* 地址映射
* 文本元数据
* 应用特定数据
* 个人资料信息
由于 BNSv2 使用 Clarity 实现，其他合约可以直接在链上读取名称数据。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.stacks.co/learn/zh/network-fundamentals/bitcoin-name-system/core-concepts.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.