一文讀懂新分片Danksharding 的提議者/構建者分離方案為何能同時確保每步安全且快速

推薦:

1、PANews推出了很多優質內容匯總頻道,比如PAData、區塊鏈日報、NFT日報、NFT預告、區塊鏈大事件一周預告、一周精選、區塊鏈融資週報等精品頻道,請點擊此處下載PANews即可第一時間看到這些頻道內容的更新。

2、點擊此處加入PANews群組與加密老司機暢聊你對俄烏局勢的看法

來源| ethresear.ch

作者| Vitalik Buterin

翻譯|EthereumCN

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

譯者註:目前新的分片方案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 會被換為信標區塊而不是中間區塊。

圖表解釋

關鍵的特性

從分叉選擇的角度來看,該系統可以被描述為就像現在的信標鏈,只是委員會的規模是不平均的,且會有一個(區塊,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 付費。提議者序列被延遲確保延遲某個提議者的執行區塊對於當被提議的區塊是高價值時竊取未來的提議權是沒用的。

對分片可能的延展

Total
0
Shares
Related Posts