Bitsocket 2.0展示了比特币SV是如何成长的

匿名开发者unwriter发布了Bitsocket 2.0版本，这是一年多前发布的服务器端事件工具的专业版本。原来的Bitsocket是在BCH和现在的比特币SV（BSV）拥有频密的、少于1兆字节的区块和低交易量（不需要专业级软件）的时候建造的。

业间的开发人员已经认知到这一点，并且一直犹豫是否在他们自己的应用程序中利用这些工具。

https://twitter.com/libitx/status/1217179071647535104?s=20

然而，在过去几个月中，比特币SV开始出现数兆字节的区块和激增的交易量，因此对网络规模的工具需求已经呼之欲出。

[caption id="attachment_248491" align="aligncenter" width="624"] 资料来源：Blockchair[/caption]

科技企业家凯文·艾尔（Calvin Ayre）对公有链进行扩容的必要性有着强烈的言辞态度，以取得任何企业客户认真对待，因此对开发工具的匹配需求是不可忽视的。

https://twitter.com/CalvinAyre/status/1203814025873829888

问题所在

正如unwriter指出，旧有的Bitsocket的问题是，如果交易量过高；服务可能会下降，进而导致用户的交易类型广播到网络时，用户不会获得通知。

[caption id="attachment_248495" align="aligncenter" width="624"] 资料来源：Medium[/caption]

零售中断场景

在企业利用此工具的情况下，此问题是无法接受的。在零售中，常见的情况是销售点（POS）终端脱机或商店因任何原因失去与互联网的连接。

零售商是否只好提前收拾行李，提早关门？

他们就这样停止接受交易，把他们的客户踢出去吗？

不！

大多数现代POS系统具有在离线时继续接受信用卡交易的功能。重新建立连接后，系统将对这些已记录的事务进行批量处理，并将其发送到信用卡处理器。

发票集成场景

企业的另一种常见集成场景是，当需要从某个第三方供应商导入发票时。大多数公司出于各种原因都希望尽快支付发票，例如与贸易伙伴建立诚信关系、为了月末结算而整理财务报表或在卸货情况中（第三方供应商装运货物），以便能尽快向客户开具发票。

任何中断此过程的系统停运都会导致各个范畴的成本增加，无论是用于发票、技术故障排除、支持或两者内部资源所需时间的增加。

此集成的技术解决方案通常涉及定期从某些终结点下载发票（如每15分钟一次），同时保留最后一个记录标识符，以便系统知道不会处理同一发票两次。

这样做的好处不仅确保不会遗漏发票，还提高了代码的性能，因此不必对以前下载的发票执行任何检查。集成只需要下载大于存储以前的值的发票。

例如，在上午10:00，公司的企业资源计划系统从API终结点下载发票#1-4。

值4将存储为下载的最后一张发票。

在上午10:15，发票5-8添加到队列中。

企业资源计划系统中的批量处理作业在下一个上午10:15运行，并检查下载的最后一个发票编号为4，因此它会向API 终结点进行查询，以便仅下载编号大于4的发票。

批量处理作业仅下载发票5-8。

事实证明，unwriter在Bitsocket 2.0中实现了这种确切的解决方案类型，企业通常为集成方案实现这种解决方案。

时间戳服务器

如果企业使用Bitsocket 2.0从区块链下载交易（如上所述），则将置入此类演算法；不需要在其记录系统中重新实施，从而降低开发成本。

当然，这种类型的解决方案只能在单一、全球时间戳服务器（Bitcoin SV）实现。

[caption id="attachment_248498" align="aligncenter" width="570"] 资料来源：比特币白皮书[/caption]

作为一名技术顾问，他已经为客户多次实施这一类型的解决方案，我可以断定，这是比特币SV开发转向成熟的一个很好的例子。

随着2月4日“创世”升级的临近，这样的增长时机再好不过了。