在下面的介绍中，BTCManager将研究比特币网络中使用的简单但功能强大的编码语言。比特币脚本语言或比特币脚本在设计时只考虑了几个功能；它是紧凑的、图灵不完备的、基于堆栈的。通过这种方式，语言可以高效、安全地服务于这些目的。

尽管其功能很少，但与以太坊等网络相比，它在过去十年中已经证明自己足够强大，足以支持价值交易。

比特币脚本和“可编程货币”

在许多人看来，先锋加密货币背后的编程语言是奥卡姆剃刀的完美例子。

即使与前加密货币编码语言相比，它也是初级的。更重要的是，中本聪有意设计了这种简单性。具有多种功能并允许复杂数据事务的语言也允许更多的攻击向量。批评者解释说，像Solidity这样的语言虽然其范围令人印象深刻，但就安全性而言却存在不足。

从这一点来看，比特币脚本是图灵不完备的。相比之下，Solidity 是图灵完备的，这意味着它可以复制任何图灵机或能够自主遵循特定算法的抽象机。掌握了这个概念，我们就可以开始理解智能合约是如何运作的。

回到主要焦点，比特币脚本不提供此功能，或者以不同的方式提供此功能，使用比特币区块链更深入地研究智能合约将是后续文章的主题。

比特币的主要用例一直是加密货币和价值转移。因此，图灵完备语言的附加特征是不必要的。然而，这并不意味着脚本受到限制。

此外，比特币脚本的限制可以防止“逻辑炸弹”或无限循环包含在任何单个交易中。此限制消除了网络遭受拒绝服务 (DoS) 攻击的可能性。这些限制的范围，例如超出仅仅向X和Y发送值的交易，将在接下来的分期中介绍。

比特币脚本语言的特点

比特币的编码语言使用“反向抛光”作为符号系统，这意味着诸如“3 + 4”之类的行将显示为“3 4+”，并且复杂性不断增加。另一个功能可以追溯到比特币脚本的“Forth-like”根源。此功能的相关性仅仅是因为这两种语言都是“基于堆栈的”。

堆栈是一种非常常见的数据结构，用Andreas Antonopolous 的话说，它允许“堆栈顶部”的信息“推送”或“弹出”。前一个操作解释了向堆栈添加信息的过程，而后者描述了从堆栈中删除信息的过程。此外，弹出或推送信息的顺序遵循“ LIFO ”原则，即后进先出。

（来源：BlockGeeks）

像“3 4+”这样的操作将表现如下：

• 将“3”推入堆栈。
• 将“4”推入堆栈。
• “+”运算符获取这两个参数，将它们从堆栈中弹出，将它们加在一起，然后将结果推回到堆栈中。（即弹出、弹出、添加、推送）
• 在这种情况下，结果操作会导致堆栈上出现“7”，并且程序终止。

在比特币脚本中，此操作将遵循相同的步骤，但还会在每个变量之前包含前缀“OP”。接下来让我们看看所有这些新词汇是如何在真实的比特币交易中组合在一起的。

实际的比特币脚本

大多数操作都是签名交易。这包括支付、交换以及涉及公钥和私钥的大多数工作。为了这篇文章的目的，我们来拆解一下作者和他的同事埃迪·米切尔之间的交流。在这里，作者（发送者）将指定米切尔（接收者）的公钥，米切尔将通过使用相同的公钥指定签名来兑换发送的比特币。

（来源：Coursera）

接下来，此类交易的前两条指令是签名和用于生成该签名的公钥。该信息被标识为“<sig>”和“<pubKey>”并压入堆栈。米切尔作为接收者确定这些值。交易的前半部分通常称为“scriptSig”或“解锁脚本”。在这部分操作中，还引用了先前存在的未花费交易输出（UTXO）。

UTXO 的包含确保了作者确实拥有他想要发送给 Mitchell 的比特币数量。比特币网络通过矿工和比特币全节点完成这一验证。在《掌握比特币》一书中，作者 Andreas Antonopoulos是这样解释的：

“每个输入都包含一个解锁脚本，并引用之前存在的 UTXO。验证软件将复制解锁脚本，检索输入引用的 UTXO，并从该 UTXO 复制锁定脚本。”

然后，交易的第二部分“锁定脚本”或“scriptPubkey”由作者执行。根据上图，下一条指令“OP_DUP”从堆栈中弹出<pubKey>，复制它，然后将其返回到堆栈。

OP_DUP 指令。

（来源：Coursera）

然后，该顶部值或 <pubKey> 的副本通过“OP_HASH160”指令进行加密散列，并变为“<pubKeyHash>”。

公钥哈希。

（来源：Coursera）

用于比特币交易的特定哈希函数称为 SHA-256（安全哈希算法），是称为 SHA-2 的更大函数组的一部分，该函数来自国家安全局于1993 年开发。SHA-256 的其他成员2 系列包括 SHA-224、SHA-256、SHA-384 和 SHA-512，每个数字代表它们生成的消息的位长度。

信息安全领域的应用非常广泛，其中最相关的是比特币和Haschash 的工作量证明（PoW）共识机制。SHA-256 最显着的特点是它能够防止如上所述的 DoS 攻击。

回到作者和他的同事之间的交易，用户仍然需要向堆栈中添加另一条数据。下一位信息是作者在交易开始时指定的公钥。需要生成签名来兑换所请求的比特币。

此时，堆栈顶部有两个关键的哈希数据：作者指定的公钥的哈希值和 Mitchell 使用的公钥的哈希值。从那里开始使用“OP_EQUALVERIFY”命令，确保作者确实使用了正确的公钥。在早期经历了几次失败的比特币交易后，作者进行了三次检查，确认公钥是米切尔的公钥。当公钥匹配时，OP_EQUALVERIFY 命令会消耗这些数据点。用户现在只剩下签名和公钥。最后一步是验证这笔交易的签名确实正确。  

签名和公钥堆栈。

比特币脚本语言在这里是有利的，因为它不需要从广泛的库中提取来确认签名的有效性。所有这些都内置于语言中。

最后的“OP_CHECKSIG”指令，然后将剩余的两项从堆栈中弹出，如果<sig>与<pubKey>匹配，则该操作将被视为有效。

比较、对比和增加复杂性

尽管下面的介绍很简短，但它应该给出比特币交易如何执行的基本概念。在此基础上，开发人员和爱好者可以开始尝试更高级的操作，这将是稍后简报的主题。

以此为基础的后续文章将更深入地探讨数字签名 ( ECDSA )、多重签名操作、付费脚本哈希 (P2SH) 和时间锁。