# NAC公链核心组件关系解析：宪法引擎与CBPP、CNNL、CSNP的协同
Issue #60 | 版本: 1.0 | 制定方: NAC架构委员会 | 发布日期: 2026年2月18日

## 一、核心组件定位

| 组件 | 全称 | 层级 | 核心职责 |
|------|------|------|---------|
| CNNL | Constitutional Neural Network Language | L2 宪法层 | 宪法条款的声明式编程语言，定义全网最高规则 |
| CEE | Constitutional Execution Engine（宪法引擎）| L2 宪法层 | 根据CNNL编译的宪法状态，验证交易合规性并签发宪法收据（CR）|
| CBPP | Constitutional Block Production Protocol | L1 协议层 | 基于宪法收据的区块生产共识协议 |
| CSNP | Constitutional Structured Network Protocol | L1 协议层 | 资产感知、法治化路由的网络协议 |

## 二、核心关系图解

```
┌─────────────────────────────────────────────────────────────┐
│                     宪法层（L2）                             │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐             │
│  │  CNNL    │───▶│宪法状态文件│───▶│   CEE    │             │
│  │  立法    │    │ (编译产物)│    │  执法    │             │
│  └──────────┘    └──────────┘    └─────┬────┘             │
│                                         │签发宪法收据(CR)   │
└─────────────────────────────────────────┼─────────────────┘
                                          ↓
┌─────────────────────────────────────────────────────────────┐
│                     协议层（L1）                             │
│  ┌──────────────────────┐    ┌──────────────────────────┐  │
│  │        CBPP          │    │          CSNP            │  │
│  │  接收CR → 生产区块   │◀──▶│  路由CR → 传播区块       │  │
│  │  "节点产生即共识"    │    │  资产感知路由             │  │
│  └──────────────────────┘    └──────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
```

## 三、数据流向

### 3.1 正向流（交易提交到上链）

```
用户交易
  → CSNP 路由（资产感知，找到正确节点）
  → CEE 验证（对照 CNNL 编译的宪法状态）
  → 签发 CR（宪法收据，含合规证明）
  → CBPP 打包（携带 CR 的交易进入区块）
  → CSNP 广播（区块通过法治化路由传播）
  → 全网确认
```

### 3.2 反向流（宪法更新）

```
CNNL 新条款提案
  → 治理投票（XIC 持有者）
  → CNNL 编译器编译
  → 新宪法状态文件
  → CEE 热更新（无需停机）
  → CBPP 自动适应新规则
  → CSNP 路由规则同步更新
```

## 四、关键接口定义

### 4.1 CEE → CBPP 接口

```rust
// 宪法收据（CR）- CBPP 区块生产的必要条件
pub struct ConstitutionalReceipt {
    pub tx_hash: [u8; 48],       // SHA3-384
    pub clause_ids: Vec<u32>,    // 验证通过的宪法条款 ID
    pub cee_signature: Vec<u8>,  // CEE 签名
    pub epoch: u64,              // 验证时的纪元
    pub is_valid: bool,
}

// CBPP 区块必须包含所有交易的 CR
pub struct Block {
    pub header: BlockHeader,
    pub transactions: Vec<Transaction>,
    pub receipts: Vec<ConstitutionalReceipt>, // 一一对应
}
```

### 4.2 CNNL → CEE 接口

```rust
// CNNL 编译产物 - 宪法状态文件
pub struct ConstitutionalState {
    pub version: u64,
    pub clauses: Vec<CompiledClause>,
    pub state_hash: [u8; 48],    // 全部条款的 Merkle 根
    pub effective_epoch: u64,
}

// CEE 加载宪法状态
impl ConstitutionalEngine {
    pub fn load_state(&mut self, state: ConstitutionalState) -> Result<(), CeeError>;
    pub fn validate_tx(&self, tx: &Transaction) -> Result<ConstitutionalReceipt, CeeError>;
}
```

### 4.3 CSNP → CEE 接口

```rust
// CSNP 路由时携带资产信息，CEE 据此选择适用的宪法条款
pub struct RoutingContext {
    pub asset_class: AssetClass,     // 资产类别（影响适用条款）
    pub jurisdiction: JurisdictionId, // 辖区（影响合规规则）
    pub sender_did: DID,
    pub receiver_did: DID,
}
```

## 五、协同保障机制

| 机制 | 描述 | 涉及组件 |
|------|------|---------|
| 宪法收据链 | 每个区块包含所有交易的 CR，形成不可篡改的合规证明链 | CEE + CBPP |
| 热更新 | CNNL 条款更新后，CEE 无需停机即可加载新状态 | CNNL + CEE |
| 辖区感知路由 | CSNP 根据资产类别和辖区，将交易路由到正确的 CEE 实例 | CSNP + CEE |
| 共识即合规 | CBPP 的共识过程本身就是合规验证过程，无额外开销 | CBPP + CEE |
| 双宪法收据 | 跨辖区交易需要两个辖区的 CEE 都签发 CR | CEE + CSNP |

## 六、与以太坊架构的本质区别

| 维度 | 以太坊 | NAC公链 |
|------|--------|---------|
| 合规性 | 事后链外合规 | 事前链上宪法验证 |
| 共识 | PoS（质押经济学）| CBPP（宪法收据驱动）|
| 网络 | P2P（无感知路由）| CSNP（资产感知路由）|
| 合约语言 | Solidity（图灵完备）| Charter（宪法约束）|
| 虚拟机 | EVM | NVM（宪法操作码）|
| 汇率 | 外部预言机 | XTZH 原生内置 |