每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
目录
1. 动机
2. TXO提交
2.1 延迟提交
2.2 实施
2.2.1 快道：区块中验证TXOUT花费
2.2.2 慢道：计算挂起TXO提交
2.2.3 TXO MMR实施细节
2.2.4 共识与修剪
2.2.5 共识关键存储开销
2.2.6 非共识关键存储开销
2.3 安全模型
2.4 其他工作
3. 参考
1. 动机
UTXO增长关乎比特币长久的去中心化。 挖矿竞争说白了也是时延的竞争，势必需要将整个UTXO集置于RAM中，造就一批更强但更集中的竞争者。有鉴于挖矿是场零和游戏，时延直接影响着利润率。另外，UTXO集也是运行全节点门槛之一，但是集越大，运行全节点的难度越高。
当前，除了块大小能稍微限制下UTXO集大小，协议层面是不设限的。早先在磁盘上的压缩序列化UTXO集大小为1.3GB，在内存中就更大了。UTXO增长受诸多因素驱动，包括：懒得合并输入、丢失币、不能花的散碎输出以及非（比特币）价值转移‘区块链’用例，比如反重放预言机或者时间戳这种，等等。
对抗UTXO增长一直也没什么好方法。SegWit提议压缩见证人空间到以前的1/4，想要通过降价txouts花费来降低UTXO集的部分大小。这么一来虽然有可能让钱包多花点散碎输出，但是前面也说了UTXO集增长是多因素合力导致，况且散碎输入并不算是UTXO集增长的主力军，想不出有什么激励手段能有效遏制全部增长行为。
比如说吧，时间戳应用易于实施，但也因此会创建些花不出去的输出。而这些输出算是确保重建时间戳证明所需数据不会丢失最简单的方式，那么所有比特币全节点就不得不保留输出的副本。再比方说，依仗比特币高度的安全及去中心化属性的反重放用例中，需要用UTXO集进行密钥轮换；想找个能代替比特币的系统基本不可能。与转账相比，这些非价值转移功能的使用者情愿花50刀注册个PGP密钥，但一般是不愿意花50刀手续费做一笔两个输出的标准交易。加之一些能有效抵制矿工审查的技术，因此需要借助白名单来阻止非价值转移用例这种‘垃圾’用法加剧比特币的负担。
诚然，UTXO集大小的硬上限以‘固定门槛’的方式为运行高性能比特币节点创造公平条件的同时，也弱化了垃圾UXTO问题的严重性。 但是，抛开币龄或价值，搞出来些不能花的硬币于政治于经济都是不太合理的。
2. TXO提交
提交所有交易输出状态（包括花费和未花费）的Merkle树是种能紧凑地证明输出当前状态的办法。相当于把UTXO集中不常用的部分‘存档’，也意味着全节点即便丢弃了相关数据，也能向其他节点证明输出未花费，进而花掉这些“存档”输出。
具体来说，TXO提交提出了一个‘Merkle 山脉（MMR）1’的概念，即一种确定性、可索引、插入有序（insertion ordered）的Merkle树，允许以最低的存储门槛将新条目便便宜宜地添加到树上，大小只有log2n的“山尖”。 输出添加至TXO MMR后，永远不会被删除；若输出被花掉，状态就地更新。 MMR中某条目的状态以及该条目变更的有效性都可以通过log2n大小的证明（数据）进行证明，该证明由到树尖的Merkle路径组成。
极端一点的话，有了TXO提交，UTXO集可以没有，那么UTXO集增长自然也不再是问题了。意思是说交易中只有TXO提交证明，表明想要花掉的输出是未被花费的状态；节点可以直接从TXO提交证明中更新TXO MMR的状态。 但是，这样的话，每个txin的log2n带宽开销会很大，所以，真正实施起来，还是应该有个最近交易的UTXO缓存，然后需要花掉旧txout时，才切换到TXO提交上。
另外，也可以在没有签名者参与的情况下生成证据并将其添加置交易；因为证明本身不需要签名且证明不包含在交易哈希中。能够访问TXO MMR数据的人都可以（重新）生成缺失的证明，因此钱包软件小改一下就能使用TXO提交。
2.1 延迟提交
TXO提交非新概念，与UTXO提交3先后提出的2。然而，对于小矿工的孤块费率而言，区块验证速度越快越好，且到目前为止，创建性能优越的（U）TXO实施已经是公知的困难，同时更新并重新计算加密哈希过的Merkle数据集本来就费事。不过幸运的是，若维护个最近输出的UTXO集，那么只有在花费旧的存档输出时才需要TXO提交。 那么，就可以通过延迟提交来利用这一点，意思是说在实际使用之前先计算好，把时延问题变成个简单点的吞吐问题。
具体而言，每个块Bi提交到TXO集的状态为区块Bi-n，就是说，若无n块延迟，TXO提交在n块之前的样子。由于该提交仅取决于区块链到块Bi-n的内容，那么这之后区块的内容便与计算无关。
2.2 实施
实现高性能/低时延延迟提交全节点，需要存储以下数据：
1. UTXO集：已知未花费txouts的低时延K：V映射。 与现有UTXO实现类似，主要区别在于旧的未花费输出可能被从UTXO集中删除。
2. STXO集：创建于TXO提交前，已知在最近一次TXO提交后由交易花费的交易输出集。
3. TXO日志：需要在TXO MMR中标记为已花费的输出FIFO。添加至日志必须为低时延，从日志删除可为高时。
4. TXO MMR列表：TXO MMR的可修剪有序列表，主要为最高级别待处理提交，由引用计数、摘要索引的加密哈希对象存储支持（类似于git repos原理）。
2.2.1 快道：区块内验证txout花费
区块内交易花费某交易输出时，有两种情形：
最近创建的输出：在最近的TXO提交后创建的输出，因此应该在UTXO集中；花费该输出的交易不需要TXO提交证明。 从UTXO集中移除该输出并添加置TXO日志。
存档输出：在最近的TXO提交前创建的输出，因此无法保证输出在UTXO集中；花费交易需要有个最近TXO提交的证明，证明输出未花费。 检查输出是否已经在STXO集中（双花），若不在，则添加输出进STXO集。 将输出及TXO提交证明添加至TXO日志。
两种情况下，将输出记录为已花费需要两次密钥：值更新，加上一步添加至日志的操作。现有UTXO集每花费一次，密钥：值更新一次，因此即便是100％存档输出花费的情况下，新区块验证时延也不会超过当前时延的2倍。
2.2.2 慢道：计算挂起TXO提交
低优先级后台任务中，划掉TXO日志，记录TXO MMR中每个区块花掉的输出，哈希MMR数据获得TXO提交摘要。 此外，此后台任务还移除了已记录在TXO提交中的STXO，并且修剪掉没用的TXO提交数据。
TXO提交计算的吞吐量会比当前仅UTXO方案差一些，进而影响批量验证，比如初始块下载。 话虽如此，TXO提交也有一些其他的手段可以减轻验证速度慢对吞吐量的影响，例如跳过旧历史验证以及防欺诈等。
https://petertodd.org/2016/delayed-txo-commitmentspetertodd.org
网友评论