本文回顾开发人员unwriter在2019年下半年发布的更多应用程序相关工具。
Bitbus
[caption id="attachment_236703" align="aligncenter" width="320"] 资料来源:https://bitbus.network/[/caption]Bitbus 基于您定义的Bitquery在文件系统中创建一个筛选的比特币交易子分类账。Bitbus消除了运行“非挖矿节点”的需要。
Bitbus 是一个更紧密的Bitsocket,让您可以监管您的文件系统,并从那里触发事件,而不是侦听他人的节点。Bitsocket只会触发一次,通过使用Bitbus,您拥有所有发生的事件的本地审计线索。
用例
构建任何需要不同类型和子集的比特币交易的应用程序——如果您需要筛选WeatherSV交易和某些B:\\文件,则可以运行两个Bitbus实例,将文件放在分开的子目录中,然后从一个应用程序查询这些信息。这比运行一个节点来获取整个区块链或在其他地方进行恒定的应用程序编程接口(API)调用来获取数据更有意思。
Eventchain
[caption id="attachment_236706" align="aligncenter" width="360"] 资料来源:https://e.planaria.network/#/[/caption]Eventchain派生自Bitbus,它将交易追加到文件中,就像事件日志一样。您可以定义交易中的查询和格式,交易将作为新的一行被添加进来。然后可以使用外部应用程序与简单文件进行交互。这对于通过其他编程语言与比特币交互非常有用,因为所有语言都可以处理文件读取/写入。
用例
我们可以通过在比特币上使用Eventchain来取代FTP,例如,我们只能筛选某些B:\\协议文件,然后在子目录中创建它们。我们现在在比特币区块链上用的是FTP。由于区块链就是一个档案,因此无需存档。如果我们添加加密,我们无需特意设置账户,即可拥有与SFTP相同的功能。
Su - 简单的身份验证协议
[caption id="attachment_236709" align="aligncenter" width="358"] 资料来源:https://su.planaria.network/[/caption]Su是个Bitcom协议,可用来验证用户在比特币上的操作。需要的三个字段为:
- 公钥
- 要检查的数据的签名位置
- 签名
对数据的签名方式进行了假设,因此这些假设不是为了保持协议的精简而实行(少即是多)。
要解释交易,可在签名位置查看OP_RETURN中的推送数据,并验证签名是否与公钥匹配。如果此数据与某些用户有关联,我们可以验证他们是否已广播并对其进行签名,因此我们可以将其显示在应用程序中。
用例
利用Su作为筛选机制,防止应用程序中的身份伪造。2019年秋天,推特的首席执行官杰克被黑客攻击。通过使用像Su这样的项目,我们不需要用户登录到应用程序来发布内容。用户可以用任何方法写入区块链,然后我们的应用程序利用比特币的加密功能,判断它是否有效显示。
(老实说,推特的首席执行官被黑客攻击并发表仇恨言论是个笑话,这全都因为互联网的网状网络拓扑学所造成的)
Bitkey
[caption id="attachment_236712" align="aligncenter" width="624"] 资料来源:https://bitkey.network/[/caption]Bitkey是比特币上的用户数据库。每个记录在paymail和公钥之间建立链接。我们只需使用paymail查询区块链,并派生一个用户的公钥来进行支付。鉴于此格式的数据库编写机制利用了签名,我们可以合理地确信paymail所有者与其用户绑定。
我注意到的一个问题是,钱包提供商没有在 HTTP 中实现相同的API路由来查询公钥的paymail。在我看来,这是荒谬的,因为它使开发更加复杂,如果他们想支持来自不同钱包提供商的paymail,那么他们必须跟踪他们的应用程序中不同的URL和路径。
用例
通过针对 Bitkey 数据库进行查询,将文件加密到不同用户的公钥。比起在上面提到的许多不同的服务器调用,我可以一致地查询一个中心位置,从而减少应用程序中的代码、复杂性和风险。
Overpool
[caption id="attachment_236715" align="aligncenter" width="254"] 资料来源:https://overpool.network/#/[/caption]Overpool是一个链外比特币交易账本。该软件允许接受已签名或未签名的交易(类似于Bitpipe)。比特币交易格式中的数据可以在广播之前在各方之间传递。间歇本地子分类账得以维护,然后应用程序可以以批量形式广播交易事务,而不用实时广播。
主要好处是为应用程序提供简化的功能,以在彼此之间发送具延展性但未能广播的比特币交易。
用例
老实说,当它刚发布时,我在建造合法的用例时纠结了许久。在反复研究unwriter推出的最新的工具后,我现在总算对如何使用这个工具有了一些概念。
在多人游戏中,您可以在本地子账本中记录不同玩家的所有操作,然后一旦只剩下一名玩家未到下(从而获胜),获胜者就可以广播结果与子账本上所做的任何潜在求和计算(以记录比赛的统计数据和细节),而不是将每个动作记录在链上。
总结
我希望这些文章帮助到那些希望了解unwriter在今年发布的工具,并且有机会在他们的应用程序开发中发挥一些作用。同时,我希望这有助于非技术人员尽可能掌握正在发生的事情,而不是每次他[unwriter]公布一个“神秘”工具时盲目庆祝。
请在评论或Twetch发表您的想法!
什么是您想要进一步了解的?
还有什么需要阐明?
欢迎提出任何反馈!