本系列连载自《重新创造比特币》，它是一本比特币入门书籍，通过一个虚拟故事，让读者体验从零开始创造比特币的过程，从而理解比特币为什么如此设计。

 0. 前言

Gilfolye 冒出了疯狂的想法，将 Bitcoin 改造为世界通用计算机。

中本聪和 Gilfoyle 已经有了大体的设计思路。

接下来就是将其落地。

1. 交易的数据模型

中本聪：“那么如何将交易函数化，这个点子落地呢？”

Gilfoyle 说出了自己的具体改造思路。

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

1. TXID：交易的 Hash 值

2. IN 部分：本交易引用的所有 UTXO

3. OUT 部分：本交易生成的所有 UTXO

4. ｓｃｒｉｐｔSig 部分：本交易的签名脚本，即，数字签名（密文）＋付款者公钥（明文）

2. 服务端的验证逻辑

服务端的计算资源，在于验证交易的 ｓｃｒｉｐｔSig 是否合法，具体计算步骤如下：

1. 计算当前交易数据的 Hash 值

2. 解密数字签名，得到明文的 TXID

3. 比较第 1 步和第 2 步的结果是否相等，如果相等则认为 ｓｃｒｉｐｔSig 合法。

3. 传统的改造思路

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

我们的目的是将交易改造成函数等价。

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

1. 选择一个成熟的函数式脚本语言，例如 Javaｓｃｒｉｐｔ、Lisp 或者 Forth。

2. 用这个脚本语言来拼装出 ｓｃｒｉｐｔSig 部分，而不再只是加密 TXID。

3. 客户端负责函数的构建。即，用脚本语言表达自己想要计算的逻辑。

4. 服务端负责函数的计算。即，运行 ｓｃｒｉｐｔSig 的脚本语言代码，将结果输出到交易中。并将结果通过消息反馈给客户端。
   （见下图）

加入计算能力

4. 问题和缺陷

听完 Gilfoyle 的思路，中本聪不是很满意：“这个方案还是太传统，不够皇冠级，另外我还发现了几个问题和缺陷”

中本聪诉说着自己看到的问题和缺陷：

1. 死循环：交易中的脚本代码如果被用户写成了死循环，那么 Bitcoin 服务端岂不要被搞崩溃了。

2. 计算量过大：交易的脚本代码即便没有出现死循环，如果代码逻辑过多，服务端计算一样吃不消。

3. 交易数据不可改：脚本代码的计算结果不应该再次写入交易数据，账本只应该记录原原本本的交易数据。

5. 优雅的解决方案

这几个问题，我们一个一个的来思考解决方案。

第 1 个问题：选择一个无循环语句的脚本语言

针对第 1 个问题，为了避免死循环，简单粗暴的解决方案就是，选择一各没有循环语句的脚本语言，那就是古老的 Forth。

Forth 犹如短刀，简单稳定，足够杀伤力。《这个杀手不太冷》里面说过，越厉害的杀手用的武器越简单。

Forth 就是匕首，稳定灵活

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

复杂语言就是机关枪，杀伤力大，不稳定

第 2 个问题：交易收取手续费

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

Bitcoin 的计算资源不再免费提供，之前由于计算的业务单一，只需要验证数字签名，服务端成本可控，也就默默承担了。一旦变成世界通用计算机，就得走市场经济，让价格通过市场自动调节。

Gilfoyle 问到：“如何收取手续费呢？”

中本聪：“只需要让用户在构建交易的时候，IN 的部分大于 OUT 的部分，IN 减去 OUT 剩余的资金就是服务端的手续费啦。例如，Alice 引用了 5 个 Bitcoin 的 UTXO，转账给 Bob3 个 Bitcoin，本来应该再构建一个 2 个 Bitcoin 的 UTXO 找零给自己。但是如果这笔交易的手续费是 0.1 个 Bitcoin，那么 Alice 就只能给自己找零 1.9 个 Bitcoin 了。多余的那 0.1Bitcoin 就会被服务端认为是手续费，服务端就会构建一个 0.1btcoin 的 UTXO 指向自己的地址。”

中本聪：“如果服务端觉得这笔交易的手续费不够，就会拒绝处理，返回给客户端的消息。我们约定一个底线价格，1 个 bit 最少的费用是 1 聪，1 聪等于一亿分之一个 Bitcoin。这样客户端在计算手续费的时候就心理有谱了。”

Gilfoyle：“如果用户的手续费给多了，有什么好处吗，如果没有好处，岂不心理很不舒服”

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

手续费

第 3 个问题：问题 (锁定脚本) + 答案 (解锁脚本) = 一个完整函数

针对第 3 个问题，如果交易不可改，脚本输出放在哪？

例子：Alice 转账给 Bob，同时想要计算 5-3 的结果。

传统的思维定式是， 5-3 是一个完整的函数体， 服务端计算函数体 5-3 得到答案 2，并将答案得写在一个地方。

之所以有这样的思维定式，是因为，我们对于角色的定义，Alice 的角色就是函数构建者。服务器就是函数计算者。

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

将 Alice 定义为问题提出者。

将 Bob 也引入进来，将 Bob 定义为问题解答者。

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

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

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

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

服务端验证一笔UTXO是否合法的时候，本质上就是将解锁脚本和锁定脚本拼在一起，并执行，得到的结果只会是 True 或者 False。这样就不必存储结果了，如果为 True 就继续执行，如果为 False 就中断。

所以本质上，一笔 UTXO是否可以被花费，就看解锁脚本是否可以解开 UTXO 上的锁定脚本。

我们整理一下：

1. Alice＝问题提出者。UTXO 创造者，UTXO 上挂着锁定脚本。

2. Bob＝问题解答者。UTXO 的引用者，引用的部分上挂着解锁脚本。

3. 服务端＝问题验证者。拼接解锁脚本＋锁定脚本，运行后看结果是否为 True。

6. 交易数据模型的重构

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

1. OUT 部分，给每一笔生成 UTXO 都加上锁定脚本：ｓｃｒｉｐｔPubKey

2. IN 部分，给每一笔引用的 UTXO 都加上解锁脚本：ｓｃｒｉｐｔSig

3. 移除之前交易中的 ｓｃｒｉｐｔSig 签名脚本。

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

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

例如上图中，锁定脚本为：3 OP_ADD 5 OP_EQUAL，解锁脚本为：2。
服务端会将 ｓｃｒｉｐｔSig+ｓｃｒｉｐｔPubKey 视为一个完整函数体，如下：

2 3 OP_ADD 5 OP_EQUAL

OP_ADD 表示相加，OP_EQUAL 表示如果相等结果为 True，否者为 False。
所以这个脚本的意思就是 2+3 是否于 5 相等。结果相等，所以服务端验证通过。

用 JSON 结构来表示交易模型：

两笔关联的交易组合，构成一个标准函数等价。

函数的计算资源，由服务端移到了客户端，本质上所有使用 Bitcoin 的客户端都是计算资源。

服务端只是做验证，保障计算的信用，所以 Bitcoin 本质上就是一个信用引擎。

由于，交易实现了函数等价，所以，Bitcoin 实现了通用计算机的能力。
下一步还需要考虑，如何让 Bitcoin 成为世界级的通用计算机。

7. 后记

本系列的上半部分就完成了，主要是在讲述交易 TX。

下半部分的核心是如何将 Bitcoin 演进成一个群系统，以便更好的支撑交易这个系统的核心业务，实现交易的自由和公平。

来源：比特币协会 BA