8.1 KiB

Raw Blame History

NAC钱包核心技术白皮书 - 实现要点

一、钱包架构

核心模块

密钥管理模块 - 生成/存储/签名
账户管理模块 - 地址派生、余额查询、历史记录
交易构造模块 - 转账、合约调用、资产发行
宪法收据模块 - 向CEE请求CR、验证CR
资产解析模块 - GNACS解析、代币标准识别
网络通信模块 - 与节点RPC交互、与CEE交互
宪法沙箱模块 - 模拟交易合规性

底层依赖

nac-primitives (Address, Hash, 编码转换)
nac_serde (序列化)
nac-toolbox (可选，用于一键上链)
密码学库 (Ed25519, BLS, Dilithium)

二、密钥管理与账户模型

2.1 密钥生成

支持三种签名算法：

Ed25519 - 默认账户密钥，用于普通交易
BLS - 用于需要聚合签名的场景（如多签、跨链中继）
Dilithium5 - 后量子备选，用于高安全需求账户

助记词: 遵循BIP39，生成种子。派生路径遵循NAC标准: m/44'/626'/0'/0/index (其中626是NAC的BIP44 coin type，需向SLIP注册)

2.2 结构化地址生成

公钥经SHA3-384哈希，取前26字节，加上版本、类型、KYC等级、区域等字段，拼接成32字节Address。钱包应提供从公钥到结构化地址的完整计算。

地址字段:

version: 地址格式版本 (当前1)
type: 账户类型 (个人/企业/合约/系统)
kyc_level: KYC等级 (0-3)
region: 司法管辖区代码 (ISO3166-1)
pubkey_hash: 公钥哈希 (26字节)

2.3 密钥存储

加密: 使用AES-256-GCM加密私钥，密码派生自用户口令
存储格式: JSON文件 (类似Web3 Secret Storage)，包含加密私钥、地址、元数据（账户类型、KYC凭证哈希等）
硬件钱包支持: 计划支持Ledger、Trezor等硬件钱包，通过NAC App集成

三、交易构造与宪法收据

3.1 交易结构

NAC交易包含两部分：交易体 + 宪法收据 (CR)。CR必须在交易广播前获取。

message Transaction {
    bytes transaction_payload = 1; // 原始交易数据（类型、金额、目标等）
    ConstitutionalReceipt receipt = 2; // 宪法收据
}

3.2 交易构造流程

用户输入: 选择资产、输入接收地址、金额等
交易体构造: 钱包根据资产类型（XTZH、XIC、ACC-20代币）构造相应的交易体
向CEE请求CR:
- 钱包将交易体（或交易哈希）及辅助信息（如资产GNACS、KYC凭证）发送给CEE节点
- CEE验证交易符合宪法条款，返回CR
签名: 用户用私钥对交易体+CR的联合哈希签名（确保交易和CR绑定）
广播: 将完整交易（含签名）发送至NAC节点

3.3 宪法收据 (CR) 格式回顾

message ConstitutionalReceipt {
    bytes32 transaction_hash;
    bytes32 constitutional_hash;
    uint64 clause_mask;
    bytes32 execution_result_hash;
    uint64 timestamp;
    uint64 validity_window;
    repeated bytes signatures; // CEE节点签名
    bytes32 receipt_id;
}

钱包需验证CR的签名、宪法哈希是否匹配当前网络、是否在有效期内。

3.4 多CEE节点策略

钱包可配置多个CEE节点地址。请求CR时，可并行请求，取第一个有效响应，或等待多个签名（对于高价值交易）。若CEE节点无响应，可切换备用节点。

四、资产支持

4.1 原生代币

XTZH: 稳定币，用于支付、储备。单位: xtzh (精度1e6)。钱包需显示XTZH余额、汇率（与SDR/USD）
XIC: 治理币，用于支付交易费、质押。单位: xic (精度1e18)

4.2 ACC-20代币

通过合约地址识别，从链上获取GNACS编码
钱包解析GNACS，显示资产类型、风险等级、合规要求等信息
支持发送ACC-20代币，调用合约的transfer方法

4.3 ACC-1400证券型代币

支持分区余额（如普通股、员工股）
发送时需指定分区ID
钱包应展示不同分区的余额

4.4 GNACS解析

钱包内置GNACS解析器，将48位编码转换为人类可读信息：

资产类型（如"不动产收益权"）
风险权重（巴塞尔III）
合规等级（完全合规/高风险等）
实时状态（正常/冻结/注销）

五、与CEE交互协议

5.1 CEE节点发现

钱包可从链上系统合约（CEEList）获取当前活跃CEE节点列表（公钥、端点）。建议钱包缓存此列表，定期更新。

5.2 请求CR的API

POST /cee/v1/issue-receipt
Content-Type: application/json

{
    "transaction_hash": "0x...",
    "transaction_payload": "base64...", // 可选
    "auxiliary_data": {
        "kyc_proof": "...",
        "asset_gnacs": "..."
    }
}

响应:

{
    "receipt": { ... }, // CR对象
    "signature": "0x..." // CEE节点签名（已包含在CR中）
}

5.3 错误处理

CEE可能返回错误（如"KYC等级不足"、"资产已冻结"），钱包应解析错误信息并友好提示用户。

5.4 离线CR（高级）

对于特殊场景（如完全离线环境），CEE可提供预签名收据，但有效期较短。钱包需在有效期内广播交易。

六、离线与在线模式

6.1 在线模式

默认模式。钱包连接节点，实时查询余额、发送交易、获取CR。

6.2 离线模式

用户可在离线环境构造交易，导出待签名文件
将文件导入在线设备（或通过二维码）获取CR和广播
离线钱包需存储宪法状态文件（定期更新），用于本地解析宪法条款、验证CR签名、估算费用等

6.3 宪法状态同步

钱包定期从节点同步最新的宪法状态文件（constitutional_state.json），用于本地解析宪法条款、验证CR签名、估算费用等。

七、宪法沙箱集成

钱包应集成宪法沙箱（nac sandbox），允许用户在发送真实交易前模拟交易结果。

用户选择"测试模式"，钱包调用本地沙箱API，模拟交易执行，返回合规性结果、预估费用、CR等
沙箱模式不消耗真实XIC，适合新手学习和复杂交易验证

八、与nac-toolbox及一键上链系统的联动

钱包将作为nac-toolbox的一部分，提供CLI和API，同时也有独立的图形界面版本（桌面/移动/Web）。所有钱包实现必须通过宪法法院的审计，确保不泄露私钥、不篡改交易。

一键上链过程中，需要用户签名资产发行交易，钱包负责签名并将交易提交
钱包提供"资产发行"界面，引导用户完成信息填写（可复用一键上链前端部分逻辑）

九、安全与审计

9.1 私钥安全

私钥永不离设备，不通过网络发送
支持硬件钱包、生物识别等额外保护

9.2 交易验证

钱包在签名前必须向用户展示完整的交易详情（包括接收地址、金额、资产类型、CR信息）
高风险交易（如资产发行、大额转账）需二次确认

9.3 代码审计

钱包代码必须开源，并接受宪法法院授权的第三方审计
每次发布新版本，需提交审计报告，版本哈希上链存证

9.4 宪法免疫集成

钱包可集成宪政免疫系统客户端，定期检查自身代码哈希与链上合法版本是否一致，防止篡改。

十、路线图

阶段	时间	交付物
Phase 1	2026.02-03	CLI钱包原型，支持XTZH/XIC转账、CR获取
Phase 2	2026.03-04	ACC-20/ACC-1400资产支持、GNACS解析
Phase 3	2026.04-05	图形界面钱包（Web/桌面）
Phase 4	2026.05-06	移动端钱包（iOS/Android）
Phase 5	2026.06	硬件钱包支持、宪法沙箱集成
Phase 6	2026.07	主网上线，通过宪法法院审计

十一、结论

NAC钱包是连接用户与宪法区块链的桥梁。它不仅管理密钥和资产，更确保每一笔交易在宪法框架内合规执行。通过深度集成CEE、GNACS、宪法状态等NAC原生特性，钱包成为NAC生态中不可或缺的"合规入口"。所有实现均遵循开源、可审计原则，与NAC"宪美中心化框架下的去中心化"理念一脉相承。

制定人: NAC钱包工作组 最后更新: 2026年2月14日 文档状态: 正式发布

8.1 KiB Raw Blame History Unescape Escape