本系列连载自《重新创造比特币》，它是一本比特币入门书籍，通过一个虚拟故事，让读者体验从零开始创造比特币的过程，从而理解比特币为什么如此设计。

1. 重构交易模型

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

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

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

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

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

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

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

4. ｓｃｒｉｐｔSIG 部分：本交易的签名脚本：数字签名（密文）＋付款者公钥（明文）

解释一下：

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

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

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

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

ｓｃｒｉｐｔSIG 部分：数字签名密文＋付款者公钥（明文），这两个部分用逗号拼接。

例如这样的场景：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. ｓｃｒｉｐｔSIG：Alice 的数字签名+Alice 的公钥（见下图）

 重构后的交易模型 

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

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

重构后的账本

2. 重构程序部分

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

服务端的重构

服务端的主要功能：

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

2. 验证交易：包括，验证 UTXO，验证 ｓｃｒｉｐｔSig，验证额度

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

2.2 验证 ｓｃｒｉｐｔSig：验证签名脚本，解密签名，得到 TXID，验证 TXID 是否合法。

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

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

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

重构后的服务端程序部分

客户端的重构

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

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

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

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

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

5. 创建交易

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

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

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

5.4 生成 ｓｃｒｉｐｔSig：加密 TXID 得到签名和公钥明文

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

重构后的客户端程序部分

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

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

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

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

3. 后记

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

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

来源：比特币协会 BA