Vitalik: 兩個 slot 的提議者/構建者分離方案

2022-03-04 15:03:42

譯者注：目前新的分片方案 Danksharding 融合了 PBS (提議者/構建者分離方案) 和 crList 的設計。其中，PBS 方案的構造設計採用的是兩個 slot 的 PBS，這也是 crList 的設計基礎。關於這種“混合式 PBS” 的抗審查分析，可以參見《Vitalik: 如何提高 PBS 方案的交易抗審查性》。本文是兩個 slot 的 PBS 方案的具體設計。

在一個 slot 對裏的事件順序

就在 0 秒之前 — 發布執行頭部發布：任何人都可以發布一個執行頭部，它包含一個執行哈希，一個出價，和一個構建者的籤名。

0 秒 — 信標區塊期限：信標區塊必須打包勝出的執行頭部

0 — 2.67 秒 — 對信標區塊做證明：只有一個委員會對信標區塊做證明投票

8 秒 — 中間區塊的期限：勝出的區塊構建者發布一個中間區塊，由執行區塊主體和他們可以找到的對信標區塊盡可能多的證明組成。

8 — 10.67 秒 — 對中間區塊的證明：剩下的 N-1委員會對中間區塊做證明投票

10.67 — 13.33 秒 — 聚合中間區塊的證明

13.33 — 16 秒 — 發布下一個執行頭部

如果錯失了一個信標區塊，下一個 slot 會被換為信標區塊而不是中間區塊。

圖表解釋

Vitalik: 兩個 slot 的提議者/構建者分離方案

關鍵的特性

從分叉選擇的角度來看，該系統可以被描述為就像現在的信標鏈，只是委員會的規模是不平均的，且會有一個 (區塊，slot ) 分叉選擇。唯一的區別是有些區塊只是用來選擇為緊隨其後的區塊選擇提議者。這就簡化了分析。

每個步驟之間的委員會有助於確保每個步驟都是“安全的“，並且減少被單個行動者濫用帶來的影響。

構建者的安全特性

在發布出價那一步，構建者看到執行頭部，並知道它是否安全 (如果有很多反對票或缺失的證明，這個執行頭部可能是不安全的)。

如果執行頭部是安全的，除非出現大於 45% 的攻擊、非常大量的罰沒，或非常嚴重的網絡延遲，執行頭部才可能被回滾。在這種情況下，構建者可以放心進行安全出價。

如果執行頭部是不安全的，在他們發布他們的主體後區塊鏈還是有重組的風險，以“偷走”他們的 MEV 機會。在這種情況下，構建者看到這個風險後可以調低他們從這個風險獲得風險溢價的出價。

在發布中間區塊時，會有兩種情況：

信標區塊還未被發布。在這種情況裏，證明委員會已經對該區塊投反對票，因此中間區塊產生者 (即構建者) 可以安全地不發布，也不會受到懲罰。

信標區塊已經發布。在這種情況下，中間區塊會有“提議者得分激勵 (proposer boost)'，這個激勵會比整個證明委員會幅度的大，因此如果構建者發布了，他們的區塊將在其余 N-1 證明委員會的證明裏獲勝。

這確保了如果證明委員會是誠實的，且網絡延遲沒有非常嚴重的情況下，構建者就能保證：

如果他們發布了區塊就能被打包

如果他們因為信標區塊頭缺失而不發布區塊是不會被懲罰的

構建者有大約 5.33—8 秒的時間發布區塊。在他們看到信標區塊時可以放心馬上發布；但是，他們可能會想等看到更多證明時再發布，因為他們打包證明會得到獎勵 (被打包的證明者也會得到獎勵)。他們可以自由地在這段時間內 ( 即 5.33 秒的窗口，獲得打包證明獎勵與第 8 秒的窗口沒能獲得打包證明獎勵）協商權衡。

信標鏈規範變更的概要

提議者索引定義

把 get_random_proposer_index(state: State) 設為現在 get_beacon_proposer_index(state) 返回的內容。

添加狀態變量 chosen_builder_index 和 chosen_exec_block_hash。如果 slot 是空的，設 state.chosen_builder_index = NO_BUILDER (一個等於 2**64 - 1 的常量)。如果 slot 包含一個信標區塊，它會包含 BuilderBid，設：

state.chosen_builder_index = builder_bid.message.builder_index

state.chosen_exec_block_hash = builder_bid.message.exec_block_hash

get_beacon_proposer_index(state: State) 的定義如下：

如果 state.chosen_builder_index == NO_BUILDER，返回 get_random_proposer_index(state)

否則，返回 state.chosen_builder_index

攜有出價區塊的條件

如果 state.chosen_builder_index == NO_BUILDER，這個區塊需要包含一個 BuilderBid，且可能不包含一個 ExecBody。builder_bid 需要通過以下檢查，且其中 val = state.validators[builder_bid.message.builder_index]：

bls.Verify(val.pubkey, compute_signing_root(builder_bid.message), builder_bid.signature)

val.activation_epoch == FAR_FUTURE_EPOCH or val.withdrawable_epoch <= get_current_epoch(state)

val.balance >= builder_bid.bid_amount

在處理邏輯中添加余額轉账：

val.balance -= builder_bid.bid_amount

state.validators[get_beacon_proposer_index(state)].balance += builder_bid.bid_amount

把 get_committee_count_per_slot 改為接受輸入 (state: BeaconState, slot: Slot) ( 而不是 epoch )。如果一個 slot 出現 state.chosen_builder_index == NO_BUILDER，委員會數應該返回 1。

攜有執行主體的區塊的條件

如果 state.chosen_builder_index != NO_BUILDER，區塊需要包含一個 ExecBody 且可能不包含 BuilderBid。ExecBody 需要通過以下的檢查：

hash_tree_root(exec_body) == state.chosen_exec_block_hash

eth1_validate(exec_body, pre_state=state.latest_exec_state_root)

在處理邏輯中添加：

state.latest_exec_state_root = exec_body.post_state_root

get_committee_count_per_slot 應該返回 (get_epoch_committee_count(epoch) - state.committees_in_this_epoch_so_far) // (slots_remaining_in_epoch)

如果 state.chosen_builder_index != NO_BUILDER，設 state.chosen_builder_index = NO_BUILDER，無論是否有區塊。

請注意

slot 時間減少到 8 秒 (請記住：執行區塊會是每 2 個 slot 出現一個)。

所有信標區塊，包括攜有出價和執行主體的，在分叉選擇時都應該有 proposer boost。

分叉 slot 應該改為 (block, slot)

可能的延展：通過一項費用延遲發布

如果中間區塊的構建者在 slot N 不發布區塊，在 slot N+1 就沒有交易捆可選。整個提議者序列會被往後推一個 slot (因此 slot N+1 的構建者會變成 slot N+2 的提議者，以此類推)，且 slot N+1 需要選出一個新的隨機提議者。構建者會獲得另一個機會 (即額外的 12 秒作為松弛空間) 來發布。該 slot N+1 執行區塊不能包含任何高價值的共識交易 (例如罰沒)。但是，他們會被罰款 block.basefee * block.target_gas_limit。

原因是他們的執行區塊被延遲了一個 slot，並前置了一個空的執行區塊，因此他們需要為這個 slot 付費。提議者序列被延遲確保延遲某個提議者的執行區塊對於當被提議的區塊是高價值時竊取未來的提議權是沒用的。