Holochain Vs 哈希图

栏目: 数据库 · 发布时间: 5年前

前言:Holochain和哈希图都是分布式账本技术,它们跟区块链不同。这两种新的技术路径能否解决区块链的扩展性问题?本文作者Arthur Brock是Holochain的创始人,他提出为什么人们要对所有事情都达成共识?从更深的底层来说,我们到底是需要一种“现实”,还是多种“现实”?从蓝狐笔记的角度,有的情境只能是一种“现实”,比如加密货币,如果有多种现实,麻烦就大了。有的情境,可以有多种“现实”。不是所有东西都需要达成共识,但这也意味着区块链的价值属性的可能缺失。“多现实”的场景更多是基于产品或服务的实际交换,无法凭空创造,有它有意思的地方。现在实际的运行会怎么样?还不好说,让我们用三五年的时间来看看吧,会越来越有意思。更有可能的情况是,各自都有自己的优势场景。本文来源于medium,由“蓝狐笔记”公众号的“Leo”翻译。

......分布式计算何时需要达成共识?

对于PoW随机抽签来说,“共识”是否是一个合理的用词?

有很多平台试图让区块链更具有扩展性,或创造区块链架构的替代方案,以实现区块链的愿景,但迄今为止区块链没能够实现。

哈希图(hashgraph)已经获得一些关注,很多人对它所承诺的速度以及他们分享的一些视频演示感到兴奋。这是最接近于holochain的创新之一,可以看到人们对区块链的固有想法。但是,从我个人具有完全偏见的角度,仍然有一些差距。

数据和代理中心主义的混合

请注意,所有哈希图(hashgraph)的示例都显示了代理(标记为A B C D E)以及谁在提交、发送以及接受哪些交易。通常来说,在区块链的解释中,它们只关注区块的链以及一些矿工或权益者所需的随机数(nonces)信息,但数据从来没有呈现显示每个节点实际上如何以不同的顺序接收交易。当区块链把一个节点的序列作为现实同时抛弃其他节点的序列时,这可能会让人对“共识”一词的使用产生怀疑。(蓝狐笔记译注:意思是说区块链只取最长链,抛弃分叉区块。)

然而,在哈希图中,你可以看到不同的代理都在构建不同的“现实”。然后,他们使用与每个代理状态相关的一些元数据,使得他们能够构建基于八卦协议的共识。他们的算法从每个代理的角度看待事情,然后他们有些随意地说:“跨代理的数据元素的中位数时间戳应该作为它的官方时间。”

从数据为中心的区块链转向代理为中心的holochain,它们是混合的。

哈希图的创建者们从以数据为中心向代理为中心进行了部分的思维转向。你可以在holochain上看到,一个app能够如何使用八卦相关的外露数据和DHT时间戳来进行它的哈希图共识变体(除了提防他们的专利)。

对共识的执迷

如果你听区块链的人们谈论分布式计算,几乎都是关于共识。事实上,哈希图的人们甚至声称BFT是关于共识的(而不是容忍拜占庭故障的能力——来自恶意节点的行为)。为什么会对共识如此执迷?

为什么你只需要一个算法为平台上的所有DApp实现共识?不是在有些情况下共识并无必要吗?或者围绕分歧参与不同的社会过程是有价值的?事实上,在某些情况下不同时机相关的信息是有价值的数据,为什么要把人们限制在一个现实中?

在Holochain中,当数据元素使得其数据元素所在的DHT邻居大部分饱和时,你会有隐含或软的共识。后续尝试把该数据放入到DHT中会产生冲突。但是,如果发生了冲突也OK,只要说“好吧,两个人现在已经发明了微积分。”或者其他什么。现在,你有两个作者,有不同的时间戳和历史,那又怎么样?

当数据是竞争资源时(如Twitter句柄、域名或加密币),那么“那又怎样”就会发挥作用。在这种情况下,你想用不同方式应付冲突,并阻止后来的添加,告诉他们名字已经有人用了或者代币已经被花费了。对于分布式app的一般计算来说,这涵盖了99.9%的用例。而在Holochain,我们建议的则是使用以代理为中心的加密记账而不是以数据为中心的代币,这意味着你不必使用竞争的代币。(蓝狐笔记译注:也就是不用担心双花。)

因此,DHT软共识唯一没有解决的剩余情况是,在DHT邻居被一位作者的条目饱和之前可能会发生冲突。因此,如果两个人同时尝试注册相同的名字,你如何解决它?

多共识之路

我们可以假设只有一个绝对的答案,正如哈希图算法使用八卦签名的中位数时间戳那样。或者我们可以认识到选择的重要性,并让app构建者来做决定。

也许你可以开始拍卖,由价高者得。

也许你可以观察社区贡献方面的声誉,并让最大的贡献者得到。

也许你给每人发一条信息,让彼此来解决冲突。

也许你用投票来决定。

问题在于,对于大多数分布式计算app来说,在很短的时间内你可能会遇到这种冲突。为什么你要为所有其他非冲突的数据承担这笔计算的开销呢?为什么通过仅用一种任意方式硬编码来排除符合情境的共识解决方案的可能性?

如果在分布式app中99.9%的数据是非竞争性的,或非冲突的,我们不应该就这0.1%的数据案例发起特别共识解决方案,且承担只有这些案例的计算或社会成本?

然而,由于区块链随着它的ONE APP管理竞争性代币(不可双花的代币)而成长起来,因此所有人都认为共识是分布式计算问题的核心。也许这也是为什么区块链为DApp执行通用计算而无法扩展的原因。如果区块链甚至不能扩展其代币的交易,这只能算是一种非常简单的app(基本上是:你有钥匙吗?好吧,那么你可以编写新代币,达到旧代币的总价值。重复。),那么,他们怎么能期望在上面运行互联网,比如类似于facebook每秒52万个赞这样的规模?

我的答案是:Holochain——用于轻量级、可扩展的P2P dApp,随着更多用户加入,它实际上还变得更有效率。

延伸阅读

Holochain(HOT):它能让区块链过时吗?

Holochain:重塑APP

简单理解Holochain

哈希图:它会优于区块链吗?

------

风险警示:蓝狐笔记所有文章都不构成投资推荐,投资有风险,投资应该考虑个人风险承受能力,建议对项目进行深入考察,慎重做好自己的投资决策。


以上所述就是小编给大家介绍的《Holochain Vs 哈希图》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

JavaScript设计模式

JavaScript设计模式

Ross Harmes、Dustin Diaz / 谢廷晟 / 人民邮电出版社 / 2008 / 45.00元

本书共有两部分。第一部分给出了实现具体设计模式所需要的面向对象特性的基础知识,主要包括接口、封装和信息隐藏、继承、单体模式等内容。第二部分则专注于各种具体的设计模式及其在JavaScript语言中的应用,主要介绍了工厂模式、桥接模式、组合模式、门面模式等几种常见的模式。为了让每一章中的示例都尽可能地贴近实际应用,书中同时列举了一些JavaScript 程序员最常见的任务,然后运用设计模式使其解决方......一起来看看 《JavaScript设计模式》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

MD5 加密
MD5 加密

MD5 加密工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具