校对 8017

finalized 从“已最终化”改为“最终确认”

translations/8017.md

@@ -5,7 +5,7 @@
     
 ## 什么是区块哈希？
 
-要理解什么是区块哈希，你必须了解什么是槽和区块。
+要理解什么是区块哈希，你必须了解什么是槽（slot）和区块。
 
 * 槽是验证者可以生成区块的时间段
 * 区块是验证者处理的交易和元数据的集合。每个区块中的元数据将其链接到前一个区块，从而创建一个链。
@@ -14,11 +14,11 @@
 
 好的，那么什么是区块哈希？区块哈希是在一个槽期间创建的所有区块链账目的唯一哈希值。 [这是从区块的最后条目 ID 计算的](https://solana.com/docs/terminology#blockhash) 。每个生成的区块结果都是一个独特的区块哈希。这些区块哈希被用作时间戳。
 
-### 索拉纳的承诺级别是什么？
+### Solana 的承诺级别是什么？
 
-另一个重要的概念是[承诺级别](https://docs.solanalabs.com/consensus/commitments) 。这些承诺级别衡量了特定区块的网络确认。三个选项是已处理、已确认和已最终化。
+另一个重要的概念是[承诺级别](https://docs.solanalabs.com/consensus/commitments) 。这些承诺级别衡量了特定区块的网络确认。三个选项是已处理（processed）、已确认（confirmed）和最终确任（finalized）。
 
-当验证者向链提交一个区块时，该区块将处于已处理状态。一旦足够数量的验证者（[66%的验证者](https://docs.solanalabs.com/consensus/commitments) ）投票以包含该区块，它将被添加到链中，承诺级别将变为已确认。一旦在该区块之上构建了额外的 31 个区块，承诺级别将变为已最终化。
+当验证者向链提交一个区块时，该区块将处于已处理状态。一旦足够数量的验证者（[66%的验证者](https://docs.solanalabs.com/consensus/commitments) ）投票以包含该区块，它将被添加到链中，承诺级别将变为已确认。一旦在该区块之上构建了额外的 31 个区块，承诺级别将变为最终确任。
 
 ![](https://img.learnblockchain.cn/attachments/migrate/1714094086351)
 
@@ -36,21 +36,21 @@
 
 导致“未找到区块哈希错误”的另一种情况是，交易的区块哈希比用于检查该交易过期的区块哈希更新。这有点令人困惑，这里有一个例子：你创建一个交易并包含一个特定区块的区块哈希，比如说区块 1000，然后立即将其发送到 RPC，RPC 可能会获取前一个区块的区块哈希，这种情况下可能是区块 999（因为 RPC 使用更高的承诺级别或者 RPC 节点落后于网络）。结果，交易中的区块哈希将无法找到。这种情况可能发生在两种情况下：
 
-1. 当创建交易时，使用了已确认的承诺级别，但当 RPC 计算其有效性时，默认使用已最终化的承诺级别。这可能导致区块哈希比交易的区块哈希旧，因为已最终化的区块比最新的区块“滞后”了 31 个区块。
+1. 当创建交易时，使用了已确认的承诺级别，但当 RPC 计算其有效性时，默认使用最终确任的承诺级别。这可能导致区块哈希比交易的区块哈希旧，因为最终确任的区块比最新的区块“滞后”了 31 个区块。
     1. 如果使用已处理的承诺级别来获取在最终上被删除的少数分叉上的交易的区块哈希，那么该区块哈希将无效，并且在处理过程中找不到。
-2. 如果用于获取区块哈希和发送交易的两个不同的 RPC，那么发送交易的 RPC 经历的任何延迟可能导致用于检查有效性的区块比创建交易时使用的区块旧。
+2. 如果用于获取区块哈希和发送交易的是两个不同的 RPC，那么发送交易的 RPC 经历的任何延迟可能导致用于检查有效性的区块比创建交易时使用的区块旧。
 
 ## 如何处理区块哈希错误
 
 处理上述每种情况的几个步骤。
 
 1. 确保提交的交易包含一个不太旧的区块哈希
-    * 在获取交易的区块哈希时使用“**已确认**”承诺级别，这可以确保包含比“**已最终化**”承诺级别更新的区块哈希。
-    * 也可以使用“**已处理**”承诺级别获取稍微更近的区块哈希，但[大约 5%的已处理区块](https://solana.com/docs/core/transactions/fees#fee-determinism)在集群中尚未最终化。这意味着交易的区块哈希将属于一个被删除的分叉，不再有效。
+    * 在获取交易的区块哈希时使用“**已确认**”承诺级别，这可以确保包含比“**最终确任**”承诺级别更新的区块哈希。
+    * 也可以使用“**已处理**”承诺级别获取稍微更近的区块哈希，但[大约 5%的已处理区块](https://solana.com/docs/core/transactions/fees#fee-determinism)在集群中尚未最终确任。这意味着交易的区块哈希将属于一个被删除的分叉，不再有效。
 2. 确保交易的区块哈希不比用于检查交易有效性的区块哈希更新
-    * 始终将**preflightCommitment**（即使使用 skipPreflight）设置为用于获取交易区块哈希的相同承诺级别。这将帮助你避免交易的区块哈希比用于检查交易有效性的区块哈希更新。
+    * 始终将 **preflightCommitment**（即使使用 skipPreflight）设置为用于获取交易区块哈希的相同承诺级别。这将帮助你避免交易的区块哈希比用于检查交易有效性的区块哈希更新。
     * 在发送交易时处理滞后的 RPC 节点时，应该保持定期重新发送交易到 RPC。这可以在一定间隔内完成，以便如果 RPC 滞后，它最终会赶上并检测到交易的过期。
-        * 如果使用 simulateTransaction 请求，则应设置**replaceRecentBlockhash**参数。此标志指示 RPC 将模拟交易的区块哈希替换为始终对模拟有效的区块哈希。
+        * 如果使用 simulateTransaction 请求，则应设置 **replaceRecentBlockhash** 参数。此标志指示 RPC 将模拟交易的区块哈希替换为始终对模拟有效的区块哈希。
 3. 在区块哈希有效时继续重试交易
     * 当创建交易并获取最新的区块哈希时，应记录该区块哈希的 lastValidBlockHeight。然后，你可以继续使用该区块哈希重试交易，直到当前区块高度超过交易的有效区块高度。可以使用 getBlockHeight RPC 调用持续检查交易是否仍然有效。一旦当前区块高度高于交易的 lastValidBlock 高度，应获取并使用新的区块哈希。希望这篇博客文章能帮助你更好地理解区块哈希错误以及如何减少这些错误发生的次数。如果你有任何进一步的问题，请随时加入我们的 [Discord 社区](https://discord.com/invite/6GXdee3gBj)或在 X 上直接发送私信。
 
@@ -62,4 +62,4 @@
 
 ‍
 
-> 本文由 AI 翻译，欢迎小伙伴们来[校对](https://github.com/lbc-team/Pioneer/blob/master/translations/8017.md)。
+> 本文由 AI 翻译，欢迎小伙伴们来[校对](https://github.com/lbc-team/Pioneer/blob/master/translations/8017.md)。