引言：EVM+工作组正在采取行动，在EOS上部署以太坊虚拟机

概述

EOS正在凝聚社区力量共同开发生态所需的关键项目，从而进一步推动EOS生态的复苏。我们拥有才华横溢的开发人员，能够做出重大贡献的社区领袖，以及责任心和行动力都非常强的EOS网络基金会。
EOS正在开辟自己的前进道路，并开启一个新的协作时代。
目前，由EOS网络基金会资助成立的六大核心工作组正在高速运行，每个工作组都在其领域发挥重要作用，其中API+、Core+、Wallet+和Audit+四个工作组蓝皮书已接近完成，每份蓝皮书都是重要的研究成果，将详细阐述发展目标，各自领域如何取得成功的可行策略等。
今天，我们将带领大家认识EVM+核心工作组，在正式介绍之前，我们先来了解一下六大核心工作组的概况。

六大核心工作组介绍

目前，EOS网络基金会赞助成立了六个核心工作组，他们分别是：

• API+：主要负责提供数据接口，帮助EOS生态以外的应用程序更好的集成EOS网络。
• Core+：主要负责维护EOS系统使EOS更适合运行各种类别的应用程序。
• Wallet+：主要负责配合软件将EOS集成到外部应用程序中。
• Audit+：主要负责为EOS应用提供安全分析工具和合约审计的整体框架。
• EVM+：主要负责实现与EVM的兼容以及探索EOS可行性的经济激励措施。
• Recover+：主要负责建立危机处理框架，通过制定紧急联络、反应机制、DAO保险和白帽奖励等措施，帮助EOS项目在遭遇黑客攻击后以更合理有效的方式应对危机及追回丢失资产。

核心工作组将会与EOS生态中最有经验的人和组织合作，在落实EOS路线图方面发挥重要作用。这将是一个评估EOS生态现状、识别潜在问题并为未来发展制定路线图的绝佳机会。

每个工作组都收到了来自EOS网络基金会提供的20–25万美元的资助，另外EOS网络基金会还支出10万美元成立了一个监督小组，专门监督工作组的整体进展。

但出于社区呼声和生态需求的考虑，EVM+工作组与其他工作组的工作流程略有不同。在EOS Argentina的领导下，EVM+工作组将采取更敏捷的方式进行开发。

EVM+工作组不撰写蓝皮书，而是直接进行开发和产品交付，从而更快的在EOS智能合约层面实现EVM兼容。另外， EVM+工作组的初始预算资金为20万美元。

EVM+工作组介绍

EOS目前面临的最重要的问题之一是区块链的互操作性。
区块链领域最容易产生的问题是向内聚焦发展，而忽视了向外兼容取长补短，这样的问题在EOS表现的很明显。开发人员经常陷入一种思维逻辑：EOS拥有最好的技术，所以EOS是最好的地方，即使其他公链生态的人都还没有意识到EOS的潜力。

这样的想法会使EOS与更广阔的区块链世界隔绝开来，很容易坐井观天错过许多机会。许多开发者离开EOS，转投以太坊，原因就是虽然以太坊存在缺陷，但是却拥有更好的兼容性。

这也是我们成立EVM+工作组并加速这方面工作的重要原因，在EOS上部署以太坊虚拟机是一件非常重要的工作，我们需要推动EOS融入更广阔的区块链生态，不断的引进来、走出去，兼容并蓄快速发展。

从技术及业务角度来看，实现EVM兼容能够在释放EOS潜力方面发挥至关重要的作用。我们需要更多的以太坊开发者和用户加入EOS生态，而帮助EOS实现EVM兼容是吸引他们加入的最佳方式。

站在成功的肩膀上，吸引开发人才

EVM+工作组的领导团队是EOS创世区块生产者EOS Argentina，该团队也是Evodex和EOS Metamask钱包背后的开发人员。
为EVM+工作组提供协助的还有EOS生态的著名开发者Syed Jafri，他在2020年凭借EOSIO.EVM赢得了Block.one举办的EVM挑战赛， EOSIO.EVM使Solidity开发人员能够在EOSIO上快速启动并以高达100倍的速度和低于1000倍的成本运行应用程序。可以说，Syed Jafri在帮助EOS实现EVM兼容方面十分有经验。
EVM是EOS急需的创新。EOS公链在过去几年中面临的主要问题之一是资金匮乏。让我们和以太坊生态做一个对比：
以太坊速度更慢、效率更低而且Gas成本非常高，但以太坊和其他基于EVM的公链之间拥有更高的网络效应和代币流动性。另一方面，一部分以太坊上的开发人员能够通过创造基于Solidity编写的模块化、可重复利用、安全开源的智能合约获得高额回报，另一部分开发者可通过OpenZeppelin等组织的收录的代码库获得丰富的开发工具和教程。一个不可否认的事实是：EVM生态系统中的开发人员工具、代码库、可供dApp开发人员使用的开源代码一直在快速增长。
反观EOS生态，开发人员只能使用不太成熟的工具从头开始构建许多代码库，一个不恰当的比喻是：以太坊生态的开发者制造汽车就像是搭积木，把现成的车轮、方向盘、发动机等拼接在一起就好，而EOS生态的开发者想要制造汽车，需要从制造车轮开始。
EOS网络基金会赞助的其他工作组正在专注于改善EOS开发人员的体验，提供更多可用的本地工具，但都需要一些时间才能充分实现。
因此，我们和社区都认为，我们可以利用EVM已经存在的人才和资源，并通过EVM兼容将这些引入EOS，以此挖掘出EOS生态的潜力。
EOS发展已经进入极其重要的一年，EOS仍然面临两个巨大挑战：
一方面，EOS必须向潜在的开发者展示其巨大的潜力和价值；
另一方面，EOS必须消除开发者进入生态的障碍，尽可能降低门槛，吸引更多开发者加入。
即使项目方或开发人员相信EOS更好，但如果进入EOS生态的过程漫长、繁琐，项目方和开发人员也不会加入。因此帮助其他公链的开发人员以无障碍、低门槛的方式，将项目部署、迁移或克隆到EOS生态，是更行之有效的方式。
EVM+工作组：在EVM和EOSIO之间架起桥梁
EVM+的总体目标是从开发人员和用户的角度，使EOS成为一个兼容的EVM平台。为此，以下是工作组正在解决的关键问题：
智能合约级别的兼容与本地节点实施：EOS Argentina正在努力开发基于智能合约的解决方案，使 EVM 能够在 EOS VM WASM 运行时正常运行。 这将允许EOS网络在不进行协议升级的情况下升级EVM运行（无需分叉）。
ETH 预编译合约：这不仅有利于EOS上的EVM，同时也有利于智能合约开发人员。 EOS与其他链一样，交易执行时间有限（协议为150毫秒，BP为30毫秒）。 尽管EOS VM功能强大且速度很快，但仍有一些类型的操作在Web汇编中执行时，缺乏它们在本机代码中可以进行的优化。 为了加快速度，EVM+工作组正在寻求将ETH预编译实现为EOS内在函数（本地代码）。
完全兼容RPC：该领域的计划仍在开发中，但EVM+团队的目标是至少支持大多数RPC，以允许在ETH上使用通用工具/开发环境。这将是该计划最重要的工作之一。
确定性Gas消耗/计费：EOS链使用三种资源：CPU（主观度量/可变价格）、NET（客观度量/可变价格）和RAM（客观度量/可变价格）计费。这方面工作的挑战是为用户提供确定性的Gas消耗和有竞争力的Gas价格，同时防止Web3 API被滥用。
支持Metamask：这意味着EOS生态将支持Metamask钱包，以便EOS本地合约和使用Solidity编写的EVM合约进行交互。
EVM+工作组将按照上述方向快速推进工作，为EOS实现EVM兼容创建最佳解决方案，并计划在2022年夏天之前产生切实可行的解决方案。
目前的六个工作组正在构建一个框架，使开发人员和用户更容易参与EOS，促进EOS网络的增长，使EOS生态系统更具吸引力。 EOS的未来从未如此光明。 我们邀请您加入我们，共同创造区块链世界最伟大的公链回归故事。
请继续关注EOS网络基金会赞助的其他工作组的深入研究。
关于EOS网络基金会
EOS网络基金会是一个非营利性的组织，旨在倾听社区声音、传达社区意愿并扶持社区优质项目发展，成为EOS社区的信息共享桥梁，并为EOS生态提供资金、技术、运营、未来规划、生态构建等关键基础设施支持，进一步发挥EOS作为世界上速度最快的治理型区块链的全部潜力。
EOS网络基金会Discord
EOS网络基金会中文Twitter
EOS网络基金会中文Medium
EOS网络基金会中文电报订阅号
EOS网络基金会中文电报群

https://medium.com/eos-network-foundation/evm-bringing-the-ethereum-virtual-machine-to-eos-f26b88466d99

关键要点

EOS 网络基金会通过招募网络架构师 Dan Larimer，在加强其独立于 Block.one 方面迈出了重要一步。
Larimer 和他的团队将分叉 EOSIO 代码库。
多年来，该项目的创始公司 Block.one 一直未能兑现承诺，社区普遍对此表示不满，但这些进展都是如此。

EOS 网络基金会已聘请 EOSIO 的创始开发者 Dan Larimer 帮助其接管 EOS 生态系统的方向。该合作伙伴关系是在 EOS 社区投票停止授予其创始支持者 Block.one 之后的。

EOS Network Foundation 的目标是更美好的未来

EOS 网络基金会的目标是复兴。

Dan Larimer 是 EOS 的架构师，之前是该项目的创始支持者 Block.one 的一部分，现在将帮助该基金会重振该项目的生态系统。为了进一步建立与 Block.one 的独立性，Larimer 和他的团队将分叉 EOSIO 代码库。

分叉将发生在两个主要升级中：Mandel 2.3 和 Mandel 3.0。EOS Network Foundation 获得了 200,000 EOS 来帮助 Larimer 和他的团队执行分叉。

Larimer 在新闻稿中表示，Mandel 代码分叉是“通往 EOS 独立的最短路径”。他还将分叉描述为“振兴 EOS 多年计划的第一步”。

今天宣布的事态发展是在 EOS 社区多年的困境之后发生的。EOS 在 2017 年声名鹊起，当时 Block.one 通过 ICO 筹集了 41 亿美元来资助该项目。它是加密社区中被称为“以太坊杀手”的几个区块链之一。然而，它未能兑现承诺。在筹集资金之后，Block.one 提出了一些在几年后仍未推出的举措。

Block.one 的失误导致 EOS 社区内长期存在分歧。该公司被指控阻碍了该项目的进展，EOS 网络基金会的首席执行官不断声称由于 Block.one 未能执行而遭受了损失。在两个阵营之间多年的紧张关系之后，EOS 区块生产者在 12 月投票停止了 6700 万个 EOS 代币的归属，这些代币计划在未来六到七年内为 Block.one 解锁。该拨款目前价值约 1.8 亿美元。

EOS 网络基金会希望加入 Larimer 将使该项目更接近于实现其最初的愿景。上周，它从 EOS 社区获得了 2100 万美元的资金，以实现其目标。能否卷土重来，还有待观察。

英文原文：https://cryptobriefing.com/eos-wants-fulfill-2017-promises-with-dan-larimer/

不知道是阅读量到了质变，还是后面引用的这篇文章太好，我终于对BFT-DPOS有了更深刻的理解

POS:
出块不再由算力说了算，由节点持有的stake说了算，解决了POW算力资源被大量无用消耗，但由于无条件信任代表，节点作恶非常容易 , 比如nothing at stake攻击

DPOS：
动态产生一定数量的代表比如21个节点代表，只由这21个节点生成区块，降低了作恶的概率，同时用事后惩罚限制节点代表作恶行为，但始终不够安全(怎么惩罚，使用抵押物？抵押物需要多少？作恶导致的失败交易的损失都是可以量化的吗？如果不能量化抵押物就没有意义)，同时确认速度确实也慢(需要14个block）

BFT+DPOS：
一个区块生产后通过BFT协议立马确认，解决了DPOS确认慢问题，需要超过1/3节点才能作恶，相比POW 51%作恶条件，这个1/3值相对来说还是偏低了点，但是这是一个折中，也只能这样了

BFT + DPOS + 小块：
该协议是为了加快出块速度，该改进的核心思想是让同一个节点产生6个小块。这个能提升性能的核心原因是6个小块的产生没有等待确认的环节。在BFT+DPOS算法中，一个节点要创建新块，必须等上一个块被确认(或者超时)，因为它不确定上一个节点是否作恶是否会被确认，所以它只能等。但是如果上一个块时也是该节点产生的，它自然不需要等上一块确认，因为它知道上一个块是真实的，不是作恶的块，最后肯定会被确认，所以安心生产下一块。

可见DPOS+BFT+小块机制中，区块生成和确认以pipeline的方式进行，是同时进行的，加快了出块速度。

何为作恶：

各种共识算法，节点基本都会进行数据检验功能，因而数据伪造作恶基本不可能。那真正的作恶是什么？

主动作恶：节点主动生产两个区块，给一部分节点发送新区块A，另外一部分节点发送区块A1,这样系统就产生分叉了。

被动作恶： 块传播因为网络延时或者中断，会导致一部分节点缺失该块的信息，进而会产生分叉，然后后续区块生产者发现分叉后，如果遵循只选择一个分支生产区块就会让分叉收敛(能收敛最后就能达成共识)，但是如果继续保持并加重这个分叉，最后就会导致整个链变成一颗森林，最后节点就永远没法达成共识, 这是被动作恶。比如POS的noting at stake攻击，当系统出现分叉时，生产者基于自己的利益会在两个分叉区块上各自生成一个区块(这样不管哪个分叉获胜，自己都能获得收益)，这其实间接助长和加重了分叉

因而要阻止这些作恶行为，有三种方法:

1)机制保证，让生产者没有时间来生成2个区块(POW)

2)利益保证，生成两个区块最后肯定没用(BFT算法, 大家最后只会认可一个快)，生产者获取不了什么好处，自然没必要生产两个区块

3）事后惩罚，比如DPOS，这种方法其实没啥用，因为事后发现作恶节点后，系统没法回溯区块，只能惩罚作恶节点，但是这个作恶损失是不确定的(前面提到过)，起不到惩罚作用，且抵押物模式是一种限制，不利于生态发展

引用原文

区块链中最重要的便是共识算法，比特币使用的是POW（Proof of Work，工作量证明），以太币使用的POS（Proof of Stake，股权证明）而EOS使用的是BFT-DPOS。

什么是BFT-DPOS呢？即拜占庭容错式的委任权益证明。

要想明白BFT-DPOS的运行机制，首先就要先明白什么是DPOS。

由于POW在比特币的共识算法中极大地消耗了算法的资源。而且会有算法集中的问题，所以在2014年的时候Dan Larimer提出了一个相较于POW来说更加高效，轻便的共识机制即DPOS。该共识机制一边能让网络成本小型化，另一方面有回复语每个持股人一定的投票权。

这些超级节点呢能够：供相关计算资源和网络资源，保证节点的正常运行;当轮到某超级节点拥有出块权时，超级节点收集该时段内的所有交易，并对交易验证后打包成区块广播至其他超级节点，其他节点验证后把区块添加到自己的数据库中。这种共识机制采用随机的见证人出块顺序，出块速度为 3 秒，交易不可逆需要45秒。为什么需要 45 秒呢？因为 DPoS 下，见证人生产一个新区块，才表示他对之前的整条区块链进行了确认，表明这个见证人认可目前的整条链。而一个交易要达到不可逆状态，需要 三分之二以上的见证人确认，在 EOS 里就是 14 个见证人。DPoS共识算法也有极强的抗分叉能力，因为区块添加到一条区块链分叉的速率与拥有该共识的超级节点比例是相关的。当一个超级节点设法在两条分叉上同时生产区块时，EOS的持有者会在下一轮投票中将该超级节点删掉，并且EOS社区会给予相关恶意节点一定的惩罚。因此，在一般情况下，使用DPoS的EOS都是很难经历分叉的。

其次，我们还要明白BFT所代表的的意义。

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

拜占庭容错技术来源于拜占庭将军问题。拜占庭将军问题是Leslie Lamport在20世纪80年代提出的一个假象问题。拜占庭是东罗马帝国的首都，由于时拜占庭罗马帝国国土辽阔，每支军队的驻地分隔很远，将军们只能靠信使传递消息发生战争时，将军们必须制订统一的行动计划。然而，这些将军中有叛徒，叛徒希望通过影响统一行动计划的制定与传播，破坏忠诚的将军们一致的行动计划。因此，将军们必须有一个预定的方法协议，使所有忠诚的将军能够达成一致，而且少数几个叛徒不能使忠诚的将军做出错误的计划。也就是说，拜占庭将军问题的实质就是要寻找一个方法，使得将军们能在一个有叛徒的非信任环境中建立对战斗计划的共识。在分布式系统中，特别是在区块链网络环境中，也和拜占庭将军的环境类似，有运行正常的服务器（类似忠诚的拜占庭将军），有故障的服务器还有破坏者的服务器（类似叛变的拜占庭将军）。共识算法的核心是在正常的节点间形成对网络状态的共识。

简单形容就是：通过在一群数量有限的节点中，使用轮换或者其他算法来筛选出某个节点作为主节点。并且赋予该节点出块的权利。在主节点是将该时段的交易打包成区块后用自己的私钥对该区块签名，并将其广播到所有节点。当主节点收到至少三分之二的不同节点的签名区块后，则该区块完成了所有节点的验证成为不可逆区块串联到区块链中。

BFT与DPOS二者相结合就诞生了BFT—DPOS共识算法。

、为了挖掘 EOS 系统的性能，Daniel Larimer 在以上基础上又进行了修改。首先，他将出块速度由 3 秒 缩短至 0.5 秒，理论上这样可以极大提升系统性能，但带来了网络延迟问题：0.5 秒的确认时间会导致下一个出块者还没有收到上一个出块者的区块，就该生产下一个区块了，那么下一个出块者会忽略上一个区块，导致区块链分叉（相同区块高度有两个区块）。比如：中国见证人后面可能就是美国见证人，中美网络延迟有时高达 300ms，很有可能到时美国见证人没有收到中国见证人的区块时，就该出块了，那么中国见证人的区块就会被略过。

为解决这个问题，Daniel Larimer 将原先的随机出块顺序改为由见证人商议后确定的出块顺序，这样网络连接延迟较低的见证人之间就可以相邻出块。比如：日本的见证人后面是中国的见证人，再后面是俄罗斯的见证人，再后面是英国的见证人，再后面是美国的见证人。这样可以大大降低见证人之间的网络延迟。使得 0.5 秒的出块速度有了理论上的可能。

为了保证万无一失，不让任何一个见证人因为网络延迟的意外而被跳过，Daniel Larimer 让每个见证人连续生产 6 个区块，也就是每个见证人还是负责 3 秒的区块生产，但是由最初的只生产 1 个变成生产 6 个。最恶劣的情况下，6 个区块中，最后一个或两个有可能因为网络延迟或其他意外被下一个见证人略过，但 6 个区块中的前几个会有足够的时间传递给下一个见证人。

再来讨论 BFT-DPoS 的交易确认时间问题：每个区块生产后立即进行全网广播，区块生产者一边等待 0.5 秒生产下一个区块，同时会接收其他见证人对于上一个区块的确认结果。新区块的生产和旧区块确认的接收同时进行。大部分的情况下，交易会在 1 秒之内确认（不可逆）。这其中包括了 0.5 秒的区块生产，和要求其他见证人确认的时间

使用上述BFT-DPoS协议就可以使得EOS的出块间隔从原来的3秒降低到500毫秒，这也使得跨链通信的时延大大缩短，单位时间内可确认的交易数量大大提升。笔者相信如果这样的机制在EOSIO1.0的正式版本中成功实现，那无疑是区块链技术向支持百万级别用户的目标迈出的巨大一步。

引用原文来自:金色财经
转载自：https://www.cxyzjd.com/article/ITleaks/80359033

Why VRF？

场景

在区块链场景中，有的框架会用算法随机产生出块节点与验证节点（如Algorand），甚至解决分叉。按传统的随机算法，按一定的哈希规则随机轮询，选出一个节点来记账/验证。如果这个随机轮询的规则是谁都可以复现的，那么可以推测出将来的某个记账/验证节点，集中攻击它。
为了解决这个问题，就引入了VRF，只有自己能够完成这个哈希过程，而别人只能在他声明之后验证这个过程，防止有人可以提前推测出将来的记账节点。

POS中的权益研磨（Grinding）

（以下来源于以太坊Github上的《Proof of Stake FAQ》）
在任何基于区块链的权益证明算法中，都需要某种机制，来随机从当前活跃验证者集合中选择能够产生下一个区块的验证者。举个例子，如果当前活跃的验证者集合由持有40以太币的Alice，持有30以太币的Bob，持有20以太币的Charlie与持有10以太币的David组成，那么你想让Alice成为下一个区块的创建者的概率为40%，而Bob的概率为30%等（在实践中，不仅要随机选择一个验证者，而是要（随机产生）一个无限验证者序列，只有这样如果Alice不在线的时候，就可以有其他人在过段时间替代她，但是这并没有改变问题的本质）。在非基于区块链的算法中，出于不同的原因也经常需要考虑随机性。
（以下来源Ouroboros白皮书《Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol》）
基于PoS的区块链协议最基本的一个问题就是模拟领导者选举过程。为了在股东们之间的选举达到一个真正的随机性，系统中就必须要引入熵(entropy)，但引入熵的机制可能会容易被敌手操作。例如，一个控制一群股东的敌手可能会试图模拟协议的执行，尝试不同的股东参与者的顺序以此来找到对敌对股东有力的继续者。这会导致一个叫做"grinding"的致命弱点，敌对参与者可能会使用计算资源来倾斜领导者选举。

VRF的目的

VRF的目的就是要生成随机值，且无法被预测，同时还要可验证，可重放。

VRF是什么?

VRF是可验证随机函数(verifiable random function)，一方面具有伪随机性，另一方面它还具有可验证性(输出包括一个非交互零知识证明)

• 伪随机性
• 可验证性
  VRF的方式是，实现本地抽签，各个节点自己抽签，如果抽中了之后，大家可以很容易地验证这个结果确实是你生成的。

eg. 假设现在是round 10（第10 轮），节点们可能会轮流抽签，以节点自己的私钥+ 一个全网都知道的随机数（比如是这轮的轮次10）作为输入，生成了一个随机数（0-100）；设置一个条件：100 个节点轮流抽签，谁先抽出来的随机数大于10，就是这一轮的打包者。假设5 号节点抽到了11，可是只有5 号知道其他人不知道，因此他在广播这个随机的同时还需要广播一个零知识证明。通过零知识证明，全网只需要通过5 号的公钥就可以验证，接受5 号为这轮打包者。图解如下：

VRF具体的操作流程？

• 证明者生成一对密钥，PK、SK；
• 证明者计算result = VRF_Hash（SK，info），proof = VRF_Proof（SK，info）；
• 证明者把result，proof，PK递交给验证者；
• 验证者计算result = VRF_P2H（proof)，True/False = VRF_Verify(PK, info, proof)

True表示验证通过，False表示验证未通过。所谓的验证通过，就是指proof是否是通过info生成的，通过proof是否可以计算出result，从而推导出info和result是否对应匹配、证明者给出的材料是否有问题。

抽签有没有必要用VRF？

相比随机预言机

1. 普通哈希Hash(a)=b，所有人都可以重现，检验正确性；
2. VRF是Hash(SIG(sk, a))=b，别人无法复现这个过程。但是可以拿b，pk，和中间信息验证b是跟a对应的。

   相比非对称加密

3. 在密码学签名算法中，大都会引入随机性，也就是对相同信息的多次签名会得到不同的签名值，因此矿工可以不断对相同的输入SK和block，计算签名，以满足结果小于D。那么理论上任何人都会成为出块者，只要计算足够多次的签名。
4. 有些非对称加密方式得到的随机数不是均匀分布的，如RSA
5. 缺乏零知识，不管使用确定性签名还是随机性签名，都存在个安全隐患。就是一旦将自己的出块凭证公布，任何人都可以公开验证，包括攻击者。那么攻击者可以对出块节点进行攻击，使其不能出块。使用VRFs的方式，矿工只需要公布自己的R表明自己的出块权，当出完块的时候再公布P，那么攻击者就无法在出块之前知道谁具有出块权，因此也就无法实施针对性的攻击。

应用

1. Consensus：共识算法中安全性
   VRF Sortition，Smart Contracts，例如本体，Cardano，Dfinity，Algorand等，不同点在于如何产生输入以及输出怎样用。VRF的返回结果可以用来公开或私密地完成节点或节点群体的选择。eg. Dfinity利用mod操作来唯一，公开的确定一个group。Algorand，Ouroboros Praos是私密选择，即计算出哈希值后，如果哈希值小于某个阈值，节点可以私密地知道自己被选中。
   

本体-VBFT共识算法：

1. 根据VRF 从共识网络中选择备选提案节点，各个备选节点将独立提出备选区块；
2. 根据VRF 从共识网络中选择多个验证节点，每个验证节点将从网络中收集备选的区块，进行验证，然后对最高优先级的备选区块进行投票；
3. 根据VRF 从共识网络中选择多个确认节点，对上述验证节点的投票结果进行统计验证，并确定出最终的共识结果。
4. 所有节点都将接收确认节点的共识结果，并在一轮共识确认后开启新的共识。

Algorand中：

1. 先选打包者，选完打包者选委员会，委员会用BA*进行选区块。
2. 输入值由前一个随机数(最初的随机数是协议给定的)和某种代表高度，轮次的变量进行组合，然后用私钥对之进行签名(或者先签名再组合)，最后哈希一下得出最新的随机数。
3. 条件：①签名算法应当具有唯一性；②避免在生成新随机数时将当前块的数据作为随机性来源之一。

Dfinity中：

交保证金提高门槛，并降低参与节点的数量，然后选打包者，选完打包者选公证人，对区块权重进行排序，选出区块。

Cardano的共识机制-Ouroboros Praos：

在根据Random seed选举slot leader时，通过VRF确保slot leader不被事先计算出来被攻击。

1. IOST的高效分布式分配片
   使用了VRF来进行领头节点的选举，通过VRF得到随机数之后，会将结果进行广播，然后其他节点会进行统计，得到随机数值最小的作为分片领头节点。是一种交互式的选举方式。
2. Key Transparency
   密钥管理系统，使消息传递在不相信服务端的情况下做到点对点的安全上的提升。
3. DNSSEC
   DNS服务的安全性。

参考文献

1. Randao可证公平随机数白皮书
2. 《一文看懂可验证随机函数VRF》
3. Ouroboros:一个可证明安全的PoS区块链协议 白皮书
4. Proof of Stake FAQ
5. 黄祺-区块链中VRF的应用及原理解析 视频资源
6. Cardano(ADA)的共识算法Ouroboros
7. 对可验证随机函数VRF的简明解释
8. VRF wiki
9. VRF原文
10. VRF在区块链中的应用

原文链接：https://blog.csdn.net/shangsongwww/article/details/88797403

由于在调研Algorand共识，所以最近阅读和测试相关的链实现，此篇将主要讲解kaleido的私链部署测试。
由于相关项目基本已经很久不更新，文档社区匮乏，只能阅读代码，反向推出运行参数和步骤。

编译源代码

参考《kaleido 编译与测试》，执行编译相关子程序

make all

最终kaleido\build\bin会生成genesis程序，下面会用到

genesis.json创建

启动私链，首先需要准备bios节点配置
阅读相关代码（github）
可以使用genesis程序进行生成，首次直接运行genesis后

Hint: You must make a minerkey before making genesis.

提示需要先生成minerkey，继续跟进
阅读相关代码（github）

    makeMinerKeyCommand = cli.Command{
        Action:    utils.MigrateFlags(makeMinerKey),
        Name:      "makeminerkey",
        Usage:     "Generates a miner key for mining",
        ArgsUsage: " ",
        Flags: []cli.Flag{
            utils.DataDirFlag,
            utils.MinerStakeOwnerFlag,
            utils.MinerKeyCoinbaseFlag,
            utils.MinerKeyStartFlag,
            utils.MinerKeyLifespanFlag,
        },
        Category: "MINER COMMANDS",
        Description: `
The makeMinerKey command generates a miner key for mining.
If the key already exists, just return it.

可以使用kalgo加上参数makeminerkey进行生成，参考有限文档例子如下

mkdir $PWD/data
export KALEIDO_HOME=$PWD/data
echo $KALEIDO_HOME

./kalgo makeminerkey \
--miner.stakeowner 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0 \
--minerkey.coinbase 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0 \
--minerkey.start 1

0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0修改为自己的地址
执行生成后，返回

MinerKey: 0x39fb25e90000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000006400000000000000000000000048f155527f25eb1d4cb2aa32b7e84692aa0025c003ada2cdce38f8fd0aafbaf5542a03a78b90b93ce594e0568760ba952e2b1f534566f9bde28e7b7d6ba8a369e0a4a6b419b12b86cb577c374cd257ef0a5a5645
Details:
    miner = 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0
    coinbase = 0x48F155527f25EB1d4cb2aa32b7e84692AA0025C0
    start = 1
    end = 1000000
    lifespan = 100
    vrfVerifier = 0x03ada2cdce38f8fd0aafbaf5542a03a78b90b93ce594e0568760ba952e2b1f53
    voteVerfier = 0x4566f9bde28e7b7d6ba8a369e0a4a6b419b12b86cb577c374cd257ef0a5a5645
GenesisStorage:
    0xf542409778bcdead44d9b45f4b07b70b047acb90dcda73c55b6b72088ca2fefd = 0x48f155527f25eb1d4cb2aa32b7e84692aa0025c0000000640000000000000001
    0xf542409778bcdead44d9b45f4b07b70b047acb90dcda73c55b6b72088ca2fefe = 0x03ada2cdce38f8fd0aafbaf5542a03a78b90b93ce594e0568760ba952e2b1f53
    0xf542409778bcdead44d9b45f4b07b70b047acb90dcda73c55b6b72088ca2feff = 0x4566f9bde28e7b7d6ba8a369e0a4a6b419b12b86cb577c374cd257ef0a5a5645

以上仅为测试数据，对于自己相关私有数据请注意保管

由于cmd/genesis/main.go和consensus/clique/clique.go已写死了0x0e09768B2B2e7aa534243f8bf9AFdC145DdA8EDa为测试数据，所以我们可以修改对应代码，也可以拿测试地址生成minerkey，然后生成genesis.json然后再手动修改对应的地址和数据。
切记替换地址时，（github）

contracts.MinerAddress: {
        Balance: common.Big0,
        Code:    common.FromHex(contracts.MinerBinRuntime),
        Storage: map[common.Hash]common.Hash{
            common.HexToHash("0x06ff3c55f357d4545a14dcc167670bf1dcc8bb45dcd90fa4a085a02a39da3a8a"): common.HexToHash("0x45ec182edc6774c9a2926172f1fd996e59b58ced000000640000000000000001"),
            common.HexToHash("0x06ff3c55f357d4545a14dcc167670bf1dcc8bb45dcd90fa4a085a02a39da3a8b"): common.HexToHash("0xf88a8d844c217531a38d6019ea671652340fe0d899996250bccce13af99933de"),
            common.HexToHash("0x06ff3c55f357d4545a14dcc167670bf1dcc8bb45dcd90fa4a085a02a39da3a8c"): common.HexToHash("0x6e8f4a7c7651766722dd7fb9d7a97cd28678a1cefb12631580a7ffe90a910b8f"),
        },
    },

Storage中的数据，要替换成上面执行kalgo makeminerkey返回的数据中的GenesisStorage对应的数据，不然检查不通过（github）会报bad signature

此时按照常规eth启动步骤执行即可，细节不再单独讲解

./kalgo --datadir ./data init genesis.json
./kalgo --config geth.toml  --nodiscover

./kalgo attach ipc:./data/geth.ipc

添加新节点

同上为新节点创建minerkey

mkdir $PWD/data
export KALEIDO_HOME=$PWD/data
echo $KALEIDO_HOME

./kalgo makeminerkey \
--miner.stakeowner 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa \
--minerkey.coinbase 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa \
--minerkey.start 1

返回

MinerKey: 0x39fb25e900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000064000000000000000000000000bb93fcc2bb90d46255c43dd398a1a372e12be6aa474d81ab830043ccdd099147b7b90f073d8b2bda52892d40e8601cfcfbb03a2e35c6ae655cecc87a4c977435e36c8d88ea2950e1cec425e42909b934adbc1de8
Details:
    miner = 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa
    coinbase = 0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa
    start = 1
    end = 1000000
    lifespan = 100
    vrfVerifier = 0x474d81ab830043ccdd099147b7b90f073d8b2bda52892d40e8601cfcfbb03a2e
    voteVerfier = 0x35c6ae655cecc87a4c977435e36c8d88ea2950e1cec425e42909b934adbc1de8
GenesisStorage:
    0x3a624f62c38b6bf3cf93859680439fb3332269b77ec12e8e022bf7be4a569857 = 0xbb93fcc2bb90d46255c43dd398a1a372e12be6aa000000640000000000000001
    0x3a624f62c38b6bf3cf93859680439fb3332269b77ec12e8e022bf7be4a569858 = 0x474d81ab830043ccdd099147b7b90f073d8b2bda52892d40e8601cfcfbb03a2e
    0x3a624f62c38b6bf3cf93859680439fb3332269b77ec12e8e022bf7be4a569859 = 0x35c6ae655cecc87a4c977435e36c8d88ea2950e1cec425e42909b934adbc1de8

mkdir -p ./data/kalgo/minerkeys
cp ~/.kaleido/kalgo/minerkeys/0xbb93FcC2bB90D46255c43DD398A1A372E12bE6Aa-0-1000000.bin ./data/kalgo/minerkeys

./kalgo makeminerkey \
--miner.stakeowner 0x10210572d6b4924Af7Ef946136295e9b209E1FA0 \
--minerkey.coinbase 0x10210572d6b4924Af7Ef946136295e9b209E1FA0 \
--minerkey.start 9500


mkdir -p ./data/kalgo/minerkeys
cp ~/.kaleido/kalgo/minerkeys/0x10210572d6b4924Af7Ef946136295e9b209E1FA0-0-1000000.bin ./data/kalgo/minerkeys


myaddr = '0x10210572d6b4924Af7Ef946136295e9b209E1FA0';
hash = eth.sendTransaction({
    from: myaddr, 
    to: '0x1000000000000000000000000000000000000002', 
    gas: 200000, 
    gasPrice: 20000000000, 
    data: 
'0x39fb25e9000000000000000000000000000000000000000000000000000000000000251c000000000000000000000000000000000000000000000000000000000000006400000000000000000000000010210572d6b4924af7ef946136295e9b209e1fa04141f8e905b628d3657b151a62c1414c4cc4f554d24bc16971c8233b761879d09b8f95e47a6f9662b78198c45ff986153c1e3316ede5cbfae09c6f927d374bd2'
});
admin.sleepBlocks(2);
eth.getTransactionReceipt(hash);


personal.importRawKey("8d91c6c7a494a4373...0715","j7OseEMVQ3Trna6gWdkp")
personal.unlockAccount("0x10210572d6b4924Af7Ef946136295e9b209E1FA0","j7OseEMVQ3Trna6gWdkp",0)



nohup ./kalgo --config geth.toml --networkid 1001 --unlock "0x10210572d6b4924Af7Ef946136295e9b209E1FA0" --password ./password --mine --miner.stakeowner "0x10210572d6b4924Af7Ef946136295e9b209E1FA0" --nodiscover --etherbase 0 --verbosity 4 2>> ./geth.log &

personal.unlockAccount("0xf8329ea42489c2164f44a81deb3be22c2c456109","j7OseEMVQ3Trna6gWdkp",0)
eth.sendTransaction({from: "0xf8329ea42489c2164f44a81deb3be22c2c456109", to: "0x10210572d6b4924Af7Ef946136295e9b209E1FA0", value: web3.toWei(25000000, 'ether')})


admin.addPeer("enode://e20d5cb1c726bb5f8bcc5c3b91255e7fcf459add7584cf6becbb99715f2f84334f14233843bb50ce68c71c4f1b6cfeaff3294cec85a488f363428476010651b1@172.31.204.223:32668?discport=0")
admin.addPeer("enode://95b41257c7da4bd0a98e81cb636b833c36693a3ab76ff55987663455b186dac96437d785b7bb6c5d5335bae91402f227d99a395c1dfe31663a891eb6e5d90140@172.31.204.224:32668?discport=0")



./kalgo --datadir ./data init genesis.json
./kalgo --config geth.toml  --nodiscover

./kalgo attach ipc:./data/geth.ipc

参考

https://docs.kaleidochain.io