作者： Gerry Wang

原文首发于：Arweave Oasis 推特

近期，Arweave 在区块高度 1391330 时进行了硬分叉，将共识机制升级为了 2.7.2 版本。这个版本有哪些更新呢？这篇文章为你详细解读。

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

1. 协作挖矿（Coordinated Mining ）

协作挖矿是一个可以让多个节点使用同一个挖矿地址进行挖矿，而不用担心会丢失区块奖励和被列入黑名单的挖矿模式。当矿工没有使用这种模式时，如果两个节点在同一个高度用同样的挖矿地址发布区块，将被视为违规，这不仅会让矿工损失挖矿收益，还会让该挖矿地址进入到黑名单中。所以这使得每个存储了 Weave 不同子集的多个节点能够获得更多双数据块解决（two-chunk solutions）方案的算力优势。

你可能对这里出现的双数据块解决方案（two-chunk solutions）有些疑惑，这是什么？

根据此前笔者在白皮书系列解读文章中解释的，每个 VDF（可以理解成每秒钟），矿工每秒每个分区最多有 2 次尝试找到成功挖矿解决方案的机会。这里我们姑且将每次尝试称为 Attempt。其中第一次 Attempt 是在矿工存储的分区中随机找到一个数据块进行 Hash；当矿工有了这个第一次 Attempt 的 Hash 之后，再用它在所有 Weave 分区中找到第二个随机数据块，并对其进行 Hash 来完成第二次 Attempt。如果矿工在第二次 Attempt 中找到了解决方案，那说明他们通过两个数据块（chunks）来完成挖矿，所以称其为 two-chunk solutions。

在 2.7.2 版本中，共识机制将第一次 Attempt 的难度大大增加，让矿工找到 one-chunk solution 变得非常困难，这样矿工就必须进行第二次 Attempt，大致比例为 100 个 two-chunk solutions 才能有一次 one-chunk solution 的机会。这样做的目的是激励矿工去尽可能多地存储 Weave 分区。而在新更新的协作挖矿模式下，就允许矿工在没有存所有 weave 的情况下，可以通过与其他矿工的合作来达到最大化的挖矿效率。

基础系统

在协作挖矿模式中有两个角色：

1. 出口节点
2. 矿工

集群中的所有节点共享同一个挖矿地址。每个矿工为他们存储的分区产生 H1 哈希。有时，他们需要的 H2 哈希是落在他们没有存储的分区中。在这种情况下，他们可以在协作挖矿集群中找到存储了相应分区的矿工，并将 H1 发送给他们，让其计算出 H2。当一个有效的解决方案被找到后（ one-chunk 或 two-chunk ），这个解决方案会被发送到出口节点（Exit node）。由于出口节点是协作挖矿集群中唯一没有被 Slash 风险，并且可以发布区块的节点。出口节点也是唯一存储了这个挖矿地址私钥的节点（因此只有出口节点可以对区块进行签名）。

协调挖矿集群中的每个节点都可以像平常一样与网络上的任何其他节点进行对等连接。

单矿工 One-Chunk 流程

Note：Miner1 存储了足够多的分区，让其可以同时获得 H1 与 H2。

协作 Two-Chunk 的流程

配置

1. 在协作挖矿集群中的所有节点必须配置 coordinated_mining 参数。
2. 在协作挖矿集群中的所有节点必须通过 cm_api_secret 配置相同的 secret 参数。它可以是任意长度的字符串。
3. 在协作挖矿集群中的所有矿工应该使用 cm_peer 参数来标识所有集群中的其它矿工。 Note：出口节点也可以选择性地进行挖矿，在这种情况下，它也被认为是一个矿工，应该由 cm_peer 参数标识。
4. 所有矿工（不包括出口节点）应该使用 cm_exit_peer 参数来标识出口节点。
5. 在协作挖矿集群中的所有节点可以正常配置，但他们都应该指定同一个挖矿地址 mining_addr。

还有两个额外的参数可用于调整性能：

• cm_out_batch_timeout：以毫秒为单位发送协作挖矿设置中其他节点的一批 H1 值的频率。较高的值可以减少网络流量，较低的值可以减少哈希延迟。默认值为 20。
• cm_in_batch_timeout：以毫秒为单位处理从对等节点接收到的 H1 批次的频率。较高的值可以减少冗余磁盘读取，较低的值可以减少哈希延迟。默认值为 20。

在早期的测试中，200 到 300 可能是许多挖矿设置中一个很好的折衷方案。但对于特定的挖矿集群配置与硬件中，最佳值可能会有很大的变化。

2. 矿池挖矿的本地支持

目前，Arweave 节点对矿池挖矿有内置的支持。

新的与矿池挖矿有关的参数：

• is_pool_server
• is_pool_client
• pool_api_key
• pool_server_address

3. 挖矿性能优化

新版本实施了几项优化和错误修复，以使更多的矿工能够实现最大哈希率。

更新摘要：

• 增加挖矿过程中使用的水平分布程度，以消除在更高的分区计数下的性能瓶颈
• 优化 Erlang 虚拟机的内存分配、管理和垃圾回收
• 修复了在更高的分区计数下可能出现的几个内存不足错误
• 修复了一个可能导致有效数据块在进行哈希之前被丢弃的错误

更新后的挖矿性能报告：

其中：

• H1 Solutions / H2 Solutions 指的是挖矿解决方案被找到的类型的计数，显示的是在 H1 哈希下找到的还是 H2 哈希下找到数量的计数。
• Confirmed Blocks 显示了这个节点挖到的区块的数量计数。
• Cur 值指的是最近的值（如，过去 10 秒的平均值）。
• Avg 值指的是全部的平均值。
• Ideal 指的是在给定 VDF 速度和当前打包的数据量的情况下的最佳速率。
• % of Max 指的是给定分区(或整个 Weave)被打包了多少。

4. 协议变更

2.7.2 硬分叉在区块 1391330 进行，其激活以下协议变更：

• one-chunk solution 的难度增加 100 倍，以更好地激励完整的 Weave 副本存储；
• 额外的定价过渡阶段计划于 2024 年 11 月开始；
• 实施每 GB/分钟 340 Winston 的定价上限，直到 11 月的定价过渡；
• 将检查点（checkpoint）深度从 50 个区块减少到 18 个；
• 为防止低影响的垃圾邮件攻击，提前拒绝不必要的 poa2 块。即使在最坏的情况下，此攻击对区块链的膨胀影响也很小，因此并不是一个实际的漏洞利用。关闭此向量是出于良好卫生习惯的考虑。

更多细节可以参考相关文档： https://github.com/ArweaveTeam/arweave/releases/tag/N.2.7.2

关于 PermaDAO：Website | Twitter | Telegram | Discord| Medium | Youtube