您正在查看: 2021年10月

VRF可验证随机函数

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

Besu 基于 Java 的企业级 Apache 2.0 许可以太坊客户端

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

kaleido chain 测试链部署

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

Algorand 共识算法

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