研究：以太坊2.0中的狀態提供者模型
編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自
以太坊愛好者（ID：ethfans）
簡介
編者按：本文來自
以太坊愛好者（ID：ethfans）
簡介
編者按：本文來自
以太坊愛好者（ID：ethfans）
簡介
本文乃與samwilsn 及adietrichs 聯合撰寫而成，亦得到villanuevawill 和Quilt 團隊的莫大幫助。
簡介
不管區塊提議者和狀態提供者是如何交換狀態的，用戶都可能需要在創建交易之前獲取狀態。比如通過獲取合約的字節碼，估計Gas 的花銷或者檢查賬戶的餘額。這意味著狀態提供者需要為用戶暴露一個類似拉取數據功能（pull-like）的接口。儘管沒有激勵層，只依賴無私的狀態提供者也可以為用戶提供狀態（以太坊1.0 就是這樣做的），也可以通過狀態通道來實現支付，給狀態提供者添加一個激勵層。
二級標題
狀態訪問限制
二級標題
如果某個模式限制了動態狀態訪問，那麼Eth1 很有可能無法成為Eth2 執行環境（EE），而且將經常需要特殊的處理。
二級標題
二級標題
對狀態提供者的報酬從下面兩方面對比：
二級標題
一開始是否支持無私狀態提供者，如果是這樣，激勵措施可以之後再加嗎？二級標題
每個模式的中心化風險都有所不同：
二級標題
區塊提議者和狀態生產者之間要達到怎樣的互信程度？
二級標題
模式
二級標題
直推模式（Direct Push Model）
Eth1 中，一旦某個給定交易的簽名驗證以及餘額和nonce 的檢查完成，礦工就可以確信他們會得到打包交易的手續費。 Eth2 中， 區塊提議者是否可以得到支付依賴於丟失狀態是否是可歸因的錯誤（attributable fault）。如果是的話，就算某筆交易是因為狀態丟失而失敗，區塊提議者也依然可以得到支付。否則，丟失狀態的交易本身是不可打包的，但區塊提議者可能在執行完所有（一般很長）的交易後才可能發現。 （譯者註：這裡的支付指區塊提議者要收取打包交易中的交易費，如果是不可歸因的錯誤，那麼區塊提議者花費成本去打包了交易，卻得不到交易中的交易費。）
二級標題
如果區塊提議者又要運行交易才能發現錯誤，但這些交易又是不可打包的（即不能支付手續費的），那區塊提議者就很容易受到成本幾乎為零的拒絕服務式攻擊。
模式
二級標題
直推模式（Direct Push Model）
狀態訪問限制
激勵
創建交易的用戶實質上成了這筆交易唯一的狀態提供方。一般來說，沒有辦法確保用戶所提供的狀態能滿足日後交易上鍊時的所有訪問需要。因此，在Direct Push 模式下，只有狀態訪問可預測的交易才能得到執行。因為交易只能使用靜態狀態訪問，合約創建者也應該設計他們的合約，得到可預測的狀態訪問：可以使用諸如可訪問列表（ access lists）的註釋，詳細說明合約在運行期間可以訪問的位置。這種方案與避免動態狀態訪問的模式(可參見Vitalik 在Eth1.x 版塊提出的這篇相關博文）相結合，產生的新模式應該仍能提供足夠的的功能性。
不過，這將會與當前的Eth1 系統大相徑庭。可能會使Eth1 轉換到Eth2 的計劃泡湯。
激勵
這個模式只依賴於一般的狀態提供者網絡。正如上面所說的，似乎沒有激勵系統也可行。
激勵制度也可以通過支付通道來添加。假定每個用戶都必須與一個或多個狀態提供者建立一個支付通道，這種方法應該會特別複雜。
中心化風險
因為狀態提供者可以僅保留一部分狀態，因此硬件要求可以按需降低。
金錢激勵可能會促使一些狀態提供者中心化，因此用戶通過支付通道購買狀態時，需要信任對手。
沒有時間約束。
二級標題
丟失狀態的可歸因性
關鍵點
二級標題
主要優勢：簡單。不需專業的狀態提供者或激勵系統。沒有特別的時間約束。
主要缺點：只適用於事先知道所有狀態訪問需要的交易。這限制了整個系統的功能。儘管可以用一些緩解措施，但兼容性問題無法解決。特別地， 這種模型下，Eth1 無法成為Eth2 的運行環境。
二級標題
中繼推送模式（Relayed Push Model）
相應地，系統在交易包池中的交易包被證明用不了的情況下，仍然可以運行。中繼者只宣告交易包的存在。區塊提議者會直接聯繫中繼者，得到交易包並包含進新的區塊。
激勵
狀態訪問限制
沒有限制。只要中繼者每個時隙（slot）都能向交易包推送狀態，確保狀態訪問的需要能得到滿足，就可以了。此外，每個新區塊只包含一個數據包，可以防止交易包間的干擾。
激勵
給中繼者設計激勵機制其實挺複雜的，因為狀態和見證信息一旦公開，用戶和/或BPs 就有機會繞過見證者，自己重新創建交易包。
兩個可能的解決方案：
沒有交易池的情況下，交易包是不公開的。中繼者向區塊提議者售賣附加了狀態的交易包（費用比交易費低一點），從而形成交易包市場。對區塊提議者來說存在一些風險：某筆交易可能已經被包含在另一個區塊中了，成了無效交易；或者收到的交易費比中繼者售賣時宣告的要少。
另一種方法是，不論有沒有交易池，交易可以包含給某個特定中繼者的支付。用戶承諾一段排他期（即幾個時隙），這段時間內，用戶不會創建其他交易。如果用戶在排他期同時簽署兩個或多個交易時，就要遭到懲罰。為此，EE 必須提供“罰沒” 用戶的方法。但因為用戶沒有鎖定保證金，那麼尚不清楚如何罰沒沒有足夠賬戶餘額的用戶。
中心化風險
中心化風險依賴於使用何種中繼者激勵機制：
假定合併交易包是複雜的（因為動態狀態訪問），交易包市場會導致高中心化，並且允許單獨的中繼者審查交易。因為上面列出的BPs 可能遭受的風險，BPs 更傾向於與知名且信任的中繼者合作。個人用戶與這些知名的中繼者相比，是無法提供有足夠高交易費的交易包的。
使用排他期以及交易包池會提供高程度的去中心化，但是以用戶的便利性和一個更加複雜的交易池實現為代價。理論上來講，任何用戶都可以從交易池中檢索到交易包，添加自己的交易去擴充交易包，然後以更高的交易費用中繼交易包。
時間約束
丟失狀態的可歸因性
狀態丟失可歸因於中繼者。區塊提議者可要求中繼者（或是中繼者自願選擇）為某一筆交易附加“退款交易”，用於在交易因狀態丟失而敗時向區塊提議者退款。
缺點：
二級標題
拉取模式（Pull Model）
沒有交易池的情況下，交易包不能被組合起來，那麼一個區塊就只能包含單個中繼者提出的交易包。中繼者可能會中心化並引入審查。
二級標題
就算有交易池，交易包組合功能是否足以完全緩解審查問題依舊是不明朗的。
激勵系統很複雜。
二級標題
拉取模式（Pull Model）
用戶向網絡發送交易，節點維護待處理交易池。創建區塊前，區塊提議者從交易池中選出部分待處理交易，組成交易包並發送給某個狀態提供者，請求這個交易包的狀態。接收到狀態後，由區塊提供者將交易包打包進新的區塊。
在狀態提供者提供所有狀態以前，為了讓中間節點和區塊提議者能夠驗證交易的有效性，用戶必須在交易上附加驗證簽名和手續費支付能力所需的見證消息。因此這一部分在不同的執行環境（EE）中必須是標準化的，所有EE 都必須提供一個最簡單驗證函數選項。
或者可以使用一個Value-Holding EE (VHEE)。每筆交易都使用這個VHEE 來支付費用。網絡中的節點會理解VHEE， 從而可以驗證交易有效性。
在這兩種情況下，網絡中的節點都需要在新區塊到達時更新附加狀態的見證信息。
狀態訪問限制
激勵
對主要交易沒有限制。區塊提議者只有在創建區塊時才會聯繫狀態提供者，確保返回的狀態是最新的。更重要的是，通過把交易捆綁在一起並以交易包為單位請求狀態，狀態被附加在準確的上下文中。這種做法保證了所提供的狀態總是充分的。這就包含了與Direct Push 模式很關鍵的一個差異，Direct Push 模式中，狀態是在交易捆綁之前被附加進去的，從而造成了狀態訪問的限制。
因為用戶必須包含驗證簽名和手續費支付能力的狀態，因此從技術上來說，交易部分的限制和Direct Push 模型中列出的相同。然而這些限制在實際中是無關緊要的。因為Eth1 中，簽名驗證和費用支付是可預測的狀態訪問，因此Eth1 和Eth2 之間的兼容性不會被破壞。此外，對VHEE 來說，它的設計將確保可預測的狀態訪問，從而沒有必要做進一步的限制。
激勵
區塊提議者可通過支付通道或其他方式為狀態提供者提供的狀態付費。根據BP 和對手SP 的信任程度，可以按交易筆數來支付費用（這是信任最小化的），也可以按交易包來支付費用（這樣效率更高）
中心化風險
狀態提供者必須保存所有的狀態，存儲量要求很大。預計狀態提供者還要快速執行交易包，因此對計算能力也有要求。
區塊提議者可能更傾向於向其信任的狀態提供者群體獲取狀態，減少惡意破壞的風險，從而增加了中心化程度。
然而，單獨一個狀態提供者無法審查交易，因為負責創建並對交易包排序的是區塊提議者。某個狀態提供者可能會隱藏某個交易包需要的狀態，但是這樣做會損害他們的信譽，而區塊提議者可以很容易地用另一個狀態提供者重試。
時間約束
區塊提議者必須在一個時隙內聯繫上一個能為TA 提供待上鍊交易包所需狀態的狀態提供者。
丟失狀態的可歸因性
狀態提供者始終要為所提供的狀態負責。區塊提議者不可以將狀態不充分的交易打包進區塊，而且只有在驗證了狀態充分後，才會支付。
關鍵點
優點：
沒有相關的狀態訪問限制。
時間約束問題較少。
沒有顯著的中心化風險。儘管可以預計到，某一些狀態提供者將專門為區塊提議者提供狀態，但沒有某個狀態提供者可以顯著地干預整個過程的進行。一個狀態提供者可以做的最壞的事情就是在被請求時不提供狀態。
主要的缺點：必須對簽名驗證做一些標準化，或者通過驗證腳本，或者使用VHEE。
延伸討論
自力更生式見證信息& Gas 花銷
如果交易發起者可以提供足夠的見證信息來保證他們的餘額，那麼狀態訪問能便宜一點嗎？如果見證信息也放在交易中、經過簽名，其確定性是可以保證的，但是會增加複雜性。
