docs: 完成Issue #26 NAC公链资产一键上链核心技术白皮书 v1.0
This commit is contained in:
NAC Development Team
parent
16b067ee82
commit
d3a7cb862a
|
|
@ -0,0 +1,932 @@
|
|||
# NAC公链资产一键上链核心技术白皮书
|
||||
|
||||
**从资产申请到交易所交易的全自动合规化流程**
|
||||
|
||||
---
|
||||
|
||||
**版本**：1.0
|
||||
**制定方**：NAC资产上链工作组
|
||||
**发布日期**：2026年2月19日
|
||||
**文档状态**：正式发布
|
||||
|
||||
**关联文档**：
|
||||
- NAC公链宪法层规范
|
||||
- NAC公链AI层规范
|
||||
- NAC公链存储层规范
|
||||
- NAC公链协议层规范
|
||||
- NAC开发者工具栈文档
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
1. [执行摘要](#执行摘要)
|
||||
2. [总体架构](#总体架构)
|
||||
3. [核心组件](#核心组件)
|
||||
4. [一键上链流程详解](#一键上链流程详解)
|
||||
5. [技术实现细节](#技术实现细节)
|
||||
6. [安全与合规](#安全与合规)
|
||||
7. [治理与宪法约束](#治理与宪法约束)
|
||||
8. [实施路线图](#实施路线图)
|
||||
9. [结论](#结论)
|
||||
|
||||
---
|
||||
|
||||
## 执行摘要
|
||||
|
||||
NAC公链的核心使命是让真实世界资产（Real World Assets, RWA）的上链和权益化像发送一封电子邮件一样简单。通过深度整合宪法层（L2）、AI层（L4）、协议层（L1）和开发者工具栈，我们设计并实现了一套全自动、一键式的资产上链流程，涵盖从资产申请、合规审批、估值、DNA生成、托管、权益衍生、代币发行到交易所上线的完整生命周期。
|
||||
|
||||
用户只需通过`nac-toolbox` CLI或Web界面提交资产基本信息，系统便自动完成以下全部流程：
|
||||
|
||||
- **合规审查**：调用AI合规引擎，基于宪法规则进行自动化审查
|
||||
- **资产估值**：通过预言机和AI模型进行专业估值
|
||||
- **链上确权**：生成GNACS编码和资产DNA
|
||||
- **托管对接**：选择合格托管机构，生成托管凭证
|
||||
- **铸造XTZH**：基于估值发行等值稳定币
|
||||
- **发行权益化代币**：创建ACC-20/ACC-1400标准代币
|
||||
- **上链公示**：自动录入区块链浏览器
|
||||
- **钱包支持**：代币自动注册到主流钱包
|
||||
- **交易所上线**：自动对接合作交易所
|
||||
|
||||
整个流程无需人工干预，所有规则由宪法定义，由AI自动执行，确保合规、透明、高效。本白皮书详细阐述一键上链系统的技术架构、核心组件、流程设计及宪法保障机制。
|
||||
|
||||
---
|
||||
|
||||
## 总体架构
|
||||
|
||||
一键上链系统作为NAC公链的上层应用，深度依赖各层级服务。其整体架构如下：
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 一键上链前端/CLI │
|
||||
│ (nac-toolbox, Web界面, API网关) │
|
||||
└─────────────────────────────┬───────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 一键上链编排引擎 │
|
||||
│ (负责协调各组件，管理状态机，处理异常) │
|
||||
└─────────────┬───────────────┬───────────────┬───────────────┘
|
||||
↓ ↓ ↓
|
||||
┌─────────────┴──────┐ ┌──────┴──────┐ ┌──────┴─────────────┐
|
||||
│ AI合规审批模块 │ │ AI估值模块 │ │ DNA生成模块 │
|
||||
│ (调用L4 AI层) │ │ (预言机聚合) │ │ (GNACS编码器) │
|
||||
└─────────────┬──────┘ └──────┬──────┘ └──────────┬──────────┘
|
||||
↓ ↓ ↓
|
||||
┌─────────────┴───────────────────────────────────┴──────────┐
|
||||
│ 宪法执行引擎（CEE） │
|
||||
│ (验证每一步合规性，签发宪法收据CR) │
|
||||
└─────────────────────────────┬───────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ L1协议层：CBPP、CSNP、NVM、ACC │
|
||||
│ (处理交易打包、广播、状态存储、代币发行) │
|
||||
└─────────────────────────────┬───────────────────────────────┘
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ L0基础设施：存储、网络、密码学 │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 设计原则
|
||||
|
||||
一键上链系统的设计遵循以下核心原则：
|
||||
|
||||
**宪法驱动**：所有规则来自L2宪法状态，AI严格遵循，不可偏离。宪法定义了资产上链的最低合规标准、估值模型参数、托管机构白名单等关键规则，确保系统行为的可预测性和合法性。
|
||||
|
||||
**全自动化**：从用户提交资产信息到最终上线交易所，整个流程无需人工介入。系统通过智能编排引擎自动协调各个模块，处理异常情况，并实时反馈进度。
|
||||
|
||||
**可审计性**：每一步操作都生成可验证的宪法收据（Constitutional Receipt, CR）和详细日志。所有关键决策和数据变更都被永久记录在链上，支持事后审计和争议解决。
|
||||
|
||||
**可扩展性**：系统支持通过宪法升级机制添加新的资产类型、新的合规要求和新的估值模型。模块化设计使得各个组件可以独立升级，而不影响整体系统的稳定性。
|
||||
|
||||
---
|
||||
|
||||
## 核心组件
|
||||
|
||||
### 2.1 一键上链编排引擎
|
||||
|
||||
编排引擎是整个一键上链系统的核心调度中心，负责管理资产上链的完整生命周期。
|
||||
|
||||
**职责**：
|
||||
- 管理资产上链状态机，跟踪每个资产的当前状态
|
||||
- 协调各模块调用，确保流程按正确顺序执行
|
||||
- 处理错误和异常，实现自动重试机制
|
||||
- 提供实时进度查询接口
|
||||
|
||||
**状态定义**：
|
||||
|
||||
| 状态 | 描述 | 下一步 |
|
||||
|------|------|--------|
|
||||
| `Pending` | 初始提交，等待处理 | `ComplianceCheck` |
|
||||
| `ComplianceCheck` | 合规审查中 | `Valuation` 或 `Failed` |
|
||||
| `Valuation` | 估值中 | `DNAGeneration` 或 `Failed` |
|
||||
| `DNAGeneration` | DNA生成中 | `Custody` 或 `Failed` |
|
||||
| `Custody` | 托管对接中 | `XTZHMinting` 或 `Failed` |
|
||||
| `XTZHMinting` | XTZH铸造中 | `TokenIssuance` 或 `Failed` |
|
||||
| `TokenIssuance` | 代币发行中 | `Listed` 或 `Failed` |
|
||||
| `Listed` | 完成（浏览器、钱包、交易所已上线） | - |
|
||||
| `Failed` | 失败（附详细原因） | - |
|
||||
|
||||
**技术实现**：编排引擎作为链下服务，使用Rust语言实现，通过`nac-toolbox`提供RESTful API和CLI接口。引擎采用事件驱动架构，支持异步处理和并发控制。
|
||||
|
||||
### 2.2 AI合规审批模块
|
||||
|
||||
AI合规审批模块负责自动化验证资产上链的合规性，确保所有资产符合NAC公链的宪法要求和相关法律法规。
|
||||
|
||||
**输入参数**：
|
||||
- 资产类型（如商业地产、股权、债权等）
|
||||
- 法律文件哈希（存储在IPFS上）
|
||||
- 发行方DID及KYC凭证
|
||||
- 管辖权信息（资产所在国家/地区）
|
||||
- 其他合规相关文档
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **加载宪法规则**：从宪法状态读取`ASSET_COMPLIANCE_MIN_STANDARD`等相关条款，获取该资产类型的最低合规要求。
|
||||
|
||||
2. **文件真伪验证**：调用AI模型（基于预训练的NLP模型）分析法律文件，通过OCR技术提取文本内容，验证文件的格式、签名和内容完整性。
|
||||
|
||||
3. **KYC等级检查**：验证发行方的KYC等级是否满足宪法要求（通常要求KYC等级≥2）。
|
||||
|
||||
4. **管辖权合规性**：检查资产所在管辖权是否在NAC公链支持的白名单内，并验证是否符合该管辖权的特定要求。
|
||||
|
||||
5. **生成合规证明**：输出合规性评分（0-100分）及详细证明，可选择性地生成零知识证明（ZK Proof）以保护隐私。
|
||||
|
||||
**输出结果**：
|
||||
- `ComplianceResult`结构体，包含合规性评分、详细报告和证明哈希
|
||||
- 提交给宪法执行引擎（CEE）进行验证
|
||||
|
||||
### 2.3 AI估值模块
|
||||
|
||||
AI估值模块负责对资产进行专业估值，为后续的XTZH铸造和代币发行提供价值基准。
|
||||
|
||||
**输入参数**：
|
||||
- 资产类型和详细属性
|
||||
- 相关市场数据（通过预言机获取）
|
||||
- 历史交易数据（如适用）
|
||||
- 宪法定义的估值模型参数
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **加载估值模型**：从宪法状态读取该资产类型对应的估值模型参数，如不动产的收益法折现率、股权的市盈率倍数等。
|
||||
|
||||
2. **聚合预言机数据**：从多个可信预言机节点获取市场数据，如房价指数、租金收益率、股票市场数据等，并进行中位数聚合以抗操纵。
|
||||
|
||||
3. **运行估值模型**：根据资产类型选择合适的估值方法（如收益法、市场法、成本法），结合AI模型进行综合估值。
|
||||
|
||||
4. **SDR计价**：所有估值结果统一以特别提款权（SDR）计价，确保跨国资产的价值可比性。
|
||||
|
||||
**输出结果**：
|
||||
- `ValuationResult`结构体，包含估值金额（SDR）、估值方法、置信区间和详细报告
|
||||
- 提交给CEE进行验证
|
||||
|
||||
### 2.4 DNA生成模块
|
||||
|
||||
DNA生成模块负责为每个资产生成唯一的GNACS编码和资产DNA，实现链上资产的精确识别和分类。
|
||||
|
||||
**职责**：
|
||||
- 根据资产信息生成48位GNACS编码
|
||||
- 创建资产DNA结构，包含基因组、表型和进化历史
|
||||
- 计算DNA哈希，用于链上存储和验证
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **解析资产属性**：从合规和估值结果中提取资产类型、风险权重、合规等级等关键信息。
|
||||
|
||||
2. **生成GNACS编码**：调用GNACS编码器，根据NAC公链的编码规范生成完整的48位编码，包含：
|
||||
- 资产类别代码（4位）
|
||||
- 风险等级代码（2位）
|
||||
- 管辖权代码（4位）
|
||||
- 合规等级代码（2位）
|
||||
- 其他属性代码（36位）
|
||||
|
||||
3. **创建DNA结构**：构建资产DNA对象，包含：
|
||||
- **基因组（Genome）**：资产的固有属性，如类型、发行方、初始估值
|
||||
- **表型（Phenotype）**：资产的可变属性，如当前价格、流动性、持有人分布
|
||||
- **进化历史（Evolution History）**：资产的历史变更记录，如估值调整、合规状态变化
|
||||
|
||||
4. **计算DNA哈希**：使用SHA3-384算法计算DNA结构的哈希值，确保数据完整性。
|
||||
|
||||
**输出结果**：
|
||||
- GNACS编码（48位十六进制字符串）
|
||||
- DNA哈希（48字节）
|
||||
- 提交给CEE进行格式验证
|
||||
|
||||
### 2.5 宪法执行引擎（CEE）
|
||||
|
||||
宪法执行引擎是NAC公链宪法层的核心组件，负责验证所有操作的合规性并签发宪法收据。
|
||||
|
||||
**职责**：
|
||||
- 为每一步操作签发宪法收据（Constitutional Receipt, CR）
|
||||
- 验证操作是否符合宪法规定
|
||||
- 记录所有合规性验证结果
|
||||
- 提供审计追踪接口
|
||||
|
||||
**交互流程**：
|
||||
|
||||
1. **申请收据**：各模块在执行操作前，先向CEE申请收据，提交操作类型和相关参数。
|
||||
|
||||
2. **宪法验证**：CEE从宪法状态中读取相关规则，验证该操作是否符合要求。例如，验证合规审批结果是否满足`ASSET_COMPLIANCE_MIN_STANDARD`条款。
|
||||
|
||||
3. **签发收据**：如果验证通过，CEE签发宪法收据（CR），包含：
|
||||
- 收据ID（唯一标识符）
|
||||
- 操作类型和参数
|
||||
- 宪法条款引用
|
||||
- CEE签名（使用宪法密钥）
|
||||
- 时间戳
|
||||
|
||||
4. **附加到交易**：模块将收据附加到后续的链上交易中，节点在验证交易时会检查所有收据的有效性。
|
||||
|
||||
**收据类型**：
|
||||
- `CR_compliance`：合规审批收据
|
||||
- `CR_valuation`：估值验证收据
|
||||
- `CR_dna`：DNA生成收据
|
||||
- `CR_custody`：托管验证收据
|
||||
|
||||
### 2.6 托管对接模块
|
||||
|
||||
托管对接模块负责与第三方托管机构对接，确保资产的物理或法律托管得到妥善处理。
|
||||
|
||||
**职责**：
|
||||
- 从宪法白名单中选择合格的托管机构
|
||||
- 发送托管请求并接收托管凭证
|
||||
- 验证托管凭证的真实性
|
||||
- 将托管凭证哈希上链存证
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **选择托管机构**：根据资产类型和管辖权，从宪法白名单中筛选合适的托管机构。白名单由NAC公链治理机构维护，确保托管机构的资质和信誉。
|
||||
|
||||
2. **发送托管请求**：通过HTTPS API向托管机构发送请求，包含：
|
||||
- 资产DNA和GNACS编码
|
||||
- 估值结果
|
||||
- 法律文件哈希
|
||||
- 发行方信息
|
||||
|
||||
3. **接收托管凭证**：托管机构审核后签发托管凭证（Custody Receipt），包含：
|
||||
- 托管机构数字签名
|
||||
- 托管资产描述
|
||||
- 托管期限和条件
|
||||
- 托管凭证编号
|
||||
|
||||
4. **验证签名**：CEE验证托管机构的公钥是否在宪法白名单内，并验证数字签名的有效性。
|
||||
|
||||
5. **上链存证**：将托管凭证哈希提交到链上，确保托管记录的不可篡改性。
|
||||
|
||||
**输出结果**：
|
||||
- 托管凭证哈希
|
||||
- 提交给CEE进行验证
|
||||
|
||||
### 2.7 XTZH铸造模块
|
||||
|
||||
XTZH铸造模块负责基于资产估值铸造等值的XTZH稳定币，为资产提供流动性支持。
|
||||
|
||||
**职责**：
|
||||
- 根据宪法定义的覆盖率要求计算应铸造的XTZH数量
|
||||
- 调用XTZH智能合约执行铸造操作
|
||||
- 将铸造记录与资产DNA关联
|
||||
- 确保XTZH的黄金储备充足
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **计算铸造量**：根据宪法条款`XTZH_GOLD_COVERAGE`（要求125%覆盖率），计算应铸造的XTZH数量：
|
||||
```
|
||||
XTZH数量 = 资产估值（SDR） × 125%
|
||||
```
|
||||
|
||||
2. **验证储备**：检查NAC公链的黄金储备是否足以支持新增的XTZH发行。如果储备不足，需要先补充储备。
|
||||
|
||||
3. **构造铸造交易**：创建XTZH铸造交易，附带所有历史宪法收据（`CR_compliance`, `CR_valuation`, `CR_dna`, `CR_custody`）。
|
||||
|
||||
4. **提交到网络**：将交易提交到CBPP共识网络，验证节点检查所有收据的有效性后打包交易。
|
||||
|
||||
5. **铸造完成**：XTZH智能合约执行`mint`函数，将新铸造的XTZH发送到资产发行方账户。
|
||||
|
||||
**输出结果**：
|
||||
- XTZH铸造交易哈希
|
||||
- 发行方账户XTZH余额更新
|
||||
|
||||
### 2.8 权益代币发行模块
|
||||
|
||||
权益代币发行模块负责发行代表资产权益的ACC-20或ACC-1400标准代币，实现资产的数字化和可交易性。
|
||||
|
||||
**职责**：
|
||||
- 根据资产类型选择合适的代币标准
|
||||
- 部署智能合约并设置代币参数
|
||||
- 将代币所有权转移给发行方或投资者
|
||||
- 注册代币元数据到链上
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **选择代币标准**：
|
||||
- **ACC-20**：用于同质化权益，如债券收益权、租金收益权
|
||||
- **ACC-1400**：用于非同质化权益，如股权、房产所有权
|
||||
|
||||
2. **部署合约**：调用Charter合约工厂（Contract Factory）部署新的代币合约，设置以下参数：
|
||||
- 代币名称和符号
|
||||
- GNACS编码（关联资产DNA）
|
||||
- 总供应量
|
||||
- 初始持有者（发行方地址）
|
||||
- 转让限制规则（如锁定期、白名单等）
|
||||
|
||||
3. **转移所有权**：根据发行方的指示，将代币转移给初始投资者或保留在发行方账户。
|
||||
|
||||
4. **注册元数据**：将代币的详细信息（如资产描述、法律文件链接、估值报告等）注册到链上元数据存储。
|
||||
|
||||
**输出结果**：
|
||||
- 代币合约地址
|
||||
- 代币发行交易哈希
|
||||
|
||||
### 2.9 链上公示模块
|
||||
|
||||
链上公示模块负责将资产信息自动推送到区块链浏览器、钱包和交易所，实现资产的公开透明和可交易性。
|
||||
|
||||
**职责**：
|
||||
- 向区块链浏览器注册资产信息
|
||||
- 向合作钱包推送代币信息
|
||||
- 向合作交易所提交自动上币申请
|
||||
- 生成资产公示页面
|
||||
|
||||
**处理流程**：
|
||||
|
||||
1. **浏览器注册**：通过API向NAC公链的官方区块链浏览器提交资产信息，包括：
|
||||
- GNACS编码
|
||||
- 代币合约地址
|
||||
- 资产元数据（名称、描述、图片等）
|
||||
- 合规和估值报告链接
|
||||
|
||||
2. **钱包推送**：向合作钱包（如NAC Vision钱包）推送代币信息，用户打开钱包后可以自动看到新资产。
|
||||
|
||||
3. **交易所上币**：向合作交易所提交自动上币申请。由于资产已经通过完整的合规审查和宪法验证，交易所节点可以自动验证所有宪法收据（CR）并批准上币。
|
||||
|
||||
4. **生成公示页面**：在NAC公链的官方网站上生成资产公示页面，展示资产的完整信息、合规证明和交易数据。
|
||||
|
||||
**输出结果**：
|
||||
- 浏览器资产页面URL
|
||||
- 钱包推送确认
|
||||
- 交易所上币确认
|
||||
|
||||
---
|
||||
|
||||
## 一键上链流程详解
|
||||
|
||||
本节详细描述用户从提交资产信息到最终完成上链的完整流程。
|
||||
|
||||
### 3.1 用户提交
|
||||
|
||||
用户通过`nac-toolbox` CLI或Web界面提交资产信息。
|
||||
|
||||
**CLI命令示例**：
|
||||
```bash
|
||||
nac asset create --type real-estate --file asset-info.json
|
||||
```
|
||||
|
||||
**`asset-info.json`文件内容**：
|
||||
```json
|
||||
{
|
||||
"asset_type": "commercial_real_estate",
|
||||
"name": "上海陆家嘴商业大厦",
|
||||
"description": "位于上海陆家嘴金融区的甲级写字楼",
|
||||
"legal_documents": [
|
||||
"ipfs://Qm...产权证明",
|
||||
"ipfs://Qm...法律意见书"
|
||||
],
|
||||
"issuer_did": "did:nac:abc123...",
|
||||
"kyc_credential": "ipfs://Qm...KYC凭证",
|
||||
"jurisdiction": "CN-SH",
|
||||
"properties": {
|
||||
"area": "50000",
|
||||
"location": "上海市浦东新区陆家嘴环路1000号",
|
||||
"construction_year": "2020",
|
||||
"annual_rental_income": "50000000"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**系统响应**：
|
||||
- 编排引擎生成唯一的`AssetID`（如`asset_67890`）
|
||||
- 状态设置为`Pending`
|
||||
- 返回进度查询URL
|
||||
|
||||
### 3.2 合规审查
|
||||
|
||||
编排引擎自动调用AI合规审批模块。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **加载宪法规则**：从宪法状态读取`ASSET_COMPLIANCE_MIN_STANDARD`条款，获取商业地产的最低合规要求：
|
||||
- 发行方KYC等级≥2
|
||||
- 必须提供产权证明和法律意见书
|
||||
- 必须有合格托管机构托管
|
||||
|
||||
2. **验证法律文件**：AI模型从IPFS下载法律文件，进行OCR识别和内容分析，验证文件的真实性和完整性。
|
||||
|
||||
3. **检查KYC等级**：查询发行方的KYC凭证，确认等级为2级（已完成身份验证和资产证明）。
|
||||
|
||||
4. **生成合规结果**：输出`ComplianceResult`，包含合规性评分（如95分）和详细报告。
|
||||
|
||||
5. **提交CEE验证**：将合规结果提交给宪法执行引擎，CEE验证结果与宪法一致后签发`CR_compliance`收据。
|
||||
|
||||
**失败处理**：如果合规审查失败（如KYC等级不足），状态设置为`Failed`，并通知用户具体原因和改进建议。
|
||||
|
||||
### 3.3 资产估值
|
||||
|
||||
编排引擎调用AI估值模块进行资产估值。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **聚合预言机数据**：从多个预言机节点获取上海陆家嘴地区的市场数据：
|
||||
- 区域房价指数
|
||||
- 租金收益率
|
||||
- 空置率
|
||||
- 类似资产的交易价格
|
||||
|
||||
2. **运行估值模型**：根据宪法定义的不动产估值模型（收益法），计算资产价值：
|
||||
```
|
||||
资产价值 = 年租金收入 / 资本化率
|
||||
资本化率 = 无风险利率 + 风险溢价
|
||||
```
|
||||
假设年租金收入为5000万元人民币，资本化率为5%，则资产价值为10亿元人民币。
|
||||
|
||||
3. **SDR转换**：将资产价值转换为SDR计价（假设汇率为1 SDR = 10 CNY），得到1亿SDR。
|
||||
|
||||
4. **生成估值结果**：输出`ValuationResult`，包含估值金额（1亿SDR）、估值方法（收益法）、置信区间（±10%）和详细报告。
|
||||
|
||||
5. **提交CEE验证**：CEE验证估值方法是否符合宪法要求（如折现率参数是否在合理范围内），签发`CR_valuation`收据。
|
||||
|
||||
### 3.4 DNA生成
|
||||
|
||||
编排引擎调用DNA生成模块生成资产的GNACS编码和DNA。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **解析资产属性**：
|
||||
- 资产类型：商业地产（类别代码`1400`）
|
||||
- 风险权重：中等风险（代码`02`）
|
||||
- 管辖权：中国上海（代码`CN-SH`）
|
||||
- 合规等级：高合规（代码`A1`）
|
||||
|
||||
2. **生成GNACS编码**：调用GNACS编码器，生成48位编码：
|
||||
```
|
||||
1400-02-CN-SH-A1-67890-...（共48位）
|
||||
```
|
||||
|
||||
3. **创建DNA结构**：
|
||||
```json
|
||||
{
|
||||
"genome": {
|
||||
"asset_type": "commercial_real_estate",
|
||||
"issuer": "did:nac:abc123...",
|
||||
"initial_valuation": "100000000 SDR"
|
||||
},
|
||||
"phenotype": {
|
||||
"current_price": "100000000 SDR",
|
||||
"liquidity": "medium",
|
||||
"holders_count": 1
|
||||
},
|
||||
"evolution_history": [
|
||||
{
|
||||
"timestamp": "2026-02-19T10:00:00Z",
|
||||
"event": "created",
|
||||
"details": "Initial asset creation"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
4. **计算DNA哈希**：使用SHA3-384计算DNA结构的哈希值。
|
||||
|
||||
5. **提交CEE验证**：CEE调用`GNACS_VALIDATE`指令验证编码格式的正确性，签发`CR_dna`收据。
|
||||
|
||||
### 3.5 托管对接
|
||||
|
||||
编排引擎调用托管对接模块，与第三方托管机构建立托管关系。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **选择托管机构**：从宪法白名单中筛选符合条件的托管机构。假设选择"中国工商银行上海分行"作为托管机构。
|
||||
|
||||
2. **发送托管请求**：通过HTTPS API向托管机构发送请求：
|
||||
```json
|
||||
{
|
||||
"asset_dna": "DNA哈希",
|
||||
"gnacs_code": "1400-02-CN-SH-A1-67890-...",
|
||||
"valuation": "100000000 SDR",
|
||||
"legal_documents": ["ipfs://Qm...产权证明", "ipfs://Qm...法律意见书"],
|
||||
"issuer": "did:nac:abc123..."
|
||||
}
|
||||
```
|
||||
|
||||
3. **接收托管凭证**：托管机构审核后返回托管凭证：
|
||||
```json
|
||||
{
|
||||
"custody_receipt_id": "ICBC-SH-2026-001",
|
||||
"custodian": "中国工商银行上海分行",
|
||||
"asset_description": "上海陆家嘴商业大厦",
|
||||
"custody_period": "长期",
|
||||
"digital_signature": "托管机构签名"
|
||||
}
|
||||
```
|
||||
|
||||
4. **验证签名**：CEE验证托管机构的公钥是否在宪法白名单内，并验证数字签名的有效性。
|
||||
|
||||
5. **上链存证**：将托管凭证哈希提交到链上，签发`CR_custody`收据。
|
||||
|
||||
### 3.6 XTZH铸造
|
||||
|
||||
编排引擎调用XTZH铸造模块，基于资产估值铸造等值XTZH。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **计算铸造量**：根据宪法要求（125%覆盖率），计算应铸造的XTZH数量：
|
||||
```
|
||||
XTZH数量 = 1亿SDR × 125% = 1.25亿SDR
|
||||
```
|
||||
|
||||
2. **验证储备**：检查NAC公链的黄金储备是否足以支持新增的1.25亿SDR XTZH发行。假设当前储备充足。
|
||||
|
||||
3. **构造铸造交易**：创建XTZH铸造交易，附带所有历史宪法收据（`CR_compliance`, `CR_valuation`, `CR_dna`, `CR_custody`）。
|
||||
|
||||
4. **提交到网络**：将交易提交到CBPP共识网络。验证节点（Constitutional Block Producer, CBP）检查所有收据的有效性：
|
||||
- 验证`CR_compliance`：确认合规审查通过
|
||||
- 验证`CR_valuation`：确认估值方法符合宪法
|
||||
- 验证`CR_dna`：确认GNACS编码格式正确
|
||||
- 验证`CR_custody`：确认托管机构在白名单内
|
||||
|
||||
5. **铸造完成**：所有验证通过后，CBP打包交易并执行XTZH智能合约的`mint`函数，将1.25亿SDR的XTZH发送到发行方账户。
|
||||
|
||||
### 3.7 权益代币发行
|
||||
|
||||
编排引擎调用权益代币发行模块，发行代表资产权益的代币。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **选择代币标准**：由于商业地产的权益可以分割，选择ACC-20标准（同质化代币）。
|
||||
|
||||
2. **部署合约**：调用Charter合约工厂部署新的ACC-20代币合约，设置参数：
|
||||
```
|
||||
代币名称: "上海陆家嘴商业大厦权益代币"
|
||||
代币符号: "SHLJ-RE"
|
||||
GNACS编码: "1400-02-CN-SH-A1-67890-..."
|
||||
总供应量: 100,000,000（1亿枚，每枚代表1 SDR的权益）
|
||||
初始持有者: 发行方地址
|
||||
```
|
||||
|
||||
3. **转移所有权**：根据发行方的指示，将部分代币转移给初始投资者，或全部保留在发行方账户等待后续销售。
|
||||
|
||||
4. **注册元数据**：将代币的详细信息注册到链上元数据存储：
|
||||
```json
|
||||
{
|
||||
"token_address": "0xabc123...",
|
||||
"asset_name": "上海陆家嘴商业大厦",
|
||||
"asset_description": "位于上海陆家嘴金融区的甲级写字楼",
|
||||
"asset_image": "ipfs://Qm...资产图片",
|
||||
"legal_documents": ["ipfs://Qm...产权证明", "ipfs://Qm...法律意见书"],
|
||||
"valuation_report": "ipfs://Qm...估值报告",
|
||||
"compliance_report": "ipfs://Qm...合规报告"
|
||||
}
|
||||
```
|
||||
|
||||
5. **交易附带收据**：代币发行交易附带所有历史宪法收据，确保合规性可追溯。
|
||||
|
||||
### 3.8 链上公示
|
||||
|
||||
编排引擎调用链上公示模块，将资产信息推送到各个平台。
|
||||
|
||||
**处理步骤**：
|
||||
|
||||
1. **浏览器注册**：向NAC公链的官方区块链浏览器提交资产信息，生成资产公示页面：
|
||||
```
|
||||
https://explorer.nac.io/asset/1400-02-CN-SH-A1-67890
|
||||
```
|
||||
|
||||
2. **钱包推送**：向NAC Vision钱包推送代币信息。用户打开钱包后，可以在资产列表中看到"SHLJ-RE"代币，并查看详细信息。
|
||||
|
||||
3. **交易所上币**：向合作交易所（如NAC DEX）提交自动上币申请。交易所节点验证所有宪法收据后，自动批准上币申请，并在交易所上线"SHLJ-RE"代币。
|
||||
|
||||
4. **生成公示页面**：在NAC公链的官方网站上生成资产公示页面，展示：
|
||||
- 资产基本信息
|
||||
- 合规证明和估值报告
|
||||
- 托管凭证
|
||||
- 代币合约地址和交易数据
|
||||
- 实时价格和流动性数据
|
||||
|
||||
### 3.9 完成
|
||||
|
||||
编排引擎将状态设置为`Listed`，并通知用户：
|
||||
|
||||
```
|
||||
资产上链成功！
|
||||
AssetID: asset_67890
|
||||
GNACS编码: 1400-02-CN-SH-A1-67890-...
|
||||
代币合约地址: 0xabc123...
|
||||
代币符号: SHLJ-RE
|
||||
浏览器页面: https://explorer.nac.io/asset/1400-02-CN-SH-A1-67890
|
||||
交易所: NAC DEX（已上线）
|
||||
```
|
||||
|
||||
整个流程从提交到完成，通常可在**数分钟到数小时**内完成，具体取决于托管机构的响应速度和网络拥堵情况。
|
||||
|
||||
---
|
||||
|
||||
## 技术实现细节
|
||||
|
||||
### 5.1 宪法规则示例（CNNL）
|
||||
|
||||
NAC公链使用宪政神经网络语言（Constitutional Neural Network Language, CNNL）定义宪法规则。以下是资产上链最低合规要求的示例：
|
||||
|
||||
```cnnl
|
||||
constitution ASSET_COMPLIANCE_MIN_STANDARD
|
||||
level strategic
|
||||
description "资产上链最低合规要求"
|
||||
for_each asset
|
||||
requires:
|
||||
asset.issuer.kyc_level >= 2 and
|
||||
exists legal_opinion (legal_opinion.asset == asset) and
|
||||
exists custody_proof (custody_proof.asset == asset)
|
||||
```
|
||||
|
||||
宪法状态文件会自动生成相应的常量和数据结构，供AI模块和智能合约调用。
|
||||
|
||||
### 5.2 AI合规模型
|
||||
|
||||
AI合规模型基于预训练的自然语言处理（NLP）模型（如BERT变体）进行微调，专门用于分析法律文件和合规性验证。
|
||||
|
||||
**模型特性**：
|
||||
- **文件真伪验证**：通过OCR技术提取文本内容，分析文件的格式、签名和内容完整性，输出真伪评分（0-100分）。
|
||||
- **TEE运行环境**：模型在可信执行环境（Trusted Execution Environment, TEE）中运行，确保数据隐私和计算结果的可信性。
|
||||
- **远程认证**：模型输出结果附带TEE的远程认证报告，证明计算过程未被篡改。
|
||||
- **版本管理**：模型版本由宪法附录管理，升级需要辖区代表协商批准。
|
||||
|
||||
### 5.3 托管机构对接
|
||||
|
||||
托管机构需要在NAC公链注册，并将公钥存入宪法白名单。
|
||||
|
||||
**对接要求**：
|
||||
- **HTTPS通信**：所有API通信必须使用HTTPS协议，确保数据传输安全。
|
||||
- **数字签名**：托管机构返回的所有数据必须包含数字签名，使用托管机构的私钥签名。
|
||||
- **托管凭证哈希上链**：托管凭证的哈希值会被提交到链上，确保托管记录的不可篡改性。
|
||||
- **定期审计**：托管机构需要定期接受NAC公链治理机构的审计，确保托管资产的安全性和合规性。
|
||||
|
||||
### 5.4 宪法收据聚合
|
||||
|
||||
一笔资产上链交易可能包含多个宪法收据（CR）。为了提高效率，NAC公链使用默克尔树（Merkle Tree）聚合所有收据。
|
||||
|
||||
**聚合流程**：
|
||||
1. 将所有收据的哈希值作为叶子节点构建默克尔树
|
||||
2. 计算默克尔根（`receipt_root`）
|
||||
3. 将`receipt_root`存储在区块头中
|
||||
4. 节点验证交易时，并行验证所有收据的有效性
|
||||
|
||||
这种设计大大减少了链上存储开销，同时保持了收据的可验证性。
|
||||
|
||||
### 5.5 一键上链CLI
|
||||
|
||||
`nac-toolbox`是NAC公链的官方命令行工具，提供了丰富的资产管理命令。
|
||||
|
||||
**常用命令**：
|
||||
|
||||
```bash
|
||||
# 交互式创建资产
|
||||
nac asset create
|
||||
|
||||
# 使用配置文件创建资产
|
||||
nac asset create --type real-estate --file asset-info.json
|
||||
|
||||
# 查看资产上链进度
|
||||
nac asset status <AssetID>
|
||||
|
||||
# 列出用户的所有资产
|
||||
nac asset list
|
||||
|
||||
# 查看资产详细信息
|
||||
nac asset info <AssetID>
|
||||
|
||||
# 更新资产元数据
|
||||
nac asset update <AssetID> --file update-info.json
|
||||
```
|
||||
|
||||
### 5.6 宪法沙箱支持
|
||||
|
||||
用户可以在提交资产前，使用宪法沙箱模拟整个上链流程，提前发现潜在问题。
|
||||
|
||||
**沙箱功能**：
|
||||
- **合规性预检**：模拟合规审查，提前发现KYC等级不足、法律文件缺失等问题
|
||||
- **估值预测**：基于当前市场数据预测资产估值
|
||||
- **成本估算**：估算上链所需的Gas费用和托管费用
|
||||
- **流程可视化**：以图形化方式展示上链流程的每个步骤
|
||||
|
||||
**使用示例**：
|
||||
```bash
|
||||
nac sandbox simulate --file asset-info.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 安全与合规
|
||||
|
||||
### 6.1 宪法保障
|
||||
|
||||
NAC公链的一键上链系统完全由宪法驱动，所有规则来自宪法状态，AI和智能合约无权自行决定。
|
||||
|
||||
**宪法保障机制**：
|
||||
- **规则透明**：所有宪法条款公开可查，任何人都可以验证系统行为是否符合宪法
|
||||
- **规则稳定**：宪法升级需要辖区代表协商批准，确保规则不会被随意修改
|
||||
- **规则可审计**：每一步操作都生成宪法收据（CR），全流程可追溯
|
||||
- **规则强制执行**：验证节点（CBP）会严格检查所有收据的有效性，不符合宪法的交易会被拒绝
|
||||
|
||||
### 6.2 数据隐私
|
||||
|
||||
一键上链系统高度重视用户数据隐私，采用多种技术手段保护敏感信息。
|
||||
|
||||
**隐私保护措施**：
|
||||
- **链上存哈希**：法律文件、KYC凭证等敏感信息仅存储在IPFS或其他去中心化存储系统中，链上只存储哈希值
|
||||
- **TEE运行环境**：AI合规模型和估值模型在可信执行环境（TEE）中运行，确保数据不外泄
|
||||
- **零知识证明**：可选择性地使用零知识证明（ZK Proof）证明合规性，而不暴露具体的合规细节
|
||||
- **访问控制**：资产元数据和合规报告设置访问权限，只有授权用户才能查看
|
||||
|
||||
### 6.3 抗攻击
|
||||
|
||||
一键上链系统采用多种机制抵御各类攻击。
|
||||
|
||||
**抗攻击措施**：
|
||||
- **预言机数据聚合**：从多个可信预言机节点获取市场数据，使用中位数聚合，抗单点操纵
|
||||
- **托管机构白名单**：托管机构由宪法白名单管理，定期审计，防止恶意托管机构
|
||||
- **宪法收据验证**：所有交易必须附带有效的宪法收据，防止绕过合规审查
|
||||
- **宪法免疫系统**：实时监控异常行为，如大量失败的合规审查、异常的估值结果等，及时预警和干预
|
||||
|
||||
### 6.4 审计追踪
|
||||
|
||||
一键上链系统的每一步操作都生成详细的日志和宪法收据，支持事后审计和争议解决。
|
||||
|
||||
**审计追踪机制**：
|
||||
- **宪法收据链**：每个资产都有完整的宪法收据链，记录从提交到上线的所有关键步骤
|
||||
- **操作日志**：编排引擎记录所有操作日志，包括模块调用、参数、结果和时间戳
|
||||
- **区块链存证**：关键数据（如托管凭证哈希、DNA哈希）永久存储在区块链上，不可篡改
|
||||
- **审计接口**：提供标准化的审计接口，监管机构和第三方审计机构可以查询和验证任何资产的上链过程
|
||||
|
||||
---
|
||||
|
||||
## 治理与宪法约束
|
||||
|
||||
### 7.1 资产类型扩展
|
||||
|
||||
NAC公链支持的资产类型由宪法定义。新资产类型的添加需要通过宪法修正案流程。
|
||||
|
||||
**扩展流程**：
|
||||
1. **提案提交**：任何辖区代表或社区成员可以提交新资产类型的提案，包括资产描述、合规要求、估值模型参数等
|
||||
2. **辖区协商**：各辖区代表对提案进行讨论和协商，评估新资产类型的合规性和可行性
|
||||
3. **投票表决**：辖区代表投票表决，需要三分之二多数通过
|
||||
4. **宪法更新**：提案通过后，宪法状态更新，新资产类型正式生效
|
||||
5. **系统升级**：AI模块和智能合约自动加载新的宪法规则，支持新资产类型的上链
|
||||
|
||||
### 7.2 托管机构准入/退出
|
||||
|
||||
托管机构的准入和退出由宪法白名单管理，确保托管服务的质量和安全性。
|
||||
|
||||
**准入流程**：
|
||||
1. **资质审查**：托管机构提交资质证明，包括营业执照、托管业务许可、财务报告等
|
||||
2. **辖区签署**：托管机构所在辖区的代表签署准入协议，确认托管机构符合当地法律法规
|
||||
3. **公钥注册**：托管机构的公钥被添加到宪法白名单，用于验证托管凭证的数字签名
|
||||
4. **定期审计**：托管机构需要定期接受NAC公链治理机构的审计，确保托管资产的安全性
|
||||
|
||||
**退出流程**：
|
||||
1. **提前通知**：托管机构需要提前通知NAC公链治理机构，说明退出原因和时间表
|
||||
2. **资产交接**：托管机构需要完成所有已托管资产的交接，将资产转移给其他合格托管机构
|
||||
3. **公钥移除**：托管机构的公钥从宪法白名单中移除，不再接受新的托管请求
|
||||
4. **历史记录保留**：托管机构的历史托管记录永久保留在链上，用于审计和争议解决
|
||||
|
||||
### 7.3 XTZH铸造参数
|
||||
|
||||
XTZH的铸造参数由宪法条款`XTZH_GOLD_COVERAGE`定义，确保XTZH的价值稳定性。
|
||||
|
||||
**当前参数**：
|
||||
- **黄金覆盖率**：125%（即每铸造1 SDR的XTZH，需要1.25 SDR的黄金储备）
|
||||
- **储备管理**：NAC公链的黄金储备由专业的托管机构管理，定期审计和公示
|
||||
- **参数调整**：任何对黄金覆盖率的调整都需要辖区代表三分之二多数同意，并通过宪法修正案流程
|
||||
|
||||
### 7.4 估值模型更新
|
||||
|
||||
估值模型的版本和参数由宪法附录管理，确保估值的公正性和一致性。
|
||||
|
||||
**更新流程**：
|
||||
1. **模型提案**：专业机构或社区成员提交新的估值模型或参数调整提案
|
||||
2. **专家评审**：邀请独立的估值专家和经济学家对提案进行评审
|
||||
3. **辖区协商**：各辖区代表对提案进行讨论和协商
|
||||
4. **投票表决**：辖区代表投票表决，需要三分之二多数通过
|
||||
5. **模型部署**：提案通过后，新的估值模型部署到AI估值模块，并更新宪法附录
|
||||
|
||||
---
|
||||
|
||||
## 实施路线图
|
||||
|
||||
NAC公链的一键上链系统将分阶段实施，确保每个阶段的功能稳定可靠。
|
||||
|
||||
| 阶段 | 时间 | 交付物 |
|
||||
|------|------|--------|
|
||||
| **Phase 1** | 2026.02-03 | 一键上链编排引擎原型，支持基本资产类型（如商业地产、股权） |
|
||||
| **Phase 2** | 2026.03-04 | AI合规/估值模块集成，宪法收据签发机制 |
|
||||
| **Phase 3** | 2026.04-05 | 托管机构对接协议标准化，首个试点托管机构接入 |
|
||||
| **Phase 4** | 2026.05-06 | XTZH铸造与代币发行模块，浏览器/钱包自动注册 |
|
||||
| **Phase 5** | 2026.06-07 | 交易所自动上币对接，宪法沙箱支持 |
|
||||
| **Phase 6** | 2026.07 | 主网上线，首批资产一键上链 |
|
||||
|
||||
**Phase 1详细计划**：
|
||||
- 开发编排引擎核心框架，实现状态机管理
|
||||
- 支持商业地产和股权两种基本资产类型
|
||||
- 实现简化的合规审查和估值流程
|
||||
- 提供CLI和Web界面原型
|
||||
|
||||
**Phase 2详细计划**：
|
||||
- 集成AI合规模型，支持法律文件真伪验证
|
||||
- 集成AI估值模型，支持多种估值方法
|
||||
- 实现宪法执行引擎（CEE），支持宪法收据签发
|
||||
- 完善错误处理和重试机制
|
||||
|
||||
**Phase 3详细计划**：
|
||||
- 制定托管机构对接协议标准
|
||||
- 接入首个试点托管机构（如中国工商银行）
|
||||
- 实现托管凭证验证和上链存证
|
||||
- 测试完整的合规-估值-托管流程
|
||||
|
||||
**Phase 4详细计划**：
|
||||
- 实现XTZH铸造模块，支持基于资产估值的自动铸造
|
||||
- 实现权益代币发行模块，支持ACC-20和ACC-1400标准
|
||||
- 集成区块链浏览器和钱包，支持自动注册
|
||||
- 测试完整的代币发行和公示流程
|
||||
|
||||
**Phase 5详细计划**：
|
||||
- 对接首个合作交易所（如NAC DEX）
|
||||
- 实现自动上币申请和审批流程
|
||||
- 开发宪法沙箱，支持上链流程模拟
|
||||
- 进行压力测试和安全审计
|
||||
|
||||
**Phase 6详细计划**：
|
||||
- 主网正式上线
|
||||
- 首批资产（如10个商业地产项目）一键上链
|
||||
- 监控系统运行状态，及时处理异常
|
||||
- 收集用户反馈，持续优化系统
|
||||
|
||||
---
|
||||
|
||||
## 结论
|
||||
|
||||
NAC公链的一键上链系统，通过宪法驱动、AI执行、全流程自动化，彻底改变了真实世界资产（RWA）上链的方式。它不再是耗时数周、成本高昂的复杂工程，而是普通用户也能轻松操作的"一键式"服务。所有规则透明、可审计、不可干预，确保合规与安全。
|
||||
|
||||
这是NAC公链"完美中心化框架下的去中心化"理念在资产上链领域的最佳实践。通过宪法层的规则约束、AI层的智能执行、协议层的技术支撑和开发者工具栈的易用性，NAC公链为全球资产数字化和权益化提供了一条清晰、可靠、高效的路径。
|
||||
|
||||
我们相信，随着一键上链系统的不断完善和推广，越来越多的真实世界资产将通过NAC公链实现数字化，为全球投资者提供更多元化的投资选择，为资产所有者提供更便捷的融资渠道，为整个金融体系带来更高的效率和透明度。
|
||||
|
||||
---
|
||||
|
||||
**制定人**：NAC资产上链工作组
|
||||
**最后更新**：2026年2月19日
|
||||
**文档状态**：正式发布
|
||||
**版本**：1.0
|
||||
|
||||
---
|
||||
|
||||
## 附录
|
||||
|
||||
### 附录A：术语表
|
||||
|
||||
| 术语 | 英文 | 定义 |
|
||||
|------|------|------|
|
||||
| RWA | Real World Assets | 真实世界资产，如房地产、股权、债权等 |
|
||||
| GNACS | Global NAC Asset Classification System | 全球NAC资产分类系统，48位编码 |
|
||||
| DNA | Digital Native Asset | 数字原生资产，包含基因组、表型和进化历史 |
|
||||
| CEE | Constitutional Execution Engine | 宪法执行引擎，负责签发宪法收据 |
|
||||
| CR | Constitutional Receipt | 宪法收据，证明操作符合宪法 |
|
||||
| XTZH | - | NAC公链的稳定币，以SDR计价，黄金储备支持 |
|
||||
| ACC-20 | Asset Compliance Contract 20 | NAC公链的同质化代币标准 |
|
||||
| ACC-1400 | Asset Compliance Contract 1400 | NAC公链的非同质化代币标准 |
|
||||
| CBPP | Constitutional Block Production Protocol | 宪政区块生产协议，NAC公链的共识机制 |
|
||||
| CSNP | Constitutional State Network Protocol | 宪政状态网络协议，NAC公链的网络协议 |
|
||||
| NVM | NAC Virtual Machine | NAC虚拟机，执行智能合约 |
|
||||
| Charter | - | NAC公链的智能合约语言 |
|
||||
| CNNL | Constitutional Neural Network Language | 宪政神经网络语言，定义宪法规则 |
|
||||
| TEE | Trusted Execution Environment | 可信执行环境，保护数据隐私 |
|
||||
| SDR | Special Drawing Rights | 特别提款权，国际货币基金组织的记账单位 |
|
||||
|
||||
### 附录B：参考资料
|
||||
|
||||
1. NAC公链宪法层规范
|
||||
2. NAC公链AI层规范
|
||||
3. NAC公链协议层规范
|
||||
4. GNACS编码标准文档
|
||||
5. XTZH价值稳定机制白皮书
|
||||
6. ACC-20代币标准文档
|
||||
7. ACC-1400代币标准文档
|
||||
8. Charter智能合约语言规范
|
||||
9. CNNL语言规范
|
||||
|
||||
### 附录C：联系方式
|
||||
|
||||
**技术支持**：tech-support@nac.io
|
||||
**商务合作**：business@nac.io
|
||||
**社区讨论**：https://forum.nac.io
|
||||
**官方网站**：https://nac.io
|
||||
|
||||
---
|
||||
|
||||
**© 2026 NAC Foundation. All rights reserved.**
|
||||
Loading…
Reference in New Issue