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犹如短刀，简单稳定，足够杀伤力。《这个杀手不太冷》里面说过，越厉害的杀手用的武器越简单。

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

第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：“如果用户的手续费给多了，有什么好处吗，如果没有好处，岂不心理很不舒服”

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