作者：何岩，禁止转载。
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结构来表示交易模型
从此之后我们的账本中的每一条记录，都是这样的JSON格式的数据：
重构后的账本
2.重构程序部分
服务端的程序也需要重构。
2.1服务端的重构
服务端的主要功能：
1.解析消息：解析客户端发来的交易消息请求。
2.验证交易：包括，验证UTXO，验证ScriptSig，验证额度
2.1验证UTXO：验证交易引用的UTXO是否可用。
2.2验证ScriptSig：验证签名脚本，解密签名，得到TXID，验证TXID是否合法。
2.3验证额度：验证交易中IN的额度是否，大于等于，OUT中的额度。
3.交易写入：将交易数据写入账本transaction.txt
4.UTXO查询：根据公钥，查询对应的可用UTXO列表（用于支持客户端计算余额的时候，发起的查询UTXO请求）。
（见下图）
重构后的服务端程序部分
2.2客户端的重构
当然，客户端的程序也要重构，主要功能包括：
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的重构已经完成，但是中本聪不禁会想，交易模型是否还有进化的空间？
难道交易只是转账吗？交易能否抽象成函数？
BSV打赏地址：1BudFu186jzdP9CBJTTPGsdbSJinbzzCyB
下一篇：重新创造比特币9:万物皆交易
相关文章：
比特币SV(Bitcoin satoshi vision,BSV)是目前唯一一个遵循中本聪原始白皮书，遵循中本聪原始协议和设计的比特币。BSV是唯一的公共区块链，维持比特币的原始愿景，并将大规模扩容成为企业级区块链和世界新货币。
网友评论