重塑比特币 | 第 10 章事务脚本

本系列连载自比特币入门书籍《再造比特币》。 通过一个虚拟的故事，读者可以体验到比特币从无到有的创造过程，从而理解比特币为什么要这样设计。

0.前言

Gilfolye 想出了将比特币转变为世界通用计算机的疯狂想法。

中本聪和吉尔福伊尔已经有了一个总体设计思路。

下一步是把它放在地上。

1.交易数据模型

中本聪：“那么如何将交易功能化，这个想法是如何实现的？”

吉尔福伊尔表达了他具体的改造思路。

当前交易的数据模型包括这4个部分：

TXID：交易的哈希值 IN部分：本次交易引用的所有UTXO OUT部分：本次交易生成的所有UTXOScriptSig部分：本次交易的签名脚本，即数字签名（密文）+付款人公钥（明文） ) 2.服务端验证逻辑

服务器的计算资源是为了验证交易的ScriptSig是否合法。 具体计算步骤如下：

计算当前交易数据的Hash值解密数字签名，得到明文的TXID。 比较步骤 1 和步骤 2 的结果，看它们是否相等。 如果它们相等，则 ScriptSig 被认为是合法的。 3、传统改造思路

我们要动刀的地方就在上面两个地方。

我们的目标是将交易转化为功能等价。

按照传统的思路，改造的思路会是这样的：

选择一种成熟的函数式脚本语言，例如 JavaScript、Lisp 或 Forth。 使用此脚本语言来组装 ScriptSig 部分，而不仅仅是加密 TXID。 客户端负责函数的构建。 即用脚本语言表达你要计算的逻辑。 服务器负责函数的计算。 即运行ScriptSig的脚本语言代码，将结果输出到交易中。 并将结果通过消息反馈给客户端。

（见下文）

增加计算能力

4.问题和错误

听完 Gilfoyle 的想法后，中本聪不是很满意：“这个方案还是太传统了，不是皇冠级别的，我也发现了几个问题和缺陷”

中本聪讲述了他看到的问题和缺陷：

死循环：如果交易中的脚本代码被用户写成死循环，那么比特币服务器就不会崩溃。 计算量过大：即使交易的脚本代码没有死循环，如果代码逻辑过多，服务器端的计算量也会过大。 交易数据不可更改：脚本代码的计算结果不应再次写入交易数据，账本只记录原始交易数据。 5.优雅的解决方案

让我们一一考虑这些问题的解决方案。

问题一：选择没有循环的脚本语言

对于第一个问题，为了避免死循环比特币脚本语言，简单粗暴的解决办法是选择一种没有循环语句的脚本语言，也就是古老的Forth。

Forth就像一把匕首，简单而稳定，足够的杀伤力。 正如《这个杀手不太冷》中提到的，越是强大的杀手，使用的武器就越是简单。

Forth是一把匕首，稳定而灵活

带有循环语句的脚本语言就像一把重型机关枪。 一旦使用不当，很容易走火，子弹卡壳。 越复杂，就越危险。

复杂的语言就像机关枪，威力大，不稳定

问题二：交易手续费

对于第二个问题，为了避免计算逻辑过于复杂，我们采用收取交易手续费的方式，根据交易字节的大小调整手续费。 字节越多，你的脚本代码越复杂，手续费也会越高。

比特币的计算资源不再免费提供。 之前因为计算业务单一，只需要数字签名验证，服务器成本可控，所以默默承担。 一旦成为世界通用的计算机，就必须采用市场经济，让价格通过市场自动调节。

吉尔福伊尔问道：“你们是怎么收费的？”

中本聪：“只需要让用户构造交易，IN部分大于OUT部分，IN减去OUT剩余的资金就是服务器端的服务费。比如引用Alice 5个比特币UTXOs 并转给 Bob 有 3 个比特币，他应该为自己构造一个 2 个比特币的 UTXO 找零。但是如果交易费是 0.1 个比特币，那么 Alice 只能给自己 1.9 个比特币。多出的 0.1 个比特币将被视为服务器收取手续费，服务器会构造一个0.1btcoin的UTXO指向自己的地址。”

中本聪：“如果服务器觉得交易手续费不够，会拒绝处理，并给客户端返回消息。我们约定一个底线价格，1比特的最低手续费是1聪，1比特中本聪等于一亿个比特币，这样客户在计算手续费的时候就会有一个合理的想法。

Gilfoyle：“如果用户多付一些费用，有没有好处？如果没有好处，心理上岂不是很难受？”

中本聪：“好处是服务器会根据手续费对交易进行排序，优先处理手续费高的交易，用户感觉顺滑如丝”（见下图）

手续费

问题三：问题（锁定脚本）+答案（解锁脚本）=一个完整的功能

对于第三个问题，如果交易不能更改，那么脚本输出应该放在哪里？

例子：Alice 给 Bob 转钱，想计算 5-3 的结果。

传统的思路是5-3是一个完整的函数体，服务端计算函数体5-3得到答案2，答案要写在一处。

我们之所以有这样的心态，是因为在我们对角色的定义中，Alice 的角色是函数构建者。 服务器是函数计算器。

如果我们打破这种传统的角色定位：

将 Alice 定义为提问者。

还要介绍 Bob，将 Bob 定义为问题解决者。

那么服务器的角色就是验证者，验证Bob的答案是否等于Alice的问题。

这样，函数体就被分成了两半，一半代表问题，另一半代表答案。 服务端将两半代码结合起来得到一个完整的函数，并执行它来验证结果是否为真。

代表问题的脚本代码，我们称之为UTXO锁定脚本。

代表答案的脚本代码，我们称之为：UTXO解锁脚本。

服务器在验证一个UTXO是否合法时，本质上是将解锁脚本和锁定脚本结合起来执行。 结果只会是 True 或 False。 这样就不用存储结果了，如果是True就继续执行，如果是False就中断。

所以从本质上来说，一个UTXO能否被花费取决于解锁脚本能否解锁UTXO上的锁定脚本。

让我们整理一下：

爱丽丝=提问者。 UTXO 的创建者，UTXO 挂了一个锁定脚本。 Bob = 问题解决者。 UTXO的引用者，解锁脚本挂在被引用的部分。 服务器 = 问题验证者。 拼接解锁脚本+锁定脚本，运行看看结果是否为True。 6、交易数据模型重构

具体交易数据结构改造如下：

在OUT部分，为每个生成的UTXO添加一个锁定脚本：scriptPubKeyIN部分，为每个引用的UTXO添加一个解锁脚本：scriptSig去除上一笔交易中的ScriptSig签名脚本。

（见下图，红色是新改造的地方，我们会看到每个UTXO都有一对解锁和锁定脚本）

添加锁定和解锁脚本后的交易数据模型

例如上图中，锁定脚本为：3 OP_ADD 5 OP_EQUAL比特币脚本语言，解锁脚本为：2。

服务器会将scriptSig+scriptPubKey视为一个完整的函数体，如下：

2 3 OP_ADD 5 OP_EQUAL

OP_ADD表示加法，OP_EQUAL表示如果相等结果为True，否则为False。

所以这个脚本的意思就是2+3是否等于5，结果相等，所以服务器端验证通过。

使用JSON结构表示事务模型：

两项关联交易的组合构成标准的功能等同。

函数的计算资源从服务端转移到客户端。 本质上，所有使用比特币的客户端都是计算资源。

服务器只是做验证来保证计算的信用，所以比特币本质上是一个信用引擎。

由于交易实现了功能等价，比特币实现了通用计算机的能力。

下一步是考虑如何让比特币成为世界级的通用计算机。

7.结语

这个系列的前半部分是完整的，主要是关于交易TX。

下半场的核心是如何将比特币演变成一个集群系统，以更好地支撑交易系统的核心业务，实现交易的自由和公平。