为什么是 UTXO Compiler
让「可验证」重新成为结算层的产品。
用一段开发者熟悉的 Python-like 写法，换回一份节点能独立核对的确定性。
§ I
一、UTXO 模型与「状态即代码」
比特币用 UTXO（Unspent Transaction Output）模型：每笔交易消耗旧的 UTXO、产生新的 UTXO。每个 UTXO 携带「聪」与「锁定脚本」。要花费它，必须提交解锁脚本，与锁定脚本联合执行返回真。
写智能合约，本质上就是把自定义逻辑写进锁定脚本里——不只是签名校验，还可以是时间、数据格式、多方条件等任何可编程约束。
§ II
二、BVM 是一台基于栈的状态机
BVM（Bitcoin Virtual Machine）没有堆，没有全局变量，只有主栈与副栈和一组操作码。直接写 Opcode 容易出错；UTXO_Compiler 把高级 .ct 翻译为 BVM 字节码，让你不用每天和栈搏斗。
§ III
三、语言设计的关键取舍
- 显式类型声明
- 所有函数参数、结构体字段必须声明类型；没有 var / auto。在零容错的 BVM 里，「代码里看到什么，栈上就发生什么」比简洁更重要。
- 编译期所有权检查
- 变量被传入内置函数或赋值给其他变量后即被「消耗」，不能再次引用。这直接对应 BVM 的栈弹出语义；编译器把这类错误从「上链后失败」前置到「编译时就拦」。
- 状态固化在字节码
- 合约成员变量被编进字节码本身，不同数据生成不同锁定脚本。这是 UTXO 的「状态即代码」，与以太坊「合约地址 + 链上存储」根本不同。
- 单文件单合约
- 一个 .ct 文件只放一个合约，与「一个 UTXO 对应一段锁定脚本」天然对齐。
§ IV
四、横向对比
| 维度 | UTXO_Compiler .ct | sCrypt（BSV） | Bitcoin Script（原生） |
|---|---|---|---|
| 抽象层级 | 高级语言 | 高级语言 | 汇编级 |
| 语法风格 | Python-like | TypeScript-like | 操作码序列 |
| 类型系统 | 强类型 | 强类型 | 无类型 |
| 所有权检查 | 编译期 | — | — |
| 调试工具 | 内置交互式调试器 | 插件支持 | 无 |
| 构造函数 | 手动嵌入 | 支持 | 手动嵌入 |
§ V
五、我们诚实承认两件事
平台支持
当前 Linux 与 Windows 已上线，macOS 计划支持中。
生态成熟度
标准库的内置函数与对象在持续扩展中；社区示例还在积累期。我们更愿意把 UTXO_Compiler 定位成「开发中的基础设施」，而不是终点。