Zcash共识升级提案缩短出块间隔并优化隐私交易规则

ZIP: 未分配 Title: 更短的区块目标间隔 Owners: ValarDragon <dojha@berkeley.edu> Status: Draft Category: Consensus Created: 2026-03-13 License: MIT Discussions-To: <https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577>

术语

本文档中的关键词 “MUST”、“MUST NOT”、“SHOULD” 和 “MAY” 在且仅在它们以全大写形式出现时，按 BCP 14 [^BCP14] 中的描述进行解释。

术语 “block chain”、“consensus rule change”、“consensus branch” 和 “network upgrade” 按 ZIP 200 中的定义进行解释。 [^zip-0200]

术语 “block target spacing” 指的是在给定 consensus branch 中，难度调整算法所针对的区块之间的时间间隔。它通常以秒为单位测量。（这有时也称为 “target block time”，但 “block target spacing” 是 Zcash Protocol Specification [^protocol-diffadjustment] 中使用的术语。）

字符 § 用于指代 Zcash Protocol Specification 的各个章节。 [^protocol]

术语 “Mainnet” 和 “Testnet” 按 § 3.12 ‘Mainnet and Testnet’ 中的描述进行解释。[^protocol-networks]

摘要

本提案规定在 NU7 中将 block target spacing 从 75 秒改为 25 秒，并为 Sapling 和 Orchard shielded protocols 引入每池 action 限制。

这解决了三个问题。

• 显著改善需要 1 或 2 个 conf's 的参与者的 UX。（Near Intents，小额支付）用户延迟降低 3 倍。
• 增加 consensus 带宽，这会放大未来不需要 shielded sync 的 shielded pool 的扩展影响。
• 引入 action 限制，短期内使 Orchard TPS 增加一倍以上（2.9 → 6.1 TPS），同时将攻击者对钱包 shielded sync 可施加的 DoS 影响降低 42%（270.5 → 156.83 MB/day）。

action 限制会显著减少每个区块可用的 Sprout 和 Sapling pool outputs 数量，以降低在尝试 DoS 时的最大 shielded sync 负担。

挖矿获得的 ZEC 的发行计划在 ZEC/day 的意义上将保持不变， 但这要求按区块的发行量根据变化后的 block target spacing 进行调整。

动机

降低 block target spacing 的动机包括：

• 降低交易延迟。 目前，无论网络利用率如何，用户即使只等待一次确认，平均也必须等待 75 秒。这给收银支付、交易所充值和跨链桥操作带来了摩擦。将目标间隔缩短到 25 秒后，首次确认的预期等待时间平均降至 25 秒。

• 提高吞吐量。 由于每天的区块数增加 3 倍，而区块大小上限仍为 2 MB，我们将分配到更高的 consensus 带宽容量。短期内，配合 action 限制，我们将使 2-action 交易的 Orchard TPS 增加一倍以上。长期来看，当我们获得一个没有 shielded sync 负担的 shielded pool 时，我们将拥有 3 倍更高的吞吐量。

• 与最终性改进互补。 本提案与 Crosslink [^crosslink] 等最终性机制是互补的，并不与之竞争。更快的区块时间会提升底层层的响应性，无论是否同时部署额外的最终性 gadget。

单独来看，吞吐量目标也可以通过提高区块大小来实现。 然而，本提案的主要目标首先是改善交易 延迟。

据估计，这种 blocktime 的减少会使 stale rate 从当前的 0.4% 上升到 1.3%。作为参考，以太坊在运行期间的 stale rate 为 5.4%。

回滚攻击有多种 threat models。粗略地说， 在保持区块传播延迟显著更低的同时降低区块时间，有助于改善最终性时间。这是因为更多诚实矿工会迅速在该区块上继续构建，而区块传播约束确保 stale rate 没有显著增加。关于各种攻击模型的分析，见 [^slowfastblocks]。由于本提案满足保持 stale rate 较低的约束，在 “X% of hashpower is byzantine” threat model 下，用户确认时间应能提升接近 3 倍略低一些。 在“Economic” threat model 下，用户要求建立在其支付之上的区块奖励超过支付价值时，这会显著改善确认延迟的方差。（但由于 stale rate，平均延迟会稍高一些）如那里所指出的，这种攻击模型不会应用于大额交易。它只可能应用于小额交易，而实际上区块时间的粒度可能会降低达到足够最终性所需的时间。除本 ZIP 中现有的 1-2 次确认用户外，我们并不主张减少墙钟时间上的区块确认次数。不过，我们确实预计，许多类用户在对其今天所选择的内容进行一致的 threat modeling 下，能够降低他们自己的墙钟时间。

然而，Zcash 独特地还存在第二个扩展成本，即 shielded sync。每一笔 shielded 交易都会给每个钱包带来带宽开销，并额外增加一次 trial decryption，因此我们必须仔细了解攻击者可能造成的影响。今天，最坏情况下的 DoS 攻击会导致客户端每天下载 270.5 MB 的钱包同步数据，并且每天执行 4.8M 次 trial decrypts。我们提议在 Orchard 中引入 action 限制（每区块 306 个 action），以及在 Sapling 中引入（输入+输出）限制（每区块 300 个）。有了这些限制，最坏情况将变为每天 156.83 MB 带宽和 2.1M 次 trial decrypts。 尽管区块数量增加 3 倍，但这使最坏情况下的钱包同步带宽改善了 42%。 这带来了 Orchard TPS 2 倍提升，并使 Sapling TPS 保持在高于当前 Orchard TPS 的水平。

不过，每个钱包确实都必须下载每个 compact block header， 其大小为 90 字节。作为改善 UX 的交换，这会给钱包带来每天额外约 200kb 的带宽。

降低 Sapling 和 Sprout 的每区块限制，是由当前 shielded funds 在各 pool 间的分布所证明合理的。截至 2026 年 3 月：

绝大多数 shielded 活动已经在 Orchard 中进行，并且这一趋势预计将持续。Sapling 和 Sprout 的限制相对于它们当前的使用量设置得很宽裕，同时大幅降低了它们被用于 DoS 滥用的潜力。

Stale block rate

stale rate 是被孤立的区块百分比，它与挖矿中心化风险、区块传播延迟以及区块验证时间有关。今天 stale rate 为 0.4%，但由于矿池中的 hashpower 集中，这可能低于纯粹由区块传播延迟所暗示的水平。

在 25 秒的 block target spacing 下，基于理论模型，预计的 stale（孤立）区块率约为 1.3%，或者基于对 Zcash 网络传播延迟进行显著四舍五入后的估计，约为 3.9%。这两个数字都远低于以太坊在其 proof-of-work 期间历史上的 5.4% stale rate。[^forum-proposal]

（TODO：完善上述数字并扩展说明。1.3% 是通过一个非常直接的方法得出的，即使用当前 uncle rate 和区块时间作为 poisson process 来估计传播延迟。3.9% 则来自观察当前 EU 和 US 节点之间的 p90 区块传播时间为 700ms，然后将其四舍五入为 1s。这还需要结合在区块已满时测得的延迟，不过很难看出这如何会接近 2s。）

@evan-forbes 正在进行实验，以在不同网络和硬件配置下进一步展示区块传播延迟。

Block processing time

缩短区块时间的一个前提是，区块验证和传播相对于目标间隔仍然保持较小。本提案引入的每池 action 限制确保最坏情况下的区块处理时间按每个区块计算比今天更低。consensus 带宽的增加，以及 Orchard TPS 的增加，确实意味着 full node sync 的总耗时会增加。我们接受这一权衡（TODO：用时间增加做出具体说明，并指出更多 CPU cores 可以解决这一点）

当前最坏情况： 今天，一个完整的 2 MB 区块最多可包含约 617 个 Orchard actions 或约 2,090 个 Sapling outputs，并且没有每池限制。一个完全填满的 Orchard 区块需要验证所有这些约 617 个 action 的 proof 和 spend authorization signatures。

提议的最坏情况： 采用 action 限制后，一个区块最多包含 306 个 Orchard actions 或 300 个 Sapling IOs。这大约是当前 Orchard 最坏情况的一半，而只是 Sapling 最坏情况的一小部分。因此，每区块的验证工作量会显著降低。

Batch verification。 Orchard 交易验证受益于 batch validation，在这种方式下，proof 和 signature 验证会分摊到多个交易上。在当前节点实现中，Orchard 交易会以最多 64 笔交易为一组进行 batch verification （每笔最坏情况为 2 个 action）。Zebra 自 3.0.0 版本起就在 live network syncing 期间执行 batch verification。借助 action 限制，一个最坏情况下区块的 Orchard bundle 可以在少量 batch 中完成完全的 batch-verified。

估计时间。 在一台典型的 4 核机器上，最坏情况下的 full block verification（包括所有 shielded components 的 proof verification）预计在 action 限制下的一个区块上低于 500ms。（TODO：用易于引用的 benchmark 进行细化） 当交易在进入 mempool 时已经预先完成验证，这在节点已经在线的典型情况下很常见，那么 block validation 就只需检查 signatures 和 state updates，这会更便宜。

规范

本节中描述的更改，应在 Zcash Protocol Specification [^protocol] 中进行，并相对于本提案激活时的规范版本。

共识变更

Block target spacing

在 § 2 ‘Notation’ 中，将 $\mathsf{NU7ActivationHeight}$ 和 $\mathsf{PostNU7PoWTargetSpacing}$ 添加到整数常量列表中。

在 § 5.3 ‘Constants’ 中，定义：

$$\mathsf{PostNU7PoWTargetSpacing} := 25 \text{ seconds}$$

对于给定网络（production 或 test），将 $\mathsf{NU7ActivationHeight}$ 定义为该 network upgrade 在该网络上激活时的高度，如单独的 deployment ZIP 中所指定。

定义：

$$\mathsf{NU7PoWTargetSpacingRatio} := \mathsf{PostBlossomPoWTargetSpacing} ;/; \mathsf{PostNU7PoWTargetSpacing} = 3$$

定义 $\mathsf{IsNU7Activated}(\mathsf{height})$ 为：如果 $\mathsf{height} \geq \mathsf{NU7ActivationHeight}$，则返回 true； 否则返回 false。

在 § 7.7.3 ‘Difficulty adjustment’ 中，将 $\mathsf{PoWTargetSpacing}$ 重定义为：

$$ \mathsf{PoWTargetSpacing}(\mathsf{height}) := \begin{cases} \mathsf{PreBlossomPoWTargetSpacing}, &\text{如果 } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ 不成立} \ \mathsf{PostBlossomPoWTargetSpacing}, &\text{如果 } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ 成立且 } \mathsf{IsNU7Activated}(\mathsf{height}) \text{ 不成立} \ \mathsf{PostNU7PoWTargetSpacing} &\text{否则} \end{cases} $$

Halving interval and block subsidy

定义：

$$\mathsf{PostNU7HalvingInterval} := \lfloor \mathsf{PostBlossomHalvingInterval} \cdot \mathsf{NU7PoWTargetSpacingRatio} \rfloor = 5{,}040{,}000$$

将 $\mathsf{Halving}$ 函数重定义为：

$$ \mathsf{Halving}(\mathsf{height}) := \begin{cases} \left\lfloor \dfrac{\mathsf{height} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} \right\rfloor, &\text{如果 } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ 不成立} \ \left\lfloor \dfrac{\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} + \dfrac{\mathsf{height} - \mathsf{BlossomActivationHeight}}{\mathsf{PostBlossomHalvingInterval}} \right\rfloor, &\text{如果 } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ 成立且 } \mathsf{IsNU7Activated}(\mathsf{height}) \text{ 不成立} \ \left\lfloor \dfrac{\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} + \dfrac{\mathsf{NU7ActivationHeight} - \mathsf{BlossomActivationHeight}}{\mathsf{PostBlossomHalvingInterval}} + \dfrac{\mathsf{height} - \mathsf{NU7ActivationHeight}}{\mathsf{PostNU7HalvingInterval}} \right\rfloor, &\text{否则} \end{cases} $$

将 $\mathsf{BlockSubsidy}$ 重定义为为激活后高度添加一个分支：

$$ \mathsf{BlockSubsidy}(\mathsf{height}) := \begin{cases} \ldots &\text{（先前的分支保持不变）} \ \left\lfloor \dfrac{\mathsf{MaxBlockSubsidy}}{\mathsf{BlossomPoWTargetSpacingRatio} \cdot \mathsf{NU7PoWTargetSpacingRatio} \cdot 2^{\mathsf{Halving}(\mathsf{height})}} \right\rfloor, &\text{如果 } \mathsf{IsNU7Activated}(\mathsf{height}) \end{cases} $$

这会将按区块计算的补贴相对于 post-Blossom 补贴再除以 3， 从而使按墙钟时间单位计算的总发行量保持不变。

注意：当前 post-Blossom 的区块补贴 1.5625 ZEC 不能被 3 整除。post-NU7 补贴为 $\lfloor 156250000 / 6 \rfloor = 26041666$ zatoshi（0.26041666 ZEC）， 每个区块因舍入损失约 0.33 zatoshi。以 5,040,000 个区块的完整 halving interval 计算，总未支付发行量不到 0.017 ZEC， 可忽略不计。如果 NSM ZIP 中的任何一项被接受，这一差额可以记入 NSM， 否则它将只是从供应中少铸造出来。

Shielded pool action limits

在 § 5.3 ‘Constants’ 中定义以下常量：

$$\mathsf{GlobalShieldedBudget} := 306$$ $$\mathsf{OrchardBlockActionLimit} := 306$$ $$\mathsf{SaplingBlockIOLimit} := 300$$ $$\mathsf{SproutBlockJoinSplitLimit} := 25$$

对于每个高度为 $\mathsf{height}$ 且 $\mathsf{IsNU7Activated}(\mathsf{height})$ 的区块，必须满足以下限制：

每池限制：

• 区块中所有交易的 Orchard actions 总数 MUST NOT exceed $\mathsf{OrchardBlockActionLimit}$。也就是说， $\sum_{\mathit{tx} \in \mathit{block}} \mathit{nActionsOrchard}(\mathit{tx}) \leq 306$。

• 区块中所有交易的 Sapling inputs 和 outputs 总数 MUST NOT exceed $\mathsf{SaplingBlockIOLimit}$。也就是说， $\sum_{\mathit{tx} \in \mathit{block}} (\mathit{nSpendsSapling}(\mathit{tx}) + \mathit{nOutputsSapling}(\mathit{tx})) \leq 300$。

• 区块中所有交易的 Sprout JoinSplits 总数 MUST NOT exceed $\mathsf{SproutBlockJoinSplitLimit}$。也就是说， $\sum_{\mathit{tx} \in \mathit{block}} \mathit{nJoinSplit}(\mathit{tx}) \leq 25$。

全局 shielded 预算：

除了每池限制之外，区块中所有 pool 的 shielded 总成本 MUST NOT exceed $\mathsf{GlobalShieldedBudget}$。 区块的 shielded 成本定义为：

$$\sum_{\mathit{tx}} \mathit{nActionsOrchard}(\mathit{tx}) ;+; \sum_{\mathit{tx}} (\mathit{nSpendsSapling}(\mathit{tx}) + \mathit{nOutputsSapling}(\mathit{tx})) ;+; 2 \times \sum_{\mathit{tx}} \mathit{nJoinSplit}(\mathit{tx}) ;\leq; 306$$

其中 Sprout JoinSplits 的系数 2 反映了每个 JoinSplit 会产生 2 个 shielded outputs。

这一全局预算确保无论使用哪种 pool 组合，每个区块的最坏情况 shielded sync 带宽都受到上限约束。 如果某个区块的 Orchard actions 达到 306 的上限，则不允许包含任何 Sapling 或 Sprout shielded outputs。如果同时使用多个 pool，它们的合并成本必须保持在预算之内。

这些限制不适用于交易的 transparent components。 总体 2 MB 的区块大小限制仍与以往一样适用。

每个 action 的 compact sync 带宽

上述限制旨在约束轻量钱包进行 shielded sync 时必须下载的最坏情况带宽。 用于同步的 compact 表示形式具有如下每个 note 的成本：

Orchard： 每个 action 148 字节，由以下部分组成：

Sapling： 每个 spend（input）32 字节，每个 output 116 字节，由以下部分组成：

在这些限制下，每个区块的最坏情况 compact sync 带宽为：

• Orchard: $306 \times 148 = 45{,}288$ bytes
• Sapling: 至多 $300 \times 116 = 34{,}800$ bytes（全为 output 的病理情况）

由于全局 shielded 预算的存在，这些不能叠加：如果一个区块使用了 306 个 Orchard actions，则不会剩余任何给 Sapling 或 Sprout 使用的预算。因此，每个区块的最坏情况 compact sync 带宽始终受 Orchard 情况限制，为 45,288 bytes。

完整的每日带宽分析见 Rationale 章节。

对 difficulty adjustment 的影响

与 Blossom 激活 [^zip-0208] 一样，difficulty adjustment 参数 $\mathsf{PoWAveragingWindow}$ 和 $\mathsf{PoWMedianBlockSpan}$ 指的是区块数量，并且在激活时不会改变。 $\mathsf{PoWTargetSpacing}$ 的有效值变化会导致区块间隔按常规的 difficulty adjustment 速率调整到新的目标。

很可能激活后的前几个区块的 difficulty adjustment 会受 $\mathsf{PoWMaxAdjustDown}$ 限制。 预计这不会造成任何问题。

Testnet 上的最小难度区块

在 Testnet 上，ZIP 205 [^zip-0205] 中定义并由 ZIP 208 [^zip-0208] 修改的最小难度区块阈值继续使用 $6 \cdot \mathsf{PoWTargetSpacing}(\mathsf{height})$ 秒。 激活后，该阈值变为 $6 \times 25 = 150$ 秒。

Non-consensus node behaviour

默认 expiry delta

当未被 -txexpirydelta 选项覆盖时，创建交易的节点实现会使用默认 expiry delta。 当前默认值为 40 个区块（在 75 秒间隔下约为 50 分钟），在激活后 SHOULD change to $\mathsf{NU7PoWTargetSpacingRatio} \times 40 = 120$ 个区块，以保持约 50 分钟的过期时间。

如果设置了 -txexpirydelta 选项，则所设置的值在激活前后都 SHOULD be used。

基于区块数量的常量

以下以区块数量计量的常量已经审查。若这些常量表示时间持续长度，实施 SHOULD 按 $\mathsf{NU7PoWTargetSpacingRatio}$ 进行缩放：

Anchor selection depth

ZIP 213 [^zip-0213] 建议在构建 shielded 交易时，从链尖回溯 10 个区块选择一个 anchor。 推荐的 anchor 深度在激活后 SHOULD remain at 10 blocks，从而将墙钟时间上的 anchor 延迟从约 12.5 分钟降至约 4.2 分钟。 这遵循了 Blossom 升级（ZIP 208 [^zip-0208]）所设定的先例，该升级在不改变 10 区块深度的情况下，将 anchor 延迟从约 25 分钟减半至约 12.5 分钟。

理由

Shielded sync bandwidth analysis

每池的区块空间限制被选定为，使轻量钱包同步的最坏情况每日带宽相对于当前协议不会增加。本节给出分析。

参数

Orchard pool：

Sapling pool：

每日带宽比较

最坏情况下的 compact sync 带宽为 156.83 MB/day，相较于今天约 270.5 MB/day 的最坏情况，减少了 42%。 尽管区块频率和总体吞吐能力增加了 3 倍，但依然如此。

约束条件由每区块 306 个 action 的 Orchard 决定： $306 \times 148 \times 3{,}456 + 90 \times 3{,}456 = 156.83\text{ MB/day}$。

trial decryption 的数量也会显著下降，因为每区块的 action 限制足以抵消区块数量 3 倍的增加。

注意，trial decrypt count 是 shielded outputs/actions 数量的 2 倍，因为钱包必须使用内部和外部 incoming viewing keys (IVKs) 都尝试解密。内部 IVK 会检测发送回钱包的找零输出，而外部 IVK 会检测外部传入支付。原则上，如果采取其他同步权衡，钱包可以避免使用其 IVK 进行 trial decrypts，但当前的 Sapling 和 Orchard 钱包总是会同时尝试两者。

正常交易吞吐量

对于标准的 2-action Orchard 交易，306 的 action 限制 允许每区块 $\lfloor 306 / 2 \rfloor = 153$ 笔交易，从而得到：

$$\mathsf{orchard_tps} = 153 ;/; 25 = 6.12 \text{ TPS}$$

作为比较，当前协议（75s 区块，受区块大小限制） 对 2-action Orchard 交易支持约 2.9 TPS。这样一来，正常 Orchard 吞吐量提升了 2.1×。

Sapling throughput. 对于标准 Sapling 交易（2 spends + 2 outputs = 4 IOs），300 IOs 的限制允许每区块 $\lfloor 300 / 4 \rfloor = 75$ 笔交易，从而得到 $75 / 25 = 3.0$ TPS。即使在 降低后的 Sapling 限制下，post-NU7 的 Sapling TPS（3.0）仍然 高于当前 pre-NU7 的 Orchard TPS（2.9）。

Fee incentives and DoS resistance

关于每池限制的一个担忧是，DoS 攻击者可能会填满 Sapling 或 Sprout 预算，从而排挤 Orchard 交易（或反之亦然）。 全局 shielded 预算确保这不会比填满任何单个 pool 更糟， 但仍值得 بررسی fee incentives 是否会造成不对称。

在 ZIP 317 [^zip-0317] 下，常规费用基于 logical actions：每个 Sapling output 或 spend 计为一个 logical action，而 每个 Orchard action 也计为一个 logical action。每个 logical action 的边际费用在不同 pool 之间相同。因此，攻击者通过用 Sapling 而不是 Orchard 进行垃圾填充（或反之）不会获得费用优势。单位 shielded budget 消耗的成本是相同的。

此外，由于全局 shielded 预算是共享的，填满 Sapling 预算必然会以同样的数量减少 Orchard 预算。一个攻击者如果把全部预算都花在 Sapling 垃圾填充上，达到 300 IOs，那么该区块只会剩下 6 个 Orchard actions 可用。但 这种攻击并不比直接填满 306 个 Orchard actions 更便宜，因为每个 action 的费用相同。全局预算确保每区块的总 shielded sync 成本无论攻击者选择哪个 pool，都会被限制在 306 个单位。

Orchard 的每池上限 306 也保证了，当未使用 Sapling 和 Sprout 时，合法的 Orchard 交易始终可以获得完整的 Orchard 预算，这也是未来预期中的常见情况。

部署

如果 tokenholder 投票和开发者共识同意，本提案拟作为 NU7 的一部分部署。另一个 ZIP 将指定部署细节，包括 激活高度和 consensus branch IDs。

参考

[^BCP14]: Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"

[^protocol]: Zcash Protocol Specification, Version 2025.6.3 or later

[^protocol-networks]: Zcash Protocol Specification, Version 2025.6.3. Section 3.12: Mainnet and Testnet

[^protocol-constants]: Zcash Protocol Specification, Version 2025.6.3. Section 5.3: Constants

[^protocol-diffadjustment]: Zcash Protocol Specification, Version 2025.6.3. Section 7.7.3: Difficulty adjustment

[^protocol-txnencoding]: Zcash Protocol Specification, Version 2025.6.3. Section 7.1: Transaction Encoding and Consensus

[^zip-0200]: ZIP 200: Network Upgrade Mechanism

[^zip-0205]: ZIP 205: Deployment of the Sapling Network Upgrade

[^zip-0206]: ZIP 206: Deployment of the Blossom Network Upgrade

[^zip-0208]: ZIP 208: Shorter Block Target Spacing

[^zip-0213]: ZIP 213: Shielded Coinbase

[^zip-0315]: ZIP 315: Best Practices for Wallet Implementations

[^zip-0317]: ZIP 317: Proportional Transfer Fee Mechanism

[^crosslink]: Crosslink — a Zcash Finality Protocol

[^slowfastblocks]: On Slow and Fast Block Times

[^forum-proposal]: 论坛：提案 — 将 Zcash 区块目标间隔降低到 25 秒

• 原文链接： github.com/valargroup/zi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～