# 智能合约

## 通道合约

我们在闪电通道RSMC合约的基础上，将闪电网络RSMC合约框架，进一步升级成为一个协调多方动作的框架，我们称之为通道合约。

通道合约是一种多方认可并共同执行和维护的合约，可以认为就是多方签署了一份由源代码构成的合同，按照这些源代码规定的动作执行。合约目前以模版的方式提供，通过在聪网节点内置这些合约，确保合约的部署，运行和验证是分布式进行的。

通道合约实现了智能合约的部分功能，但是目前并不具备EVM的完整功能。 目前已经提供的这几类

* Transcend，资产穿越合约，替代闪电网络通道，任何人都可以跟该合约交互，自由在主网和聪网之间穿越资产（通过一个多签钱包和聪网交互）
* Launchpool，发射池合约。可以在主网部署资产ticker，铸造并自动穿越到聪网，在聪网做二次分发，发射成功后留下一个底池，支持AMM交易
* AMM，AMM交易合约，一个可以添加流动性的AMM交易池子，交易速度快，费用低，添加流动性还可以分享池子收益
* LimitOrder，限价单交易合约，不喜欢AMM交易模式的，也可以挂限价的买单或卖单，按照自己期望的价格进行交易

通道合约是聪网的关键创新之一，其潜力无限，支持WASM，这是聪网后续发展的重要支柱，其功能性和灵活性远远大于其他在比特币网络实现智能合约的方案。

## 脚本合约

将现有的btc脚本语言升级，使其成为一个图灵完备的脚本语言，这是一条在主网上已经探索并且推动多年的路径。不可否认这是一条可行的路径。但比特币网络的设计理念，其实跟链上实现图灵完备的脚本语言是冲突的。

比特币脚本（Bitcoin Script）从设计之初就是一种受限的、非图灵完备（non-Turing-complete）栈语言，它主要用于表达“这笔币可以在满足哪些条件时被花费”，而不是用于执行一般意义的计算。

一个开发语言是图灵完备的，当且仅当它能：

* 表达任意计算逻辑（条件、循环、递归等）
* 具备无限状态的能力（例如通过循环可无限运行）

而比特币脚本语言，缺少：

* while、for、goto 等循环结构
* 任意内存读写能力
* 动态跳转与函数调用
* 动态长度执行栈扩展（栈深有限）

因此，比特币脚本在设计上被严格限制为“有限计算”模型。这种设计原则，目标是为了：

* 防止拒绝服务攻击（DoS） 区块链上的每个节点都必须验证脚本。 如果脚本允许循环或递归，就可能造成无限执行或高复杂度执行。 这会导致一个恶意交易就能让节点CPU暴涨、验证阻塞。 而非图灵完备保证所有脚本在有限步内执行完毕。
* 可预测的验证成本 比特币每个交易的验证成本必须是确定的： 交易验证时间 = 区块传播时间 区块传播时间决定网络共识的稳定性 非图灵完备 → 验证复杂度固定上界，网络共识更安全。
* 简化安全审计 图灵完备语言极难完全验证安全性（Halting Problem）。 比特币脚本的非图灵完备性让每个分支都能静态分析，确定执行路径。
* 共识一致性与去中心化实现的现实约束 每个节点必须运行相同的脚本解释器。 复杂脚本语言更容易导致： 不同平台执行结果不一致（Endianness, Integer overflow） 实现差异（共识分叉）

因此，比特币故意不图灵完备，以确保主网的安全性、稳定性和可扩展性。这也是比特币分层设计哲学的体现。比特币主网（L1）只负责：

* 最终结算（Final settlement）
* 状态安全性与抗审查性

而复杂计算逻辑交给L2或侧链实现，闪电网络的设计本意，就是成为BTC网络的扩展网络。

从上面的讨论已经可以看出，比特币脚本的非图灵完备是设计的结果，不可能改变这个共识。即使社区现在很热的激活OP-CAT指令的呼声，也不可能改变这个共识。激活OP-CAT的BIP347方案大致内容如下：

* 限制拼接结果最大长度（例如 ≤ 520 bytes）
* 禁止递归拼接
* 不引入跳转指令
* 不改变栈深规则

这样可以在不引入循环、递归的前提下安全恢复 OP\_CAT。

所以结论如下：

* 在不违背“主网保持非图灵完备”的设计哲学的前提下，OP\_CAT 属于 “安全边界内的功能增强”。
* 中长期（2025–2027）激活的可能性较高，但比特币主网仍不会走向图灵完备化。

所以主网链上图灵完备的智能合约的可能性，基本等于零。 聪网虽然可以做的更多，但一个技术如果在主网上没有被应用的可能性，值不值得做，就看该技术本身是否是最佳方案了。从目前的探索结果来看，直接在指令集上做更多的增强，才有可能实现图灵完备的脚本语言，但复杂度比较高，而且开发成本非常高。而目前已经实现的通道合约的方案，开发成本低，方案更灵活，是聪网上最佳的实现智能合约的方案。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sat20.org/cong-wang-satoshinet/ca.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.