比特币的脚本

我们都知道比特币内置一个脚本语言，中本聪在比特币的0.1.0版本里面定义了所有的操作码以及对应的功能。那么中本聪为什么要设计这样一个脚本呢？在比特币的白皮书里面并没有对脚本的任何描述，但是在中本聪的参与的讨论中，我们可以找到下面的一段文字：

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whETHer it was used or not, and on covered one special case at a time. It would have been an explosion of special cases. The SOLution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes on need to understand the transaction to the extent of evaluating whETHer the sender’s conditions are met.

The script is actual a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Current, receivers on accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we’ll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

翻译成中文的意思是：

比特币的性质是0.1版一旦发布，其核心设计在剩余的生命周期中就不再改变。因此，我想将其设计成能支撑各种可能交易类的系统。问题在于不管是否用到这些类，都需要特殊的支持代码和数据字段，并且每次只能覆盖一种情况，这会产生海量的特例。解决方案是用脚本来概括问题，因此交易方可以将交易描述为对网络节点评估的断言。节点对交易的了解只需到可以评估支付方是否满足条件就可以了。脚本实际上是一种断言。它只是用来评估真假的方程式。断言是一个生僻的词，所以我称之为脚本。收款方在脚本上匹配模板。

目前，收款方只接受两种模板：直接支付和比特币地址。未来的版本可以为更多的交易类提供更多的模板，运行那个版本或更高版本的节点就能接收这些交易类。网络中所有版本的节点都可以验证并且处理任何新交易，然后移至区块里，即使它们可能不知道如何读取这些新交易类。这个设计支持我多年前设计的各种可能的交易类，包括托管交易、担保交易、第三方仲裁、多方签名等。如果比特币的发展规模够大，这些就是未来我们想要探索的，但它们都必须在一开始就设计才能确保未来成为可能。

从上面的话语我们可以知道，中本聪是为了支持各种各样的交易类，所以才设计了比特币脚本。意味着我们可以用比特币脚本来实现任何我可能的交易类。但是现在的比特币区块链上，我们是不是已经用比特币脚本实现了托管交易、担保交易、第三方仲裁、多方签名等交易呢？实际上并没有。起码我个人只见过多方签名，其他的没见过。我认为，如果是一个受限的图灵不完备的脚本语言，肯定不可能实现任何可能想到的交易的。在比特币0.1.0版本的注释里面，我们可以看到这样的一段描述：

Script is a stack machine (like Forth) that evaluates a predicate returning a bool indicating valid or not. There are no loops.

比特币脚本里面是没有循环的。这是中本聪故意为之的。很多人认为没有循环的脚本语言就是图灵不完完备的。但很多语言本身就是没有循环的，比如Haskell，但可以用模式匹配的方式来实现类似循环的功能。关于比特币脚本的图灵完备性证明，我是看不懂的。但中本聪这么设计，肯定有他的理解。骷髅会邱少贤的比特币重生计划里面关于图灵完备有这样的一段描述：

图灵停机问题

图灵停机是一个难题，而且与比特币、区块链密切相关。凡是图灵机、图灵完备的程序语言，都有图灵停机的难题。

停机问题，通俗地说，就是对任意一个程序，对任意的输入数据，能否事先判断出程序是否会停止运行？

…

聪哥既要比特币脚本功能相当于图灵完备，又要避免麻烦的停机问题。而且在比特币中，矿工收取矿工费用，是按照区块大小收矿工费的。如果有循环语句，一段指令，循环了一万次，跟只执行一次，代码大小是一样的，收取矿工费是一样的；但是耗费矿工的资源却是差别很大的，对矿工不公平。

聪哥设计的比特币脚本是有二个堆栈，可以实现递归函数调用。递归方法类似于循环语句。但是，比特币脚本实现智能合约之类的程序 ，是把所有的递归（循环）展开，以增大程序的体积为代价，消除了递归（循环），得到的脚本程序必然会停机。智能合约的编译器，在生成比特币脚本指令程序的时候，会有一个程序体积的上限。太大的程序编译时都会报错，不能生成程序。那些不能停机、无限死循环的程序，生成的程序体积必然是无穷大，编译器就会报错，编译器把不能停机的有害程序，提前给拦截下来了。要实现这一点，需要比特币的区块足够大，因为比特币脚本指令的程序也会很大的！

由此可知，比特币的脚本系统设计，根本不是水平差，而是神来之笔！中本聪团队中，有英国的数学家 David Rees。David Rees 教授，年轻的时候，是跟着艾伦 · 图灵一起做项目的。所以中本聪团队，能够对图灵机、图灵停机等理论问题，理解这么深刻。

当然，本文中说的比特币，是指 Bitcoin SV。BTC 以及其它的分叉币，没有这个图灵完备的能力。

©2020 – Metanet.Press 版权所有

从邱少的文章中，我们可以看到，中本聪将比特币脚本故意设计成无循环的是神来之笔。目前来说，比特币BSV在今年2月的创世升级完成之后，已经恢复了中本聪对脚本的最初设计。可以预见的是，比特币BSV链上将会出现包括托管交易、担保交易、第三方仲裁等等各种各样复杂的交易类。