作者：何岩，由 recreating.org发行。

0.前言

中本聪和Gilfoyle一起合作，完成了Bitcoin0.0.2版本的设计工作。

重要的改变包括：

1.加入数字签名。

2.公钥替代用户名。

3.将签名加入交易模型。

4.删除了账号模型。

新版本，让交易变得更自由！

1.创建私钥

中途镇，咖啡馆，经过一周的开发和测试，Bitcoin0.0.2版本上线了。

中本聪找到Bob：“Hi，老板，Bitcoin的新版本上线啦！再有新客户想加入，
不用再来找我注册啦，他们自己就可以创建账号（其实是地址，Bitcoin已经没有账户模型了）啦”。

Bob朝着大厅喊道：“太好了！有人要来杯咖啡吗？顺便试试新系统！”

Alice走过来：“我来吧，正好想再喝一杯卡布奇诺。”

Alice拿出手机，打开浏览器，输入bitcoin.org。出现了这样的界面。

Alice叫到：“怎么和以前不一样了！”（见下图）

新版本的登陆页面

中本聪说：“你需要先创建私钥”

Alice问：“什么是私钥？“

中本聪：“你可以把私钥当成是你的账号密码，这个密码很长，可以代替之前的用户名＋密码”。

Alice：“这么说我就理解了”

中本聪：“你先创建私钥吧”

Alice选择创建私钥，点击了确定按钮，进入了下一个界面（见下图）

生成的私钥和公钥

Alice按照提示，拿出笔抄写着自己的私钥：“这个公钥又是什么？”

中本聪：“你可以理解成你的收款地址，你也可以用他来查询余额，公钥是公开的，只有私钥需要保密”

Bob在一旁看着，问到：“这个私钥看起来很重要，它是在哪里生成的？在服务端还是客户端（浏览器就是客户端），安全吗？可以和我说说你是如何做的吗？我以前学过点编程，应该能听懂。”

中本聪说：“原来老板也懂编程啊，私钥是在客户端生成的，私钥永远不会在网络中传输，因为一旦被截获，别人将你的私钥导入，你的余额会被分分钟转走。”

中本聪继续解释：“但是生成私钥的算法代码是在服务端存储的，当浏览器第一次访问bitcoin.org的时候，服务端会将算...

作者：何岩，由 recreating.org发行。

0.前言

Bitcoin的第二个版本已经上线，运行正常。

重要的改变包括：

1.加入数字签名。

2.公钥替代用户名。

3.将签名加入交易模型。

4.删除了账号模型。

本篇在讲如何重新定义交易。

交易是经济学理论的核心，交易是一切。

交易即承载着每个个体的起心动念，交易也承载着整个世界的斑驳陆离。

对交易这个概念的认知高度，决定了Bitcoin系统的高度。

如何认知交易，就表现在如何定义交易。

1.Bug出现！

新版本上线后， 系统看起来一切正常。

不过，只要是人写的程序就会有Bug。

这一天Alice找到中本聪，说自己的余额忽然归零了，怀疑自己的私钥泄漏了。

中本聪赶紧登陆到服务器上，查看账本中的交易记录，发现了Alice的交易记录有异常。

怎么会有重复的交易记录呢？（见下图）

账本

中本聪问：“Alice，你最近做了几次转账？”

Alice说：“就一次，昨天给Carol转账20个Bitcoin”

中本聪说：“可是，在账本里我查到了3笔给Carol的转账（公钥C代表Carol的公钥）”

中本聪找来Gilfoyle，两人一起分析，很快找到了问题所在。

原来是Carol搞的鬼，Carol截获了Alice的交易请求，并重复的将其发送给服务端，服务端错误的认为是Alice在多次请求转账，结果就是将Alice的余额全
部转给了Carol。(见下图)

Carol在搞鬼

2.分析Bug

问题的根源是什么呢？

原来问题出在签名上，在现在的设计中，同一用户在不同交易中，签名没有变化。

服务端只会验证签名真伪，只要签名是真的，交易就成立。

黑客会重复发送伪造的交易请求，直到用户的余额小于交易金额。

那么签名为什么没有变化呢？

这是因为签名是将公钥加密，公钥不变，所以签名就不变。

签名不变，就意味着，签名的权利空间为用户的所有余额。

分析到了这里，中本聪对Gilfoyle说：“我们得让每笔交易中的签名都不同，最好是每笔交易的签名是系统唯一的”

如何做到...

作者：何岩，由 recreating.org发行。

1.重构交易模型

中本聪在脑中，模拟运行着UTXO的设计：“现在的设计应该没有大的缺陷了，可以进入交易模型的设计啦”。

Gilfoyle：“UTXO的确优雅，交易模型的改动会很大”

所谓交易模型的设计，就是说，通过重新构建交易模型，来承载UTXO机制。

新的交易模型，分为四个部分：

1.TXID：交易的Hash值（关于Hash是什么，后续会详细介绍，现在可以简单理解为：任何数据作为参数，输入到Hash函数中，都会生成一个固定长度，并且唯一字符串，即， Hash值=FuncHash(m)。）

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

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

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

解释一下：

TXID：计算交易数据的Hash值：TXID=FuncHash(TX)

IN中引用的每一条UTXO的字段：TXID、VOUT（VOUT是本UTXO其所在的TX的OUT中的排序号）

OUT中每条新生成的UTXO的字段：排序号，收款者公钥，金额

数字签名密文：加密交易的TXID生成的密文：数字签名＝FunSig(付款者私钥, TXID)

ScriptSIG部分：数字签名密文＋付款者公钥（明文），这两个部分用逗号拼接。

例如这样的场景：Alice要转账3.5个Bitcoin给Bob。

Alice的浏览器需要创建交易，包括4个部分：

1.IN：引用了2条属于自己的UXTO。

2.OUT：创建2条新的UXTO，一条UTXO属于Bob，另一条UTXO属于自己的
找零。

3.TXID：生成当前交易的Hash值:TXID=FuncHash(TX)

4.ScriptSIG：Alice的数字签名+Alice的公钥（见下图）

重构后的交易模型

用JSON结构来表示交易模型：(见下图)

从此之后我们的账本中的每一条记录，都是这样的JSON格式的数据：（见下图）

重构后的账本

2.重构程序部分

服务端的程序...

作者：何岩，由 recreating.org发行。

0.前言

本篇会比较抽象，解释为什么要将交易设计成函数等价。

以及，函数的本质是什么？

1.交易改造为标准函数等价

咖啡馆，细碎的闲聊声混合着咖啡的气味。

Gilfoyle端着咖啡杯，望着窗外。

中本聪也端着咖啡杯，望着窗外。

他俩享受着，内心充盈又狂喜的美妙滋味。

中本聪和Gilfoyle对UTXO的设计很满意，他俩很清楚，自己搞出了一个皇冠级别的设计方案。

Gilfoyle转过头，盯着中本聪说：“你有野心吗？”

中本聪一愣：“什么意思？”

Gilfoyle：“我是说，你想把Bitcoin改造的再疯狂一些吗？”

中本聪：“当然，搞崩了我都不怕，怎么奔放怎么来，我是一个自由主义者！”

中本聪：“说说看，你的灵感是啥？”

Gilfoyle：“我想把Bitcoin系统改造成世界通用计算机”

中本聪：“卧槽，牛逼了！节奏对了，嗨起来！继续说！”，显然，中本聪浓缩咖啡喝多了。

Gilfoyle：“现在Bitcoin系统本质上是什么？本质上就是一个交易系统，就是一个单一业务的服务。”

中本聪：“你的意思是，Bitcoin系统可以做，除了转账之外的业务？可是我的初衷，就是构造一个电子现金系统啊！”

Gilfoyle：“初衷限制了你的思路，看不到Bitcoin的可能性。以Bitcoin现在的架构设计，刚好有机会可以改造成世界通用计算机。转账业务反而是优势，甚至是成为世界通用计算机的必要条件”

Gilfoyle：“如何成为世界级的，现在我还想不出方案，但我想明白了，如何成为通用计算机，只需要改动一个点，即可实现！”

中本聪：“这么神奇，改动哪个点？”

Gilfoyle：“只需要将交易改造成函数等价即可！”

中本聪喝了一口咖啡，思考着这句话背后的逻辑。

忽然中本聪兴奋的狠狠拍了下桌子：“我想明白了！的确如此！你真是天才！”

中本聪：“你看看我理解的对不对，计算机的本质既不是编程语言，机器语言这种软件。也不是cpu，内存，硬盘这类硬件。计算机的本质是抽象维度的计算而已。而计算属于逻辑系统。...

作者：何岩，由 recreating.org发行。

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.交易数据不可改：脚本代码的计算结果不应该再次写入交易...

作者：何岩，由 recreating.org发行。

0.前言

本系列的上半部分，主要围绕着交易TX的演进。

从这篇开始，进入下半部分，核心为点对点网络架构。

Bitcoin系统将朝着生命体的方向演进。

1.寻找演进方向

中途镇，咖啡馆。

中本聪和Gilfoyle按照之前的设计，实现了交易脚本机制，Bitcoin就好似生命演化出了细胞。

接下来，中本聪开始思考，如何用细胞拼装出复杂的生命体，甚至是拥有自我意识的超级智能体。

中本聪：“我想将Bitcoin改造成一个可以拥有独立生命的系统，让它可以自给自足，不再依赖我的维护”

Gilfoyle：“啊！你这个IDEA太疯狂了！”

Gilfoyle：“不过仔细想一想，确很符合逻辑。因为如果Bitcoin要成为世界级的通用计算机，那么获得全球的绝对信任是必须，只要系统的运行还要依赖于某一个维护者，那么这个信用就不成立。必须让Bitcoin自食其力，成为一个不依赖某个‘老大哥’的自治系统。愿它最终演化成一个不会被杀死的永动机。”

Gilfoyle：“你有思路了吗？”

中本聪：“这世界上最智慧的事物是什么？就是大自然啊，所以我们应该向大自然学习，学习它设计出来的成功案例。例如蜂群，蚁群，甚至人类大脑等有机体。”

中本聪：“我们用一个概念来表达他们的抽象本质，就是群系统。”

中本聪：“如果我们有足够有野心，就要去挑战这世界上的智能的极限，那就是：创造出一个生命系统！”

中本聪：“所以，Bitcoin的演进方向，就是成为一个，群系统！”

2.群系统

究竟什么是群系统呢？

在这个世界上，存在着两类系统，一类是精确系统，另一类是复杂系统。当前阶段的Bitcoin系统属于前者。而，群系统就属于后者。

有两种极端的途径可以产生“更多”。一种途径是按照顺序操作的思路来构建系统，就像工厂的装配流水线一样。这类顺序系统的原理类似于钟表的内部逻辑——通过一系列的复杂动作来映衬出时间的流逝。大多数机械系统遵循的都是这种逻辑。

“还有另一种极端的途径。我们发现，许多系统都是将并行运作的部件拼接在一起，很像大脑的神经元...

作者：何岩，由 recreating.org发行。

0.前言

中本聪和Gilfoyle明确了Bitcoin的演进方向，即，群系统。

那么，如何设计，可以让一个计算机系统，一步一步由一个精确系统变为一个复杂系统呢？

1.群系统无法被“设计”出来

咖啡馆，Gilfoyle喝着咖啡。

中本聪走进来，捧着一堆书，啪的一声将书摔在桌子上。

中本聪：“我是这么想的，既然Bitcoin的演进方向是群系统，而群系统中的尖货是生命系统。那么我们就要去学习生命系统，怎么学，看书呗！这些是我从城里图书馆找来的生命科学方面的书。”

Gilfoyle：“这个思路不错，从上帝的造物中寻找灵感！”

中本聪：“是的！回顾人类历史上很多伟大的发明，很多都是在模仿大自然。例如，由螳螂发明了镰刀、由蝙蝠发明了声纳和雷达、由蜻蜓发明了飞机。”

说完，俩人拿起书开始快速的翻阅起来，好像侦探在搜罗犯罪现场的蛛丝马迹。

通过这几天的研究，中本聪和Gilfoyle更加确信：生命不是被上帝设计出来的。生命是偶然而成。

所以，Bitcoin也同样不可以被设计，只能通过模仿，模仿那个经过几十亿年打磨而成的造物：生命体。

2.Bitcoin和生命体的类比

如果将演进后的Bitcoin类比成一个最简单的多细胞生命。

1）交易即信息

交易类似与细胞之间传递的信息。交易中即可以装载业务数据，也可以装载算法代码。

交易作为Bitcoin系统中业务层面唯一的信息载体，其意义在于：装载信息的容器是一个具有共识的标准协议。

什么意思呢？

就是说，在系统中的任何需要处理信息的地方，大家都心照不宣的有一个共识，业务信息只会是交易（TX）这一种载体。所以解析信息就省事了，因为不可能出现其它形式的信息，所以各个环节只需要按照交易的约定格式进行拆解，组装，发送。

这就好像，集装箱是统一尺寸，搬运货物的轮船、吊车、汽车等等只要接触集装箱的环节，都可以按照共识来设计尺寸。因为集装箱的尺寸不会变。

这就是协议的意义。Bitcoin中的交易（TX）就是一种标准协议。

集装箱的标准化

具体如何实现呢？

作者：何岩，由 recreating.org发行。

0.前言

中本聪在生命体上找到了Bitcoin演进的灵感，下一步是将技术落地。

生命体演进的顺序是从单细胞到多细胞，之后才出现器官，最后才是大脑。
换句话说，生命可以没有大脑，没有器官，但不能没有生殖细胞。

中本聪开始着手设计事关Bitcoin生存的基础（漩涡模型的内环），即，点对点的记账网络。

点对点，英文是：peer-to-peer ，缩写为：P2P。

Bitcoin的定义从此可以变为：一个点对点电子现金系统。

当然，未来Bitcoin的定义还会发生变化，也许是：一个点对点的通用计算机、一个点对点的超级智能体、或者世界之根：元网（Metanet）。

anyway，有点扯远了，我们回到脚下，开始记账网络的落地。

1.从2个节点开始

中本聪：“现在运行着的Bitcoin服务端，就可以看成是一个单节点。”

Gilfoyle：“可以把它看成是一个单细胞生命体吗？”

中本聪：“不能，它和单细胞生命有着本质的区别。因为，单细胞是生活在同类之间形成的群系统中的，例如之前我们讨论过的费氏孤菌。而当前的Bitcoin是一个世界上孤零零的一个单细胞，在自然界中孤独的单细胞是无法生存下去的。我们的Bitcoin之所以可以生存至今，是因为有我们在维护着它，给他供电，换一种说法，它的生存不可持续。所以，它还不算是一个自治系统。而我们现在要做的事，就是将它升级成一个自治的群系统，这样它就可以靠着自己存活下去，甚至自我演化下去。”

中本聪：“我们先从最简单的场景开始，加入一个新节点，让Bitcoin系统发生质变，成为拥有2个节点的极简群系统。”

Gilfoyle：“我们需要一个新的服务器，正好我家里有台多余的主机，我这就去抱过来”

中本聪：“太棒啦！我还在愁这个月没有闲钱买新主机呢！”
过了一会，Gilfoyle将一个老旧的主机放到了咖啡桌上，现在他们拥有了两台服务器啦。

直接装载之前Bitcoin的服务端代码，是没有效果的，因为两台主机会认为自己是世界上唯一的Bitcoin系统，互相老死不相往来。

中本聪：“...

作者：何岩，由 recreating.org发行。

0.前言

在上一篇中，中本聪和Gilfoyle搞定了最简单的点对点网络。但是无法正常运行，因为账本还没实现同步机制。为了解决账本的同步，需要先引出交易的同步。

1.账本不一致

咖啡馆，中本聪对着老板Bob说：“老板，这几天Bitcoin系统要升级，暂时无法用了”

Bob说：“我看到了，你们又是搬机器，又是写代码，这次升级动静够大的。”

中本聪说：“是啊，Bitcoin要发生质变了，对了，你家要是有不用的机器也搬过来，我们需要更多节点。”

Bob说：“好啊，我家还真有一台，不过运行Bitcoin我能得到什么好处呢？”

中本聪说：“好处……这个我得想想，暂时还没有，纯是友情支持。”

Bob说：“好吧，看在你是我的老客户，我去给你搬过来。”

中本聪说：“太好了！你真是个慷慨的老板！”

中本聪对Gilfoyle说：“我们将要有第3个节点啦！现在，我们来解决账本的同步问题吧！”

我们假设一个交易场景：

1.Alice账本中的余额是50，并且记账节点1和记账节点2的账本一致。

2.Alice的客户端连接的是记账节点1。

3.Carol的客户端连接的是记账节点2。

4.Alice向节点1发送一个交易消息：Alice to Bob 50

5.Carol向节点2发送一个交易消息：Carol to Alice 30

6.这时候的Alice的正确余额本应该是30。但是由于账本没有同步，所以在节点1中Alice的余额是0，在节点2中Alice的余额是80，都不正确。（见下图）

账本不一致

面对这个场景，应该如何解决账本不一致的问题呢？

中本聪解释到：“解决这个场景还算简单。只需要节点互相将自己的账本发送给对方节点，收到对方的账本后，找出自己账本中缺少的交易记录，然后将此交易记录补充到自己的账本，这样俩个节点的账本就又一致了。”
在上面这个场景中，

节点1补充进自己账本的交易记录是：Carol to Alice 30。

节点2补充进自己账本的交易记录是：Alice to Bob 50。

...

作者：何岩，由 recreating.org发行。

0.前言

上一篇描述了交易的同步，如果光是交易的同步是不够的，还需要考虑账本的同步

交易内存池代表着系统的当下，账本代表着系统的过去。

1.三个节点

咖啡馆，老板Bob给中本聪抱来了之前答应过的旧主机。中本聪接过老板怀中的主机，一顿表达感谢。

现在桌子上放着3台主机，由于桌子地方不够用了，第三台机器堆在了另外两台的上面，看起来像个金字塔。

中本聪对Gilfoyle说：“之前的2个节点已经可以正常的提供记账服务了，我们现在把第3个节点也接入Bitcoin网络吧。”

Gilfoyle说：“好，不过我感觉八成会出问题，先运行起来再说，反正现在是测试阶段，遇到问题解决问题。”

中本聪给节点3配置好IP，部署了最新的代码，重启运行。节点3很顺利的自动连接上了节点1和节点2（因为临时方案：代码中写死了节点1和节点2的IP），并且开始同步交易了。（见下图）

节点3加入记账网络，开始同步交易

运行了一会，中本聪发现问题了：“我给忘了，账本的同步还是需要的，新加入网络的节点账本是空的”

Gilfoyle说：“那就改一下代码，每次程序启动，向自己订阅的节点申请账本的同步。”

这个逻辑很简单，中本聪马上改好代码，重新部署了，启动。（见下图）

账本的同步，但是内存池缺失交易

这次节点3完成了账本的同步。

但是观察了一会，中本聪又发现了另一个问题：“我发现节点3的交易记录一直缺失2条交易记录”

原来问题出在这里，节点3加入记账网络的时候，节点1和节点2已经提前在内存中同步好了2条记录：“Alice to Bob 50” 和 “Carol to Alice 30"。而这2条记录还没来得及写入到账本，所以即便节点3得到最新账本，也不会包含这两条交易记录。

而继续运行，节点3只会同步之后发生的交易，即：“Bob to Alice 5”。
所以，节点3就会一直缺失那两条记录。

这就好像，一个中学的课堂上，老师在上面讲课，学生在下面记笔记。这时候一个叫老三的学生迟到了，慌慌张张的坐下来之后，不知道...