应对UTXO集增长问题：低时延延迟TXO提交方案（3）
每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
2.2.4 共识及修剪
注意，共识是修剪行为的关键因素，所谓共识关键：修剪过早导致丢失数据的全节点达不成共识；未能根据共识要求包含Merkle证明的矿工出块无效。与此同时，许多全节点手里的数据会明显多于所需的最低数据量，因此可以帮助钱包做花费旧硬币的交易；实现最好考虑将共识关键的数据与其他（非关键）数据相分离。
最简单的方法是一事一议：TXO提交也对UTXO到期规则需要和不需要保留的数据进行提交。但是，（TXO）不提交的话，就能允许某些类型的软分叉，好比软分叉中协议变更为需要比以前更多的数据。
2.2.5 共识关键存储开销
仅UTXO和STXO集需要保存在快速随机存取存储器上。 由于STXO集条目只能通过花费UTXO来创建并且小于UTXO条目，可以保证UTXO和STXO组合集最大值始终小于当前仅UTXO方案中的UTXO集。（花费大量存档txout时，组合集大小可能暂时大于UXTO集）。
TXO MMR中的TXO日志条目和未经修改的条目的最大开销为log2n/每条目，即至TXO提交的唯一Merkle路径（“唯一”是指没有其他条目与其共享数据）。 处理速度比较快的系统中，TXO日志刷新速度也会比较快，最后转换为TXO MMR数据；TXO日志大小不会超过若干区块大小。
花费非归档txouts的交易不需要提供任何TXO提交数据；但是需要以每个UTXO一个TXO MMR条目的形式保存将该数据保存在身边。一旦花费，与该非存档txout相关联的TXO MMR叶节点可以立即被修剪，由于不在UTXO集中，因此不能花费。有鉴于数据现在是不可变的，也就永远不会再需要它了。TXO MMR中的内部节点也可以被修剪，若节点下的所有叶子都被花掉，若TXO MMR是个Merkle和树4，修剪掉内部节点应该很容易，原因是每个内部节点会提交它下面未花费的txout总和。
花费存档txout时，需要交易提供至最近的TXO提交的Merkle路径。 上面说过，路径信息足以恢复TXO MMR中的必要节点，随后即刻应用于该笔花费，将问题变成TXO日志大小问题。
考虑到所有这些因素，与当前相比，TXO提交方案最大的存储开销便是log2n的Merkle路径；只要少于1/log2n的UTXO集处于活跃、非存档状态，就可以了。
2.2.6非共识关键存储开销
花费存档txouts的交易有两方面挑战：
1. 获取最新的TXO提交证明
2. 区块被挖出时证明被更新
问题1可以由专门的归档节点处理，与一些节点通过布隆过滤器或Electrum协议使钱包可访问交易数据类似。手段其实还蛮多，且能对轻松分片，实现水平扩展，因为数据是自我验证的，允许水平扩展而无需信任。
尽管矿工和中继节点不需要关注初始提交证明，但更新该证明就是另一回事了。 若节点在计算挂起TXO提交时大量修剪旧版本的TXO MMR，那么挖出下个块的时候，节点就没有数据来更新TXO提交证明对出块进行验证，虽说TXO MMR末端的子节点绝对已经变了，但大量修剪的时候这个数据也就一起丢弃了。
中继节点的话，在交易首次广播时完整中继交易一次，此后在不提供内存池功能，因此可以忽略此问题。但是Peter T.早先也指出过，中继节点是不需要内存池的5。
于矿工而言，挖出区块后没有更新证明所需的数据意味着可能拿不到交易费。 所以，问题又成了，所需数据怎么量化？
由于TXO MMR是插入排序的，因此花费非存档txout只能使存档txout的TXO MMR证明中的上层节点无效（想象个两层的方案，每个块都有TXO MMR ，由所有块的主MMR提交）。变更的内部节点数量最多为每个块log2n，因此若最近的TXO提交和待处理的TXO MMR末端之间有n个非归档块，则需存储nlog2n个内部节点， 若n等于一年的出块数量，这个大小大约在几十MB的样子。
另一方面，花费存档txout可以使任何级别的TXO MMR证明无效（考虑下花费相邻两个txout的情形）。为了确保成功花费，需要存储完整证明。但是，完整证明首选受限于块大小限制，其次这个用法并不常见。比方说吧，若1MB区块中有1％是存档花费，那么一年的TXO提交延迟只有小几百MB低IO性能要求的数据。
2.3 安全模型
当然了，TXO提交延迟一年是有点扯。最慢的计算机也就需要个把区块的TXO提交延迟，而且谁也没说UTXO存档延迟比TXO提交延长时间长不行。
然而，与UTXO提交一样，TXO提交允许矿工挖矿不验证之前历史，因此对比特币安全模型带来问题。极端情况下，全节点用点额外的网络带宽便可换取去延迟提交，或者默认全部交易都包含证明输入未花费的证明进而挖出完全无状态的区块。尚未验证的TXO提交证明没办法证明交易输出确实未被花费，只能说某些矿工声称txout未花费。
再或者，可以“虚拟”实施TXO提交，意思是说矿工不用在自己挖出的区块中包含TXO提交摘要。那么，全节点就得从零开始计算提交，就跟计算UTXO状态或总工作量一样。不愿意验证旧历史的全节点运行者可以从可信来源获取TXO状态副本，跟从可信来源获取UTXO集副本的方式一样。
实用一点的话，就是直接相信人们无论如何都会这样做，因此姑且认为足够老的块都是有效的。那么，“足够老”具体是多老呢？首先，若全节点实施来源正常并具有相对新的最低总工作量阈值6（就是说，实施不认可总工作量小于此数值的链），则认为任何具有足够算力能使得分叉链满足该阈值的Sybil攻击者，也有足够算力威胁主链。
这也说明有可能试图伪造TXO提交。这种情形下，“假设有效”的阈值决定全节点开始认可无效链之前攻击必须持续的时间，或者说新上来的全节点认可需要的攻击时间。因此，“假设有效”的最低年龄本身就是政治、社会、技术所关注的不同点之间的来回拉扯；但是总得留几周出来给防御者们做做各种准备不是。
考虑到这一点，长一点的TXO提交延迟7可能有助于确保全节点软件不抄近路实实在在的去验证最低门槛数量的区块。实现的方法有多种，好比先前区块证明8、欺诈证明或者依赖区块链数据的内循环PoW。 与UTXO提交一样，TXO提交也可以有效降低SPV钱包获取交易数据必须信任三方的需要。
2.4 其他问题
3. 参考
1. Merkle Mountain Ranges, Peter Todd, OpenTimestamps, Mar 18th 2013.
2. #bitcoin-wizards IRC discussion, Oct 17th 2013
3. Pettycoin Revisted Part I: Utxo Commitments, Rusty Russell, Nov 29th 2014
4. Proving Your Bitcoin Reserves, Zak Wilcox, Feb 27th 2014
5. Do we really need a mempool? (for relay nodes), Peter Todd, bitcoin-dev mailing list, Jul 18th 2015
6. Checkpoints that reject any chain without a specific block are a more common, if uglier, way of achieving this protection.
7. A good homework problem is to figure out how the TXO commitment could be designed such that the delay could be reduced in a soft-fork.
8. Segregated witnesses and validationless mining, Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015
Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitmentspetertodd.org
