作者 ：Botanix Labs 中文

在比特币上发展代币、NFT 和 DeFi 的过程其实比表面上看起来要复杂得多。比如，在以太坊虚拟机（EVM）以及其他智能合约平台上，智能合约具有图灵完备性，这意味着只需部署一个自定义合约就可以新增功能或选项。但在比特币上，开发者则必须小心翼翼地在不引发硬分叉的前提下进行创新，只能在现有协议功能的限制内操作。如我们在前文中提到的，比特币之所以具有独特的重要性和价值，其中一个关键因素就是它对“原始性”的坚持，主链在时间推移中几乎没有经历太多改动。

尽管如此，比特币是第一个获得广泛采用的区块链，许多后续在更灵活区块链上实现的技术，最早的萌芽其实都出现在比特币上。事实上，NFT 最初是以“彩色币”（Colored Coins）的形式出现在比特币上；状态通道（State Channels）的概念在设计上与当今的 L1-L2 架构颇为相似；而原子交换（Atomic Swaps）为现代的跨链桥打下了基础。我们在前文《从比特币出发：DeFi 的真实起源》中已部分介绍过这些发展。但若要真正理解比特币作为 Botanix 及其他比特币链的基础设施所具备的无与伦比的价值，我们需要更深入了解这些早期创新如何为今日生态铺路。尽管比特币本身相对“简洁”，但它实际上是 Web3 领域中最复杂、最迷人的生态之一，拥有最丰富的历史。

探讨比特币功能理论：比特币的能力是否足以支持复杂生态？

2009 年比特币上线时就内置了一套脚本语言，这不仅仅能实现简单的支付，还从一开始就支持如多重签名（multi-sig）和时间锁（time-lock）等更复杂的操作。中本聪甚至描述过，使用 nLockTime 和序列号（sequence number）的未确认交易可以在双方之间多次更新用于高频交易，只有最终状态会被写入链上。

比特币脚本（Bitcoin Script）是一种非常有趣的机制：一方面，它是图灵不完备的，限制了其功能性；但另一方面，它也因此保持了简洁和安全。因此，在比特币上构建任何复杂功能时，开发者都必须在 Script 所提供的框架内进行设计。它包含了大量命令（Opcode），用于编程各种动作，这些操作最终都会写入交易数据中。

Bitcoin Script 是比特币定义币的支出条件所使用的脚本语言本体。你可以将 Script 理解为一份食谱 —— 一整套烘焙蛋糕的步骤。而 Opcodes（操作码）就是这套语言的构建模块 —— 它们是程序员编写脚本时使用的基本指令，例如“搅拌”“加热”等。为了更清楚地理解 Script 的功能，我们简要回顾一下最常见的几种脚本类型：

• P2PK（Pay To Public Key） —— 这是最原始的 BTC 转账方式，后来被 P2PKH 替代。它由几个 Opcode 构成，例如：OP_DATA_65 OP_CHECKSIG OP_DATA_33 OP_CHECKSIG。

• P2PKH（Pay To Public Key Hash） —— 脚本形式为：OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG。由于使用 32 字节的公钥哈希以优化交易大小，比起 64 字节的 P2PK，这种脚本更节省空间，因此很快成为主流。交易数据越小，费用越低 —— 这在比特币使用和手续费增加的背景下尤其重要。

• 存储任意数据 —— 这类脚本通常锁定的聪数量极小，主要用于存储 ASCII 文本、链接或脚本。例如：OP_0 OP_DATA_20 # 20 字节自定义数据。此外还有标准化的方式使用 OP_RETURN 存储数据。例如，比特币彩色币协议（NFT 前身）就通过 OP_RETURN 嵌入代币元数据。

NCC Group 的一份研究中汇总了 156 种不同的 Script 模式，对这些脚本结构做了详细分析。

那么，我们是否可以尝试使用 Script 在比特币上组织类似 DeFi 的机制呢？下一步让我们继续探讨。

借贷机制：

正如我们前文所述，操作码（opcodes）可以组合使用，从而构建出一系列小的指令链，进而实现更复杂的行为。例如，开发者可以通过组合操作码来构造具有借贷合约功能的复杂脚本。这可以通过时间锁和多签组合来实现：

• OP_CHECKSEQUENCEVERIFY (CSV)：用于相对时间锁（例如，在某笔交易之后锁定资金 X 个区块）；

• OP_CHECKLOCKTIMEVERIFY (CLTV)：用于绝对时间锁（例如，贷款在某个具体区块高度或时间戳时到期）；

• OP_CHECKMULTISIG（或多个 OP_CHECKSIG 配合 OP_ADD）：要求多方共同签署；

• 条件逻辑操作码 OP_IF / OP_ELSE：定义不同的支出路径（例如还款 vs 违约）。

这些工具可以实现“带超时功能的双边托管合约”。举个例子：假设 Alice 提供 BTC 作为抵押，而 Bob 线下借给她稳定币。他们希望通过合约设置如下规则：如果 Alice 到期未还款，Bob 将获得她的 BTC；若按时还款，则 BTC 将解锁返还给 Alice。为此，他们可以使用一个 2-of-2 的多签输出（Alice 和 Bob 都需要签名才能动用资金）。然后，他们可以设定脚本逻辑：如果到达某个区块高度之后仍未还款，只有 Bob 可以单独动用这笔资金。

不过，这里仍存在一个重大难点：比特币本身无法自动计算利息、监控抵押率或强制执行清算。任何利息支付都必须通过链下方式完成，或是借助预签名交易来实现（这在实践中相当复杂）。如果贷款期间 BTC 价格下跌，比特币脚本本身无法得知，也就无法自动触发清算。要实现这种功能，必须借助预言机或链下协议。在没有预言机的前提下，合约只能基于最终到期时间来做判断。

因此，在比特币一层上直接实现无需信任的 BTC 抵押稳定币借贷非常困难。目前的实践方式通常依赖可信第三方，或是借助其他链上的原子交换机制来间接实现。

AMM 功能：

如前文所述，借贷和质押机制在理论上可以通过 Bitcoin Script 实现，但在实际操作中效率较低。然而，我们仍可以探讨是否有可能在比特币上构建类似自动做市商（AMM）的更复杂机制。比特币脚本中包含了如 OP_ADD、OP_SUB 和 OP_MUL 等数学操作码（尽管其中一些已被禁用），也有类似 OP_LESSTHAN 的比较操作码。从理论上讲，这些功能可以用来实现价格计算逻辑。

在理论上，开发者可以构造一个脚本，内置固定价格或一组预定义的可接受价格点，但无法做到每次交易后动态调整价格。原因在于比特币采用 UTXO 模型，每笔交易都会生成新的 UTXO 和脚本，因此每个可能状态都必须预先计算，或者每次交易后都需重新部署一个合约。

另一个 AMM 实现的关键因素是资产交换能力。理论上，比特币支持原子交换（Atomic Swaps），可构建为订单簿形式而非流动性池。类似 AMM 的行为也可以通过构建一系列 HTLC（哈希时间锁定合约）或在不同价格点发布挂单来模拟，从而形成一个静态的自动做市系统（类似一条收益曲线）。但维护这样的系统非常繁琐，每次交易后都需手动更新脚本并重新发布 UTXO，链上成本极高。

因此，虽然理论上可以构建 AMM，但实际还面临一个更大的问题：比特币主网上只存在 BTC 一种原生资产。虽然如 Omni 协议提供了代币机制，但这些资产存在于交易的元数据中，无法被脚本识别和处理。因此，通过 Bitcoin Script 无法实现真正的资产对资产交换或流动性池维护。此外，比特币的 UTXO 模型也不支持单个合约同时持有多方资金并更新部分余额——每次状态变化都需要新的交易和多方签名。

扩展 Script 功能：

上述几点解释了为什么比特币会定期进行重大更新以提升其功能。其中一项重要更新是 Taproot，它通过软分叉的方式引入，但极大地改变了 Script（脚本）的设计方式。

Taproot 的 OP_SUCCESS 机制：

随着 Taproot 升级（BIP 342）的引入，许多此前被禁用或保留的操作码（opcode）在 Tapscript（即 SegWit v1 脚本）中被转变为 OP_SUCCESS 操作码。OP_SUCCESS 表示：只要执行该操作码，脚本就会立即成功终止。这种设计使得通过软分叉添加新操作码变得更加简单和安全。具体而言，在 Tapscript 中，若操作码的值位于特定范围内（例如：0x50、0x62、0x7E–0x81、0x83–0x86、0x89–0x8a、0x8d–0x8e、0x95–0x99、0xbb–0xfe），就会被视为 OP_SUCCESSx。一旦遇到这些操作码，脚本会无条件判定为成功，忽略其他逻辑。

这种机制取代了旧有的 OP_NOP（空操作码）升级方式，带来了更高的安全性与灵活性。未来的软分叉可以重新定义某个 OP_SUCCESS 操作码的行为，而老版本节点仍会将其视为“脚本成功”，从而避免因版本不一致导致的无效交易。总结而言，所有未被列为“可用”的操作码，要么是保留未用，要么在 Taproot 中已转为始终返回成功的 OP_SUCCESS。

另一个重要方面 是操作码可以通过 BIP（比特币改进提案）流程提出，目前已经有一些功能强大的提案正在审议或已被拒绝。其中一些提案如果被采纳，将显著拓展比特币的功能，使其能够执行更复杂的操作：

• OP_CAT（连接操作符）： 用于增强比特币脚本中对数据组合和处理的能力，极大提升表达能力。OP_CAT 原本在早期比特币中就存在（2010 年被禁用），其作用是从栈中取出两个字节串并连接后再推入栈中。这种简单却强大的操作可用于动态构建消息、在脚本中计算 Merkle 树哈希等复杂逻辑。该提案建议限制连接后结果不超过 520 字节（即最大栈元素限制）。

• OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY（简称 OP_CSFS）： 这一操作码可实现基于预言机的脚本验证。例如，一个脚本可以验证一个外部条件（如价格或事件结果）的签名信息是否来自特定预言机。尽管执行逻辑简单，但 OP_CSFS 能为比特币解锁全新的能力。例如：预言机签署一条消息“BTC 在 X 时间点跌破 $20,000”，借贷脚本通过 OP_CSFS 验证此签名，从而允许出借方清算抵押品——这一过程无需第三方保管私钥。此外，借款人还款后，预言机或出借人可签名“已收到还款”，脚本验证后将抵押物返还。若无 OP_CSFS，这类基于外部条件的自动合约要么无法实现，要么只能通过预言机作为联合签名人来完成，存在更高的信任风险。

• OP_CHECKTEMPLATEVERIFY（简称 OP_CTV）： 此操作码允许用户预先设定其比特币的未来使用方式，例如：只能转账到某一组特定地址，或在满足特定手续费条件下才能花费。OP_CTV 可用于构建批量交易、通道工厂、以及其它基于“契约”（covenant）机制的高级用例，从而确保某些预定义规则被强制执行。

但为什么这些操作码至今仍未被批准？

最主要的原因可能是：比特币开发者社区对于保持比特币的原始形态极为谨慎。

一方面，引入新功能确实可以增强比特币的可用性和扩展性；但另一方面，比特币本身就是一个设计为“慢”的网络，而这种“慢”，在某种程度上也被视为其“原汁原味”的特性。例如，以 OP_CSFS 应用于清算机制为例，速度是其中的关键因素。如果市场崩盘、BTC 价格剧烈下跌，就可能出现一个悖论：

首先，区块链负载飙升，网络速度进一步下降；

其次，比特币网络中的交易处理速度会大幅滞后，价格早已脱离当前市场水平，而中心化和去中心化交易所（CEX 与 DEX）却早已迅速反应。

极有可能，在链上清算交易完成前，价格已经反弹。

因此，比特币本身运行缓慢、在高负载时交易费用极高，使得原生实现 DeFi 相关机制在主网上的尝试基本失去意义。

正因为如此，开发者们逐步得出一个更为合理的结论：应当在比特币之上构建扩展层。这其实就是 Rollup 思想的前身——即“原型支付通道”（proto-payment channel）的概念：通过支持链下的多笔微交易，最终压缩成一笔链上结算交易。

早在 2011 年 4 月，Bitcoin 的第一个代码分支 Namecoin 被推出，它通过比特币技术实现了去中心化的域名注册（DNS “.bit”）。

Namecoin 的案例——在链上存储“名称-值”对——首次展示了：比特币设计不仅可用于货币交易，也可以用于其他资产，尽管可能需要独立的区块链结构。这些理念为后续的资产代币化、去中心化交易、以及比特币的链下扩展创新奠定了基础。

稳定币：在比特币生态中究竟有多有效？

稳定币已成为任何 Web3 生态系统中的关键组成部分，即便是那些与 DeFi 没有直接关系的系统也不例外。它们让用户得以规避波动性风险，在转账时无需担心资产价格的变动。如前所述，比特币网络始终在功能简洁性与可记录数据量之间寻找平衡。有趣的是，比特币上最早的资产发行尝试，是通过“彩色币”（Colored Coins）的开发实现的，这种方式在某种程度上类似于 NFT。

早在 2012 年，J.R. Willett 就提出了在比特币上发行新资产的设想，并提出了“彩色币”概念。他随后帮助创建了 Mastercoin 协议（后更名为 Omni），为在比特币上实现资产代币化（包括锚定法币的代币）奠定了基础。

由于标准的比特币 Script 脚本中并没有直接的“token”操作码，开发者只能借助 OP_RETURN 将代币元数据嵌入到交易输出中（OP_RETURN 会使输出变为不可花费，并附带数据）。在 OP_RETURN 标准化之前，甚至连多重签名脚本都曾被“曲线救国”地用来编码数据。

比特币脚本本身无法强制执行任何代币规则——规则由链下软件维护，这些软件负责解析比特币交易。

像 Colored Coins、Omni Layer（原 Mastercoin）、Counterparty 和 Open Assets 等协议，都是通过“为某些 satoshi 或 UTXO 上色”的方式来表示代币。例如，Open Assets 协议会使用包含元数据的 OP_RETURN 输出，其中指明了代币数量和资产 ID。

从本质上说，比特币区块链本身并不知道“代币”的存在——它仅仅是处理数据。代币的有效性（例如供应量、归属权）由外部钱包解析 OP_RETURN 数据后自行追踪。

值得注意的是，OP_RETURN 有数据大小限制。比特币核心客户端的标准策略规定：每个 OP_RETURN 输出最多只能包含 80 字节的任意数据。超过 80 字节的数据将被视为“非标准交易”，不会被默认转发。在理论上，一笔交易可以包含多个 OP_RETURN 输出，以增加附带数据量（每个最多 80 字节），但为了防止垃圾交易，比特币当前的标准中继策略一般只允许每笔交易含有一个 OP_RETURN 输出。

这种“在比特币交易中嵌入元数据”的能力，使得 2012 年的 Mastercoin 协议得以诞生，后来更名为 Omni。Omni Layer 对早期 Tether 的运行起到了关键作用，成为第一批 USDT 转账的底层传输协议。

在 2010 年代中期的一段时间里，基于比特币（Omni）的 USDT 是市场上最主要的稳定币，尤其在 Bitfinex 等交易所中被广泛使用。Omni 交易实质上是标准的比特币交易，外加附加的元数据。Omni 后续还发展出多个不同实现类别，形成了自己的技术演进路线。