diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
index 315c0fbb414..f69e6cd8267 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
@@ -1,23 +1,23 @@
---
-title: 默克爾帕特里夏樹
-description: 介紹默克爾帕特里夏樹。
+title: "默克爾帕特里夏樹"
+description: "介紹默克爾帕特里夏樹。"
lang: zh-tw
sidebarDepth: 2
---
-以太坊的狀態(所有帳戶、餘額和智慧型合約的總體)被編碼成一種特殊版本的資料結構,這種結構在計算機科學界通常被稱作默克爾樹。 這種結構在密碼學中的許多應用中都非常有用,因為它會在默克爾樹中所有互相有關的資料片段之間建立了一種可驗證的關係,產生可用於驗證相關資料的單一**根**值。
+以太坊的狀態(所有帳戶、餘額和智慧型合約的總體)被編碼成一種特殊版本的資料結構,這種結構在計算機科學界通常被稱作默克爾樹。 這種結構在密碼學中的許多應用程式中非常有用,因為它會在樹中所有互相纏繞的資料片段之間建立一種可驗證的關係,產生可用於驗證相關資料的單一 **根** 值。
-以太坊的資料結構是「改良版的默克爾帕特里夏樹」,之所以會這樣命名,是因為它借鑒了一些 PATRICIA(字母數字編碼的資訊擷取實用演算法)的部分特徵,同時它是為了對構成以太坊狀態的項目進行有效率的資料**擷取**而設計的。
+以太坊的資料結構是「改良版默克爾-派翠西亞樹」,之所以如此命名,是因為它借鑒了 PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric) 的一些功能,並且其設計是為了能有效率地對構成以太坊狀態的項目進行資料**擷取**。
-默克爾帕特里夏樹是確定性的,並且可以透過加密方式驗證:生成狀態根的唯一方式是從每個單獨的狀態進行計算,且兩個相同的狀態可以透過比較根雜湊和其父雜湊(_默克爾證明_)來簡單地證明相同。 相反,無法用同一個根雜湊建立兩個不同的狀態,任何用不同值修改狀態的嘗試都會導致不同的狀態根雜湊。 從理論上講,這種結構為置入、查找和刪除提供了完美的 `O(log(n))` 效率。
+默克爾-派翠西亞樹是確定性且可加密驗證的:產生狀態根的唯一方法是透過狀態的每個獨立部分來計算,而兩個相同的狀態可以透過比較根雜湊以及導出根雜湊的那些雜湊 (_默克爾證明_) 來輕易地證明其相同性。 相反,無法用同一個根雜湊建立兩個不同的狀態,任何用不同值修改狀態的嘗試都會導致不同的狀態根雜湊。 理論上,此結構為插入、查詢和刪除提供了 `O(log(n))` 效率的「終極目標」。
在不久的將來,以太坊計劃遷移到[沃克爾樹](/roadmap/verkle-trees)結構,這將為未來的協定改進帶來更多新的可能性。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更容易理解本文,具備以下基礎知識會很有幫助:[雜湊](https://en.wikipedia.org/wiki/Hash_function)、[默克爾樹](https://en.wikipedia.org/wiki/Merkle_tree)、[字典树](https://en.wikipedia.org/wiki/Trie)和[序列化](https://en.wikipedia.org/wiki/Serialization)。 本文從基本的[基數樹](https://en.wikipedia.org/wiki/Radix_tree)描述開始,然後逐步介紹使以太坊資料結構更爲優化的必要修改。
+為了能更佳理解此頁面,最好對 [雜湊](https://en.wikipedia.org/wiki/Hash_function)、[默克爾樹](https://en.wikipedia.org/wiki/Merkle_tree)、[前綴樹](https://en.wikipedia.org/wiki/Trie) 和 [序列化](https://en.wikipedia.org/wiki/Serialization) 有基本了解。 本文從基本的 [基數樹](https://en.wikipedia.org/wiki/Radix_tree) 描述開始,然後逐步介紹讓以太坊資料結構更優化所做的必要修改。
-## 基數樹 {#basic-radix-tries}
+## 基本基數前綴樹 {#basic-radix-tries}
在基數樹中,每個節點看起來如下:
@@ -25,146 +25,149 @@ sidebarDepth: 2
[i_0, i_1 ... i_n, value]
```
-其中,`i_0 ... i_n` 代表字母表的符號(通常是二進位或十六進位),`value` 是節點的終值,`i_0, i_1 ... i_n` 插槽中的值為 `NULL` 或指向其他節點(在我們的示例中,是其他節點的雜湊)的指針。 這形成了基本的 `(key, value)` 存儲。
+其中 `i_0 ...` i_n` 代表字母表的符號 (通常是二進制或十六進制),`value`是節點的終端值,而`i_0, i_1 ...` 中的值 i_n` 位置的值要不是 `NULL`,就是指向其他節點的指標 (在我們的例子中,是其他節點的雜湊)。 這形成了基本的 `(key, value)` 儲存。
-假設你想使用基數樹資料結構永久保存一組鍵值對的順序。 爲了在字典樹中找到目前與鍵 `dog` 對應的值,你首先需要把 `dog` 轉換為字母表中的字母(提供 `64 6f 67`),然後沿著該路徑向下遍歷字典樹,直到找到該值。 也就是説,爲了找到字典樹的根節點,你首先需要在平面鍵/值資料庫中找到根雜湊。 它表示指向其他節點的一個鍵陣列。 你將使用索引 `6` 的值作爲鍵,並通過在平面鍵/值資料庫中查找該鍵來獲取下一級的節點。 然後選取索引 `4` 查找下一個值,再選取索引 `6`,依此類推,直到遍歷路徑 `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7` 后,你會找到該節點的值並返回結果。
+假設你想使用基數樹資料結構永久保存一組鍵值對的順序。 要在前綴樹中找到目前映射至鍵 `dog` 的值,您要先將 `dog` 轉換成字母表中的字母 (得到 `64 6f 67`),然後沿著該路徑向下遍歷前綴樹,直到找到值為止。 也就是説,爲了找到字典樹的根節點,你首先需要在平面鍵/值資料庫中找到根雜湊。 它表示指向其他節點的一個鍵陣列。 您可以使用索引 `6` 的值作為鍵,並在平面鍵/值資料庫中查詢,以取得下一層的節點。 然後選擇索引 `4` 來查詢下一個值,接著選擇索引 `6`,依此類推,直到您遵循路徑:`root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`,您便會查詢到節點的值並回傳結果。
-從「樹」中和從底層平面鍵/值「資料庫」中進行查找有所區別。 它們都定義了鍵/值排列,但底層資料庫能夠對鍵執行傳統的一步查找。 在樹中查找一個鍵對應的值則需要在底層資料庫中查詢多次,才能得到上述的最終值。 讓我們將後者稱爲 `path`,以消除歧義。
+從「樹」中和從底層平面鍵/值「資料庫」中進行查找有所區別。 它們都定義了鍵/值排列,但底層資料庫能夠對鍵執行傳統的一步查找。 在樹中查找一個鍵對應的值則需要在底層資料庫中查詢多次,才能得到上述的最終值。 為消除歧義,我們將後者稱為 `path` (路徑)。
基數樹的更新和刪除操作可被定義如下:
-```
- def update(node,path,value):
- curnode = db.get(node) if node else [ NULL ] * 17
+```python
+ def update(node_hash, path, value):
+ curnode = db.get(node_hash) if node_hash else [NULL] * 17
newnode = curnode.copy()
- if path == '':
+ if path == "":
newnode[-1] = value
else:
- newindex = update(curnode[path[0]],path[1:],value)
+ newindex = update(curnode[path[0]], path[1:], value)
newnode[path[0]] = newindex
- db.put(hash(newnode),newnode)
+ db.put(hash(newnode), newnode)
return hash(newnode)
- def delete(node,path):
- if node is NULL:
+ def delete(node_hash, path):
+ if node_hash is NULL:
return NULL
else:
- curnode = db.get(node)
+ curnode = db.get(node_hash)
newnode = curnode.copy()
- if path == '':
+ if path == "":
newnode[-1] = NULL
else:
- newindex = delete(curnode[path[0]],path[1:])
+ newindex = delete(curnode[path[0]], path[1:])
newnode[path[0]] = newindex
if all(x is NULL for x in newnode):
return NULL
else:
- db.put(hash(newnode),newnode)
+ db.put(hash(newnode), newnode)
return hash(newnode)
```
-「默克爾」基數樹是透過使用確定性產生的加密雜湊摘要連結節點來構建的。 這種(鍵/值資料庫中 `key == keccak256(rlp(value))`)内容尋址提供了儲存資料的加密完整性保證。 如果給定字典樹的根雜湊是公開的,則任何能夠訪問底層葉資料的人都可以透過提供將特定值與樹根連結的每個節點的雜湊,來證明該字典樹在特定路徑中包含給定值。
+「默克爾」基數樹是透過使用確定性產生的加密雜湊摘要連結節點來構建的。 這種內容定址 (在鍵/值資料庫中 `key == keccak256(rlp(value))`) 為儲存的資料提供了加密完整性保證。 如果給定字典樹的根雜湊是公開的,則任何能夠訪問底層葉資料的人都可以透過提供將特定值與樹根連結的每個節點的雜湊,來證明該字典樹在特定路徑中包含給定值。
-對於攻擊者來講,他們無法證明 `(path, value)` 對不存在,因爲根雜湊最終基於其下方的所有雜湊。 任何底層修改都會改變根雜湊。 你可以將雜湊想做是資料結構資訊的一種壓縮表示,並透過雜湊函式的預映射保護保證安全。
+攻擊者不可能提供不存在的 `(path, value)` 配對證明,因為根雜湊最終是基於其下的所有雜湊。 任何底層修改都會改變根雜湊。 你可以將雜湊想做是資料結構資訊的一種壓縮表示,並透過雜湊函式的預映射保護保證安全。
-我們將基數樹的原子單位(例如單個十六進位字元或 4 位二進位數字)稱爲「nibble」。 如上所述,以 nibble 為單位遍歷路徑時,節點最多可以指向 16 個子節點,但是還包括一個 `value` 元素。 因此,我們將它們表示爲長度 17 的陣列。 我們將這 17 個元素的陣列稱爲「分支節點」。
+我們會將基數樹的一個原子單位 (例如單一的十六進制字元,或 4 位元的二進制數) 稱為「半位元組 (nibble)」。 如上所述,在一次遍歷一個半位元組的路徑時,節點最多可以引用 16 個子節點,但包含一個 `value` 元素。 因此,我們將它們表示爲長度 17 的陣列。 我們將這 17 個元素的陣列稱爲「分支節點」。
-## 默克爾帕特里夏樹 {#merkle-patricia-trees}
+## 默克爾-派翠西亞樹 {#merkle-patricia-trees}
-基數樹有一個主要限制:效率低下。 如果你希望將一個 `(path, value)` 繫結儲存在路徑長度為 64 字符(`bytes32` 中的 nibble 數)的位置,如以太坊中,我們需要超過一千個位元組的額外空間將每個字元存儲一個等級,並且每次查詢或刪除都需要執行完整的 64 步。 下文介紹的帕特里夏樹解決了這個問題。
+基數樹有一個主要限制:效率低下。 如果您想儲存一個 `(path, value)` 綁定,其中路徑的長度 (像在以太坊一樣) 為 64 個字元 (即 `bytes32` 中的半位元組數),那麼每個字元都需要超過 1 KB 的額外空間來儲存一個層級,且每次查詢或刪除都將需要整整 64 個步驟。 下文介紹的帕特里夏樹解決了這個問題。
-### 最佳化 {#optimization}
+### 優化 {#optimization}
默克爾帕特里夏樹中的節點可以是以下其中一種:
-1. `NULL`(表示爲空字串)
-2. `branch` 一個 17 項目節點 `[ v0 ... v15, vt ]`
-3. `leaf` 一個 2 項目節點 `[ encodedPath, value ]`
-4. `extension` 一個 2 項目節點 `[ encodedPath, key ]`
+1. `NULL` (以空字串表示)
+2. `branch` 一個 17 項的節點 `[ v0 ...` `v15, vt ]`
+3. `leaf` 一個 2 項的節點 `[ encodedPath, value ]`
+4. `extension` 一個 2 項的節點 `[ encodedPath, key ]`
-在 64 字元的路徑中,遍歷樹的前幾層后,你將會達到一個至少下游部分不再有分支路徑的節點。 爲了避免在路徑中建立多達 15 個稀疏 `NULL` 節點,我們需要透過設置一個形式爲 `[ encodedPath, key ]` 的 `extension` 節點來簡化向下遍歷,其中 `encodedPath` 包含要跳過的「部分路徑」(使用下面描述的壓縮編碼),`key` 用於下一次資料庫查詢。
+在 64 字元的路徑中,遍歷樹的前幾層后,你將會達到一個至少下游部分不再有分支路徑的節點。 為避免沿路徑建立多達 15 個稀疏的 `NULL` 節點,我們透過設定 `[ encodedPath, key ]` 形式的 `extension` 節點來簡化向下搜尋,其中 `encodedPath` 包含要跳過的「部分路徑」 (使用下述的緊湊編碼),而 `key` 則用於下一次資料庫查詢。
-對於 `leaf` 節點,可以使用 `encodedPath` 的第一個 nibble 中的標記來標注,該路徑編碼了所有先前節點的路徑片段,並且我們可以直接查找 `value`。
+對於 `leaf` 節點,可以在 `encodedPath` 的第一個半位元組中以旗標標記,路徑會編碼所有先前節點的路徑片段,而我們可以直接查詢 `value`。
然而,上述優化帶來了歧義。
-當 nibble 遍歷路徑時,最後我們可能需要遍歷奇數個 nibble,但是所有資料都需要以 `bytes` 形式儲存。 兩者之間是無法區分的,例如,nibble `1` 和 nibble `01`(兩者都必須存儲爲 `<01>`)。 爲了指定奇數長度,這部分路徑需要用標記作爲前置詞。
+以半位元組為單位遍歷路徑時,我們最終可能需要遍歷奇數個半位元組,但是所有資料都是以 `bytes` 格式儲存的。 例如,我們無法區分半位元組 `1` 和半位元組 `01` (兩者都必須儲存為 `<01>`)。 爲了指定奇數長度,這部分路徑需要用標記作爲前置詞。
-### 規範:具有可選終止符的十六進位序列壓縮編碼 {#specification}
+### 規格:帶有可選終端符的十六進制序列的緊湊編碼 {#specification}
-如上所述,_剩餘部分路徑長度為奇數 vs 偶數_和_葉節點 vs 擴展節點_的標記位於任意 2 項目節點中部分路徑的第一個 nibble。 它們會產生以下結果:
+如上所述,關於_剩餘部分路徑長度為奇數還是偶數_以及是_葉節點還是擴充節點_的旗標,都位於任何 2 項節點的部分路徑的第一個半位元組中。 它們會產生以下結果:
- hex char bits | node type partial path length
- ----------------------------------------------------------
- 0 0000 | extension even
- 1 0001 | extension odd
- 2 0010 | terminating (leaf) even
- 3 0011 | terminating (leaf) odd
+| 十六進位字符 | 比特 | 部分節點類型 | 路徑長度 |
+| ------ | ---- | ------------------------- | ---- |
+| 0 | 0000 | 擴充 | 偶數 |
+| 1 | 0001 | 擴充 | 奇數 |
+| 2 | 0010 | 終端 (葉) | 偶數 |
+| 3 | 0011 | 終端 (葉) | 奇數 |
-對於剩餘路徑長度為偶數的情況(`0` 或 `2`),一定會附加一個 `0`「填充」nibble。
+對於偶數的剩餘路徑長度 (`0` 或 `2`),後面將總會跟著另一個 `0`「填充」半位元組。
-```
+```python
def compact_encode(hexarray):
term = 1 if hexarray[-1] == 16 else 0
- if term: hexarray = hexarray[:-1]
+ if term:
+ hexarray = hexarray[:-1]
oddlen = len(hexarray) % 2
flags = 2 * term + oddlen
if oddlen:
hexarray = [flags] + hexarray
else:
hexarray = [flags] + [0] + hexarray
- // hexarray now has an even length whose first nibble is the flags.
- o = ''
- for i in range(0,len(hexarray),2):
- o += chr(16 * hexarray[i] + hexarray[i+1])
+ # hexarray 現在的長度為偶數,其第一個半位元組為旗標。
+ o = ""
+ for i in range(0, len(hexarray), 2):
+ o += chr(16 * hexarray[i] + hexarray[i + 1])
return o
```
-範例:
+範例:
-```
- > [ 1, 2, 3, 4, 5, ...]
+```python
+ > [1, 2, 3, 4, 5, ...]
'11 23 45'
- > [ 0, 1, 2, 3, 4, 5, ...]
+ > [0, 1, 2, 3, 4, 5, ...]
'00 01 23 45'
- > [ 0, f, 1, c, b, 8, 10]
+ > [0, f, 1, c, b, 8, 10]
'20 0f 1c b8'
- > [ f, 1, c, b, 8, 10]
+ > [f, 1, c, b, 8, 10]
'3f 1c b8'
```
下面是獲取默克爾帕特里夏樹中節點的擴展程式碼:
-```
- def get_helper(node,path):
- if path == []: return node
- if node = '': return ''
- curnode = rlp.decode(node if len(node) < 32 else db.get(node))
+```python
+ def get_helper(node_hash, path):
+ if path == []:
+ return node_hash
+ if node_hash == "":
+ return ""
+ curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash))
if len(curnode) == 2:
(k2, v2) = curnode
k2 = compact_decode(k2)
- if k2 == path[:len(k2)]:
- return get(v2, path[len(k2):])
+ if k2 == path[: len(k2)]:
+ return get(v2, path[len(k2) :])
else:
- return ''
+ return ""
elif len(curnode) == 17:
- return get_helper(curnode[path[0]],path[1:])
+ return get_helper(curnode[path[0]], path[1:])
- def get(node,path):
+ def get(node_hash, path):
path2 = []
for i in range(len(path)):
path2.push(int(ord(path[i]) / 16))
path2.push(ord(path[i]) % 16)
path2.push(16)
- return get_helper(node,path2)
+ return get_helper(node_hash, path2)
```
-### 示例樹 {#example-trie}
+### 前綴樹範例 {#example-trie}
-假設我們想要一個包含四個路徑/值對 `('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')` 的樹。
+假設我們想要一個前綴樹,其中包含四個路徑/值配對:`('do', 'verb')`、`('dog', 'puppy')`、`('doge', 'coins')`、`('horse', 'stallion')`。
-首先,我們需要將路徑和值都轉換爲 `bytes`。 如下,_paths_ 的實際位元組代表由 `<>` 表示,而 _values_ 仍然顯示爲字串,由 `"` 表示,以方便理解(值也應該為 `bytes`):
+首先,我們將路徑和值都轉換為 `bytes`。 下面,_路徑_ 的實際位元組表示法以 `<>` 表示,但為了方便理解,_值_ 仍然以字串 (`''`) 顯示 (值實際上也應是 `bytes`):
```
<64 6f> : 'verb'
@@ -183,38 +186,38 @@ sidebarDepth: 2
hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
```
-當一個節點在另一個節點内部被引用時,包含的内容是 `H(rlp.encode(node))`,其中 `H(x) = keccak256(x) if len(x) >= 32 else x` 並且 `rlp.encode` 是[遞迴長度前置詞](/developers/docs/data-structures-and-encoding/rlp)編碼函式。
+當一個節點在另一個節點中被引用時,所包含的是 `keccak256(rlp.encode(node))` (若 `len(rlp.encode(node)) >= 32`) 或 `node` (若否),其中 `rlp.encode` 是 [RLP](/developers/docs/data-structures-and-encoding/rlp) 編碼函式。
-請注意,更新樹時,_如果_新建立的節點長度 >= 32,則需要將鍵/值對 `(keccak256(x), x)` 儲存在一個持續不變的查找表中。 然而,如果節點比這短,則不需要儲存任何資料,因爲函式 f(x) = x 是可逆的。
+請注意,在更新前綴樹時,如果新建立的節點長度 >= 32,則需要將鍵/值配對 `(keccak256(x), x)` 儲存在持久性查詢表中。 然而,如果節點比這短,則不需要儲存任何資料,因爲函式 f(x) = x 是可逆的。
-## 以太坊中的樹 {#tries-in-ethereum}
+## 以太坊中的前綴樹 {#tries-in-ethereum}
以太坊執行層中的所有默克爾樹都使用默克爾帕特里夏樹。
在區塊頭,有來自其中 3 棵樹的 3 個根。
-1. stateRoot
-2. transactionsRoot
-3. receiptsRoot
+1. stateRoot
+2. transactionsRoot
+3. receiptsRoot
-### 狀態樹 {#state-trie}
+### 狀態前綴樹 {#state-trie}
-有一個全域狀態樹,每次用戶端處理一個區塊時它都會更新。 其中,`path` 始終為 `keccak256(ethereumAddress)`,並且 `value` 始終為 `rlp(ethereumAccount)`。 具體來講,一個以太坊 `account` 是包含 4 個項目的陣列:`[nonce,balance,storageRoot,codeHash]`。 此時,值得注意的是,該 `storageRoot` 是另一個帕特里夏樹的根:
+有一個全域狀態樹,每次用戶端處理一個區塊時它都會更新。 在其中,`path` 始終為:`keccak256(ethereumAddress)`,而 `value` 始終為:`rlp(ethereumAccount)`。 更具體地說,以太坊 `account` (帳戶) 是一個 4 項陣列,包含 `[nonce,balance,storageRoot,codeHash]`。 此時,值得注意的是,這個 `storageRoot` 是另一個派翠西亞樹的根:
-### 存儲樹 {#storage-trie}
+### 儲存前綴樹 {#storage-trie}
-存儲樹是保存_所有_合約資料的地方。 每個帳戶都有一棵單獨的存儲樹。 爲了用給定地址檢索位於特定存儲位置的值,需要有存儲地址、存儲中所儲存資料的整數位置,以及區塊 ID。 之後,這些資料可以作爲引數傳入 JSON-RPC 應用程式介面中定義的 `eth_getStorageAt`,例如,用於檢索地址 `0x295a70b2de5e3953354a6a8344e616ed314d7251` 的存儲插槽 0 中的資料:
+儲存前綴樹是_所有_合約資料儲存的地方。 每個帳戶都有一棵單獨的存儲樹。 爲了用給定地址檢索位於特定存儲位置的值,需要有存儲地址、存儲中所儲存資料的整數位置,以及區塊 ID。 然後,這些資料可以作為引數傳遞給 JSON-RPC API 中定義的 `eth_getStorageAt`,例如,要擷取位址 `0x295a70b2de5e3953354a6a8344e616ed314d7251` 的儲存槽 0 中的資料:
-```
+```bash
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
```
-檢索存儲中的其他元素稍微複雜一些,因爲必須首先計算存儲樹中的位置。 該位置作爲地址和存儲位置的 `keccak256` 雜湊進行計算,兩者都從左側開始,用零填充 32 位元組的長度。 例如,地址 `0x391694e7e0b0cce554cb130d723a9d27458f9298` 存儲插槽 1 中的資料位置是:
+檢索存儲中的其他元素稍微複雜一些,因爲必須首先計算存儲樹中的位置。 此位置是透過計算地址和儲存位置的 `keccak256` 雜湊所得,兩者都向左填充零,直到長度為 32 位元組。 例如,位址 `0x391694e7e0b0cce554cb130d723a9d27458f9298` 的儲存槽 1 中資料的位置是:
-```
+```python
keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))
```
@@ -227,37 +230,37 @@ undefined
"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
```
-因此,`path` 為 `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`。 與之前一樣,該地址現在可用於從存儲樹檢索資料:
+因此,`path` 是 `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`。 與之前一樣,該地址現在可用於從存儲樹檢索資料:
-```
+```bash
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
```
-注:如果不是合約帳戶,以太坊帳戶的 `storageRoot` 預設為空。
+注意:如果不是合約帳戶,以太坊帳戶的 `storageRoot` 預設為空。
-### 交易樹 {#transaction-trie}
+### 交易前綴樹 {#transaction-trie}
-每個區塊都有一個獨立的交易樹,也用於儲存 `(key, value)` 對。 此處的路徑為:`rlp(transactionIndex)`,代表了對應一個值的鍵,該值由以下程式碼決定:
+每個區塊都有一個獨立的交易前綴樹,同樣儲存 `(key, value)` 配對。 這裡的路徑是:`rlp(transactionIndex)`,它代表對應於由以下方式決定的值的鍵:
-```
+```python
if legacyTx:
value = rlp(tx)
else:
value = TxType | encode(tx)
```
-在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中可以找到更多相關資訊。
+更多相關資訊可以在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中找到。
-### 收據樹 {#receipts-trie}
+### 收據前綴樹 {#receipts-trie}
-每個區塊都有其收據樹。 此處的 `path` 是:`rlp(transactionIndex)`。 `transactionIndex` 是其所在區塊中的索引。 收據樹從不更新。 與交易樹類似,它也有當前和以前的收據。 爲了在收據樹中查詢特定的收據,需要提供區塊中交易的索引、收據承載以及交易類型。 返回的收據可以是 `Receipt` 類型,該類型被定義爲 `TransactionType` 和 `ReceiptPayload` 的串聯,也可以是 `LegacyReceipt` 類型,該類型被定義爲 `rlp([status, cumulativeGasUsed, logsBloom, logs])`。
+每個區塊都有其收據樹。 這裡的 `path` 是:`rlp(transactionIndex)`。 `transactionIndex` 是它在所包含區塊中的索引。 收據樹從不更新。 與交易樹類似,它也有當前和以前的收據。 爲了在收據樹中查詢特定的收據,需要提供區塊中交易的索引、收據承載以及交易類型。 回傳的收據可以是 `Receipt` 類型,其定義為 `TransactionType` 和 `ReceiptPayload` 的串接;或者也可以是 `LegacyReceipt` 類型,其定義為 `rlp([status, cumulativeGasUsed, logsBloom, logs])`。
-在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中可以找到更多相關資訊。
+更多相關資訊可以在 [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) 文件中找到。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [修改後的默克爾帕特里夏樹 — 以太坊如何保存狀態](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
-- [以太坊中的默克爾](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
-- [瞭解以太坊樹](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
+- [改良版默克爾-派翠西亞樹 — 以太坊如何儲存狀態](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
+- [以太坊中的默克爾化](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
+- [了解以太坊前綴樹](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md
index 30cef3a9519..b8f706451e7 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/rlp/index.md
@@ -1,24 +1,24 @@
---
-title: 遞迴長度前置詞 (RLP) 序列化
-description: 以太坊執行層中的遞迴長度前置詞編碼的定義
+title: "遞迴長度前置詞 (RLP) 序列化"
+description: "以太坊執行層中的遞迴長度前置詞編碼的定義"
lang: zh-tw
sidebarDepth: 2
---
-遞迴長度前置詞 (RLP) 序列化在以太坊執行層用戶端中廣泛使用。 遞迴長度前置詞以節省空間的格式標準化資料在節點之間的傳送。 遞迴長度前置詞的目的在於,對任意嵌套的二進位資料陣列進行編碼,而遞迴長度前置詞是用於序列化以太坊執行層中物件的主要編碼方法。 遞迴長度前置詞的主要目的是對結構進行解碼;除了正整數外,遞迴長度前置詞將特定資料類型(例如字串、浮點數)的編碼委托給更高階的協定。 正整數必須以沒有前導零的大端二進位形式表示(因而使整數值零相當於空位元組陣列)。 任何使用遞迴長度前置詞的高階協定都必須將具有前導零的反序列化正整數視爲無效。
+遞迴長度前置詞 (RLP) 序列化在以太坊執行層用戶端中廣泛使用。 遞迴長度前置詞以節省空間的格式標準化資料在節點之間的傳送。 遞迴長度前置詞的目的在於,對任意嵌套的二進位資料陣列進行編碼,而遞迴長度前置詞是用於序列化以太坊執行層中物件的主要編碼方法。 RLP 的主要用途是編碼結構;除了正整數以外,RLP 會將特定資料類型 (例如字串、浮點數) 的編碼委派給更高階的協定。 正整數必須以沒有前導零的大端二進位形式表示(因而使整數值零相當於空位元組陣列)。 任何使用遞迴長度前置詞的高階協定都必須將具有前導零的反序列化正整數視爲無效。
更多資訊請參閱[以太坊黃皮書(附錄 B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19)。
要使用遞迴長度前置詞對字典進行編碼,建議的兩種規範形式為:
-- 配合按字典順序排序的鍵使用 `[[k1,v1],[k2,v2]...]`
+- 使用 `[[k1,v1],[k2,v2]...]`,並以字典順序排列鍵
- 像以太坊一樣使用更高階的帕特里夏樹編碼
## 定義 {#definition}
遞迴長度前置詞編碼函式接受一個項目。 該項目的定義如下:
-- 一個字串(即位元組陣列)是一個項目
+- 一個字串 (亦即位元組陣列) 是一個項目
- 一個項目清單是一個項目
- 一個正整數是一個項目
@@ -35,12 +35,12 @@ sidebarDepth: 2
遞迴長度前置詞編碼的定義如下:
- 對於正整數,將其轉換爲最短位元組陣列,其大端解釋為整數,然後根據下面的規則編碼為字串。
-- 對於值在 `[0x00, 0x7f]`(十進位 `[0, 127]`)範圍内的單一位元組,該位元組就是它自己的遞迴長度前置詞編碼。
-- 否則,如果字串的長度為 0-55 位元組,則遞迴長度前置詞編碼包含一個值為 **0x80**(十進位 128)的單一位元組,加上該字串后字串的長度。 因此,第一個位元組的範圍是 `[0x80, 0xb7]`(十進位 `[128, 183]`)。
-- 如果字串的長度超過 55 位元組,則遞迴長度前置詞編碼的組成為:一個值為 **0xb7**(十進位 183)的單一位元組,加上二進位形式的字串長度之長度(以位元組為單位),后跟字串的長度,然後是字串。 例如,一個 1024 位元組長的字串將被編碼為 `\xb9\x04\x00`(十進位 `185, 4, 0`),後跟該字串。 在這裏,`0xb9` (183 + 2 = 185) 為第一個位元組,然後是表示實際字串長度的 2 個位元組 `0x0400`(十進位 1024)。 因此,第一個位元組的範圍是 `[0xb8, 0xbf]`(十進位 `[184, 191]`)。
+- 對於值在 `[0x00, 0x7f]` (十進位 `[0, 127]`) 範圍內的單一位元組,該位元組即為其自身的 RLP 編碼。
+- 否則,若字串長度為 0-55 位元組,RLP 編碼由一個值為 **0x80** (十進位 128) 的單一位元組,加上字串的長度,後面再跟著字串本身所組成。 因此,第一個位元組的範圍為 `[0x80, 0xb7]` (十進位 `[128, 183]`)。
+- 若字串長度超過 55 位元組,RLP 編碼由一個值為 **0xb7** (十進位 183) 的單一位元組,加上以位元組為單位、二進位形式的字串長度之長度,後面跟著字串的長度,最後再跟著字串本身所組成。 例如,一個 1024 位元組長的字串會被編碼為 `\xb9\x04\x00` (十進位 `185, 4, 0`),後面再跟著字串。 在此,`0xb9` (183 + 2 = 185) 是第一個位元組,後面跟著代表實際字串長度的 2 個位元組 `0x0400` (十進位 1024)。 因此,第一個位元組的範圍為 `[0xb8, 0xbf]` (十進位 `[184, 191]`)。
- 如果字串長度為 2^64 位元組或者更長,則可能不會對其進行編碼。
-- 如果清單的縂承載長度(即其所有經過遞迴長度前置詞編碼的項目的組合長度)為 0-55 位元組,則遞迴長度前置詞編碼包含一個值為 **0xc0** 的單一位元組,加上承載長度,後跟項目遞迴長度前置詞編碼的串聯。 因此,第一個字節位元組的範圍是 `[0xc0, 0xf7]`(十進位 `[192, 247]`)。
-- 如果清單的縂承載長度超過 55 位元組,則遞迴長度前置詞編碼包含一個值為 **0xf7** 的單一位元組,加上二進位形式的承載長度(以位元組為單位),後跟承載的長度,後跟項目遞迴長度前置詞編碼的串聯。 因此,第一個字節位元組的範圍是 `[0xf8, 0xff]`(十進位 `[248, 255]`)。
+- 若一個清單的總承載量 (亦即其所有 RLP 編碼項目的組合長度) 為 0-55 位元組,RLP 編碼由一個值為 **0xc0** 的單一位元組,加上承載量的長度,後面再跟著串連起來的各項目 RLP 編碼所組成。 因此,第一個位元組的範圍為 `[0xc0, 0xf7]` (十進位 `[192, 247]`)。
+- 若一個清單的總承載量超過 55 位元組,RLP 編碼由一個值為 **0xf7** 的單一位元組,加上以位元組為單位、二進位形式的承載量長度,後面跟著承載量的長度,最後再跟著串連起來的各項目 RLP 編碼所組成。 因此,第一個位元組的範圍為 `[0xf8, 0xff]` (十進位 `[248, 255]`)。
對應的程式碼為:
@@ -62,7 +62,7 @@ def encode_length(L, offset):
elif L < 256**8:
BL = to_binary(L)
return chr(len(BL) + offset + 55) + BL
- raise Exception("input too long")
+ raise Exception("input too long")
def to_binary(x):
if x == 0:
@@ -80,30 +80,30 @@ def to_binary(x):
- 位元組 '\\x00' = `[ 0x00 ]`
- 位元組 '\\x0f' = `[ 0x0f ]`
- 位元組 '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]`
-- 3 的[集合理論表示](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers),`[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
-- 字串 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]`
+- 3 的[集合論表示法](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers),`[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
+- 字串 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]`
-## 遞迴長度前置詞解碼 {#rlp-decoding}
+## RLP 解碼 {#rlp-decoding}
根據遞迴長度前置詞編碼的規則和過程,遞迴長度前置詞解碼的輸入被視爲一個二進位資料陣列。 遞迴長度前置詞解碼過程如下:
-1. 根據輸入資料的第一個位元組(即前置詞),解碼資料類型、實際資料長度和位移;
+1. 根據輸入資料的第一個位元組 (亦即字首) 來解碼資料類型、實際資料長度及偏移量;
-2. 根據資料的類型和位移,對資料進行相應的解碼,遵循正整數的最小編碼規則;
+2. 根據資料的類型和位移,對資料進行相應的解碼,遵循正整數的最小編碼規則;
-3. 繼續解碼輸入的剩餘部分;
+3. 繼續解碼輸入的剩餘部分;
其中,解碼資料類型和位移的規則如下:
-1. 如果第一個位元組(即前置詞)的範圍是 [0x00, 0x7f],則資料為字串,并且字串本身就是第一個位元組;
+1. 若第一個位元組 (亦即字首) 的範圍是 [0x00, 0x7f],則資料為字串,而且字串就是第一個位元組本身;
-2. 如果第一個位元組的範圍是 [0x80, 0xb7],則資料為字串,并且第一個位元組后跟長度等於第一個位元組減去 0x80 的字串;
+2. 如果第一個位元組的範圍是 [0x80, 0xb7],則資料為字串,並且第一個位元組后跟長度等於第一個位元組減去 0x80 的字串;
-3. 如果第一個位元組的範圍是 [0xb8, 0xbf],則資料為字串,第一個位元組后跟長度等於第一個位元組減去 0xb7 的字串長度,后跟該字串;
+3. 如果第一個位元組的範圍是 [0xb8, 0xbf],則資料為字串,第一個位元組后跟長度等於第一個位元組減去 0xb7 的字串長度,后跟該字串;
-4. 如果第一個位元組的範圍是 [0xc0, 0xf7],則資料為清單,第一個位元組後跟清單中所有項目的遞迴長度前置詞編碼串聯,而清單的縂承載等於第一個位元組減去 0xc0;
+4. 如果第一個位元組的範圍是 [0xc0, 0xf7],則資料為清單,第一個位元組後跟清單中所有項目的遞迴長度前置詞編碼串聯,而清單的縂承載等於第一個位元組減去 0xc0;
-5. 如果第一個位元組的範圍是 [0xf8, 0xff],則資料為清單,第一個位元組后跟長度等於第一個位元組減去 0xf7 的縂承載,而清單所有項目的遞迴長度前置詞編碼串聯則跟在清單的縂承載之後;
+5. 如果第一個位元組的範圍是 [0xf8, 0xff],則資料為清單,第一個位元組后跟長度等於第一個位元組減去 0xf7 的縂承載,而清單所有項目的遞迴長度前置詞編碼串聯則跟在清單的縂承載之後;
對應的程式碼為:
@@ -152,12 +152,12 @@ def to_integer(b):
return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256
```
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊中的遞迴長度前置詞](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
-- [深入瞭解以太坊:遞迴長度前置詞](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
-- [Coglio, A. (2020)。 ACL2 中的以太坊遞迴長度前置詞。 arXiv 預印本 arXiv:2009.13769。](https://arxiv.org/abs/2009.13769)
+- [以太坊中的 RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
+- [深入了解以太坊:RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
+- Coglio, A. (2020)。 ACL2 中的以太坊遞迴長度前置詞。 arXiv 預印本 arXiv:2009.13769。](https://arxiv.org/abs/2009.13769)
## 相關主題 {#related-topics}
-- [帕特里夏默克爾樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
+- [帕特里夏·默克爾樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md
index efb6450536c..bb673f723f9 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/ssz/index.md
@@ -1,11 +1,11 @@
---
-title: 簡單序列化
-description: 以太坊簡單序列化 (SSZ) 格式的解釋説明。
+title: "簡單序列化"
+description: "以太坊簡單序列化 (SSZ) 格式的解釋説明。"
lang: zh-tw
sidebarDepth: 2
---
-**簡單序列化 (SSZ)** 是信標鏈上使用的序列化方法。 它取代了遞迴長度前置詞序列化,後者在除了對等點發現協定以外的共識層到執行層上廣泛使用。 簡單序列化被設計爲具有確定性,並且也能夠有效率地進行默克爾化。 簡單序列化可以被認爲有兩個組成部分:序列化方案和默克爾化方案,其中默克爾化方案旨在有效率地處理序列化資料結構。
+**簡單序列化 (SSZ)** 是信標鏈上使用的序列化方法。 它取代了遞迴長度前置詞序列化,後者在除了對等點發現協定以外的共識層到執行層上廣泛使用。 若要深入了解 RLP 序列化,請參閱 [遞迴長度前綴 (RLP)](/developers/docs/data-structures-and-encoding/rlp/) 簡單序列化被設計爲具有確定性,並且也能夠有效率地進行默克爾化。 簡單序列化可以被認爲有兩個組成部分:序列化方案和默克爾化方案,其中默克爾化方案旨在有效率地處理序列化資料結構。
## 簡單序列化如何運作? {#how-does-ssz-work}
@@ -16,7 +16,7 @@ sidebarDepth: 2
- 無號整數
- 布林值
-對於複雜的「複合」類型,序列化會更加複雜,因爲複合類型包含多個可能具有不同類型或不同大小或兩者都有的元素。 在這些物件都具有固定長度的情況下(即無論它們的實際值如何,元素的大小將始終保持不變),序列化只是將複合類型中的每個元素轉換爲小端位元組字串。 這些位元組字串會連結在一起。 序列化物件用位元組清單表示,清單中的元素具有固定長度,它們的排序順序與其在反序列化物件中的順序相同。
+對於複雜的「複合」類型,序列化會更加複雜,因爲複合類型包含多個可能具有不同類型或不同大小或兩者都有的元素。 在這些物件都具有固定長度的情況下 (即無論其實際值為何,元素的大小將始終保持不變),序列化只是將複合類型中的每個元素依序轉換為小端序位元組字串。 這些位元組字串會連結在一起。 序列化物件用位元組清單表示,清單中的元素具有固定長度,它們的排序順序與其在反序列化物件中的順序相同。
對於具有可變長度的類型,實際資料會被序列化物件中該元素位置的「位移」值取代。 實際資料會添加到序列化物件末尾的堆中。 位移值是堆中實際資料開始的索引,充當指向相關位元組的指針。
@@ -44,14 +44,14 @@ sidebarDepth: 2
```
-`serialized` 將具有以下結構(這裏只填充到 4 個位元,實際會填充到 32 個位元,並爲了清晰起見保留 `int` 表示):
+`serialized` 將具有以下結構 (此處只填充到 4 個位元,實際會填充到 32 個位元,並為了清楚起見保留 `int` 表示):
```
[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
------------ ----------- ----------- ----------- ----------
| | | | |
- number1 number2 offset for number 3 value for
- vector vector
+ number1 number2 vector 的 number 3 vector 的
+ 偏移 值
```
@@ -59,11 +59,11 @@ sidebarDepth: 2
```
[
- 37, 0, 0, 0, # little-endian encoding of `number1`.
- 55, 0, 0, 0, # little-endian encoding of `number2`.
- 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16).
- 22, 0, 0, 0, # little-endian encoding of `number3`.
- 1, 2, 3, 4, # The actual values in `vector`.
+ 37, 0, 0, 0, # `number1` 的小端序編碼。
+ 55, 0, 0, 0, # `number2` 的小端序編碼。
+ 16, 0, 0, 0, # 指示 `vector` 值開始位置的「偏移」(小端序 16)。
+ 22, 0, 0, 0, # `number3` 的小端序編碼。
+ 1, 2, 3, 4, # `vector` 中的實際值。
]
```
@@ -71,36 +71,35 @@ sidebarDepth: 2
```
[
- 10100101000000000000000000000000 # little-endian encoding of `number1`
- 10110111000000000000000000000000 # little-endian encoding of `number2`.
- 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16).
- 10010110000000000000000000000000 # little-endian encoding of `number3`.
- 10000001100000101000001110000100 # The actual value of the `bytes` field.
+ 10100101000000000000000000000000 # `number1` 的小端序編碼
+ 10110111000000000000000000000000 # `number2` 的小端序編碼。
+ 10010000000000000000000000000000 # 指示 `vector` 值開始位置的「偏移」(小端序 16)。
+ 10010110000000000000000000000000 # `number3` 的小端序編碼。
+ 10000001100000101000001110000100 # `bytes` 欄位的實際值。
]
```
因此,可變長度類型的實際值儲存在序列化物件末尾的堆中,它們的位移則儲存在有序欄位清單中的正確位置。
-還有一些特殊情況需要特殊處理,例如 `BitList` 類型需要在序列化過程中新增長度上限,並在反序列化過程中移除該上限。 在[簡單序列化規範](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)中查看完整詳情。
+還有一些特殊情況需要特殊處理,例如 `BitList` 類型需要在序列化過程中新增長度上限,並在反序列化過程中移除該上限。 完整細節請參閱 [SSZ 規範](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)。
### 反序列化 {#deserialization}
反序列化該物件需要一個方案。 方案會定義序列化資料的精確配置,以便每個特定元素都可以從一個位元組二進位大型物件反序列化為一些有意義的物件,其中的元素具有正確的類型、值、大小和位置。 該方案告訴反序列化器哪些值是實際值,哪些是位移值。 當物件被序列化時,所有欄位名稱都會消失,但會根據方案在反序列化時被重新具現化。
-參閱 [ssz.dev](https://www.ssz.dev/overview) 上關於此主題的互動式解釋。
+關於這一點的互動式解說,請參閱 [ssz.dev](https://www.ssz.dev/overview)。
## 默克爾化 {#merkleization}
該簡單序列化物件之後可以被默克爾化 - 即轉換爲表示相同資料的默克爾樹。 首先,確定序列化物件中的 32 位元組區塊數量。 這些都是樹的「葉子」。 葉子的總數必須為 2 的冪,以便將葉子散列到一起,最終產生單個雜湊樹根。 如果情況並非如此,則會新增包含 32 位元組零的額外葉子。 如圖所示:
```
- hash tree root
+ 哈希樹根
/ \
/ \
/ \
/ \
- hash of leaves hash of leaves
- 1 and 2 3 and 4
+ 葉 1 和 2 的哈希 葉 3 和 4 的哈希
/ \ / \
/ \ / \
/ \ / \
@@ -109,11 +108,11 @@ sidebarDepth: 2
在某些情況下,樹的葉子不會像上述範例中一樣自然均匀分佈。 例如,葉子 4 可能是一個包含多個元素的容器,需要向默克爾樹增加額外的「深度」,從而建立一棵不均匀的樹。
-與其將這些樹元素稱爲葉子 X、節點 X 等,我們可以賦予它們廣義索引,從根 = 1 開始,沿著每個層級從左往右計數。 這就是之前解釋的廣義索引。 序列化清單中的每個元素都有一個等於 `2**depth + idx` 的廣義索引,其中 idx 是其在序列化物件中的零索引位置,depth 是默克爾樹的層級數,可以計算爲元素(葉子)數量以 2 為底的對數。
+與其將這些樹元素稱爲葉子 X、節點 X 等,我們可以賦予它們廣義索引,從根 = 1 開始,沿著每個層級從左往右計數。 這就是之前解釋的廣義索引。 序列化清單中的每個元素都有一個等於 `2**depth + idx` 的廣義索引,其中 `idx` 是其在序列化物件中的零索引位置,而 `depth` 是默克爾樹的層級數,可以計算為元素 (葉) 數量以 2 為底的對數。
## 廣義索引 {#generalized-indices}
-廣義索引是一個整數,表示二進位默克爾樹中的一個節點,其中每個節點都有一個廣義索引 `2 ** depth + index in row`。
+廣義索引是一個整數,代表二元默克爾樹中的一個節點,其中每個節點都有一個廣義索引 `2 ** depth + index in row`。
```
1 --depth = 0 2**0 + 0 = 1
@@ -126,12 +125,13 @@ sidebarDepth: 2
## 多重證明 {#multiproofs}
-提供表示特定元素的廣義索引清單,以使我們可以根據雜湊樹根來對其進行驗證。 該根是我們接受的現實版本。 我們提供的任何資料都可以根據現實進行驗證,即,將資料插入默克爾樹中的正確位置(由其廣義索引確定),然後觀察根是否保持不變。 [此處](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)的規範中包含了一些函式,這些函式展示了如何計算所需的最小節點集,來驗證一組特定廣義索引的内容。
+提供表示特定元素的廣義索引清單,以使我們可以根據雜湊樹根來對其進行驗證。 該根是我們接受的現實版本。 我們提供的任何資料都可以根據現實進行驗證,即,將資料插入默克爾樹中的正確位置(由其廣義索引確定),然後觀察根是否保持不變。 在[此處](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)的規範中有函式,說明如何計算驗證特定廣義索引集內容所需的最小節點集。
-例如,爲了驗證下面樹中索引 9 中的資料,我們需要索引 8、9、5、3、1 處資料的雜湊。 (8,9) 的雜湊應該等於 (4) 的雜湊,它與 5 進行雜湊計算將產生 2,與 3 進行雜湊計算將產生樹根 1。 如果為 9 提供了不正確的資料,根將會改變,我們會檢測到這個問題並無法驗證分支。
+例如,爲了驗證下面樹中索引 9 中的資料,我們需要索引 8、9、5、3、1 處資料的雜湊。
+(8,9) 的雜湊應該等於 (4) 的雜湊,它與 5 進行雜湊計算將產生 2,與 3 進行雜湊計算將產生樹根 1。 如果為 9 提供了不正確的資料,根將會改變,我們會檢測到這個問題並無法驗證分支。
```
-* = data required to generate proof
+* = 產生證明所需的資料
1*
2 3*
@@ -140,10 +140,10 @@ sidebarDepth: 2
```
-## 進一步閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [升級以太坊:簡單序列化](https://eth2book.info/altair/part2/building_blocks/ssz)
+- [升級以太坊:SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
- [升級以太坊:默克爾化](https://eth2book.info/altair/part2/building_blocks/merkleization)
-- [簡單序列化實作](https://github.com/ethereum/consensus-specs/issues/2138)
-- [簡單序列化計算器](https://simpleserialize.com/)
+- [SSZ 實作](https://github.com/ethereum/consensus-specs/issues/2138)
+- [SSZ 計算器](https://simpleserialize.com/)
- [SSZ.dev](https://www.ssz.dev/)
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
index 858d1258106..240b399a17d 100644
--- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
@@ -1,6 +1,6 @@
---
-title: Web3 金鑰儲存的定義
-description: Web3 金鑰儲存的正式定義
+title: "Web3 金鑰儲存的定義"
+description: "Web3 金鑰儲存的正式定義"
lang: zh-tw
sidebarDepth: 2
---
diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
new file mode 100644
index 00000000000..2689f6ec42a
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
@@ -0,0 +1,195 @@
+---
+title: "Web3 金鑰儲存的定義"
+description: "Web3 金鑰儲存的正式定義"
+lang: zh-tw
+sidebarDepth: 2
+---
+
+要讓應用程式在以太坊上執行,可以使用 web3.js 程式庫提供的 web3 物件。 這樣,程式透過 RPC 呼叫來和區域節點溝通。 [web3](https://github.com/ethereum/web3.js/) 可與任何公開 RPC 層的以太坊節點搭配運作。
+
+`web3` 包含 `eth` 物件 - web3.eth。
+
+```js
+var fs = require("fs")
+var recognizer = require("ethereum-keyfile-recognizer")
+
+fs.readFile("keyfile.json", (err, data) => {
+ var json = JSON.parse(data)
+ var result = recognizer(json)
+})
+
+/** result
+ * [ 'web3', 3 ] web3 (v3) 金鑰檔案
+ * [ 'ethersale', undefined ] Ethersale 金鑰檔案
+ * null 無效的金鑰檔案
+ */
+```
+
+本文件記載了 **第 3 版** 的 Web3 秘密金鑰儲存定義。
+
+## 定義 {#definition}
+
+除了加密演算法不再綁定 AES-128-CBC 外(現在最低要求是 AES-128-CTR),和第一版對照,檔案的編碼和解碼方式差異不大。 大部分的意涵/演算法與版本 1 相似,但 `mac` 除外,其為衍生金鑰從左邊數來第二個 16 位元組與完整的 `ciphertext` 串接後,所得到的 SHA3 (keccak-256) 值。
+
+秘密金鑰檔案直接儲存在 `~/.web3/keystore` (類 Unix 系統) 和 `~/AppData/Web3/keystore` (Windows) 中。 檔案可以任意命名,但良好的慣例是 `.json`,其中 `` 是賦予秘密金鑰的 128 位元 UUID (一個為秘密金鑰地址保護隱私的代理)。
+
+所有這類的檔案都有一個相關的密碼。 若要衍生給定 `.json` 檔的秘密金鑰,請先衍生檔案的加密金鑰;作法是取得檔案的密碼,並將其傳遞給 `kdf` 金鑰中所描述的金鑰衍生函數。 傳遞至 KDF 函數的、依賴 KDF 的靜態與動態參數,皆描述於 `kdfparams` 金鑰中。
+
+KDF 函式的靜態和動態 KDF 依存參數是記述在 kdfparams 金鑰裡。
+
+- `kdf`:`pbkdf2`
+
+就 PBKDF2 而言,kdfparams 包含:
+
+- `prf`:必須是 `hmac-sha256` (未來可能會擴充);
+- `c`:迭代次數;
+- `salt`:傳遞給 PBKDF 的 salt;
+- `dklen`:衍生金鑰的長度。 必須 >= 32。
+
+一旦檔案的金鑰導出後,必須透過 MAC 的導出進行驗証。 MAC 應計算為衍生金鑰從左邊數來第二個 16 位元組,與 `ciphertext` 金鑰內容串接所形成的位元組陣列之 SHA3 (keccak-256) 哈希值,即:
+
+```js
+KECCAK(DK[16..31] ++ )
+```
+
+(其中 `++` 是串接運算子)
+
+此值應與 `mac` 金鑰的內容進行比較;如果不同,應要求提供替代密碼 (或取消操作)。
+
+在檔案的金鑰驗證完畢後,密文 (`ciphertext` 金鑰在檔案中) 即可使用由 `cipher` 金鑰指定的對稱加密演算法來解密,並透過 `cipherparams` 金鑰進行參數化。 如果衍生金鑰的長度和演算法的金鑰大小不一樣,則用 0 填滿,衍生金鑰最右邊的位元組應當用作演算法的金鑰。
+
+所有最低限度合規實作都必須支援 AES-128-CTR 演算法,表示如下:
+
+- `cipher:aes-128-ctr`
+
+這密碼取得下列參數,作為 cipherparams 金鑰的金鑰提供:
+
+- `iv`:加密用的 128 位元初始向量。
+
+加密金鑰是衍生金鑰最左邊的 16 個位元組,也就是 `DK[0..15]`。
+
+祕密金鑰的建立/加密基本上應該是這些步驟的反序操作。 請確保 `uuid`、`salt` 和 `iv` 確實是隨機的。
+
+除了 `version` 欄位應作為版本的「硬」識別碼之外,實作也可以使用 `minorversion` 來追蹤格式的較小、非破壞性變更。
+
+## 測試向量 {#test-vectors}
+
+詳細資料:
+
+- `地址`:`008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
+- `ICAP`:`XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
+- `UUID`:`3198bc9c-6672-5ab3-d9954942343ae5b6`
+- `密碼`:`testpassword`
+- `祕密金鑰`:`7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
+
+### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
+
+使用 `AES-128-CTR` 和 `PBKDF2-SHA-256` 的測試向量:
+
+`~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json` 的檔案內容:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
+ },
+ "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
+ "kdf": "pbkdf2",
+ "kdfparams": {
+ "c": 262144,
+ "dklen": 32,
+ "prf": "hmac-sha256",
+ "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
+ },
+ "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**中間值**:
+
+`衍生金鑰`:`f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551`
+`MAC 主體`:`e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46`
+`MAC`:`517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2`
+`加密金鑰`:`f06d69cdc7da0faffb1008270bca38f5`
+
+### Scrypt {#scrypt}
+
+測試向量使用 AES-128-CTR 和 Scrypt:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "740770fce12ce862af21264dab25f1da"
+ },
+ "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
+ },
+ "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**中間值**:
+
+`衍生金鑰`:`7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d`
+`MAC 主體`:`edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2`
+`MAC`:`337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c`
+`加密金鑰`:`7446f59ecc301d2d79bc3302650d8a5c`
+
+## 與版本 1 的差異 {#alterations-from-v2}
+
+此版本修正了與[此處](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst)發布的版本 1 之間的幾個不一致之處。 簡述如下:
+
+- 大小寫未對齊和不一致(scrypt 為小寫字母,Kdf 為大小寫字母混合,MAC 為大寫字母)。
+- 不必要的地址和侵害隱私權。
+- `Salt` 本質上是金鑰衍生函數的一個參數,理應與其關聯,而非與籠統的加密機制關聯。
+- `_SaltLen_` 是不必要的 (直接從 Salt 衍生即可)。
+- 給定了金鑰衍生函式,但加密演算法是硬式指定的。
+- `Version` 本質上是數值,但卻是字串 (雖然字串可以做到結構化版本管理,但對於不常變更的設定檔格式而言,這可被視為超出範圍)。
+- `KDF` 和 `cipher` 在概念上是同級概念,但組織方式卻不同。
+- `MAC` 是透過一段忽略空白字元的資料計算出來的 (!)
+
+已變更格式,賦予下列檔案等同先前連結頁面所述範例的功能:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-cbc",
+ "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
+ "cipherparams": {
+ "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
+ },
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
+ },
+ "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
+ "version": 1
+ },
+ "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
+ "version": 2
+}
+```
+
+## 與版本 2 的差異 {#alterations-from-v2}
+
+第二版是早期的 C++ 實作,有若干缺陷。 所有基本元素保留不變。
diff --git a/public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md
new file mode 100644
index 00000000000..675691753ad
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/design-and-ux/dex-design-best-practice/index.md
@@ -0,0 +1,220 @@
+---
+title: "去中心化交易所(DEX) 設計的最佳實踐"
+description: "交換代幣的 UX/UI 設計決策指南"
+lang: zh-tw
+---
+
+自 2018 年 Uniswap 推出以來,已經有數百個去中心化交易所(DEX) 在不同的區塊鏈上推出。
+其中許多去中心化交易所引入新的元素或增加自己的特色,但他們依然保有整體介面的一致性。
+
+能做到這樣的原因之一,就是遵循 Jackob 法則(Jakob’s Law):
+
+> 使用者大多數時間在使用其他網站, 他們會更喜歡您的網站與其他已經很熟悉的網站以相同方式運作。
+
+多虧有像 Uniswap、Pancakeswap 和 Sushiswap 這類型的早期創新者,DeFi 使用者對去中心化交易所(DEX)的樣貌有了共同的認知。
+因此,現在有了「最佳實踐」。 我們看到越來越多不同平台的設計逐漸標準化。 你可以將去中心化交易所的演變,看成一個大型的即時測試案例。 有用的設計被保留下來,不好的設計會被淘汰, 雖然應該要保有設計彈性,但去中心化交易所的設計應遵循某些規範。
+
+這篇文章會提到
+
+- 要引入什麼
+- 如何提升易用性
+- 如何進行有彈性的設計
+
+所有範例線框圖都是基於真實案例,專為本文製作而成。
+
+Figma 工具包就放在文末,歡迎用來加速您的線框圖設計!
+
+## 拆解去中心化交易所的基本設計要素 {#basic-anatomy-of-a-dex}
+
+UI 通常包含下列三種元素:
+
+1. 主介面
+2. 按鈕
+3. 資訊選單
+
+
+
+## 變化 {#variations}
+
+這將是本文的通用主題,但這三個元素有許多不同的組織方式。 資訊頁面的變化包含:
+
+- 位在按鍵上方
+- 位在按鍵下方
+- 隱藏在折疊區內
+- 或者是在預覽模式內
+
+請注意: 雖然預覽模式不是必要的,但若主介面顯示的資訊非常少,那就必須使用預覽模式。
+
+## 主介面的架構 {#structure-of-the-main-form}
+
+您可以在這個區塊選擇要交換的代幣。 這個元件是由一個輸入欄位與一個小型按鍵排列組成。
+
+去中心化交易所會根據使用情境,通常會在這個上方或下方,顯示額外的說明文字。
+
+
+
+## 變化 {#variations2}
+
+這裏展示了兩種用戶介面變化:一種沒有任何邊框,形成一種非常開放的設計;另一種的輸入行帶有邊框,引導使用者關注該元素。
+
+
+
+該基本結構允許顯示**四種關鍵資訊**:每個角落顯示一種。 如果只有一個頂部/底部行,則只顯示兩種資訊。
+
+隨著去中心化金融 (DeFi) 的演變,許多其他資訊也被包含在這裏。
+
+## 需要包含的關鍵資訊 {#key-info-to-include}
+
+- 錢包餘額
+- 最大化按鈕
+- 等價法定貨幣
+- 價格對「接收」金額的影響
+
+在去中心化金融的早期,等價法定貨幣常常被忽略。 無論你正在構建任何類型的 Web3 項目,顯示等價法定貨幣都是至關重要的。 用戶仍然以本地貨幣進行思考。因此,爲了與真實世界的心理模型相匹配,等價法定貨幣應該包含在内。
+
+在第二個欄位 (你選擇交換的目標代幣),你還可以透過計算輸入金額與預計輸出金額之間的差異,在法定貨幣金額旁包含價格影響。 這是一個相當實用的細節。
+
+百分比按鈕(例如:25%、50%、75%)可以是個實用的功能,但會佔用更多空間、增加更多行動呼籲,並加重心理負擔。 百分比滾滑桿亦是如此。 其中一些用戶介面的決定取決於您的品牌和使用者類型。
+
+主表單下方可以顯示額外的細節。 由於這類資訊主要針對專業的使用者,因此合理的做法有:
+
+- 盡可能最小化,或;
+- 將其隱藏在折叠面板中
+
+
+
+## 需要包含的額外資訊 {#extra-info-to-include}
+
+- 代幣價格
+- 滑點
+- 最小到帳金額
+- 預期輸出
+- 價格影響
+- 燃料成本估算
+- 其他費用
+- 訂單路徑
+
+可以説,其中一些細節是可選的。
+
+訂單路徑很有趣,但對大多數使用者來説沒什麽作用。
+
+一些其他細節只是在以不同的方式表達同樣的内容。 例如,「最小到帳金額」與「滑點」就像是同個硬幣的兩個面。 如果將滑點設爲 1%,那麽您預計收到的最小金額就是預期輸出 - 1%。 一些用戶介面會顯示預期金額,最小金額和滑點… 這些細節雖然有用,但可能過於繁瑣了。
+
+大多數用戶只會使用默認的滑點。
+
+「價格影響」通常在等價法定貨幣旁「發送至」欄位中的括號内。 該細節能夠有效提升用戶體驗,但如果已經在這裏顯示,真的還有必要在下方再次顯示嗎? 然後在預覽畫面中再顯示一次?
+
+許多使用者 (尤其是進行小額交換的使用者)不會在意這些細節;他們只會簡單地輸入數字並點擊交換。
+
+
+
+具體顯示哪些細節將取決於您的受眾,以及您希望該應用程式給使用者帶來什麽樣的感覺。
+
+如果您在詳情面板中包含了滑點容差,則還應該讓其可以在此處直接編輯。 這是一個很好的「加速器」例子;簡潔的用戶體驗可以幫助經驗豐富的使用者加快使用流程,並且不會影響應用程式的一般可用性。
+
+
+
+在思考時仔細考慮整體的流程,而非螢幕上的片面資訊是個好方法,流程如下:
+在主表格輸入數字 → 掃描詳情 → 點擊進入預覽畫面(如果有的話)
+詳情面板應該常駐顯示,還是需要經使用者點擊才展開面板?
+您是否應該透過新增預覽頁面來增加緩衝? 這非常有用,使用者必須放慢速度並考慮該交易。 但是,他們會想再看到完全一樣的資訊嗎? 此時,對使用者來說最重要的是什麼?
+
+## 設計選項 {#design-options}
+
+如前面所述,設計選項主要依您的個人風格而定
+您的目標使用者為何?
+您的品牌是什麽?
+您想要能顯示所有細節的「專業」面板,或者走極簡風?
+即使您瞄準的是想要所有資訊的專業使用者,您仍應謹記 Alan Cooper 的名言:
+
+> 無論您的介面有多美、多炫,少一點會更好。
+
+### 結構 {#structure}
+
+- 代幣在左邊或是右邊
+- 2 行或 3 行
+- 詳情顯示在按鈕上方或下方
+- 展開、最小化或者不顯示詳情頁面
+
+### 元件風格 {#component-style}
+
+- 空心
+- 描邊
+- 實心
+
+從單純使用者體驗方面來看,界面風格的重要性其實比您想像中的低。 視覺上的流行風格是循環變化的,且很多偏好都是主觀的。
+
+要感受這點,最簡單的方式就是看些範例,再自己動手試試不同的配置。
+
+文中附上的 Figma 大禮包包含了空心、描邊及實心這幾種元件。
+
+看一下下方的例子,來了解將不同元素組合在一起的各種方式。
+
+
+
+
+
+
+
+
+
+
+
+
+
+## 但代幣應該放哪邊? {#but-which-side-should-the-token-go-on}
+
+結論是:這對可用性來說可能沒有太大的影響。 不過有幾點需要注意,可能會讓您更傾向某個選擇。
+
+看著潮流隨時尚變化挺有意思的。 Uniswap 一開始將代幣放在左邊,但後來將其移到右邊。 Sushiswap 也在某次設計升級中完成了此變更。 大多(並非所有)協議也跟進了這個改變。
+
+金融慣例上,傳統是將貨幣符號置於數字之前,例如 $50、€50、£50,但我們會_說_ 50 美元、50 歐元、50 英鎊。
+
+對於一般用戶,特別是從左到右、從上到下閱讀的人,在右邊的代幣可能感覺更自然。
+
+
+
+將代幣放在左側,所有數字放在右側,看起來有令人愉悅的對稱性,這是個優點,但此布局也有其缺點。
+
+接近法則指出,彼此靠近的項目會被視為相關的。 因此,我們希望將相關的項目放在彼此旁邊。 代幣的餘額與代幣本身直接相關,且在新代幣被選擇時會隨之改變。 因此,將代幣餘額放在代幣選擇按鈕旁會更加合理一些。 也可以移到代幣下方,但這就破壞了佈局的對稱性。
+
+總之,兩個選項各有優缺。有趣的是,目前的趨勢似乎偏向把代幣放在右側。
+
+## 按鍵行為 {#button-behavior}
+
+不要給授權(Approve)獨立的按鈕。 在授權時也不要讓使用者額外點擊。 使用者想做的是交換代幣,因此直接在按鈕上顯示「交換」,並在第一步觸發授權。 可以用彈窗顯示步驟,或者顯示單純的「第 1 筆交易,共 2 筆」通知。
+
+
+
+
+
+### 按鈕作為情境式說明 {#button-as-contextual-help}
+
+按鈕可以兩用,同時具有警示功能!
+
+實際上,這在 Web3 領域之外不常見,但在 Web3 這已成為標準做法。 這是個不錯的創新,因為它可以省空間,並讓使用者保持專注。
+
+如果主要的行動 - 交換代幣 - 因錯誤而不可用,該錯誤的原因可用按鈕解說明,如:
+
+- 切換網路
+- 連接錢包
+- 各種錯誤
+
+按鈕也可以 **映射到** 需要被執行的動作。 舉例來說,如果使用者在錯誤的網路上而無法交換代幣,按鈕上應該顯示「切換到以太坊」,而當使用者點擊該按鈕時,應將網路切換至以太坊。 這種設計可以顯著提升使用者的效率。
+
+
+
+
+
+## 透過此 Figma 檔案打造您自己的設計 {#build-your-own-with-this-figma-file}
+
+多虧了多個協議的付出,去中心化交易所的設計已進步許多。 我們知道使用者需要哪些資訊、該如何顯示,以及如何讓流程盡可能絲滑。
+希望這篇文章能提供各位紮實的使用者體驗原則概述。
+
+如果您想實驗看看,歡迎使用 Figma 的線框稿設計包。 該設計包已盡可能保持簡潔,不過也有足夠的彈性,可以用多種方式建構基本結構。
+
+[Figma 線框稿設計包](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
+
+去中心化金融會持續進化,且總會有可改進的空間。
+
+祝您好運!
diff --git a/public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md
new file mode 100644
index 00000000000..6347c59449e
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/design-and-ux/heuristics-for-web3/index.md
@@ -0,0 +1,138 @@
+---
+title: "Web3 介面設計的 7 個啓發法"
+description: "改進 Web3 可用性的原則"
+lang: zh-tw
+---
+
+可用性啓發法是廣泛的 “經驗法則”,你可以用其來衡量網站的可用性。
+這 7 個啓發法是爲 Web3 量身定制的,並且應該與 Jakob Nielsen 的[介面設計的 10 條通用原則](https://www.nngroup.com/articles/ten-usability-heuristics/)一起使用。
+
+## Web3 的 7 個可用性啓發法 {#seven-usability-heuristics-for-web3}
+
+1. 操作后進行反饋
+2. 安全與信任
+3. 凸顯最重要的資訊
+4. 易於理解的術語
+5. 盡可能簡短的操作
+6. 靈活且可見的網路連接
+7. 透過應用程式而非錢包進行控制
+
+## 定義和範例 {#definitions-and-examples}
+
+### 1. 操作后進行反饋 {#feedback-follows-action}
+
+**當某些事情已經或正在發生時,應該明確地展示出來。**
+
+使用者會以前面步驟的結果為基礎,做出後續步驟的決定。 因此,確保他們隨時了解系統狀態至關重要。 這在 Web3 中尤其重要,因爲交易有時只需很短的時間就提交到區塊鏈了。 如果沒有反饋來通知他們等待,使用者將不確定是否發生了任何操作。
+
+**提示:**
+
+- 透過訊息、通知或其他警報來通知使用者。
+- 明確地傳達等待時間。
+- 如果操作需要的時間超過幾秒鐘,請用一個計時器或動畫來讓使用者放心,讓他們知道有操作正在發生。
+- 如果某個過程有多個步驟,請顯示每個步驟。
+
+**例如:**
+展示交易中涉及的每個步驟,有助於使用者了解自己正處於該過程的什麽位置。 適當的圖標能讓使用者了解他們的操作狀態。
+
+
+
+### 2. 融入安全與信任 {#security-and-trust-are-backed-in}
+
+應該優先考慮安全性,並向使用者强調這一點。
+人們非常在乎他們的資料。 安全往往是用戶的首要關注點,因此應該在設計的所有層面充分考慮安全問題。 你應該始終努力贏得使用者的信任,但實現這一點的方式在不同的應用程式中可能有不同的含義。 這不應該是事後才考慮的問題,而應該有意識地設計爲貫穿始終。 在整個使用者體驗中建立信任,包括社交頻道和相關文檔,以及最終的使用者介面。 如去中心化水平,資金庫的多重簽名狀態,以及團隊是否接受監督之類的因素,都會影響使用者的信任。
+
+**提示:**
+
+- 自豪地展示你的審核
+- 進行多次審核
+- 宣傳你設計的任何安全功能
+- 强調任何可能的風險,包括底層的整合
+- 傳達策略的複雜性
+- 考慮可能會影響使用者安全感的非使用者介面問題
+
+**範例:**
+在頁脚以顯眼的尺寸包含你的審核内容。
+
+
+
+### 3 凸顯最重要的資訊 {#the-most-important-info-is-obvious}
+
+對於複雜的系統,只展示最相關的資料。 確定那些資訊是最重要的,並優先展示它們。
+太多的資訊會讓人無所適從,並且使用者通常只依托一條資訊做出決定。 在去中心化金融 (DeFi) 中,這可能會是收益應用程式中的年化收益率和借貸應用程式中的貸款價值比。
+
+**提示:**
+
+- 使用者研究將揭示最重要的指標
+- 讓關鍵資訊變大,並讓其他細節變小且不引人注目
+- 人們不會仔細閲讀,而是一掃而過;確保你的設計是可掃視的
+
+**範例:** 在掃視時,巨大的全彩色代幣很容易就被找到。 年化收益率用大號字體和强調色突出顯示。
+
+
+
+### 4. 易於理解的術語 {#clear-terminology}
+
+術語應該是易於理解且恰儅的。
+技術行話可能構成巨大的阻礙,因爲它需要構建一個全新的心理模型。 使用者無法將設計與他們已知的詞語、短語或概念聯係起來。 一切似乎都令人感到困惑且陌生,他們需要經歷一條陡峭的學習曲綫才能嘗試使用。 使用者可能是出於省錢目的而接觸到去中心化金融的,而他們找到的卻是: 挖礦、礦池、質押、排放、賄賂、金庫、置物櫃、投票托管代幣、歸屬、時期、去中心化演算法、協議自有流動性…
+嘗試使用大多數人能夠理解的簡單術語。 不要僅僅爲你的項目發明新術語。
+
+**提示:**
+
+- 使用簡單且一致的術語
+- 盡可能多地使用現有語言
+- 不要杜撰自己的術語
+- 遵循現有的慣例
+- 盡可能對使用者進行教育
+
+**例如:**
+「你的獎勵」 是一個衆所周知的中性術語,並非為該項目創造的新詞。 代幣
+
+
+
+### 5. 盡可能簡短的操作 {#actions-are-as-short-as-possible}
+
+透過歸類子操作來加速使用者的互動。
+這可以在智能合約的層面上完成,也可以在使用者介面完成。 用戶不應該從系統的一部分移動到另一部分 - 或者完全離開系統 - 來完成一個常見的操作。
+
+**提示:**
+
+- 盡可能將「批准」與其他操作相結合
+- 盡可能將簽名步驟緊密地捆綁起來
+
+**例如:** 將「增加流動性資金」與「質押」結合起來,是一個能節省使用者時間與燃料的簡單加速器示例。
+
+
+
+### 6. 可見且靈活的網路連結 {#network-connections-are-visible-and-flexible}
+
+向用戶告知他們所連結的網路,並提供清晰的切換網路的快鍵。
+這在多鏈應用程式中尤其重要。 當斷開連結或連結到不支持的網路時,應用程式的主要功能仍然應該可見。
+
+**提示:**
+
+- 在斷開連結時盡可能多地顯示應用程式内容
+- 顯示使用者正在連結的網路
+- 不要讓使用者到錢包中切換網路
+- 如果應用程式需要使用者切換網路,請從主要行動號召中提示該操作
+- 如果應用程式包含多個網絡的市場或金庫,請明確陳述使用者目前查看的是哪一組。
+
+**例如:** 向用戶展示他們所連結的網路,並允許他們在應用程式欄中進行更改。
+
+
+
+### 7. 透過應用程式而非錢包進行控制 {#control-from-the-app-not-the-wallet}
+
+用戶介面應該告訴用戶他們需要知道的所有内容,並使他們能夠控制需要控制的一切。
+在 Web3 中,有些操作需要在使用者介面内執行,有些需要在錢包内執行。 一般而言,在使用者介面開始一項操作,然後在錢包中確認它。 如果這兩條綫沒有仔細合併,使用者可能會感覺不適應。
+
+**提示:**
+
+- 透過使用者介面中的反饋來傳達系統狀態
+- 保存他們的歷史記錄
+- 提供先前交易的區塊瀏覽器連結
+- 提供切換網路的快捷鍵。
+
+**範例:**一個設計巧妙的容器,向使用者顯示了其錢包中的相關代幣,且主要的行動呼籲按鈕提供了切換網路的快捷鍵。
+
+
diff --git a/public/content/translations/zh-tw/developers/docs/design-and-ux/index.md b/public/content/translations/zh-tw/developers/docs/design-and-ux/index.md
new file mode 100644
index 00000000000..abf203418b7
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/design-and-ux/index.md
@@ -0,0 +1,86 @@
+---
+title: "Web3 中的設計和用戶體驗"
+description: "介紹 Web3 領域和以太坊中的用戶體驗設計和研究"
+lang: zh-tw
+---
+
+你不熟悉用以太坊進行設計嗎? 如果是的話,那麼這個地方你來對了。 以太坊社區中有很多介紹 Web3 的設計和研究資源。 你將學習一些核心概念,它們可能與你熟悉的其他應用程式設計不同。
+
+需要先對 Web3 有更基本的瞭解嗎? 查看 [**學習中心**](/learn/)。
+
+## 從使用者研究開始 {#start-with-user-research}
+
+實用的介面設計勝過只是視覺上吸引人的設計, 還涉及到深入瞭解用戶需求、目標以及驅動因素。 因此,我們強烈建議所有設計師採用設計流程,例如 [**雙鑽石設計流程**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)),以確保其工作是經過深思熟慮且有目的性的。
+
+- [Web3 需要更多使用者體驗研究員與設計師](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - 當前設計成熟度概覽
+- [web3 使用者體驗研究簡易指南](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - 如何進行研究的簡易指南
+- [如何在 Web3 中處理使用者體驗決策](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - 量化和質化研究及其差異簡介 (影片,6 分鐘)
+- [在 web3 中擔任使用者體驗研究員](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - 關於在 web3 中擔任使用者體驗研究員的個人看法
+
+## Web3 研究 {#research-in-web3}
+
+以下是一份可以幫助激發設計靈感和產品決策的精選清單:
+
+| 聚焦領域 | 名稱 |
+| :------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 加密貨幣入門 | [The Reown Pulse 2024:加密貨幣消費者情緒與使用情況](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) |
+| 加密貨幣入門 | [CRADL:加密貨幣的使用者體驗](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
+| 加密貨幣入門 | [CRADL:加密貨幣入門](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
+| 加密貨幣入門 | [比特幣使用者體驗報告](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
+| 加密貨幣入門 | [Consensys:2023 年全球 Web3 認知狀況](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
+| 加密貨幣入門 | [NEAR:加速採用之旅](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
+| 質押 | [OpenUX:Rocket Pool 節點營運商使用者體驗](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) |
+| 質押 | [質押:主要趨勢、重點和預測 - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
+| 質押 | [多應用程式質押](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
+| DAO | [2022 年 DAO 研究更新:DAO 建立者需要什麼?](https://blog.aragon.org/2022-dao-research-update/) |
+| DeFi | [保險資金池](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
+| DeFi | [Consensys:2022 年 DeFi 使用者研究報告](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
+| 元宇宙 | [元宇宙:使用者研究報告](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
+| 元宇宙 | [實地探查:在元宇宙中研究使用者](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (影片,27 分鐘) |
+
+## 為 Web3 設計 {#design-for-web3}
+
+- [Web3 使用者體驗設計手冊](https://web3ux.design/) - 設計 Web3 應用程式的實用指南
+- [Web3 設計原則](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - 基於區塊鏈的去中心化應用程式的使用者體驗規則框架
+- [區塊鏈設計原則](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - IBM 區塊鏈設計團隊學到的經驗教訓
+- [Neueux.com](https://neueux.com/apps) - 具有多種篩選選項的使用者流程 UI 庫
+- [Web3 的可用性危機:您需要知道的事!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - 關於以開發者為中心的專案建設陷阱的小組討論 (影片,34 分鐘)
+
+## 入門 {#getting-started}
+
+- [Web3 啟發式原則](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 項 Web3 介面設計的啟發式原則
+- [DEX 設計最佳實踐](/developers/docs/design-and-ux/dex-design-best-practice/) - 去中心化交易所設計指南
+
+## Web3 設計案例研究 {#design-case-studies}
+
+- [Deep Work Studio](https://www.deepwork.studio/case-studies)
+- [在 OpenSea 上販售 NFT](https://builtformars.com/case-studies/opensea)
+- [錢包使用者體驗剖析:錢包需要如何改變](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (影片,20 分鐘)
+
+## 設計懸賞 {#bounties}
+
+- [Dework](https://app.dework.xyz/bounties)
+- [Buildbox 駭客松](https://app.buidlbox.io/)
+- [ETHGlobal 駭客松](https://ethglobal.com/)
+
+## 設計 DAO 和社群 {#design-daos-and-communities}
+
+一起投入專業的自治組織或加入設計團體,與成員們聊聊設計、研究相關主題與趨勢。
+
+- [Vectordao.com](https://vectordao.com/)
+- [Deepwork.studio](https://www.deepwork.studio/)
+- [We3.co](https://we3.co/)
+- [Openux.xyz](https://openux.xyz/)
+
+## 設計系統和其他設計資源 {#design-systems-and-resources}
+
+- [Optimism 設計](https://www.figma.com/@optimism) (Figma)
+- [Ethereum.org 設計系統](https://www.figma.com/@ethdotorg) (Figma)
+- [Finity,Polygon 的設計系統](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma)
+- [Kleros 設計系統](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
+- [Safe 設計系統](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
+- [ENS 設計系統](https://thorin.ens.domains/)
+- [Mirror 設計系統](https://degen-xyz.vercel.app/)
+
+**本頁所列的文章和專案並非官方背書**,僅供參考。
+我們根據 [刊登政策](/contributing/design/adding-design-resources) 中的標準在本頁面新增連結。 如果您希望我們新增專案/文章,請在 [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) 上編輯此頁面。
diff --git a/public/content/translations/zh-tw/developers/docs/development-networks/index.md b/public/content/translations/zh-tw/developers/docs/development-networks/index.md
index ef2f6d3af87..1411497a997 100644
--- a/public/content/translations/zh-tw/developers/docs/development-networks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/development-networks/index.md
@@ -1,6 +1,6 @@
---
-title: 開發網路
-description: 可用於協助構建以太坊應用程式的開發網路和工具的概觀。
+title: "開發網路"
+description: "可用於協助構建以太坊應用程式的開發網路和工具的概觀。"
lang: zh-tw
---
@@ -8,25 +8,25 @@ lang: zh-tw
與在電腦上執行本地伺服器進行 Web 開發的方式類似,你可以使用開發網路建立本機區塊鏈執行個體來測試你的去中心化應用程式。 這些以太坊開發網路提供的功能比公共測試網的迭代速度快得多(例如,你不需要從測試網水龍頭取得以太幣)。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入瞭解開發網路之前,應該先瞭解[以太坊堆疊的基礎知識](/developers/docs/ethereum-stack/)和[以太坊網路](/developers/docs/networks/)。
+在深入研究開發網路前,您應先了解 [以太坊技術堆疊](/developers/docs/ethereum-stack/) 和 [以太坊網路](/developers/docs/networks/) 的基礎知識。
## 什麼是開發網路? {#what-is-a-development-network}
開發網路本質上是專為本地開發而設計的以太坊用戶端(以太坊的實作)。
-**為什麼不在本地運行一個標準的以太坊節點呢?**
+**為什麼不直接在本機執行標準的以太坊節點?**
-你_可以_[運行節點](/developers/docs/nodes-and-clients/#running-your-own-node),但由於開發網路是專門為開發而建立,它們往往會具有一些快速方便的功能,例如:
+您_可以_ [執行一個節點](/developers/docs/nodes-and-clients/#running-your-own-node),但因為開發網路是專為開發而打造的,所以通常會內建許多便利功能,例如:
-- 確定性地用資料植入你的本地區塊鏈(例如具有以太幣餘額的帳戶)
+- 以確定性方式將資料 (例如:具有 ETH 餘額的帳戶) 植入您的本機區塊鏈
- 用接收的每筆交易,依照順序及零延遲即時產生區塊
- 增強的偵錯和日誌記錄功能
## 可用工具 {#available-projects}
-**注意**:大多數[開發架構](/developers/docs/frameworks/)包含一個內建開發網路。 推薦你從一個架構開始[設定你的本地開發環境](/developers/local-environment/)。
+**注意**:大多數 [開發框架](/developers/docs/frameworks/) 都包含內建的開發網路。 我們建議從一個框架開始 [設定您的本機開發環境](/developers/local-environment/)。
### Hardhat 網路 {#hardhat-network}
@@ -35,25 +35,20 @@ lang: zh-tw
Hardhat 網路內建了 Hardhat,這是一個專業以太坊開發環境。
- [網站](https://hardhat.org/)
-- [Github](https://github.com/nomiclabs/hardhat)
+- [GitHub](https://github.com/NomicFoundation/hardhat)
-### 本地信標鏈 {#local-beacon-chains}
+### 本機信標鏈 {#local-beacon-chains}
一些共識用戶端具有內建工具,用於啟動本地信標鏈以進行測試。 Lighthouse、Nimbus 和 Lodestar 的說明如下:
-- [使用 Lodestar 的本地測試網](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
-- [使用 Lighthouse 的本地測試網](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
+- [使用 Lodestar 的本機測試網](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
+- [使用 Lighthouse 的本機測試網](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
-### 公共以太坊測試鏈 {#public-beacon-testchains}
+### 公開以太坊測試鏈 {#public-beacon-testchains}
-以太坊目前有兩個維護中的公共測試網:Sepolia 和 Hoodi。 推薦開發者使用 Sepolia 作為主要測試網,因為它是一個輕量級的測試鏈,預計在可預見的未來會繼續維護。Sepolia 上有獲得許可的驗證者集,這意味著普通用戶無法在此測試網上部署新的驗證者。Hoodi 是一個較新的測試網,允許任何人自由成為驗證者,適合進行質押和驗證者測試。
+以太坊還有兩個維護中的公共測試實作:Sepolia 和 Hoodi。 推薦使用受長期受支援的測試網 Hoodi,任何人都可以自由在其上驗證。 Sepolia 使用許可制的驗證者集合,這意味著在該測試網中沒有面向公衆的心驗證者訪問權限。
-- [Sepolia 水龍頭](https://faucet.sepolia.dev/)
-- [Hoodi 質押啟動面板](https://holesky.launchpad.ethereum.org/)
-
-請注意,Goerli 已被棄用,Ropsten、Rinkeby 和 Kiln 測試網已停用。
-
-- [測試網棄用公告](https://blog.ethereum.org/2022/06/21/testnet-deprecation)
+- [Hoodi 質押啟動面板](https://hoodi.launchpad.ethereum.org/)
### Kurtosis 以太坊套件 {#kurtosis}
@@ -62,15 +57,15 @@ Kurtosis 是一個用於多容器測試環境的構建系統,讓開發者能
以太坊 Kurtosis 套件可用於透過 Docker 或 Kubernetes 快速具現化一個可參數化、高擴展性的私人以太坊測試網。 此套件支援所有主要的執行層 (EL) 和共識層 (CL) 用戶端。 Kurtosis 從容處理代表網路的所有本地端口映射和服務連線,以用於與以太坊核心基礎設施相關的驗證和測試工作流程。
- [以太坊網路套件](https://github.com/kurtosis-tech/ethereum-package)
-- [官網](https://www.kurtosis.com/)
+- [網站](https://www.kurtosis.com/)
- [GitHub](https://github.com/kurtosis-tech/kurtosis)
-- [文件](https://docs.kurtosis.com/)
+- [說明文件](https://docs.kurtosis.com/)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [開發架構](/developers/docs/frameworks/)
-- [設定本地開發環境](/developers/local-environment/)
+- [開發框架](/developers/docs/frameworks/)
+- [設定本機開發環境](/developers/local-environment/)
diff --git a/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md b/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md
index 6521b5a8681..61bb404bdd2 100644
--- a/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md
+++ b/public/content/translations/zh-tw/developers/docs/ethereum-stack/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊堆疊簡介
-description: 演練以太坊堆疊的不同層以及它們如何組合在一起。
+title: "以太坊堆疊簡介"
+description: "演練以太坊堆疊的不同層以及它們如何組合在一起。"
lang: zh-tw
---
@@ -8,54 +8,54 @@ lang: zh-tw
然而,以太坊的核心元件有助於為軟體應用程式如何與以太坊區塊鏈互動提供思維模型。 理解堆疊的各層將幫助瞭解將以太坊整合到軟體專案中的不同方式。
-## 等級 1:以太坊虛擬機器 {#ethereum-virtual-machine}
+## 第 1 層:以太坊虛擬機 {#ethereum-virtual-machine}
-[以太坊虛擬機器](/developers/docs/evm/)是以太坊上智慧型合約的執行階段環境。 以太坊區塊鏈上的所有智慧型合約和狀態變更均由[交易](/developers/docs/transactions/)執行。 以太坊虛擬機器負責處理以太坊網路上的所有交易。
+[以太坊虛擬機 (EVM)](/developers/docs/evm/) 是以太坊上智慧型合約的執行環境。 以太坊區塊鏈上的所有智慧型合約和狀態變更都是透過[交易](/developers/docs/transactions/)執行的。 以太坊虛擬機器負責處理以太坊網路上的所有交易。
與任何虛擬機器一樣,以太坊虛擬機器在執行程式碼和執行機器(以太坊節點)之間建立了一個抽象層。 目前,以太坊虛擬機器運行在分佈於全球的數千個節點上。
-在後台,以太坊虛擬機器使用一組操作碼指令來執行特定任務。 這些(140 個獨特的)操作碼讓以太坊虛擬機器是**圖靈完備**的,這表示只要提供足夠資源,以太坊虛擬機器就可以進行任何運算。
+在後台,以太坊虛擬機器使用一組操作碼指令來執行特定任務。 這 140 個獨特的操作碼讓 EVM [圖靈完備](https://en.wikipedia.org/wiki/Turing_completeness),這表示只要有足夠的資源,EVM 就能計算幾乎任何東西。
作為去中心化應用程式開發者,不需要瞭解太多關於以太坊虛擬機器的知識,只需要瞭解其存在以及能夠可靠地為以太坊上的所有應用程式提供無停機的支援。
-## 等級 2:智慧型合約 {#smart-contracts}
+## 第 2 層:智慧型合約 {#smart-contracts}
-[智慧型合約](/developers/docs/smart-contracts/)為在以太坊區塊鏈上運行的可執行程式。
+[智慧型合約](/developers/docs/smart-contracts/) 是在以太坊區塊鏈上運行的可執行程式。
-智慧型合約使用特定[程式語言](/developers/docs/smart-contracts/languages/)來編譯至以太坊虛擬機器位元組碼(稱為操作碼的低階機器指令)。
+智慧型合約是使用特定的[程式語言](/developers/docs/smart-contracts/languages/)撰寫的,可編譯成 EVM 位元組碼 (稱為操作碼的低階機器指令)。
-智慧型合約不僅充當開源程式庫,而且本質上是始終運行且無法關閉的開放應用程式介面服務。 智慧型合約提供使用者和應用程式([去中心化應用程式](/developers/docs/dapps/))無需許可即可與之互動的公共功能。 任何應用程式都可以與已部署的智慧型合約整合以構成功能,例如新增[資料饋送](/developers/docs/oracles/)或支援代幣兌換。 此外,任何人都可以將新的智慧型合約部署到以太坊,以新增自訂功能來滿足其應用程式的需求。
+智慧型合約不僅充當開源程式庫,而且本質上是始終運行且無法關閉的開放應用程式介面服務。 智慧型合約提供公開函式,使用者和應用程式 ([去中心化應用程式](/developers/docs/dapps/)) 無需許可即可與之互動。 任何應用程式都可以與已部署的智慧型合約整合,以組合出新功能,例如新增[資料饋送](/developers/docs/oracles/)或支援代幣交換。 此外,任何人都可以將新的智慧型合約部署到以太坊,以新增自訂功能來滿足其應用程式的需求。
作為去中心化應用程式開發者,只有當你想在以太坊區塊鏈上新增自訂功能時,才需要編寫智慧型合約。 你可能會發現,只需與現有智慧型合約整合即可實現專案的大部分或全部需求,例如,如果想支援穩定幣支付或實現代幣的去中心化交易。
-## 等級 3:以太坊節點 {#ethereum-nodes}
+## 第 3 層:以太坊節點 {#ethereum-nodes}
-為了使應用程式能夠與以太坊區塊鏈互動,必須連結至[以太坊節點](/developers/docs/nodes-and-clients/)。 連結至節點可讓你讀取區塊鏈資料和/或將交易傳送到網路。
+應用程式若要與以太坊區塊鏈互動,就必須連接到[以太坊節點](/developers/docs/nodes-and-clients/)。 連結至節點可讓你讀取區塊鏈資料和/或將交易傳送到網路。
以太坊節點是運行軟體的電腦 - 以太坊用戶端。 用戶端是以太坊的實作,會驗證每個區塊中的所有交易,保持網路安全和資料準確。 **以太坊節點就是以太坊區塊鏈**。 以太坊節點共同存儲以太坊區塊鏈的狀態,並就交易達成共識以改變區塊鏈狀態。
-透過將你的應用程式連結到以太坊節點(透過 [JSON-RPC 應用程式介面](/developers/docs/apis/json-rpc/)),應用程式能夠從區塊鏈讀取資料(例如使用者帳戶餘額)並向網路廣播新交易(例如在使用者帳戶之間轉移以太幣或執行智慧型合約的功能)。
+將應用程式連接到以太坊節點 (透過 [JSON-RPC API](/developers/docs/apis/json-rpc/)) 後,應用程式便能夠從區塊鏈讀取資料 (例如使用者帳戶餘額),也能向網路廣播新交易 (例如在使用者帳戶之間轉移 ETH 或執行智慧型合約的函式)。
-## 等級 4:以太坊用戶端應用程式介面 {#ethereum-client-apis}
+## 第 4 層:以太坊用戶端 API {#ethereum-client-apis}
許多便利的程式庫(由以太坊的開源社群建立和維護)允許你的應用程式連結到以太坊區塊鏈並與之通訊。
-如果你的面向使用者的應用程式是網路應用程式,可以選擇直接在前端透過 `npm install` 安裝 [JavaScript API](/developers/docs/apis/javascript/)。 或者,你可能會選擇使用 [Python](/developers/docs/programming-languages/python/) 或 [Java](/developers/docs/programming-languages/java/) 應用程式介面在伺服器端實作此功能。
+如果你的使用者導向應用程式是網頁應用程式,你可以選擇直接在前端用 `npm install` 安裝 [JavaScript API](/developers/docs/apis/javascript/)。 或者,你也可以選擇在伺服器端,使用 [Python](/developers/docs/programming-languages/python/) 或 [Java](/developers/docs/programming-languages/java/) API 來實作此功能。
-雖然這些應用程式介面不是堆疊的必要組成部分,但顯著降低了與以太坊節點直接互動的複雜度。 這些應用程式介面還提供公用程式功能(例如將 ETH 轉換為 Gwei),使得開發者可以花更少的時間處理複雜的以太坊用戶端,將更多的時間專注於應用程式的特定功能。
+雖然這些應用程式介面不是堆疊的必要組成部分,但顯著降低了與以太坊節點直接互動的複雜度。 它們也提供工具函式 (例如,將 ETH 轉換為 Gwei),因此開發人員可以花更少的時間處理以太坊用戶端的複雜細節,而將更多時間專注在應用程式的特定功能上。
-## 等級 5:終端使用者應用程式 {#end-user-applications}
+## 第 5 層:終端使用者應用程式 {#end-user-applications}
堆疊的頂層是面向使用者的應用程式。 它們是目前經常使用和建立的標準應用程式:主要是 Web 和行動應用程式。
開發這些使用者介面的方式基本上保持不變。 通常,使用者不需要知道他們正在使用的應用程式是使用區塊鏈建立的。
-## 準備好選擇你的堆疊了嗎? {#ready-to-choose-your-stack}
+## 準備好選擇你的堆疊了嗎? 準備好選擇你的技術堆疊了嗎? {#ready-to-choose-your-stack}
-請查看我們的指南,瞭解如何為你的以太坊應用程式[設定本地開發環境](/developers/local-environment/)。
+請參閱我們的指南,為你的以太坊應用程式[設定本機開發環境](/developers/local-environment/)。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [Web 3.0 應用程式的架構](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/evm/index.md b/public/content/translations/zh-tw/developers/docs/evm/index.md
index 15bd936d253..61e310d41c8 100644
--- a/public/content/translations/zh-tw/developers/docs/evm/index.md
+++ b/public/content/translations/zh-tw/developers/docs/evm/index.md
@@ -1,62 +1,72 @@
---
-title: 以太坊虛擬機 (EVM)
-description: 以太坊虛擬機及其與網路狀態、交易、智慧型合約之間關係之介紹。
+title: "以太坊虛擬機 (EVM)"
+description: "以太坊虛擬機及其與網路狀態、交易、智慧型合約之間關係之介紹。"
lang: zh-tw
---
-以太坊虛擬機 (EVM) 是去中心化的虛擬環境,可以跨所有以太坊節點一致且安全地執行程式碼。 節點運行以太坊虛擬機來執行智慧型合約,使用「[燃料](/gas/)」來衡量[運算](/developers/docs/evm/opcodes/)所需的算力,確保高效的資源分配和網路安全。
+以太坊虛擬機 (EVM) 是去中心化的虛擬環境,可以跨所有以太坊節點一致且安全地執行程式碼。 節點運行 EVM 來執行智能合約,使用「[gas](/developers/docs/gas/)」來衡量[運算](/developers/docs/evm/opcodes/)所需的計算量,確保資源有效分配和網路安全。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-首先,對電腦科學之常用術語,例如[字節位元組](https://wikipedia.org/wiki/Byte)、[記憶體](https://wikipedia.org/wiki/Computer_memory)及[堆疊](https://wikipedia.org/wiki/Stack_(abstract_data_type))等有一個基本認知,才能夠理解以太坊虛擬機。 熟悉密碼學/區塊鏈概念,如[雜湊函式](https://wikipedia.org/wiki/Cryptographic_hash_function)和[梅克爾樹](https://wikipedia.org/wiki/Merkle_tree)等也有幫助。
+若要了解 EVM,必須對電腦科學中的常用術語,例如 [bytes](https://wikipedia.org/wiki/Byte)、[memory](https://wikipedia.org/wiki/Computer_memory) 和 [stack](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)) 等有基本認識。 熟悉[哈希函數](https://wikipedia.org/wiki/Cryptographic_hash_function)和[默克爾樹](https://wikipedia.org/wiki/Merkle_tree)等密碼學/區塊鏈概念也會很有幫助。
-## 從帳本至狀態機 {#from-ledger-to-state-machine}
+## 從帳本到狀態機 {#from-ledger-to-state-machine}
我們經常使用「分佈式帳本」這一比喻來描述比特幣一類的區塊鏈,區塊鏈透過使用一些基礎加密工具來支持去中心化貨幣。 帳本維護著活動記錄,並且必須遵守一套管控帳本修改相關操作的規則。 例如,比特幣地址無法花費超出其先前接受數量之比特幣。 此類規則構成比特幣及其他區塊鏈上所有交易的基礎。
-盡管以太坊有著自己的原生加密貨幣(以太幣)且遵循幾乎相同的直觀規則,但它還支持一種更加強大的功能:[智慧型合約](/developers/docs/smart-contracts/)。 對於此更為複雜的功能,需要一種更貼切之比喻來形容以太坊。 以太坊並非分佈式帳本,而是一種分佈式[狀態機](https://wikipedia.org/wiki/Finite-state_machine)。 以太坊狀態為一種龐大資料結構,其中不僅包含所有帳戶與餘額還包括_機器狀態_,機器狀態能夠遵照先前定義的一套規則在區塊之間變化並能執行任何機器程式碼。 在區塊之間變更狀態的具體規則由以太坊虛擬機定義。
+雖然以太坊有自己的原生加密貨幣 (以太幣),遵循著幾乎完全相同的直觀規則,但它也啟用了一項更強大的功能:[智能合約](/developers/docs/smart-contracts/)。 對於此更為複雜的功能,需要一種更貼切之比喻來形容以太坊。 以太坊不是分散式帳本,而是分散式[狀態機](https://wikipedia.org/wiki/Finite-state_machine)。 以太坊的狀態是一個龐大的資料結構,不僅保存了所有帳戶和餘額,還保存了一個「_機器狀態_」。這個狀態可以根據預先定義的一組規則,在區塊之間變更,並且可以執行任意機器程式碼。 在區塊之間變更狀態的具體規則由以太坊虛擬機定義。
- _此圖源於[以太坊EVM圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-## 以太坊狀態轉換函式 {#the-ethereum-state-transition-function}
+## 以太坊狀態轉換函數 {#the-ethereum-state-transition-function}
-以太坊虛擬機的運行類似於數學函式:提供一個輸入,就會生成確定的輸出。 因此,更加正式地描述以太坊具有**狀態轉換函式**將很有幫助:
+以太坊虛擬機的運行類似於數學函式:提供一個輸入,就會生成確定的輸出。 因此,將以太坊更正式地描述為具有**狀態轉換函數**會很有幫助:
```
Y(S, T)= S'
```
-提供一個舊的有效狀態 `(S)` 及一組新的有效交易 `(T)`,以太坊狀態轉換函式 `Y(S, T)` 將生成一個新的有效輸出狀態 `S'`。
+給定一個舊的有效狀態 `(S)` 和一組新的有效交易 `(T)`,以太坊狀態轉換函數 `Y(S, T)` 會產生一個新的有效輸出狀態 `S'`。
### 狀態 {#state}
-在以太坊情境下,狀態為一個龐大的資料結構,稱為[改進的梅克爾帕特里夏樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/),該樹保存由雜湊值連接在一起的所有[帳戶](/developers/docs/accounts/)且可回朔至在區塊鏈上儲存的單一根哈希。
+在以太坊的脈絡中,狀態是一個龐大的資料結構,稱為[改良式 Merkle Patricia 樹](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/),它將所有[帳戶](/developers/docs/accounts/)以哈希連結,並可歸納為儲存在區塊鏈上的單一根哈希。
### 交易 {#transactions}
-交易為完全由帳戶指令加密簽章. 交易主要有兩種類型:一種交易發起訊息調用,一種啟動合約建立。
+交易是帳戶發出的帶密碼學簽章的指令。 交易主要有兩種類型:一種交易發起訊息調用,一種啟動合約建立。
-合約建立將建立一個新合約帳戶,其中包含已編譯的[智慧型合約](/developers/docs/smart-contracts/anatomy/)位元組碼。 當其他帳戶對該合約進行訊息調用時,將執行該合約的位元組碼。
+創建合約會產生一個新的合約帳戶,其中包含已編譯的[智能合約](/developers/docs/smart-contracts/anatomy/)位元組碼。 當其他帳戶對該合約進行訊息調用時,將執行該合約的位元組碼。
-## 以太坊虛擬機相關說明 {#evm-instructions}
+## EVM 指令 {#evm-instructions}
-以太坊虛擬機的執行類似於[堆疊機](https://wikipedia.org/wiki/Stack_machine),執行深度為 1024 個專案。 每個專案均為 256 位元的字,選擇它是為了方便用於 256 位元加密(例如,Keccak-256 雜湊或 secp256k1 簽章)。
+EVM 作為[堆疊機](https://wikipedia.org/wiki/Stack_machine)執行,深度為 1024 個項目。 每個專案均為 256 位元的字,選擇它是為了方便用於 256 位元加密(例如,Keccak-256 雜湊或 secp256k1 簽章)。
-執行過程中,以太坊虛擬機維持一個臨時_記憶體_(即字尋址字元陣列),該記憶體於交易間隔期間不存在。
+在執行期間,EVM 會維護一個暫時性的「_記憶體_」(一個字組定址的位元組陣列),此記憶體在不同交易之間不會留存。
-然而,合約確實包含一棵梅克爾帕特里夏_儲存_樹(即字尋址字陳列),該樹與相關帳戶關聯且是全域狀態的一部分。
+### 暫時性儲存
-已編譯的智慧型合約位元組碼作為一些以太坊虛擬機[作業碼](/developers/docs/evm/opcodes)執行,後者執行標準堆疊操作,例如 `XOR`、`AND`、`ADD`、`SUB` 等。 以太坊虛擬機亦可透過一些區塊鏈特定的堆疊操作實作,例如 `ADDRESS`、`BALANCE`、`BLOCKHASH` 等。
+暫時性儲存是每個交易的鍵值儲存庫,可透過 `TSTORE` 和 `TLOAD` 操作碼存取。 它會在同個交易內的所有內部呼叫中持續存在,但在交易結束時會被清除。 與記憶體不同,暫時性儲存被塑模為 EVM 狀態的一部分,而非執行框架,但它不會被提交到全域狀態。 暫時性儲存可以在交易期間,讓內部呼叫以符合 gas 效益的方式共享暫時狀態。
- _圖表源於[以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+### 儲存
-## 以太坊虛擬機實作 {#evm-implementations}
+合約包含一個 Merkle Patricia _儲存_樹(一個字組定址的字組陣列),與相關帳戶關聯,並且是全域狀態的一部分。 這種永久性儲存與暫時性儲存不同,暫時性儲存僅在單一交易期間可用,且不構成帳戶永久性儲存樹的一部分。
+
+### 作業碼
+
+已編譯的智能合約位元組碼會以多個 EVM [操作碼](/developers/docs/evm/opcodes)的形式執行,這些操作碼會執行標準的堆疊操作,例如 `XOR`、`AND`、`ADD`、`SUB` 等。 EVM 也實作了一些區塊鏈專用的堆疊操作,例如 `ADDRESS`、`BALANCE`、`BLOCKHASH` 等。 操作碼集還包括 `TSTORE` 和 `TLOAD`,可用來存取暫時性儲存。
+
+
+_圖表改編自 [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+## EVM 實作 {#evm-implementations}
所有以太坊虛擬機實作均須遵照以太坊黃皮書中規定的相關規範。
-在以太坊九年的歷程中,以太坊虛擬機經歷了數次修改,有著各種不同程式語言的以太坊虛擬機實作。
+在以太坊十年的歷史中,EVM 經歷了數次修訂,並且有以各種程式語言撰寫的數種 EVM 實作版本。
-[以太坊執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)包含以太坊虛擬機實作。 此外,還有一些獨立的實作,包括:
+[以太坊執行用戶端](/developers/docs/nodes-and-clients/#execution-clients)包含一個 EVM 實作。 此外,還有一些獨立的實作,包括:
- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_
- [evmone](https://github.com/ethereum/evmone) - _C++_
@@ -66,12 +76,12 @@ Y(S, T)= S'
## 延伸閱讀 {#further-reading}
- [以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [Jellopaper 亦稱為 KEVM:K 框架中的以太坊虛擬機語意](https://jellopaper.org/)
-- [The Beigepaper](https://github.com/chronaeon/beigepaper)
-- [以太坊虛擬機作業碼](https://www.ethervm.io/)
-- [以太坊虛擬機作業碼互動式參考資料](https://www.evm.codes/)
-- [Solidity 文件簡介](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
-- [掌握以太坊 - 以太坊虛擬機 (EVM)](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
+- [Jellopaper 又名 KEVM:K 框架中的 EVM 語意學](https://jellopaper.org/)
+- [米色論文](https://github.com/chronaeon/beigepaper)
+- [以太坊虛擬機操作碼](https://www.ethervm.io/)
+- [以太坊虛擬機操作碼互動式參考](https://www.evm.codes/)
+- [Solidity 文件中的簡短介紹](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
+- [精通以太坊 - 以太坊虛擬機](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
## 相關主題 {#related-topics}
diff --git a/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md b/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
index 58812e2ebd4..30b44830d5e 100644
--- a/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
+++ b/public/content/translations/zh-tw/developers/docs/evm/opcodes/index.md
@@ -1,174 +1,177 @@
---
-title: 以太坊虛擬機的作業碼
-description: 以太坊虛擬機可用的所有作業碼清單。
+title: "以太坊虛擬機的作業碼"
+description: "以太坊虛擬機可用的所有作業碼清單。"
lang: zh-tw
---
-## 概觀 {#overview}
+## 概覽 {#overview}
-本文是以太坊虛擬機參考頁面的更新版本,網址為:[wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes)。 同樣取自[黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/) 和 [geth](https://github.com/ethereum/go-ethereum) 實作。 本文意圖成为方便參考的頁面,但並非特別嚴謹。 若你想確定正確性並了解每種邊界案例(指僅在極端工作參數下才會發生的問題或情況),建議使用 Jello Paper 或用戶端實作。
+這是 [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) 上 EVM 參考頁面的更新版本。
+內容也參考自 [黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)、[Jello Paper](https://jellopaper.org/evm/) 和 [geth](https://github.com/ethereum/go-ethereum) 的實作。
+本文意圖成為方便參考的頁面,但並非特別嚴謹。
+若你想確定正確性並了解每種邊界案例(指僅在極端工作參數下才會發生的問題或情況),建議使用 Jello Paper 或用戶端實作。
-正在尋找互動式參考資料? 請瀏覽 [evm.codes](https://www.evm.codes/)
+正在尋找互動式參考資料? 請查看 [evm.codes](https://www.evm.codes/)。
-關於燃料費用為動態的操作,請查看 [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)。
+關於動態 gas 成本的操作,請參閱 [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md)。
-💡 快速提示:要檢視整行,可以用 `[shift] + 滑鼠滾輪`在桌面上水平滾動。
+💡 快速提示:若要檢視完整一行,請使用 `[shift] + scroll` 在桌上型電腦上水平捲動。
-| 堆疊 | 名稱 | 燃料 | 初始堆疊 | 最終堆疊 | 記憶體/儲存空間 | 注釋 |
-|:-----:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 00 | STOP | 0 | | | | halt execution |
-| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 |
-| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 |
-| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 |
-| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division |
-| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division |
-| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus |
-| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus |
-| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N |
-| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N |
-| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 |
-| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes |
-| 0C-0F | _invalid_ | | | | | |
-| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than |
-| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than |
-| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than |
-| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than |
-| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality |
-| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero |
-| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND |
-| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR |
-| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR |
-| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT |
-| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left |
-| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left |
-| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right |
-| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right |
-| 1E-1F | _invalid_ | | | | | |
-| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
-| 21-2F | _invalid_ | | | | | |
-| 30 | ADDRESS | 2 | `。` | `address(this)` | | address of executing contract |
-| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei |
-| 32 | ORIGIN | 2 | `。` | `tx.origin` | | address that originated the tx |
-| 33 | CALLER | 2 | `。` | `msg.sender` | | address of msg sender |
-| 34 | CALLVALUE | 2 | `。` | `msg.value` | | msg value, in wei |
-| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` |
-| 36 | CALLDATASIZE | 2 | `。` | `len(msg.data)` | | length of msg data, in bytes |
-| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data |
-| 38 | CODESIZE | 2 | `。` | `len(this.code)` | | length of executing contract's code, in bytes |
-| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode |
-| 3A | GASPRICE | 2 | `。` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
-| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes |
-| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` |
-| 3D | RETURNDATASIZE | 2 | `。` | `size` | | size of returned data from last external call, in bytes |
-| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `。` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
-| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 |
-| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `。` | `block.coinbase` | | 目前區塊提交者的地址 |
-| 42 | TIMESTAMP | 2 | `。` | `block.timestamp` | | timestamp of current block |
-| 43 | NUMBER | 2 | `。` | `block.number` | | number of current block |
-| 44 | PREVRANDAO | 2 | `。` | `randomness beacon` | | randomness beacon |
-| 45 | GASLIMIT | 2 | `。` | `block.gaslimit` | | gas limit of current block |
-| 46 | CHAINID | 2 | `。` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
-| 47 | SELFBALANCE | 5 | `。` | `address(this).balance` | | balance of executing contract, in wei |
-| 48 | BASEFEE | 2 | `。` | `block.basefee` | | base fee of current block |
-| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
-| 4A | BLOBBASEFEE | 2 | `。` | `block.blobbasefee` | | 当前区块的二進位大型物件基本费用 ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
-| 4B-4F | _invalid_ | | | | | |
-| 50 | POP | 2 | `_anon` | `。` | | remove item from top of stack and discard it |
-| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
-| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `。` | mem[ost:ost+32] := val | write a word to memory |
-| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `。` | mem[ost] := val && 0xFF | write a single byte to memory |
-| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage |
-| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `。` | storage[key] := val | write word to storage |
-| 56 | JUMP | 8 | `dst` | `。` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest |
-| 57 | JUMPI | 10 | `dst, condition` | `。` | | `$pc := condition ? dst : $pc + 1` |
-| 58 | PC | 2 | `。` | `$pc` | | program counter |
-| 59 | MSIZE | 2 | `。` | `len(mem)` | | size of memory in current execution context, in bytes |
-| 5A | GAS | 2 | `。` | `gasRemaining` | | |
-| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 從暫存中讀取字詞 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5D | TSTORE | 100 | `key, val` | `。` | tstorage[key] := val | 將字詞寫入暫存 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5E | MCOPY | 3+3\*字詞數+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `。` | mem[dstOst] := mem[ost:ost+len] | 從一個區域複製記憶體到另一個區域 ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
-| 5E | PUSH0 | 2 | `。` | `uint8` | | 將常數值 0 推至堆疊上 |
-| 60 | PUSH1 | 3 | `。` | `uint8` | | push 1-byte value onto stack |
-| 61 | PUSH2 | 3 | `。` | `uint16` | | push 2-byte value onto stack |
-| 62 | PUSH3 | 3 | `。` | `uint24` | | push 3-byte value onto stack |
-| 63 | PUSH4 | 3 | `。` | `uint32` | | push 4-byte value onto stack |
-| 64 | PUSH5 | 3 | `。` | `uint40` | | push 5-byte value onto stack |
-| 65 | PUSH6 | 3 | `。` | `uint48` | | push 6-byte value onto stack |
-| 66 | PUSH7 | 3 | `。` | `uint56` | | push 7-byte value onto stack |
-| 67 | PUSH8 | 3 | `。` | `uint64` | | push 8-byte value onto stack |
-| 68 | PUSH9 | 3 | `。` | `uint72` | | push 9-byte value onto stack |
-| 69 | PUSH10 | 3 | `。` | `uint80` | | push 10-byte value onto stack |
-| 6A | PUSH11 | 3 | `。` | `uint88` | | push 11-byte value onto stack |
-| 6B | PUSH12 | 3 | `。` | `uint96` | | push 12-byte value onto stack |
-| 6C | PUSH13 | 3 | `。` | `uint104` | | push 13-byte value onto stack |
-| 6D | PUSH14 | 3 | `。` | `uint112` | | push 14-byte value onto stack |
-| 6E | PUSH15 | 3 | `。` | `uint120` | | push 15-byte value onto stack |
-| 6F | PUSH16 | 3 | `。` | `uint128` | | push 16-byte value onto stack |
-| 70 | PUSH17 | 3 | `。` | `uint136` | | push 17-byte value onto stack |
-| 71 | PUSH18 | 3 | `。` | `uint144` | | push 18-byte value onto stack |
-| 72 | PUSH19 | 3 | `。` | `uint152` | | push 19-byte value onto stack |
-| 73 | PUSH20 | 3 | `。` | `uint160` | | push 20-byte value onto stack |
-| 74 | PUSH21 | 3 | `。` | `uint168` | | push 21-byte value onto stack |
-| 75 | PUSH22 | 3 | `。` | `uint176` | | push 22-byte value onto stack |
-| 76 | PUSH23 | 3 | `。` | `uint184` | | push 23-byte value onto stack |
-| 77 | PUSH24 | 3 | `。` | `uint192` | | push 24-byte value onto stack |
-| 78 | PUSH25 | 3 | `。` | `uint200` | | push 25-byte value onto stack |
-| 79 | PUSH26 | 3 | `。` | `uint208` | | push 26-byte value onto stack |
-| 7A | PUSH27 | 3 | `。` | `uint216` | | push 27-byte value onto stack |
-| 7B | PUSH28 | 3 | `。` | `uint224` | | push 28-byte value onto stack |
-| 7C | PUSH29 | 3 | `。` | `uint232` | | push 29-byte value onto stack |
-| 7D | PUSH30 | 3 | `。` | `uint240` | | push 30-byte value onto stack |
-| 7E | PUSH31 | 3 | `。` | `uint248` | | push 31-byte value onto stack |
-| 7F | PUSH32 | 3 | `。` | `uint256` | | push 32-byte value onto stack |
-| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack |
-| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack |
-| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack |
-| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack |
-| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack |
-| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack |
-| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack |
-| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack |
-| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack |
-| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack |
-| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack |
-| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack |
-| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack |
-| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack |
-| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack |
-| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack |
-| 90 | SWAP1 | 3 | `a, b` | `b, a` | | |
-| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | |
-| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | |
-| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | |
-| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
-| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `。` | | LOG0(memory[ost:ost+len-1]) |
-| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `。` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `。` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `。` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `。` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
-| A5-EF | _invalid_ | | | | | |
-| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
-| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
-| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `。` | | return mem[ost:ost+len-1] |
-| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
-| F6-F9 | _invalid_ | | | | | |
-| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| FB-FC | _invalid_ | | | | | |
-| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `。` | | revert(mem[ost:ost+len-1]) |
-| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `。` | | 傳送所有以太幣到 `addr`;如果在建立合約的相同交易中執行,則會銷毀合約 |
+| 堆疊 | 名稱 | 燃料 | 初始堆疊 | 最終堆疊 | 記憶體/儲存空間 | 注釋 | |
+| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
+| 00 | STOP | 0 | | | | 停止執行 | |
+| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 加法,模數為 2\*\*256 | |
+| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 乘法,模數為 2\*\*256 | |
+| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 減法,模數為 2\*\*256 | |
+| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 除法 | |
+| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 除法 | |
+| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 模數運算 | |
+| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 模數運算 | |
+| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 加法,模數為 N | |
+| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 乘法,模數為 N | |
+| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 冪,模數為 2\*\*256 | |
+| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | 對 `x` 進行[符號擴充](https://wikipedia.org/wiki/Sign_extension),從 `(b+1)` 位元組擴充為 32 位元組。 | |
+| 0C-0F | _無效_ | | | | | | |
+| 10 | LT | 3 | `a, b` | `a < b` | | uint256 小於 | |
+| 11 | GT | 3 | `a, b` | `a > b` | | uint256 大於 | |
+| 12 | SLT | 3 | `a, b` | `a < b` | | int256 小於 | |
+| 13 | SGT | 3 | `a, b` | `a > b` | | int256 大於 | |
+| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 相等 | |
+| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 是否為零 | |
+| 16 | AND | 3 | `a, b` | `a && b` | | 位元 AND | |
+| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | 位元 OR | |
+| 18 | XOR | 3 | `a, b` | `a ^ b` | | 位元 XOR | |
+| 19 | NOT | 3 | `a` | `~a` | | 位元 NOT | |
+| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | 從左邊算起,(u)int256 `x` 的第 `i` 個位元組 | |
+| 1B | SHL | 3 | `shift, val` | `val << shift` | | 向左移位 | |
+| 1C | SHR | 3 | `shift, val` | `val >> shift` | | 邏輯右移 | |
+| 1D | SAR | 3 | `shift, val` | `val >> shift` | | 算術右移 | |
+| 1E-1F | _無效_ | | | | | | |
+| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | |
+| 21-2F | _無效_ | | | | | | |
+| 30 | ADDRESS | 2 | `.` | `address(this)` | | 執行合約的地址 | |
+| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | 餘額,以 wei 計 | |
+| 32 | ORIGIN | 2 | `.` | `tx.origin` | | 發起交易的地址 | |
+| 33 | CALLER | 2 | `.` | `msg.sender` | | 訊息發送者的地址 | |
+| 34 | CALLVALUE | 2 | `.` | `msg.value` | | 訊息數值,以 wei 計 | |
+| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | 從索引 `idx` 讀取訊息資料中的字 | |
+| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | 訊息資料的長度,以位元組計 | |
+| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | 複製訊息資料 | |
+| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | 執行合約的程式碼長度,以位元組計 | |
+| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | 複製執行合約的位元組碼 |
+| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | 交易的 gas 價格,以 wei/單位 gas 計 [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | |
+| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | 地址處程式碼的大小,以位元組計 | |
+| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | 從 `addr` 複製程式碼 | |
+| 3D | RETURNDATASIZE | 2 | `.` | `size` | | 上次外部呼叫所回傳資料的大小,以位元組計 | |
+| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | 複製上次外部呼叫所回傳的資料 | |
+| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `雜湊值` | | hash = addr.exists ? keccak256(addr.code) : 0 | |
+| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | |
+| 41 | COINBASE | 2 | `.` | `block.coinbase` | | 目前區塊提交者的地址 | |
+| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | 目前區塊的時間戳 | |
+| 43 | NUMBER | 2 | `.` | `block.number` | | 目前區塊的編號 | |
+| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | 隨機信標 | |
+| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | 目前區塊的 gas 上限 | |
+| 46 | CHAINID | 2 | `.` | `chain_id` | | 將目前[鏈 ID](https://eips.ethereum.org/EIPS/eip-155) 推入堆疊 | |
+| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | 執行中合約的餘額,以 wei 計 | |
+| 48 | BASEFEE | 2 | `.` | `block.basefee` | | 目前區塊的基本費用 | |
+| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | |
+| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | 目前區塊的 Blob 基本費用 ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | |
+| 4B-4F | _無效_ | | | | | | |
+| 50 | POP | 2 | `_anon` | `.` | | 從堆疊頂端移除項目並捨棄 | |
+| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | 從偏移量 `ost` 的記憶體讀取字 | |
+| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | 將一個字寫入記憶體 | |
+| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | 將單一位元組寫入記憶體 | |
+| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | 從儲存體讀取字 | |
+| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | 將字寫入儲存體 | |
+| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` 標示 `pc` 僅在 `dst` 為有效跳轉目的地時才會被指派 | |
+| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | |
+| 58 | PC | 2 | `.` | `$pc` | | 程式計數器 | |
+| 59 | MSIZE | 2 | `.` | `len(mem)` | | 目前執行情境中的記憶體大小,以位元組計 | |
+| 5A | GAS | 2 | `.` | `gasRemaining` | | | |
+| 5B | JUMPDEST | 1 | | | 標記有效的跳轉目的地 | 有效的跳轉目的地,例如不在推送資料內的跳轉目的地 | |
+| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | 從暫時性儲存體讀取字 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | |
+| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | 將字寫入暫時性儲存體 ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | |
+| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | 將記憶體從一個區域複製到另一個區域 ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | |
+| 5E | PUSH0 | 2 | `.` | `uint8` | | 將常數值 0 推至堆疊上 | |
+| 60 | PUSH1 | 3 | `.` | `uint8` | | 將 1 位元組值推入堆疊 | |
+| 61 | PUSH2 | 3 | `.` | `uint16` | | 將 2 位元組值推入堆疊 | |
+| 62 | PUSH3 | 3 | `.` | `uint24` | | 將 3 位元組值推入堆疊 | |
+| 63 | PUSH4 | 3 | `.` | `uint32` | | 將 4 位元組值推入堆疊 | |
+| 64 | PUSH5 | 3 | `.` | `uint40` | | 將 5 位元組值推入堆疊 | |
+| 65 | PUSH6 | 3 | `.` | `uint48` | | 將 6 位元組值推入堆疊 | |
+| 66 | PUSH7 | 3 | `.` | `uint56` | | 將 7 位元組值推入堆疊 | |
+| 67 | PUSH8 | 3 | `.` | `uint64` | | 將 8 位元組值推入堆疊 | |
+| 68 | PUSH9 | 3 | `.` | `uint72` | | 將 9 位元組值推入堆疊 | |
+| 69 | PUSH10 | 3 | `.` | `uint80` | | 將 10 位元組值推入堆疊 | |
+| 6A | PUSH11 | 3 | `.` | `uint88` | | 將 11 位元組值推入堆疊 | |
+| 6B | PUSH12 | 3 | `.` | `uint96` | | 將 12 位元組值推入堆疊 | |
+| 6C | PUSH13 | 3 | `.` | `uint104` | | 將 13 位元組值推入堆疊 | |
+| 6D | PUSH14 | 3 | `.` | `uint112` | | 將 14 位元組值推入堆疊 | |
+| 6E | PUSH15 | 3 | `.` | `uint120` | | 將 15 位元組值推入堆疊 | |
+| 6F | PUSH16 | 3 | `.` | `uint128` | | 將 16 位元組值推入堆疊 | |
+| 70 | PUSH17 | 3 | `.` | `uint136` | | 將 17 位元組值推入堆疊 | |
+| 71 | PUSH18 | 3 | `.` | `uint144` | | 將 18 位元組值推入堆疊 | |
+| 72 | PUSH19 | 3 | `.` | `uint152` | | 將 19 位元組值推入堆疊 | |
+| 73 | PUSH20 | 3 | `.` | `uint160` | | 將 20 位元組值推入堆疊 | |
+| 74 | PUSH21 | 3 | `.` | `uint168` | | 將 21 位元組值推入堆疊 | |
+| 75 | PUSH22 | 3 | `.` | `uint176` | | 將 22 位元組值推入堆疊 | |
+| 76 | PUSH23 | 3 | `.` | `uint184` | | 將 23 位元組值推入堆疊 | |
+| 77 | PUSH24 | 3 | `.` | `uint192` | | 將 24 位元組值推入堆疊 | |
+| 78 | PUSH25 | 3 | `.` | `uint200` | | 將 25 位元組值推入堆疊 | |
+| 79 | PUSH26 | 3 | `.` | `uint208` | | 將 26 位元組值推入堆疊 | |
+| 7A | PUSH27 | 3 | `.` | `uint216` | | 將 27 位元組值推入堆疊 | |
+| 7B | PUSH28 | 3 | `.` | `uint224` | | 將 28 位元組值推入堆疊 | |
+| 7C | PUSH29 | 3 | `.` | `uint232` | | 將 29 位元組值推入堆疊 | |
+| 7D | PUSH30 | 3 | `.` | `uint240` | | 將 30 位元組值推入堆疊 | |
+| 7E | PUSH31 | 3 | `.` | `uint248` | | 將 31 位元組值推入堆疊 | |
+| 7F | PUSH32 | 3 | `.` | `uint256` | | 將 32 位元組值推入堆疊 | |
+| 80 | DUP1 | 3 | `a` | `a, a` | | 複製堆疊上的第 1 個值 | |
+| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | 複製堆疊上的第 2 個值 | |
+| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | 複製堆疊上的第 3 個值 | |
+| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | 複製堆疊上的第 4 個值 | |
+| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 5 個值 | |
+| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 6 個值 | |
+| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 7 個值 | |
+| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 8 個值 | |
+| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 9 個值 | |
+| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 10 個值 | |
+| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 11 個值 | |
+| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 12 個值 | |
+| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 13 個值 | |
+| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 14 個值 | |
+| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 15 個值 | |
+| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | 複製堆疊上的第 16 個值 | |
+| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | |
+| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | |
+| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | |
+| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | |
+| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | |
+| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | |
+| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | |
+| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | |
+| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | |
+| A5-EF | _無效_ | | | | | | |
+| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | |
+| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | 與 DELEGATECALL 相同,但不傳播原始的 msg.sender 和 msg.value | |
+| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | 回傳 mem[ost:ost+len-1] | |
+| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | |
+| F6-F9 | _無效_ | | | | | | |
+| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| FB-FC | _無效_ | | | | | | |
+| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | 還原 (mem[ost:ost+len-1]) | |
+| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | 指定的無效操作碼 - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | |
+| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | 將所有 ETH 傳送到 `addr`;如果在建立合約的同筆交易中執行,就會銷毀該合約 | |
diff --git a/public/content/translations/zh-tw/developers/docs/frameworks/index.md b/public/content/translations/zh-tw/developers/docs/frameworks/index.md
index 9929d5aab4b..a97475f402e 100644
--- a/public/content/translations/zh-tw/developers/docs/frameworks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/frameworks/index.md
@@ -1,71 +1,79 @@
---
-title: 去中心化應用程式開發架構
-description: 探索架構優勢及比較現有選項。
+title: "去中心化應用程式開發架構"
+description: "探索架構優勢及比較現有選項。"
lang: zh-tw
---
-## 架構簡介 {#introduction-to-frameworks}
+## 框架簡介 {#introduction-to-frameworks}
-建構成熟的去中心化應用程式需要 不同的技術。 軟體架構包含許多必要功能, 或提供簡單的外掛程式系統來選擇 你需要的工具。
+建構成熟的去中心化應用程式需要
+不同的技術。 軟體架構包含許多必要功能,
+或提供簡單的外掛程式系統來選擇
+你需要的工具。
-架構帶有許多非常規功能, 例如:
+架構帶有許多非常規功能,
+例如:
-- 編列系統內區塊鏈功能.
+- 運行本機區塊鏈實例功能。
- 編輯和測試你的智慧型合約.
-- 用戶端開發外掛程式可在同一專案/儲存庫中建立 面向使用者的應用程式。
-- 用於連結到以太坊網路並部署 合約的設定,無論是連接到本地運行的執行個體 還是連結到以太坊的公共網路之一。
-- 去中心化應用程式分發 - 與星際檔案系統 等存儲選項整合。
+- 用戶端開發附加元件,可在同一個專案/儲存庫中建立
+ 面對使用者的應用程式。
+- 用於連結到以太坊網路並部署
+ 合約的設定,無論是連接到本地運行的執行個體
+ 還是連結到以太坊的公共網路之一。
+- 去中心化應用程式發行 - 與 IPFS 等儲存選項
+ 整合。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入介紹這些架構之前,推薦你先閱讀下面的[去中心化應用程式](/developers/docs/dapps/)和[以太坊堆疊](/developers/docs/ethereum-stack/)簡介。
+在深入研究框架之前,建議您先閱讀我們的 [去中心化應用程式](/developers/docs/dapps/) 和 [以太坊技術堆疊](/developers/docs/ethereum-stack/) 簡介。
-## 可用架構 {#available-frameworks}
+## 可用的框架 {#available-frameworks}
-**Foundry** - **_Foundry 是一款快速、便攜和模組化的工具包,用於以太坊應用程式開發_**
+**Foundry** - **_Foundry 是一款極速、可攜式且模組化的工具組,用於開發以太坊應用程式_**
- [安裝 Foundry](https://book.getfoundry.sh/)
-- [Foundry 手册](https://book.getfoundry.sh/)
-- [Telegram 上的 Foundry 社群聊天](https://t.me/foundry_support)
+- [Foundry 書籍](https://book.getfoundry.sh/)
+- [Telegram 上的 Foundry 社群聊天室](https://t.me/foundry_support)
- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry)
-**Hardhat -** **_專業以太坊開發環境。_**
+**Hardhat -** **_為專業人士打造的以太坊開發環境。_**
- [hardhat.org](https://hardhat.org)
- [GitHub](https://github.com/nomiclabs/hardhat)
-**Ape -** **_Python 程式人員、資料科學家和安全性專業人員適用的智慧型合約開發工具。_**
+**Ape -** **_專為 Python 開發人員、資料科學家和安全專家打造的智慧合約開發工具。_**
-- [文件](https://docs.apeworx.io/ape/stable/)
+- [說明文件](https://docs.apeworx.io/ape/stable/)
- [GitHub](https://github.com/ApeWorX/ape)
-**Web3j -** **_用於在 JAVA 虛擬機上開發區塊鏈應用程式的平台。_**
+**Web3j -** **_一個在 JVM 上開發區塊鏈應用程式的平台。_**
- [首頁](https://www.web3labs.com/web3j-sdk)
-- [文件](https://docs.web3j.io)
+- [說明文件](https://docs.web3j.io)
- [GitHub](https://github.com/web3j/web3j)
-**ethers-kt -** **_適用基於以太坊虛擬機區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。_**
+**ethers-kt -** **_適用於 EVM 區塊鏈的非同步、高效能 Kotlin/Java/Android 程式庫。_**
- [GitHub](https://github.com/Kr1ptal/ethers-kt)
- [範例](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
- [Discord](https://discord.gg/rx35NzQGSb)
-**Create Eth App -** **_使用一個命令建立以太坊支援的應用程式。 包含多種使用者介面架構與去中心化金融模板供你選擇。_**
+**Create Eth App -** **_用一道指令建立由以太坊驅動的應用程式。 包含多種UI架構與Defi模板供你選擇._**
- [GitHub](https://github.com/paulrberg/create-eth-app)
-- [模板](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
+- [範本](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
-**Scaffold-Eth -** **_Ethers.js + Hardhat + React 元件和 web3 掛勾:開始構建由智慧型合約支援的去中心化應用程式所需的一切。_**
+**Scaffold-Eth -** **_Ethers.js + Hardhat + React 元件和 web3 掛鉤:開始建構由智慧合約驅動的去中心化應用程式所需的一切。_**
- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
-**Tenderly -** **_Web3 開發平台,使區塊鏈開發者能夠建立、測試、除錯、監控和操作智慧型合約並改進去中心化應用程式使用者體驗。_**
+**Tenderly -** **_Web3 開發平台,能讓區塊鏈開發者建立、測試、除錯、監控和操作智慧合約,並改善去中心化應用程式的使用者體驗。_**
- [網站](https://tenderly.co/)
-- [文件](https://docs.tenderly.co/)
+- [說明文件](https://docs.tenderly.co/)
-**The Graph****_高效率查詢區塊鏈資料的圖表。_**
+**The Graph -** **_The Graph,有效率地查詢區塊鏈資料。_**
- [網站](https://thegraph.com/)
- [使用教學](/developers/tutorials/the-graph-fixing-web3-data-querying/)
@@ -82,68 +90,68 @@ lang: zh-tw
- [GitHub](https://github.com/node-real)
- [Discord](https://discord.gg/V5k5gsuE)
-**thirdweb SDK -** **_透過我們的強大軟體開發套件和命令列介面,可以建構與你的智慧型合約互動的 Web3 應用程式。_**
+**thirdweb SDK -** **_使用我們強大的 SDK 和 CLI,建構可與您的智慧合約互動的 web3 應用程式。_**
-- [文件](https://portal.thirdweb.com/sdk/)
-- [Github](https://github.com/thirdweb-dev/)
+- [說明文件](https://portal.thirdweb.com/sdk/)
+- [GitHub](https://github.com/thirdweb-dev/)
-**Chainstack -** **_Web3(以太坊及其他區塊鏈)開發平台。_**
+**Chainstack -** **_Web3 (以太坊及其他) 開發平台。_**
- [chainstack.com](https://www.chainstack.com/)
-- [Github](https://github.com/chainstack)
+- [GitHub](https://github.com/chainstack)
- [Discord](https://discord.gg/BSb5zfp9AT)
-**Crossmint -** **_企業級 web3 開發平台,讓你在所有主要鏈以太坊虛擬機器鏈上建立非同質化代幣應用程式。_**
+**Crossmint -** **_企業級 web3 開發平台,讓您可以在所有主要 EVM 鏈 (及其他鏈) 上建立 NFT 應用程式。_**
- [網站](https://www.crossmint.com)
- [文件](https://docs.crossmint.com)
- [Discord](https://discord.com/invite/crossmint)
-**Brownie -** **_基於 Python 的開發環境和測試架構。_**
+**Brownie -** **_以 Python 為基礎的開發環境和測試框架。_**
-- [文件](https://eth-brownie.readthedocs.io/en/latest/)
+- [說明文件](https://eth-brownie.readthedocs.io/en/latest/)
- [GitHub](https://github.com/eth-brownie/brownie)
- **Brownie 目前未有維護**
-**OpenZeppelin 軟體開發套件 -** **_終極智慧型合約工具組:一套幫助你開發、編譯、升級、部署智慧型合約以及與智慧型合約互動的工具。_**
+**OpenZeppelin SDK -** **_終極智慧合約工具組:一套可協助您開發、編譯、升級、部署智慧合約並與其互動的工具。_**
-- [OpenZeppelin 軟體開發套件](https://openzeppelin.com/sdk/)
+- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk)
- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk)
- [社群論壇](https://forum.openzeppelin.com/c/support/17)
- **OpenZeppelin 軟體開發套件開發已結束**
-**Catapulta -** **_多鏈智慧型合約部署工具,在區塊瀏覽器中自動驗證,追蹤部署的智慧型合約並分享部署報告,Foundry 和 Hardhat 專案隨插即用。_**
+**Catapulta -** **_多鏈智慧合約部署工具,可在區塊瀏覽器中自動驗證、追蹤已部署的智慧合約並分享部署報告,為 Foundry 和 Hardhat 專案提供隨插即用功能。_**
- [網站](https://catapulta.sh/)
-- [文件](https://catapulta.sh/docs)
+- [說明文件](https://catapulta.sh/docs)
- [Github](https://github.com/catapulta-sh)
-**Covalent -** **_200 多條鏈的已擴充區塊鏈應用程式介面。_**
+**GoldRush (由 Covalent 提供技術支援) -** **_GoldRush 為開發人員、分析師和企業提供最全面的區塊鏈資料 API 套件, 無論您是在建構 DeFi 儀表板、錢包、交易機器人、AI 代理程式還是合規平台,資料 API 都能提供快速、準確且對開發人員友善的存取方式,讓您取得所需的必要鏈上資料_**
-- [covalenthq.com](https://www.covalenthq.com/)
-- [文件](https://www.covalenthq.com/docs/api/)
+- [網站](https://goldrush.dev/)
+- [說明文件](https://goldrush.dev/docs/chains/ethereum)
- [GitHub](https://github.com/covalenthq)
- [Discord](https://www.covalenthq.com/discord/)
**Wake -** **_用於合約測試、模糊測試、部署、漏洞掃描和程式碼導航的一體化 Python 框架。_**
- [首頁](https://getwake.io/)
-- [文件](https://ackeeblockchain.com/wake/docs/latest/)
+- [說明文件](https://ackeeblockchain.com/wake/docs/latest/)
- [GitHub](https://github.com/Ackee-Blockchain/wake)
- [VS Code 擴充功能](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
-**Veramo -** **_開放原始碼、模組化且不受限的框架,讓去中心化應用程式開發者能輕鬆地將去中心化身分和可驗證憑證整合到他們的應用程式中。_**
+**Veramo -** **_開源、模組化且不受限的框架,讓去中心化應用程式開發者能輕鬆地將去中心化身分和可驗證憑證整合到他們的應用程式中。_**
- [首頁](https://veramo.io/)
-- [文件](https://veramo.io/docs/basics/introduction)
+- [說明文件](https://veramo.io/docs/basics/introduction)
- [GitHub](https://github.com/uport-project/veramo)
- [Discord](https://discord.com/invite/FRRBdjemHV)
-- [節點包裹管理器 (NPM) 包裹](https://www.npmjs.com/package/@veramo/core)
+- [NPM 套件](https://www.npmjs.com/package/@veramo/core)
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-_知道對你有幫助的社群資源嗎? 請編輯此頁面並新增資源!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
## 相關主題 {#related-topics}
-- [設定本地開發環境](/developers/local-environment/)
+- [設定本機開發環境](/developers/local-environment/)
diff --git a/public/content/translations/zh-tw/developers/docs/gas/index.md b/public/content/translations/zh-tw/developers/docs/gas/index.md
index efa60ccf64a..e69db8732d2 100644
--- a/public/content/translations/zh-tw/developers/docs/gas/index.md
+++ b/public/content/translations/zh-tw/developers/docs/gas/index.md
@@ -1,15 +1,15 @@
---
-title: 燃料和費用
+title: "燃料和費用"
metaTitle: "以太坊燃料和費用:技術概覽"
-description:
+description: "了解以太坊 Gas Fee、其計算方式,以及在網路安全和交易處理中的作用。"
lang: zh-tw
---
燃料對於以太坊網路至關重要。 燃料讓以太坊得以運轉,就像是汽車需要汽油行駛一樣。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了更好地理解本頁面,建議你先閱讀[交易](/developers/docs/transactions/)和[以太坊虛擬機](/developers/docs/evm/)。
+為更佳理解本頁面,我們建議您先閱讀關於 [交易](/developers/docs/transactions/) 和 [EVM](/developers/docs/evm/) 的內容。
## 什麼是燃料? {#what-is-gas}
@@ -17,80 +17,85 @@ lang: zh-tw
因為執行每一筆以太坊交易都需要計算資源,要使用這些資源就必須付費,以確保以太坊不會受到垃圾訊息的影響,或者卡在無窮計算迴圈中。 計算費用以燃料費的形式支付。
-燃料費的計算方式是**執行操作消耗的燃料數量乘以每單位燃料費價格**。 無論交易成功與否,都要支付燃料費。
+燃料費用是**執行某些操作所使用的燃料數量,乘以每單位燃料的成本**。 無論交易成功與否,都要支付燃料費。
- _此圖表源於[以太坊的以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [以太坊 EVM 圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
燃料費須用以太坊原生貨幣以太幣 (ETH) 支付。 燃料價格一般會以 gwei 為單位,gwei 是以太幣的面額之一。 每一 gwei 等於一以太幣的十億分之一(0.000000001 以太幣或 10-9 以太幣)。
舉例來說,可以說你的燃料費為 1 gwei,而不是 0.000000001 以太幣。
-「gwei」這個字是「giga-wei」的縮寫,意思是「10 億 wei」。 1 gwei 等於 10 億 wei。 Wei 本身(命名於 [Wei Dai](https://wikipedia.org/wiki/Wei_Dai),[b-money](https://www.investopedia.com/terms/b/bmoney.asp) 創建者)為以太幣之最小單位面額。
+「gwei」這個字是「giga-wei」的縮寫,意思是「10 億 wei」。 1 gwei 等於 10 億 wei。 Wei 本身(以 [b-money](https://www.investopedia.com/terms/b/bmoney.asp) 創始人 [戴維](https://wikipedia.org/wiki/Wei_Dai) 的名字命名)是 ETH 的最小單位。
## 燃料費是如何計算的? {#how-are-gas-fees-calculated}
提交交易時,可以設定你願意支付的燃料費數量。 藉由提供一定數量的燃料費,你實際上是在出價,以便將你的交易加入下一個區塊。 如果你的報價過低,驗證者就不太可能選擇將你的交易加入下一個區塊,代表你的交易可能會延遲或根本不會被執行。 如果你報價過高,則可能會浪費一些以太幣。 那麼,該如何判定支付多少費用呢?
-支付的燃料費分成兩個部分:`base fee` 及 `priority fee`(小費)。
+您支付的總燃料費分為兩個部分:`基本費用` 和 `優先費用` (小費)。
-`base fee` 是由協議設定的 - 你必須支付至少這個數量的以太幣,你的交易才會被視為有效。 `priority fee` 是你在基本費用上增加的額外小費,使你的交易對驗證者來說更有吸引力,以便讓他們選擇將其添加到下一個區塊中。
+`基本費用` 由協議設定——您必須至少支付此金額,您的交易才算有效。 `優先費用` 是您加在基本費用上的小費,用來吸引驗證程式,讓他們選擇將您的交易納入下一個區塊。
-只支付 `base fee` 的交易在技術層面上是有效的,但不太可能加入下一個區塊中,因為此類交易未向驗證者提供任何激勵,因此驗證者不會選擇它而不管任何其他交易。 「適宜」的 `priority` 費依據發送交易時的網路使用情況而定 - 若當時需求非常高,你需要將你的 `priority` 費設高點,而需求低時則可以付少點。
+僅支付 `基本費用` 的交易在技術上有效,但不太可能被納入,因為它沒有提供任何誘因讓驗證程式優先選擇它,而不是其他任何交易。 「正確的」`優先`費用取決於您傳送交易時的網路使用情況——如果需求量大,您可能需要設定較高的 `優先`費用,但當需求較少時,您可以支付較少的費用。
舉例來說,假設 Jordan 要付給 Taylor 1 以太幣。 以太幣轉帳需要 21,000 單位的燃料,而基本費用為 10 gwei。 Jordan 支付 2 gwei 小費。
現在總燃料費為:
-`使用的單位燃料 * (基本費用 + 優先費)`
+`已使用的燃料單位 * (基本費用 + 優先費用)`
-其中,`base fee` 的值由協議設定,而 `priority fee` 的值則是由使用者設置,是給驗證者的小費。
+其中,`基本費用` 的值由協議設定,而 `優先費用` 的值則是由使用者設置,是給驗證程式的小費。
-範例:`21,000 * (10 + 2) = 252,000 gwei` (0.000252 以太幣)。
+例如 `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH)。
-當 Jordan 發送該金額時,1.000252 以太幣將從 Jordan 的帳戶中扣除。 而 Taylor 將獲得 1.0000 以太幣。 驗證者將收到 0.000042 以太幣的小費。 0.00021 以太幣的 `base fee` 被銷毀。
+當 Jordan 發送該金額時,1.000252 以太幣將從 Jordan 的帳戶中扣除。 而 Taylor 將獲得 1.0000 以太幣。 驗證者將收到 0.000042 以太幣的小費。 0.00021 ETH 的 `基本費用` 被銷毀。
### 基本費用 {#base-fee}
-每個區塊都有基本費用作為底價。 為了達成添加至區塊中的條件,提供的每單位燃料價格必須至少等於基本費用。 基本費用的計算與當前區塊無關,而是由當前區塊前面的區塊決定,讓交易費用對於使用者更具可預測性。 建立區塊時,此**基本費用被「銷毀」**,從流通中移除。
+每個區塊都有基本費用作為底價。 為了達成添加至區塊中的條件,提供的每單位燃料價格必須至少等於基本費用。 基本費用的計算與當前區塊無關,而是由其之前的區塊決定,讓使用者的交易費用更具可預測性。 建立區塊時,此**基本費用會被\"銷毀\"**,從流通中移除。
-此基本費用透過一個公式計算,該公式比較前一個區塊的大小(所有交易使用的燃料用量)與目標區塊大小。 如果超出目標區塊大小,每個區塊的基本費用將最大增加 12.5%。 這種指數級增長讓區塊大小無限增加在經濟上不可行。
+基本費用是根據一個公式計算出來的,該公式將前一個區塊的大小 (所有交易使用的燃料量) 與目標大小 (燃料限制的一半) 進行比較。 如果目標區塊大小分別高於或低於目標,每個區塊的基本費用最多將增加或減少 12.5%。 這種指數級增長讓區塊大小無限增加在經濟上不可行。
-| 區塊編號 | 包含燃料 | 費用增幅 | 當前基本費用 |
-| ---- | ----:| -----:| ----------:|
-| 1 | 15M | 0% | 100 gwei |
-| 2 | 30M | 0% | 100 gwei |
-| 3 | 30M | 12.5% | 112.5 gwei |
-| 4 | 30M | 12.5% | 126.6 gwei |
-| 5 | 30M | 12.5% | 142.4 gwei |
-| 6 | 30M | 12.5% | 160.2 gwei |
-| 7 | 30M | 12.5% | 180.2 gwei |
-| 8 | 30M | 12.5% | 202.7 gwei |
+| 區塊編號 | 包含燃料 | 費用增幅 | 當前基本費用 |
+| ---- | ---: | --------------------: | -------------------------: |
+| 1 | 18M | 0% | 100 gwei |
+| 2 | 36M | 0% | 100 gwei |
+| 3 | 36M | 12.5% | 112.5 gwei |
+| 4 | 36M | 12.5% | 126.6 gwei |
+| 5 | 36M | 12.5% | 142.4 gwei |
+| 6 | 36M | 12.5% | 160.2 gwei |
+| 7 | 36M | 12.5% | 180.2 gwei |
+| 8 | 36M | 12.5% | 202.7 gwei |
-依據上表 -- 要在 9 號區塊中建立一筆交易,錢包會讓使用者明確知道將交易添加到下一個區塊中的**最大基本費用**為 `current base fee * 112.5%` 或 `202.7 gwei * 112.5% = 228.1 gwei`。
+上表中,以 3600 萬作為燃料限制為例進行了示範。 以上表為例,若要在第 9 號區塊建立交易,錢包會讓使用者明確知道,要新增至下一個區塊的**最高基本費用**為 `目前的基本費用 * 112.5%` 或 `202.7 gwei * 112.5% = 228.1 gwei`。
值得注意的是,因為基本費用在區塊變滿之前增加的速度很快,我們不太可能看到大量已滿區塊連續出現。
-| 區塊編碼 | 包含Gas費 | 增加費用 | 目前基本費用 |
-| ---- | ------:| -----:| ---------------:|
-| 30 | 30M | 12.5% | 2705.6 gwei |
-| ... | ... | 12.5% | ... |
-| 50 | 30M | 12.5% | 28531.3 gwei |
-| ... | ... | 12.5% | ... |
-| 100 | 30M | 12.5% | 10302608.6 gwei |
+| 區塊編號 | 包含燃料 | 費用增幅 | 當前基本費用 |
+| --------------------------------------------------- | --------------------------------------------------: | --------------------: | --------------------------------------------------: |
+| 30 | 36M | 12.5% | 2705.6 gwei |
+| ... | ... | 12.5% | ... |
+| 50 | 36M | 12.5% | 28531.3 gwei |
+| ... | ... | 12.5% | ... |
+| 100 | 36M | 12.5% | 10302608.6 gwei |
-### 優先費(小費) {#priority-fee}
+### 優先費用 (小費) {#priority-fee}
-優先費(小費)激勵驗證者將交易添加進區塊中。 如果沒有小費,驗證者會發現開採空區塊在經濟上可行,因為他們收到的區塊獎勵相同。 少量的小費提供的激勵極弱,不足以讓驗證者將交易打包進區塊。 為了使交易比相同區塊中的其他交易優先執行,可以提供較高的小費,以超出其他競爭交易的報價。
+優先費用 (小費) 旨在激勵驗證程式在區塊燃料限制的範圍內,盡可能將區塊內的交易數量最大化。 若沒有小費,理性的驗證程式可能會納入較少,甚至是零筆交易,且不會受到執行層或共識層的直接懲罰,因為質押獎勵與區塊中的交易數量無關。 此外,小費讓使用者能以更高價格在同一個區塊中取得優先處理權,有效地表達交易的急迫性。
-### 最大費用 {#maxfee}
+### 最高費用 {#maxfee}
-要在網路上執行交易,使用者可以指定為了執行其交易他們願意支付的最大費用限制。 此可選參數亦稱為 `maxFeePerGas`。 執行交易所需的最大費用必須超過基本費用與小費的總和。 會向交易發送者退還最大費用與基本費用和小費之總合之間的差額。
+要在網路上執行交易,使用者可以指定為了執行其交易他們願意支付的最大費用限制。 此選用參數稱為 `maxFeePerGas`。 執行交易所需的最大費用必須超過基本費用與小費的總和。 會向交易發送者退還最大費用與基本費用和小費之總合之間的差額。
### 區塊大小 {#block-size}
-每個區塊具 15M 單位燃料用量之目標大小,但區塊大小將跟隨網路需求增減,最大可達到 60M 燃料用量的區塊大小限制(目標區塊大小之兩倍)。 協議往往透過 _tâtonnement_ 流程達成 30M 的均衡區塊大小。 這意味著,如果區塊大小大於目標區塊大小,協議將增加下一個區塊的基本費用。 同樣,如果區塊大小小於目標區塊大小,協議將減少基本費用。 基本費用的調節額度與實際區塊大小與目標區塊大小之間的差異成比例。 [更多區塊相關資訊](/developers/docs/blocks/)。
+每個區塊的目標大小是目前燃料限制的一半,但區塊大小會根據網路需求增減,直到達到區塊上限 (目標區塊大小的 2 倍)。 協議透過 _tâtonnement_ (試探) 過程,使平均區塊大小達到目標值的均衡狀態。 這意味著,如果區塊大小大於目標區塊大小,協議將增加下一個區塊的基本費用。 同樣,如果區塊大小小於目標區塊大小,協議將減少基本費用。
-### 實際計算燃料費 {#calculating-fees-in-practice}
+基本費用的調節額度與實際區塊大小與目標區塊大小之間的差異成比例。 這是線性計算:空區塊為 -12.5%,達到目標大小時為 0%,達到燃料限制時最高為 +12.5%。 燃料限制會根據驗證程式的信號以及網路升級而隨時間波動。 您可以在[此處查看燃料限制隨時間的變化](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths)。
+
+[更多關於區塊的資訊](/developers/docs/blocks/)
+
+### 實務上如何計算燃料費用 {#calculating-fees-in-practice}
可明確聲明願意支付多少費用,以讓驗證者執行你的交易。 然而,大多數錢包提供商會自動設定推薦的交易費(基本費用 + 推薦的優先費),以降低使用者面臨的複雜度。
@@ -98,43 +103,49 @@ lang: zh-tw
簡言之,燃料費可幫助保障以太坊網路安全。 透過要求為網路上執行的每次計算支付費用,可以阻止惡意行為者利用垃圾郵件攻擊網路。 為避免程式碼中出現意外或是惡意的無限迴圈或其他計算浪費,對於每筆交易,都必須設定一個關於可以使用程式碼執行中多少個計算步驟的限制。 計算的基本單位為「燃料」。
-雖然交易包括限制,但任何在交易中未使用的燃料將會退還給使用者(即退還 `max fee - (base fee + tip)`)。
+雖然交易設有上限,但交易中任何未使用的燃料都會退還給使用者 (例如,退還的金額為 `最高費用 - (基本費用 + 小費)`)。
- _此圖表源於[以太坊的以太坊虛擬機圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_圖表改編自 [以太坊 EVM 圖解](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## 什麼是燃料限制? {#what-is-gas-limit}
-燃料限制指的是你在一筆交易中最多願意使用多少燃料。 包含[智慧型合約](/developers/docs/smart-contracts/)的更複雜的交易需要進行更多計算工作,所以比起簡單的支付,它們需要更高的燃料限制。 標準以太幣轉帳需要的燃料限制為 21,000 單位燃料。
+燃料限制指的是你在一筆交易中最多願意使用多少燃料。 涉及 [智能合約](/developers/docs/smart-contracts/) 的更複雜交易需要更多計算工作,因此需要的燃料限制比簡單的支付更高。 標準以太幣轉帳需要的燃料限制為 21,000 單位燃料。
-例如,如果為一次簡單的以太幣轉帳設定了 50,000 的燃料限制,以太坊虛擬機將消耗 21,000 單位燃料並退還剩餘的 29,000。 然而,如果你設定的燃料過低,例如為簡單的以太幣轉帳設定 20,000 的燃料限制,以太坊虛擬機將用盡 20,000 燃料單位嘗試完成交易,但最終交易會失敗。 隨後,以太坊虛擬機會還原全部變更,但因為驗證者已完成了相當於 20k 燃料單位的工作,所以會消耗這些燃料。
+例如,如果為一次簡單的以太幣轉帳設定了 50,000 的燃料限制,以太坊虛擬機將消耗 21,000 單位燃料並退還剩餘的 29,000。 然而,如果你指定的 gas 過少,例如,對於一筆簡單的 ETH 轉移,gas 限制設置爲 20,000,那麽交易將在驗證階段失敗。 它會在被包含在區塊之前被拒絕,並且不會消耗任何 gas。 另一方面,如果交易在執行過程中耗盡了 gas(例如,智能合約在執行過程中耗盡了所有 gas),以太坊虛擬機將回滾所有更改,但已提供的 gas 仍將用於已完成的工作。
## 為何燃料費這麼高? {#why-can-gas-fees-get-so-high}
燃料費高是因為以太坊人氣高。 如果需求過高,使用者必須支付更高的小費,以便超出其他使用者的交易報價。 小費越高,你的交易添加到下一個區塊中的可能性越大。 另外,越複雜的智慧型合約應用程式可能會執行大量操作,以支援其函式,這會消耗許多燃料。
-## 燃料費用削減倡議 {#initiatives-to-reduce-gas-costs}
+## 降低燃料成本的措施 {#initiatives-to-reduce-gas-costs}
+
+以太坊的[可擴展性升級](/roadmap/) 最終應能解決一些燃料費用問題,從而使該平台能夠每秒處理數千筆交易並在全球範圍內擴展。
-以太坊的[可擴容性](/roadmap/)應最終解決一部分燃料費用問題,繼而讓該平台能夠每秒處理數千筆交易並實現全域擴容。
+二層網路擴容為一項主要倡議,可大幅減低燃料費用並加強用戶體驗及可擴容性。
-二層網路擴容為一項主要倡議,可大幅減低燃料費用並加強用戶體驗及可擴容性。 [更多二層網路擴容相關資訊](/developers/docs/scaling/#layer-2-scaling)。
+[更多關於 Layer 2 擴展的資訊](/developers/docs/scaling/#layer-2-scaling)
-## 監控燃料費 {#monitoring-gas-fees}
+## 監控燃料費用 {#monitoring-gas-fees}
若你想要監控燃料價格,以便能以更低的費用發送以太幣,你可以使用許多不同的工具,例如:
-- [Etherscan](https://etherscan.io/gastracker) _交易燃料費價格估算器_
-- [以太幣燃料追蹤器](https://www.ethgastracker.com/)_監控並追蹤以太坊和二層網路的燃料價格,以降低交易費用並節省資金_
-- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _燃料估算 Chrome 延伸模組,支援 0 類原始交易及 2 類 EIP-1559 交易。_
-- [Cryptoneur燃料Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _在主網、Arbitrum、Polygon 上使用當地貨幣計算不同交易類型的燃料費。_
+- [Etherscan](https://etherscan.io/gastracker) _交易燃料價格估算器_
+- [Blockscout](https://eth.blockscout.com/gas-tracker) _開源交易燃料價格估算器_
+- [ETH Gas Tracker](https://www.ethgastracker.com/) _監控和追蹤以太坊和 L2 的燃料價格,以降低交易費用並節省資金_
+- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _支援類型 0 傳統交易和類型 2 EIP-1559 交易的燃料估算 Chrome 擴充功能。_
+- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _在主網、Arbitrum 和 Polygon 上,為不同交易類型以您的當地貨幣計算燃料費用。_
## 相關工具 {#related-tools}
-- [Blocknative's Gas Platform](https://www.blocknative.com/gas)_ 由 Blocknative 的全域記憶體池資料平臺支援的燃料估算應用程式介面平台_
+- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _由 Blocknative 的全球記憶體池資料平台提供支援的燃料估算 API_
+- [Gas Network](https://gas.network) 鏈上燃料預言機。 支援超過 35 條鏈。
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊燃料詳解](https://defiprime.com/gas)
-- [減低智慧型合約之燃料消耗](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
-- [開發者的燃料優化策略](https://www.alchemy.com/overviews/solidity-gas-optimization)
-- [EIP-1559 文檔](https://eips.ethereum.org/EIPS/eip-1559)。
-- [Tim Beiko 的 EIP-1559 資源](https://hackmd.io/@timbeiko/1559-resources)。
+- [以太坊燃料說明](https://defiprime.com/gas)
+- [降低您智能合約的燃料消耗](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
+- [開發人員的燃料最佳化策略](https://www.alchemy.com/overviews/solidity-gas-optimization)
+- [EIP-1559 文件](https://eips.ethereum.org/EIPS/eip-1559)。
+- [Tim Beiko 的 EIP-1559 資源](https://hackmd.io/@timbeiko/1559-resources)
+- [EIP-1559:將機制與迷因區分開來](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes)
diff --git a/public/content/translations/zh-tw/developers/docs/ides/index.md b/public/content/translations/zh-tw/developers/docs/ides/index.md
index f5c0d085180..1e521944e99 100644
--- a/public/content/translations/zh-tw/developers/docs/ides/index.md
+++ b/public/content/translations/zh-tw/developers/docs/ides/index.md
@@ -1,64 +1,64 @@
---
-title: 整合開發環境
-description:
+title: "整合開發環境 (IDE)"
+description: "了解關於以太坊開發的網頁及桌面版 IDE,包括 Remix、VS Code 及其他受歡迎的插件。"
lang: zh-tw
---
-在設定[整合開發環境 (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) 時,以太坊上的應用程式程式設計與任何其他軟體專案的程式設計類似。 有很多選項可供選擇,因此最終請選擇最適合你喜好設定的整合開發環境或程式碼編輯器。 最適合你以太坊開發的整合開發環境選項很可能是你已經用於傳統軟體開發的整合開發環境。
+在設定 [整合開發環境 (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) 時,以太坊上的應用程式設計與任何其他軟體專案的設計類似。 有很多選項可供選擇,因此最終請選擇最適合你喜好設定的整合開發環境或程式碼編輯器。 最適合你以太坊開發的整合開發環境選項很可能是你已經用於傳統軟體開發的整合開發環境。
-## 網頁型整合開發環境 {#web-based-ides}
+## 網頁版 IDE {#web-based-ides}
-如果你想在[設定本地開發環境](/developers/local-environment/)之前試一下程式碼,以下網頁應用程式是為以太坊智慧型合約開發客製化構建的。
+如果你想在 [設定本機開發環境](/developers/local-environment/) 之前,先試著修改程式碼,這些網路應用程式是專為以太坊智慧型合約開發而打造的。
-**[Remix](https://remix.ethereum.org/)** - **_網頁型整合開發環境,內建靜態分析與區塊鏈測試虛擬機_**
+**[Remix](https://remix.ethereum.org/)** - **_網頁版 IDE,內建靜態分析和測試用區塊鏈虛擬機_**
- [文件](https://remix-ide.readthedocs.io/en/latest/#)
- [Gitter](https://gitter.im/ethereum/remix)
-**[ChainIDE](https://chainide.com/)** - **_一個支援多鏈的雲端整合開發環境_**
+**[ChainIDE](https://chainide.com/)** - **_一個雲端多鏈 IDE_**
- [文件](https://chainide.gitbook.io/chainide-english-1/)
- [幫助論壇](https://forum.chainide.com/)
-**[Replit(Solidity 新手教學 - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_一個可自訂的以太坊開發環境,提供熱重載、錯誤檢查和一流的測試網支援_**
+**[Replit (Solidity 入門 - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_一個可自訂的以太坊開發環境,具備熱重載、錯誤檢查和頂級的測試網支援_**
- [文件](https://docs.replit.com/)
-**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_一個快速的原型建置環境,讓你可以使用 Solidity 和 JavaScript 在瀏覽器中編寫、執行智慧型合約並對其偵錯_**
+**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_一個快速的原型設計環境,您可以在瀏覽器中使用 Solidity 和 JavaScript 編寫、執行和偵錯智慧型合約_**
-**[EthFiddle](https://ethfiddle.com/)** - **_網頁型整合開發環境 (IDE),可讓你編寫、編譯智慧型合約並對其偵錯_**
+**[EthFiddle](https://ethfiddle.com/)** - **_網頁版 IDE,可讓您編寫、編譯和偵錯您的智慧型合約_**
- [Gitter](https://gitter.im/loomnetwork/ethfiddle)
-## 桌上型整合開發環境 {#desktop-ides}
+## 桌面版 IDE {#desktop-ides}
-大多數成熟的整合開發環境都內建了外掛程式來增強以太坊開發體驗。 這些整合開發環境至少為[智慧型合約語言](/developers/docs/smart-contracts/languages/)提供語法醒目提示。
+大多數成熟的整合開發環境都內建了外掛程式來增強以太坊開發體驗。 最起碼,它們會為 [智慧型合約語言](/developers/docs/smart-contracts/languages/) 提供語法高亮功能。
-**Visual Studio Code -** **_專業跨平台整合開發環境,獲以太坊官方支援_**
+**Visual Studio Code -** **_具備以太坊官方支援的專業跨平台 IDE_**
- [Visual Studio Code](https://code.visualstudio.com/)
- [程式碼範例](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
- [GitHub](https://github.com/microsoft/vscode)
-**JetBrains 整合開發環境(IntelliJ IDEA 等) -****_軟體開發者和團隊的必備工具_**
+**JetBrains IDEs (IntelliJ IDEA, 等.) -** **_軟體開發人員與團隊的必備工具_**
- [JetBrains](https://www.jetbrains.com/)
- [GitHub](https://github.com/JetBrains)
- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
-**Remix Desktop -****_在本地機器上體驗 Remix 整合開發環境_**
+**Remix Desktop -** **_在您的本機電腦上體驗 Remix IDE_**
- [下載](https://github.com/ethereum/remix-desktop/releases)
- [GitHub](https://github.com/ethereum/remix-desktop)
-## 外掛程式和擴充功能 {#plugins-extensions}
+## 外掛程式與擴充功能 {#plugins-extensions}
-- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - 支援 Visual Studio Code 的以太坊 Solidity 語言
-- [支援 VS Code 的 Solidity + Hardhat](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Hardhat 團隊提供 Solidity 和 Hardhat 支援
-- [Prettier Soliditty](https://github.com/prettier-solidity/prettier-plugin-solidity) - 使用 prettier 的程式碼格式器
+- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - 適用於 Visual Studio Code 的 Ethereum Solidity 語言
+- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - 由 Hardhat 團隊提供的 Solidity 與 Hardhat 支援
+- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - 使用 prettier 的程式碼格式化工具
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-- [以太坊整合開發環境](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _ - Alchemy 提供的以太坊整合開發環境清單_
+- [以太坊 IDE](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- Alchemy 的以太坊 IDE 清單_
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/index.md b/public/content/translations/zh-tw/developers/docs/index.md
index eca812e3bc0..b321e99917a 100644
--- a/public/content/translations/zh-tw/developers/docs/index.md
+++ b/public/content/translations/zh-tw/developers/docs/index.md
@@ -1,14 +1,14 @@
---
-title: 以太坊開發文檔
-description: Ethereum.org 開發者文檔簡介。
+title: "以太坊開發文檔"
+description: "Ethereum.org 開發者文檔簡介。"
lang: zh-tw
---
本文檔旨在幫助你透過以太坊建置。 它介紹以太坊概念,解釋以太坊技術堆疊,並記錄關於更加複雜的應用程式及用例的高階主題。
-此為開源社群的一項工作,歡迎在你認為有所幫助時提出新主題、增添新內容並提供範例。 所有文檔均可透過 GitHub 進行編輯 – 如果你不確定如何操作,[請遵循相關說明](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)。
+此為開源社群的一項工作,歡迎在你認為有所幫助時提出新主題、增添新內容並提供範例。 所有文件都可以透過 GitHub 編輯 – 如果您不確定如何操作,[請依照這些說明操作](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md)。
-## 發展模組 {#development-modules}
+## 開發模組 {#development-modules}
若這是你初次嘗試進行以太坊開發,我們建議你從頭開始並進行全面學習。
@@ -16,7 +16,7 @@ lang: zh-tw
-### 以太坊權益質押 {#ethereum-stack}
+### 以太坊技術堆棧 {#ethereum-stack}
diff --git a/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md b/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md
index e876b2c5fa9..e28c3e65ba2 100644
--- a/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md
+++ b/public/content/translations/zh-tw/developers/docs/intro-to-ether/index.md
@@ -1,12 +1,12 @@
---
-title: 以太幣簡介
-description: 開發者為你介紹以太幣加密貨幣
+title: "以太幣的技術性介紹"
+description: "開發者為你介紹以太幣加密貨幣"
lang: zh-tw
---
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-為了讓你更容易理解本頁,建議你先通讀我們的[以太坊介紹](/developers/docs/intro-to-ethereum/)。
+為協助您更瞭解本頁面,建議您先閱讀 [以太坊簡介](/developers/docs/intro-to-ethereum/)。
## 什麼是加密貨幣? {#what-is-a-cryptocurrency}
@@ -16,17 +16,17 @@ lang: zh-tw
第一種加密貨幣為比特幣,由中本聰創建。 自從比特幣 2009 問世以來,人們已經在多個不同區塊鏈上開發了數千種加密貨幣。
-## 甚麼是以太(ETH)? {#what-is-ether}
+## 甚麼是以太(以太幣)? {#what-is-ether}
-**以太幣 (ETH)** 為一種加密貨幣,在以太坊網路上有諸多用途。 基本上,它是唯一可被接受的交易費支付形式,且在[合併](/roadmap/merge)之後,在主網上驗證和提出區塊會需要以太幣。 以太幣還可以作為[去中心化金融](/defi)借貸市場中的主要抵押物,非同質化代幣市場上的計帳單位,或作為提供服務或銷售真正的商品而獲得的付款,還有更多用途。
+**以太幣 (ETH)** 是以太坊網路上用於許多用途的加密貨幣。 基本上,它是唯一可接受的交易費用支付形式,而且在[合併](/roadmap/merge)之後,在主網上驗證和提出區塊都需要以太幣。 以太幣也用作 [DeFi](/defi) 借貸市場的主要抵押品、NFT 市場的記帳單位、執行服務或銷售實體商品賺取的報酬等等。
-透過以太坊,開發者可以建立[**去中心化應用程式 (dapp)**](/developers/docs/dapps),而所有去中心化應用程式都共用同一算力池。 此共享算力池是有限的,因此以太坊需要一種機制來決定由誰使用它。 不然,某個去中心化應用程式可能會意外或惡意佔用全部網路資源,令其他人無法使用。
+以太坊讓開發者可以建立 [**去中心化應用程式 (dapps)**](/developers/docs/dapps),它們都共享一個算力池。 此共享算力池是有限的,因此以太坊需要一種機制來決定由誰使用它。 不然,某個去中心化應用程式可能會意外或惡意佔用全部網路資源,令其他人無法使用。
-以太幣加密貨幣支援以太坊算力的定價機制。 當使用者想進行交易時,他們必須支付以太幣,使其交易在區塊鏈上獲得認可。 此等使用成本亦稱為[燃料費](/developers/docs/gas/),而燃料費取決於執行交易所需的算力及當時整個網路對於算力的需求。
+以太幣加密貨幣支援以太坊算力的定價機制。 當使用者想進行交易時,他們必須支付以太幣,使其交易在區塊鏈上獲得認可。 這些使用成本稱為 [gas 費用](/developers/docs/gas/),而 gas 費用取決於執行交易所需的算力,以及當時全網路對算力的需求。
因此,即使惡意去中心化應用程式提交一個無窮迴圈,交易將最終會用盡以太幣並終止,讓網路能回復正常。
-人們[經常將以太坊與以太幣混為一談](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) — 當提到「以太坊的價格」時,他們指的是以太幣的市價。
+人們[通常會將](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845)以太坊和以太幣混淆 — 當人們提到「以太坊的價格」時,他們指的是以太幣的價格。
## 鑄造以太幣 {#minting-ether}
@@ -38,15 +38,15 @@ lang: zh-tw
如同區塊獎勵過程中會創建新的以太幣一樣,以太幣也可以透過稱為「燃燒」的流程銷毀。 以太幣銷毀後,將從流通中永久移除。
-以太坊上的每筆交易中都有以太幣銷毀。 當使用者為交易支付費用時,透過網路設定的基本燃料費用會根據交易需求銷毀。 它與不同的區塊大小以及最大燃料費用結合起來,簡化了以太坊上的交易費的估算。 當網路需求較高時,[區塊](https://etherscan.io/block/12965263)可以銷毀的以太幣數量比鑄造數量更大,有效抵銷以太幣的發行。
+以太坊上的每筆交易中都有以太幣銷毀。 當使用者為交易支付費用時,透過網路設定的基本燃料費用會根據交易需求銷毀。 它與不同的區塊大小以及最大燃料費用結合起來,簡化了以太坊上的交易費的估算。 當網路需求高時,[區塊](https://eth.blockscout.com/block/22580057)可以銷毀比鑄造的數量更多的以太幣,有效地抵銷了以太幣的發行。
-銷毀基本費用會束縛區塊產生者操縱交易的能力。 舉例來說,若區塊產生者收到基本費用,他們可以免費添加自己的交易,並提高其他人的基本費用。 或者,他們可以在鏈外將基本費用退還給某些使用者,造成交易費市場更加不透明且複雜。
+銷毀基本費用會阻礙區塊生產者操縱交易的能力。 舉例來說,若區塊產生者收到基本費用,他們可以免費添加自己的交易,並提高其他人的基本費用。 或者,他們可以在鏈下將基本費用退還給某些使用者,造成交易費市場更加不透明且複雜。
-## 以太幣面額 {#denominations}
+## 以太幣的面額 {#denominations}
由於以太坊上許多交易的價值很小,以太幣也就有了各種不同的面額,可做為較小的記帳單位。 其中,Wei 和 gwei 尤為重要。
-Wei 為以太幣的最小面額,因而,許多技術實作,例如[以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf)等將在所有計算中以 Wei 為單位。
+Wei 是以太幣的最小單位,因此許多技術實作,例如 [以太坊黃皮書](https://ethereum.github.io/yellowpaper/paper.pdf),會以 Wei 為單位進行所有計算。
Gwei 是 giga-wei 的簡稱,常用來描述以太坊上的燃料費用。
@@ -55,24 +55,24 @@ Gwei 是 giga-wei 的簡稱,常用來描述以太坊上的燃料費用。
| Wei | 10-18 | 技術實作 |
| Gwei | 10-9 | 人類可讀燃料費 |
-## 傳送以太幣 {#transferring-ether}
+## 轉移以太幣 {#transferring-ether}
-以太坊上的每筆交易都有一個 `value` 欄位,指定要從發送者地址傳送到接收者地址的以太幣數量,面額為 wei。
+以太坊上的每筆交易都包含一個 `value` 欄位,此欄位指定要從寄件人地址傳送到收款人地址的以太幣數量,並以 wei 為單位。
-當接收者地址為[智慧型合約](/developers/docs/smart-contracts/)時,在智慧型合約執行其程式碼後,傳送之以太幣可用於支付燃料費用。
+當收款人地址是 [智能合約](/developers/docs/smart-contracts/) 時,這筆轉移的以太幣可用於在智能合約執行其程式碼時支付 gas 費用。
-[更多交易相關資訊](/developers/docs/transactions/)
+[更多關於交易的資訊](/developers/docs/transactions/)
## 查詢以太幣 {#querying-ether}
-使用者能透過檢視帳戶的 `balance` 欄位來查詢任何[帳戶](/developers/docs/accounts/)的以太幣餘額,該欄位顯示面額為 wei 的以太幣持有量。
+使用者可以透過檢視帳戶的 `balance` 欄位來查詢任何[帳戶](/developers/docs/accounts/)的以太幣餘額,此欄位會顯示以 wei 為單位的以太幣持有量。
-[Etherscan](https://etherscan.io) 為一種人氣工具,可透過網路應用程式檢視地址餘額。 例如,[此 Etherscan 頁面](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae)顯示以太坊基金會的餘額。 也可使用錢包或者透過直接向節點發送請求查詢帳戶餘額。
+[Etherscan](https://etherscan.io) 和 [Blockscout](https://eth.blockscout.com) 是透過網頁應用程式檢視地址餘額的熱門工具。 例如,[這個 Blockscout 頁面](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) 顯示了以太坊基金會的餘額。 也可使用錢包或者透過直接向節點發送請求查詢帳戶餘額。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [定義以太幣與以太坊](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_
-- [以太坊白皮書](/whitepaper/):以太坊初始提案。 該文件包含對以太幣的描述及創建以太幣的動機。
-- [Gwei 計算機](https://www.alchemy.com/gwei-calculator):使用此 Gwei 計算機輕鬆轉換 wei、gwei 和以太幣。 只需輸入任意數量的 wei、gwei 或以太幣即可自動計算轉換後的數值。
+- [以太坊白皮書](/whitepaper/):以太坊的原始提案。 該文件包含對以太幣的描述及創建以太幣的動機。
+- [Gwei 計算機](https://www.alchemy.com/gwei-calculator):使用此 Gwei 計算機可輕鬆轉換 wei、gwei 和以太幣。 只需輸入任意數量的 wei、gwei 或以太幣即可自動計算轉換後的數值。
-_認識社區或社團資源能幫助大家學習更多? 歡迎自由編輯或添加於本頁!!_
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
diff --git a/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md b/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md
index ba3941f4ab6..f74bc6c7f97 100644
--- a/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md
+++ b/public/content/translations/zh-tw/developers/docs/intro-to-ethereum/index.md
@@ -1,6 +1,6 @@
---
-title: 以太坊簡介
-description: 去中心化應用程式開發者介紹以太坊核心概念。
+title: "以太坊的技術性介紹"
+description: "去中心化應用程式開發者介紹以太坊核心概念。"
lang: zh-tw
---
@@ -14,15 +14,15 @@ lang: zh-tw
網路上的所有電腦必須對所有新區塊及整條區塊鏈達成一致。 此等電腦稱為「節點」。 節點確保與區塊鏈互動的每個人具相同資料。 為了達成這種分佈式共識,區塊鏈需要一共識機制。
-以太坊採用[權益證明共識機制](/developers/docs/consensus-mechanisms/pos/)。 任何想將新區塊添加至區塊鏈的人都必須質押以太幣(以太坊的原生貨幣)作為抵押品並運行驗證者軟體。 接著,這些「驗證者」會被隨機選取以提出區塊,區塊由其他驗證者檢查並添加到區塊鏈上。 以太坊有獎勵及懲罰制度,以激勵參與者保持誠實並儘可能持續上線。
+以太坊使用[權益證明共識機制](/developers/docs/consensus-mechanisms/pos/)。 任何想將新區塊添加至區塊鏈的人都必須質押以太幣(以太坊的原生貨幣)作為抵押品並運行驗證者軟體。 接著,這些「驗證者」會被隨機選取以提出區塊,區塊由其他驗證者檢查並添加到區塊鏈上。 以太坊有獎勵及懲罰制度,以激勵參與者保持誠實並儘可能持續上線。
-如果想瞭解區塊鏈資料是如何被雜湊後並附加到區塊參考的歷史記錄中,歡迎查看這個由 Anders Brownworth 製作的[示範](https://andersbrownworth.com/blockchain/blockchain),並觀看附上的影片。
+如果您想了解區塊鏈資料如何被哈希處理,並隨後附加到區塊參考歷史記錄中,請務必查看 Anders Brownworth 製作的[此示範](https://andersbrownworth.com/blockchain/blockchain),並觀看下面的附帶影片。
觀看 Anders 解釋區塊鏈中雜湊的影片:
-## 甚麼是以太坊(Ethereum)? {#what-is-ethereum}
+## 什麼是 Ethereum? {#what-is-ethereum}
以太坊是一條嵌入了電腦的區塊鏈。 它是以去中心化、無需許可、抗審查的方式建立應用程式和組織的基礎。
@@ -32,7 +32,7 @@ lang: zh-tw
加密機制確保一旦交易被驗證為有效並添加至區塊鏈上,以後就無法被篡改。 此相同機制也確保所有交易是透過相同的「權限」簽署並執行(除了 Alice 本人外,任何人都不應該能從她的帳戶發送數位資產)。
-## 什麼是以太幣? {#what-is-ether}
+## 甚麼是以太(以太幣)? {#what-is-ether}
**以太幣 (ETH)** 是以太坊的原生加密貨幣。 以太坊的作用是提供一個計算市場。 此類市場為參與者提供經濟獎勵,激勵其驗證並執行交易請求,並且向網路提供計算資源。
@@ -42,9 +42,9 @@ lang: zh-tw
以太幣也用來為網路提供加密經濟學安全性,主要有以下三種方式:1) 作為一種獎勵方式,獎勵提交區塊或檢舉其他驗證者不誠實行為的驗證者;2) 由驗證者質押,作為對抗不誠實行為的抵押品 - 如果驗證者嘗試從事不良行為,則它們的以太幣可能會被銷毀;3) 用來衡量新提交區塊的「投票」,並輸入共識機制的分叉選擇部分。
-## 什麼是智慧型合約? {#what-are-smart-contracts}
+## 什麼是智慧型合約? 什麼是智能合約? {#what-are-smart-contracts}
-實際上,參與者想請求在以太坊虛擬機上進行計算時,不用每次編寫新程式碼。 反之,應用程式開發者將程式(可重複使用的程式片段)上傳到以太坊虛擬機狀態中,使用者請求使用不同的參數來執行此類程式碼片段。 我們將此類上傳並執行的程式稱為網路智慧型合約。
+實際上,參與者想請求在以太坊虛擬機上進行計算時,不用每次編寫新程式碼。 反之,應用程式開發者將程式(可重複使用的程式片段)上傳到以太坊虛擬機狀態中,使用者請求使用不同的參數來執行此類程式碼片段。 我們將上傳至網路並由網路執行的程式稱為「智能合約」。
簡單來說,你可以想像智慧型合約為一臺自動販賣機:一個指令碼,在使用某些參數呼叫時,若滿足特定條件,該指令碼會執行一些操作或計算。 舉例來說,如果呼叫者將以太幣發送給特定接收者,一個簡易的販賣智慧型合約可能會建立和指定某件數位資產的所有權。
@@ -58,31 +58,31 @@ lang: zh-tw
以太坊網路之歷史記錄中提交至網路上的所有區塊的順序。 有此名稱的原因是,每個區塊都包含對前一個塊的引用,這有助於維護所有區塊(以及精確歷史記錄)的排序。
-### 以太幣 {#eth}
+### ETH {#eth}
-**以太 (ETH)**以太坊原生加密貨幣. 使用者向其他使用者支付以太幣,以完成他們的程式碼執行請求。
+**以太幣 (ETH)** 是以太坊的原生加密貨幣。 使用者向其他使用者支付以太幣,以完成他們的程式碼執行請求。
-[有關以太幣的更多資訊](/developers/docs/intro-to-ether/)
+[更多關於 ETH](/developers/docs/intro-to-ether/)
-### 以太坊虛擬機 {#evm}
+### EVM {#evm}
以太坊虛擬機為一臺全域虛擬電腦,所有以太坊網路參與者都儲存其狀態並達成共識。 任何參與者都能請求在以太坊虛擬機上執行任何程式碼;程式碼執行會改變以太坊虛擬機的狀態。
-[更多以太坊虛擬機相關資訊](/developers/docs/evm/)
+[更多關於 EVM](/developers/docs/evm/)
### 節點 {#nodes}
儲存以太坊虛擬機狀態的真實電腦。 節點互相通訊,以傳播關於以太坊虛擬機狀態及新出現狀態變化的資訊。 任何使用者還可以透過從節點廣播程式碼執行請求,請求執行程式碼。 以太坊網路本身為所有以太坊節點及其通信之彙總。
-[更多詳情關於節點](/developers/docs/nodes-and-clients/)
+[更多關於節點](/developers/docs/nodes-and-clients/)
### 帳戶 {#accounts}
以太幣儲存之處。 使用者可以初始化帳戶,將以太幣存入帳戶,並將其帳戶中的以太幣轉帳給其他使用者。 帳戶及帳戶餘額儲存於以太坊虛擬機中的一張龐大表格中;它們是以太坊虛擬機全部狀態的一部分。
-[更多帳戶相關資訊](/developers/docs/accounts/)
+[更多關於帳戶](/developers/docs/accounts/)
-### 交易紀錄 {#transactions}
+### 交易 {#transactions}
「交易請求」為表示以太坊虛擬機上程式碼執行請求的正式術語,而「交易」為已完成的交易請求及相關的以太坊虛擬機狀態變化。 任何使用者都能從節點向網路廣播交易請求。 為了讓交易請求影響達成共識的以太坊虛擬機狀態,必須由其他節點驗證、執行此交易請求並「將其提交至網路上」。 執行任何程式碼都會改變以太坊虛擬機的狀態;提交時,此狀態變化將廣播至網路上的所有節點。 以下為一些交易範例:
@@ -90,27 +90,35 @@ lang: zh-tw
- 將一些智慧型合約程式碼發佈至以太坊虛擬機狀態中。
- 使用 Y 參數來執行以太坊虛擬機中地址 X 處的智慧型合約的程式碼。
-[更多詳情關於交易記錄](/developers/docs/transactions/)
+[更多關於交易的資訊](/developers/docs/transactions/)
### 區塊 {#blocks}
交易量非常龐大,因此交易按批次或區塊「提交」。 區塊通常包含數十乃至數百筆交易。
-[更多區塊相關資訊](/developers/docs/blocks/)
+[更多關於區塊的資訊](/developers/docs/blocks/)
-### 智慧型合約 {#smart-contracts}
+### 智能合約 {#smart-contracts}
-一段可重複使用的程式碼片段(程式),由開發者發佈至以太坊虛擬機狀態中。 任何人都可以透過發出交易請求來請求執行智慧型合約的程式碼。 因為開發者能藉由發佈智慧型合約向以太坊虛擬機中編寫任意可執行應用程式(遊戲、市場、金融工具等),此類合約也經常稱為 [Dapp 或去中央化應用程式](/developers/docs/dapps/)。
+一段可重複使用的程式碼片段(程式),由開發者發佈至以太坊虛擬機狀態中。 任何人都可以透過發出交易請求來請求執行智慧型合約的程式碼。 因為開發者可以將任何可執行的應用程式(遊戲、市場、金融工具等)寫入 EVM 透過發布智能合約,這些應用程式通常也被稱為[去中心化應用程式](/developers/docs/dapps/)。
-[了解更多關於智慧型合約的資訊](/developers/docs/smart-contracts/)
+[更多關於智能合約](/developers/docs/smart-contracts/)
-## 了解更多 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [以太坊白皮書](/whitepaper/)
-- [以太坊到底是如何運作的?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_(**注意**:此資源仍有參考價值,但留意它是早於[以太網合併](/roadmap/merge)的文獻,因此引述的仍然是以太坊的工作量證明機制 - 以太坊實際上目前是由[權益證明](/developers/docs/consensus-mechanisms/pos)來保障安全)
+- [以太坊到底是如何運作的?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_(**注意**:此資源仍具價值,但請注意,它的內容早於[合併](/roadmap/merge),因此仍提及以太坊的工作量證明機制——以太坊現在實際上是使用[權益證明](/developers/docs/consensus-mechanisms/pos)來保護安全)
-_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!!_
+### 想透過視覺方式學習? {#visual-learner}
-## 相關教學影片 {#related-tutorials}
+本系列視頻對基本主題進行了深入探索:
-- [以太坊開發者指南,第一部分](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– 適合初學者的以太坊探索(使用 Python 和 web3.py)_
+
+
+[以太坊基礎知識播放清單](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ)
+
+_知道一個曾經幫助你學習更多社區或社團資源? 歡迎在本頁自由編輯或添加內容!_
+
+## 相關教學 {#related-tutorials}
+
+- [開發者的以太坊指南,第一部分](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– 一份對初學者非常友善的指南,使用 Python 和 web3.py 探索以太坊_
diff --git a/public/content/translations/zh-tw/developers/docs/mev/index.md b/public/content/translations/zh-tw/developers/docs/mev/index.md
new file mode 100644
index 00000000000..5471675cb56
--- /dev/null
+++ b/public/content/translations/zh-tw/developers/docs/mev/index.md
@@ -0,0 +1,221 @@
+---
+title: "最大可提取價值 (MEV)"
+description: "最大可提取價值 (MEV) 簡介"
+lang: zh-tw
+---
+
+最大可提取價值 (MEV) 是指透過在區塊中新增和排除交易並更改區塊中的交易順序,可以從區塊生產中提取的超過標準區塊獎勵和燃料費用的最大值。
+
+## 最大可提取價值 {#maximal-extractable-value}
+
+最大可提取價值首次應用於 [工作量證明](/developers/docs/consensus-mechanisms/pow/) 的背景下,最初稱為「礦工可提取價值」。 此是因為於工作量證明, 礦工能選擇來交易之納入, 不納入, 及順序. 然而,自從透過 [The Merge](/roadmap/merge) 過渡至權益證明後,驗證者就一直負責這些角色,挖礦也不再是以太坊協定的一部分。 但價值提取方法仍然存在,因此現在使用的術語是「最大可提取價值」。
+
+## 先決條件 {#prerequisites}
+
+請確保您熟悉[交易](/developers/docs/transactions/)、[區塊](/developers/docs/blocks/)、[權益證明](/developers/docs/consensus-mechanisms/pos) 和 [Gas](/developers/docs/gas/) 熟悉[去中心化應用程式](/apps/)和 [DeFi](/defi/) 也會有所幫助。
+
+## MEV 提取 {#mev-extraction}
+
+理論上,最大可提取價值完全屬於驗證者,因為他們是唯一可以保證執行有利可圖的最大可提取價值機會的一方。 實際上,大部分最大可提取價值是由稱為「搜尋者」的獨立網路參與者提取的。 搜尋者在區塊鏈數據上運行複雜的演算法來檢測盈利的最大可提取價值的機會,並且有機器人自動將這些盈利交易提交到網路。
+
+無論如何,驗證者確實會獲得全部最大可提取價值金額的一部分,因為搜尋者願意支付高昂的燃料費用(這些費用將歸驗證者所有),以換取更高可能性將其有利可圖的交易納入一個區塊。 假設尋找者為完全經濟合理, Gas費此研究者願意來支付最大為100%之MEV利益(因為如果Gas費高於利益, 尋找者將會賠錢).
+
+因此,對於一些競爭激烈的 MEV 機會,例如 [DEX 套利](#mev-examples-dex-arbitrage),搜尋者可能需要將其 MEV 總收入的 90% 或更多作為 Gas 費用支付給驗證者,因為有太多人想進行同樣有利可圖的套利交易。 這是因為確保套利交易運作的唯一方法,是提交最高燃料費用的交易。
+
+### Gas 節省技巧 {#mev-extraction-gas-golfing}
+
+這種動態讓「燃料高爾夫」— 即能夠使用最少數量燃料的程式交易,成為一種競爭優勢。因為它允許搜尋者設定較高的燃料價格,同時保持總燃料費不變(因為燃料費 = 燃料價格 \* 燃料用量)。
+
+一些著名的 Gas 節省技巧包括:使用以一長串零開頭的地址 (例如:[0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)),因為它們佔用的儲存空間較少 (因此 Gas 也較少);以及在合約中保留少量的 [ERC-20](/developers/docs/standards/tokens/erc-20/) 代幣餘額,因為初始化一個儲存槽 (餘額為 0 的情況) 比更新一個儲存槽花費更多的 Gas。 尋找更多減少燃料使用的技巧,是搜尋者在積極研究的一個領域。
+
+### 通用搶先交易者 {#mev-extraction-generalized-frontrunners}
+
+一些尋找者不自行尋找MEV榨取機會, 反之, 其成為一般偷跑者. 一般偷跑者為機器帳戶來監控交易內存池來發現榨益可能交易. 偷跑者將拷貝潛力榨取目標之交易程式, 取代地址部分利用偷跑者帳戶, 並於當地環境測試來確保此交易確實能榨取利益. 如測試結果為確實有利益, 偷跑者將提交此更改後交易使用一更高Gas費, 並"偷跑"先前於原始交易並榨取原先尋找者的MEV利益.
+
+### Flashbots {#mev-extraction-flashbots}
+
+快閃機器是一個獨立專案,透過一項服務擴展執行用戶端,該服務允許搜尋者將最大可提取價值交易提交給驗證者,而無需將它們透露給公共記憶體池。 此避免交易被其他尋找者發現並偷跑.
+
+## MEV 範例 {#mev-examples}
+
+最大可提取價值以多種方式出現在區塊鏈上。
+
+### DEX 套利 {#mev-examples-dex-arbitrage}
+
+[去中心化交易所](/glossary/#dex) (DEX) 套利是最簡單且最知名的 MEV 機會。 因此,它也是競爭最激烈的。
+
+其運作如此: 如果兩個DEXes列表一同一代幣但於不同價格, 某人能購入此代幣於低價DEX並販售此於高價DEX於一單一交易. 因為區塊鏈某些機制, 此為近於無風險之套購機會.
+
+[這裡有一個](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4)獲利套利交易的範例,其中一名搜尋者利用 Uniswap 和 Sushiswap 上 ETH/DAI 交易對的不同定價,將 1,000 ETH 變成了 1,045 ETH。
+
+### 清算 {#mev-examples-liquidations}
+
+借貸協議之清算機制也是一有名MEV榨取機會.
+
+像 Maker 和 Aave 這樣的借貸協定要求使用者存入一些抵押品 (例如 ETH)。 這些存入的抵押品會被用來借貸給其他使用者。
+
+然後,使用者可以根據自己的需求向他人借入資產和代幣 (例如,如果你想在 MakerDAO 管理體系提案中投票,你可以借入 MKR),最高可達其存入抵押品的一定百分比。 例如,如果借款金額不超過 30%,則將 100 DAI 存入協議的使用者最多可以借入價值 30 DAI 的另一種資產。 該協議確定了確切的借貸能力百分比。
+
+隨著借款人抵押品的價值波動,他們的借款能力也會波動。 如果因市場波動,借入資產的價值超過其抵押品價值的 (比方說) 30% (同樣地,準確的百分比由協定確定),協定通常允許任何人清算抵押品,立即償還貸款人 (這類似於傳統金融中 [保證金追繳](https://www.investopedia.com/terms/m/margincall.asp) 的運作方式)。 如果被清算,借款人通常必須支付高額清算費,其中一些費用會支付給清算人 — 這就是最大可提取價值機會的來源。
+
+搜尋者競相以最快的速度解析區塊鏈資料,以判斷哪些借款人可以清算,並率先提交清算交易並自己收取清算費用。
+
+### 三明治交易 {#mev-examples-sandwich-trading}
+
+三明治攻擊為另一常見攻略於MEV榨取.
+
+來做一三明治攻擊, 一尋找者必須監控大筆DEX交易於交易內存池. 例如, 假設某人欲想換10,000 UNI至DAI於Uniswap. 這類大額交易會對 UNI/DAI 對產生重大影響,可能會顯著提高 UNI 相對於 DAI 的價格。
+
+搜尋者可以計算這筆大額交易對 UNI/DAI 交易對的大致價格影響,並在這筆大額交易 _之前_ 立即執行一筆最佳買單,低價買入 UNI,然後在這筆大額交易 _之後_ 立即執行一筆賣單,以大額訂單造成的更高價格賣出。
+
+然而,三明治攻擊的風險更高,因為它不是原子性的 (不像上面描述的 DEX 套利),而且容易受到 [沙門氏菌攻擊](https://github.com/Defi-Cartel/salmonella)。
+
+### NFT MEV {#mev-examples-nfts}
+
+MEV於NFT環境為一崛起市場, 但其也具有多重風險.
+
+然而, 因為NFT交易發生於同樣共享之以太坊區塊鏈上, 尋找者能利用類似技術來於NFT市場.
+
+例如, 如一人氣NFT舉辦一空投活動, 而尋找者想要一或一組特定NFT, 他們能程式編輯一交易來使他們能成為第一個來購入此一或一整組之NFT於單一交易內. 或者,如果一個 NFT [被錯誤地以低價上架](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent),搜尋者可以搶在其他購買者之前,以低價搶購。
+
+一個 NFT MEV 的著名例子是,一名搜尋者花費 700 萬美元,以地板價 [購買了](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) 所有的 Cryptopunk。 一位區塊鏈研究員在 [Twitter 上解釋](https://twitter.com/IvanBogatyy/status/1422232184493121538)了買家如何與 MEV 供應商合作,對其購買行為保密。
+
+### 長尾效應 {#mev-examples-long-tail}
+
+DEX套購, 清算, 及三明治為知名MEV榨取機會, 且極為競爭所以新尋找者幾乎無法賺錢. 然而, 其有另一較不出名的"長尾攻擊"MEV機會(NFT MEV為一用例).
+
+新尋找者或許能利用長尾攻擊來賺取較多利益. Flashbot 的 [MEV 工作板](https://github.com/flashbots/mev-job-board)列出了一些新興機會。
+
+## MEV 的影響 {#effects-of-mev}
+
+最大可提取價值並不都是壞事 — 以太坊的最大可提取價值既有正面也有負面的影響。
+
+### 優點 {#effects-of-mev-the-good}
+
+許多Defi計畫依靠套購利益尋求者來維持幣池價格與實際市場價格. 例如, DEX套購確保用戶們能取得最佳, 最正確之價格為其代幣, 且借出協議依賴快速清算來確保借出者確實有被支付.
+
+無理性尋找者來時時刻刻尋求經濟性機會且利用此優勢, Defi協議或許無法成長至其今日地位.
+
+### 缺點 {#effects-of-mev-the-bad}
+
+於應用程式層面, 一些MEV如三明治攻擊, 時常導致極差用戶體驗. 用戶被夾三明治將面臨市價滑點及較差執行價格於其交易.
+
+於網路層面, 偷跑者及Gas費價格賭價時常導致網路堵塞及昂貴Gas費(當一或多方的偷跑者嘗試跑贏另一對手藉由提交更高額之Gas費賭價), 且無法使正常用戶來運行一般交易.
+
+除了在區塊 _內部_ 發生的事情之外,MEV 也可能在區塊 _之間_ 產生有害影響。 如果區塊中可用的最大可提取價值大幅超過標準區塊獎勵,驗證者可能會被激勵重組區塊並為自己捕獲最大可提取價值,從而導致區塊鏈重組和共識不穩。
+
+這種區塊鏈重組的可能性,先前已在 [比特幣區塊鏈上進行過探討](https://dl.acm.org/doi/10.1145/2976749.2978408)。 當比特幣的區塊獎勵多次砍半, 交易費將成為主要區塊獎勵, 而其將成為經濟性合理來使礦工來放棄下一區塊獎勵並重挖此區塊來賺取更多利益. 隨MEV增長, 相同憂慮將面臨於以太坊, 而直接威脅區塊鏈信賴度.
+
+## MEV 的現狀 {#state-of-mev}
+
+MEV榨取暴增於2021年初期, 而其導長時間之高額Gas費. 快閃機器的最大可提取價中繼的出現,降低了普通偷跑者的效力,並將礦工費價格拍賣帶到鏈下,降低了普通使用者的礦工費。
+
+雖然許多搜尋者仍然從最大可提取價值賺到很多錢,但隨著機會變得越來越廣為人知,越來越多的搜尋者爭奪相同的機會,驗證者將獲得越來越多的最大可提取價值總收入(因為如最初描述的相同類型的燃料拍賣也在快閃機器中發生,儘管是私下進行的,而驗證者將獲得由此產生的燃料收入)。 MEV並非專屬以太坊, 而當MEV環境越來越競爭, 許多尋找者已轉移戰場至BSC幣安智鏈, 而其具相同潛力之MEV機會與一較低競爭環境.
+
+另一方面,從工作量證明過渡到權益證明以及持續不斷使用卷軸來拓展以太坊,這些都以某種還不太清楚的方式改變著最大可提取價值的格局。 與工作量證明中的機率模型相比,提前得知有保證的區塊提議者會如何改變 MEV 提取的動態,以及當 [單一秘密領導人選舉](https://ethresear.ch/t/secret-non-single-leader-election/11789) 和 [分散式驗證者技術](/staking/dvt/) 實施後,這將會如何被打亂,目前尚不清楚。 同樣,當大多數使用者活動遷離以太坊並轉移至其二層網路卷軸和分片時,存在哪些最大可提取價值機會還有待觀察。
+
+## 以太坊權益證明 (PoS) 中的 MEV {#mev-in-ethereum-proof-of-stake}
+
+如前述,最大可提取價值對使用者綜合體驗和共識層安全性產生負面影響。 但以太坊向權益證明共識的過渡(稱為「合併」)也可能帶來與最大可提取價值有關的新風險:
+
+### 驗證者中心化 {#validator-centralization}
+
+在合併後的以太坊,驗證者(已存入 32 個以太幣作為保證金)就新增到信標鏈的區塊的有效性達成共識。 由於 32 ETH 對許多人來說可能遙不可及,[加入質押池](/staking/pools/) 可能是一個更可行的選擇。 然而,[獨立質押者](/staking/solo/) 的健康分佈是理想的,因為它減輕了驗證者的中心化問題並提高了以太坊的安全性。
+
+不過,最大可提取價值提取被認為能夠加速驗證者中心化。 部分原因在於,相較於過去的礦工,驗證者 [提議區塊的收入較少](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply),因此自 [合併](/roadmap/merge/) 以來,MEV 提取已極大地 [影響了驗證者的收入](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb)。
+
+更大的質押池可能會有更多的資源投資進行必要的最佳化,以抓住最大可提取價值機會。 這些池提取的 MEV 越多,它們就擁有越多的資源來提升其 MEV 提取能力 (並增加整體收入),這基本上創造了 [規模經濟](https://www.investopedia.com/terms/e/economiesofscale.asp#)。
+
+由於可支配的資源較少,單獨質押者可能無法從最大可提取價值機會中獲利。 這可能會增加獨立驗證者加入強大的質押池以提高收益的壓力,從而削弱以太坊的去中心化。
+
+### 許可制交易池 {#permissioned-mempools}
+
+爲了應對三明治攻擊和搶先交易攻擊,交易者可能會開始與驗證者進行鏈下交易以確保交易隱私。 交易者將潛在的最大可提取價值交易直接發送到驗證者而非公共内存池,驗證者將交易添加到該區塊中並於交易者分配利潤。
+
+“暗池” 是這種模式的升級版,是一種只供訪問的許可内存池,對願意支付特定費用的用戶開放。 該趨勢將弱化以太坊的無許可和去信任,並有可能將區塊鏈轉換爲一種有利於最高出價者的 “付費游玩” 機制。
+
+許可内存池還會增加先前部分描述的中心化風險。 運行多個驗證者的大型池可能會受益於為交易者和使用者提供交易隱私,增加其最大可提取價值收入。
+
+在合併後的以太坊中解決這些與最大可提取價值相關的問題,是一個核心研究領域。 迄今為止,為了減少在合併之後 MEV 對以太坊去中心化和安全性的負面影響,提出了兩種解決方案:[**提議者-建構者分離 (PBS)**](/roadmap/pbs/) 和 [**建構者 API**](https://github.com/ethereum/builder-specs)。
+
+### 提議者-建構者分離 {#proposer-builder-separation}
+
+在工作量證明和權益證明中,建構區塊的節點面向參與共識的其他節點提出區塊以將其新增到鏈中。 新區塊在另一位礦工在其上建立區塊(在工作量證明中)後,或從大多數驗證者那裡獲得認證(在權益證明中)後,成為規範鏈的一部分。
+
+區塊生產者和區塊提交者角色的結合造成了大多數先前描述的與最大可提取價值相關的問題。 例如,在 [時間盜賊攻擊](https://www.mev.wiki/attack-examples/time-bandit-attack) 中,共識節點有動機觸發鏈重組,以最大化 MEV 收益。
+
+[提議者-建構者分離](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) 旨在減輕 MEV 的影響,尤其是在共識層。 PBS 的主要特點是區塊生產者與區塊提交者的分離。 驗證者仍然負責提議區塊並對其投票,但是一類稱為 **區塊建構者** 的新型專業實體,將負責對交易進行排序和建構區塊。
+
+在 PBS 模式下,區塊構建者創建一個交易捆綁並出價將其納入信標鏈區塊中 (作爲 “執行有效負載”)。 被選中提出下一個區塊的驗證者隨後查看不同的出價,並選擇費用最高的交易包。 PBS 本質上創建了一個拍賣市場,使構建者和出售區塊空間的驗證者進行協調。
+
+目前的 PBS 設計採用 [承諾-揭示方案](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/),建構者只會發布對區塊內容 (區塊頭) 的密碼學承諾以及他們的出價。 在接受獲勝的出價后,提交者創建一個包括區塊頭的簽名區塊提案。 區塊建構者在看到已簽署的區塊提議後,應會發布完整的區塊主體,且在最終確認前,還必須從驗證者那裡收到足夠的 [證明](/glossary/#attestation)。
+
+#### 提議者-建構者分離如何減弱最大可提取價值的影響? {#how-does-pbs-curb-mev-impact}
+
+協議内的提交者-構建者分離將最大可提取價值從驗證者的權限中移除,降低了最大可提取價值對共識的影響。 相反,運行專用硬體的區塊建置者將抓住出現的最大可提取價值機會。
+
+不過,這並不完全將驗證者排除在最大可提取價值相關收入之外,因為建置者必須出高價才能讓驗證者接受他們的區塊。 盡管如此,由於驗證者不再直接專注於如何盡可能提高最大可提取價值收入,時間强盜攻擊的威脅得以降低。
+
+提出者-構建者分離也降低了最大可提取價值的中心化風險。 例如,使用提交-揭露方案,構建者就會信任驗證者不會竊取最大可提取價值機會或將其暴露給其他構建者。 這就低了單獨質押者從最大可提取價值獲益的門檻,否則建置者將傾向於支持有著鏈下聲譽的大型池並與它們進行鏈下交易。
+
+同樣地,驗證者不必信任建置者不會隱藏區塊體或發布無效區塊,因為付款是無條件的。 即使提出的區塊不可用或被其他驗證者宣稱無效,驗證者的費用仍然會支付。 在後一種情況下,區塊被直接丟棄,迫使區塊建置者失去所有交易費和最大可提取價值收入。
+
+### 建構者 API {#builder-api}
+
+儘管提交者-構建者分離有望減少最大可提取價值的影響,但實現它需要對共識協議進行更改。 具體來說,信標鏈上的 [分叉選擇](/developers/docs/consensus-mechanisms/pos/#fork-choice) 規則需要更新。 [建構者 API](https://github.com/ethereum/builder-specs) 是一個臨時解決方案,旨在提供一個可行的提議者-建構者分離實作,儘管它帶有更高的信任假設。
+
+建構者 API 是 [引擎 API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) 的修改版本,共識層用戶端用它來向執行層用戶端請求執行負載。 如 [誠實驗證者規範](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) 所述,被選中負責提議區塊的驗證者會向一個已連接的執行用戶端請求交易捆綁包,並將其包含在提議的信標鏈區塊中。
+
+建置者應用程式介面還充當驗證者和執行層用戶端之間的中介軟體;不同之處是它允許信標鏈上的驗證者從外部實體獲取區塊(而不是使用執行用戶端在本地構建區塊)。
+
+以下簡述建置者應用程式介面如何運作:
+
+1. 建置者應用程式介面將驗證者連接到由運行執行層用戶端的區塊建置者組成的網路。 與 PBS 相同,構建者專注於投資消耗大量資源的區塊構建,並使用不同的策略最大限度地提提高從最大可提取價值 + 優先消費中賺取的收入。
+
+2. 驗證者(運行共識層用戶端)向建置者網路請求執行有效負載及出價。 建置者的出價將包含執行有效負載標頭,即對有效負載內容的加密承諾,和向驗證者支付的費用。
+
+3. 驗證者查看收到的出價並選擇費用最高的執行有效負載。 利用建置者應用程式介面,驗證者創建一個僅包括其簽名和執行有效負載標頭的「盲」信標區塊提案並發送給建置者。
+
+4. 在看到盲區塊提案時,運行建置者應用程式介面的建置者可能會用完整的執行有效負載回應。 這讓驗證者可以創建一個在整個網路中傳播的「已簽署」信標區塊。
+
+5. 如果區塊構建者未能及時響應,使用構建者應用程式介面的驗證者仍有可能在本地構建區塊,因此他們不會錯過區塊提交獎勵。 然而,驗證者不能使用已揭示的交易或另一組交易來創建另一個區塊,因為這將構成 _雙重簽署_ (在同一個時槽內簽署兩個區塊) 的行為,這是一種可罰沒的違規行為。
+
+建構者 API 的一個實作範例是 [MEV Boost](https://github.com/flashbots/mev-boost),這是對 [Flashbots 拍賣機制](https://docs.flashbots.net/Flashbots-auction/overview) 的改進,旨在抑制 MEV 對以太坊的負面外部性。 Flashbots 拍賣允許權益證明中的驗證者將建構有利可圖區塊的工作外包給稱為 **搜尋者** 的專業參與方。
+
+
+搜尋者尋找有利可圖的 MEV 機會,並將交易捆綁包連同 [密封價格投標](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) 一起發送給區塊提議者,以便將其納入區塊。 運行 mev-geth,即 go-ethereum (Geth) 用戶端的分叉版本的驗證者只需要選擇利潤最高的交易包,並將其新增到新區塊的一部分。 為了保護區塊提議者 (驗證者) 免受垃圾郵件和無效交易的影響,交易捆綁包在到達提議者之前會經過 **中繼者** 進行驗證。
+
+MEV Boost 的運作方式與原來的 Flashbots 拍賣相同,但增加了一些為以太坊向權益證明過渡而設計的新功能。 搜尋者仍然會尋找有利可圖的 MEV 交易以納入區塊,但是一類稱為 **建構者** 的新型專業參與方,將負責將交易和捆綁包匯總到區塊中。 建置者接受搜尋者提供的價格密封出價,並執行最佳化以找到利潤最大的排序。
+
+中繼者仍然負責驗證交易捆綁並將其傳送給提交者。 然而,MEV Boost 引入了 **託管方**,負責透過儲存建構者發送的區塊主體和驗證者發送的區塊頭來提供 [資料可用性](/developers/docs/data-availability/)。 對於代管,連結到中繼的驗證者請求可用的執行有效負載,並使用MEV Boost 的順序演算法選擇出價 + 最大可提取價值小費最高的有效負載頭。
+
+#### 建置者應用程式介面如何減低最大可提取價值的影響? {#how-does-builder-api-curb-mev-impact}
+
+建置者應用程式介面的核心優勢在於,它有可能讓參與者平等獲得最大可提取價值機會。 使用提交-揭露方案消除了信任假設,降低了尋求從最大可提取價值中獲利的驗證者的進入門檻。 這應該可以減輕單獨質押者加入大型質押池,以提高最大可提取價值利潤的壓力。
+
+建置者應用程式介面的廣泛實作將鼓勵區塊建置者之間進行更激烈的競爭,這將增強抗審查能力。 驗證者審查多個構建者的出價時,意圖審查一筆或多筆用戶交易的構建者必須出價高於所有其他不審查的構建者才能成功。 這大大增加了審查使用者的成本並對審查有所限制。
+
+一些項目,例如 MEV Boost,將構建者應用程式介面作爲整體結構的一部分,旨在為某些參與方 (例如試圖避免搶先交易/三明治攻擊的交易者) 提供交易隱私。 這是透過在使用者和區塊建置者之間提供一條私密通訊通道來實現的。 與先前描述的許可内存池不同,這種方法是有益的,原因如下:
+
+1. 市場上有多種建置者存在讓審查變得不切實際,這是有利於使用者的。 相反,基於信任的中心化暗池的存在將權力集中在少數區塊構建者的手中,並增加了審查的可能性。
+
+2. 建置者應用程式介面軟體是開源的,允許任何人提供區塊建置者服務。 這意味著使用者不會被迫使用任何特定的區塊建置者,並提高了以太坊的中立和無許可特性。 此外,尋求最大可提取價值的交易者不會因為使用私密交易管道而無意中促進中心化。
+
+## 相關資源 {#related-resources}
+
+- [Flashbots 文件](https://docs.flashbots.net/)
+- [Flashbots GitHub](https://github.com/flashbots/pm)
+- [mevboost.org](https://www.mevboost.org/) - _提供 MEV-Boost 中繼器和區塊建構者即時統計數據的追蹤器_
+
+## 延伸閱讀 {#further-reading}
+
+- [什麼是礦工可提取價值 (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/)
+- [MEV 與我](https://www.paradigm.xyz/2021/02/mev-and-me)
+- [以太坊是一座黑暗森林](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/)
+- [逃離黑暗森林](https://samczsun.com/escaping-the-dark-forest/)
+- [Flashbots:搶先應對 MEV 危機](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752)
+- [@bertcmiller 的 MEV 討論串](https://twitter.com/bertcmiller/status/1402665992422047747)
+- [MEV-Boost:為合併準備就緒的 Flashbots 架構](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
+- [什麼是 MEV Boost](https://www.alchemy.com/overviews/mev-boost)
+- [為什麼要執行 mev-boost?](https://writings.flashbots.net/writings/why-run-mevboost/)
+- [以太坊漫遊指南](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum)
diff --git a/public/content/translations/zh-tw/developers/docs/networking-layer/index.md b/public/content/translations/zh-tw/developers/docs/networking-layer/index.md
index 669968f52d2..12896c34e8e 100644
--- a/public/content/translations/zh-tw/developers/docs/networking-layer/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networking-layer/index.md
@@ -1,6 +1,6 @@
---
-title: 網路層(Networking Layer)
-description: 以太坊網路層簡介
+title: "網路層"
+description: "以太坊網路層簡介"
lang: zh-tw
sidebarDepth: 2
---
@@ -11,9 +11,9 @@ sidebarDepth: 2
執行用戶端透過執行層的點對點網路廣播交易。 這需要經過驗證的對等點之間進行加密通訊。 當一名驗證者被選擇來提議區塊,來自區域交易池的交易將會透過區域遠端程序呼叫連線傳遞到共識用戶端,然後被打包進信標區塊中。 之後,共識用戶端將在其點對點網路中廣播信標區塊。 這需要兩個獨立的點對點網路:一個連線執行用戶端來廣播交易,另一個連線共識用戶端來廣播區塊。
-## 前置要求 {#prerequisites}
+## 先決條件 {#prerequisites}
-對以太坊[節點和用戶端](/developers/docs/nodes-and-clients/)稍有瞭解將有助於理解本文。
+對以太坊[節點和用戶端](/developers/docs/nodes-and-clients/)有一定了解,將有助於您理解本頁內容。
## 執行層 {#execution-layer}
@@ -25,27 +25,27 @@ sidebarDepth: 2
這兩個堆疊平行運作。 發現堆疊將新的網路參與者傳送到網路中,而 DevP2P 堆疊則使它們能夠進行互動。
-### 發現 {#discovery}
+### 探索 {#discovery}
-發現是在網路中尋找其他節點的過程。 這會使用一小組引導節點來啓動(地址被[硬編碼](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)到用戶端中的節點,因此它們能夠立即被找到並將用戶端連線到對等點)。 這些引導節點只用於將新節點引入到一組對等點 - 這是它們唯一的目的,它們不參與正常的用戶端任務,如同步鏈,並且它們只在用戶端第一次啓動時使用。
+發現是在網路中尋找其他節點的過程。 這是透過一小組啟動節點來引導的(節點位址被[硬編碼](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go)到用戶端中,因此可以立即找到它們並將用戶端連接到對等點)。 這些引導節點只用於將新節點引入到一組對等點 - 這是它們唯一的目的,它們不參與正常的用戶端任務,如同步鏈,並且它們只在用戶端第一次啓動時使用。
-用於節點-引導節點互動的協定是 [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) 的修改版本,它使用[分散式雜湊資料表](https://en.wikipedia.org/wiki/Distributed_hash_table)來共用節點清單。 每個節點都有一個該資料表的版本,其中包含連線到其最近對等點所需的資訊。 這裏的「近」不是地理上的 - 距離是由節點 ID 的相似性來定義的。 每個節點的資料表都會定期刷新,作爲一種安全功能。 例如,在 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 中,發現協定節點也可以發送「ads」來展示用戶端支持的子協定,這允許對等點協調它們可以用於通訊的協定。
+用於節點與啟動節點之間互動的協議是 [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) 的修改形式,它使用[分散式哈希表](https://en.wikipedia.org/wiki/Distributed_hash_table)來共享節點列表。 每個節點都有一個該資料表的版本,其中包含連線到其最近對等點所需的資訊。 這裏的「近」不是地理上的 - 距離是由節點 ID 的相似性來定義的。 每個節點的資料表都會定期刷新,作爲一種安全功能。 例如,在 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 探索協議中,節點也能夠發送「廣告」,顯示用戶端支援的子協議,讓對等點能夠協商雙方都可以使用的通訊協議。
-發現從 PING-PONG 游戲開始。 一個成功的 PING-PONG 將新節點「連結綁定」到一個引導節點。 通知引導節點有新節點進入網路的初始訊息為 `PING`。 此 `PING` 包括關於新節點、引導節點和過期時間戳的雜湊資訊。 引導節點接收 `PING` 並返回包含 `PING` 雜湊的 `PONG`。 如果 `PING` 和 `PONG` 的雜湊相吻合,新節點和引導節點之間的連線就會被驗證,然後它們就被認爲「已綁定連結」。
+發現從 PING-PONG 游戲開始。 一個成功的 PING-PONG 將新節點「連結綁定」到一個引導節點。 提醒啟動節點有新節點進入網路的初始訊息是 `PING`。 這個 `PING` 包含關於新節點、啟動節點和到期時間戳的哈希資訊。 啟動節點收到 `PING` 後,會回傳一個包含 `PING` 哈希的 `PONG`。 如果 `PING` 和 `PONG` 的哈希相符,新節點和啟動節點之間的連線就會被驗證,即為「已綁定」。
-一旦綁定連結,新節點就可以向引導節點發送 `FIND-NEIGHBOURS` 請求。 引導節點返回的資料包含一個新節點可以連線的對等點清單。 如果節點沒有綁定連結,`FIND-NEIGHBOURS` 請求將會失敗,因而新節點將無法進入網路。
+一旦綁定,新節點就可以向啟動節點發送 `FIND-NEIGHBOURS` 請求。 引導節點返回的資料包含一個新節點可以連線的對等點清單。 如果節點沒有綁定,`FIND-NEIGHBOURS` 請求將會失敗,因此新節點將無法進入網路。
一旦新節點從引導節點收到鄰居清單,就會開始與每個鄰居節點進行 PING-PONG 交換。 成功的 PING-PONG 會將新節點與鄰居節點連結綁定,以實現訊息交換。
```
-start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours
+啟動用戶端 --> 連接到啟動節點 --> 綁定到啟動節點 --> 尋找鄰居節點 --> 綁定到鄰居節點
```
-執行用戶端目前使用 [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) 發現協定,並且正在努力遷移到 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 協定。
+執行用戶端目前使用 [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) 探索協議,並正積極遷移到 [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) 協議。
#### ENR:以太坊節點記錄 {#enr}
-[以太坊節點記錄 (ENR)](/developers/docs/networking-layer/network-addresses/) 是一個包含 3 個基本元素的物件:一個簽名(根據某種商定同意的身分識別方案產生的記錄内容的雜湊),一個追蹤記錄變更的序列編號,以及一個鍵值配對的任意清單。 這是一種面向未來的格式,它使得新對等點之間身分識別資訊的交換更加容易,並且是以太坊節點偏好的[網路地址](/developers/docs/networking-layer/network-addresses)格式。
+[以太坊節點記錄 (ENR)](/developers/docs/networking-layer/network-addresses/) 是一個物件,包含三個基本元素:一個簽章 (根據商定的身分方案對記錄內容進行哈希運算後的結果)、一個追蹤記錄變更的序號,以及一個任意的鍵值對列表。 這是一種能適應未來需求的格式,可讓新的對等點之間更容易交換識別資訊,也是以太坊節點偏好的[網路位址](/developers/docs/networking-layer/network-addresses)格式。
#### 爲什麽在使用者資料包通訊協定之上建置發現? {#why-udp}
@@ -53,7 +53,7 @@ start client --> connect to bootnode --> bond to bootnode --> find neighbours --
### DevP2P {#devp2p}
-DevP2P 本身是以太坊爲了建立和維護點對點網路而實作的一整套協定。 新節點進入網路之後,其互動由 [DevP2P](https://github.com/ethereum/devp2p)堆疊中的協定管理。 這些都建立於傳輸控制通訊協定之上,包括 RLPx 傳輸協定、綫路協定和一些子協定。 [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) 是管理啓動、驗證和維護節點之間工作階段的協定 RLPx 使用 RLP(遞迴長度前綴)編碼訊息,這是一種將資料編碼為最小結構來在節點之間發送的方法,這種方法非常節省空間。
+DevP2P 本身是以太坊爲了建立和維護點對點網路而實作的一整套協定。 新節點進入網路後,它們的互動由 [DevP2P](https://github.com/ethereum/devp2p) 堆疊中的協議所管理。 這些都建立於傳輸控制通訊協定之上,包括 RLPx 傳輸協定、綫路協定和一些子協定。 [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) 是管理節點之間啟動、驗證和維護會話的協議。 RLPx 使用 RLP(遞迴長度前綴)編碼訊息,這是一種將資料編碼為最小結構來在節點之間發送的方法,這種方法非常節省空間。
兩個節點之間的 RLPx 工作階段從初始加密握手開始。 這需要節點發送身份驗證訊息,然後對等點會進行驗證。 成功驗證後,對等點會生成驗證確認訊息,並將其返回初始節點。 這是一個密鈅交換程序,使節點能夠私密且安全地進行通訊。 成功的加密握手會觸發兩個節點「在綫上」互相發送「hello」訊息。 綫路協定透過成功交換 hello 訊息來發起。
@@ -69,47 +69,47 @@ hello 訊息包含:
除了「hello」訊息以外,綫路協定還可以發送「disconnect」訊息,該訊息警告對等點連線將會被關閉。 綫路協定還包含定期發送的 PING 和 PONG 訊息,以保持工作階段開放。 因此,RLPx 和綫路協定的交換為節點之間的通訊奠定了基礎,並為根據特定子協定交換的有用資訊提供了平台。
-### 子協定 {#sub-protocols}
+### 子協議 {#sub-protocols}
-#### 綫路協定 {#wire-protocol}
+#### 有線協議 {#wire-protocol}
-一旦對等點連線並且 RLPx 工作階段啓動,綫路協定就會定義對等點的通訊方式。 一開始,綫路協定會定義三個主要任務:鏈同步、區塊傳播和交易交換。 然而,以太坊切換到權益證明後,區塊傳播和鏈同步變成了共識層的一部分。 但交易交換仍然由執行用戶端負責。 交易交換指的是節點之間交換等待處理的交易,以便區塊建置者能夠選擇其中一些放到下一個區塊中。 請在[此處](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)查看有關這些任務的詳細資訊。 支持這些子協定的用戶端透過 [JSON-RPC](/developers/docs/apis/json-rpc/) 將自己公開。
+一旦對等點連線並且 RLPx 工作階段啓動,綫路協定就會定義對等點的通訊方式。 一開始,綫路協定會定義三個主要任務:鏈同步、區塊傳播和交易交換。 然而,以太坊切換到權益證明後,區塊傳播和鏈同步變成了共識層的一部分。 但交易交換仍然由執行用戶端負責。 交易交換指的是節點之間交換等待處理的交易,以便區塊建置者能夠選擇其中一些放到下一個區塊中。 關於這些任務的詳細資訊,請參閱[此處](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)。 支援這些子協議的用戶端會透過 [JSON-RPC](/developers/docs/apis/json-rpc/) 將它們公開。
-#### les(輕量以太坊子協定) {#les}
+#### les (輕量以太坊子協議) {#les}
-這是用於同步輕量級用戶端的最小協定。 傳統上,該協定很少被使用,因爲全節點需要在沒有激勵的情況下向輕用戶端提供資料。 執行用戶端的預設行爲不是透過 les 為輕量級用戶端提供服務。 請在 les [規範](https://github.com/ethereum/devp2p/blob/master/caps/les.md)中查看更多相關資訊。
+這是用於同步輕量級用戶端的最小協定。 傳統上,該協定很少被使用,因爲全節點需要在沒有激勵的情況下向輕用戶端提供資料。 執行用戶端的預設行爲不是透過 les 為輕量級用戶端提供服務。 更多資訊請參閱 les [規格](https://github.com/ethereum/devp2p/blob/master/caps/les.md)。
-#### 快照 {#snap}
+#### Snap {#snap}
-[快照協定](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap)是一種可選的擴充功能,它使對等點能夠交換最近狀態的快照,從而無需下載默克爾樹的内部節點就能驗證帳戶及存儲資料。
+[快照協議 (snap protocol)](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) 是一種可選的擴充功能,讓對等點能交換最近狀態的快照,從而無需下載中介的默克爾樹節點即可驗證帳戶和儲存資料。
-#### Wit(見證協定) {#wit}
+#### Wit (見證協議) {#wit}
-[見證協定](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit)是一種可選的擴充功能,使對等點之間能夠交換狀態見證,幫助用戶端與鏈前端同步。
+[見證協議 (witness protocol)](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) 是一種可選的擴充功能,能在對等點之間交換狀態見證,有助於將用戶端同步到鏈的頂端。
#### Whisper {#whisper}
-Whisper 是一個旨在實現安全的點對點資訊傳輸,而不需要向區塊鏈寫入任何資訊的協定。 它曾是 DevP2P 綫路協定的一部分,但現在已經棄用。 其他[相關專案](https://wakunetwork.com/)也有類似目標。
+Whisper 是一個旨在實現安全的點對點資訊傳輸,而不需要向區塊鏈寫入任何資訊的協定。 它曾是 DevP2P 綫路協定的一部分,但現在已經棄用。 也有其他目標類似的[相關專案](https://wakunetwork.com/)。
## 共識層 {#consensus-layer}
共識用戶端參與具有不同規範的單獨點對點網路。 共識用戶端需要參與區塊廣播,以便其能夠從對等點接受新區塊,並在輪到其成爲區塊提議者時廣播它們。 與執行層類似,這首先需要一個發現協定,一邊節點可以找到對等點並建立安全的工作階段來交換區塊、證明等。
-### 發現 {#consensus-discovery}
+### 探索 {#consensus-discovery}
-與執行用戶端類似,共識用戶端使用使用者資料包通訊協定上的 [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) 尋找對等點。 discv5 的共識層實現與執行用戶端的區別僅在於,它包含一個將 discv5 連線到 [libP2P](https://libp2p.io/) 堆疊的適配器,棄用了 DevP2P。 執行層的 RLPx 工作階段被棄用,代之以 libP2P 的噪音安全通道握手。
+與執行用戶端類似,共識用戶端也透過 UDP 使用 [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) 來尋找對等點。 discv5 的共識層實作與執行用戶端的實作不同之處僅在於:它包含一個將 discv5 連接到 [libP2P](https://libp2p.io/) 堆疊的適配器,並棄用了 DevP2P。 執行層的 RLPx 工作階段被棄用,代之以 libP2P 的噪音安全通道握手。
-### 以太坊節點記錄 {#consensus-enr}
+### ENR {#consensus-enr}
-共識節點的以太坊節點記錄包括節點的公鑰、IP 地址、使用者資料包通訊協定和傳輸控制通訊協定連接埠,以及兩個共識特定欄位:證明子網路位元欄位和 `eth2` 金鑰。 前者使節點更容易找到參與特定證明廣播子網路的對等點。 `eth2` 金輪包含節點正在使用的以太坊分叉版本的資訊,以確保對等點連線到正確的以太坊。
+共識節點的 ENR 包括節點的公鑰、IP 位址、UDP 和 TCP 連接埠,以及兩個共識專屬的欄位:證明子網路位元欄位和 `eth2` 金鑰。 前者使節點更容易找到參與特定證明廣播子網路的對等點。 `eth2` 金鑰包含節點正在使用的以太坊分叉版本資訊,確保對等點連接到正確的以太坊。
### libP2P {#libp2p}
libP2P 堆疊支持發現之後的所有通訊。 用戶端可以根據其以太坊節點記錄的定義在 IPv4 和/或 IPv6 上撥號和接聽。 libP2P 層上的協定可以細分爲廣播和請求/響應域。
-### 廣播 {#gossip}
+### 傳播 {#gossip}
-廣播域包括必須在整個網路中快速傳播的所有資訊。 這包括信標區區塊、證據、證明、退出和罰沒。 這是使用 libP2P gossipsub v1 傳輸的,並且依賴於在每個節點本機儲存的各種中繼資料,包括接收和傳輸的廣播承載的上限。 請在[此處](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)查看有關廣播域的詳細資訊。
+廣播域包括必須在整個網路中快速傳播的所有資訊。 這包括信標區區塊、證據、證明、退出和罰沒。 這是使用 libP2P gossipsub v1 傳輸的,並且依賴於在每個節點本機儲存的各種中繼資料,包括接收和傳輸的廣播承載的上限。 關於傳播網域的詳細資訊,請參閱[此處](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub)。
### 請求-回應 {#request-response}
@@ -119,25 +119,25 @@ libP2P 堆疊支持發現之後的所有通訊。 用戶端可以根據其以太
SSZ 代表簡單序列化。 它使用固定位移,能夠簡單地解碼編碼訊息的單獨部分,而無需解碼整個結構,這對於共識用戶端非常有用,因爲它可以高效地從編碼訊息中獲取特定資訊片段。 它還專門設計於與默克爾協定整合,並提升與默克爾化相關的效率。 由於共識層中的所有雜湊都是默克爾根,這會帶來顯著的改進。 簡單序列化也保證值的唯一表示。
-## 連線執行用戶端和共識用戶端 {#connecting-clients}
+## 連接執行用戶端與共識用戶端 {#connecting-clients}
-共識用戶端和執行用戶端平行運作。 它們需要彼此連線,以便共識用戶端向執行用戶端提供指示,並使執行用戶端能夠向執行用戶端傳送需要納入信標區塊的交易捆綁。 兩個用戶端之間的通訊可以透過本機遠端程序呼叫連線來實現。 名爲[「Engine-API」](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)的應用程式介面定義兩個用戶端之間發送的指示。 由於兩個用戶端共用一個網路身分,它們也共用一個 ENR(以太坊節點記錄),其中包含每個用戶端的單獨金鑰(eth1 金鑰和 eth2 金鑰)。
+共識用戶端和執行用戶端平行運作。 它們需要彼此連線,以便共識用戶端向執行用戶端提供指示,並使執行用戶端能夠向執行用戶端傳送需要納入信標區塊的交易捆綁。 兩個用戶端之間的通訊可以透過本機遠端程序呼叫連線來實現。 一個稱為「Engine-API」的 [API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) 定義了在這兩個用戶端之間傳送的指令。 由於兩個用戶端共用一個網路身分,它們也共用一個 ENR(以太坊節點記錄),其中包含每個用戶端的單獨金鑰(eth1 金鑰和 eth2 金鑰)。
如下展示了控制流摘要,括號中是相關的網路堆疊。
### 當共識用戶端不是區塊生產者時: {#when-consensus-client-is-not-block-producer}
- 共識用戶端透過區塊廣播協定(共識點對點)接收區塊
-- 共識用戶端預驗證區塊,即確保它來自具有正確中繼資料的有效發送者
+- 共識用戶端預先驗證區塊,即確保區塊來自有效的發送者且帶有正確的中繼資料
- 區塊中的交易作爲執行承載發送到執行層(本機遠端程序呼叫連線)
-- 執行層執行交易並驗證區塊頭中的狀態(即檢查雜湊是否相符)
+- 執行層執行交易並驗證區塊頭中的狀態 (即檢查哈希是否相符)
- 執行層將驗證資料傳送回共識層,區塊現在被認爲已驗證(本機遠端程序呼叫連線)
- 共識層將區塊添加到其區塊鏈頭並證明該區塊,透過網路廣播證明(共識點對點)
### 當共識用戶端是區塊生產者時: {#when-consensus-client-is-block-producer}
- 共識用戶端收到其將成爲下一個區塊生產者的通知(共識點對點)
-- 共識層在執行用戶端調用 `create block` 方法(本機遠端程序呼叫)
+- 共識層在執行用戶端中呼叫 `create block` 方法 (本機 RPC)
- 執行層訪問已由交易廣播協定填充的交易内存池(執行點對點)
- 執行用戶端將交易捆綁進一個區塊,執行交易並產生一個區塊雜湊
- 共識用戶端從執行用戶端獲取交易和區塊雜湊,並將其新增至信標區塊(本機遠端程序呼叫)
@@ -146,10 +146,18 @@ SSZ 代表簡單序列化。 它使用固定位移,能夠簡單地解碼編碼
一旦區塊被足夠多的驗證者證明后,就會被新增到鏈頭,經過合理化並最終確定。
- 
+
+
-共識用戶端和執行用戶端的網路層示意圖,取自 [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
+共識和執行用戶端的網路層示意圖,來源:[ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
-[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [共識層網路規範](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia 到 discv5](https://vac.dev/kademlia-to-discv5) [kademlia 論文](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [以太坊點對點簡介](https://p2p.paris/en/talks/intro-ethereum-networking/) [eth1/eth2 的關係](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [合併和 eth2 用戶端詳情影片](https://www.youtube.com/watch?v=zNIrIninMgg)
+[DevP2P](https://github.com/ethereum/devp2p)
+[LibP2p](https://github.com/libp2p/specs)
+[共識層網路規格](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)
+[kademlia 到 discv5](https://vac.dev/kademlia-to-discv5)
+[kademlia 論文](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf)
+[以太坊點對點網路介紹](https://p2p.paris/en/talks/intro-ethereum-networking/)
+[eth1/eth2 關係](http://ethresear.ch/t/eth1-eth2-client-relationship/7248)
+[合併與 eth2 用戶端詳細資訊影片](https://www.youtube.com/watch?v=zNIrIninMgg)
diff --git a/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md
index 59be88f0d71..deecfca1fae 100644
--- a/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networking-layer/network-addresses/index.md
@@ -1,39 +1,39 @@
---
-title: 網路地址(Network addresses)
-description: 網路地址簡介
+title: "網路地址"
+description: "網路地址簡介"
lang: zh-tw
sidebarDepth: 2
---
以太坊節點必須使用一些基本資訊識別自身,以連接對等節點。 為了確保任何潛在對等節點都能解釋該資訊,需要使用任何以太網節點都能理解的三種標準化格式中的一種進行轉送:Multiaddr、Enode 或以太坊節點記錄 (ENR)。 以太坊節點紀錄 (ENR) 是目前的以太坊網路地址標準。
-## 先備知識 {#prerequisites}
+## 先決條件 {#prerequisites}
-要理解本頁內容,需具備一些以太坊[網路層](/developers/docs/networking-layer/)的基本知識。
+要了解此頁面,您需要對以太坊的[網路層](/developers/docs/networking-layer/)有一些了解。
## Multiaddr {#multiaddr}
-原始以太坊節點地址的格式為「multiaddr」(簡稱「多重地址」)。 Multiaddr 是為點對點網絡設計的通用格式。 這些地址利用鍵值配對表示,其中的鍵與值以斜線分隔。 例如,對於一個 IPv4 地址為 `192.168.22.27`、監聽傳輸控制通訊協定 (TCP) 連接埠 `33000` 的節點,其 Multiaddr 可以表示為:
+原始以太坊節點地址的格式為「multiaddr」(簡稱「多重地址」)。 Multiaddr 是為點對點網絡設計的通用格式。 這些地址利用鍵值配對表示,其中的鍵與值以斜線分隔。 例如,一個 IPv4 位址為 `192.168.22.27` 並監聽 TCP 連接埠 `33000` 的節點,其 multiaddr 如下:
-`/ip4/192.168.22.27/tcp/33000`
+/ip4/192.168.22.27/tcp/33000
若以太坊節點為例,含有節點 ID(其公鑰的雜湊值)的 Multiaddr 可以表示為:
-`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br`
+/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br
## Enode {#enode}
Enode 使得以太坊節點可以用統一資源定位器地址格式識別。 在統一資源定位器的使用者名稱部分編碼十六進位的節點 ID,並使用 @ 將其與主機名稱分開。 主機名稱只能使用 IP 地址表示;不能使用網域名稱服務名稱。 主機名稱部分的連接埠是傳輸控制通訊協定 (TCP) 監聽連接埠。 如果傳輸控制通訊協定 (TCP) 與使用者資料包通訊協定 (UDP) 連接埠不同,則使用者資料包通訊協定 (UDP) 連接埠必須宣告為查詢參數「discport」。
-下述範例中,節點統一資源定位器由 IP 地址 `10.3.58.6`、傳輸控制通訊協定 (TCP) 連接埠 `30303` 以及使用者資料包通訊協定 (UDP) 探索連接埠 `30301` 組成。
+在以下範例中,節點 URL 描述了一個 IP 位址為 `10.3.58.6`、TCP 連接埠為 `30303`,以及 UDP 探索連接埠為 `30301` 的節點。
-`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301`
+enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301
## 以太坊節點紀錄 (ENR) {#enr}
-以太坊節點紀錄 (ENR) 是目前以太坊網路地址的標準化格式。 它取代了 Multiaddr 與 Encode 格式, 並允許節點間更大量的資訊交換,這一點尤其有用。 以太坊節點紀錄包含簽章、序列編號和多個欄位,這些欄位詳細說明用於產生和驗證簽章的身分識別方案。 以太坊節點紀錄也可以填入任意組織為鍵值配對形式的資料。 這些鍵值配對包含節點的 IP 地址以及節點能使用的子通訊協定相關資訊。 共識用戶端使用一種[特定的以太坊節點記錄結構](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)來識別引導節點,並且也包含一個 `eth2` 欄位,其中包含有關目前以太坊分叉和證明八卦子網路(該子網路將節點連線到一組已將其證明彙總到一起的特定對等方)的資訊。
+以太坊節點紀錄 (ENR) 是目前以太坊網路地址的標準化格式。 它取代了 Multiaddr 與 Encode 格式, 並允許節點間更大量的資訊交換,這一點尤其有用。 以太坊節點紀錄包含簽章、序列編號和多個欄位,這些欄位詳細說明用於產生和驗證簽章的身分識別方案。 以太坊節點紀錄也可以填入任意組織為鍵值配對形式的資料。 這些鍵值配對包含節點的 IP 地址以及節點能使用的子通訊協定相關資訊。 共識用戶端使用[特定的 ENR 結構](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)來識別引導節點,且亦包含 `eth2` 欄位,其中含有關於當前以太坊分叉和證明 gossip 子網路的資訊(此子網路將節點連結至一組特定的對等點,其證明會被匯總在一起)。
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [EIP-778:以太坊節點紀錄 (ENR)](https://eips.ethereum.org/EIPS/eip-778)
-- [LibP2P:Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
+- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
diff --git a/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md
index 2e6e0a8b394..e8d82096e87 100644
--- a/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networking-layer/portal-network/index.md
@@ -1,6 +1,6 @@
---
-title: 入口網路
-description: 入口網路概覽 - 一個開發中的網路,設計用來支援資源匱乏的客戶端。
+title: "入口網路"
+description: "入口網路概覽 - 一個開發中的網路,設計用來支援資源匱乏的客戶端。"
lang: zh-tw
---
@@ -10,25 +10,25 @@ lang: zh-tw
入口網路是為以太坊開發的新型網路設計。藉由以小塊方式在整個網路分享必要性的資料,輕量級節點不需要信任或增加全節點負擔的方式,解決資料可用性問題。
-更多資訊請參閱[節點和用戶端](/developers/docs/nodes-and-clients/)
+深入了解[節點和用戶端](/developers/docs/nodes-and-clients/)
-## 為什麼我們需要入口網路 {#why-do-we-need-portal-network}
+## 我們為什麼需要入口網路 {#why-do-we-need-portal-network}
以太坊節點儲存以太坊區塊鏈的全部或部分複製資料。 這些區域性的複本被用來驗證交易和確保節點沿著正確的區塊鏈行進。 在區域儲存資料使節點能夠獨立驗證進來的資料有效和正確與否,不需要依賴任何其他實體。
-區塊鏈以及相關狀態和收據資料的區域複本佔據節點硬碟相當大的空間。 例如:使用 [Geth](https://geth.ethereum.org) 搭配共識用戶端來經營一個節點,建議要有 2TB 的硬碟。 使用只儲存比較近期的區塊組的鏈資料的快照同步,Geth 通常佔用約 650GB 的磁碟空間,但以約 14GB/周在成長(你可以定期向下修整節點至 650GB)。
+區塊鏈以及相關狀態和收據資料的區域複本佔據節點硬碟相當大的空間。 例如,建議使用 2TB 的硬碟,以執行與共識用戶端配對的 [Geth](https://geth.ethereum.org) 節點。 使用只儲存比較近期的區塊組的鏈資料的快照同步,Geth 通常佔用約 650GB 的磁碟空間,但以約 14GB/周在成長(你可以定期向下修整節點至 650GB)。
-這意味著經營節點的成本是很高的,因為以太坊需要大量的專用磁碟空間。 在以太坊開發藍圖上對這個問題有若干解決方法,包括[歷史有效期限](/roadmap/statelessness/#history-expiry)、[狀態有效期限](/roadmap/statelessness/#state-expiry)和[無狀態](/roadmap/statelessness/)。 然而,這可能要若干年後才有可能實行。 還有不必保存自己的鏈上資料複本的[輕量級節點](/developers/docs/nodes-and-clients/light-clients/),它們需要向全節點請求資料。 然而,這意味著輕量級節點必須信任全節點會提供真實的資料,並且強調全節點必須提供輕量級節點需要的資料。
+這意味著經營節點的成本是很高的,因為以太坊需要大量的專用磁碟空間。 以太坊開發藍圖上有幾個此問題的解決方案,包括[歷史紀錄過期](/roadmap/statelessness/#history-expiry)、[狀態過期](/roadmap/statelessness/#state-expiry) 和[無狀態性](/roadmap/statelessness/)。 然而,這可能要若干年後才有可能實行。 另外還有[輕量節點](/developers/docs/nodes-and-clients/light-clients/),它們不會儲存自己的鏈上資料複本,而是向完整節點請求所需的資料。 然而,這意味著輕量級節點必須信任全節點會提供真實的資料,並且強調全節點必須提供輕量級節點需要的資料。
入口網路旨在提供一種替代方法,使輕量級節點能夠獲取它們的資料,而無需信任或顯著增加全節點必須完成的工作。 讓整個網路上的以太坊節點可以分享資料,需要引入新的方法。
## 入口網路如何運作? {#how-does-portal-network-work}
-以太坊節點有嚴格的協定來定義它們如何相互通訊。 執行用戶端使用一組稱為 [DevP2P](/developers/docs/networking-layer/#devp2p) 的子協定通訊,而共識用戶端則使用一組不同的被稱為 [libP2P](/developers/docs/networking-layer/#libp2p) 的子協定。 它們定義了可以在節點之間傳遞的資料類型。
+以太坊節點有嚴格的協定來定義它們如何相互通訊。 執行用戶端使用一組稱為 [DevP2P](/developers/docs/networking-layer/#devp2p) 的子協定進行通訊,而共識用戶端則使用另一組稱為 [libP2P](/developers/docs/networking-layer/#libp2p) 的子協定堆疊。 它們定義了可以在節點之間傳遞的資料類型。

-節點可以經由 [JSON-RPC 應用程式介面](/developers/docs/apis/json-rpc/)提供特定資料,這是應用程式和電子錢包與以太坊節點交換資訊的方式。 然而,這些都不是用來提供資料給輕量級用戶端的理想協定。
+節點也可透過 [JSON-RPC API](/developers/docs/apis/json-rpc/) 提供特定資料,應用程式和錢包就是透過這種方式與以太坊節點交換資訊。 然而,這些都不是用來提供資料給輕量級用戶端的理想協定。
輕量級用戶端目前無法透過 DevP2P 或 libP2p 請求具體的鏈資料,因爲那些協定只被設計來實現鏈同步和廣播區塊與交易。 輕量級用戶端不想下載這些資訊,因為這樣它們將不再是「輕量」的。
@@ -36,7 +36,7 @@ JSON-RPC 應用程式介面也不是輕量級用戶端資料請求的理想選
入口網路的重點在於重新思考整個設計,專門為輕便而建立,不受現有以太坊用戶端的設計限制。
-入口網路的核心思想是使用[分散式雜湊資料表](https://en.wikipedia.org/wiki/Distributed_hash_table)(類似於 Bittorrent),透過輕量 DevP2P 式的點對點去中心化網絡啓用輕量級用戶端所需的資訊,例如歷史資料和目前鏈頭的身份,從而充分利用目前網路堆棧的最佳部分。
+入口網路的核心概念是汲取當前網路堆疊的精華,透過輕量級 DevP2P 風格的點對點去中心化網路,使用[分散式雜湊表 (DHT)](https://en.wikipedia.org/wiki/Distributed_hash_table)(類似 Bittorrent)來提供輕量用戶端所需的資訊,例如歷史資料與當前鏈首的身分。
這個概念是新增小部分的以太坊全體歷史資料和一些特定節點責任到每一個節點。 然後,尋找儲存所請求特定資料的節點,擷取這些資料,將資料提供給請求。
@@ -48,16 +48,16 @@ JSON-RPC 應用程式介面也不是輕量級用戶端資料請求的理想選
- 同步近期和歷史鏈資料
- 擷取狀態資料
- 廣播交易
-- 使用[以太坊虛擬機](/developers/docs/evm/)執行交易
+- 使用 [EVM](/developers/docs/evm/) 執行交易
這個網路設計的優勢是:
- 降低對中心化提供者的依存
- 降低網際網路頻寬的使用
- 同步處理減到最少或零
-- 可存取資源有限的裝置(\<1 GB RAM,\<100 MB 磁碟空間,1 個 CPU)
+- 可供資源受限的裝置存取 (\<1 GB RAM、\<100 MB 磁碟空間、1 個 CPU)
-下圖顯示可由入口網路提供的現存用戶端功能,如此讓使用者能在低資源裝置上存取這些功能。
+下表顯示可由入口網路提供的現有用戶端功能,能讓使用者在資源極少的裝置上存取這些功能。
### 入口網路
@@ -69,21 +69,21 @@ JSON-RPC 應用程式介面也不是輕量級用戶端資料請求的理想選
## 預設的用戶端多樣性 {#client-diversity-as-default}
-入口網路開發者最初也決定建立三種不同的入口網路用戶端設計。
+入口網路的開發者也從一開始就做出了設計選擇,要建置四個獨立的入口網路用戶端。
入口網路用戶端如下:
-- [Trin](https://github.com/ethereum/trin):以 Rust 編寫
-- [Fluffy](https://nimbus.team/docs/fluffy.html):以 Nim 編寫
-- [Ultralight](https://github.com/ethereumjs/ultralight):以 Typescript 編寫
-- [Shisui](https://github.com/optimism-java/shisui):以 Go 語言編寫
+- [Trin](https://github.com/ethereum/trin):以 Rust 撰寫
+- [Fluffy](https://fluffy.guide):以 Nim 撰寫
+- [Ultralight](https://github.com/ethereumjs/ultralight):以 Typescript 撰寫
+- [Shisui](https://github.com/zen-eth/shisui):以 Go 撰寫
有多個獨立用戶端安裝啟用,增強了以太坊網路的回復力和去中心化。
假如一個用戶端遭受問題或漏洞,其他用戶端能繼續順暢運作,可以防止單點失靈。 此外,多樣化的用戶端安裝啟用能促進創新和競爭,驅使改善,和降低在這生態系統的單一文化風險。
-## 了解更多 {#futher-reading}
+## 延伸閱讀 {#further-reading}
-- [入口網路(Piper Merriam 在 Bogota 舉辦的 Devcon 大會)](https://www.youtube.com/watch?v=0stc9jnQLXA)。
-- [入口網路 discord](https://discord.gg/CFFnmE7Hbs)
+- [入口網路 (Piper Merriam 於 Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA)。
+- [入口網路 Discord](https://discord.gg/CFFnmE7Hbs)
- [入口網路網站](https://www.ethportal.net/)
diff --git a/public/content/translations/zh-tw/developers/docs/networks/index.md b/public/content/translations/zh-tw/developers/docs/networks/index.md
index 241733f4b9a..23d9d3eaedf 100644
--- a/public/content/translations/zh-tw/developers/docs/networks/index.md
+++ b/public/content/translations/zh-tw/developers/docs/networks/index.md
@@ -1,6 +1,6 @@
---
-title: 網路
-description: 以太坊網路及何處獲取測試網以太幣 (ETH) 測試應用程式之概觀。
+title: "網路"
+description: "以太坊網路及何處獲取測試網以太幣 (ETH) 測試應用程式之概觀。"
lang: zh-tw
---
@@ -8,36 +8,37 @@ lang: zh-tw
你的以太坊帳戶可以跨不同網路使用,但你的帳戶餘額及交易歷史記錄並不會跟著從以太坊主網轉移過去。 進行測試時,知道哪些網路可用及如何取得要試用的測試網以太幣是非常有用的。 一般來說,出於安全考量,並不推薦在測試網上再次使用主網帳戶,反之亦然。
-## 基本資訊 {#prerequisites}
+## 先決條件 {#prerequisites}
-在深入閱讀不同網路相關內容前,你應先了解[以太坊的基礎知識](/developers/docs/intro-to-ethereum/),因為測試網路會給你提供實惠、安全的以太坊版本以供測試。
+在深入閱讀不同網路的相關內容前,你應先了解[以太坊的基礎知識](/developers/docs/intro-to-ethereum/),因為測試網會給你提供實惠、安全的以太坊版本以供測試。
## 公共網路 {#public-networks}
-公共網路可由全球任何人透過網際網路進行存取。 任何人都可以在公共區塊鏈上讀取或建立交易,並且可以驗證已經執行的交易。 網路中對等節點間的共識決定了交易的納入和網路的狀態。
+公共網路可供世界上任何有網際網路連線的人訪問。 任何人都能在公共區塊鏈上讀取或創建交易並驗證被執行的交易。 對等節點間的共識決定了交易的打包和網路的狀態。
-### 主網 {#mainnet}
+### 以太坊主網 {#ethereum-mainnet}
-主網是指主要的以太坊生產區塊鏈,所有具有實際價值的交易都發生在主網的去中心化帳本上。
+主網為以太坊的主要公共生產區塊鏈,也為實際交易發生於分佈式帳本之所在。
-當人們和交易所討論 ETH 價格時,他們談論的是主網上的 ETH。
+當人們和交易所討論以太幣價格時,討論的是主網以太幣。
-### 測試網 {#testnets}
+### 以太坊測試網 {#ethereum-testnets}
-除了主網外,還有公共測試網。 測試網由協議開發者或智慧型合約開發者使用,用於在將建議部署到主網之前,在模擬主網的環境中測試協議升級和潛在的智慧型合約。 將其視為生產與試運行伺服器的類比。
+除主網外,還有一些公共測試網。 應用程式開發者或智慧型合約開發者使用測試網來測試協議升級,也用於在部署到主網之前在一個類生產環境中測試潛在的智慧型合約。 可將主網與測試網類比於生產伺服器與暫置伺服器。
-在將你的合約部署到主網前,你應該先在測試網上測試你編寫的任何合約程式碼。 在與現有智慧型合約整合的去中心化應用程式中,大多數專案會將副本部署在測試網上。
+部署至主網前,應在測試網上測試你編寫的所有合約程式碼。 在整合了智慧型合約的去中心化應用程式中,大部分專案都有部署到測試網的版本。
-目前主要的測試網是 Sepolia 和 Hoodi。 Sepolia 是合約和應用程式開發者用來測試其應用程式的網路。 而在 Hoodi 網路上,協議開發者測試網路升級,質押者測試驗證者的運行狀況。
+大部分測試網一開使都使用權威證明共識機制。 這表示將挑選出一小部分節點驗證交易並創建新區塊 – 並在此過程中質押其身分。 或者,有些測試網採用開放的權益證明共識機制,任何人都可以測試驗證者的運行狀況,就像在以太坊主網上一樣。
-#### Sepolia {#sepolia}
+測試網上的以太幣原本應該是沒有實際價值的;然而,已經有為取得一些稀少或難以獲得的測試網以太幣而建立的市場。 因為要和以太坊(即使在測試網上)實際互動需要以太幣,多數人透過水龍頭免費獲得測試網以太幣。 多數水龍頭為 Web 應用程式,你可以在其中輸入你請求發送以太幣的地址。
+
+#### 我該使用哪個測試網?
-Sepolia 是推薦供開發者測試其應用程式的測試網。 Sepolia 網路採用許可制的驗證者集。 這意味著此測試網不對外開放新的驗證者,因此不具高風險性不會分叉或遇到下線的問題。 相對而言,該網路也擁有較小的狀態,這意味著需同步的網路較小,運行節點和與網路交互會更加容易。
+目前用戶端開發者維護的兩個公共測試網分別為 Sepolia 及 Hoodi。 Sepolia 是合約和應用程式開發者用來測試其應用程式的網路。 在 Hoodi 網路上,協議開發者測試網路升級,質押者測試驗證者的運行狀況。
-- 採許可制的驗證者集,由用戶端和測試團隊控制
-- 新測試網,狀態資料較少
-- 快速同步且建立節點容易
-- 若需測試合約或去中心化應用程式,可使用此網路
+#### Sepolia {#sepolia}
+
+**Sepolia 是推薦用於應用程式開發的預設測試網**。 Sepolia 網路使用許可制的驗證程式集合,由用戶端和測試團隊控制。
##### 資源
@@ -45,78 +46,135 @@ Sepolia 是推薦供開發者測試其應用程式的測試網。 Sepolia 網路
- [GitHub](https://github.com/eth-clients/sepolia)
- [Otterscan](https://sepolia.otterscan.io/)
- [Etherscan](https://sepolia.etherscan.io)
+- [Blockscout](https://eth-sepolia.blockscout.com/)
##### 水龍頭
-- [工作量證明水龍頭](https://sepolia-faucet.pk910.de/)
-- [Coinbase 錢包水龍頭 | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet)
-- [Alchemy Sepolia 水龍頭](https://sepoliafaucet.com/)
-- [QuickNode Sepolia 水龍頭](https://faucet.quicknode.com/drip)
+- [Alchemy Sepolia 水龍頭](https://www.alchemy.com/faucets/ethereum-sepolia)
+- [Chain Platform Sepolia 水龍頭](https://faucet.chainplatform.co/faucets/ethereum-sepolia/)
+- [Chainstack Sepolia 水龍頭](https://faucet.chainstack.com/sepolia-testnet-faucet)
+- [以太坊生態系水龍頭](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia)
+- [ethfaucet.com Sepolia 水龍頭](https://ethfaucet.com/networks/ethereum)
+- [Google Cloud Web3 Sepolia 水龍頭](https://cloud.google.com/application/web3/faucet/ethereum/sepolia)
+- [Grabteeth](https://grabteeth.xyz/)
- [Infura Sepolia 水龍頭](https://www.infura.io/faucet)
-- [Chainstack Sepolia 水龍頭](https://faucet.chainstack.com/sepolia-faucet)
-- [Alchemy Sepolia 水龍頭](https://sepoliafaucet.com/)
+- [PoW 水龍頭](https://sepolia-faucet.pk910.de/)
+- [QuickNode Sepolia 水龍頭](https://faucet.quicknode.com/ethereum/sepolia)
#### Hoodi {#hoodi}
-Hoodi 是為測試驗證和質押而設計的測試網。 Hoodi 網路對於希望運行測試網驗證者的使用者開放。 因此,想測試協議升級的質押者,應在部署至主網前先使用 Hoodi 測試。
+Hoodi 是測試驗證和質押的測試網。 Hoodi 測試網對想要運行測試網驗證者的使用者開放。 因此,想測試協議升級的質押者,應在部署至主網前先使用 Hoodi 測試。
-- 開放的驗證者集,質押者可測試網路升級
-- 較大的狀態資料,適用於測試複雜的智慧合約互動
-- 同步時間較長,運行節點需要更多儲存空間
+- 開放的驗證者集合,質押者可以測試網路升級
+- 龐大的狀態,對於測試複雜的智能合約互動很有幫助
+- 同步時間更長,運行節點需要更多存儲
##### 資源
- [網站](https://hoodi.ethpandaops.io/)
- [GitHub](https://github.com/eth-clients/hoodi)
-- [區塊瀏覽器](https://explorer.hoodi.ethpandaops.io/)
+- [瀏覽器](https://explorer.hoodi.ethpandaops.io/)
- [檢查點同步](https://checkpoint-sync.hoodi.ethpandaops.io/)
+- [Otterscan](https://hoodi.otterscan.io/)
+- [Etherscan](https://hoodi.etherscan.io/)
##### 水龍頭
+- [Chain Platform Hoodi 水龍頭](https://faucet.chainplatform.co/faucets/ethereum-hoodi/)
- [Hoodi 水龍頭](https://hoodi.ethpandaops.io/)
+- [PoW 水龍頭](https://hoodi-faucet.pk910.de/)
+
+#### Ephemery {#ephemery}
+
+Ephemery 是一個獨特的測試網,每個月都會完全重置。 執行和共識狀態每 28 天回滾至創世區塊,這意味著在測試網上發生的任何事情都是短暫的 (ephemeral)。 這使其非常適合短期測試,快速節點引導以及不需要持久性的「hello world」類應用程式。
+
+- 不斷刷新狀態,適用於驗證者和應用程式的短期測試
+- 只包含基本的合約集合
+- 開放驗證者集合,能夠輕鬆訪問大量資金
+- 最低的節點要求和最快的同步速度,平均小於 5GB
+
+##### 資源
-要在 Hoodi 測試網上啟動驗證者,請使用 [Hoodi 啟動面板](https://hoodi.launchpad.ethereum.org/en/)。
+- [網站](https://ephemery.dev/)
+- [Github](https://github.com/ephemery-testnet/ephemery-resources)
+- [社群聊天室](https://matrix.to/#/#staker-testnet:matrix.org)
+- [Blockscout](https://explorer.ephemery.dev/)
+- [Otterscan](https://otter.bordel.wtf/)
+- [信標瀏覽器](https://beaconlight.ephemery.dev/)
+- [檢查點同步](https://checkpoint-sync.ephemery.ethpandaops.io)
+- [啟動面板](https://launchpad.ephemery.dev/)
-### 第 2 層測試網 {#layer-2-testnets}
+#### 水龍頭
-[第 2 層 (L2)](/layer-2/) 是一個統稱,用於描述一系列特定的以太坊擴容解決方案。 第 2 層是一個單獨的區塊鏈,它擴展以太坊並繼承了以太坊的安全保障。 第 2 層測試網通常與公共以太坊測試網緊密結合。
+- [Bordel 水龍頭](https://faucet.bordel.wtf/)
+- [Pk910 PoW 水龍頭](https://ephemery-faucet.pk910.de/)
+
+#### Holesky (已棄用) {#holesky}
+
+Holesky 測試網將在 2025 年 9 月棄用。 質押營運者和基礎設施提供者應該使用 Hoodi 進行驗證者測試。
+
+- [Holesky 測試網關閉公告](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) - _以太坊基金會部落格,2025 年 9 月 1 日_
+- [Holesky 與 Hoodi 測試網更新](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) - _以太坊基金會部落格,2025 年 3 月 18 日_
+
+### 二層測試網 {#layer-2-testnets}
+
+[第二層 (L2)](/layer-2/) 是個統稱,描述一組特定的以太坊擴容方案。 二層網路是獨立的區塊鏈,拓展了以太坊並繼承了以太坊的安全保證。 二層網路測試網通常與以太坊公共測試網緊密相關。
#### Arbitrum Sepolia {#arbitrum-sepolia}
-[Arbitrum](https://arbitrum.io/) 的測試網。
+[Arbitrum](https://arbitrum.io/) 的一個測試網。
+
+##### 資源
+
+- [Etherscan](https://sepolia.arbiscan.io/)
+- [Blockscout](https://sepolia-explorer.arbitrum.io/)
##### 水龍頭
-- [Chainlink 水龍頭](https://faucets.chain.link/arbitrum-sepolia)
-- [Alchemy 水龍頭](https://www.alchemy.com/faucets/arbitrum-sepolia)
+- [Alchemy Arbitrum Sepolia 水龍頭](https://www.alchemy.com/faucets/arbitrum-sepolia)
+- [Chainlink Arbitrum Sepolia 水龍頭](https://faucets.chain.link/arbitrum-sepolia)
+- [ethfaucet.com Arbitrum Sepolia 水龍頭](https://ethfaucet.com/networks/arbitrum)
+- [QuickNode Arbitrum Sepolia 水龍頭](https://faucet.quicknode.com/arbitrum/sepolia)
#### Optimistic Sepolia {#optimistic-sepolia}
-[Optimism](https://www.optimism.io/) 的測試網。
+[Optimism](https://www.optimism.io/) 的一個測試網。
+
+##### 資源
+
+- [Etherscan](https://sepolia-optimistic.etherscan.io/)
+- [Blockscout](https://optimism-sepolia.blockscout.com/)
##### 水龍頭
-- [Chainlink 水龍頭](https://faucets.chain.link/optimism-sepolia)
-- [Coinbase 錢包水龍頭 | Optimism Sepolia](https://coinbase.com/faucets/optimism-sepolia-faucet)
- [Alchemy 水龍頭](https://www.alchemy.com/faucets/optimism-sepolia)
+- [Chainlink 水龍頭](https://faucets.chain.link/optimism-sepolia)
+- [ethfaucet.com Optimism Sepolia 水龍頭](https://ethfaucet.com/networks/optimism)
+- [測試網水龍頭](https://docs.optimism.io/builders/tools/build/faucets)
#### Starknet Sepolia {#starknet-sepolia}
-[Starknet](https://www.starknet.io) 的測試網。
+[Starknet](https://www.starknet.io) 的一個測試網。
+
+##### 資源
+
+- [Starkscan](https://sepolia.starkscan.co/)
##### 水龍頭
- [Alchemy 水龍頭](https://www.alchemy.com/faucets/starknet-sepolia)
+- [Blast Starknet Sepolia 水龍頭](https://blastapi.io/faucets/starknet-sepolia-eth)
+- [Starknet 水龍頭](https://starknet-faucet.vercel.app/)
-## 私人網路 {#private-networks}
+## 私有網路 {#private-networks}
-若節點未連接到公共網路 (即主網或測試網),則以太坊網路就是一個 私人網路。 在此情況下,私人僅表示保留或隔離,而非受保護或安全。
+如果一個以太坊網路的節點未連線至公共網路 (即主網或測試網),則該網路為私有網路。 在此情況下,私人僅表示保留或隔離,而非受保護或安全。
-### 發展網路 {#development-networks}
+### 開發網路 {#development-networks}
開發以太坊應用程式時,最好在部署前先在私人網路上執行,瞭解其運作情況。 類似於進行網頁開發時,在自己的電腦上建立本機伺服器,你可以建立本機區塊鏈實例來測試你的去中心化應用程式。 與公共測試網相比,這可以大幅提升迭代速度。
-有些專門輔助專案和工具可以使用。 深入瞭解[開發網路](/developers/docs/development-networks/)的資訊。
+有些專門輔助專案和工具可以使用。 深入了解[開發網路](/developers/docs/development-networks/)。
### 聯盟網路 {#consortium-networks}
@@ -124,12 +182,35 @@ Hoodi 是為測試驗證和質押而設計的測試網。 Hoodi 網路對於希
如果說公共以太坊網路是公共網際網路,那麼聯盟網路就是私有內部網路。
+## 為何以太坊測試網會以地鐵站命名? {#why-naming}
+
+許多以太坊測試網都以真實世界的地鐵站或火車站命名。 這個命名傳統很早就開始了,它反映了貢獻者曾經生活或工作過的全球城市。 它既具象徵意義、好記,又很實用。 就像測試網獨立於以太坊主網一樣,地鐵線路也與地面交通分開運行。
+
+### 常用與舊版測試網 {#common-and-legacy-testnets}
+
+- **Sepolia** - 希臘雅典一個有地鐵相連的社區。 目前用於智慧合約和去中心化應用程式的測試。
+- **Hoodi** - 以印度班加羅爾的 Hoodi 地鐵站命名。 用於驗證程式與協定升級測試。
+- **Goerli** _(已棄用)_ - 以德國柏林的 Görlitzer Bahnhof 站命名。
+- **Rinkeby** _(已棄用)_ - 以斯德哥爾摩一個有地鐵站的郊區命名。
+- **Ropsten** _(已棄用)_ - 指斯德哥爾摩的一個地區及過去的渡輪/地鐵總站。
+- **Kovan** _(已棄用)_ - 以新加坡的一個地鐵站命名。
+- **Morden** _(已棄用)_ - 以倫敦的一個地鐵站命名。 以太坊的第一個公共測試網。
+
+### 其他專用測試網 {#other-testnets}
+
+有些測試網是為短期或特定升級測試而建立,不一定以地鐵為主題:
+
+- **Holesky** _(已棄用)_ - 以布拉格的 Holešovice 站命名。 用於驗證程式測試;於 2025 年棄用。
+- **Kiln**、**Zhejiang**、**Shandong**、**Prater**、**Pyrmont**、**Olympic** _(皆已棄用)_ 與 **Ephemery** - 為合併、上海升級等升級模擬,或驗證程式實驗而專門打造。 有些名稱是地域性或主題性的,而非以地鐵為基礎。
+
+使用地鐵站名有助於開發者快速識別及記住測試網,而無需依賴數字鏈 ID。 這也反映了以太坊的文化:實用、全球化與以人為本。
+
## 相關工具 {#related-tools}
-- [Chainlist](https://chainlist.org/) _是將錢包與提供者連結到適當鏈 ID 與網路 ID 的以太坊虛擬機網路的清單_
-- [採用以太坊虛擬機 (EVM) 的鏈](https://github.com/ethereum-lists/chains) _Github 鏈中繼資料存放庫,支援 Chainlist_
+- [Chainlist](https://chainlist.org/) _以太坊虛擬機網路清單,用於將錢包和提供者連接到對應的鏈 ID 和網路 ID_
+- [基於 EVM 的鏈](https://github.com/ethereum-lists/chains) _為 Chainlist 提供支援的鏈元資料 GitHub 存放庫_
-## 衍生閱讀 {#further-reading}
+## 延伸閱讀 {#further-reading}
- [提案:可預測的以太坊測試網生命週期](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17)
-- [以太坊測試網的演進](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)
+- [以太坊測試網的演變](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)