0.前言

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

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

接下来就是将其落地。

1.交易的数据模型

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

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

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

1.TXID：交易的Hash值

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

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

4.ScriptSig部分：本交易的签名脚本，即，数字签名（密文）＋付款者公钥（明文）

2.服务端的验证逻辑

服务端的计算资源，在于验证交易的ScriptSig是否合法，具体计算步骤如下：

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

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

3.比较第1步和第2步的结果是否相等，如果相等则认为ScriptSig合法。

3.传统的改造思路

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

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

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

1.选择一个成熟的函数式脚本语言，例如JavaScript、Lisp或者Forth。

2.用这个脚本语言来拼装出ScriptSig部分，而不再只是加密TXID。

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

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

加入计算能力

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都加上锁定脚本：scriptPubKey

2.IN部分，给每一笔引用的UTXO都加上解锁脚本：scriptSig

3.移除之前交易中的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结构来表示交易模型：

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

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

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

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

7.后记

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

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

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。