虽然用时比我们预期的久，但是Bitcoin SV节点软件1.0.7测试版本（名为Dynastic）终于将在1月初发布了。
我们在这次发布的Dynastic版本上忙活了近一年，为了解决我们此前从Bitcoin Core（BTC）那里继承的一个特别棘手的麻烦事。这次代码更改很多，因此我们需要比通常的测试更加谨慎，但我相信大多数 BSV 应用程序开发者会认为这是值得的。
上面是一个动态图表，演示了随着时间推移，我们向Bitcoin SV 节点提交200万笔交易时的情况。Y 轴表示节点接受的交易数量，X轴是经历的时间，单位为秒（动画演示中我们对时间进行了加速）。橙色线是v1.0.7最新测试版软件的表现，蓝色线是以前的v1.0.6软件。在第一张图表中，你可以看到v1.0.6和v1.0.7的表现几乎是相同的；第二张图中你可以看到差异开始显现；第三图你可以看到戏剧化的差异。
上面为什么有3个并列的图表？答案就在每个图表的上方。这三个图表中所提交的交易分别是（祖孙）交易链长度为1、50和1000的交易集。
祖孙交易链长度25的限制已成为历史！
在Bitcoin SV v1.0.7测试版中，我们将祖孙链默认限制长度从25提高到了1000。我们也测试过了更长的链，观察到了相似的线性性能曲线。实际上，除了因为在一个充满敌意的环境中我们需要格外谨慎，并没有什么明确的理由阻止我们删除这个限制。因此请放心，在这次将上限提升至1000几个月后，我们就会彻底移除限制。我们认为移除了这个限制还可以使性能略有提高，因为不需要再计算交易链长度了。
话说回来，为什么一开始会有这个限制呢？为什么我们花了很久才移除它？
区块构建的历史
一开始，bitcoind 0.1.0版本的做法相当简单：每隔一秒左右，它就对接收到的所有交易做一次内存映射，并检查其中所有新的交易以确保它们满足了最低的交易费要求；只要满足，就将它们添加到区块模板中，这就相当于一个有顺序的、有效交易的列表。接下来计算这组交易的merkle树，并构建一个区块头来开始进行工作量证明（挖矿）。这个过程可以被优化，但当时这种做法已体现出足够高的效率，因此并没有人对此进行不必要的优化。
随后出现了1MB区块大小限制和打造一个交易费市场的想法。当时的想法是，限制区块大小将创造出对区块空间的需求，并推高交易手续费，进而让用户竞价交易费，以争取自己的交易被打包入块。这时就对比特币软件提出了新需求：如果一个矿工由于1MB限制无法选择所有的可用交易，他就需要通过选择高费率的交易来最大化他自己的挖矿收入，把利润较低的交易留给他人后续处理。
限制区块大小的后果
因为限制了区块大小，因此构建区块的代码变成了一个如同要对意大利面条进行记账的噩梦，而且基于这个限制还衍生了其它规则。选择高费率的交易听起来很简单，但实际上当您有未确认的祖先交易并且出现CPFP（child-pays-for-parent）时，将会面临大量的图形遍历工作和其它可怕的复杂性情况。比如每新增一个关联交易时，基本上就需要再次遍历与这个交易有关联的交易图组，这会带来二次计算成本。进一步解释就是，关联交易集合越大，在集合上进行操作就越贵，结果就是速度呈指数级下降。这一点从我们上面的图表中就可以清楚的看到，随着关联交易集合数量的增大，我们传输交易到 mempool 的速率会急剧下降。
你也可以在用Bitcoin Core、Bitcoin ABC 和旧版本的Bitcoin SV软件生产的区块中的交易布局里，观察到这种效应——区块中的第一个交易的交易费率最高，往交易列表的后面看，会发现交易的费率越来越低。不幸的是，这种模式消除了区块内交易的时间顺序属性，而这是比特币系统中一个重要的功能。
解决方案
就像我们在比特币上面临的大多数问题和困境一样，解决这个问题的方法就是让比特币回到本来的样子。这说起来简单做起来难，因为开发人员已经在代码库上花了12年的时间了。
2020年Bitocin SV的几次升级软件中包含了一些为了解决这个问题而做的准备工作，并且已被证明可以稳定运行。v1.0.6软件里的技术变更最为重要，我们用新的日志区块汇编程序（JBA）替换了默认的旧版区块汇编程序（LBA）模块，因此现在的交易判定回归到以下这种简单的模式：
- 交易是有效的吗？答：是的
- 这个交易支付了高于我们最低要求的费率了吗？答：是的
- 可以将这个交易添加到交易列表中
你可以看到，当区块大小被假定为无上限的时候，就没有必要担心一个交易的交易费相对于其他交易来说是高是低；只要这个交易的费率高于你设定的最低值，你就可以选择它们。这使得构建区块变得出人意料的简单，但也对比特币费率市场的运作模式产生了深远的影响——从用户竞价抬高手续费转化为矿工（矿池）之间相互竞争、提供更低的收费标准从而鼓励大量交易。
因为我们上面提到的费用选择（fee selection）逻辑与LBA紧密交织在一起，这意味着我们不可能在不破除LBA的情况下移除这个逻辑，因此明智的做法就是完全取消LBA。为了做到这一点，我们需要确保替换了LBA的JBA是完全稳定的。此外，此前的交易费逻辑不仅涉及区块汇编程序，它还涉及到Bitcoin SV中几乎所有的领域，甚至会深入到非常敏感的代码中，这其中一些代码还将影响JBA的性能。
因此，我们在Dynastic版本中实现的最后一步就是移除了LBA，删除了费用选择代码，并大大简化了交易选择逻辑。
无需多说大家也知道，这次的改动巨大，因此需要大量的测试。去年为了Genesis升级，我们的QA团队在工作中度过了圣诞假期。但今年我强制他们要在圣诞节期间休息一段时间（如果不强制休假他们可能还会继续工作下去，他们就是如此敬业）。因此，我们将在一月初对v1.0.7测试版进行测试。
我真的很喜欢这个图表，所以我想任性地再展示一次。因为它不仅证明了我们解决了这个难题，还彰显出了当我们要解决比特币中所有扩容挑战时必须遵循的结构原则：
- 不要做不必要的工作；
- 如果你认为你需要做这个事，那就进行冷酷的自我拷问；
- 保证图中的线足够徒峭。
相比Bitcoin SV节点软件，我们此次处理的难题在Teranode中更容易被解决，因为我们不必担心在切除垃圾代码的手术中可能产生的连带破坏风险。在Teranode里我们只要简单的遵循中本聪原始设计原则就可以了，这也是中本聪在alpha版本代码中就已经能做到的。
无论如何，应用开发团队可以利用未来的几周时间思考如何利用好更长的链式交易。就像我们在Genesis创世纪升级之后看到的脚本实践大爆炸一样，我期待着看到应用长链交易的创新浪潮。
转载：https://blog.csdn.net/BitcoinSV/article/details/112493400