比特币历史 71 | 智能合约（六）：逆向抛光

（Jan Lukasiewicz，波兰逻辑学家。图片来自网络）

往期情况回顾：

文本：

1929年，波兰逻辑学家扬·卢卡塞维茨（Jan Łukasewicz）发明了一种新颖的数学表达式书写方式，后世称为“逆波兰式”（Reverse Polish Notation），又称“后缀表达式”。 相应地，相反的写法是“波兰语”，也称为“前缀表达”。

通常，人们习惯把数学表达式写成所谓的“中缀表达式”，也就是把运算符写在操作数的中间，像这样：(1 + 2 + 3) * 4。等价的前缀表达式，顾名思义，就是把运算符写在前面：(* (+ 1 2 3) 4)。 等价的后缀表达式，也就是反波兰表达式，写成这样：1 2 3 + 4 *。

我们平时接触的数学和编程语言，大部分都是使用最常见的中缀表达式。 这种书写形式最符合人类的阅读习惯比特币合约地址，但对计算机最不友好。 有必要仔细定义运算符的优先级。 并合理地使用括号来表示想要的计算顺序，使计算机能够正确理解人的意思。 著名函数式编程语言的鼻祖 LISP，就是使用前缀表达式来编写程序代码。 好处是程序直接是一个AST抽象语法树，免去了计算机语法分析的痛苦。 Reverse Polish expression是最不常见的一种写法，因为这种写法最违背人类的阅读习惯。 只有Forth等少数冷门编程语言使用这种编码方式。 这种写法对计算机非常友好。 使用最简单的计算机堆栈（stack）就可以计算和评估。 然而，写反波兰表达式的最大优点之一是完全不需要括号，这避免了由于括号的位置或嵌套顺序错误而导致的难以察觉的错误（bug）。

中本聪选择使用逆波兰表达式来编写比特币脚本。 一方面，逆波兰表达式不易出现书写错误，这本身就是系统“安全”或“健壮”的重要体现； 比特币脚本的设计非常关键，我们稍后会看到为什么没有括号对比特币脚本的设计如此重要。

那么，上面用比特币脚本语言编写的例子的表达式是类似这样的：

1 2 3 加法 (OP_ADD) 4 乘法 (OP_MUL) [注意：禁用]

让我们举一个真实的例子。 我们最常见的转账交易是向比特币地址转账，其中使用的比特币脚本如下所示：

收款人签名 收款人公钥复制 (OP_DUP) 哈希 160 (OP_HASH160) 收款人地址验证相等性 (OP_EQUALVERIFY) 校验签名 (OP_CHECKSIG)

上面以OP_开头的都是运算符，也叫运算符或操作码（operators），代表一个运算，其他的都是操作数，就是要运算的某类数据。

在认识比特币脚本之前，我们对比特币的理解和直观想象是，一笔比特币以不同面额的硬币（UTXO）的形式存储在一个比特币地址中，就好像放在一个带锁的保险箱里，只持有比特币地址对应的所谓私钥，也就是保险箱的钥匙，就可以打开保险箱，使用里面存放的比特币。

但实际上，中本聪通过比特币脚本的设计比特币合约地址，将保险柜的锁和钥匙升级为智能锁和智能钥匙。 这对配对的智能钥匙和智能锁是通过将比特币脚本对半折断得到的，就像中国古代的虎符一样，国王和将军各执一半，需要的时候放在一起调兵遣将。 以上述比特币地址转账交易为例，分为两半如下：

智能钥匙由收款人持有，只需要在必要时出示：收款人签名收款人的公钥

智能锁由付款人在区块链账本上发布以锁定比特币：复制（OP_DUP）哈希160（OP_HASH160）收款人地址相等验证（OP_EQUALVERIFY）检查签名（OP_CHECKSIG）

智能钥匙在比特币中被称为解锁脚本（scriptSig）。 智能锁被称为锁脚本（scriptPubKey）或见证脚本（witness scripts）。 当钥匙和锁放在一起时，就还原了一个可以运行的脚本，任何人都可以计算和验证。 至此，你可以看到使用反向波兰表达式消除了括号，这就避免了配对括号的麻烦和打开脚本时可能出现的错误。

我们之前的表述“存储在比特币地址中”，其实是类比和等同于比特币“地址”和银行“账户”。 没有所谓的“账户”，也不存在所谓的比特币放在哪里的问题。 比特币区块链上真正存在的只是一枚比特币（UTXO 未花费的交易输出），每一枚都有不同的面值，并被“智能锁”或“锁定脚本”锁定。 任何人只要出示可以打开“智能锁”的“智能钥匙”，就可以使用此币。

那么，是否存在不在任何比特币地址中的比特币？ 答案显然是肯定的。 例如，如果一个硬币的锁定脚本是“哈希值 256 (OP_HASH256) 是否等于 (OP_EQUAL)”，那么只有提供给定哈希值的正确原像才能花费该硬币，并且该硬币没有“存储”在任何地址。

通过这种巧妙的设计，我们需要的“托管”就非常容易实现了。