直推、中繼推送與拉取三種狀態提供者模型在訪問狀態、激勵措施、中心化風險等方面有何異同?

推薦閱讀:《鏈聞精選好文|重新認識最強公鏈以太坊

原文標題:《乾貨 | 研究以太坊 2.0 中的狀態提供者模型》
撰文:adietrichs、samwilsn
翻譯 & 校對:裴奇 & 阿劍

本文乃與 samwilsn 及 adietrichs 聯合撰寫而成,亦得到 villanuevawill 和 Quilt 團隊的莫大幫助。

以太坊 2.0 的無狀態性意味着交易必須攜帶自己要訪問的狀態。更準確地說,對於區塊提議者(BP),除了包含交易,區塊還需要包含所有交易訪問的所有狀態和對應的見證信息。假定創建交易的用戶和 BP 都未存儲狀態數據,那麼,網絡就需要另一個羣體來保存並提供這些狀態。這種角色通常被稱作狀態提供者(SP)

不管區塊提議者和狀態提供者是如何交換狀態的,用戶都可能需要在創建交易之前獲取狀態。比如通過獲取合約的字節碼,估計 Gas 的花銷或者檢查賬戶的餘額。這意味着狀態提供者需要爲用戶暴露一個類似拉取數據功能(pull-like)的接口。儘管沒有激勵層,只依賴無私的狀態提供者也可以爲用戶提供狀態(以太坊 1.0 就是這樣做的),也可以通過狀態通道來實現支付,給狀態提供者添加一個激勵層。

比較準則

關於如何將狀態提供者集成到整個系統中,人們已經提出了多種想法。在下面的章節中,我們將扼要地介紹幾種方案。除了概括性的描述,我們還會對比下面的幾個性質:

狀態訪問限制

因爲交易的執行基於執行時的狀態,所以,如果底層的狀態變化了,交易的執行也會跟着變化。特別地,對一些交易來說,其狀態訪問的位置可能會變化。這可能是因爲簡單的跳轉語句(比如 if),或者所訪問的位置是在運行時計算的。我們將兩種情況稱作動態狀態訪問(DSA)。在無狀態模式下,這會讓交易創建過程變得複雜。問題在於可能無法提前爲這些交易提供狀態(因爲無法提前知道這些交易會訪問哪些全局狀態)。不同的狀態提供者模式在支持這些交易的程度上表現不同。

如果某個模式限制了動態狀態訪問,那麼Eth1 很有可能無法成爲 Eth2 執行環境(EE),而且將經常需要特殊的處理。

激勵措施

對狀態提供者的報酬從下面兩方面對比:

  • 誰支付報酬以及報酬是如何計算的?
  • 一開始是否支持無私狀態提供者,如果是這樣,激勵措施可以之後再加嗎?

中心化風險

每個模式的中心化風險都有所不同:

  • 誰可以審查交易,可以審查到什麼程度?
  • 一個狀態提供者可以存儲多少狀態?需要什麼樣的硬件?
  • 區塊提議者和狀態生產者之間要達到怎樣的互信程度?

時間約束

區塊生產者廣播區塊的時間是固定的。因此我們會專門考慮不同模式在該時間限制下的表現。

丟失狀態的可歸因性

Eth1 中,一旦某個給定交易的簽名驗證以及餘額和 nonce 的檢查完成,礦工就可以確信他們會得到打包交易的手續費。Eth2 中, 區塊提議者是否可以得到支付依賴於丟失狀態是否是可歸因的錯誤(attributable fault)。如果是的話,就算某筆交易是因爲狀態丟失而失敗,區塊提議者也依然可以得到支付。否則,丟失狀態的交易本身是不可打包的,但區塊提議者可能在執行完所有(一般很長)的交易後纔可能發現。(譯者注:這裏的支付指區塊提議者要收取打包交易中的交易費,如果是不可歸因的錯誤,那麼區塊提議者花費成本去打包了交易,卻得不到交易中的交易費。)

如果區塊提議者又要運行交易才能發現錯誤,但這些交易又是不可打包的(即不能支付手續費的),那區塊提議者就很容易受到成本幾乎爲零的拒絕服務式攻擊。

模式

乾貨 | 研究以太坊 2.0 中的狀態提供者模型

直推模式(Direct Push Model)

乾貨 | 研究以太坊 2.0 中的狀態提供者模型

用戶直接從一個或多個狀態提供者處請求必要的狀態,然後將帶有狀態的交易發往網絡。節點維護待處理的交易池,每當網絡產生新區塊就更新見證信息。區塊提議者創建區塊時, 從交易池中選擇待打包交易子集,包含進新的區塊。

狀態訪問限制

創建交易的用戶實質上成了這筆交易唯一的狀態提供方。一般來說,沒有辦法確保用戶所提供的狀態能滿足日後交易上鍊時的所有訪問需要。因此,在 Direct Push 模式下,只有狀態訪問可預測的交易才能得到執行。因爲交易只能使用靜態狀態訪問,合約創建者也應該設計他們的合約,得到可預測的狀態訪問:可以使用諸如可訪問列表( access lists)的註釋,詳細說明合約在運行期間可以訪問的位置。這種方案與避免動態狀態訪問的模式 (可參見 Vitalik 在 Eth1.x 版塊提出的這篇相關博文 )相結合,產生的新模式應該仍能提供足夠的的功能性。不過,這將會與當前的 Eth1 系統大相徑庭。可能會使 Eth1 轉換到 Eth2 的計劃泡湯。

激勵

這個模式只依賴於一般的狀態提供者網絡。正如上面所說的,似乎沒有激勵系統也可行。

激勵制度也可以通過支付通道來添加。假定每個用戶都必須與一個或多個狀態提供者建立一個支付通道,這種方法應該會特別複雜。

中心化風險

單個狀態提供者是無法審查交易的,因爲用戶可以向多個狀態提供者發送多條查詢。因爲狀態提供者可以僅保留一部分狀態,因此硬件要求可以按需降低。金錢激勵可能會促使一些狀態提供者中心化,因此用戶通過支付通道購買狀態時,需要信任對手。

時間約束

沒有時間約束。

丟失狀態的可歸因性

丟失狀態可歸因給用戶。大部分情況下,區塊提供者可以打包狀態不足的交易而仍讓用戶支付。唯一的例外是初始簽名驗證或手續費支付所需的狀態也丟了,這種情況下,交易不會被打包。類比 Eth1 的情況,網絡中的節點可以從交易池中丟棄這種交易。對於這些初始交易部分,必須要施加一些限制來最大化 Gas 的利用 。

關鍵點

  • 主要優勢:簡單。不需專業的狀態提供者或激勵系統。沒有特別的時間約束。
  • 主要缺點:只適用於事先知道所有狀態訪問需要的交易。這限制了整個系統的功能。儘管可以用一些緩解措施,但兼容性問題無法解決。特別地, 這種模型下,Eth1 無法成爲 Eth2 的運行環境。

中繼推送模式(Relayed Push Model)

乾貨 | 研究以太坊 2.0 中的狀態提供者模型

用戶自主向某個中繼者(Relayer,專業的狀態提供者)發送交易。該中繼者將多個交易捆綁在一起並附加交易狀態,將捆綁的交易包中繼至網絡。節點維護待處理的交易包池。每當有新區塊產生,中繼者就爲交易包中繼更新狀態,所有的節點則更新對應的見證信息。BP 在創建區塊時,從交易包池中選擇最新的待處理交易包,把他們包含進新的區塊。

相應地,系統在交易包池中的交易包被證明用不了的情況下,仍然可以運行。中繼者只宣告交易包的存在。區塊提議者會直接聯繫中繼者,得到交易包幷包含進新的區塊。

狀態訪問限制

沒有限制。只要中繼者每個時隙(slot)都能向交易包推送狀態,確保狀態訪問的需要能得到滿足,就可以了。此外,每個新區塊只包含一個數據包,可以防止交易包間的干擾。

激勵

給中繼者設計激勵機制其實挺複雜的,因爲狀態和見證信息一旦公開,用戶 和 / 或 BPs 就有機會繞過見證者,自己重新創建交易包。

兩個可能的解決方案:

  • 沒有交易池的情況下,交易包是不公開的。中繼者向區塊提議者售賣附加了狀態的交易包(費用比交易費低一點),從而形成交易包市場。對區塊提議者來說存在一些風險:某筆交易可能已經被包含在另一個區塊中了,成了無效交易;或者收到的交易費比中繼者售賣時宣告的要少。
  • 另一種方法是,不論有沒有交易池,交易可以包含給某個特定中繼者的支付。用戶承諾一段排他期(即幾個時隙),這段時間內,用戶不會創建其他交易。如果用戶在排他期同時簽署兩個或多個交易時,就要遭到懲罰。爲此,EE 必須提供 「罰沒」 用戶的方法。但因爲用戶沒有鎖定保證金,那麼尚不清楚如何罰沒沒有足夠賬戶餘額的用戶。

中心化風險

中心化風險依賴於使用何種中繼者激勵機制:

  • 假定合併交易包是複雜的(因爲動態狀態訪問),交易包市場會導致高中心化,並且允許單獨的中繼者審查交易。因爲上面列出的 BPs 可能遭受的風險,BPs 更傾向於與知名且信任的中繼者合作。個人用戶與這些知名的中繼者相比,是無法提供有足夠高交易費的交易包的。
  • 使用排他期以及交易包池會提供高程度的去中心化,但是以用戶的便利性和一個更加複雜的交易池實現爲代價。理論上來講,任何用戶都可以從交易池中檢索到交易包,添加自己的交易去擴充交易包,然後以更高的交易費用中繼交易包。

時間約束

爲了支持所有類型的交易,任何包含進區塊的交易包都必須包含最新狀態。中繼者必須下載前面的區塊,創建並向區塊提議者發送交易包對應的更新, 區塊提議者則在新塊中包含更新的交易包,所有的這些行爲都要在一個 slot 的時間內完成。

丟失狀態的可歸因性

狀態丟失可歸因於中繼者。區塊提議者可要求中繼者(或是中繼者自願選擇)爲某一筆交易附加 「退款交易」,用於在交易因狀態丟失而失敗時向區塊提議者退款。

關鍵點

  • 主要優勢:沒有狀態訪問限制。
  • 缺點:
    • 光靠一個交易包池可能不夠,因爲交易包體積較大(與 Eth1 中單個單個交易所組成的交易池相反),而且有嚴格的時間約束。
    • 沒有交易池的情況下,交易包不能被組合起來,那麼一個區塊就只能包含單箇中繼者提出的交易包。中繼者可能會中心化並引入審查。
    • 就算有交易池,交易包組合功能是否足以完全緩解審查問題依舊是不明朗的。
    • 激勵系統很複雜。

拉取模式(Pull Model)

乾貨 | 研究以太坊 2.0 中的狀態提供者模型

用戶向網絡發送交易,節點維護待處理交易池。創建區塊前,區塊提議者從交易池中選出部分待處理交易,組成交易包併發送給某個狀態提供者,請求這個交易包的狀態。接收到狀態後,由區塊提供者將交易包打包進新的區塊。

在狀態提供者提供所有狀態以前,爲了讓中間節點和區塊提議者能夠驗證交易的有效性,用戶必須在交易上附加驗證簽名和手續費支付能力所需的見證消息。因此這一部分在不同的執行環境(EE)中必須是標準化的,所有 EE 都必須提供一個最簡單驗證函數選項。

或者可以使用一個 Value-Holding EE (VHEE)。每筆交易都使用這個 VHEE 來支付費用。網絡中的節點會理解 VHEE, 從而可以驗證交易有效性。

在這兩種情況下,網絡中的節點都需要在新區塊到達時更新附加狀態的見證信息。

區塊提議者是預測不了交易包的實際 Gas 花銷的。在特殊條件下,交易包中的任意一筆交易都有可能使得這筆交易的所有後序交易無效化,比如將發送方的餘額減少爲 0。爲了緩解這個問題,區塊提議者會「超額打包」(overbundle),也就是說,向狀態提供者發送多於他們預計要在區塊中打包的交易數。狀態提供者會提供這些交易的狀態,直到達到區塊上限。如果使用了 VHEE,交易可能還要額外附加一些數據,其中包含 VHEE 地址的列表,以及可以從這些地址中取走的最大金額數。通過這種方式,區塊提議者就能防止前面的交易將後序交易無效化。

狀態訪問限制

對主要交易沒有限制。區塊提議者只有在創建區塊時纔會聯繫狀態提供者,確保返回的狀態是最新的。更重要的是,通過把交易捆綁在一起並以交易包爲單位請求狀態,狀態被附加在準確的上下文中。這種做法保證了所提供的狀態總是充分的。這就包含了與 Direct Push 模式很關鍵的一個差異,Direct Push 模式中,狀態是在交易捆綁_之前_被附加進去的,從而造成了狀態訪問的限制。

因爲用戶必須包含驗證簽名和手續費支付能力的狀態,因此從技術上來說,交易部分的限制和 Direct Push 模型中列出的相同。然而這些限制在實際中是無關緊要的。因爲 Eth1 中,簽名驗證和費用支付是可預測的狀態訪問,因此 Eth1 和 Eth2 之間的兼容性不會被破壞。此外,對 VHEE 來說,它的設計將確保可預測的狀態訪問,從而沒有必要做進一步的限制。

激勵

區塊提議者可通過支付通道或其他方式爲狀態提供者提供的狀態付費。根據 BP 和對手 SP 的信任程度,可以按交易筆數來支付費用(這是信任最小化的),也可以按交易包來支付費用(這樣效率更高)

中心化風險

狀態提供者必須保存所有的狀態,存儲量要求很大。預計狀態提供者還要快速執行交易包,因此對計算能力也有要求。

區塊提議者可能更傾向於向其信任的狀態提供者羣體獲取狀態,減少惡意破壞的風險,從而增加了中心化程度。

然而,單獨一個狀態提供者無法審查交易,因爲負責創建並對交易包排序的是區塊提議者。某個狀態提供者可能會隱藏某個交易包需要的狀態,但是這樣做會損害他們的信譽,而區塊提議者可以很容易地用另一個狀態提供者重試。

時間約束

區塊提議者必須在一個時隙內聯繫上一個能爲 TA 提供待上鍊交易包所需狀態的狀態提供者。

丟失狀態的可歸因性

狀態提供者始終要爲所提供的狀態負責。區塊提議者不可以將狀態不充分的交易打包進區塊,而且只有在驗證了狀態充分後,纔會支付。

關鍵點

  • 優點:
    • 沒有相關的狀態訪問限制。
    • 時間約束問題較少。
    • 沒有顯著的中心化風險。儘管可以預計到,某一些狀態提供者將專門爲區塊提議者提供狀態,但沒有某個狀態提供者可以顯著地干預整個過程的進行。一個狀態提供者可以做的最壞的事情就是在被請求時不提供狀態。
  • 主要的缺點:必須對簽名驗證做一些標準化,或者通過驗證腳本,或者使用 VHEE。

延伸討論

自力更生式見證信息 & Gas 花銷

如果交易發起者可以提供足夠的見證信息來保證他們的餘額,那麼狀態訪問能便宜一點嗎?如果見證信息也放在交易中、經過簽名,其確定性是可以保證的,但是會增加複雜性。

狀態費用

區塊提議者和狀態提供者對狀態的價格是如何協商的呢?由網絡設置嗎?爲生成一個區塊,區塊提議者應該向多個狀態提議者招標,並選擇最便宜的那個嗎?

價格是按狀態訪問次數來算呢?還是按見證數據的大小來算呢?

如果按見證數據的數據量來收費,那麼 BP 如何知道 SP 沒有包含多餘的字節?

如果多筆交易使用相同的見證信息,費用應該被均分嗎?還是每筆交易都支付全款?還是隻有第一筆交易需要支付?

狀態抽象

這個提議沒有確切地定義執行環境該如何獲取狀態,但是拉取模型或者中繼模型運行時應該需要。

分佈式狀態網絡

試想一下,不去收集交易並向狀態提供者發送整個交易包,而是創建一個分佈式哈希表,讓區塊提議者在執行中動態地獲取狀態可行嗎?這種替代方法在網絡請求上會阻塞交易的執行,可能讓交易的序列化執行 太慢 / 不可預測。利用 software transactional memory 中的進展也可以實現這種替代方法。

來源鏈接:ethresear.ch