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

go env -w GO111MODULE=auto

Besu 是一个 Apache 2.0 许可的、兼容 MainNet 的、用 Java 编写的以太坊客户端。
https://github.com/hyperledger/besu

由于在调研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

2018年是公链技术爆发的一年，诞生了诸多从共识方面创新的项目。由于目前人们普遍认为存在区块链“不可能三角”，这些共识往往要在性能、安全、去中心化、激励机制中做出取舍。例如，EOS达成每秒数千次交易速度是以牺牲去中心化为前提的。然而“不可能三角”从来没有像FLP、CAP这些分布式系统定理一样得到严谨的数学证明，因此有些人认为打破“不可能三角”是有可能的。可验证随机函数VRF被认为是一个有前景的方向。本次为大家带来最近热度非常高的Algorand项目的分析。

1、Algorand共识算法简介

Algorand共识算法是图灵奖获得者Silvio Micali在2017年底提出。Michali是MIT的教授，是一位密码学家和计算机理论学家，在伪随机数以及零知识证明领域很有名。
Algorand共识算法的论文的下载地址：https://people.csail.mit.edu/nickolai/papers/gilad-algorand.pdf

Algorand采用了VRF函数，并结合账户的余额比例，随机确定区块生成以及投票人角色。

所谓VRF（Verifiable Random Function）就是可验证随机函数。

随机数对于区块链技术来说很关键。 本质上，分布式账本的核心问题就是随机选择出块人的问题，这个随机性要能被全网确认，并且不能被操控，也不能被预测， 否则恶意节点通过操控这个随机数就可以操控长链，从而实现双花攻击。

PoW的方案是让大家进行算力竞赛，设置一个计算哈希的难题，谁先算出来谁赢，算力高的赢的概率高，算力低的赢的概率低，以这样的方式保证胜出者是随机的。投入的算力能够体现在哈希值上， 这样全网能够验证，并选择包含最多算力的那条链。恶意节点只能通过提升自己的算力来增加攻击成功的概率。

PoS的方案是选举，大家不用浪费电力去进行算力竞赛，而是文明一点，随机选举一个节点来出块，并且被选中的概率和它拥有的份额相关。 如果“随机”这一步没有问题的话，恶意节点只能通过增加自己的份额，增加自己被选中的概率，从而增加双花攻击的成功概率。 这里有一点比PoW的方案要好就是，要实现攻击，先得成为持币大户，如果攻击成功币价大跌，攻击者也会承受最大的损失。

那么接下来的核心问题就是，这个不能被操控不能被预测的随机数从哪来。传统地PoS方案尝试从链上现有的数据入手，比如使用上一个区块的哈希值，上一个区块的时间戳等等来作为随机数的来源，但这些会带来额外的安全风险。 因为区块本身的信息就是节点写进去的，然后又要根据里面的信息来选举后续的出块者，存在循环论证的嫌疑，安全性不会太好。 这也是传统地认为PoS方案不如PoW可靠的部分原因。

Algorand提出的VRF能够由私钥( SK )以及讯息( X )产生一组可验证的伪随机 (pseudorandom) 数Y以及证明 ⍴。任何人都可以透过Verify函数来检验这个随机字串是否真的是该公钥对应私钥持有者，依照规定使用Evaluate函数所产生，而不是自己乱掰的。更详细一点的VRF三个函示描述如下：

•Keygen(r) → (VK, SK). On a random input, the key generation algorithm produces a verification key VK and a secret key SK pair. •Evaluate(SK, X) → (Y, ⍴) . The evaluation algorithm takes as input the secret key SK , a message X and produces a pseudorandom output string Yand a proof ⍴ . •Verify(VK, X, Y, ⍴) → 0/1 . The verification algorithm takes as input the verification key VK , the message X , the output Y, and the proof ⍴ . It outputs 1 if and only if it verifies that Y is the output produced by the evaluation algorithm on inputs SK and X .

为什么我们需要这么一个大家自己产生，却又要可以被验证的随机字串产生器呢？这是因为在Algorand的拜占庭演算法中，虽然也存在着每一轮不同的区块生产者(称为Leader)以及验证委员会(Committee, Verifiers)，但并不是用「公开选举」的方式来选的，而是透过每个使用者自己对奖的方式来看看自己是不是下一轮的Leader。

algorand就是通过随机算法从一群大范围的验证者中选取一部分验证者运行BFT算法(Micali教授实现的BA*算法)，从而达到提高共识的效果。

无论是在何种BFT的共识机制中，都是由Leader以及Committee来完成区块的发布以及共识决议。例如EOS的dPoS BFT是固定21个BP轮流担任Leader以及投票者、Zilliqa透过PoW加入Committee进行PBFT共识算法。这些比较直观的拜占庭共识演算法都有一个共同特征，就是大家都可以看到下一个区块的Leader是谁，以及负责协议共识的Committee是谁。这造成了一个可能的风险，就是这些区块生产者以及Committee成员容易成为DDOS或是贿赂的目标。

Algorand为了解决这种潜在的风险，利用VRF来掩盖Leader Selection的步骤。可以想像成：一般的BFT在每一轮开始时公平公开选出Leader以及Committee，Algorand则是像在每一轮开始时公布中奖号码，每个使用者都可以自己拿自己的票根对奖，中奖的人即可成为下一轮的Leader(或是Committee Verifier)，但在中奖者自己表明身分前，没有人知道谁中奖，也就是没有人能预测下一轮的Leader以及Committee。当然中奖与否并不是口说无凭，中奖者需要出示中奖证明，而这个证明是大家都可以验证的，这正是我们刚刚说到的VRF。

2、Algorand共识算法缺陷

(1)现实环境的随机选择的空间并不大。

VRF是可以提供了公平且不容易收到伪造和攻击的委员会随机选择方式，但是任何随机数的生成必须依赖大的种子集合才可以有作用，在VRF中假设80%节点是诚实的，Committee需要2000个成员才够大，现实情况是不太可能有这么多成员的。

(2)完全没考虑网络延迟情况。

VRF Committee集合选举时依赖数量庞大的主机通讯的，主机之间相互沟通造成的延迟，必然大大拖慢整个系统的处理速度。

(3)没考虑节点的动态加入和退出情况。

Algorand的下一个区块的发布者是从k个区块之前的所有参与者（在k区块之前的某段链上发过交易的节点）里选。于是，恶意节点想影响下个区块的发布者，他得影响k个区块才行，当k很大的时候，这个影响也是微乎其微。于是，Algorand得到了一个无偏向的随机数产生器。不过，这个做法有一个问题——k区块之前的节点，有可能已经不在线了。而对于这一点，虽然Micali做出了解释，但是个人觉得并不符合实际情况。

(4)签名数据庞大，造成存储浪费并影响性能。

Algorand使用VRF来确定提案组与验证组，这个方式充分发挥了VRF的可验证性优势，且后验优势使得Algorand的共识体系更安全。但是，Algorand进入验证阶段，采用的是一种可扩展的拜占庭容错算法，即BA算法，参与节点通过VRF秘密抽签选出。这一设计使Algorand在验证前必须等待凭证（VRF prove）到来，才能知晓参与节点。而且，由于使用了可扩展的拜占庭容错算法，使得Algorand的验证组规模必须比较大(2000～4000人)，这将导致签名数据异常庞大。根据我们的估算，在平均每组3000个验证节点的规模下，每组的签名数据长达126KB，加上其它信息，通知信息约300K，每块的签名数据可达200064*12=1M（共12组，每组3000人，至少2/3达成共识。ed25519签名数据长度是64。），远超一般门限签名几十个字节，严重浪费存储和容量（因每块存储的交易量将被占用，不存储签名又会影响安全），不仅造成存储浪费，而且更影响性能。

(5)无法构建很好的激励机制

在POW中，提案者得到提案权需要预先付出算力成本，若其提案区块有问题（交易双花），则该提案区块在全网其他节点验证必将失败，从而不但没有铸块收益，还付出了算力成本。

Algorand协议并没有设计经济激励机制，Micali教授曾回应”Algorand协议只需要进行平凡的计算，因此不需要激励”。在没有经济激励机制下，高性能带宽和服务器必然不愿意参与（因为它本身要消耗费用），整个网络会遇到网络本身无法解决的困难。

(6)存在潜在的安全问题

网络用户必须连续访问其私钥，以确定其在每一轮中的VRF状态（即验证者、提议者，或者两者都不是）。

一般认为，对于那些将大量资产存储在区块链上的个人，为了防止攻击，他们应该把私钥以冷存储的方式进行保存。而持续的验证（需要经常签名）会需要高频率地动用私钥，从而增加被攻击的风险。这显然将导致网络中很多诚实的个体（出于安全的考虑）会避免参与验证过程，从而造成区块链缺乏活力的问题。

(7)买断问题

在区块链的婴儿期，系统的通证价值通常较低，其市值也是处在相对较低的水平。Token的发行往往要经过私募-->基石-->公募 等逐步分散的过程，因此很长一段时间里币是集中在少数人手里的，因此任何POS共识都面临着EOS类似的中心化的问题。

(8)没有惩罚问题

Algorand所存在的另一个问题是，没有办法识别“离线验证者”并惩罚它们。因此，在没有惩罚措施来防止无效的情况下，没有经济激励就是一个问题，很多人会选择不为共识做贡献，因此离开这个网络。假设网络中只有10%的诚信节点在不断地进行验证，而其余节点是离线的状态，与此同时，恶意的节点选择保持在线，那其就很容易超过在线委员会节点。这使得恶意节点更容易控制共识。

总的来说，Algorand的VRF和加密抽签后验性给出了一个解决“三角悖论”的很好设计思想，但其在验证环节的设计更偏单纯的学术化理想化，导致其对网络流量、有效通讯数据等实际工程落地思考不够，严重影响了公链运行性能、节点网络规模、账本存储容量和去中心化程度。
转载：https://www.8btc.com/article/348383