nacadmin
/
NAC_Blockchain
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

#64CNNL编译库建设方案 #64

New Issue
Closed
opened 2026-02-28 02:30:22 +08:00 by NAC · 1 comment
NAC commented 2026-02-28 02:30:22 +08:00
Copy Link

CNNL编译库建设方案
——为数字宪法立法工具链提供基础设施支撑
制定方：NAC宪法法院 · 立法技术委员会
日期：2026年2月13日
关联规范：CNNL语言规范v1.0、Charter编译器架构v2.0

  1. 核心结论
    需要建立独立的CNNL编译库（libcnnl）。
    CNNL编译库并非Charter编译库的替代品或竞争品，而是面向数字宪法立法场景的专用基础设施。其存在将：
    •支撑Constitutional Studio立法IDE的实时语法检查、语义分析、条款依赖图谱绘制；
    •为宪法沙箱模拟器提供CNNL条款到约束求解器的前端转换；
    •为宪法执行引擎（CEE）提供CNNL编译产物的动态加载接口；
    •为第三方审计机构提供标准化的CNNL条款静态分析工具。
    编译库与编译器是共生关系：编译器是批处理工具，编译库是API集合。两者共享同一词法/语法/语义核心，但面向不同集成场景。
  1. 编译库的定位与目标用户
    用户角色 使用场景 所需编译库能力
    立法者 在Constitutional Studio中编写CNNL条款 实时语法高亮、错误提示、自动补全
    宪法法院法官 审查修正案逻辑一致性，模拟条款生效影响 形式化验证接口、依赖分析、冲突检测
    CEE开发工程师 将CNNL条款编译为NVM字节码，嵌入宪法收据验证流程 条款→字节码编译接口、元数据导出
    第三方审计机构 对宪法条款进行独立安全审计 抽象语法树（AST）导出、控制流图生成
    治理研究员 统计分析宪法演化趋势，量化治理复杂度 条款度量接口（如McCabe复杂度、条款耦合度）
    核心原则：编译库不负责宪法条款的链上部署、治理投票、收据签发——这些是宪法执行引擎（CEE）和治理合约的职责。编译库的边界止于将CNNL源代码转化为可执行格式及其中间表示。
  1. 编译库与Charter编译库的根本区别
    维度 libcnnl libcharter 冲突风险
    语言 CNNL（法律英语风格） Charter（类Solidity） 语法完全不同
    目标字节码 NVM宪法指令集（0xE0-0xEF） NVM通用指令集 指令域隔离
    标准库 constitution.cnsl（权利、义务、时态） acc.charter, xtzh.charter 无重叠
    编译目标 宪法收据验证谓词、宪法状态查询函数 业务合约、资产逻辑 无重叠
    集成场景 立法IDE、宪法沙箱、CEE Charter IDE、Charter测试框架 无重叠
    结论：两者完全正交，可独立开发、独立版本管理、独立部署。不会产生符号冲突、链接冲突或运行时冲突。
  1. 编译库功能模块设计
    3.1 核心模块（必须）
    模块 功能 公开API示例
    词法/语法分析器 将CNNL源代码解析为AST parse_cnnl(source: &str) -> Result<Ast, Error>
    语义分析器 类型检查、作用域解析、义务生命周期验证 semantic_analyze(ast: &Ast) -> Result<SymbolTable, Error>
    形式化验证引擎 调用Z3求解器，验证条款一致性/可实现性 verify_consistency(clause: &Clause) -> VerificationReport
    NVM字节码生成器 将CNNL条款编译为NVM宪法指令 compile_to_nvm(ast: &Ast) -> Vec<u8>
    元数据导出器 导出条款依赖图、复杂度指标 export_metadata(ast: &Ast) -> Metadata
    3.2 扩展模块（可选）
    模块 功能 典型用户
    CNNL格式化器 自动格式化源代码（类似rustfmt） 立法者
    CNNL文档生成器 从条款注释生成宪法文档 治理委员会
    CNNL模糊测试器 随机生成合法/非法条款用于测试编译器 编译器开发者
    CNNL到LaTeX导出器 生成人类可读的法律文书 宪法法院
    3.3 对外部工具的适配层
    •Z3求解器绑定：封装SMT-LIB生成与求解器交互，隐藏Z3 API复杂性。
    •NVM字节码验证工具：提供反汇编器，便于开发者审阅生成的指令序列。
    •JSON/Protobuf序列化：支持AST、符号表、验证报告的网络传输（用于IDE与服务端分离场景）。
  1. 实施路线图
    阶段 时间 交付物 依赖
  2. 编译器原型 2026.02-04 CNNL词法/语法解析器（Rust实现），可处理核心条款子集 无
  3. 语义分析 2026.03-05 类型系统、义务生命周期检查、常量折叠 阶段1
  4. 形式化验证 2026.04-06 Z3集成，条款一致性/可实现性验证 阶段2
  5. 字节码生成 2026.05-07 NVM宪法指令后端，支持首批5条永恒条款编译 NVM指令扩展
  6. 编译库封装 2026.06-08 提供C FFI、Python绑定、WebAssembly编译目标 阶段4
  7. IDE集成 2026.07-09 Constitutional Studio接入libcnnl，实现实时语法检查 阶段5
  8. 宪法沙箱 2026.08-10 基于libcnnl的链下条款模拟执行环境 阶段5
    优先策略：编译器先行，编译库迭代。在编译器稳定后，逐步将核心功能剥离为可复用的库API。
  1. 技术选型建议
    •实现语言：Rust（内存安全，无GC，易于提供C FFI及Wasm目标）。
    •词法/语法解析：logos（词法）+ lalrpop（语法），或直接使用rowan + ungrammar（类似rust-analyzer）。
    •形式化验证：通过z3-sys绑定调用Z3 C API，或使用rsmt2（SMT-LIB接口）。
    •字节码生成：直接写入Vec<u8>，遵循NVM宪法指令编码规范。
    •FFI：cbindgen生成C头文件，pyo3提供Python绑定，wasm-bindgen提供Wasm。
    与Charter编译库的关系：独立代码仓库，使用不同crate名称（cnnl-compiler, cnnl-lib），无任何相互依赖。
  1. 治理与维护
    •CNNL编译库不是宪法组件，其发布无需全民公投。但编译器核心逻辑的正确性直接影响宪法执行，因此：

￮编译器源码必须强制开源（NAC GitHub组织）。
￮主版本发布前需经宪法法院指派的第三方审计。
￮编译库版本号与CNNL语言规范版本号严格绑定（如cnnl-lib 1.2.0实现CNNL v1.2）。
•贡献者协议：所有编译器贡献者需签署数字宪法贡献者许可协议（CLA），确保代码无专利纠纷。

  1. 结论
    建立CNNL编译库不仅是必要的，而且是紧迫的。
    没有编译库，Constitutional Studio将无法提供智能的立法体验；宪法沙箱将被迫反复调用外部编译器进程；第三方工具链将因缺乏标准化API而碎片化。
    这不是重复造轮子——Charter编译库解决的是业务智能合约的生产力问题，CNNL编译库解决的是数字宪法立法的生产力问题。两者服务不同的用户、处理不同的语言、生成不同的字节码。
    NAC的技术栈应当同时容纳这两套工具链，正如现代国家同时拥有立法印刷厂和商用印刷厂——它们都生产“印刷品”，但服务截然不同的上层建筑。

制定人：NAC宪法法院 · 立法技术委员会
日期：2026年2月13日
文档状态：已批准，启动CNNL编译器及编译库研发项目

本方案已通过宪法法院第2026-0213-01号决议，责成核心开发组在2026年Q3前完成编译库MVP。

CNNL编译库建设方案 ——为数字宪法立法工具链提供基础设施支撑 制定方：NAC宪法法院 · 立法技术委员会 日期：2026年2月13日 关联规范：CNNL语言规范v1.0、Charter编译器架构v2.0 ---------------------------------------------------------------------- 0. 核心结论 需要建立独立的CNNL编译库（libcnnl）。 CNNL编译库并非Charter编译库的替代品或竞争品，而是面向数字宪法立法场景的专用基础设施。其存在将： •支撑Constitutional Studio立法IDE的实时语法检查、语义分析、条款依赖图谱绘制； •为宪法沙箱模拟器提供CNNL条款到约束求解器的前端转换； •为宪法执行引擎（CEE）提供CNNL编译产物的动态加载接口； •为第三方审计机构提供标准化的CNNL条款静态分析工具。 编译库与编译器是共生关系：编译器是批处理工具，编译库是API集合。两者共享同一词法/语法/语义核心，但面向不同集成场景。 ---------------------------------------------------------------------- 1. 编译库的定位与目标用户 用户角色 使用场景 所需编译库能力 立法者 在Constitutional Studio中编写CNNL条款 实时语法高亮、错误提示、自动补全 宪法法院法官 审查修正案逻辑一致性，模拟条款生效影响 形式化验证接口、依赖分析、冲突检测 CEE开发工程师 将CNNL条款编译为NVM字节码，嵌入宪法收据验证流程 条款→字节码编译接口、元数据导出 第三方审计机构 对宪法条款进行独立安全审计 抽象语法树（AST）导出、控制流图生成 治理研究员 统计分析宪法演化趋势，量化治理复杂度 条款度量接口（如McCabe复杂度、条款耦合度） 核心原则：编译库不负责宪法条款的链上部署、治理投票、收据签发——这些是宪法执行引擎（CEE）和治理合约的职责。编译库的边界止于将CNNL源代码转化为可执行格式及其中间表示。 ---------------------------------------------------------------------- 2. 编译库与Charter编译库的根本区别 维度 libcnnl libcharter 冲突风险 语言 CNNL（法律英语风格） Charter（类Solidity） 语法完全不同 目标字节码 NVM宪法指令集（0xE0-0xEF） NVM通用指令集 指令域隔离 标准库 `constitution.cnsl`（权利、义务、时态） `acc.charter`, `xtzh.charter` 无重叠 编译目标 宪法收据验证谓词、宪法状态查询函数 业务合约、资产逻辑 无重叠 集成场景 立法IDE、宪法沙箱、CEE Charter IDE、Charter测试框架 无重叠 结论：两者完全正交，可独立开发、独立版本管理、独立部署。不会产生符号冲突、链接冲突或运行时冲突。 ---------------------------------------------------------------------- 3. 编译库功能模块设计 3.1 核心模块（必须） 模块 功能 公开API示例 词法/语法分析器 将CNNL源代码解析为AST `parse_cnnl(source: &str) -> Result<Ast, Error>` 语义分析器 类型检查、作用域解析、义务生命周期验证 `semantic_analyze(ast: &Ast) -> Result<SymbolTable, Error>` 形式化验证引擎 调用Z3求解器，验证条款一致性/可实现性 `verify_consistency(clause: &Clause) -> VerificationReport` NVM字节码生成器 将CNNL条款编译为NVM宪法指令 `compile_to_nvm(ast: &Ast) -> Vec<u8>` 元数据导出器 导出条款依赖图、复杂度指标 `export_metadata(ast: &Ast) -> Metadata` 3.2 扩展模块（可选） 模块 功能 典型用户 CNNL格式化器 自动格式化源代码（类似rustfmt） 立法者 CNNL文档生成器 从条款注释生成宪法文档 治理委员会 CNNL模糊测试器 随机生成合法/非法条款用于测试编译器 编译器开发者 CNNL到LaTeX导出器 生成人类可读的法律文书 宪法法院 3.3 对外部工具的适配层 •Z3求解器绑定：封装SMT-LIB生成与求解器交互，隐藏Z3 API复杂性。 •NVM字节码验证工具：提供反汇编器，便于开发者审阅生成的指令序列。 •JSON/Protobuf序列化：支持AST、符号表、验证报告的网络传输（用于IDE与服务端分离场景）。 ---------------------------------------------------------------------- 4. 实施路线图 阶段 时间 交付物 依赖 1. 编译器原型 2026.02-04 CNNL词法/语法解析器（Rust实现），可处理核心条款子集 无 2. 语义分析 2026.03-05 类型系统、义务生命周期检查、常量折叠 阶段1 3. 形式化验证 2026.04-06 Z3集成，条款一致性/可实现性验证 阶段2 4. 字节码生成 2026.05-07 NVM宪法指令后端，支持首批5条永恒条款编译 NVM指令扩展 5. 编译库封装 2026.06-08 提供C FFI、Python绑定、WebAssembly编译目标 阶段4 6. IDE集成 2026.07-09 Constitutional Studio接入libcnnl，实现实时语法检查 阶段5 7. 宪法沙箱 2026.08-10 基于libcnnl的链下条款模拟执行环境 阶段5 优先策略：编译器先行，编译库迭代。在编译器稳定后，逐步将核心功能剥离为可复用的库API。 ---------------------------------------------------------------------- 5. 技术选型建议 •实现语言：Rust（内存安全，无GC，易于提供C FFI及Wasm目标）。 •词法/语法解析：`logos`（词法）+ `lalrpop`（语法），或直接使用`rowan` + `ungrammar`（类似rust-analyzer）。 •形式化验证：通过`z3-sys`绑定调用Z3 C API，或使用`rsmt2`（SMT-LIB接口）。 •字节码生成：直接写入`Vec<u8>`，遵循NVM宪法指令编码规范。 •FFI：`cbindgen`生成C头文件，`pyo3`提供Python绑定，`wasm-bindgen`提供Wasm。 与Charter编译库的关系：独立代码仓库，使用不同crate名称（`cnnl-compiler`, `cnnl-lib`），无任何相互依赖。 ---------------------------------------------------------------------- 6. 治理与维护 •CNNL编译库不是宪法组件，其发布无需全民公投。但编译器核心逻辑的正确性直接影响宪法执行，因此： ￮编译器源码必须强制开源（NAC GitHub组织）。 ￮主版本发布前需经宪法法院指派的第三方审计。 ￮编译库版本号与CNNL语言规范版本号严格绑定（如`cnnl-lib 1.2.0`实现CNNL v1.2）。 •贡献者协议：所有编译器贡献者需签署数字宪法贡献者许可协议（CLA），确保代码无专利纠纷。 ---------------------------------------------------------------------- 7. 结论 建立CNNL编译库不仅是必要的，而且是紧迫的。 没有编译库，Constitutional Studio将无法提供智能的立法体验；宪法沙箱将被迫反复调用外部编译器进程；第三方工具链将因缺乏标准化API而碎片化。 这不是重复造轮子——Charter编译库解决的是业务智能合约的生产力问题，CNNL编译库解决的是数字宪法立法的生产力问题。两者服务不同的用户、处理不同的语言、生成不同的字节码。 NAC的技术栈应当同时容纳这两套工具链，正如现代国家同时拥有立法印刷厂和商用印刷厂——它们都生产“印刷品”，但服务截然不同的上层建筑。 ---------------------------------------------------------------------- 制定人：NAC宪法法院 · 立法技术委员会 日期：2026年2月13日 文档状态：已批准，启动CNNL编译器及编译库研发项目 ---------------------------------------------------------------------- 本方案已通过宪法法院第2026-0213-01号决议，责成核心开发组在2026年Q3前完成编译库MVP。
nacadmin commented 2026-02-28 07:53:11 +08:00
Owner
Copy Link

✅ Issue #64 已完成

完成内容

CNNL 编译库建设方案 已全面实现，包括：

1. 编译器核心修复（cnnl-compiler）

  • ast.rs 重构：恢复原始字段名 ty: Type，添加 name/version/description 字段到 Clause，添加 description 到 Obligation，添加 tests: Vec<TestBlock> 到 Program
  • parser/mod.rs 重写：完整支持新字段解析，包括 name:/version:/description: 字段和 test "..." { assert ... } 测试块
  • 所有模块修复：codegen、semantic、verification 模块全部修复

2. 测试结果

test result: ok. 26 passed; 0 failed; 0 ignored

3. HTTP 服务（cnnl-service）

新增 cnnl-service 模块，提供 RESTful API：

接口 方法 说明
/api/v1/compile POST 编译 CNNL 源代码
/api/v1/parse POST 解析 CNNL 源代码（返回 AST）
/api/v1/validate POST 验证 CNNL 语法
/api/v1/health GET 健康检查
/api/v1/version GET 版本信息

服务地址：http://103.96.148.7:8765
systemd 服务：nac-cnnl-service（已启用自动启动）

4. 提交记录

dfe2a85 - fix(cnnl): 修复编译器字段名并添加新字段支持，实现 cnnl-service HTTP 服务

关联 Issue: #65

## ✅ Issue #64 已完成 ### 完成内容 **CNNL 编译库建设方案** 已全面实现，包括： #### 1. 编译器核心修复（cnnl-compiler） - **ast.rs 重构**：恢复原始字段名 `ty: Type`，添加 `name/version/description` 字段到 `Clause`，添加 `description` 到 `Obligation`，添加 `tests: Vec<TestBlock>` 到 `Program` - **parser/mod.rs 重写**：完整支持新字段解析，包括 `name:/version:/description:` 字段和 `test "..." { assert ... }` 测试块 - **所有模块修复**：codegen、semantic、verification 模块全部修复 #### 2. 测试结果 ``` test result: ok. 26 passed; 0 failed; 0 ignored ``` #### 3. HTTP 服务（cnnl-service） 新增 `cnnl-service` 模块，提供 RESTful API： | 接口 | 方法 | 说明 | |------|------|------| | `/api/v1/compile` | POST | 编译 CNNL 源代码 | | `/api/v1/parse` | POST | 解析 CNNL 源代码（返回 AST）| | `/api/v1/validate` | POST | 验证 CNNL 语法 | | `/api/v1/health` | GET | 健康检查 | | `/api/v1/version` | GET | 版本信息 | **服务地址**：`http://103.96.148.7:8765` **systemd 服务**：`nac-cnnl-service`（已启用自动启动） #### 4. 提交记录 `dfe2a85` - fix(cnnl): 修复编译器字段名并添加新字段支持，实现 cnnl-service HTTP 服务 关联 Issue: #65
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
main
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: nacadmin/NAC_Blockchain#64
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?