Public Single Leader Election (PSLE) + Secret Probabilistic Backup Election (SPBE)（具體還有其他好的翻譯，請各路大神留言）

爲什麼在eth2中只有單一領導者？

在eth2的每個插槽中（相對於多個插槽），對提案區塊進行單一領導者選舉有助於減少“額外工作”和p2p消息開銷，以及減少與“多個”潛在區塊頭相關的不必要的分叉。

每個插槽都有多個潛在負責人，這將導致委員會內的不同認證票數，從而降低可聚合性，增加p2p消息開銷並增加請求方區塊大小。

在階段1+中增加了分片後，分片提案中的多個領導者將使這一不同的證明問題（每個插槽的BEACON_PROPOSERS_PER_SLOT * SHARD_PROPOSERS_PER_SLOT選項）更加複雜，這不僅會增加開銷，而且會降低給定插槽中交叉鏈接成功的可能性 。如果插槽中的分片提議者的數量爲SHARD_PROPOSERS_PER_SLOT，並且每個選擇者具有相同的選擇概率，則證明將在不同的分片提議中粗略地分割，並且任何SHARD_PROPOSERS_PER_SLOT> 1在大多數情況下都無法獲得2/3交叉鏈接投票 。

單一領導人選舉的弊端

無論是公開的還是祕密的單一領導人選舉（分別是PSLE和SSLE）都有一個明顯的缺點：對於特定時段的活躍性存在單一故障點。

這種活躍性失敗可能有兩種形式（通過共識協議無法區分）：

• 驗證節點不在線，連接不良，或者不生成區塊

• 驗證節點已被惡意攻擊者專門刪除

（1）最基本的-如果驗證節點只是離線的，那就沒辦法。反對（1）是一個大問題，該論點是在整體提案期間脫機會產生巨大的機會成本（約佔總獎勵的1/8），但由於這個原因，我們仍然希望有一定數量的空插槽。

考慮到驗證節點信息泄漏（即頻繁的共識消息的廣播）因此對於典型節點的去匿名化在許多情況下是微不足道的，PSLE使得區塊提議者在其指定的插槽時間附近易受目標DoS攻擊。

儘管有許多額外的協議工具可供區塊提議者使用l (TOR, cloudflare/etc, 使用哨兵節點體系結構等)但這些解決方案中的許多並不令人滿意（例如更高的延遲、集中的依賴性、更高的基礎設施成本等），而這對於愛好者/節點守衛者來說尤爲重要（我們持有的一類驗證節點對權力下放eth2至關重要）。

（2）一般來說，可以通過使該領導人選舉祕密（SSLE）來解決，因此如果不攻擊所有節點，則無法對特定節點執行有針對性的攻擊，但是SSLE很難實現，而且還沒有準備好投入生產。

建議解決方案

鑑於祕密的單一領導人選舉在當前很難進行，尚未準備就緒，且（1）始終是一個邊緣問題，我們提出公共單一選舉（PSLE）+祕密概率備份選舉（SPBE）作爲一種混合解決方案，以提高網絡對攻擊/離線區塊提議者的恢復能力。即使SSLE準備好了，SSLE+SPBE仍然可以作爲抵抗（1）的額外彈性。

PSLE組件的運行方式與今天的區塊提議者領導人選舉完全相同，而SPBE則提供了一個備份，以防所選區塊建議者沒有出現在他們的工作中。

SPBE通過一個可以在區塊提議中被證明的局部祕密（例如插槽的簽名和紀元的隨機種子）來概率地選擇一組備用提議者。此選擇可以通過與聚合選擇非常相似的方式完成（請參閱is_aggregator），其中有一個用於目標備份數的可調參數– TARGET_BACKUPS_PER_SLOT。

如果尚未在本地看到來自公共領導人的區塊提議，則選定的備份提議者通過指定的插槽創建並廣播部分區塊（例如eth2階段0配置中的1/6）。節點不考慮/廣播早期備份。

在LMD GHOST中打破平局時，公共領導建議優先考慮，然後是備用區塊提議，然後按字典順序打破。在正常情況下，公共領導人按時提交提案，該席位的委員會將把該提案視爲提案的負責人，而不考慮任何備份，在公共領導人區塊準時/可用的情況下，自然會集中選擇分叉點。[請記住，在插槽 S+1之前，我們不會考慮插槽 S的證明，因此提案是權重爲0的葉節點，給leader-block建議以平局優勢]

具體規格變更

將backup_proposer_proof：BLSSignature添加到BeaconBlock

修改process_block_header 1中的提議者斷言，以允許備份提議：

def is_valid_leader_proposal(state: BeaconState, block: BeaconBlock) -> bool:
    return (
        block.proposer_index == get_beacon_proposer_index(state)
        and block.backup_proposer_proof == BLSSignature()  # empty bytes
    )

def is_valid_backup_proposal(state: BeaconState, block: BeaconBlock) -> bool:
    # Similar to leader selection, backups are only known within current epoch
    seed = get_seed(state, epoch, DOMAIN_BEACON_PROPOSER) + int_to_bytes(state.slot, length=8)
    signing_root = compute_signing_root(seed, get_domain(state, DOMAIN_BACKUP_PROPOSER))
    proposer = state.validators[block.proposer_index]
    return (
        # public leader cannot make backup proposal
        block.proposer_index != get_beacon_proposer_index(state)
        and bls.Verify(proposer.pubkey, signing_root, block.backup_proposer_proof)

    )

def process_block_header(state: BeaconState, block: BeaconBlock) -> None:
    ...
    # Verify that proposer index is the correct index
    # -- REMOVE -- assert block.proposer_index == get_beacon_proposer_index(state)
    assert (
        is_valid_leader_proposal(state, block)
        or is_valid_backup_proposal(state, block)
    )
    ...

記住在fork選擇存儲中哪些區塊是“ leader”區塊。例如添加is_leader：Dict [Root，bool]存儲在on_block中添加時以領導者（True）或備份（False）提議跟蹤每個區塊。

修改分叉選項的get_head，以首先由is_leader和第二個按字典順序平分。

def get_head(store: Store) -> Root:
    ...
    while True:
        ...
        # Sort by latest attesting balance with ties broken leader blocks then lexicographically
        head = max(
            children,
            key=lambda root: (
                get_latest_attesting_balance(store, root),
                is_leader[root],  # tie break by leader
                root,  # tie break by lexicographical sort
            )
        )

將備用職責添加到“驗證程序”指南中。如果尚未看到領導者的有效提議，則備份區塊將在SECONDS_PER_SLOT // 6廣播到插槽中。

修改process_randao，process_attestation和slash_validator以使用block.proposer_index（而不是get_beacon_proposer_index）進行提議者查找，因爲get_beacon_proposer_index僅適用於領導者。這將需要更改每個函數的功能簽名以確保傳遞信息。

討論區

及時的備用提議者

我們可能會擔心，對於一個備份提議者來說，在任何選定的時段開始時及時地創建和廣播備份建議，而不是等待是否真的需要備份。這主要是在帶寬方面損害了網絡-每個插槽〜1 + TARGET_BACKUPS_PER_SLOT個區塊。是由於fork選項的修改，當leader處於活動狀態時，不會導致更高程度的分叉。

可以添加有關gossipsub beacon_block主題中的其他約束，以確保不傳播早期備份塊（在1/6時隙之前），並且如果看到前導塊，則將其完全刪除。在大多數網絡遵循這種傳播規則的情況下，通常情況下，當領導者處於活動狀態並且等待時間很短時，即使備用提議者嘗試分發數據塊，它們也將在一兩跳之內被丟棄。

攻擊者備用提議者

我們可能擔心備用提議者攻擊領導者以增加備用提議者被納入規範鏈的機會變得合理。

在驗證器內部創建此額外的攻擊媒介/誘因是合理的考慮。如果沒有SPBE，則想要破壞提議者活動的集合通常僅限於外部攻擊者，而SPBE則創建了新的驗證者內部動機來進行分析。

有幾件事需要注意

1. 這種對SPBE的攻擊會退化爲一個活鏈，這很好。

2. 進行這種攻擊的動機可以說很低，因爲實際獲得備份建議的機會只是TARGET_BACKUPS_PER_SLOT的一小部分，因此，在實驗中，這僅值已經相對較小的部分獎勵（與attes職責相比）。

3. 爲了進一步降低備份方案的額外攻擊誘因，我們可以使備份方案只接受方案獎勵//backup_DISCOUNT_FACTOR，其中backup_DISCOUNT_FACTOR>=2。隨着這個數字的增加，備份建議將變得更像是一種利他主義行爲，以幫助網絡的活躍性（我認爲大多數誠實的驗證者都願意執行），而不是一種單獨盈利的行爲，可能會導致破壞正常運行。

也就是說，在PSLE+SPBE中，備份提議者可以進行的攻擊是主要關注的問題，應該進一步討論和分析。

共識複雜性和第0階段交付

儘管我想在那裏討論這種潛在的算法，但我還是主張不要在階段0中引入SPBE，以免干擾階段0的交付。如果有針對性的DoS成爲主網上的真正問題，我們可以將其作爲選擇。此外將PSLE + SPBE聲明爲公共選項可能從一開始就可以阻止這種攻擊。

根據進一步的討論，觀察到的主網攻擊以及SSLE的進展，我們可以考慮將其集成到後續階段/分支中。

-----------------------------------------------原文作者：djrtwo  譯者：鏈三豐  譯文出處： http://bitoken.world -----------------------------------------------