内容简介:对于近期备受争议的ProgPoW算法,独立开发者kikx在今日披露了该算法存在的一个漏洞,这使其无法真正实现抗ASIC的目标,kikx还补充表示,这一漏洞是新发现的,并且不会对以太坊当前使用的Ethash算法造成威胁。对此,以太坊研发人员Philippe Castonguay评论称:“看起来ProgPoW的当前实现,可能并没有那么抗ASIC,基本上,ProgPoW哈希函数使用了一个64位种子,ASIC可以“轻松”地强制执行,而不是像预期的那样进行挖矿。这需要更多的关注来正式确认。”
对于近期备受争议的ProgPoW算法,独立开发者kikx在今日披露了该算法存在的一个漏洞,这使其无法真正实现抗ASIC的目标,kikx还补充表示,这一漏洞是新发现的,并且不会对以太坊当前使用的Ethash算法造成威胁。
对此,以太坊研发人员Philippe Castonguay评论称:
“看起来ProgPoW的当前实现,可能并没有那么抗ASIC,基本上,ProgPoW哈希函数使用了一个64位种子,ASIC可以“轻松”地强制执行,而不是像预期的那样进行挖矿。这需要更多的关注来正式确认。”
此后,以太坊硬分叉协调员James Hancock对这一漏洞的存在进行了确认,随后表示了感谢。那这一漏洞到底是肿么一回事呢?
我们来看看kikx披露的细节吧:
ProgPoW的设计漏洞
ProgPow存在一个设计缺陷:
64位 seed
太小了,这允许ASIC无需存储访问即可计算哈希。
初步实现
感谢chfast提供了可读的实现!
ProgPoW 哈希函数被定义为:
result hash(const epoch_context& context, int block_number, const hash256& header_hash, uint64_t nonce) noexcept { const uint64_t seed = keccak_progpow_64(header_hash, nonce); const hash256 mix_hash = hash_mix(context, block_number, seed, calculate_dataset_item_2048); const hash256 final_hash = keccak_progpow_256(header_hash, seed, mix_hash); return {final_hash, mix_hash}; }
ASIC友好计算
假设给出了一个区块头block_header
以及一个区块数
block_number
。
然后,执行以下3个步骤:
- 将
seed
固定为任何64位值,然后计算mix_hash = hash_mix(block_number, seed)
; - 搜索
extra_nonce
,以便header_hash
满足难度条件; - 搜索
nonce
,以便keccak_progpow_64(header_hash, nonce) == seed
;
seed
和
block_number
计算
mix_hash
。由于
mix_hash
被设计为
seed
和
block_number
的函数,所以我们得到一个有效的三元组
(seed,mix_hash,block_number)
。现在,我们的目标是找到满足以下两个条件的
header_hash
和
nonce
:
keccak_progpow_64(header_hash, nonce) == seed keccak_progpow_256(header_hash, seed, mix_hash) <= boundary
(header_hash, seed, mix_hash, block_number)
,但
nonce
是自由的。 最后,步骤3扫描
nonce
以查找条件(A)。由于
seed
只有64位长度,所以条件(A)仅提供64位安全性,并且可以由ASIC执行步骤3。
计算成本
有四个函数,keccak_1600
,
keccak_progpow_64
,
hash_mix
以及
keccak_progpow_256
。成本的计算,可通过计算所需函数的调用来实现,这取决于网络难度
D
。
在正常的哈希计算中,需要一个 keccak_1600
调用,才能从 block_header
计算出 header_hash
,并针对每个 nonce
值依次调用其他函数。
而在ASIC哈希计算中,在步骤1中需要一个 hash_mix
调用,在步骤2中则要调用 keccak_1600
和 keccak_progpow_256
,在步骤3中将调用 keccak_progpow_64
。
由于 hash_mix
在我们的ASIC计算中仅被调用一次,因此我们可以使用主机CPU来计算 hash_mix
。而其它函数都是keccak哈希函数,不需要memory存储,并且可以在ASIC上轻松计算。
我们需要比较 keccak_progpow_64
row中的 D
和 2^64
。简单地说,更大的 D
会使ASIC更有利可图。估计阈值门槛是困难的,但我认为目前的难度 (> 2^50)是足够大的。
Demo
演示位于此存储库中。
$ git clone https://github.com/kik/progpow-exploit.git $ cd progpow-exploit $ mkdir build $ cd build $ cmake .. $ make $ ./test/ethash-test --gtest_filter=asic.search
在此演示中,seed被截断为24位宽度,以便在CPU上运行。参见代码。
测试代码是简单的。
这里定义了search_asic
由于这一漏洞的存在,以太坊矿机商们是不是可以松一口气了?
以上所述就是小编给大家介绍的《ProgPoW算法被曝漏洞,以太坊ASIC挖矿已不可阻挡?》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 使用 Envoy 和 AdGuard Home 阻挡烦人的广告
- 2020 年 Go 语言盘点:新冠大流行阻挡不了 Go 演进的步伐
- 通俗易懂--决策树算法、随机森林算法讲解(算法+案例)
- 限流算法之漏桶算法、令牌桶算法
- 什么是Paxos算法?Paxos算法是区块链核心算法之一
- 一文读懂对称加密算法、非对称加密算法和Hash算法
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
人人都是架构师:分布式系统架构落地与瓶颈突破
高翔龙 / 电子工业出版社 / 2017-5 / 69
《人人都是架构师:分布式系统架构落地与瓶颈突破》并没有过多渲染系统架构的理论知识,而是切切实实站在开发一线角度,为各位读者诠释了大型网站在架构演变过程中出现一系列技术难题时的解决方案。《人人都是架构师:分布式系统架构落地与瓶颈突破》首先从分布式服务案例开始介绍,重点为大家讲解了大规模服务化场景下企业应该如何实施服务治理;然后在大流量限流/消峰案例中,笔者为大家讲解了应该如何有效地对流量实施管制,避......一起来看看 《人人都是架构师:分布式系统架构落地与瓶颈突破》 这本书的介绍吧!