原文网址：https://bitcoinsv.io/2020/05/15/comments-on-may-12-2020-user-stress-test-of-bitcoin-sv-network/
作者：Bitcoin SV节点团队
背景
从5月12日起，一些用户在Bitcoin SV网络上发起了一个公开的压力测试，并且表示此压力测试将维持一周。在公开压力测试的首日，有大约200万笔低费率交易被广播至Bitcoin SV网络。这些交易中大多数交易的费率都在刚好在0.25聪/字节以上，即超过了转发费率（relay fee）的默认值，这意味着这些交易可以在网络中进行顺利地传播；但是却低于交易接受费率（transaction acceptance fee），或可称为挖矿费率（mining fee）的0.5聪/字节，意味着绝大多数矿工将不会打包这些交易。这导致了交易在交易内存池不断积压，占用了高达1.7GB的内存。在此请注意，Bitcoin SV节点软件的默认内存池上限为1GB，但是许多矿池已经将他们的内存池上限大幅调高了。
这次交易内存池的交易积压事件刚好发生于BTC区块奖励减半后的第一天，减半后有许多BTC矿工转移至了BSV，使得此前的BSV矿工的算力占比被稀释。我们推断出这一点是因为很明显，在5月11日后，BSV网络上出现了许多1MB的区块，说明这些从BTC转移过来的矿工依然使用着BTC挖矿的参数设置。在此情况下，一个我们先前知道的执行0.25聪/字节的交易接受费率的矿池——Mempool由于算力占比下降，在5月11日之后的日子只挖出了不到1%的区块，因此无法凭他们一己之力处理完所有积压的交易。最后，5月12日内存池积压的交易由TAAL清空，并挖出了一个309MB的大型区块，创造了新的世界记录。
网络影响
Bitcoin SV节点团队在主网上运行了许多bitcoind程序实例来监控网络状态。我们在比特币全节点（bitcoin daemons）和许多矿工身上看到的情况十分令人鼓舞。在整个交易积压事件过程中，Bitcoin SV节点软件始终在操作范围内运行性能良好。一些内存池默认为1GB的程序实例没有保留所有的交易，他们也无需这样做，但是可以看到他们在触及1GB上限的时候并没有降速。我们对这一现象并不意外，因为此次事件中出现的交易负载量比BSV扩容测试网（STN）上的每日负载低很多。
究意发生了什么？——转发费率 VS 交易接受费率
我们必须要了解比特币节点软件中两种不同的可设置费率：
- 转发费率（relay fee）：此费率决定了一个矿工是否接受这个交易进入内存池并向其他矿工广播此交易。在Bitcoin SV节点软件中，转发费率默认设置为25聪/字节。
- 交易接受费率/挖矿费率（transaction acceptance (mining) fee）：此费率决定了矿池是否接受这个交易并将其打包进入自己正在挖矿的区块中，交易接受费率默认设置为5聪/字节。
因此，0.25聪/字节的转发费率低于0.5聪/字节的交易接受费率。在2019年年底之前，这两种不同费率的默认值都为1聪/字节，因此它们之间的功能差异还没有显现出来。此外，只要你的交易在发出时没有被拒绝，那么它就会被迅速地打包进入区块。这与BTC网络上的交易体验相比有了很大的提升，但依然还有一个显著的缺点，那就是它没有给矿工们留下费率竞争的空间。
设想一下，如果大多数矿工将转发费率和交易接受费率都设置为1聪/字节，这时有一个矿工愿意提供一个更低的费率——0.8聪/字节，矿工当然可以这样做，但是作为想利用这个低费率的比特币用户，你必须要注意以下两点：
- 由于其他矿工将会忽略这类低费率的交易，他们将无法检测出之后的双花交易，因此你将失去双花保护；
- 由于你的交易将不会被其他矿工转发（因为8聪/字节的转发费率低于其他矿工设置的1聪/字节的转发费率），所以如果要让愿意接受低费率的矿工得到此交易，你就必须得找到这个矿工的节点，并且使用比特币的点对点协议直接把交易发送至这个节点。
上述的第二个问题可以用Miner ID和Merchant API解决，Miner ID可以帮助用户找到矿工API端点，而Merchant API可以为用户探测费率并且将交易发送给接受折扣费率的矿工。上述的第一个问题更值得关注，因为如果我们的出发点将使这种本来具有竞争力的费率下调由于迅速失去效用而失去其竞争力，这会在一开始就形成阻碍竞争的屏障。我们在BCH上就看到了这样的恶果，BCH的费率在过去的两年多里依然一直停滞不前。
将这两种费率区别开并且在它们中间设定一个差额，我们就可以让费率竞争成为可能。与此同时，任何矿工都可以把交易接受费率调至与转发费率一样低，这时交易依然会被完全传播；矿工也可以随时调低转发费率以便抢占市场，但是他们必须知晓这些交易只能由自己打包，而且必须要有一个能够从内存池清空低费率交易的计划，比如打包这些交易进入区块。
但是，如果没有任何一个矿工打包这些低费率交易，将会出现什么情况？会不会这些交易堆积如山直至节点内存不足？
不会的！因为Bitcoin SV节点软件能够优雅地处理这种情况：当交易内存池触及配置的内存上限时，软件将逐出低费率交易，给新的交易腾出空间。这不会使矿工付出多余成本，因此他们可以一直维持这种状态，同时仍然能够接受符合他们费率要求的所有交易。这与BTC上交易拥堵时的情况截然不同，尤其是以下这一关键点：BSV并不会推动交易手续费上升，而是由矿工去设置费率的下限。在真正的比特币世界里，竞争将驱动价格下降，而不是让交易内存池拥堵，而且用户应该始终有把握用已知的费率发出一笔可被网络接受的交易。这可能会创造一个费率市场，鼓励低费率的交易通过CPFP（Child Pays for Parent）来提升他们的交易手续费，但是费率的提升有一个已知上限，这与BTC上的费率市场是具有本质差异的，
内存池具有内存上限值仅仅是因为最好不存在回退选择，但这并不意味着这个上限会被触及。内存上限被触及将是极其罕见的情况，原因如下：
- 矿工通常会有很大的内存池，目前大多数矿工都将内存池设置为至少8GB，并且在必要的情况下，他们也能相对轻易地实时提升内存容量。
- 如果你是一个交易发送者，你肯定希望能使用如Merchant API这类矿工服务来确定你发出的交易需要支付多少费用，不然你可能会面临交易卡在交易内存池数天或者数星期的风险，这时你只能使用CPFP支付来把交易费推高超过费率最低标准，除此之外，你对这笔资产将无能为力。一旦“费率发现”的操作普及起来或者可以被自动执行，我们应该就不会再看到此类交易在内存池压积的现象了。届时，低费率的交易一定是用户人为操作试图进行市场测试或用户不在意交易确认时长才会出现，而不是系统错误导致的。
- 内存池默认对一笔交易最长的保留时间为2周（14天），因此内存池不会持续被交易填满。
- 在交易内存池过满的情况下，总会出现某个矿工愿意将内存池里的交易清空，就如同TAAL在5月12日挖出创纪录的309MB区块那样。
- 矿工们永远可以强硬地提高转发费率或拒绝所有低于他们挖矿费率的交易。虽然我们认为矿工并不愿意这样做，但是如果矿工认为有人在试图用大量交易填满他们的内存池以逼他们降低费率，他们就极有可能反其道而行之，通过提高费率来向攻击者示范打包哪些交易完全是矿工的自由。
我们需要知道矿工留存这些交易并不是太大的负担，这并不会导致CPU开销过大，交易仅仅是在内存池里静静地等着而已。只要矿工们有充足的内存（现在大多数矿工都可以做到这一点），他们就可以根据需要将交易长期留存在内存池里。尽管如此，Bitcoin SV节点团队依然有计划对软件进行改进，使矿工在此类场景下有更多的选择。未来，首个选择就是让矿工可以将交易转移至硬盘，而非留在内存中，这将使交易可以依照矿工的意愿保留更长时间。其次在矿工的低费率交易逐出政策上，对于那些未达到自己挖矿费率门槛的交易，矿工可以选择在将其逐出内存池之前保留一小段时间，比如一天。
这一次，为什么矿工要干预？
鉴于Bitcoin SV节点软件终归可以妥善地处理各类事务，你可能会提出疑问：为什么这次矿工不干脆放任内存池积压呢？Mempool应该可以最终将这些交易打包的，因为他们执行着0.25聪/字节的挖矿费率。然而，此次矿工进行干预是因为一些BSV应用服务开始报错，于是TAAL决定将内存池清空。另外，BTC减半使很多BTC矿工开始关注BSV，这时也是一个矿工展示自身实力的好时机。
此外，矿工们也认识到逐渐将转发费率和交易接受费率区分开，并且调整户用行为，将会不可避免地带来“成长之痛”。在比特币用户（尤其是交易量大的用户）能够适应符合中本聪愿景的网络交互模式之前，必然还会发生一些小插曲，而矿工们则不希望比特币网络服务会遭受不必要的中断。随着BSV生态系统进一步专业化，我们期待矿工们都能够依据以下原则更强硬地表明立场：“如果你维护着一个内存池，那么你需要确保自己能够处理好它。虽然我能够做到，但是我没有义务照顾你的内存池。”
