i18n(zh-tw): automated Crowdin translation import (part 03 of 13)

public/content/translations/zh-tw/developers/docs/consensus-mechanisms/poa/index.md

@@ -1,6 +1,6 @@
 ---
-title: 權威證明 (PoA)
-description: 解釋權威證明共識協定及其在區塊鏈生態系統中的作用。
+title: "權威證明 (PoA)"
+description: "解釋權威證明共識協定及其在區塊鏈生態系統中的作用。"
 lang: zh-tw
 ---
 
@@ -77,3 +77,4 @@ lang: zh-tw
 
 - [工作量證明](/developers/docs/consensus-mechanisms/pow/)
 - [權益證明](/developers/docs/consensus-mechanisms/pos/)
+

public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/attestations/index.md

@@ -1,42 +1,42 @@
 ---
-title: 證明
-description: 關於在權益證明以太坊上進行證明的描述。
+title: "證明"
+description: "關於在權益證明以太坊上進行證明的描述。"
 lang: zh-tw
 ---
 
 驗證者需要在每個時期建立、簽署和廣播證明。 本頁概述這些證明是什麼樣的，以及它們是如何處理和如何在共識用戶端之間交流的。
 
 ## 什麼是證明？ {#what-is-an-attestation}
 
-每個[時期](/glossary/#epoch)（6.4 分鐘）驗證者都會向網路提交一個證明。 這個證明針對時期內的一個特定時隙。 證明的目的是投票贊成驗證者對於鏈的看法，特別是最近的合理區塊和當前時期內的第一個區塊（稱為`來源`和`目標`檢查點）。 所有參與的驗證者的資訊都會合併，使得網路可以達成關於區塊鏈狀態的共識。
+每個[時期](/glossary/#epoch)（6.4 分鐘），驗證者都會向網路提交一項證明。 這個證明針對時期內的一個特定時隙。 證明的目的是投票贊成驗證者對鏈的看法，特別是最近的合理區塊和當前時期內的第一個區塊（稱為`來源`和`目標`檢查點）。 所有參與的驗證者的資訊都會合併，使得網路可以達成關於區塊鏈狀態的共識。
 
 證明包含以下組成部分：
 
-- `aggregation_bits`：驗證者的位元列表，其位置對應到委員會中的驗證者索引；(0/1) 數值表示驗證者是否簽署了 `data`（即，他們是否活躍和同意區塊提議者）
-- `data`：與證明相關的細節，如下方的定義
-- `signature`：彙總了個人驗證者簽署的 Boneh-Lynn-Shacham 簽章
+- `aggregation_bits`：驗證者的位元列表，其位置對應於委員會中的驗證者索引；值 (0/1) 表示驗證者是否簽署了 `data` (亦即他們是否處於活躍狀態並同意區塊提議者)。
+- `data`：與證明相關的詳細資訊，定義如下
+- `signature`：彙總了個別驗證者簽章的 BLS 簽章。
 
 證明驗證者的第一個任務是建置 `data`。 `data` 包含以下資訊：
 
-- `slot`：證明參考的時隙號碼
-- `index`：一個數字，用來辨識驗證者在給定的時隙中所屬的委員會
-- `beacon_block_root`：驗證者在鏈頭看到的區塊的根雜湊（套用分叉選擇演算法的結果）
-- `source`：最終確定性投票的一部分，表示驗證者認為的最新的合理區塊
-- `target`：最終確定性投票的一部分，表示驗證者認為的當前時段的第一個區塊
+- `slot`：證明所參考的時隙號碼
+- `index`：一個數字，用來識別驗證者在特定時隙中隸屬哪個委員會
+- `beacon_block_root`：驗證者在鏈首所見區塊的根雜湊 (套用分叉選擇演算法的結果)
+- `source`：最終性投票的一部分，指出驗證者所見最近的合理區塊
+- `target`：最終性投票的一部分，指出驗證者所見當前時期的第一個區塊
 
-一旦 `data` 建置完成，驗證者就可以將 `aggregation_bits` 中對應於他們自己的驗證者索引的位元從 0 翻轉到 1，表示他們已經參與。
+一旦 `data` 建置完成，驗證者就可以將 `aggregation_bits` 中對應於自身驗證者索引的位元從 0 翻轉為 1，以表示他們已參與。
 
 最終，驗證者簽署證明並且在網路上進行廣播。
 
-### 彙總的證明 {#aggregated-attestation}
+### 彙總證明 {#aggregated-attestation}
 
-每個驗證者在網路上傳遞此資料時，都會產生大量的相關開銷。 因此，個人驗證者在更廣泛的廣播前，先會在子網內彙總。 這包括將簽章彙總在一起，以讓廣播出去的證明包含共識 `data` 及一個單一簽章，此為所有同意該 `data` 的驗證者之簽章合併而成的簽章。 這可以透過 `aggregation_bits` 來檢查，因為它提供了每個驗證者在其委員會（委員會 ID 在 `data` 中提供）中的索引，可用於查詢個人簽章。
+每個驗證者在網路上傳遞此資料時，都會產生大量的相關開銷。 因此，個人驗證者在更廣泛的廣播前，先會在子網內彙總。 這包括將簽章彙總在一起，讓廣播的證明包含共識 `data` 及由所有同意該 `data` 的驗證者簽章組合而成的單一簽章。 這可以透過 `aggregation_bits` 來檢查，因為它提供了每個驗證者在其委員會中的索引 (其 ID 在 `data` 中提供)，可用於查詢個人簽章。
 
-在每個時期，每個子網中都會選出 16 個驗證者來擔任`聚合者`。 聚合者會收集它在廣播網路中監聽到的與其自身 `data` 相同的所有證明。 每個符合證明的發送者會被記錄在 `aggregation_bits` 中。 然後，聚合者將彙總證明廣播到更廣泛的網路。
+在每個時期，每個子網中會選出 16 個驗證者來擔任`聚合者`。 聚合者會從 gossip 網路上收集與其自身 `data` 等效的所有證明。 每個相符證明的發送者都會記錄在 `aggregation_bits` 中。 然後，聚合者將彙總證明廣播到更廣泛的網路。
 
 當驗證者被選為區塊提議者時，它們會將最新時隙來自子網的彙總證明打包到新區塊中。
 
-### 證明包含生命週期 {#attestation-inclusion-lifecycle}
+### 證明納入生命週期 {#attestation-inclusion-lifecycle}
 
 1. 產生
 2. 傳播
@@ -46,9 +46,9 @@ lang: zh-tw
 
 證明的生命週期如下圖所示：
 
-![證明的生命週期](./attestation_schematic.png)
+![證明生命週期](./attestation_schematic.png)
 
-## 酬勞 {#rewards}
+## 獎勵 {#rewards}
 
 驗證者提交證明可以獲得獎勵。 證明的獎勵依參與標記（來源、目標和頭部）、基礎獎勵和參與率而定。
 
@@ -60,33 +60,33 @@ lang: zh-tw
 
 標記證明率是透過特定標記的「所有證明驗證者的有效餘額總和」與「總活躍有效餘額」的比較來計算的。
 
-### 基礎獎勵 {#base-reward}
+### 基本酬勞 {#base-reward}
 
 基礎獎勵是根據參與證明的驗證者數量及其質押的有效以太幣餘額計算的：
 
-`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)`
+`基本酬勞 = 驗證者有效餘額 x 2^6 / SQRT(所有活躍驗證者的有效餘額)`
 
 #### 納入延遲 {#inclusion-delay}
 
-當驗證者在鏈頭 (`block n`) 上投票時，`block n+1` 尚未提議。 所以，證明自然會在**經過一個區塊之後**被納入區塊，因此所有在作為鏈頭的 `block n` 上投票的證明都會在 `block n+1` 被納入，**納入延遲**爲 1。 若納入延遲加倍至 2 個時隙，則證明的獎勵會減半，這是因爲證明獎勵的計算方式爲基礎獎勵乘以納入延遲的倒數。
+當驗證者對鏈首 (`block n`) 投票時，`block n+1` 尚未提出。 因此，證明自然會**晚一個區塊**被納入，所有對 `block n` 為鏈首投票的證明都會被納入 `block n+1`，而**納入延遲**是 1。 若納入延遲加倍至 2 個時隙，則證明的獎勵會減半，這是因爲證明獎勵的計算方式爲基礎獎勵乘以納入延遲的倒數。
 
-### 證明場景 {#attestation-scenarios}
+### 證明情境 {#attestation-scenarios}
 
-#### 缺少參加投票的驗證者 {#missing-voting-validator}
+#### 投票驗證者缺席 {#missing-voting-validator}
 
 驗證者最多有一個時期能夠提交他們的證明。 若錯過了在時期 0 時提交證明的機會，則它們可在時期 1 時提交（經過一個納入延遲）。
 
-#### 缺少聚合者 {#missing-aggregator}
+#### 聚合者缺席 {#missing-aggregator}
 
-每個時期總共有 16 個聚合者。 此外，驗證者會隨機訂閱**兩個子網路並持續 256 個時期**，並在缺少聚合者時作為備用。
+每個時期總共有 16 個聚合者。 此外，隨機的驗證者會訂閱**兩個子網路長達 256 個時期**，並在聚合者缺席時充當備援。
 
-#### 缺少區塊提議者 {#missing-block-proposer}
+#### 區塊提議者缺席 {#missing-block-proposer}
 
-值得注意的是，在一些情況下幸運的聚合者可能同時被選為區塊提議者。 若因為區塊提議者消失而導致證明未被納入，則下個區塊提議者會取得已彙總的證明並納入下一個區塊。 但是，**納入延遲**會因此增加 1。
+值得注意的是，在一些情況下幸運的聚合者可能同時被選為區塊提議者。 若因為區塊提議者消失而導致證明未被納入，則下個區塊提議者會取得已彙總的證明並納入下一個區塊。 然而，**納入延遲**將會增加 1。
 
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
 
-- [Vitalik 註解的共識規範中的證明](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
+- [Vitalik 的註解版共識規格中的證明](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
 - [eth2book.info 中的證明](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
 
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容！_

public/content/translations/zh-tw/developers/docs/consensus-mechanisms/pos/block-proposal/index.md

@@ -1,14 +1,14 @@
 ---
-title: 區塊提出
-description: 解釋在權益證明以太坊中如何提議區塊。
+title: "區塊提出"
+description: "解釋在權益證明以太坊中如何提議區塊。"
 lang: zh-tw
 ---
 
 區塊是區塊鏈中的基本單位。 區塊是節點之間傳送，達成共識並新增到每個節點資料庫的獨立資訊單元。 本頁會解釋它們是如何產生的。
 
 ## 先決條件 {#prerequisites}
 
-區塊提議是權益證明協定的一部分。 為了幫助瞭解本頁的資訊，我們推薦你閱讀關於[權益證明](/developers/docs/consensus-mechanisms/pos/)與[區塊架構](/developers/docs/blocks/)的相關內容。
+區塊提議是權益證明協定的一部分。 為了幫助您理解本頁面，我們建議您先閱讀關於 [權益證明](/developers/docs/consensus-mechanisms/pos/) 和 [區塊架構](/developers/docs/blocks/) 的文章。
 
 ## 區塊由誰生產？ {#who-produces-blocks}
 
@@ -18,11 +18,11 @@ lang: zh-tw
 
 每個時隙會有一個以偽隨機方式選擇的驗證者來提議區塊。 在區塊鏈中沒有實質的隨機性，因為如果每個節點都產生真實的隨機數，那麼它們是無法達成共識的。 相反的，目的是讓驗證者的選擇過程無法預測。 以太坊使用一種名為 RanDAO 的演算法來達到隨機性，這種演算法會將區塊提議者的雜湊值與一個隨著每個區塊而更新的種子混在一起。 這個值會被用來從整個驗證者集合中選出一個特定的驗證者。 驗證者的選擇會提前兩個時期鎖定，這種方式可以防範特定類型的種子操控。
 
-儘管驗證者會在每個時隙添增 RANDAO，全域 RANDAO 值每個時期僅更新一次。 為了計算下一個區塊提議者的索引，RANDAO 值會跟時隙號碼混合，為每個時隙提供一個獨特數值。 一個驗證者被選中的機率並不是簡單的 `1/N`（其中 `N`= 活躍驗證者總數）。 相反的，它會依照每個驗證者的有效以太幣餘額進行加權。 最大有效餘額為 32 個以太幣（這代表著 `balance < 32 ETH` 會產生低於 `balance == 32 ETH` 的加權，但是 `balance > 32 ETH` 並不會產生高於 `balance == 32 ETH` 的加權）。
+儘管驗證者會在每個時隙添增 RANDAO，全域 RANDAO 值每個時期僅更新一次。 為了計算下一個區塊提議者的索引，RANDAO 值會跟時隙號碼混合，為每個時隙提供一個獨特數值。 單一驗證者被選中的機率並非只是 `1/N`（其中 `N` = 活躍驗證者總數）。 相反的，它會依照每個驗證者的有效以太幣餘額進行加權。 最大有效餘額為 32 ETH（這表示 `balance < 32 ETH` 的權重會低於 `balance == 32 ETH`，但 `balance > 32 ETH` 的權重並不會高於 `balance == 32 ETH`）。
 
 每個時隙只有一個區塊提議者會被選中。 在正常的情況下，一個區塊生產者會在其專門的時隙中建立並且釋出一個區塊。 在一個時隙中建立兩個區塊是一種很嚴重的罪行，通常被稱為「模棱兩可」。
 
-## 區塊如何建立？ {#how-is-a-block-created}
+## 區塊是如何被創造的？ {#how-is-a-block-created}
 
 區塊提議者預計會廣播一個已簽署的信標區塊，該區塊建置在根據他們自己在本地運行的分叉選擇演算法所看到的最近鏈頭之上。 分叉選擇演算法會套用上一個時隙留下的任何排隊證明，然後在其歷史記錄中尋找具有最大累積證明權重的區塊。 該區塊便是由提議者建立的新區塊的父塊。
 
@@ -42,28 +42,28 @@ class BeaconBlockBody(Container):
     execution_payload: ExecutionPayload
 ```
 
-`randao_reveal` 欄位取一個可驗證的隨機值，該值是區塊提議者透過簽署當前的時期編號建立的。 `eth1_data` 是就區塊提議者對存款合約的看法進行的投票，包括存款默克爾樹的根和使新存款能夠被驗證的總存款數。 `graffiti` 是一個可選欄位，可用來在區塊中新增一條訊息。 `proposer_slashings` 和 `attester_slashings` 欄位包含了某些驗證者根據區塊提議者對鏈的看法已經犯下可罰沒行為的證據。 `deposits` 是區塊提議者所知道的新驗證者存款的清單，`voluntary_exits` 是區塊提議者從共識層廣播網路上監聽到的希望退出的驗證者的清單。 `sync_aggregate` 是一個向量，顯示哪些驗證者之前被分配到一個同步委員會（服務於輕量用戶端資料的驗證者子集）並參與了資料簽章。
+`randao_reveal` 欄位採用一個可驗證的隨機值，該值由區塊提議者簽署當前時期編號所建立。 `eth1_data` 是對區塊提議者關於存款合約觀點的投票，內容包含存款 Merkle trie 的根，以及可讓新存款通過驗證的存款總數。 `graffiti` 是一個選填欄位，可用來在區塊中新增訊息。 `proposer_slashings` 和 `attester_slashings` 是包含證明的欄位，根據提議者對鏈的觀點，某些驗證者已犯下可罰沒的行為。 `deposits` 是區塊提議者知悉的新驗證者存款清單，`voluntary_exits` 是區塊提議者在共識層 gossip 網路上聽聞的、希望退出的驗證者清單。 `sync_aggregate` 是一個向量，顯示先前指派到同步委員會 (服務輕型用戶端資料的驗證者子集) 且參與簽署資料的驗證者。
 
-`execution_payload` 使得關於交易的資訊可以在執行用戶端和共識用戶端之間傳遞。 `execution_payload` 是一個被嵌套在信標鏈區塊內部的執行資料區塊。 `execution_payload` 中的欄位反映了以太坊黃皮書中概述的區塊結構，只不過其中沒有親戚區塊，並且 `prev_randao` 取代了 `difficulty`。 執行用戶端可以存取它在自己的 Gossip 網路上監聽到的本機交易池。 這些交易在本機執行，以產生一個被稱為「後狀態」的更新狀態樹。 這些交易被包含在 `execution_payload` 中名為 `transactions` 的清單中，後狀態則在 `state-root` 欄位中提供。
+`execution_payload` 讓交易相關資訊得以在執行用戶端和共識用戶端之間傳遞。 `execution_payload` 是巢狀內嵌於信標區塊的執行資料區塊。 `execution_payload` 內的欄位反映了以太坊黃皮書中所述的區塊結構，但其中沒有 ommers，且 `prev_randao` 取代了 `difficulty`。 執行用戶端可以存取它在自己的 Gossip 網路上監聽到的本機交易池。 這些交易在本機執行，以產生一個被稱為「後狀態」的更新狀態樹。 交易會以名為 `transactions` 的清單形式包含在 `execution_payload` 中，而後狀態則在 `state-root` 欄位中提供。
 
 所有這些資料都被收集在一個信標區塊中，經過簽署並廣播給區塊提議者的對等節點，再由他們傳播給他們的對等節點，以此類推。
 
-閱讀更多關於[區塊剖析](/developers/docs/blocks)的內容。
+閱讀更多關於 [區塊剖析](/developers/docs/blocks) 的資訊。
 
 ## 區塊會發生什麼？ {#what-happens-to-blocks}
 
-區塊被新增至區塊提議者的本機資料庫，並透過共識層廣播網路廣播給對等節點。 當驗證者接收到區塊時，它會驗證其中的資料，包括檢查區塊是否有正確的父塊、是否對應正確的時隙、提議者索引是否符合預期、RANDAO 揭示是否有效，以及提議者是否被罰沒。 `execution_payload` 被解綁，驗證者的執行用戶端重新執行清單中的交易，以檢查所提議的狀態變化。 假設區塊通過了所有這些檢查，每個驗證者將區塊新增到自己的規範鏈中。 然後，在下一個時隙中重新開始這個過程。
+區塊被新增至區塊提議者的本機資料庫，並透過共識層廣播網路廣播給對等節點。 當驗證者接收到區塊時，它會驗證其中的資料，包括檢查區塊是否有正確的父塊、是否對應正確的時隙、提議者索引是否符合預期、RANDAO 揭示是否有效，以及提議者是否被罰沒。 `execution_payload` 會被解包，驗證者的執行用戶端會重新執行清單中的交易，以檢查提議的狀態變更。 假設區塊通過了所有這些檢查，每個驗證者將區塊新增到自己的規範鏈中。 然後，在下一個時隙中重新開始這個過程。
 
 ## 區塊獎勵 {#block-rewards}
 
-區塊提議者會收到他們工作的報酬。 有一個 `base_reward`，是根據活躍驗證者的數量和他們的有效餘額來計算的。 然後，區塊提議者會因為區塊中包含的每個有效證明而收到 `base_reward` 的一部分；證明區塊的驗證者越多，區塊提議者獲得的獎勵就越高。 還有一個獎勵是報告應該被罰沒的驗證者，數額等於每個被罰沒的驗證者的 `1/512 * effective balance`。
+區塊提議者會收到他們工作的報酬。 有一個 `base_reward`，是根據活躍驗證者的數量及其有效餘額計算而來。 區塊提議者接著會因區塊中包含的每個有效證明，而收到一部分的 `base_reward`；為區塊證明的驗證者越多，區塊提議者的獎勵就越高。 舉報應受罰沒的驗證者也會獲得獎勵，獎勵金額為每位受罰沒的驗證者的 `1/512 * 有效餘額`。
 
 [更多關於獎勵和懲罰的資訊](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
 
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
 
 - [區塊簡介](/developers/docs/blocks/)
 - [權益證明簡介](/developers/docs/consensus-mechanisms/pos/)
-- [以太坊共識規範](https://github.com/ethereum/consensus-specs)
-- [Gasper 簡介](/developers/docs/consensus-mechanisms/pos/)
+- [以太坊共識規格](https://github.com/ethereum/consensus-specs)
+- [Gasper 簡介](/developers/docs/consensus-mechanisms/pos/gasper/)
 - [升級以太坊](https://eth2book.info/)