譯者：灑脫喜
注：原文作者是以太坊2.0協調員Danny Ryan（djrtwo），在這篇文章中，他詳細介紹了以太坊1.0將如何與以太坊2.0合併，根據他的介紹，在eth2+eth2組合客戶端中，eth2客戶端可以處理PoS和分片共識的複雜性，而附屬eth2客戶端可以成為一個eth2引擎，它可以處理狀態、交易、虛擬機器等事物的複雜性。
以太坊1.0和以太坊2.0客戶端的關係
自從Vitalik在2019年12月提出一個早期eth2 <-> eth2 合併替代方案之後，研究人員一直在進行積極討論，以從軟體的角度來考慮這種合併的可能形式，而對於原型設計的期望，也是愈發變得更強。我們的願景是建立一個混合體，其中核心共識工作是由以太坊2.0客戶端（以下簡稱eth2客戶端）管理，而狀態/區塊則由一個以太坊1.0引擎（以下簡稱eth2引擎）管理，而它們一起構成了eth2+eth2組合客戶端。
本文旨在更明確地區分eth2客戶端和附屬eth2引擎之間的職責，以便為會話、規範編寫及原型提供更好的基礎。注意，文章並不會定義協議的具體細節（例如eth2 客戶端呼叫eth2引擎的精確方法），並且文中包含的任何示例，都只是用於幫助描述及後續討論。
而要理解本文的內容，前提條件是需要你基本熟悉以太坊2.0以及無狀態以太坊的概念。
分工明確
eth2+eth2的合併目的，是在升級的以太坊2.0共識環境中利用現有以太坊1.0的狀態、生態系統以及軟體。
概括地說，我們今天所認為的eth2客戶端會處理核心PoS以及分片共識。本質上，eth2協議及eth2客戶端被設計成非常擅於在一堆“東西”上產生及達成共識，而這些東西，就是很多充滿資料和（最終）狀態的分片鏈。與當今eth2的PoW共識層相比，eth2的“共識層”要先進的多，同時也複雜的多。
今天，eth2客戶端具有相對簡單且較薄的共識層，它只有一條鏈，並且PoW可處理協議外硬體中的大部分複雜性。eth2客戶端的大多數複雜性及最佳化，都位於使用者層（包括狀態儲存/管理、狀態同步、虛擬機器執行、交易處理、交易池等）。
當eth2作為一個分片被納入eth2時，這種關注點分離就可實現很好的配對，eth2客戶端可以處理PoS和分片共識的複雜性，而附屬eth2客戶端可以成為eth2引擎，它可以處理狀態、交易、虛擬機器以及更接近使用者層事物的複雜性。
最小的改變，實現本地通訊
如何將eth2和eth2客戶端軟體組合在一起，有很多可能的途徑（比如完全合併、將eth2作為庫匯入、透過兩者之間的通訊協議等），但在本文當中，我們會重點介紹一個最具微創性和和模組化的方法 —— 一種eth2客戶端與簡化eth2引擎之間的本地通訊協議。
考慮到eth2和eth2客戶端實現的多樣性，這種方法可以防止客戶端軟體在任一側鎖定，允許客戶端團隊保持獨立，並專注於他們自己的研發工作，使軟體專案在很大程度上保持穩定，以便進行快速原型製作。
那它會是什麼樣子的呢？
大致上，一個eth2+eth2組合客戶端會是下面這個樣子的：
其中eth2引擎和eth2引擎一起執行，透過eth2客戶端驅動的RPC進行本地通訊。
兩者都會維護自己的p2p介面，連線到對等方並處理與每個特定域相關的網路協議。
以太坊2.0客戶端
- 信標鏈和信標狀態 （構建系統其餘部分的核心共識物件）；
- 分片鏈（1、eth2分片鏈，2、很多僅限資料的分片鏈）；
- Mempool操作[未顯示]（證明（Attestation）、存款（deposit）、退出出口（ exit）等）
- P2P介面（1、共識層資訊，2、包括eth2分片區塊gossip）；
- RPC到eth2引擎 （所有呼叫都由eth2客戶端驅動）；
以太坊1.0引擎
- EVM虛擬機器（eth2分片區塊的執行與驗證）；
- eth2狀態（今天以太坊中的使用者層eth2狀態）；
- 交易儲存池Mempool（使用者交易mempool，為區塊生產做準備）；
- P2P介面（1、今天以太坊上的交易gossip，2、狀態同步，3、沒有eth2分片區塊gossip）；
- 來自eth2客戶端的RPC （所有呼叫都由eth2客戶端驅動）；
共識
從核心共識的角度來看，eth2客戶端負責並推動信標鏈、資料分片鏈以及eth2分片鏈的構建。eth2客戶端透過RPC直接提供有關eth2引擎關於eth2分片鏈和核心共識（信標鏈/狀態）的任何知識。
具體來說，附加的eth2引擎必須能夠訪問eth2客戶端，因為它不能維護自己的共識。在今天以太坊的PoW中，eth2客戶端檢查工作量證明，形成一個樹狀結構，並執行分叉選擇規則來查詢鏈的頂端。在eth2中，這些機制要大不相同，這需要對eth2的核心共識有深入的瞭解。eth2客戶端提供有關eth2分片鏈頭部（head）的最新資訊，以便eth2引擎可以維護eth2狀態的準確檢視。
由於eth2引擎完全依賴eth2客戶端推動共識，因此我們提議eth2客戶端與eth2引擎之間的通訊，都是eth2客戶端呼叫的eth2引擎上的所有方法（例如addBlock， getBlockProposal等）。這將強制執行一個leader/follower關係，以降低系統推理的複雜性，並限制eth2引擎所需的業務邏輯。
從eth2客戶端和核心共識的角度來看，eth2分片鏈的處理，幾乎與所有其他分片鏈（分叉選擇、交聯、區塊結構、簽名等）完全相同。主要區別在於，可以針對eth2引擎執行分片區塊內容，因此eth2分片區塊資料的格式必須與eth2相關，並且必須針對此成功執行進行額外的驗證。
狀態
eth2有一種與核心共識相關的狀態，這就是所謂的“信標狀態”（beacon-state）。信標狀態資料很小（大約只有10-40MB，取決於驗證者集的大小），它包含了理解核心共識及如何處理分片鏈所需的所有資訊。事實上，要處理分片鏈中與共識相關的部分，客戶端必須能夠訪問信標狀態（例如，執行分片鏈分叉選擇的最新交聯crosslink、驗證分片鏈簽名的當前驗證集或shuffling隨機分配）。
eth2的狀態不會一直和使用者層狀態互動，其互動最多的是分片鏈資料的可用性。實際的使用者層資料根位於該分片鏈資料中，對於eth2分片鏈，則為當前以太坊使用者狀態根。
下面討論了和eth2客戶端相關的eth2狀態的不同情況：
1、沒有eth2引擎的eth2客戶端
核心eth2協議可以在沒有附加eth2引擎的情況下執行。單獨的eth2客戶端可以遵循信標鏈和分片鏈（包括eth2分片）。而沒有eth2引擎，客戶端將無法執行無狀態eth2分片區塊，因此無法完全驗證它們或從中獲取任何有用的使用者資訊。不過，根據對eth2核心共識和驗證者的假設，eth2分片鏈的頭部（head）仍然可以安全地找到。
2、帶無狀態eth2引擎的eth2客戶端
要執行一個驗證者節點，必須使用附加的eth2引擎執行eth2客戶端。這可以透過無狀態的方式完成（即不在本地儲存整個eth2狀態），因此eth2分片區塊具有可用於執行的驗證資料（witness）。信標委員會可以透過對eth2引擎進行無狀態呼叫，來檢查分片區塊資料的可用性及關於eth2的資料有效性。
除了驗證者外，很多使用者/應用程式節點也可能使用無狀態或半狀態的eth2引擎執行。使用瘦eth2客戶端，來跟隨eth2分片鏈的頭部，並以無狀態或半無狀態的方式與其互動。
3、帶有狀態eth2引擎的eth2客戶端
要執行可產生eth2 分片區塊的驗證者，必須使用附加的eth2引擎和完整的eth2狀態執行eth2協議（研發者們正在探索無狀態的區塊產生方法，但為簡單起見，我們不對其進行討論）。然後，可以使用本地狀態和交易儲存池（TX mempool）按需形成新的有效區塊（在下文中有更多討論）。
除驗證者外，很多使用者/應用程式節點也可能使用完全有狀態的eth2引擎執行，例如區塊瀏覽器、存檔節點、狀態提供者等。
網路
為簡單起見，eth2和eth2最初會維護它們各自獨立的網路堆疊和協議。為了響應責任轉移（例如eth2分片區塊gossip），開發者已不贊成使用某些現有的eth2協議（例如eth2分片區塊gossip），取而代之的是eth2協議。在初始原型設計階段之後，或者在更進一步的階段，可能需要將eth2協議遷移到libp2p以統一網路堆疊，但這不是必須的。
eth2客戶端和eth2引擎可以訪問相同的discv5 DHT，但是可獨立地找到具有適當功能的對等節點並獨立地維護連線。
ENR
eth2+eth2組合客戶端會使用一個ENR，因為節點位於具有多個功能的邏輯網路標識之後。
eth2功能（狀態、交易等）由ENR中的現有eth（或新eth2）key表示。
eth2功能（核心共識）在ENR中用eth2 key表示。
每種協議的存在，都意味著節點能夠且願意識別底層網路協議的類別。
Wire協議
1、eth2協議
1、eth2請求/響應（1、狀態，2、信標區塊同步，3、分片區塊同步）； 2、核心共識gossip（1、Beacon區塊，2、證明，3、分片區塊，包括eth2分片， 4、其它驗證者操作）；
2、eth2協議
1、eth2 wire協議的子集 （1、交易gossip，2、同步方法，例如getnodedata或新方法， 3、獲取收據receipt）
2、NOT（與區塊雜湊、區塊頭或體相關的訊息）；
3、為什麼eth2客戶端會處理eth2區塊gossip ?
eth2專門用於處理分片區塊的生產、gossip以及驗證。我們的目標是讓eth2分片成為標準分片，並儘可能與其餘分片保持一致。關於核心共識，與其他分片相比，eth2區塊的主要區別在於針對eth2引擎執行/驗證區塊內容的能力，
當驗證者正在將eth2分片區塊叉聯到信標鏈時，eth2客戶端將再次呼叫eth2引擎來執行和驗證該區塊。
當有狀態的eth2 + eth2組合節點收到新的eth2分片區塊時，eth2客戶端將再次呼叫eth2引擎，以驗證該區塊並更新本地狀態儲存。
交易gossip和儲存池mempool
eth2引擎幾乎會以當前以太坊相同的方式，維護使用者交易gossip以及eth2交易儲存池。同樣的網路協議和本地機制，可以用於gossip及儲存池的維護，為區塊的生產做好準備。
主要的區別在於如何確定已用交易的知識，以及如何將儲存池用於區塊生產，但這些可以說是位於儲存池外部的一個層中。
eth2分片區塊是從附屬eth2客戶端提供給eth2引擎的。包含在這些區塊中的交易，應該以類似於當前以太坊主網PoW區塊的方式從儲存池中清除。
eth2分片區塊是根據附屬eth2客戶端，透過儲存池mempool的內容生成的。此RPC方法和基礎功能類似於getWork，但將返回完整的區塊內容，而不僅僅是一個雜湊值。
區塊生產
在eth2協議中，所有區塊（信標區塊、分片區塊、eth2分片區塊）必須由PoS驗證者根據核心共識進行生產及簽名。為此，eth2客戶端最終要負責所有區塊的生產。
對於信標區塊和非eth2分片區塊，eth2客戶端具有生成有效區塊所需的一切。
對於eth2分片區塊，eth2客戶端立即/隨時訪問eth2狀態、交易和其它底層eth2結構，以生成有效區塊。相反，當指定驗證者生成eth2區塊時，eth2客戶端從eth2引擎請求一個可行的eth2區塊資料（TX、狀態根等）。然後，eth2客戶端將此eth2區塊資料打包到完整的分片區塊中（新增slot、positer_index、positer_signature等），並將該區塊廣播至網路。
eth2引擎之所以能夠生成有效/可行的eth2區塊資料，是因為它採用了今天以太坊主網所使用的相同方式來管理eth2交易儲存池，並且它透過eth2客戶端的更新來維護eth2頭狀態的最新資訊。
下一步該怎麼走？
如果這一總體設計被大家認同，那接下來的步驟包括：
- 確保有關eth2客戶端驅動eth2引擎的假設與現有eth2軟體一致，並且不會給現有eth2軟體帶來意外的負擔；
- 更明確地定義用於驅動eth2引擎的通訊協議，例如
new_head(block)、validate_block_transition(block)、get_proposal(parent_root)等； - 定義網路元件，例如需要eth2協議的哪一個子集，如何具體使用ENR；
- 擴充套件以太坊2.0 階段1 規範
- 原型！
本文經作者Danny Ryan授權翻譯。
