来源|ethresear.ch
作者|VitalikButerin
翻译｜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机会。在这种情况下，构建者看到这个风险后可以调低他们从这个风险获得风险溢价的出价。
在发布中间区块时，会有两种情况：
信标区块还未被发布。在这种情况里，证明委员会已经对该区块投反对票，因此中间区块产生者(即构建者)可以安全地不发布，也不会受到惩罚。
信标区块已经发布。在这种情况下，中间区块会有“提议者得分激励(proposerboost)'，这个激励会比整个证明委员会幅度的大，因此如果构建者发布了，他们的区块将在其余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：
bls.Verify(val.pubkey,compute_signing_root(builder_bid.message),builder_bid.signature)
val.activation_epoch==FAR_FUTURE_EPOCHorval.withdrawable_epoch<=get_current_epoch(state)
val.balance>=builder_bid.bid_amount
在处理逻辑中添加余额转账：
val.balance-=builder_bid.bid_amount
state.validators.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出现一个)。
所有信标区块，包括携有出价和执行主体的，在分叉选择时都应该有proposerboost。
分叉slot应该改为(block,slot)
可能的延展：通过一项费用延迟发布
如果中间区块的构建者在slotN不发布区块，在slotN+1就没有交易捆可选。整个提议者序列会被往后推一个slot(因此slotN+1的构建者会变成slotN+2的提议者，以此类推)，且slotN+1需要选出一个新的随机提议者。构建者会获得另一个机会(即额外的12秒作为松弛空间)来发布。该slotN+1执行区块不能包含任何高价值的共识交易(例如罚没)。但是，他们会被罚款block.basefee*block.target_gas_limit。
原因是他们的执行区块被延迟了一个slot，并前置了一个空的执行区块，因此他们需要为这个slot付费。提议者序列被延迟确保延迟某个提议者的执行区块对于当被提议的区块是高价值时窃取未来的提议权是没用的。
对分片可能的延展
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。