最先进的抗ASIC工作量证明：RandomX

标准工作量证明

在经典PoW算法（如比特币使用的hashcash）中，核心通常是密码学哈希函数，其中唯一变量是函数输入数据。为实现目标"难度"，需要哈希输出前缀包含特定数量的零比特。每增加一个零比特，挖矿难度翻倍。然而，这类算法极易通过ASIC和GPU加速，因为所有输入执行固定操作集且内存需求有限，这并非理想状态。

为何关注抗ASIC特性？

理想情况下，区块链挖矿应是高度去中心化的任务，没有单一实体控制大部分算力。区块链易受51%攻击，恶意多数可覆盖全局状态（如允许双花）。如果ASIC能比通用CPU显著提升挖矿效率，经济因素将削弱CPU挖矿动力。比特币网络即是例证：ASIC制造商建立大型矿场，少数实体控制惊人比例的算力。

过去几年，ASIC制造商展现出快速设计和制造能力。希望抗ASIC的项目（在不转向权益证明模型的前提下）必须利用通用CPU相对于假设ASIC的特定优势。这一需求催生大量抗ASIC研究，RandomX代表了最新抗ASIC思想在加密货币中的具体实现。

RandomX工作原理

RandomX核心是随机化执行概念，即执行随机指令序列以利用通用CPU的动态代码执行灵活性。算法简化流程如下：

步骤1

使用输入密钥K通过argon2d创建称为Cache的数据结构。Argon2d是内存硬密码哈希函数，计算机通常拥有大容量快速内存，但ASIC内存成本高昂。要求大量内存是对抗专用硬件的常见防御手段。

步骤2

从Cache扩展数据集（只读内存结构）。数据集设计为大量内存段，包含虚拟机将读取的数据。两个参数控制数据集大小（RANDOMX_DATASET_BASE_SIZE和RANDOMX_DATASET_EXTRA_SIZE），共同限定算法所需内存上限。额外尺寸用于将内存推至略超2的幂边界，增加ASIC制造难度。

步骤3

通过对输入数据执行blake2哈希初始化暂存器（读写内存），结果输出用于初始化AesGenerator。该生成器使用AES-NI指令填充暂存器。初始暂存器生成使用AES变换，现代CPU已硬件加速此算法，ASIC无优势。暂存器本身是（相对）大型读写数据结构，专为适配CPU缓存设计。

步骤4

算法核心：在虚拟机上运行随机程序。VM通过随机字节生成器构建程序执行。RandomX虚拟机架构经精心设计，允许任何8字节序列作为有效指令。这些指令设计用于：

• 需要双精度浮点运算
• 使用128位向量数学
• 使用所有四种IEEE 754浮点舍入模式
• 读写专为完全适配CPU缓存的暂存器
• 通过低概率分支指令利用分支预测
• 利用CPU的超标量和乱序执行能力

程序执行后VM状态经哈希处理生成新程序。此循环次数可配置（默认8次），防止ASIC矿工仅实现操作子集或运行"简单"程序。

步骤5

最后使用AesHash哈希暂存器和寄存器文件（VM寄存器），后接最终blake2哈希。此步骤除使用AES指令外无显著抗ASIC优势，主要用于输出64字节最终哈希值。

审计发现

在两人周审计中发现三个问题（两个低严重性，一个信息性）：

AesGenerator使用单轮AES

RandomX规范描述的AES加密指单轮AES，不足以完全混合输入数据。RandomX不依赖AES加密保证安全，而是将其作为偏向CPU的快速变换提供输出扩散。但比特扩散取决于AES轮数。此问题严重性"低"，因需在算法几乎每一步发现额外偏差，并构造能传播该偏差的输入。

披露后，RandomX团队开发执行四轮的新AesGenerator4R函数，并通过PR 46合并至代码库。

VM正确性测试与验证不足

RandomX代码库缺乏验证虚拟机语义的测试覆盖。审计投入一半时间（一人周）评估算法实现的安全属性，虽发现若干代码质量问题，但不足以验证VM无语义错误。此问题严重性"低"，因只要满足：(1)输出确定性、(2)输出密码学随机、(3)参考实现是区块链挖矿唯一实现，RandomX正确性即无关紧要。但规范与实现间任何差异可能导致共识问题和链分叉。

可配置参数脆弱性

RandomX包含47个可配置参数，包括并行化标志、内存消耗、初始KDF迭代次数、数据集内存大小、虚拟CPU三级缓存大小、VM程序大小和迭代次数及缓存访问/延迟。默认参数为最大化CPU优势选择，但51%攻击威胁迫使其他区块链需不同参数选择，这些选择缺乏明确指导可能损害算法优势。此脆弱性可能阻碍第三方采用。

披露后，RandomX团队移除部分不必要参数，编写关于安全更改配置值的额外指南，并添加禁止不安全配置的新检查集。

评估深度

区块链行业存在"多次小规模审计优于单次大规模审计"的观点，认为不同团队会以不同方式和专业知识覆盖更多问题。但我们认为大规模单一评估为客户提供更好整体价值。客户支付评估团队获取专家意见，但如同新员工需要时间熟悉代码库。初始学习期结束后，评估质量和深度迅速提升。许多大规模长期代码评估直到项目后期才揭示最关键发现。

软件保证原则在Dave Aitel的《黑客策略》演讲中得到充分体现：研究人员发现漏洞的质量与时间投入强相关。一小时仅能发现极浅层问题，一周显著加深，一月可发现他人难以发现的漏洞。

《零日，千夜》——基于数十位专家访谈的漏洞研究权威参考——进一步讨论：查找漏洞的方法影响实际发现结果。例如新研究声称模糊测试仅发现漏洞冰山一角（Kirda等）。新开发或代码库简单产品可通过模糊测试发现漏洞，而生命周期长、复杂度高、市场份额大或高收入产品需更深入审计、逻辑审查和源代码分析。

例如手动验证RandomX VM正确性（我们发现的最严重问题）就需要数人周。即使完成所有四次审计，也无法保证VM实现无语义错误。同样，在审计期内分析RandomX各函数密码强度可行，但探索潜在偏差跨步骤传播方法需更深入工作。小规模审计禁止此类工作，偏向浅层结果。

当前项目状态

我们的两人周审计是RandomX团队计划的多轮评审之首。接下来数周项目将接受三次额外小规模审计，结果应于本月晚些时候发布。待审计发布且RandomX作者解决所有发现后，Arweave和Monero计划在预定协议升级中采用该算法。

（原文包含的社交媒体分享提示及页脚信息已省略）