Grin币交易代码分析

• 什么是Grin

Grin是实现了Mimblewimble协议的一条公链。Mimblewimble实现了压缩交易的历史利于检验节省空间。去除了地址的概念且加密了交易金额，Grin基于对交易输入输出的承若来校验交易的有效性，能提供很好的隐私性。
相对于比特币而言：
有如下优点：
1.隐私性：UTXO中使用commiment替代了账户地址，是的转账用户不可知，同时UTXO交易历史不可知，交易金额不可知。
2.可扩展性：
区块、交易节省空间，所以可扩展性强。
缺点是：
对与需要交易追溯等功能就不支持了。

• PoW相关

Grin的出块率每60秒出一块，每块奖励是60个Grin, 和比特币有上限2100万而言，目前Grin 没有规定上限， 挖矿奖励没有衰减。Coinbase确认数是1000个区块，交易确认数是10个区块。
Grin是使用PoW共识机制，核心算法是Cuckoo,是内存绑定算法，目的是防止GPU、ASIC挖矿。

• Mimblewimble

Grin中mimblewimble实现主要体现在UTXO, Transaction, Block。

1. UTXO上的变化。
   去除了地址的概念，之前BTC里UTXO会有交易的收入地址，具体金额等。
   Grin里存的是交易输出的Commitment以及其对应的RangProof(金额范围值是0到2的64次)。
   只有能解开该commiment的用户才能花费这笔钱， 即有对应的Binding Factor才能花费对应的UTXO。

2. Transaction
   结构体如下， offset是用于交易验证是否合法,body交易主体。
   

   交易主体如下：
   

   1）交易输入如下：
   
   feature：utxo花费的特征，针对的是coinbase是否成熟。
   commit:输出承若。

   2）交易输出如下：
   
   commit:输出承诺，
   proof: 输出值的范围。

   3）Kernal 用于验证交易是否合法，结构如下：
   
   features: kernel特征值，与输入输出commit一起计算验证是否有效。
   fee:交易费用。
   lock_height:锁定高度。
   excess:交易余额承诺。
   excess_sig： excess的签名。
   PS:
   交易链压缩时，会保留最近一段时间的交易记录， 中间数据也会保留一部分（不是所有都丢弃），这样目的是验证交易输入的合法性的工作量保持在一个合理的范围内，同时又保证一定数据历史。
   交易中的每个Input都是唯一的不能重复。
   4）交易过程
   假如A要发送钱给B:A==>B，在btc里A只要知道B的地址，A生交易然后签名上链就完事了，但是在grin里就不一样了，它需要以下三步：
   第一步： A: 生成未完善的交易(交易输出等未完善)。A把该交易发送给B。
   第二步： B收到A未完善的交易，B生成交易输出的对应的commitment,以及以及对应的blinding Factor(这个自己保存)，并且对交易做对应的签名。然后把交易发给A.
   第三步： A收到B完善后的交易，A对该交易做签名等其他处理，然后上链。

3. Block
   1）Btc里有多笔交易，在Grin里只有一笔混币后的交易，例如有如下交易对，A==>B，B==>C，E==>F，在Grin块中只会有一笔交易（A, E） > (C, F)。这里就抹去了B，因为在该过程中B的金额流入又流出了。
   2）中间块合并来缩减交易数据，例如块1中有A>B, C==>D, 块2中有B==>A, D==>E， 块1和块2合并时就会抹去B, D,就是抹去同时在输入和输出的commit.

全节点部署
Grin分为全节点和挖矿工具，全节点负责同步校验区块数据、简单的钱包功能，不负责挖矿功能，挖矿由工具grin-miner承担。
Grin：
代码：https://github.com/mimblewimble/grin
Grin-miner:
代码：https://github.com/mimblewimble/grin-miner
使用命令 cargo build 编译。
浏览器：
https://grinscan.net
使用测试网络Testnet4, 目前测试网上挖矿比较困难，可以使用miner-pool或在论坛请求测试币。
Miner-pool参考：
https://github.com/grin-pool/grin-pool
https://www.grinmint.com/pages/index.html
论坛：
https://gitter.im/grin_community/Lobby

竞品调研
Wallet713
(Ps:这部分代码和线上最新代码有些区别，但是流程是一致的，文档是去年11月份整理的。)
代码目录：https://github.com/vault713/wallet713
该钱包是一款区中心化钱包，基于grinbox开发。
(1) grinbox给交易双方提供简单的交易信息交换的功能，用户使用公钥作为地址标识。基于grinbox发送交易过程如下：
Alice 给Bob发送50个Grin。步骤如下：

	1）Alice创建公钥/私钥对和访问签名, 公钥作为专用地址。
	2）Bob创建公钥/私钥对和访问签名，公钥作为专用地址。
	3）Bob把自己的公钥寄给Alice
	4）Alice给Bob发送50个Grin， 创建一个Slate，并且附加上Bob的公钥地址。
	5）Bob用自己的签名从他的地址中得到了那份信。
	7）Bob处理Slate并把响应写在Alice的地址上。
	8）Alice用自己的签名从她的地址中得到了Slate。
	9）Alice完成交易并将其广播到GRIN Buffic链。

(2）Wallet713，连接了全节点，使用了全节点的来上链交易内容， 同时基于Grin-box来完成交互式交易构造。
做测试如下：

交易打包区块为：71736，下图第二列值为输出commit，包含A的找零。

该区块内容如下（复制于区块链浏览器）：

输出结果如红框。
（3）Wallet713代码分析：工程结构如下

common：常用工具类编解码加密签名等，cli:命令行相关，contract没有细看，grinbox：grinbox的连接库， storage：账户数据存储。Wallet:核心类，实现交易交互式构造。以下进行分析：
1）A 发送未完成的交易Slate给B:
由函数send实现，该函数是做了输出地址的校验，获取了钱包对象，然后初始化化交易，初始化交易由initialte_tx()完成。

该函数最终调用了create_send_tx(),该函数初始化了交易构造Context,该Context里保存了交易输入要使用的commit，及其对应binding factor，该binding factor体现在context.sec_key 和context.sec_nonce

最后调用grinbox客户端发出该Slate.
2）B收到该Slate, 完善该Slate并且发还给A如下图：

函数process_slate如果收到是是完善的的slate，表明之前发送给其他人的交易的slate已经完善，可以上链。如果是未完善slate，说明是别人发给我的交易slate需要我来完善，则完善它。完善slate的代码最终调用到函数receive_tx(),该函数构建了交易输出，填充相应数据，并且做对应签名。如下图中调用函数build_recipient_output_with_slate()创建了交易slate的context, Context里保存了交易输出要使用的commit，及其对应binding factor，该binding factor体现在context.sec_key 和context.sec_nonce。

过程中的签名步骤使用到了blak2b函数。

PS: 寒冬之际，求一个好坑!