什么是比特币脚本语言？

比特币脚本（Bitcoin Script）是控制比特币网络上每笔交易的编程语言。这是一种简单的、基于栈的语言，它明确规定了比特币可以被支出的具体条件，网络上的每个全节点在验证每笔交易时都会运行该脚本。如果没有它，比特币就只是一本数字账本，没有任何机制来确保资产归属。

大多数用户从未直接接触过比特币脚本语言。他们的钱包会在后台默默处理这一切。 但每当你发送或接收比特币时，就有两个小程序在成千上万台计算机上同时运行，以验证支出条件是否已满足。理解这一机制的运作原理，能很好地解释比特币为何采用这样的架构，以及与以太坊等平台相比，它能做什么、不能做什么。

本文介绍了比特币脚本的工作原理，详细阐述了它支持的主要交易类型，解释了2021年使脚本层实现现代化的Taproot升级，并概述了截至2026年6月关于covenant操作码的争议现状。

通过自主托管安全地管理您的比特币 Bitcoin.com 钱包应用.

要点总结

• 比特币脚本（Bitcoin Script）是一种内置于比特币协议中的栈式编程语言，用于定义任何比特币输出的可花费条件。
• 每笔比特币交易都包含两个脚本：由收款人设置的锁定脚本（ScriptPubKey）和由付款人提供的解锁脚本（ScriptSig）。这两个脚本都必须成功执行，交易才算有效。
• 比特币脚本（Bitcoin Script）是刻意设计为非图灵完备的。它没有循环，执行之间不保留持久状态，且对脚本大小设有硬性限制。这确保了每个脚本都能终止执行，这是一种安全特性，而非限制。
• 该脚本语言经历了五种主要格式的演变：P2PK、P2PKH、P2SH、SegWit（P2WPKH/P2WSH）和Taproot（P2TR），每种格式都在保持向后兼容的同时，进一步拓展了功能范围。
• Taproot（2021年11月）引入了Schnorr签名、基于MAST的隐私支出路径，以及作为更新版脚本语言的Tapscript——该语言内置了机制，可确保未来升级更加简洁。
• 基于比特币脚本构建的实际应用案例包括多签名钱包、定时交易、哈希定时合约（闪电网络的基础）、第三方托管以及离散日志合约。
• 与以太坊智能合约不同，比特币脚本是无状态的：每个脚本都在完全隔离的环境中运行，对其他任何交易一无所知。这是经过深思熟虑的架构设计。
• 2026年比特币脚本开发最活跃的领域是契约操作码，尤其是OP_CTV（BIP-119）和OP_CAT（BIP-347），这些操作码将允许脚本对支出交易的具体形式进行限制。目前这两项操作码均尚未在主网激活。

什么是比特币脚本？

比特币脚本（Bitcoin Script）是一种内置于比特币协议中的基于栈、无状态的脚本语言。 比特币网络上的每笔交易输出都携带一个锁定脚本（称为 ScriptPubKey），该脚本规定了花费资金的条件。任何想要花费这些资金的人，都必须提供一个满足这些条件的解锁脚本（称为 ScriptSig，或在 SegWit 和 Taproot 交易中称为见证数据）。

该语言的结构源自Forth——一种于20世纪60年代开发的、基于栈的极简主义编程语言。 与Forth一样，比特币脚本从左向右读取，基于一种称为“栈”的数据结构进行操作，并采用反波兰表示法（RPN），即运算符位于其操作数之后，而非之前。它每次只执行一条指令，没有循环，且在两次执行之间不保留任何持久内存。

在从协议层面了解比特币脚本时，最后这一点是大多数人首先会接触到的：该语言是刻意设计为非图灵完备的。图灵完备的语言在给定足够的时间和资源的情况下，可以执行任何计算。而比特币脚本在设计上无法做到这一点，这一设计选择背后的原因对网络的运行方式至关重要。

比特币脚本的工作原理：栈模型

要理解比特币脚本的工作原理，你需要了解栈。栈是一种遵循“后进先出”（LIFO）原则的数据结构。 想象一摞盘子：你只能从最上面添加或取出。在比特币脚本中，数据会被压入栈中，而操作码（opcodes）则对栈顶的数据进行操作。

当一个比特币节点验证一笔交易时，它会依次运行两个脚本：

1. 解锁脚本（ScriptSig 或见证） 由花费这些代币的人提供。这会将数据压入栈中，通常包括一个数字签名和一个公钥。
2. 锁定脚本（ScriptPubKey） 与被花费的输出相关联。其中包含对栈数据进行操作并验证花费条件是否满足的操作码。

如果脚本执行时未出现错误，且最终在栈上留下了非零值（TRUE），则该交易有效。如果脚本执行失败或留下了 FALSE，该交易将被节点拒绝，且永远不会被纳入区块。

该执行过程完全是无状态的。脚本既不了解任何先前的事务，也不知晓当前的余额，且在脚本执行完毕后不会保留任何记忆。每次脚本都会从头开始、在隔离环境中独立运行。

分步指南：一笔标准的 P2PKH 交易

“向公钥哈希支付”（P2PKH）是比特币最初的交易类型，自2009年起便一直沿用至今。P2PKH地址以“1.”开头。以下是ScriptPubKey和ScriptSig在实际应用中的具体形式：

解锁脚本（ScriptSig）：

<签名> <公钥>

锁定脚本（ScriptPubKey）：

OP_DUP OP_HASH160 <公钥哈希值> OP_EQUALVERIFY OP_CHECKSIG

当节点将两者连接并同时执行时，栈操作会一步一步地进行：

• 来自 ScriptSig 的签名和公钥被压入栈中
• OP_DUP 将栈顶的公钥复制一份
• OP_HASH160 对重复项进行哈希计算（先使用 SHA-256，再使用 RIPEMD-160），生成一个 20 字节的哈希值
• 来自锁定脚本的公钥哈希被压入栈中
• OP_EQUALVERIFY 检查这两个哈希值是否匹配。如果不匹配，则执行中止，事务失败。
• OP_CHECKSIG 验证该签名是否对该公钥有效

如果所有步骤均通过，栈将以 TRUE 结束，资金随即被释放。整个过程仅需几毫秒，且在网络中的每个节点上运行方式完全一致。

比特币操作码详解

比特币操作码是构成脚本的各个独立指令。每个操作码占用一个字节，因此共有 256 个可能的操作码槽位。其中，主网上目前约有 80 个处于活跃状态。其余的要么被保留，要么被禁用，要么被分配给了随 Tapscript 引入的 OP_SUCCESS 前向兼容机制。

操作码可分为以下几类：

• 数据推送操作码 将公钥、签名和哈希值等值压入栈中
• 算术操作码 执行加法、减法和比较运算。需要注意的是，乘法和除法已被禁用。
• 加密操作码 包括用于哈希计算的 OP_SHA256、OP_HASH160 和 OP_SHA1，以及用于签名验证的 OP_CHECKSIG
• 流程控制操作码 启用条件逻辑：OP_IF、OP_ELSE、OP_ENDIF、OP_NOTIF
• 栈操作指令 包括 OP_DUP（复制最顶部的元素）、OP_DROP（移除最顶部的元素）和 OP_SWAP（交换最顶部的两个元素）

2010年，在中本聪发现若干操作码的原始实现中存在漏洞后，他禁用了其中几项操作码。这些操作码包括OP_CAT（连接两个栈项）、OP_MUL（乘法）和OP_DIV（除法）。 这些指令的缺失对比特币脚本（Bitcoin Script）的表达能力产生了深远影响，而2026年备受热议的若干比特币升级提案，其核心议题正是是否应重新启用其中部分指令。

如需查看包含十六进制值和说明的完整操作码参考，请参阅 比特币维基脚本页面 是权威来源。

为什么“非图灵完备”是一项优势

通常的解释是，比特币脚本（Bitcoin Script）不支持循环，因此脚本必定会终止执行，从而保护网络免受无限执行的影响。这种说法虽然准确，但未能充分说明问题。

更深层次的争论在于攻击面。一种图灵完备的语言能够表达任意的计算。这种表达能力也是漏洞滋生的温床。以太坊的Solidity语言曾导致了历史上一些代价最昂贵的软件漏洞。 2016年的DAO黑客攻击利用了智能合约中的重入漏洞，按当时的价格计算造成了约6000万美元的损失，最终导致以太坊网络进行了一次颇具争议的硬分叉。在更广泛的DeFi生态系统中，多年来已有数亿美元通过智能合约漏洞被盗。

比特币脚本从结构上杜绝了此类攻击。你无法编写出能够调用其他脚本、在条件改变前无限循环，或在交易之间保存状态的比特币脚本。 每个脚本都是一个范围有限、可终止且可检查的程序。脚本的最大大小为 10,000 字节。每个脚本中非“push”操作码的最大数量为 201 个。验证者总能在运行脚本之前计算出最坏情况下的执行成本。

对于一个价值高达数千亿美元的网络而言，这种可预测性比你所放弃的灵活性更为宝贵。 以太坊通过设置 gas 限制来解决无限制计算的问题，对执行的每个操作码向用户收费，并在预算耗尽时终止脚本执行。这种方法虽然有效，但也带来了自身的复杂性和故障模式。比特币则在设计上完全规避了这一问题。

话虽如此，“非图灵完备”并不意味着“无法处理复杂逻辑”。比特币脚本支持多方支付要求、基于时间的条件、哈希预像揭示，以及上述所有功能的组合。闪电网络每天处理数百万笔支付，其架构完全基于比特币脚本的基本元素。

脚本类型：从 P2PKH 到 Taproot 的演变

自2009年以来，比特币的脚本层已发生了显著演变，每次升级都会引入一种新的交易格式，同时仍与之前的所有版本保持向后兼容。

P2PK（向公钥支付，2009年）

原始格式，用于最早的比特币交易中，包括中本聪在第170个区块中向哈尔·芬尼（Hal Finney）支付的那笔交易。资金直接锁定在完整的公钥上，而非其哈希值。 如今在新交易中很少使用，因为这种方式会在消费前将公钥暴露在链上，这被认为比先对密钥进行哈希处理的安全性更低。

P2PKH（向公钥哈希付款，2009年）

十多年来一直沿用的标准格式。P2PKH 将资金锁定在公钥的哈希值上，而非公钥本身，从而在消费前一直保持公钥的私密性，生成更短的 20 字节地址，并构成了所有以“1”开头的地址的基础。 根据 Unchained 的链上数据（2026 年 4 月），P2PKH 地址目前持有约 43% 的已开采比特币供应量。

P2SH（Pay-to-Script-Hash，2012年，BIP 16）

P2SH于2012年4月1日通过软分叉推出，将复杂支付脚本的处理负担从发送方转移到了接收方。P2SH不再在输出中嵌入完整的锁定脚本，而是输出对“赎回脚本”20字节哈希值的提交。 完整的脚本仅在币被花费时才会揭示。这使得多签名机制对普通用户变得切实可行：一种“2 of 3”的多签名设置，不再要求发件人在支付时必须看到全部三个公钥。P2SH地址以“3.”开头。

有关 P2SH 验证在协议层面上如何运作的详细说明， developer.bitcoin.org 的交易指南 逐步讲解了Redeem脚本的机制。

P2WPKH 和 P2WSH（原生 SegWit，2017 年，BIP 141）

隔离见证（Segregated Witness）于2017年8月在第481,824个区块激活，将签名数据从主交易体移至独立的见证结构中。见证数据可享受75%的权重折扣，这使得SegWit交易的费用显著降低。 根据相关数据，一笔标准的单输入、双输出的 P2WPKH 交易权重约为 141 个虚拟字节，而同等规模的 P2PKH 交易权重则为 226 个虚拟字节。 Spark对比特币地址类型的分析 自2026年3月起。SegWit还解决了交易可变性问题，这是构建闪电网络的前提条件。原生SegWit地址以“bc1q”开头。

P2TR（Pay-to-Taproot，2021年，BIP 340/341/342）

Taproot 于 2021 年 11 月在第 709,632 个区块激活，是自 SegWit 以来比特币脚本层最重要的升级。它引入了 Schnorr 签名、一种支持 MAST 的新输出类型，以及作为更新版脚本语言的 Tapscript。 Taproot 地址以“bc1p.”开头。

Taproot 与 Tapscript：2021 年比特币脚本语言发生了哪些变化

Taproot 并非一项单独的变更，而是三项比特币改进提案（BIP），它们经过协同设计并同时生效。

BIP 340：Schnorr 签名

比特币最初采用的是 ECDSA（椭圆曲线数字签名算法）。中本聪选择该算法，部分原因在于当时施诺尔签名受专利保护。该专利于 2008 年到期，Taproot 最终将施诺尔签名引入了该协议。

Schnorr 签名的大小为 64 字节，而 ECDSA 签名的大小为 71-73 字节，因此前者更小。 更重要的是，它们通过名为 MuSig2 的方案支持密钥聚合。密钥聚合允许多个签名人将其各自的密钥和签名组合成一个聚合密钥和聚合签名，该聚合密钥和聚合签名在链上与普通的单签名支付无法区分。 通过 Taproot 的协作密钥路径进行支出的 2-of-3 多签钱包，在区块链上的表现与标准支付完全相同。对于那些通过复杂托管安排持有比特币的人来说，这确实是一项实实在在的隐私提升。

BIP 341：Pay-to-Taproot 和 MAST

P2TR 引入了一种具有两条支出路径的新输出类型：

• A 关键路径 使用Schnorr签名进行支付，当所有各方达成一致且希望采用最简单、最经济的方案时使用
• A 脚本路径 使用 MAST（默克尔化抽象语法树，即该概念在 Taproot 中的实现）进行支付

MAST 允许单个输出通过默克尔根（Merkle root）绑定到由多个消费脚本组成的树上。在消费时，链上仅会披露实际使用的特定条件。树中所有其他可能的消费路径将永久隐藏。 对于配置了复杂支出策略的用户——例如“我可以正常支出，或者六个月后由三名受托人中的任意两人进行支出，或者两年后使用恢复密钥进行支出”——只有实际执行的路径才会出现在区块链上。

根据Spark在2026年3月援引的Glassnode数据，截至2024年，Taproot在比特币交易中的占比已增至约42%，这主要得益于Ordinals和BRC-20的铭文活动。 此后，该占比虽随市场行情有所波动，但该基础设施现已成为各大钱包和交易所的标准配置。 Bitcoin Optech 的 Taproot 专题页面 跟踪围绕Taproot进行的协议开发进展。

BIP 342：Tapscript

Tapscript 是 Taproot 中用于脚本路径支出的更新版脚本语言。它与旧版比特币脚本共享大部分操作码，但进行了若干重要改动：

• OP_CHECKMULTISIG 以及 OP_CHECKMULTISIGVERIFY 已弃用。旧版多签名操作码存在一个怪癖，需要将一个虚拟元素压入栈中作为临时解决方案。Tapscript 移除了该操作码，并用 OP_CHECKSIGADD，该算法逐个验证Schnorr签名，并累积计数。阈值多签名方案的实现变得更加简洁，执行成本也更低。
• 取消了每个 MAST 叶节点的脚本大小限制。Taproot 分支中的单个脚本大小可任意大。
• OP_SUCCESS 操作码 是最具前瞻性的变革。在传统脚本中，遇到未定义的操作码会导致脚本执行失败。而在 Tapscript 中，OP_SUCCESS 范围内的操作码会使脚本无条件成功执行。 未来的软分叉可以通过对这些操作码的成功条件添加约束，为其赋予实际行为，而无需发布新版本脚本或让整个生态系统经历完整的重新部署周期。与比特币协议历史上的任何时期相比，现在可以更简洁地向其脚本层添加新功能。

Miniscript

除了 Tapscript 之外，一个名为 Miniscript 的相关项目也越来越受到开发者的关注。Miniscript 是一种结构化的编写方式，用于实现比特币脚本（Bitcoin Script）的一个子集，该子集具有可分析性、可组合性，并且能够进行通用签名。 原始 Script 需要手动构建且难以审计，而 Miniscript 脚本则可以自动验证其正确性，并组合成更复杂的策略。它并未扩展 Script 的功能，但使构建钱包和托管工具的开发者能够更轻松地利用 Script 现有的功能。

比特币脚本的实现：现实世界中的应用场景

目前，比特币主网上已启用以下交易类型，它们均基于比特币脚本（Bitcoin Script）的基本语法构建：

多签名（multisig）钱包 需要 M/N 个私钥才能授权一笔支出。 公司财务部门可能要求任何提款都需要5人中3人的批准。一对已婚夫妇可能对共同储蓄采用2人中2人的授权机制。借助Taproot和Schnorr密钥聚合技术，协作式多签名交易在链上已与标准的单签名交易无法区分。

带时间锁的交易 使用 OP_CHECKLOCKTIMEVERIFY（CheckLockTimeVerify，简称 CLTV）和 OP_CHECKSEQUENCEVERIFY（CheckSequenceVerify，简称 CSV），以防止资金在达到特定区块高度或经过特定时间之前被转移。 其应用场景包括遗产规划、员工代币归属计划、强制储蓄机制，以及闪电网络通道内使用的惩罚性交易。

哈希时间锁合约（HTLC） 将哈希原像要求与时间锁相结合。其支付条件如下：必须在达到该区块高度之前揭示该哈希的哈希原像，否则资金将退还给发送方。HTLC是闪电网络的核心基础组件，它使互不认识的各方能够通过通道链实现无需信任的支付路由。

托管 此类安排将资金锁定在 P2SH 或 Taproot 脚本中，在释放资金前需要多方达成一致，通常由持有决胜权的第三方仲裁者负责。

隐式日志合同（DLC） 使用基于预言机的Schnorr适配器签名，使金融合约能够根据价格数据流或事件结果等现实世界数据进行结算，且无需预言机托管任何资金。DLCs已在比特币主网上线，并被用于以比特币结算的期权和期货产品。

比特币脚本与以太坊智能合约

比特币的Script语言和以太坊的Solidity语言都定义了资金转移的条件，但它们代表了根本不同的架构选择。直接进行比较是有意义的，因为这些差异在很大程度上解释了每个网络所接受的权衡取舍。

根本的分水岭在于是否具有状态。以太坊合约会存储和修改跨交易持久化的数据，从而使借贷协议、去中心化交易所、链上治理和代币标准成为可能。比特币脚本则没有类似的功能。每个脚本都在真空环境中运行，对其他任何交易一无所知。

这是一种有意的架构设计，而非亟待填补的空白。比特币的脚本层专为一项特定任务而设计：以可预测且安全的方式，在大规模环境下强制执行比特币支出的条件。 对于这一任务而言，无状态性是一大优势。攻击面更小，在数百万个独立验证者之间执行结果具有确定性，而且由于协议层不存在带状态的合约，因此也不存在协议层级的智能合约漏洞。

希望在比特币基础上实现更高可编程性的项目，通常采用分层架构。闪电网络（Lightning Network）负责处理支付；DLC协议则处理与外部数据相关的金融合约；而Ark和Liquid Network等第二层（Layer-2）系统则针对不同的可扩展性需求提供解决方案。所有这些都不需要修改基础层的脚本模型。

《Covenant》之争：比特币脚本可能发生哪些变化

比特币脚本的演进一直缓慢且保守。目前最活跃的开发领域是契约操作码，这些提案将使脚本不仅能够限制谁可以花费一个输出，还能限制由此产生的交易必须具备什么样貌。这极大地扩展了脚本的表达能力。

截至2026年6月，主要提案包括：

• OP_CTV（BIP-119，CheckTemplateVerify）该提案由杰里米·鲁宾（Jeremy Rubin）起草，新增了一个操作码，用于将一个UTXO绑定到一个特定的、预先确定的支出模板中，该模板包含交易的版本号、锁定时间、输入数量、序列号、输出数量以及输出项。 该提案按设计不具有递归性，被视为最保守的主要提案，主要针对金库、拥塞控制以及某些闪电网络改进。截至2026年4月，OP_CTV已提出具体的部署参数，其中规定了“快速试行”（Speedy Trial）信号窗口，但尚未达到激活所需的广泛社区共识，根据 BlockEden 2026年4月的契约分析.
• OP_CAT (BIP-347)该提案由伊桑·海尔曼（Ethan Heilman）和阿明·萨布里（Armin Sabouri）提出，旨在重新启用中本聪于2010年禁用的一个操作码。OP_CAT 可将两个栈项进行拼接，这一功能描述虽简单，但影响深远。当与施诺尔签名（Schnorr signatures）结合使用时，它能够实现类似契约（covenant）的交易内省功能。 根据 sCrypt 在 2024 年末进行的链上分析，在比特币 Signet 测试网中，OP_CAT 生成的开发者交易数量远超 APO 或 CTV。OP_CAT 目前已在 Liquid Network 和 Fractal Bitcoin 上投入使用，且尚未发现与其相关的任何安全漏洞。 BIP-347 拥有官方提案编号且背后有活跃的研究支持，但要在主网激活该功能，仍需社区达成共识，而目前尚未形成这种共识。
• LNHANCE 将 OP_CTV 与 OP_CHECKSIGFROMSTACK（CSFS）和 OP_INTERNALKEY 捆绑在一起，旨在针对闪电网络通道构建进行具体改进，包括非交互式通道开启以及更高效的多方通道管理。

截至2026年6月，这些提案均未在比特币主网激活。它们之间存在的技术分歧在很大程度上是可以解决的。 更棘手的问题在于激活机制。比特币的软分叉流程需要广泛共识，而关于“契约”的争论中仍残留着此前有争议的升级所引发的紧张情绪。从这场辩论中可以明确看出，比特币的脚本层在其保守的框架内仍有显著的发展空间。当前正在探讨的问题是实施顺序和社区共识，而非脚本语言是否具有未来。

结论

比特币脚本是网络上每笔交易背后那看不见的基础设施。 大多数用户从未直接接触过它。钱包会构建有效的脚本、对其进行签名并广播，而整个过程中不会暴露其内部机制。但每一笔支付、每一个闪电通道、每一个定时计划、每一个多签金库，都运行在2009年随协议一同推出的、基于栈的比特币脚本语言之上。

自那时以来，脚本层已取得了长足发展：P2SH 使复杂的交易支出成为可能；SegWit 降低了手续费并支持了闪电网络；Taproot 则带来了 Schnorr 签名、基于 MAST 的隐私保护以及 Tapscript 的前向兼容操作码设计。 目前正在积极讨论的契约提案代表了下一个潜在的发展篇章。截至2026年年中，这些提案究竟能否生效以及具体的时间表如何，仍完全未定。

理解脚本并不需要具备开发者背景。但必须认识到，比特币的保守性、刻意设定的限制、缓慢的升级节奏以及非图灵完备性，并非缺陷。正是这些使比特币脚本具有可预测性的特性，才让共识层在十六年间始终保持纯净。