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

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

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

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

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

资料来源:Blockchair

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

问题所在

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

资料来源:Medium

零售中断场景

在企业利用此工具的情况下,此问题是无法接受的。在零售中,常见的情况是销售点(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)实现。

资料来源:比特币白皮书

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

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

202024日的“创世”协议升级是比特币历史上的一大里程碑,将见证BSV最大程度地回归到中本聪原先设想的协议。请访问“创世”硬分叉页面以了解更多信息。

要直接在您的收件箱接获CoinGeek.com最新消息,CoinGeek会议特别优惠以及其他内部信息,请加入我们的邮件列表