數據

Header（區塊頭）

即以太坊協議所定義的 Header 對象。 （譯者註：區塊頭包含一個區塊的元信息）

Block（區塊）

一個區塊由兩部分數據組成：

區塊頭Block Body（區塊體）；區塊體又由兩部分內容組成：Transactions（交易，事務）Uncles（叔塊信息）

Block Body（區塊體）

就是一個區塊中的事務和叔塊信息的集合。

事務

即以太坊協議所定義的 Transaction 對象。 （譯者註：事務可視為觸發以太坊協議狀態變更的操作的基本單元）

事務的構建

創建一條完全簽名的事務的過程：

必須知道發起事務的Account（賬戶）的 nonce（流水號）。一般來說需要使用 eth_estimateGas 方法來確定該事務需要使用的 gas 消耗量。需要該賬戶的私鑰，用於生成數字簽名。

叔塊信息

即被該區塊視作叔塊的區塊的區塊頭。 （譯者註：對於任一區塊來說，叔塊指的是那些上溯7 代及以內、並非其祖先區塊的有效區塊；一個區塊可標記兩個叔塊；標記叔塊可使區塊挖出者獲得額外的“侄塊獎勵”，也會使叔塊挖出者獲得獎勵，獎勵大小隨叔塊與侄塊之間的代際距離遞減；叔塊內的所有事務視作沒有上鍊，除非另一些區塊中包含了這些事務，否則都回到待打包事務的內存池中）

區塊鏈歷史

Header Chain（全部區塊頭）

所有歷史區塊的區塊頭的集合

截至2021 年1 月29 日，約有1100 萬個區塊頭截至2021 年1 月29 日，全體區塊頭約佔用5 GB 的存儲空間是驗證其餘大部分鏈數據所必需的數據如果使用Header Accumulator（區塊頭累加器），我們將能證明某個區塊頭存在於主鏈上

Block Body History（區塊體歷史）

所有由事務和叔塊信息所組成的歷史區塊的集合

截至2021 年1 月29 日，約有1100 萬個區塊體截至2021 年1 月29 日，所有區塊體需佔用約120 GB 的存儲空間

Receipt History（收據歷史）

由歷史事務所產生的所有收據的集合

截至2021 年1 月29 日，約有10 億條收據截至2021 年1 月29 日，所有收據需佔用約60 GB 存儲

State（狀態）

所有賬戶及contract storage（合約存儲項）的集合

賬戶

由 Header.state_root 所代表的主狀態樹的一部分

字段：balance/nonce/state_root/code_hash

合約存儲項

每個賬戶的 Account.state_root 標識的單個存儲值

所有數據都以 0 - 2^^256-1 範圍內的整數作為鍵（該整數也被當作存儲槽的序號）

Contract Code（合約代碼）

合約代碼僅使用 Account.code_hash 來指代；並非狀態的顯式部分。

Archive State（歸檔狀態）

所有歷史狀態的集合。詳見Archive Node（歸檔節點）

使用Naive Database Layout，存儲歸檔狀態需佔用約7 TB 的存儲使用一些基於Flat Database Layout 的高級技巧，Trube Geth 客戶端使用約800 GB 實現了歸檔狀態存儲

Recent State（近期狀態）

指作為 近期 狀態根一部分的狀態。

“近期” 一般來說是128～256 個區塊內

維護這一數據需要某種形式的垃圾回收技術，以清除不再是近期狀態一部分的狀態對象

Cold State（冷狀態）

指的是很長一段時間沒有被觸及（訪問及修改）的狀態對象

Database Layouts（數據庫佈局）

Naive Database Layout

該數據庫實現將所有的狀態對像都存儲為單個的樹節點，通過節點哈希值來訪問

導致性能低下以及高硬盤讀寫開銷相對易於理解和實現此方案下的垃圾回收算法更加複雜

Flat Database Layout

將所有的狀態對像都存儲為樹的路徑，某種程度上有點類似於鍵值對存儲

性能更高、硬盤開銷更小更難以理解和實現

Witness（見證數據）

即以一種可驗證的形式存儲的狀態數據

Block Witness（區塊見證數據）

一種類型的見證數據，提供了執行區塊所需的所有狀態數據

Transaction Witness（事務見證數據）

一種類型的見證數據，提供了一筆事務的EVM 執行所需的所有狀態數據

Node Type（節點類型）

Full Node（全節點）

指一個滿足了下列要求的節點：

存儲了所有的區塊頭存儲了全部區塊體歷史存儲了全部收據歷史存儲著近期狀態維護者一個主鏈區塊索引系統維護者一個主鏈事務索引系統參與ETH DevP2P 協議（譯者註：該協議用於在以太坊網絡的對等節點之間傳輸數據，如區塊、事務、狀態數據等；以太坊交易的廣播就是靠這個協議實現的）

Archive Node（歸檔節點）

其他特點與全節點都一樣，但歸檔節點會存儲全部歸檔狀態。一般都需要執行Full Sync（全量同步）。

LES Light Node（LES 輕節點）

連接到 LES DevP2P 協議的客戶端，意圖是跟上區塊鏈並暴露JSON-RPC API。

此類客戶端依賴於鏈接到至少一個LES Server（LES 服務器）來滿足對數據的需求。

Stateless Node（無狀態節點）

一個仍在計劃中的客戶端類型，如果能夠實現區塊見證數據的話，就可使之成真。

此類客戶端不需要狀態數據來執行區塊，因為它們可以使用見證數據

（TODO：還需增加對其他功能所需技術的描述）

Ultra Light Node（極輕節點）

增加這個術語只是為了區分當前類型的輕節點和一種新類型的輕節點—— Piper

一種僅暴露JSO-RPC API 的節點。

P2P 協議

ETH DevP2P 協議

DevP2P 網絡中所用的點對點協議，是所有主網客戶端的基石

作為這個點對點網絡中的一部分，一個節點需要：

參與Transaction Gossip（事務廣播）參與Block Gossip（區塊廣播）擁有近期狀態擁有完整的區塊鏈歷史

LES DevP2P 協議

作為輕客戶端基礎的DevP2P 網絡所用的點對點協議

LES 服務器

參與LES 網絡、向LES 客戶端提供數據的節點。

在這個網絡中成為一個服務器需要：

完整的近期狀態全部區塊鏈歷史主鏈區塊索引/事務索引有能力參與事務廣播有能力參與區塊廣播

LES 客戶端

參與LES 網絡、向LES 服務器請求數據的節點。



原文鏈接:https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary

作者: Piper Merriam

翻譯: 阿劍