182 lines
9.9 KiB
Markdown
182 lines
9.9 KiB
Markdown
# CBPP技术白皮书关键发现
|
||
|
||
## 文档来源
|
||
宪政区块生产协议（CBPP）技术白皮书 - 基于"宪法即共识"的下一代RWA公链核心架构
|
||
|
||
## 核心创新点
|
||
|
||
### 1. 设计哲学：从"共识达成"到"规则服从"
|
||
|
||
传统区块链的共识机制（PoW, PoS, BFT等）核心在于让分布式节点对"什么是下一个有效区块"达成一致。
|
||
|
||
**CBPP的核心创新**：将共识问题转化为**规则验证问题**
|
||
|
||
1. **最高规则（宪法）预先确定且不可违逆**
|
||
- 所有关于交易有效性、区块结构、网络行为的规则
|
||
- 由L2宪法层通过严谨的民主程序产生，并固化为L1的确定性代码
|
||
|
||
2. **共识是规则的自然结果**
|
||
- 任何节点，只要其行为（打包交易、生成区块、传播数据）严格符合宪法规则
|
||
- 就自动成为网络共识的一部分
|
||
- **节点间无需"谁对谁错"进行投票，只需独立验证"是否合规"**
|
||
|
||
3. **生产权与验证权合一**
|
||
- 传统架构中，矿工/验证者生产区块，全节点验证区块
|
||
- 在CBPP中，**每一个全节点都是潜在的生产者**
|
||
- 其生产区块的权利，来源于其严格遵循规则的行为本身
|
||
|
||
### 2. 三大核心技术支柱
|
||
|
||
#### 2.1 宪法收据（Constitutional Receipt, CR）
|
||
|
||
**定义**：任何试图改变链状态的操作（交易），必须首先获得一个由"宪法执行引擎"签发的数字凭证，证明该操作已通过宪法所有相关条款的校验。
|
||
|
||
**作用**：将链下复杂的合规、估值、审批流程的结果，转化为链上可快速验证、标准化的"合法性证明"。它是交易进入区块链世界的**唯一门票**。
|
||
|
||
**数据结构**：
|
||
```protobuf
|
||
message ConstitutionalReceipt {
|
||
bytes32 transaction_hash; // 对应交易的哈希
|
||
bytes32 constitutional_hash; // 当前宪法版本哈希
|
||
uint64 clause_index; // 触发的主要宪法条款索引
|
||
bytes32 execution_result_hash; // AI引擎执行结果的Merkle根
|
||
uint64 timestamp; // 收据生成时间
|
||
uint64 validity_window; // 收据有效期（如120个区块高度）
|
||
bytes validator_signature; // 宪法执行引擎（或指定验证组）的签名
|
||
bytes32 receipt_id; // ReceiptID = Hash(上述所有字段)
|
||
}
|
||
```
|
||
|
||
**关键特性**：
|
||
1. **宪法绑定**：`constitutional_hash`确保收据只在特定宪法版本下有效。宪法升级后，旧收据自动失效。
|
||
2. **结果可验证**：`execution_result_hash`允许在不泄露细节（如具体估值报告）的情况下，验证AI校验结果的存在性与一致性。
|
||
3. **时效性**：`validity_window`防止交易被无限期延迟打包，确保市场条件与估值的一致性。
|
||
|
||
#### 2.2 开放生产网络（Open Production Network, OPN）
|
||
|
||
**定义**：任何满足最低技术要求（硬件、带宽）并完成身份绑定（DID+KYC）的节点，均可注册成为"宪法区块生产者"（Constitutional Block Producer, CBP）。
|
||
|
||
**机制**：CBP无需质押代币，其权力来源于对规则的掌握与执行。网络通过**基于收据验证的Gossip协议和经济激励机制**，确保诚实节点主导网络。
|
||
|
||
**节点类型与资格**：
|
||
|
||
| 节点类型 | 资格要求 | 核心职责 | 激励 |
|
||
|---------|---------|---------|------|
|
||
| 宪法区块生产者 | 1. 注册DID并完成KYC L2+2<br>2. 满足硬件带宽基准<br>3. 通过宪法知识测试 | 1. 验证并打包带CR的交易<br>2. 生成并签名合规区块<br>3. 传播区块与交易 | 出块奖励 + 交易费(XIC) |
|
||
| 全验证节点 | 无身份要求，可匿名运行 | 1. 同步并验证全链数据<br>2. 验证区块和交易的CR<br>3. 传播数据，监督CBP | 无（维护网络健康与安全） |
|
||
| 宪法执行引擎 | 由治理委员会授权 | 1. 执行宪法条款<br>2. 签发宪法收据 | 服务费(XIC) |
|
||
|
||
**CBP注册流程**：
|
||
1. 节点运营商用其DID发起注册交易
|
||
2. 抵押少量XIC（如100 XIC）作为注册保证金（可退还，主要用于防女巫攻击）
|
||
3. 完成一个包含宪法核心条款的链上测试（确保理解规则）
|
||
4. 注册成功，公开加入"活跃CBP列表"
|
||
|
||
#### 2.3 流体区块模型（Fluid Block Model, FBM）
|
||
|
||
**定义**：摒弃固定大小/固定间隔的区块。区块作为交易的**自然容器**，其容量和生成频率由实时网络交易负载动态决定。
|
||
|
||
**实现**：通过"软上限动态调整"和"交易驱动出块"算法，使网络在吞吐量需求平滑地随需求扩张，同时在低负载时保持低能耗。
|
||
|
||
### 3. 系统层级架构
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ L2: 宪法治理层 (Governance) │
|
||
│ · XIC持有者提案与投票 · 宪法条款修订 · 紧急仲裁 │
|
||
└─────────────────────────────────────────────────────┘
|
||
↓ (宪法哈希同步)
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ L1: 宪法协议层 (Protocol) │
|
||
│ ├─ 宪法执行引擎 (CEE) -- 签发宪法收据 (CR) │
|
||
│ ├─ 宪政区块生产协议 (CBPP) 核心逻辑 │
|
||
│ │ ├─ 开放生产网络 (OPN) 节点管理 │
|
||
│ │ ├─ 流体区块模型 (FBM) 动态调整器 │
|
||
│ │ └─ 收据验证Gossip协议 (RVGP) │
|
||
│ └─ ACC-20/ACC-20C 等原生资产协议 (保持不变，受宪法约束) │
|
||
└─────────────────────────────────────────────────────┘
|
||
↓ (P2P 网络传输)
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ 网络层: P2P 网络与数据传播 │
|
||
│ · 基于Libp2p · 交易/区块传播 · 节点发现与评分 │
|
||
└─────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 4. 核心工作流
|
||
|
||
#### 4.1 交易生命周期
|
||
```
|
||
用户发起交易 → 宪法执行引擎(CEE)校验 → 获得宪法收据(CR) → 广播带CR的交易 →
|
||
CBP节点收集验证 → 打包入流体区块 → 网络传播与收敛
|
||
```
|
||
|
||
#### 4.2 区块生产周期
|
||
```
|
||
CBP节点监听有效交易 → 满足出块条件的打包 → 生成并签名区块 → 广播区块 → 其他节点
|
||
验证收据与规则 → 接受并传播/拒绝 → 链状态更新
|
||
```
|
||
|
||
## 与NVM的关联性分析
|
||
|
||
### 可借鉴的设计理念
|
||
|
||
1. **宪法收据（CR）机制**
|
||
- 可以作为NVM的**合规验证层**
|
||
- 在ACC协议层之上增加一个宪法验证层
|
||
- 所有RWA资产操作必须先获得CR才能执行
|
||
|
||
2. **开放生产网络（OPN）**
|
||
- 可以替代传统的PoS/PoW共识
|
||
- 任何满足条件的节点都可以成为区块生产者
|
||
- 通过KYC+DID实现合规的去中心化
|
||
|
||
3. **流体区块模型（FBM）**
|
||
- 动态调整区块大小和生成频率
|
||
- 提高网络吞吐量和响应速度
|
||
- 特别适合RWA交易的不规则负载特性
|
||
|
||
### 建议的集成方案
|
||
|
||
```
|
||
NVM v2 + CBPP 集成架构:
|
||
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ L2: 宪法治理层 (Governance) │
|
||
│ XIC持有者投票、宪法修订、紧急仲裁 │
|
||
└─────────────────────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ ACC协议层 + 宪法执行引擎 (CEE) │
|
||
│ 所有ACC协议操作必须先通过CEE验证获得CR │
|
||
└─────────────────────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ NVM-L1 (智能合约层) + CR验证 │
|
||
│ 执行合约前验证CR的有效性 │
|
||
└─────────────────────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ NVM-L0 (共识层) + CBPP │
|
||
│ 使用OPN + FBM替代传统DAG共识 │
|
||
└─────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 下一步行动
|
||
|
||
1. **实现宪法收据（CR）模块**
|
||
- 在NVM-L0中添加CR验证逻辑
|
||
- 定义CR数据结构和验证接口
|
||
|
||
2. **实现开放生产网络（OPN）**
|
||
- 替换当前的DagConsensus
|
||
- 实现CBP注册和管理机制
|
||
|
||
3. **实现流体区块模型（FBM）**
|
||
- 动态调整区块大小
|
||
- 实现交易驱动的出块机制
|
||
|
||
4. **集成测试**
|
||
- 测试CR + ACC协议的集成
|
||
- 测试OPN的区块生产流程
|
||
- 性能测试和优化
|