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.重构程序部分

服务端的程序也需要重构。

服务端的重构

服务端的主要功能：

1.解析消息：解析客户端发来的交易消息请求。

2.验证交易：包括，验证UTXO，验证ScriptSig，验证额度

2.1验证UTXO：验证交易引用的UTXO是否可用。

2.2验证ScriptSig：验证签名脚本，解密签名，得到TXID，验证TXID是否合法。

2.3验证额度：验证交易中IN的额度是否，大于等于，OUT中的额度。

3.交易写入：将交易数据写入账本transaction.txt

4.UTXO查询：根据公钥，查询对应的可用UTXO列表（用于支持客户端计算余额的时候，发起的查询UTXO请求）。
（见下图）

重构后的服务端程序部分

客户端的重构

当然，客户端的程序也要重构，主要功能包括：

1.导入私钥：用户可以直接导入自己自己保存的私钥。

2.创建私钥：用户也可以通过客户端的算法运行生成私钥。

3.生成公钥：根据私钥生成公钥

4.余额查询：调用服务端提供的，UTXO查询服务，求和得到余额

5.创建交易

5.1生成IN部分：调用服务端的UTXO查询服务，构建可引用的UTXO

5.2生成OUT部分：生成新的UTXO

5.3生成TXID：计算交易数据的hash值

5.4生成ScriptSig：加密TXID得到签名和公钥明文

6.消息发送：将交易数据放入消息，请求服务端。
（见下图）

重构后的客户端程序部分

这里要提醒一下，所谓的客户端的程序，虽然是运行在浏览器中，但是程序的代码的来源，是来自于服务端，浏览器访问bitcoin.org就是在请求代码，然后将代码缓存在浏览器里，等待后面的运行。

由于服务端实质上，控制着客户端代码的变更，所以这种设计模式，还是不够自由公平。因为我们无法防止服务端的维护人员作恶，例如私自改动客户端的代码。

如何降低客户端对服务端的依赖，这个是一个大问题，我们留给中本聪后面再去解决吧。

经过数据部分和程序部分的重构，加入了UTXO机制的新版本，已经设计完毕。

3.后记

UTXO的重构已经完成，但是中本聪不禁会想，交易模型是否还有进化的空间？

难道交易只是转账吗？交易能否抽象成函数？

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

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