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：“如果用户的手续费给多了，有什么好处吗，如果没有好处，岂不心理很不舒服”
中本聪：“好处就是，服务端会根据手续费排序，优先处理手续费高的交易，用户会感觉如丝般顺滑”（见下图）
第3个问题：问题(锁定脚本) + 答案(解锁脚本) = 一个完整函数
针对第3个问题，如果交易不可改，脚本输出放在哪？
例子：Alice转账给Bob，同时想要计算1+2的结果。
传统的思维定式是， 1+2是一个完整的函数体， 服务端计算函数体1+2得到答案3，并将答案得写在一个地方。
之所以有这样的思维定式，是因为，我们对于角色的定义，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演进成一个群系统。
BSV打赏地址：1BudFu186jzdP9CBJTTPGsdbSJinbzzCyB
下一篇：重新创造比特币11:群系统(上)
相关文章：
比特币SV(Bitcoin satoshi vision,BSV)是目前唯一一个遵循中本聪原始白皮书，遵循中本聪原始协议和设计的比特币。BSV是唯一的公共区块链，维持比特币的原始愿景，并将大规模扩容成为企业级区块链和世界新货币。
