精华内容
下载资源
问答
  • 当产品同学提出需求的时候,研发同学做了好的回应,但实际上双方想的内容并不一致,这种情况我们称之为表面一致;当产品上线后,产品同学提出需求疑问时,研发同学的回答充满了各种技术行话:定时系统,原子性等。...

    简介: 在考虑如何对业务模型进行抽象从而建立领域模型之前,必须解决业务与产品、开发之间“沟通”的问题。如何让业务人员和开发人员顺畅沟通,在业务流程设计中不遗漏成败攸关的业务场景?如何才能让业务沟通的过程顺畅过渡到架构设计、编码乃至测试?阿里巴巴技术专家李建结合团队的实际案例,分享了他们在使用 Event Storming(事件风暴) 进行领域建模时的经验、收获和思考。

    image.png

    一 软件研发的困境

    “失效”的语言交流

    日常研发过程中不同角色经常需要进行各种交流:沟通业务需求、讨论产品原型、讨论设计方案等。每个环节不同角色反复沟通,这是研发过程非常重要的环节。但问题是:我们花费大量时间沟通,真的“说” 清楚了吗?

    让我们看两个例子:

    image.png

    上面的两段对话发生在一次项目 Review 的过程中。通过第一个对话,我们能看出不同的角色在沟通的时候遇到了障碍;通过第二个对话说明即便是相同的角色,沟通在某种程度也遇到了障碍。

    软件研发的困境

    无论传统的瀑布流程还是敏捷模式,软件研发总体上能划分成几个阶段:提出需求,产品设计,研发,测试,最后上线。不同阶段会产出不同交付物,有些比较简单,也有些比较详尽:MRD,PRD,技术方案,验收方案等。在整个过程中,我们还会组织不同会议,或者是线下讨论。

    image.png

    大家想一想,在哪一个阶段暴露了最多的问题?

    不管我们多么期望在早期发现问题,然而现实是越到研发晚期越会暴露更多问题。当产品进入测试阶段,当上线后真实数据开始跑起来,当业务同学开始使用产品,这时候问题会像泉水一样主动涌现出来,用户会反馈各种问题:“这个不是我想要的功能”,“XX 和我的预期不一样”等等。通常在软件研发的后期发现很多这种类似的问题。软件研发发展到今天,这个问题依然没有被很好的解决。

    阻碍产品正确交付的原因

    我们通过下面一个例子来分析什么原因阻碍了产品的正确交付。

    image.png

    当产品同学提出需求的时候,研发同学做了好的回应,但实际上双方想的内容并不一致,这种情况我们称之为表面一致;当产品上线后,产品同学提出需求疑问时,研发同学的回答充满了各种技术行话:定时系统,原子性等。显然大部分产品同学不能理解这些技术行话,对话进入停滞状态,我们称这种现象为沟通障碍。在软件研发中该问题反复的出现:沟通不畅阻碍了产品价值的正确交付。在不同角色进行交流时,三个原因阻碍了沟通的顺畅进行:

    image.png

    • 得到的信息不同:产品同学和业务同学关注的是业务需求,市场情况,近中远期规划,以及运营数据等;开发同学关注的是一个个具体的需求列表,功能点,是实现层次的细节信息。
    • 思维方式不同:产品同学关注业务/需求的合理性,产品逻辑,用户体验;而开发同学关注方案的可行性,实施成本,系统稳定性等。
    • 沟通语言不同:产品同学用描述性的语言,语言的模糊会导致不同角色理解的不同;而开发同学习惯使用技术语言,SDK、数据库、一致性等。不同角色交流的时候,会因为语言不相容,沟通不到一起去。

    由于以上的原因,沟通容易陷入“鸡同鸭讲”的窘境:讨论很热烈,甚至能取得表面的一致,实际并没有“说”清楚。

    洞察软件研发困境

    Event Storming 方法的发明者 Alberto Brandolini 认为:产品体现了程序员对业务的理解(或误解)。很多时候沟通失败导致的误解进入产品实现。于是真正的业务需求在产品中没有得到体现。沟通失败是软件研发的一个痛点,有待解决。

    image.png

    二 Event Storming

    Event Storming 介绍

    Event Storming(ES):由不同角色共同参与,用彩色贴纸进行交流的工作坊。

    image.png

    如上图,一群同学围绕一个业务场景,用贴纸进行交流,这就是 ES 工作坊。通过贴纸进行交流,让大家用同一种沟通语言,同一个思维方式,让大家的思维在一个频道上,这是 ES 的形式,也是 ES 的目的。

    Event Storming 语法

    ES 定义了一套彩色贴纸的“语法”:不同颜色的贴纸都有定义。浅黄色代表 Actor (角色)、蓝色表示 Command (命令)、粉色代表 Policy (业务规则)、浅粉色代表System(系统)、橙色代表 Event (事件),浅绿色表示 Read Model (读模型)、红色代表 HotSpot (热点/问题)。

    image.png

    用 ES 的语法表达用户的下单流程:买家 (浅黄色贴纸) 提交订单(蓝色贴纸),如果订单里商品是在线状态,购买量小于商品库存量 (粉色贴纸 Policy) ,那么订单创建成功(橙色事件贴纸),已创建的订单 (绿色贴纸) 展示给用户。订单创建后需要通知买家(业务规则,粉色贴纸),系统执行发送站内信(蓝色贴纸)。

    image.png

    二 如何在业务中使用 ES

    下面我们通过一个业务场景(优惠券的投放和使用)介绍如何使用 ES。

    业务背景介绍

    电商网站提供各种优惠券:满减券,折扣券,有无门槛券。

    image.png

    下图描述电商运营小二在活动中投放优惠券的整体流程:小二先创建优惠券,然后再创建一个活动,把优惠券和活动关联起来。活动通过公司财务的审批后才可发布上线。消费者在活动页面领取优惠券,在下单流程使用优惠券抵消金额。最后活动结束时要对整体活动的数据进行统计分析。

    image.png

    准备 Event Storming

    在开始 ES 前,先做好准备:

    image.png

    • 准备物料:彩色贴纸、笔纸、一个足够大的房间等。房间里不要有椅子,因为在 ES 过程中,我们希望大家都全神贯注的投入,而不是坐在椅子上开始放松。
    • 邀请正确的人:有问题的人和有答案的人。程序员、交互设计师、测试等都是有问题的人,需要通过 ES 理解业务和产品;有答案的人通常是用户、业务或产品,他们通常能回答业务的背景,诉求和目标。

    Event Storming 的过程

    ES 可以分为开场介绍、ES 沟通业务和讲故事三个阶段。

    开场介绍

    在 ES 中有一个特殊的角色叫做 Facilitator(推动者),一般是 ES 的组织者。在 ES 开始前,Facilitator 向大家介绍 ES 是什么,有什么好处,以及彩色贴纸的用法。然后介绍讨论的范围和目标。

    比如,今天讨论优惠券场景,目标是理清营销活动过程中优惠券的业务流程。最后 Facilitator 强调 ES 的规则:所有的讨论都写在贴纸上;不允许使用电脑,手机;也不允许坐下。在 ES 的后续过程中,Facilitator 还需要承担另外两个重要职责:保持参与者的专注,通过提问驱动交流。

    image.png

    ES 的方式沟通业务

    第一步先梳理事件(橙色贴纸): 事件是已发生且重要的事情。事件必须是既成事实,且业务关注的事情。通常 Facilitator 会先准备第一个事件(可以是系统中任一事件), 然后把它贴到墙上。

    image.png

    假设第一个事件是:优惠券已领取。接下来 Facilitator 通过提问引导大家找到更多的事件:

    • 事件发生前有哪些事件(“优惠券已领取”前须先有“活动已发布”事件)?
    • 事件发生后下一个事件是什么(“优惠券已领取”后有“优惠券已使用”,“优惠券已过期”等事件)?

    提问会引导参与 ES 的同学将新发现的事件不断补充到墙上。事件要保持整体的时间顺序:先发生的事情贴在左边,后发生的事情在右边。通常大家容易关注系统的正常流程,也就是 Happy path。这时候 Facilitator 需要引导大家关注业务的非正常流程 Unhappy path。边界条件,异常情况通常是业务复杂性的重要原因,也是非常容易被忽视的部分。

    • 事件一定会发生吗(优惠券一定领取成功吗?不是,贴上“优惠券领取失败”事件)?

    追问 unhappy path 梳理出业务的完整视图,当大家发现新事件的速度接近停滞的时候,就应进入梳理业务规则的阶段了。

    Policy,业务逻辑或规则,这是业务中最重要的部分。Facilitator 会提出以下问题:

    • 事件是否一定成功?如果不是,那么成功的前提条件是什么?
    • 该事件是否会导致其他事件的发生(Reaction)?

    例如“活动已提交”事件:

    • 活动提交成功的前提条件:活动已关联有效优惠券,且已选择了生效方式,并且选择了适用人群。
    • 活动提交后,会导致审核任务已创建事件,这里的业务规则是:活动提交或需创建审核任务。

    image.png

    接下来找出三个角色:Actor (和系统交互的人),Command (用户动作) 和 Read Model (辅助用户决策的工具)。Facilitator 提出以下问题:

    • 是什么触发了事件?即事件发生的原因 (ES 的语法:when Event, then Command)。
    • 谁执行了动作。是人,系统,还是时间(例如定时触发的事件)?
    • 做出动作前,用户需要获取哪些信息?

    以上的问题会引导大家找到 Actor, command 和 Read Model。 在营销活动已提交事件中:小二(Actor)执行了提交活动(Command), 从而产生了“活动已提交”事件。

    image.png

    最后介绍 Hotspot:业务痛点、瓶颈、模糊点。Hotspot 是 ES 过程中随时都应该发现并记录下来的。Facilitator 可以引导大家发现业务中未描叙到的问题,例如:用户使用优惠券进行支付的场景中,如果用户支付失败,已使用的优惠券该如何处理呢?优惠券应该返还给用户,还是不做处理?通过提出这样的问题,引导大家对业务流程进行更深入的讨论。通常在 ES 的过程中,识别并记录 Hotspot,不要在 ES 中尝试解决所有的 hotspot。

    image.png

    以上介绍了 ES 的主要元素:Event,Policy,Actor,Command,Read Model,Hotspot。用 ES 描述了优惠券发放的业务流程,最后一步是“讲故事” (storytelling) 的阶段。

    讲故事

    Facilitator 邀请不同的人担任志愿者,每个志愿者讲一段故事:按时间顺序和 ES 描叙的逻辑, 向其他人介绍业务流程。过程中,听众注意到不一致的地方随时提出问题,大家讨论问题,通过增加/删除/移动贴纸来修复问题,并继续讲故事的流程。

    最开始大家会按时间正序讲故事,最后大家还可以倒序讲故事。梳理业务的异常场景,倒序讲故事的方法更有效。例如为什么会发生“优惠券领取失败”事件,事件的原因是 balabala…

    经过讲故事阶段的完善,大家获得了业务的完整理解,这时候可以结束讨论,保存相关材料,遗留下来的 Hotspot 交由相关同学跟进。

    image.png

    Event Storming 常见问题

    ES 比其他方式更能帮助大家顺畅的沟通,但是对于首次参与或组织 ES 的同学也有一些疑问。 以下列出一些常见问题:

    Q:ES 通常邀请多少人参加?我需要邀请所有角色吗?

    A:不一定。ES 鼓励不同角色共同参与,但是参与人的态度更重要,积极主动参与是 ES 成功的关键。通常一个 Pizza (8 - 10人) 的规模,是适合 ES 人数。

    Q:我的业务场景和复杂,在 ES 中要梳理完整个业务流程吗?

    A: 不需要。ES 需要大家高度参与,因此需要控制好时间。每次 ES 的范围选择复杂业务场景的一部分,保证 ES 的效果。

    Q:我应该在什么阶段做 ES?

    A:项目的任何阶段都可以做 ES。ES 既可用于梳理业务现状,也可以用于设计业务的未来方案。

    Event Storming 小结

    下面的四个图直观的解释了 ES 的作用:

    image.png

    • 图 1,说明不同角色通过语言交流,虽然达成表面一致,实际上大家理解不一致。
    • 图 2,ES 要求大家通过贴纸的形式可视化出来脑海中的想法,从而使分歧自动显现。
    • 图 3,ES 通过不断的提问触发讨论,从而能够拉通认知,消除分歧点和模糊点。
    • 图 4,ES 拉通了大家对业务的理解,从而达成了真正的共识。

    总的来说,ES 让不同的角色用同一种语言(彩色贴纸)从全局对业务达成共识。

    四 从 ES 到代码

    简单介绍下 ES 如何顺畅过渡到 DDD(Domain-Driven Design 领域驱动设计)。

    提取业务概念

    DDD 中最重要的是统一语言:交流使用统一语言;模型表达统一语言;代码表达统一语言。语言是由概念组成的,ES 的过程已经将概念写在贴纸上,并且在交流中反复使用。例如:优惠券,营销活动,已领取优惠券,领取方式,人群等。

    一部分概念有生命周期,并且有唯一的标识符。例如:营销活动,优惠券,已领取优惠券。这些就是 DDD 中的实体;还有一部分概念标识一个完整的业务含义,但是没有生命周期,并且属性相同的两个对象可以替换,这些对象就是 DDD 中的值对象,例如:领取方式,生效方式,人群。

    image.png

    提炼模型

    概念和概念之间是有关系的。比如说,优惠券和营销活动有关联关系,已领取优惠券是在某个营销活动下领取的,营销活动也包含很多信息,它的生效方式是什么,领取方式是什么,人群是谁。概念与概念之间的关系也就是领域模型。

    image.png

    从模型到实现

    将 ES 贴纸重新组合:围绕一个核心概念,将与该概念有关的 Event,Command,Policy 组合在一起。例如下图左边围绕营销活动为中心重新组织了贴纸(Command,Policy,Event),这些贴纸和右边的代码映射起来,这也就是 DDD 中说的代码表达统一语言。到此,简单介绍了如何从 ES 到概念,从概念到模型,以及模型和代码实现是怎么关联起来的。

    image.png

    架构,代码和约束

    下图简单描述应用架构,代码结构,以及如何通过 ArchUnit 实现架构约束。

    image.png

    四 总结

    ES 的价值在于:不同角色在具体业务场景下用一种共同语言(彩色贴纸)进行交流,通过不断提问触发探索、讨论,最终达成真正共识。

    阿里巴巴研发效能峰会 | 架构设计与代码智能专场

    6 月 13 日,阿里巴巴研发效能峰会架构设计与代码智能专场将围绕领域驱动设计、代码可测试性、代码智能、代码数据打标等技术,探讨如何从架构设计和机器智能方面让代码更加容易被编写和维护。

    点击”阅读原文“立即参与!

    展开全文
  • ADA共识算法Ouroboros简介

    万次阅读 2018-07-10 15:47:40
    达成一致性效率低以及无利益攻击( Nothing-at-stake attack )的问题, DPOS 采取在拥有权益的有限集合范围内(即 Leader 之间)进行投票达成一致。 验证基于链的 POS 方案尝试从链上现有数据入手,比如使用上一...

    ADA项目简介

    名称

    ADA,中文称为艾达币,是卡尔达诺(Cardano)的代币,Cardano项目发起于2015年,名字的由来是来自16世纪的意大利数学家Gerolamo Cardano。而 ADA 则是以19世纪英国贵族 Ada levea 的名字来命名,她是拜伦的女儿,被称为人类史上的第一位程式员。

    团队

    卡尔达诺的整个团队由卡尔达诺基金会,Input Output HK(简称 IOHK )和 Emrugo 公司三方组成。

    卡尔达诺基金会:负责规范,保护和推广卡尔达诺协议技术;
    Emrugo:负责开发、支援和孕育商业企业,协助将这些业务整合到卡尔达诺的分散区块链生态系统中,类似于公司的市场推广;
    IOHK: 是一家成立于香港的世界级区块链工程公司,负责卡尔达诺项目的技术开发,由 Charles HoskinsonJeremy Wood 两位重量级人物创办。

    目标

    卡尔达诺要实现的是一个非常宏伟的计划。其它公链基本是瞄准目前公链存在的某一个问题去解决,比如:EOSIOTA 追求可扩展性,他们宣称可以达到很高的 TPS(每秒交易数);AE币 和瑞波币致力于可交互问题的解决;达世币和泰达币致力于解决治理性的问题,而卡尔达诺试图解决目前底层公链存在的所有问题。

    卡尔达诺想要解决目前区块链生态面临的三个问题:

    可扩展性(Scalability):通过分层技术及共识机制。
    可交互性(Interoperability):通过侧链来解决币种之间的直接交互。
    可持续发展性(Sustainability):通过链上资助计划,每个区块奖励的一部分会流入国库(treasury)中,国库会对最热门的提议释放资金,来鼓励和资助开发者实现这一改进方案。

    本文主要关注可扩展性。卡尔达诺主要通过分层技术及共识机制来解决可扩展性问题。

    可扩展性实现

    分层

    分层的逻辑是将不同的交易在不同的层级里去完成。卡尔达诺将其架构分成了清算层和计算层:

    清算层(Settlement Layer):卡尔达诺的代币 ADA在该层流动,是卡尔达诺整个系统的基础。可以把清算层理解为升级版的比特币系统。
    计算层(Computation Layer):卡尔达诺将在该层提供智能合约,身份认证,消息通信等等功能,以方便开发者在此开发DAPP。可以把计算层理解为升级版的以太坊系统。

    共识机制

    共识机制类似于区块链生态中的宪法,或者说平台治理的价值观。目前主流的三种共识机制:

    工作量证明(POW): Proof of Work,依赖机器进行数学运算来获取记账权,资源消耗相比其他共识机制高、可监管性弱,同时每次达成共识需要全网共同参与运算,性能效率比较低,容错性方面允许全网50%节点出错。典型代表比特币。
    权益证明(POS): Proof of State,节点记账权的获得难度与节点持有的权益成反比,相对于POW,一定程度减少了数学运算带来的资源消耗,性能也得到了相应的提升,但依然是基于哈希运算竞争获取记账权的方式,可监管性弱。典型代表以太坊。
    权益代理证明(DPOS): Delegated Proof of State,与POS的主要区别在于节点选举若干代理人,由代理人验证和记账。其合规监管、性能、资源消耗和容错性与POS相似。这种机制有些偏于中心化,但极大地提高了共识和出块效率。典型代表EOS

    卡尔达诺采用了一种称之为乌洛波洛斯(Ouroboros)的共识机制,这也是一种POS机制,与通常的理解的权益代理证明(Delegated Proof of Stake)不同,它是动态权益证明(Dynamic Proof of Stake)。

    乌洛波洛斯

    POW是算力竞赛,设计一个计算哈希的难题,谁先算出来谁赢,算力高的赢的概率高,算力低的赢的概率低,以这样的方式保证胜出者是随机的,且易于验证。POS是选举,根据区块链账本中股权者所拥有权益的比例,随机投票选举下一个出块人。POS的选举投票需要在非常多的节点之间达成一致,这对一致性验证、防伪等要求较高。为了解决POS达成一致性效率低以及无利益攻击(Nothing-at-stake attack)的问题,DPOS采取在拥有权益的有限集合范围内(即Leader之间)进行投票达成一致。

    验证基于链的POS方案尝试从链上现有数据入手,比如使用上一个区块的哈希值,上一个区块的时间戳等等来作为随机数的来源,但这些会带来额外的安全风险。因为区块本身的信息就是节点写进去的,然后又要根据这些信息来选取后续的出块者,存在循环论证的嫌疑,安全性不会太好。这也是为什么普遍认为POS方案不如POW可靠的部分原因。

    为了确保区块链的安全性,选取股权者来产生区块的方法必须是真随机的。为了实现领导者选举(Leader election)过程的随机性,IOHK首席科学家Aggelos Kiayias教授领导的团队设计了名为乌洛波洛斯(Ouroboros)的共识机制。乌洛波洛斯是第一个具有科学凭证其安全性的权益证明协议,该协议由系统随机筛选产生记账者,从而不会产生恶意攻击。下面就来详细介绍该机制的运作过程。

    随机数协议

    简单随机数协议(Coin-Tossing

    假设张三李四要玩剪刀石头布,用传统方式作弊者如果稍微出的晚一点,可以等看到对方的手势后再做选择。为了防止这种情况,他们分三步执行一套“分歧终端机”流程:

    先各自做出选择,然后把自己的选择做个哈希,交换这个哈希;
    等双方都收到对方的哈希后,再交换双方的选择;
    验证对方的选择和之前的哈希一致;

    这样双方都知道了对方的选择,也能确认对方的选择是提前就做好的。这个哈希值就叫做承诺(Commitment),因为它里面包含了保密信息,但又没有泄漏保密信息,而最终发送对应的保密信息,就叫做打开承诺(Open)。

    多方随机数协议

    简单随机数协议只是一个两方参与的协议,下面扩展该协议来设计一个生成多方随机数协议:

    每个节点在本地产生一个随机数,并把它的承诺广播给其他人;
    当它收到所有人广播的承诺后,再把打开也广播给其他人;
    最后大家把得到的随机数异或到一起,因为异或操作满足交换律和结合律,所以操作顺序不影响结果;

    最终大家都得到了一个一致的无法被操纵的随机数。但这个协议的问题在于,部分节点可能因为网络掉线或者因为恶意可以选择终止协议不发送自己的打开,会使得其他人无法进行下去。

    可验证秘密共享(Verifiable Secret Sharing

    为了解决多方生成随机数协议中部分节点不可用的问题,乌洛波洛斯引入了可验证秘密共享方案。该方案的规则如下:把一个需要保密的信息,拆分成N份,分别发送给N个人,只要恶意节点不超过一定数量,最终大家可以综合各自的信息片段把原始信息还原出来。并且就算分发者如果作弊,也可以检查出来。

    结合该技术,就有了一个完整的随机数生成协议了。下面综合一下来看整个协议流程:

    提交阶段(Commitment phase):每个节点本地生成随机数和对应的承诺,同时把随机数拆成N份匹配其他的投票节点,并且用相应投票节点的公钥对每一份信息进行加密,保证它只能被对应的节点解密,然后把承诺和加密后的拆分信息一起广播给区块链。
    打开阶段(Reveal phase):当大家收到大部分节点的承诺和拆分信息后,每个节点把自己的打开广播到链上。
    恢复阶段(Recovery phase):每个节点检查是否有节点发送了承诺但没有发送打开,如果有,则解密自己对应的那份拆分信息并发布,然后根据大家发布的拆分信息恢复出该节点的随机数。现在大家就有了所有节点的随机数,把它们异或到一起,最终得到了一个一致的随机数。

    追寻中本聪算法(Follow the Satoshi (FTS)

    有了安全的随机数,就可以以该随机数作为随机源,按照各节点的权益比例选择出下一个出块的Leader,乌洛波洛斯是通过追寻中本聪算法来实现该选择过程的。

             +-----+
    SEED --->| FTS |---> ELECTED_SLOT_LEADERS
             +-----+

    追寻中本聪算法的原理非常简单:将所有的权益组成一棵Merkletree,其形式是非叶子节点的权重为左右子树的权重之和,叶子节点的权重即为某个权益所有者的权益值。然后根据随机数在左右子树中进行选择。
    Merkletree

    下面分别就选择与验证两阶段来介绍:

    选择

    从该Merkletree的根节点开始,以前面生成的随机数作为随机源,使用伪随机数生成器生成一个小于当前树节点权重的随机数,如果该随机数小于左子树的权重则选择左子树继续遍历,否则选择右子树继续遍历,直到选择某一个叶子节点,也即选择了该叶子节点所代表的权益所有者作为下一个出块的Leader

    验证

    由于使用的是伪随机数生成器,因此当不同生成器使用同一个随机数当做随机源来生成随机数序列时,该随机数序列是相同的。因此验证的过程与选择的过程类似,从该Merkletree的根节点开始,以前面生成的随机数作为随机源生成随机数进行节点选择,然后比较选中的树节点的哈希值,相等则验证通过。

    实现

    Cardano的运行中,时间被分为 slot,每个 slot 时长为20秒。每个slot只能产生一个块,若这个块有问题,或者应该产出这个块的“矿工”(也就是stakeholder的候选人)不在线,或者产出的块没有广播给大多数人,那么这个slot是当作废弃的,也就是会跳过这个slot的块。多个slot为一个 epoch,权益的计算是以每个epoch开始前的历史来计算,也就是说在这个epoch中所产生的权益变化不影响当前的这个epoch中的slot的出块者的选择和其他和历史相关的东西。当前epoch中所产生的这些历史只能在以后的epoch中生效。

    把每个epochslot分成10等份,整个epoch被分为了三个阶段:Commitment Phase, Revel Phase, Recovery Phase,分别占比4:4:2,对应可验证秘密共享协议的三个阶段。
    epoch][Imgur

    具体的实现流程如下:
    1. 从链的真正创世块开始,硬编码进入了一些公钥和这些公钥对应的权益S及初始的随机种子ρ,之后,这个epoch会采用这些基础信息继续运行。
    2. 每个节点自己独立运行代码,根据当前epoch的随机种子ρ,执行追寻中本聪算法F,把genesisblock中的权益,随机种子ρslotindex作为输入,根据概率获得当前这个slot应该由谁出块。若发现是自己出块,则执行打包交易等等操作,和bitcoin没有太大区别,但是除了基础工作之外,还会生成一个随机数,但是这个随机数不放到链(块)中,而是放一个承诺Com中。若不是自己出块,则等待出块者出块并广播。收到这个块的时候就进行和bitcoin类似的检查,要是长时间未收到(超出这个slot的时间)则会认为这个slot的块废弃。
    3. 在当前epoch中不断重复2的流程直到这个epoch中的所有slot结束。
    4. 在整个epoch的过程中会产出一个在这个epoch参与出块者们(slot leaders)都共同认同的随机种子ρ
    5. 在自己的内存里记录好这个随机种子ρ及下一个epoch参与的stakeholders,开启下一个epoch周期,进入2的流程。

    引用:

    1. proof-of-stake
    2. follow-the-satoshi
    3. Cardano(ADA)的共识算法Ouroboros
    展开全文
  • 共识算法

    千次阅读 2019-11-07 19:20:00
    [区块链] 共识算法之争(PBFT,Raft,PoW,PoS,DPoS,Ripple) 目录 一.拜占庭容错技术(Byzantine Fault Tolerance,BFT) 二.PBFT:Practical Byzantine Fault Tolerance,实用拜占庭容错算法。 三.Raft...

     [区块链] 共识算法之争(PBFT,Raft,PoW,PoS,DPoS,Ripple)

    目录

     

    正文

      近几天对区块链中几种常见的共识机制(PBFT,Raft,PoW,PoS,DPoS,Ripple)进行了总结。尽量使用简单易懂语言,篇幅较大,想了解的可以只读每个算法介绍中前边的原理。本篇文章主要参考《区块链技术指南》,首先表示感谢! 

      ---Begin---

      区块链架构是一种分布式的架构。其部署模式有公共链、联盟链、私有链三种,对应的是去中心化分布式系统、部分去中心化分布式系统和弱中心分布式系统。

      在分布式系统中,多个主机通过异步通信方式组成网络集群。在这样的一个异步系统中,需要主机之间进行状态复制,以保证每个主机达成一致的状态共识。然而,异步系统中,可能出现无法通信的故障主机,而主机的性能可能下降,网络可能拥塞,这些可能导致错误信息在系统内传播。因此需要在默认不可靠的异步网络中定义容错协议,以确保各主机达成安全可靠的状态共识。

      所谓共识,简单理解就是指大家都达成一致的意思。其实在现实生活中,有很多需要达成共识的场景,比如开会讨论,双方或多方签订一份合作协议等。而在区块链系统中,每个节点必须要做的事情就是让自己的账本跟其他节点的账本保持一致。如果是在传统的软件结构中,这几乎就不是问题,因为有一个中心服务器存在,也就是所谓的主库,其他的从库向主库看齐就行了。在实际生活中,很多事情人们也都是按照这种思路来的,比如企业老板发布一个通知,员工照着做。但是区块链是一个分布式的对等网络结构,在这个结构中没有哪个节点是“老大”,一切都要商量着来。

      所以在区块链系统中,如何让每个节点通过一个规则将各自的数据保持一致是一个很核心的问题,这个问题的解决方案就是制定一套共识算法,实现不同账本节点上的账本数据的一致性和正确性。这就需要借鉴已有的在分布式系统中实现状态共识的算法,确定网络中选择记账节点的机制,以及如何保障账本数据在全网中形成正确、一致的共识。

      共识算法其实就是一个规则,每个节点都按照这个规则去确认各自的数据。我们暂且抛开算法的原理,先来想一想在生活中我们会如何解决这样一个问题:假设一群人开会,这群人中没有一个领导或者说老大,大家各抒己见,那么最后如何统一出一个决定出来呢?实际处理的时候,我们一般会在某一个时间段中选出一个人,那个人负责汇总大家的内容,然后发布完整的意见,其他人投票表决,每个人都有机会来做汇总发表,最后谁的支持者多就以谁的最终意见为准。这种思路其实就算是一种共识算法了。然而在实际过程中,如果人数不多并且数量是确定的,还好处理;如果人数很多且数量也不固定,那就很难通过这种方式投票决定了,效率太低。我们需要通过一种机制筛选出最有代表性的人,在共识算法中就是筛选出具有代表性的节点。

      那如何筛选呢?其实就是设置一组条件,就像筛选尖子生一样,给一组指标让大家来完成,谁能更好地完成指标,谁就能有机会被选上。在区块链系统中,存在着多种这样的筛选方案,比如PBFT(Practical Byzantine Fault Tolerance,实用拜占庭容错算法)、PoW(Proof of Work,工作量证明)、PoS(Proof of Stake,权益证明)、DPoS(Delegate Proof of Stake,委托权益证明)、Ripple(瑞波)等,各种不同的算法,其实就是不同的游戏玩法。

     

     

    一.拜占庭容错技术(Byzantine Fault Tolerance,BFT)

      拜占庭容错技术(Byzantine Fault Tolerance,BFT)是一类分布式计算领域的容错技术。拜占庭假设是对现实世界的模型化,由于硬件错误、网络拥塞或中断以及遭到恶意攻击等原因,计算机和网络可能出现不可预料的行为。拜占庭容错技术被设计用来处理这些异常行为,并满足所要解决的问题的规范要求。

      拜占庭容错技术来源于拜占庭将军问题(猛击!查看该问题)。

      在分布式系统中,特别是在区块链网络环境中,也和拜占庭将军的环境类似,有运行正常的服务器(类似忠诚的拜占庭将军),有故障的服务器,还有破坏者的服务器(类似叛变的拜占庭将军)。共识算法的核心是在正常的节点间形成对网络状态的共识。

      通常,这些发生故障节点被称为拜占庭节点,而正常的节点即为非拜占庭节点

      拜占庭容错系统是一个拥有n台节点的系统,整个系统对于每一个请求,满足以下条件:

      1)所有非拜占庭节点使用相同的输入信息,产生同样的结果;

      2)如果输入的信息正确,那么所有非拜占庭节点必须接收这个信息,并计算相应的结果。

      拜占庭系统普遍采用的假设条件包括:

      1)拜占庭节点的行为可以是任意的,拜占庭节点之间可以共谋;

      2)节点之间的错误是不相关的;

      3)节点之间通过异步网络连接,网络中的消息可能丢失、乱序并延时到达,但大部分协议假设消息在有限的时间里能传达到目的地;

      4)服务器之间传递的信息,第三方可以嗅探到,但是不能篡改、伪造信息的内容和验证信息的完整性。

      原始的拜占庭容错系统由于需要展示其理论上的可行性而缺乏实用性。另外,还需要额外的时钟同步机制支持算法的复杂度也是随节点增加而指数级增加

    二.PBFT:Practical Byzantine Fault Tolerance,实用拜占庭容错算法。

      实用拜占庭容错系统(PBFT)降低了拜占庭协议的运行复杂度,从指数级别降低到多项式级别(Polynomial),使拜占庭协议在分布式系统中应用成为可能。

      PBFT是一种状态机副本复制算法,即服务作为状态机进行建模,状态机在分布式系统的不同节点进行副本复制。每个状态机的副本都保存了服务的状态,同时也实现了服务的操作。将所有的副本组成的集合使用大写字母R表示,使用0到|R|-1的整数表示每一个副本。为了描述方便,通常假设故障节点数为m个,整个服务节点数为|R|=3m+1个,这里m是有可能失效的副本的最大个数。尽管可以存在多于3m+1个副本,但是额外的副本除了降低性能之外不能提高可靠性。

      PBFT要求共同维护一个状态,所有节点采取的行动一致。为此,需要运行三类基本协议,包括一致性协议、检查点协议和视图更换协议。我们主要关注支持系统日常运行的一致性协议。一致性协议至少包含若干个阶段:请求(request)、序号分配(pre-prepare)和响应(reply)。根据协议设计的不同,可能包含相互交互(prepare),序号确认(commit)等阶段。

    PBFT协议通信模式

      上图为PBFT协议通信模式,每一个客户端的请求需要经过5个阶段,通过采用两次两两交互的方式在服务器达成一致之后再执行客户端的请求。由于客户端不能从服务器端获得任何服务器运行状态的信息,PBFT中主节点是否发生错误只能由服务器监测。如果服务器在一段时间内都不能完成客户端的请求,则会触发视图更换协议。其中C为客户端,N0~N3表示服务节点,特别的,N0为主节点,N3为故障节点。整个协议的基本过程如下:

    1)客户端发送请求,激活主节点的服务操作。

    2)当主节点接收请求后,启动三阶段的协议以向各从节点广播请求。

    [2.1]序号分配阶段,主节点给请求赋值一个序列号n,广播序号分配消息和客户端的请求消息m,并将构造PRE-PREPARE消息给各从节点;

    [2.2]交互阶段,从节点接收PRE-PREPARE消息,向其他服务节点广播PREPARE消息;

    [2.3]序号确认阶段,各节点对视图内的请求和次序进行验证后,广播COMMIT消息,执行收到的客户端的请求并给客户端以响应。

    3)客户端等待来自不同节点的响应,若有m+1个响应相同,则该响应即为运算的结果。

     

      PBFT在很多场景都有应用,在区块链场景中,一般适合于对强一致性有要求的私有链和联盟链场景。例如,在IBM主导的区块链超级账本项目中,PBFT是一个可选的共识协议。在Hyperledger的Fabric项目中,共识模块被设计成可插拔的模块,支持像PBFT、Raft等共识算法。

    三.Raft协议。

      在这些分布式系统的实用场景下,其假设条件不需要考虑拜占庭故障,而只是处理一般的死机故障。在这种情况下,采用Paxos等协议会更加高效。Paxos是Lamport设计的保持分布式系统一致性的协议。但由于Paxos非常复杂,比较难以理解,因此后来出现了各种不同的实现和变种。Raft是由Stanford提出的一种更易理解的一致性算法,意在取代目前广为使用的Paxos算法。目前,在各种主流语言中都有了一些开源实现,比如本文中将使用的基于JGroups的Raft协议实现。关于Raft的原理,强烈推荐动画版Raft讲解 (猛击!查看该视频)。

      Raft最初是一个用于管理复制日志的共识算法,它是一个为真实世界应用建立的协议,主要注重协议的落地性和可理解性。Raft是在非拜占庭故障下达成共识的强一致协议。

      在区块链系统中,使用Raft实现记账共识的过程可以描述如下:首先选举一个leader,接着赋予leader完全的权力管理记账。leader从客户端接收记账请求,完成记账操作,生成区块,并复制到其他记账节点。有了leader简化了记账操作的管理。例如,leader能够决定是否接受新的交易记录项而无需考虑其他的记账节点,leader可能失效或与其他节点失去联系,这时,系统就会选出新的leader。

      在Raft中,每个结点会处于下面三种状态中的一种:

    • follower:所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态
    • candidate:会向其他结点“拉选票”,如果得到大部分的票则成为leader。这个过程就叫做Leader选举(Leader Election)
    • leader:所有对系统的修改都会先经过leader。每个修改都会写一条日志(log entry)。leader收到修改请求后的过程如下,这个过程叫做日志复制(Log Replication): 
      • 复制日志到所有follower结点(replicate entry)
      • 大部分结点响应时才提交日志
      • 通知所有follower结点日志已提交
      • 所有follower也提交日志
      • 现在整个系统处于一致的状态

    Raft阶段主要分为两个,首先是leader选举过程,然后在选举出来的leader基础上进行正常操作,比如日志复制、记账等。

    1.Leader Election 

      当follower在选举超时时间内未收到leader的心跳消息,则转换为candidate状态。为了避免选举冲突,这个超时时间是一个150~300ms之间的随机数。

      一般而言,在Raft系统中:

      1)任何一个服务器都可以成为一个候选者candidate,它向其他服务器follower发出要求选举自己的请求。

      2)其他服务器同意了,发出OK。注意,如果在这个过程中,有一个follower宕机,没有收到请求选举的要求,此时候选者可以自己选自己,只要达到N/2+1的大多数票,候选人还是可以成为leader的。

      3)这样这个候选者就成为了leader领导人,它可以向选民也就是follower发出指令,比如进行记账。

      4)以后通过心跳进行记账的通知。

      5)一旦这个leader崩溃了,那么follower中有一个成为候选者,并发出邀票选举。

      6)follower同意后,其成为leader,继续承担记账等指导工作。

    2.Log Replication

      Raft的记账过程按以下步骤完成:

      1)假设leader领导人已经选出,这时客户端发出增加一个日志的要求;

      2)leader要求follower遵从他的指令,都将这个新的日志内容追加到他们各自日志中;

      3)大多数follower服务器将交易记录写入账本后,确认追加成功,发出确认成功信息;

      4)在下一个心跳中,leader会通知所有follower更新确认的项目。

      对于每个新的交易记录,重复上述过程。

      在这一过程中,若发生网络通信故障,使得leader不能访问大多数follower了,那么leader只能正常更新它能访问的那些follower服务器。而大多数的服务器follower因为没有了leader,他们将重新选举一个候选者作为leader,然后这个leader作为代表与外界打交道,如果外界要求其添加新的交易记录,这个新的leader就按上述步骤通知大多数follower。当网络通信恢复,原先的leader就变成follower,在失联阶段,这个老leader的任何更新都不能算确认,必须全部回滚,接收新的leader的新的更新。

     

    四.POW:Proof of Work,工作证明。

      从去中心化账本系统的角度看,每个加入这个系统的节点都要保存一份完整的账本,但每个节点却不能同时记账,因为节点处于不同的环境,接收到不同的信息,如果同时记账的话,必然会导致账本的不一致,造成混乱。因此,需要有共识来达成哪个节点有权记账。比特币区块链通过竞争记账的方式解决去中心化的记账系统的一致性问题, 即以每个节点的计算能力即“算力”来竞争记账权的机制。 

      在比特币系统中,大约每10分钟进行一轮算力竞赛,竞赛的胜利者,就获得一次记账的权力,并向其他节点同步新增账本信息。然而,在一个去中心化的系统中,谁有权判定竞争的结果呢?比特币系统是通过一个称为“工作量证明”(Proof of Work,PoW)的机制完成的。

      简单地说,PoW就是一份确认工作端做过一定量工作的证明。PoW系统的主要特征是计算的不对称性。工作端需要做一定难度的工作得出一个结果,验证方却很容易通过结果来检查工作端是不是做了相应的工作。

      举个例子,给定字符串“blockchain”,我们给出的工作量要求是,可以在这个字符串后面连接一个称为nonce的整数值串,对连接后的字符串进行SHA256哈希运算,如果得到的哈希结果(以十六进制的形式表示)是以若干个0开头的,则验证通过。为了达到这个工作量证明的目标,我们需要不停地递增nonce值,对得到的新字符串进行SHA256哈希运算。按照这个规则,需要经过2688次计算才能找到前3位均为0的哈希值,而要找到前6位均为0的哈希值,则需进行620969次计算。

    1 blockchain1 → 4bfb943cba9fb9926df93f33c17d64b378d56714e8a29c6ba8bdc9690cea8e27  
    2 blockchain2 → 01181212a283e760929f6b1628d903127c65e6fb5a9ad7fe94b790e699269221 ……
    3 blockchain515 → 0074448bea8027bebd6333d3aa12fd11641e051911c5bab661a9b849b83958a7……
    4 blockchain2688 → 0009b257eb8cf9eba179ab2be74d446fa1c59f0adfa8814260f52ae0016dd50f……
    5 blockchain48851: 00000b3d96b4db1a976d3a69829aabef8bafa35ab5871e084211a16d3a4f385c……
    6 blockchain6200969: 000000db7fa334aef754b51792cff6c880cd286c5f490d5cf73f658d9576d424

      通过上面这个计算特定SHA256运算结果的示例,我们对PoW机制有了一个初步的理解。对于特定字符串后接随机nonce值所构成的串,要找到这样的nonce值,满足前n位均为0的SHA256值,需要多次进行哈希值的计算。一般来说,n值越大,需要完成的哈希计算量也越大。由于哈希值的伪随机特性,要寻找4个前导0的哈希值,预期大概要进行216次尝试,这个数学期望的计算次数,就是所要求的“工作量”。

      比特币网络中任何一个节点,如果想生成一个新的区块并写入区块链,必须解出比特币网络出的PoW问题。这道题关键的3个要素是工作量证明函数、区块及难度值。工作量证明函数是这道题的计算方法,区块决定了这道题的输入数据,难度值决定了这道题所需要的计算量。

      1.工作量证明函数 及 区块数据计算过程

      比特币系统中使用的工作量证明函数就是SHA256(猛击!查看该问题)。

      比特币区块结构如下图所示:

      比特币的区块由区块头及该区块所包含的交易列表组成。区块头的大小为80字节,由4字节的版本号、32字节的上一个区块的哈希值、32字节的Merkle根哈希值、4字节的时间戳(当前时间)、4字节的当前难度值、4字节的随机数组成。区块包含的交易列表则附加在区块头后面,其中的第一笔交易是coinbase交易,这是一笔为了让矿工获得奖励及手续费的特殊交易。

      拥有80字节固定长度的区块头,就是用于比特币工作量证明的输入字符串。因此,为了使区块头能体现区块所包含的所有交易,在区块的构造过程中,需要将该区块要包含的交易列表,通过Merkle树算法(猛击)生成Merkle根哈希值,并以此作为交易列表的哈希值存到区块头中。其中Merkle树的算法图解如下图所示。

      

      

      上图展示了一个具有4个交易记录的Merkle树的根哈希值的计算过程。首先以这4个交易作为叶子结点构造一棵完全二叉树,然后通过哈希值的计算,将这棵二叉树转化为Merkle树。

    首先对4个交易记录:Txa~Txc,分别计算各自的哈希值HA~HC,然后计算两个中间节点的哈希值HAB=Hash(HA+HB)和HCD=Hash(HC+HD),最后计算出根节点的哈希值HABCD=Hash(HAB+HCD)。

     

      而构造出来的简化的区块链结构如上图所示。We find that: 所有在给定时间范围需要记录的交易信息被构造成一个Merkle树,区块中包含了指向这个Merkle树的哈希指针,关联了与该区块相关的交易数据,同时,区块中也包含了指向前一区块的哈希指针,使得记录了不同交易的单个区块被关联起来,形成区块链。

      2.挖矿难度

      难度值是比特币系统中的节点在生成区块时的重要参考指标,它决定了节点大约需要经过多少次哈希运算才能产生一个合法的区块。比特币的区块大约每10分钟生成一个,如果要在不同的全网算力条件下,新区块的产生都基本保持这个速率,难度值必须根据全网算力的变化进行调整。简单地说,难度值被设定在无论节点计算能力如何,新区块产生速率都保持在每10分钟一个。

      难度的调整是在每个完整节点中独立自动发生的。每2016个区块,所有节点都会按统一的公式自动调整难度,这个公式是由最新2016个区块的花费时长与期望时长(期望时长为20160分钟,即两周,是按每10分钟一个区块的产生速率计算出的总时长)比较得出的,根据实际时长与期望时长的比值,进行相应调整(或变难或变易)。也就是说,如果区块产生的速率比10分钟快则增加难度,比10分钟慢则降低难度。 

      这个公式可以总结为:新难度值=旧难度值×(过去2016个区块花费时长/20160分钟)

      工作量证明需要有一个目标值。比特币工作量证明的目标值(Target)的计算公式:目标值=最大目标值/难度值

      其中最大目标值为一个恒定值:0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

      目标值的大小与难度值成反比。比特币工作量证明的达成就是矿工计算出来的区块哈希值必须小于目标值。

      3.PoW过程 

      比特币PoW的过程,可以简单理解成就是将不同的nonce值作为输入,尝试进行SHA256哈希运算,找出满足给定数量前导0的哈希值的过程。而要求的前导0的个数越多,代表难度越大。比特币节点求解工作量证明问题的步骤大致归纳如下:

      1)生成铸币交易,并与其他所有准备打包进区块的交易组成交易列表,通过Merkle树算法生成Merkle根哈希;

      2)把Merkle根哈希及其他相关字段组装成区块头,将区块头的80字节数据作为工作量证明的输入;

      3)不停地变更区块头中的随机数,即nonce的数值,并对每次变更后的区块头做双重SHA256运算(即SHA256(SHA256(Block_Header))),将结果值与当前网络的目标值做对比,如果小于目标值,则解题成功,工作量证明完成。

      比特币的工作量证明,就是俗称“挖矿”所做的主要工作。

      4.PoW能否解决拜占庭将军问题 

      关于比特币PoW共识机制能否解决拜占庭将军问题一直在业界有争议。2015年,Juan Garay对比特币的PoW共识算法进行了正式的分析,得出的结论是比特币的PoW共识算法是一种概率性的拜占庭协议(Probabilistic BA)。Garay对比特币共识协议的两个重要属性分析如下。

      1)一致性(Agreement)

      在不诚实节点总算力小于50%的情况下,同时每轮同步区块生成的几率很少的情况下,诚实的节点具有相同的区块的概率很高。用数学的严格语言说应该是:当任意两个诚实节点的本地链条截取K个节点,两条剩下的链条的头区块不相同的概率随着K的增加呈指数型递减。

      2)正确性(Validity)

      大多数的区块必须由诚实节点提供。严格来说,当不诚实算力非常小的时候,才能使大多数区块由诚实节点提供。

      因此可以看到,当不诚实的算力小于网络总算力的50%时,同时挖矿难度比较高,在大约10分钟出一个区块情况下,比特币网络达到一致性的概念会随确认区块的数目增多而呈指数型增加。但当不诚实算力具一定规模,甚至不用接近50%的时候,比特币的共识算法并不能保证正确性,也就是,不能保证大多数的区块由诚实节点来提供。

      因此,我们可以看到,比特币的共识算法不适合于私有链和联盟链。其原因首先是它是一个最终一致性共识算法,不是一个强一致性共识算法。第二个原因是其共识效率低。提供共识效率又会牺牲共识协议的安全性。另外,比特币通过巧妙的矿工奖励机制来提升网络的安全性。矿工挖矿获得比特币奖励以及记账所得的交易费用使得矿工更希望维护网络的正常运行,而任何破坏网络的非诚信行为都会损害矿工自身的利益。因此,即使有些比特币矿池具备强大的算力,它们都没有作恶的动机,反而有动力维护比特币的正常运行,因为这和它们的切实利益相关。

      PoW机制存在明显的弊端。一方面,PoW的前提是,节点和算力是均匀分布的,因为通过CPU的计算能力来进行投票,拥有钱包(节点)数和算力值应该是大致匹配的,然而随着人们将CPU挖矿逐渐升级到GPU、FPGA,直至ASIC矿机挖矿,节点数和算力值也渐渐失配。另一方面,PoW太浪费了。比特币网络每秒可完成数百万亿次SHA256计算,但这些计算除了使恶意攻击者不能轻易地伪装成几百万个节点和打垮比特币网络,并没有更多实际或科学价值。当然,相对于允许世界上任何一个人在瞬间就能通过去中心化和半匿名的全球货币网络,给其他人几乎没有手续费地转账所带来的巨大好处,它的浪费也许只算是很小的代价。

      有鉴于此,人们提出了权益证明(Proof of Stake,PoS)。

     

    五.POS:Proof of Stake,股权证明。

      PoS类似于财产储存在银行,这种模式会根据你持有数字货币的量和时间,分配给你相应的利息。 
      简单来说,就是一个根据你持有货币的量和时间,给你发利息的一个制度,在股权证明PoS模式下,有一个名词叫币龄,每个币每天产生1币龄,比如你持有100个币,总共持有了30天,那么,此时你的币龄就为3000,这个时候,如果你发现了一个PoS区块,你的币龄就会被清空为0。你每被清空365币龄,你将会从区块中获得0.05个币的利息(假定利息可理解为年利率5%),那么在这个案例中,利息 = 3000 * 5% / 365 = 0.41个币,这下就很有意思了,持币有利息。

      点点币(Peercoin)是首先采用权益证明的货币,点点币在SHA256的哈希运算的难度方面引入了币龄的概念,使得难度与交易输入的币龄成反比。在点点币中,币龄被定义为币的数量与币所拥有的天数的乘积,这使得币龄能够反映交易时刻用户所拥有的货币数量。实际上,点点币的权益证明机制结合了随机化与币龄的概念,未使用至少30天的币可以参与竞争下一区块,越久和越大的币集有更大的可能去签名下一区块。

      然而,一旦币的权益被用于签名一个区块,则币龄将清为零,这样必须等待至少30日才能签署另一区块。同时,为防止非常老或非常大的权益控制区块链,寻找下一区块的最大概率在90天后达到最大值,这一过程保护了网络,并随着时间逐渐生成新的币而无需消耗大量的计算能力。点点币的开发者声称这将使得恶意攻击变得困难,因为没有中心化的挖矿池需求,而且购买半数以上的币的开销似乎超过获得51%的工作量证明的哈希计算能力。

      权益证明必须采用某种方法定义任意区块链中的下一合法区块,依据账户结余来选择将导致中心化,例如单个首富成员可能会拥有长久的优势。为此,人们还设计了其他不同的方法来选择下一合法区块。

      PoS机制虽然考虑到了PoW的不足,但依据权益结余来选择,会导致首富账户的权力更大,有可能支配记账权。股份授权证明机制(Delegated Proof of Stake,DPoS)的出现正是基于解决PoW机制和PoS机制的这类不足。

     

    六.DPOS:Delegated Proof of Stake,委任权益证明

      比特股(Bitshare)是一类采用DPoS机制的密码货币,它期望通过引入一个技术民主层来减少中心化的负面影响。

      比特股的DPoS机制,中文名叫做股份授权证明机制(又称受托人机制),它的原理是让每一个持有比特股的人进行投票,由此产生101位代表 , 我们可以将其理解为101个超级节点或者矿池,而这101个超级节点彼此的权利是完全相等的。从某种角度来看,DPOS有点像是议会制度或人民代表大会制度。如果代表不能履行他们的职责(当轮到他们时,没能生成区块),他们会被除名,网络会选出新的超级节点来取代他们。DPOS的出现最主要还是因为矿机的产生,大量的算力在不了解也不关心比特币的人身上,类似演唱会的黄牛,大量囤票而丝毫不关心演唱会的内容。

      比特股引入了见证人这个概念,见证人可以生成区块,每一个持有比特股的人都可以投票选举见证人。得到总同意票数中的前N个(N通常定义为101)候选者可以当选为见证人,当选见证人的个数(N)需满足:至少一半的参与投票者相信N已经充分地去中心化。

      见证人的候选名单每个维护周期(1天)更新一次。见证人然后随机排列,每个见证人按序有2秒的权限时间生成区块,若见证人在给定的时间片不能生成区块,区块生成权限交给下一个时间片对应的见证人。DPoS的这种设计使得区块的生成更为快速,也更加节能。

      DPoS充分利用了持股人的投票,以公平民主的方式达成共识,他们投票选出的N个见证人,可以视为N个矿池,而这N个矿池彼此的权利是完全相等的。持股人可以随时通过投票更换这些见证人(矿池),只要他们提供的算力不稳定,计算机宕机,或者试图利用手中的权力作恶。

      比特股还设计了另外一类竞选,代表竞选。选出的代表拥有提出改变网络参数的特权,包括交易费用、区块大小、见证人费用和区块区间。若大多数代表同意所提出的改变,持股人有两周的审查期,这期间可以罢免代表并废止所提出的改变。这一设计确保代表技术上没有直接修改参数的权利以及所有的网络参数的改变最终需得到持股人的同意。

     

    七.Ripple共识算法。

      Ripple(瑞波)是一种基于互联网的开源支付协议,可以实现去中心化的货币兑换、支付与清算功能。在Ripple的网络中,交易由客户端(应用)发起,经过追踪节点(tracking node)或验证节点(validating node)把交易广播到整个网络中。追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外,还能够通过共识协议,在账本中增加新的账本实例数据。  

      Ripple的共识达成发生在验证节点之间,每个验证节点都预先配置了一份可信任节点名单,称为UNL(Unique Node List)。在名单上的节点可对交易达成进行投票。每隔几秒,Ripple网络将进行如下共识过程:

      1)每个验证节点会不断收到从网络发送过来的交易,通过与本地账本数据验证后,不合法的交易直接丢弃,合法的交易将汇总成交易候选集(candidate set)。交易候选集里面还包括之前共识过程无法确认而遗留下来的交易。

      2)每个验证节点把自己的交易候选集作为提案发送给其他验证节点。

      3)验证节点在收到其他节点发来的提案后,如果不是来自UNL上的节点,则忽略该提案;如果是来自UNL上的节点,就会对比提案中的交易和本地的交易候选集,如果有相同的交易,该交易就获得一票。在一定时间内,当交易获得超过50%的票数时,则该交易进入下一轮。没有超过50%的交易,将留待下一次共识过程去确认。  

      4)验证节点把超过50%票数的交易作为提案发给其他节点,同时提高所需票数的阈值到60%,重复步骤3)、步骤4),直到阈值达到80%。

      5)验证节点把经过80%UNL节点确认的交易正式写入本地的账本数据中,称为最后关闭账本(Last Closed Ledger),即账本最后(最新)的状态。

     

     Ripple共识过程节点交互示意图

     

    Ripple共识算法流程

     

      在Ripple的共识算法中,参与投票节点的身份是事先知道的,因此,算法的效率比PoW等匿名共识算法要高效,交易的确认时间只需几秒钟。当然,这点也决定了该共识算法只适合于权限链(Permissioned chain)的场景。Ripple共识算法的拜占庭容错(BFT)能力为(n-1)/5,即可以容忍整个网络中20%的节点出现拜占庭错误而不影响正确的共识。

     


     

      以上主要是目前主流的共识算法。 但说起哪种共识机制更好或更具替代作用? 我认为DPOS来单独替代POW,POS或者POW+POS不太可能,毕竟存在即合理。每种算法都在特定的时间段、场景下具有各自的意义,无论是技术上,还是业务上。如果跳出技术者的角度,更多结合政治与经济的思考方式在里面,或许还会不断出现更多的共识机制。

      对于算法的选择,一句话总结如下:

     在区块链网络中,由于应用场景的不同,所设计的目标各异,不同的区块链系统采用了不同的共识算法。一般来说,在私有链和联盟链情况下,对一致性、正确性有很强的要求。一般来说要采用强一致性的共识算法。而在公有链情况下,对一致性和正确性通常没法做到百分之百,通常采用最终一致性(Eventual Consistency)的共识算法。

      通俗点就是:共识算法的选择与应用场景高度相关,可信环境使用paxos 或者raft,带许可的联盟可使用pbft ,非许可链可以是pow,pos,ripple共识等,根据对手方信任度分级,自由选择共识机制。

    REFERENCE

    1. Diego Ongaro and John Ousterhout Stanford University In Search of an Understandable Consensus Algorithm (Extended Version)
    2. 《区块链技术指南》邹均张海宁唐屹李磊 著
    3. Raft协议 https://blog.csdn.net/dc_726/article/details/48832405/
    展开全文
  • 泛泛而谈:白话分布式一致性与共识算法 转载,存储,学习,共享。。。。 说的简单明了他们说你是泛泛而谈,算法这东西是讲明白的吗?自己不动手光想听别人讲就能明白,还想深刻明白,天下哪有这种便宜事!好吧,我...

    泛泛而谈:白话分布式一致性与共识算法

    转载,存储,学习,共享。。。。

    说的简单明了他们说你是泛泛而谈,算法这东西是讲明白的吗?自己不动手光想听别人讲就能明白,还想深刻明白,天下哪有这种便宜事!好吧,我就泛泛而谈吧。

    一、分布式系统问题

    多节点,提高了系统整体的负载能力;可以使用多个处理器,同步查询,提高查询性能;可以有更多节点复制数据,增强了失败情况下的恢复能力,提高了系统整体的可用性。但是,分布式处理增加了系统各个方面的复杂度,关键问题是解决如何通信问题。

    (1)分布式系统的先天不足—CAP理论

    2000年,Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论:分布式系统不可能同时满足一致性(Consistency),可用性(Availability)和分区容错性(Tolerance of network Partition) 这三个需求。

    一致性 Consistency:系统在执行过某项操作后仍然处于一致的状态。在分布式系统中,更新操作执行成功后所有的用户都应该读到最新的值,这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。这个和数据库ACID的一致性类似,但这里关注的是所有数据节点上的数据一致性和正确性,而数据库的ACID关注的是在一个事务内,对数据的一些约束。

    可用性 Availability:每一个操作总是能够在一定的时间内返回结果,这里需要注意的是“一定时间内”和“返回结果”。一定时间指的是,在可以容忍的范围内返回结果,结果可以是成功或者失败。关注的是在某个结点的数据是否可用,可以认为某一个节点的系统是否可用,通信故障除外。

    分区容错性 Partition Tolerance:是否可以对数据进行分区。存在网络分区的情况下,仍然可以接受请求。

    (2)最终一致性、CAP理论、BASE原则

    最终一致性就是等会儿就一致了,早晚会一致的。使用最终一致性的关键就是想方设法让用户“等会儿”。办法是让用户知道(对用户透明),这个方法有个学名叫“用户感知到的一致性”,意思就是让用户自己知道数据已经不一致了,你再忍会儿。

    虽然分布式系统不符合ACID原则,但是我们符合NOACID原则。我们换个词,就叫BASE原则(基本可用性、软状态与最终一致性)。BASE的含义就是指:设计可以通过牺牲一定的数据一致性和容错性来换取高性能的保持甚至提高。其实所有的分布式系统都是牺牲C(一致性 Consistency )来换取P(分区容错性 Partition Tolerance ),而不是牺牲A(可用性 Availability )。可用性是所有分布式系统共同追求的特性。

    二、共识算法

    (1)拜占庭将军问题

    就是说,皇帝发出的命令,各地区的将军能不能行动一致,怎么避免出现不一致,甚至出现叛徒。行动听指挥,Leader说了算。

    避免分布式系统节点数据不一致,方法很简单,写操作由其中一个节点执行。这个Leader节点谁来做,这个Leader选举办法,就是一致性算法或共识算法。

    (2)工作量证明机制(Proof of Work, POW)

    手速快的,来做写节点Leader,谁手速快,比一比就知道了,就是POW算法。就是大家熟悉的挖矿,通过与或运算,计算出一个满足规则的随机数,即获得本次记账权,发出本轮需要记录的数据,全网其它节点验证后一起存储。
    优点:完全去中心化,节点自由进出;缺点:目前Bitcoin已经吸引全球大部分的算力,其它再用Pow共识机制的区块链应用很难获得相同的算力来保障自身的安全;挖矿造成大量的资源浪费;共识达成的周期较长,不适合商业应用。

    (3)股权证明机制(Proof of Stake, POS)

    谁钱多谁来,根据每个节点所占代币的比例和时间,等比例的降低挖矿难度,从而加快找随机数的速度。
    优点:在一定程度上缩短了共识达成的时间,对节点性能要求低,达成共识时间短,网络环境好的话可实现毫秒级;缺点:还是需要挖矿,本质上没有解决商业应用的痛点。

    (4)授权股权证明机制(Delegate Proof of Stake, DPOS)

    类似于公司董事会制度,选出一定数量的代表,来负责生产区块。这些代表是怎么被选出来的呢?是每一位持币人,根据手中的持有的代币投票选出来的。每个股东可以将其投票权授予一名代表,获票数最多的前100名代表按既定时间表轮流产生区块。

    (5)实用拜占庭协议(PBFT)

    PBFT是一种基于消息传递的一致性算法,算法经过三个阶段达成一致性,这些阶段可能因为失败而重复进行。该算法主要应用在IBM超级账本等联盟区块链或私有区块链场景中,容错率低、灵活性差,超过1/3的节点作恶就会导致系统崩溃,并且不可动态添加节点(这能算商用一致性算法吗?)。

    假设节点总数为3f+1,f为拜占庭错误节点:

    1)当节点发现leader作恶时,通过算法选举其他的replica为leader;

    2)leader通过pre-prepare 消息把它选择的value广播给其他replica节点,其他replica节点如果接受则发送prepare,如果失败则不发送;

    3)一旦2f个节点接受prepare消息,则节点发送commit消息;

    4)当2f+1个节点接受commit消息后,代表该value值被确定。

    三、Paxos算法

    Paxos算法是莱斯利兰伯特于1990年提出的一种基于消息传递,具有高度容错特性的一致性算法。SunlightDB等区块链数据库使用这种算法,Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。

    基于拜占庭将军问题解析:分为以下两种角色:proposer:提交者;acceptor:决策者

    1)提交者1发起提议,派通信兵带信给3个决策者,内容为(编号1);
    2)3个决策者收到提交者1的提议,由于之前还没有保存任何编号,因此把(编号1)保存下来,避免遗忘;同时让通信兵带信回去,内容为(ok);
    3)提交者1收到至少2个决策者的回复,再次派通信兵带信给3个决策者,内容为(编号1,进攻时间1);
    4)3个决策者收到提交者1的时间,把(编号1,进攻时间1)保存下来,避免遗忘;同时让通信兵带信回去,内容为(Accepted);
    5)提交者1收到至少2个决策者的(Accepted)内容,确认进攻时间已经被大家接收;
    6)提交者2发起提议,派通信兵带信给3个决策者,内容为(编号2);
    7)3个决策者收到提交者2的提议,由于(编号2)比(编号1)大,因此把(编号2)保存下来,避免遗忘;又由于之前已经接受提交者1的提议,因此让通信兵带信回去,内容为(编号1,进攻时间1);
    8)提交者2收到至少2个决策者的回复,由于回复中带来了已接受的提交者1的提议内容,提交者2因此不再提出新的进攻时间,接受提交者1提出的时间。

     

    一个潜在的问题是 proposer 在此过程中出现故障,可以通过超时机制来解决。极为凑巧的情况下,每次新的一轮提案的 proposer 都恰好故障,系统则永远无法达成一致(概率很小)。Paxos 能保证在超过50%的正常节点存在时,系统能达成共识。


    区块链落地应用案例:SunlightStamp 区块链签章

     

    近年来,随着互联网金融以及区块链技术的快速发展,电子签章行业兴起,短短几年时间就获得长足发展。不管是国内还是国外,电子签章都将成为一种趋势。

     

    电子签章服务商DocuSign

    2018年5月31日,上市仅一个多月的美国电子签章服务商DocuSign市值已经超过77亿美元,与上市前相比,涨幅超过75%。

     

    2019年4月,DocuSign在财报中透露,今年一季度总收入2.14亿美元,同比增长37%。订阅收入2.015亿美元,同比增长36%。预计在未来一年,全球个人用户数的增长将高达26%,而企业客户的增长将高达33%。从市值这个维度来看,DocuSign的市值是百亿美元,这个规模比微博、陌陌、YY都要大。

     

    DocuSign招股书披露,全球Top10的科技公司中有7家使用DocuSign的服务;全球Top20的制药企业中,有18家使用DocuSign的服务;全球Top15的金融企业中有10家是DocuSign的客户。

     

    美国电子签名市场相对成熟,却依然保持着30%左右的增长,因此全球投资机构都在寻找下一个DocuSign。对投资者来说,中国电子签名市场规模太大了。随着国务院、财政部对电子签名的认可,房屋买卖、物流运输等行业鼓励采用电子合同,电子签名的效能正在得到企业认可。艾媒咨询显示,2019年中国电子签约次数高达216.4亿次,到2020年预计将高达374.4亿次,年增长率超过80%。

     

    新型区块链签章产品优势

    SunlightStamp通过完善的PKI技术来验证数字签名及证书的有效性,并将验证结果以有效印章的方式在文档中直观的显示出来,以此保证文档内容的完整性和签名的不可否认性。

     

    随着技术的发展,SunlightStamp不断引入更多的安全措施,如数字水印技术,签名证书的撤销列表校验,尤其是通过引入区块链技术取代传统数据库存储,极大的增强了签章数据存储的安全性和不可篡改性。

     

    区块链签章优势一:基于区块链的签章数据存储。传统的电子印章签章及其管理系统均是数据中心化的集中化存储,每个节点的认证,均需要中心端的许可,每次用印记录必须实时上传中心,这种模式天然存在弊端。利用区块链去中心化、信息不可伪造、不可篡改的技术特点,打造更安全、更方便的电子签章模式。

     

    区块链签章优势二:基于区块链的签章数据验证。传统签章所有密码运算使用智能卡系统内置的相关算法实现。区块链电子签章系统的签名运算可以使用签章联盟链内置的相关算法实现,签名运算完全在联盟链全节点内完成,不会泄漏到主机内存或其他设备中。

     

    区块链签章优势三:基于区块链的签章数据共享。利用SunlightDB区块链数据库技术,将数据同步传送给司法鉴定中心、公证处,保全中心、合同双方等,多方共同组织形成一条签章联盟链,同时在线出具司法鉴定证书、公证书。当债务人未履行合同义务时,可凭公证机构签发的执行证书,直接向人民法院申请强制执行。

    区块链签章优势四:基于区块链的三流合一新型电子商务通过区块链签章SunlightStamp和区块链通证技术SunlightChain相结合,使未来的区块链电子商务更具有法律效应。从商务谈判期,合同双方使用的电子签章技术;到商务交易期,底层数据共享,使用的区块链数据库;最后商务结算期,使用的区块链通证技术。商务过程全流程跟踪,可追溯。三种安全产品共同组成了新型区块链电子商务解决方案。

    SunlightStamp区块链签章系列产品

    SunlightStamp区块链签章系列产品目前包含:适用于微软Office电子办公Word版本和Excel版本,Adobe原厂提供的PDF文档版本,以及基于网站应用的WebStamp网页签章,这四个版本。

     

    SunlightStamp组件技术,使其可以无缝嵌入到Office运行环境中,不影响原有Office系统的功能。签名后,不会形成其他附加文档,而是与待签文档结合在一起,一同在办公系统中流转,与对原始文档的其他操作无异。控件在Office文档中的显示效果与纸质文档上的普通印章或签名的效果十分接近,并且其打印效果与纸质文档的签章效果更为接近。

     

    SunlightStamp电子办公Word版本和Excel版本,是以微软Office为运行环境,对Word、Excel等格式的文件进行电子签章的操作,能够独立于网络环境运行,可以作为单独的电子印章系统来使用,也可以与现有的办公OA产品结合起来发挥更完整的作用。由于签章部分的独立性,使得OA厂商只要在开启Word文档时使Word可见就可以了。其他的事情完全由签章系统自己完成,不会干扰OA系统的操作。

     

    主要功能

    • 文档签章:能在Office电子文档上签署印章。印章上浮透明显示,效果如同纸质盖章或签名。支持多个单位或个人的会签,签章前电子印章可移动,一旦签章则印章不能移动,签名哈希数据存放于区块链中不可篡改。

    • 文档验证:实现电子文档的完整性验证,即如果签署后的文档发生了变更,验证时则会提示文档验证不通过,并在印章上显示不可去除的遭篡改标识。

    • 离线认证:利用颁发者证书和证书撤销列表来验证印章对应的签名证书的有效性,同时利用数字水印技术验证印章本身的有效性。

    • 在线认证:通过签章联盟链来验证印章对应的签名证书的有效性,同时利用数字水印技术验证印章的有效性。

    • 删除样章:无法用Delete键删除样章,仅能通过此功能删除样章。

    • 撤消签章:签章用户若希望对签章后的文档内容进行修改,可以使用此功能撤消签章,待修改文档完成后再执行“文档签章”操作来重新签章。

    • 签章时间:显示签署该印章时的计算机本地时间。

    • 锁定文档:提供类似于OFFICE自身携带的“保护文档”功能,并且设置重试次数,超过重试次数后,文档的锁定状态只能由签章者利用签章时的密码设备解除。处于锁定状态下的文档其签章控件的必要功能依然有效,如:“文档验证”,“签章时间”等等。

     

    区块链签章SunlightStamp系列产品演示

     

    SunlightStamp WORD文档区块链签章演示视频

     

    SunlightStamp Excel文档区块链签章演示视频

     

    SunlightStamp WebStamp网页签章演示视频

     

    SunlightStamp PDF文档区块链签章演示视频

    展开全文
  • 区块链主流共识算法简介

    千次阅读 2021-12-10 22:19:54
    本文主要是参考网上资料自己对区块链共识算法做的一个汇总和简介 主要参考文章“一文读懂11个主流共识算法, 彻底搞懂PoS,PoW,dPoW,PBFT,dBFT这些究竟是什么鬼”(https://www.tuoniaox.com/news/p-287193.html)
  • 在这样的一个异步系统中,需要主机之间进行状态复制,以保证每个主机达成一致的状态共识。然而,异步系统中,可能出现无法通信的故障主机,而主机的性能可能下降,网络可能拥塞,这些可能导致错误信息在系统内传播。...
  • 目录一.拜占庭容错技术(Byzantine Fault Tolerance,BFT)二.PBFT:Practical Byzantine Fault Tolerance,实用拜占庭...六.DPOS:Delegated Proof of Stake,委任权益证明七.Ripple共识算法。 正文  近几天对
  • 当产品同学提出需求的时候,研发同学做了好的回应,但实际上双方想的内容并不一致,这种情况我们称之为表面一致;当产品上线后,产品同学提出需求疑问时,研发同学的回答充满了各种技术行话:定时系统,原子性等。...
  • 就是有相同验前知识的人不可能达成一致。 我们在公布这个观察结果时多少有点缺乏自 信, 因为一旦人们有了适当的框架, 从数学的角度 来看, 它就会变得是微不足道的了。尽管如此, 从 直观上, 这个结果并不是非常明显...
  • 所谓一致性,就是指数据要完整、要同步。比如,我们在网上下了个订单,付了款,商城系统会记录下这些数据,之后无论我 们在哪里访问自己的订单,都能看到同样的结果,即便商城系统出了故障,那一般也会返回一个错误...
  • 共识,权威以及去中心化的区块链

    万次阅读 2017-11-25 09:22:23
    所谓共识,很简单,就是大家都相信的东西,正如合作需要一份合作双方均承认的协议一样,共识也可以看作是某种非约束性的协议,在这份协议的背后,需要参与者 默默 履行一种契约。   我们用纸币买东西的时候,...
  • 区块链与分布式系统一致性解决方案拜占庭将军问题共识算法常见的共识算法 分布式系统中的节点通信存在两种模型:共享内存(Shared memory)和消息传递(Messages passing)。基于消息传递通信模型的分布式系统,不可...
  • 客观事实性的一致共识比较容易达成,而主观价值性的一致共识往往不易形成,原因是多方面的,而最重要的一点是态、势、感、知四个要素阶段还没有深度统一化,分歧化没有得到化解所致。 那么怎样才能形成有效的...
  • Hi,相信关注区块链的你,一定对经常听到的“共识”一词充满了好奇,那作为区块链灵魂的共识算法到底是什么呢? 今日在线解决三大疑问:共识算法到底是什么?有哪些?未来发展如何? 共识算法到底是什么? 在了解这...
  • 目前Vitalik和我对于Serenity阶段的POS协议应该长什么样已经有了许多共识,只剩一些细节方面的分歧。我们称它为友善的小精灵Casper(Casper the friendly ghost),因为它实际上是GHOST(Greedy Heaviest-Observe
  • 终局性 (liveness):所有参与共识的诚实的节点,最终可以达成一致性结果。 3. 容错性 (fault tolerance):在共识算法的成功执行过程中,可以容许参与共识的节点发生一些错误。 以下,以表格形式列举了主流的几...
  • 区块链的共识机制

    2018-08-28 14:16:57
    区块链系统会选取记账最快、最好的那个节点,以这个节点的账目为准,并发送备份给所有节点。那么,系统是凭什么来认定最快、最好的节点的?最快、最好的标 ...换句话说,靠什么达成共识?这就涉及区块链的共识...
  • 深入理解区块链之七:挖矿与共识

    千次阅读 2017-08-16 00:00:00
    挖矿与共识简介挖矿是增加比特币货币供应的一个过程。挖矿同时还保护着比特币系统的安全,防止欺诈交易,避免“双重支付”,“双重支付”是指多次花费同一笔比特币。矿工们通过为比特币网络提供算力来换取获得比特币...
  • 典型案例: A公司是一家专门从事ERP系统研发和实施的IT企业,目前该公司正在为某大型生产单位(甲方)研发一个ERP系统。A公司同甲方关系比较密切,也正因为 ...由于签订合同内容简单, 合作双方对范围没有达成一...
  • 我们在前文讲述了许多区块链这几年发展演进过来的共识机制。在之前的内容中,我们讲述的共识多属于区块链1.o与2.0的知识。这次,我们着重讲述下区块链3.0时代的HyperLedger Fabric中的共识机制以及相关特性。而今,...
  • 关于DAG共识的调研

    千次阅读 2021-09-02 10:15:08
    DAG 是什么常见共识机制主链DAG共识朴素DAG平行链DAG问题与挑战 这是自己看的一篇综述,参考里面的分类并对现在的一些DAG共识做的简要理解,后面会对一些共识的论文做学习笔记。 若有错误之处还请批评指正。 ps: ...
  • Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法。Paxos算法目前在Google的Chubby、MegaStore、Spanner等系统中得到了应用,Hadoop中的ZooKeeper也使用了Paxos算法,在上面的...
  • 分布式共识算法

    千次阅读 2022-01-03 10:58:47
    分布式共识算法可以分为CFT(Crash Fault Tolerance)与BFT(Byzantine Fault Tolerance)。 CFT CFT算法如Paxos、Raft,只能容忍分布式节点中存在故障,不能容忍分布式节点中有节点作恶。适用于机器节点之间的通信...
  • 在拜占庭将军问题中,将军们必须有一个预定的方法,使所有忠诚的将军能够达成一致,即使有几个叛徒传递了错误消息,也不会使忠诚的将军做出错误的计划。   拜占庭将军问题的实质是:要寻找一个方法,使将军们能在...
  • raft是一种分布式共识协议, raft解决的是多个节点如何达成共识的问题 raft保证了高可用, 但不是强一致, 而是最终一致性 raft把时间分成了一个个任期, 任期总是以选举开始的, 如果选举失败, 该任期...
  • 共识机制

    2019-09-11 20:59:12
    共识机制是区块链节点就区块信息达成全网一致共识的机制,可以保证最新区块被准确添加至区块链、节点存储的区块链信息一致不分叉甚至可以抵御恶意攻击。 当前主流的共识机制包括:工作量证明、权益证明、工作量证明...
  • Casper共识协议

    千次阅读 2018-06-05 08:06:58
    Security-deposit based security and authenticationCasper是一种基于保证金的经济激励共识协议(security-deposit based economic consensus protocol)。协议中的节点,作为“锁定保证金的验证人(bonded validators...
  • Cardano(ADA)的共识算法Ouroboros

    千次阅读 2018-04-29 09:10:01
    Cardano(ADA)的共识算法Ouroboros一、前言2018年的公链将会毫不意外的统一转向pos共识方向,pow将会被扫入历史中。在我认为,pos代表的就是不再需要从现实中将价值输入至区块链体系(pow消耗现实中的算力达成区块链...
  • 恒星共识协议白皮书概论

    千次阅读 2018-03-12 21:03:13
    SCP分布式共识呈现最主要的挑战是:系统达成一致声明时不能规避被阻断和失去活跃度的风险。   在系统达成一致前,一份声明有可能在长期不确定状态中停滞。SCP的目标就是使得这些阻碍和分支的潜因降至最少。该协议...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,375
精华内容 1,750
关键字:

双方达成一致共识

友情链接: xuanfugouwuche.zip