Bitbus发布新版,提供BSV上高效的索引服务

Unwriter发布了BSV高效索引服务Bitbus的2.0版。该版本的主要变化在于弃用了较老的Planaria API,因为交易量的增加暴露了其设计缺陷。Bitbus努力成为一个许多服务可以与之交互的单一终端,而不是每个应用程序运行其自己的变形虫节点,并从另一个“全节点”服务器筛选交易记录。

 

图片来源: Bitbus

Bitbus使用什么来扩容?

由于筛选过程是在服务端完成的,Bitbus现在可以更高效地扩容了。客户端通过发送包含Bitquery命令的HTTP请求,来指定所需的数据和数据格式。

由于Bitbus存有账本的索引副本,他们可以快速提取交易记录并将其返回到客户端。与Planaria不同,Bitbus的用户不需要下载任何在客户端运行的JavaScript软件——他们只需从现有的应用程序发出HTTP请求即可与BSV账本进行数据交互。

此外,这种精心设计的架构支持任何平台。用任何编程语言编写的任何应用程序(不仅仅是JavaScript!)都可以立即使用Bitbus,因为他们只需向服务器发出API请求。

区块头状态访问点

Bitbus提供一个“状态”访问点,该访问点提供一个JSON对象,表示有关最近一个区块头的详细信息。这是一个不错的补充,因为用户可以订阅此访问点并收到下一个区块的通知,并随之获悉Bitbus何时通过该区块的数据来更新。

Source: Bitbus

我特别喜欢这个功能,因为我相信在应用程序中可以利用最新的区块信息来做一些有趣的事情,而这个API访问点使得这一点变得非常简单。在下面的视频链接中,我在CoinGeek多伦多大会的演讲中讲解Unwriter开发的工具时谈到了这些:

图片来源: YouTube

Bitbus + Bitsocket

上述细节很重要,因为Bitbus不存储未确认的交易记录,那么我们就有必要用Bitsocket来获取未确认的记录。Unwriter已经有文档告诉我们如何实现——应用程序将对已确认的交易进行初始查询,然后进入“侦听模式”以获取新的交易记录。

如果应用程序在启动时仅执行一次Bitbus查询,然后在其接下来的运行时间使用Bitsocket,就能实际上缓解Bitbus的压力。

如何减轻扩容后带来的负担

为了解决潜在的性能问题,Bitbus不会将大数据块存储到与交易格式相同的数据库中。相反,它们存储在文件系统中,并由Bitbus引用。因此,应用将需要对不同的访问点进行多个查询,以便获取大于512字节的数据。应用将接收到一个对该数据的引用,然后在BitFS(比特币文件系统)中查询这些数据。

虽然这对客户端来说有点不方便,但这确实有助于Bitbus保持其在线运行时间和响应能力,因为它不必提供大块的数据。

Bitbus要求客户端在https://token.planaria.network/注册API令牌。用户可以在控制面板查看其令牌使用情况,并分别指示“花费的流量”和“花费的时间”,分别对应数据消耗和查询时长。

图片来源: Planaria Token

这虽然是个猜测,但也许这是Planaria公司的第一个潜在的收入来源——利用BSV的微支付能力,并根据Bitbus的实际使用情况向客户收费。

Bitbus可以扩容到TB级别的区块吗?

尽管随着BSV网络的发展,Bitbus在扩容方面做出了不少的努力,但我们仍然不能确定Bitbus是否有能力达到TB级别。Bitbus必须从矿工处获取数据,并需要矿工有更强大的基础设施来处理这项工作。

这说明,由于交易量低和区块奖励(即将减半),矿工在提供这类服务方面一直相当懒惰和被动。无论该软件是由Planaria公司还是矿工运行,它在短期内都非常有用。

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

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