引领区块链隐私革命：Aleo 最新算法解读

Aleo 是一个专注于隐私保护的区块链项目，通过零知识证明技术（ZKP）实现更高的隐私和可扩展性。Aleo 的核心理念是让用户能够在不泄露个人数据的前提下进行身份验证和数据处理。

本文主要介绍了 Aleo 的项目概要及最新进展，对市场十分关心的 puzzle 算法更新做了详细的解读。

Leo 编译语言：基于 Rust 语言改编，专门用于开发零知识应用（ZKApps），降低了开发者对密码学知识的要求。

snarkVM 和 snarkOS：snarkVM 允许链下执行计算，链上仅验证计算结果，从而提升了效率。snarkOS 确保数据和计算的安全，并允许无许可的功能执行。

zkCloud：提供安全、私密的链下计算环境，支持用户、组织和 DAO 之间的编程交互。

Aleo 还提供了集成开发环境（IDE）和软件开发工具包（SDK），支持开发者快速编写和发布应用；此外，开发者可以在 Aleo 的程序注册表中部署应用，无需依赖第三方，如此便降低了平台风险。

区块快速最终性：AleoBFT 确保每个区块在生成后立即得到确认，提升了节点稳定性和用户体验。

去中心化保障：通过将区块生产与 coinbase 生成分离，验证者负责生成区块，证明者进行证明计算，防止少数实体垄断网络。

激励机制：验证者和证明者共享区块奖励；鼓励证明者通过质押代币成为验证者，从而提升网络的去中心化程度和计算能力。

Aleo 允许开发者创建不受 gas 限制的应用程序，因此尤其适用于机器学习等需要长时间运行的应用。

ARC-100 投票通过：ARC-100 （“Aleo 开发人员和运营商的合规最佳实践”提案，涉及合规方面、Aleo 网络上资金的锁定和延时到帐等安全措施） 的投票已经结束，并获得通过。团队正在进行最终的调整。

验证者激励计划：该计划将于 7 月 1 日启动，旨在验证新的 puzzle 机制。计划将运行至 7 月 15 日，期间将分配 100 万 Aleo 积分作为奖励。节点生成的积分百分比将决定其奖励份额，每个验证者至少需赚取 100 代币才能获得奖励。具体细则尚未敲定。

初始供应和流通供应：初始供应量为 15 亿代币，初始流通供应量约为 10% （尚未最终确定）。这些代币主要来自 Coinbase 任务（7500 万），将在前六个月内分发，同时包括质押、运行验证者和验证节点的奖励。

Testnet Beta 重置：这是最后一次网络重置，完成后将不会添加新功能，网络将与主网类似。重置是为了添加 ARC-41 和新 puzzle 功能。

代码冻结：代码冻结已于一周前完成。

验证节点扩展计划：初始验证节点数量为 15 个，目标是在年内增加到 50 个，并最终达到 500 个。成为委托者需要 1 万代币，成为验证者需要 1000 万代币，这些数额将随着时间逐渐减少。

puzzle spec 和代码后，对最新算法做一个简单介绍。

Prover 计算 puzzle 构建出 solutions 并广播到网络中

Validator 聚合交易和 solution 为下一个新区块，保证 solution 数量不超出共识限制（MAX_SOLUTIONS）

Solution 的合法性需要校验其 epoch_hash 符合 validator 维护的 latest_epoch_hash，其计算出的 proof_target 符合网络中 valiator 维护的 latest_proof_target，同时该 block 中包含的 solution 数量小于共识限制

有效的 solution 可以获得共识奖励

1. 每一次 puzzle 计算称为 nonce，它是由接收挖矿奖励的地址、epoch_hash 和 一个随机数 counter 构建，每次需要计算新的 solution 时可以通过更新 counter 获得新的 nonce

• 将所有指令组成 EpochProgram

3. 使用 nonce 作为随机数种子生成 EpochProgram 的输入

4. 聚合 EpochProgram 对应的 R 1 CS 和 input，进行 witness （R 1 CS assignment） 计算

5. 计算出所有 witness 后，这些 witness 将被转换为对应的 merkle tree 的叶子节点序列，merkle tree 是一个深度为 8 的 8 元 K-ary Merkle tree

6. 计算 merkle root 并将其转换为 solution 的 proof_target，判断其是否满足当前 epoch 的 latest_proof_target，若满足则计算成功，提交上文中构建输入需要的 reward address、epoch_hash 和 counter 作为 solution 并广播

7. 同一个 epoch 中可通过迭代 counter 的方式更新 EpochProgram 的输入进行多次 solution 计算

挖矿的变化和影响

经过此次更新后，puzzle 由生成 proof 转变为生成 witness，每一个 epoch 内的所有 solution 计算逻辑一致但是不同 epoch 计算逻辑有较大区别。

从之前的测试网中我们可以发现很多优化手段着重于使用 GPU 对生成 proof 阶段的 MSM 和 NTT 计算进行优化从而提高挖矿效率，此次更新完全摒弃了这部分计算；同时由于生成 witness 的过程产生于执行一个跟随 epoch 变化的 program，其中的指令将存在部分串行执行的依赖关系，所以实现并行化具有不小的挑战。