先备知识：
对MEV有基本的认识，知道Flashbot的角色及Flashbot对MEV的影响
知道PoS机制的基本认识以及TheMerge带来的改变
了解mev-boost架构
https://medium.com/taipei-ethereum-meetup/after-the-merge-mev-309e836698cf
Proposer-BuilderSeparation指的是将原本Proposer所负责，进行交易排序的工作，分拆给另一个角色Builder来负责，让Proposer专心验证区块并投票以确保PoS网路的安全。
而mev-boost其实就是一种PBS：Builder透过Relay去竞标收入自己区块内容的权利，Proposer透过Relay选择对他最有利的区块内容。複杂的交易排序由Builder来计算，Proposer只需单纯地选择竞标价格最高的区块内容，如此即便是普通人自己跑的Proposer都能享受到MEV收益，而不必担心自己需要参与激烈的MEV套利竞争。
而这裡指的PBS是由Ethereum协议本身去实行PBS的规则，而不再像是mev-boost一样是单纯Proposer、Relay及Builder之间没有强制力的私下协议。
PBS对Ethereum协议本身的好处
在PBS中，Proposer因为不再需要处理交易排序而可以变成Stateless的状态，也就是Proposer节点不需保存著Ethereum完整的状态。负责交易排序的Builder才需要保存完整的状态，Proposer只需要在收到Builder区块内容时验证MerkleProof就能确认交易会使用到的Ethereum状态，例如Uniswap某个Pool的馀额及Alice本身的代币馀额，有了状态Proposer就能模拟交易执行来确认交易有效性。
Proposer是Stateless，他不保存State，只需要验证MerkleProof
这让Proposer本身的负担又变得更轻，表示成为Proposer门槛又降得更低，就有更多人能成为Proposer，让Ethereum变得更去中心化。
另外一个优点是Dank-Sharding或Sharding都会让区块容量变得更大，表示Proposer负担会变得更重。在PBS中这些负担是由Builder来承担，因此Proposer的中心化程度不会受影响。
https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6
(In-Protocol)PBS
原本在mev-boost中是由被信任的Relay来担任Proposer及Builder之间的中间人。Relay负责保管区块内容，确保Proposer会拿到区块内容但不能轻易偷走Builder的区块内容。但如果Relay是恶意的，则Proposer和Builder都会受害，且他们只能转向和其他Relay合作并期望其他Relay不是恶意的。PBS则是以Ethereum协议来取代这个需要被信任的Relay角色，如果Proposer或Builder任一方作恶，都能由Ethereum协议本身来施加惩罚，而不是必须要仰赖对某个角色的信任。
但要移除这个信任的代价不小，首先我们必须要确保
Builder的区块内容需要被保护，不能直接揭露Proposer如果偷走Builder的区块内容，他必须要付出代价Builder如果没有公佈区块内容，他必须要付出代价综合第1,2点，Proposer必须要先对Builder的区块内容进行承诺，然后Builder才揭露实际的区块内容。如果Proposer违反承诺，改为propose其他区块内容，则他会被惩罚：他的押金被部分没收而且他propose的区块内容无效，也就是收不到该区块内容的手续费及MEV。这也是目前mev-boost有的惩罚机制。
第3点，如果Builder没有公佈区块内容，Builder还是要将竞标费用支付给Proposer。这会由Ethereum协议来强制执行，也是mev-boost做不到的。
Proposer或Builder作恶都会被惩罚，反之合作则都获益
以上是PBS要做到，用来保护Proposer及Builder的规则，而实际上该怎麽完成Proposer承诺及Builder发布区块内容则有不同方式，后面会介绍。但在那之前，必须要先提到当我们把每个区块的交易排序权利都交给Builder时，即便Builder会彼此竞争，都还是会比原本交给Proposer排序交易来的中心化许多。这迫使我们必须要加入额外的机制来避免Builder审查交易。
Censorship
Censorship最著名的例子是2022年八月美国财政部将TornadoCash列入反制裁名单，许多mev-boost的Relay纷纷将TornadoCash的交易加入黑名单。这使得TornadoCash使用者的交易平均需要比普通交易等上数倍的时间才能被收入区块里。
绝大部分Relay还是遵从OFAC，来源mevWatch.info
注1：OFAC甚至将一个只会Echo的合约纳入制裁名单。
注2：这篇文章分析OFAC制裁对Builder的影响。
注3：你可以为自己的Proposer节点设置一个最低竞标价门槛，避免全都採用mev-boost的区块，藉此增加整体网路的抗审查能力。有将近一半的mev-boost区块竞标价都没有到0.05ETH的门槛。
虽然仍有一些Relay是不甩OFAC的，但在PBS中我们没有Relay、也不能指望为数不多的Builder会愿意违背政府的命令。因此我们需要有机制来迫使Builder收录指定的交易。
Censorship成本
在mev-boost/PBS之前，攻击者想要审查一笔最多愿意付XETH的交易，则攻击者必须要不断产生并广播新交易，迫使区块超过半满，藉此把BaseFee拉高到BaseFee*150k>X，如此该交易才不会被收入。假设每个区块只收入最多5mgas的交易，则他每个区块都要烧掉(X/150k)*10m=X*66.67ETH，等同于每个小时要烧掉约X*20000ETH。
但在mev-boost/PBS中，如果BuilderCharlie想要审查一笔交易，他只需要让他的竞标价高过其他Builder。假设该笔交易的手续费中扣掉BaseFee费用后为P，也就是PriorityFee的费用，也就是一个Proposer收入这笔交易实际会获得的手续费，则P就是Charlie在每个区块竞标时都要额外付出的成本。而这和EIP-1559市场机制相比其实是一个非常低的成本，表示mev-boost/PBS让Censorship变得更容易。
不同CensorshipResistance的设计
在PBS中，因为我们不能仰赖Builder是好人，所以我们只能仰赖Proposer，透过Proposer来(1)强迫Builder收入疑似被审查的交易，或是(2)乾脆自己收入疑似被审查的交易。
注意到(2)其实打破了前面对PBSCensorship的假设，不只有Builder可以决定交易排序，Proposer也可以自己插入交易，也因此Censorship自然就没有那麽容易。
(1)InclusionListorcrList(censorshipresistancelist)
Proposer透过指定一个交易清单crList，要求Builder只要区块还有空位，就必须收入crList中的交易，直到塞不下为止。
没有交易被审查的情况，crList会为空。如果一个Proposer发现一笔交易的手续费符合规定可以被收入，且过去一段时间的Builder的区块都还有足够空间可以容纳该笔交易但却没有收入该笔交易的话，就可以怀疑该笔交易正在被审查。轮到他propose时他就可以将该笔交易加入到他的crList中，要来竞标的Builder就必须要收入该交易，除非区块没有足够空间。
注：一笔交易是否正在被审查是主观的，不一定每个Proposer都会看到一样的交易或观察到一样的现象。
当crList裡有交易，Builder就被迫要收入交易，除非塞满区块或原本就已经满了
如此一来，想要审查交易的Builder就必须要将区块用其他交易塞满，除了这些填充用的交易会一直消耗Builder的成本，BaseFee也会因为区块持续塞满而呈指数型上升，导致Builder成本跟著指数型上升，其长期的审查成本会远超过单纯EIP-1559市场机制的审查成本。
不过想要审查交易的Builder可以透过在网路上发布了一系列交易黑名单，要求Proposer不要将裡面的交易加入crList，否则就会拒绝产出区块。假设有Proposer是好人，他宁愿收益减少也不会理会Builder的威胁，那就没问题。但如果假设Proposer皆为理性的，则他们会因为经济考量而配合Builder。因此如果我们要能在Proposer皆为理性的情况下还能做到抗审查，那必须要对crList机制做一点调整。
Revised(1):ForwardInclusionList
为了避免Proposer和来竞标的Builder有利益关係而臣服，在ForwardInclusionList中是由slotn-1的Proposer来决定slotn区块的crList。而因为slotn-1的Proposer收的是slotn-1而不是slotn的竞标收益，所以就没有利益衝突的问题。
Proposer不必担心crList会影响到来竞标的Builder。影响的是下一个Slot的Builder
注：提出crList的人不一定要是Proposer，也可以由其他人来负责提crList，只要能够避免有利益衝突即可。
(2)Proposerbuildpartialblock
除了透过crList指定交易的方式，我们也可以让Proposer来直接插入交易。依插入的交易安排在Builder区块的前或后可以分成Proposerprefixes或Proposersuffixes。
Proposerprefixes中Proposer在commit时会先插入他自己安排的交易，然后再告诉Builder剩下多少gas可以用以及这些交易执行完的状态，让Builder能够调整区块内容。
注：这会需要比较弹性的commit方式，称作SlotAuction，让Builder先竞标到产块权利再决定区块内容。
Proposer先插入他安排的交易
Proposersuffixes中Proposercommit时会顺便commit一个他想插入的交易清单并交给Builder，Builder发布区块内容后Proposer再按照清单裡的顺序，一一安插交易到Builder的区块内容之后，直到区块空间不够或没有剩余交易。
Proposer先commit他想插入的交易，最后如果有空间再一一插入
prefixes和suffixes这两个方法都会加重Proposer的责任，而且Proposer因为要负责亲自插入交易，所以必须要储存完整的Ethereum状态来进行交易运算，也就没办法变成Stateless节点。
注：目前比较有共识的是ForwardInclusionList的做法。
以上是关于抗审查机制的设计，接下来将继续完成对Proposer如何commit及Builder如何发布区块内容的介绍。
mev-boost中Relay要在区块最终上链之前，确保Proposer已经做出承诺、确保Builder的区块内容真的存在。我们要怎麽取代这个角色呢？我们可以用ValidatorCommittee来取代。另外Relay和Proposer/Builder之间的沟通管道也会被p2p网路取代。
注：目前PoS中每个Slot会有1个Proposer及64个Committee的Validator要对该Slot的区块进行投票。
也因此这个机制的安全性和稳定性就会变成奠基于PoS之上：Committee中非恶意成员不能超过一定比例、网路连线没有出现重大延迟，否则会和PoS发生fork一样出现错误，导致Proposer或Builder权益受损。但这还是比原本相信一个中心化角色的安全性来得高。
目前的设计中主要以整个过程多快做完分为TwoSlotPBS及SingleSlotPBS，也就是将整个过程分为两个Slot来做完还是单一个Slot就做完。
TwoSlotPBS
TwoSlotPBS中，会新增一个IntermediateBlock的区块类别，用来放得标Builder的区块内容。Proposer在Slotnpropose一个正常的BeaconBlock，裡面会包含对得标Builder区块内容的commit，Builder接著在Slotn+1proposeIntermediateBlock，裡面包含他的区块内容。可以将两者视为同一个大区块，只是分成两阶段来完成，第一阶段像是BlockHeader，第二阶段才是真正的BlockBody，没有BeaconBlock就没有后面的IntermediateBlock。
区块都要经过Committee投票，变成ForkChoiceRule的一部分
这两个Block都要经过Committee投票，但Slotn的BeaconBlock只有1个Committee对其投票，而Slotn+1的IntermediateBlock则由剩下的N-1个Committee对其投票。
投给SlotnBeaconBlock的投票会被收入在Slotn+1的IntermediateBlock裡，投给Slotn+1IntermediateBlock的投票会被收入在Slotn+2的BeaconBlock裡。
直接引用原文裡的图片：https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
如果Builder一直没有看到BeaconBlock，代表BeaconBlock可能没有被即时发布，所以Builder不会发布IntermediateBlock。但如果该BeaconBlock过一段时间后出现，是否有可能会导致Builder赔钱？事实上该BeaconBlock会因为太晚出现而被其他Validator的ForkChoiceRule拒绝，所以Builder不需要担心。
SingleSlotPBS
SingleSlotPBS可以想像成是把mev-boost中心化的Relay角色换成是去中心化的Committee：Committee负责保管区块内容，等到Proposercommit得标Builder的区块内容后，Committee再合作还原出Builder完整的区块内容并广播出去。
直接引用原文裡的图片：https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877
TwoSlotPBSv.s.SingleSlotPBS
複杂程度
SingleSlotPBS不影响ForkChoiceRule，因此其ForkChoiceRule也不需要像TwoSlotPBS被改得更複杂，进而影响PoS分析难度及安全性。
且SingleSlotPBS和mev-boost架构相似，Proposer和Builder不需要做太大的改动就可以切换。
但SingleSlotPBS需要标准化并实作一套加解密用的密码学技术。
区块时间影响
SingleSlotPBS在一个Slot就能执行完，不像TwoSlotPBS基本上等于把区块时间延长，两个Slot的时间才能有一个“完整”的区块出现
TwoSlotsPBS可以选择把Slot时间缩短，但代价是对网路状况的要求和各个角色的负担会更高，更容易出错
对Committee依赖程度
SingleSlotPBS需要Committee大部分的成员都在线才有办法顺利解密，如果太多不在线会直接导致无法产出区块内容
TwoSlotPBS则不会因为Committee成员不在线而无法产出区块内容
加入crList
如果加入crList，则Committee在对区块投票时的规则就要调整一下：如果Committee成员在crList发布时限之前有收到crList，则Builder的内容需要符合crList的要求，如果不符合要求则Committee成员当作区块内容没有被发布；如果crList没有及时发布，则Committee成员不会检查区块内容是否符合crList要求。
另外因为crList并不是包含在区块资讯中，而是透过p2p网路传递，所以有可能Builder会没收到crList，这时候他可能就会选择不竞标或降低竞标价格，避免发布区块内容后才发现Committee都有收到crList，就他没有收到，导致区块内容不符合crList要求而赔钱。但要真的发生整个p2p网路中Committee成员都收到crList，就Builder没收到的机率也不高。
BlockAuctionv.s.SlotAuction
除了目前mev-boost中Builder对区块内容做竞标，称为BlockAuction，另一种做法是对“产出区块内容的权利”做竞标，称作SlotAuction。
SlotAuction给Builder更多弹性，他可以先竞标取得产出区块内容的权利再开始组装区块内容，但缺点是Builder如果预估错误就有可能因为最后产出的区块内容的MEV比竞标价还少而赔钱，不像BlockAuction中Builder可以确定就是会赚这麽多钱。
总结与重点
PBS能减轻Proposer负担，让网路更去中心化，并能顺利因应未来Sharding带来的区块容量大幅提升的挑战当把交易排序权都交给Builder，自然必须要担心Censorship的问题有几个抗审查的设计，包含Proposer自己排序部分的交易，但目前比较有共识的是採取ForwardInclusionList的做法TwoSlotPBS和SingleSlotPBS是目前PBS架构的两种设计，各有优缺点SingleSlotPBS较简单，但也较中心化，仰赖单一个Committee成员需在线且诚实TwoSlotPBS较去中心化，和PoSForkChoiceRule整合并仰赖多组Committee增加安全性但又不需要Committee一定要在线，只是缺点是设计较複杂下一篇将介绍一些PBS的补丁，让PBS机制及MEV供应链更加去中心化。
参考资料与推荐延伸阅读
PBS资源整理：https://notes.ethereum.org/@domothy/pbs_linksojwr
https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877
https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
https://notes.ethereum.org/@fradamt/H1ZqdtrBF
https://barnabe.substack.com/p/pbs
https://iyusufali.xyz/writings/inclusion-lists
Rollup-Relay
另外有人提出了介于MEV-boost与In-ProtocolPBS之间的RollupRelay：不把PBS加在L1的共识层及p2p层上，而是把PBS实作成一个L2，但缺点是L2Sequencer的角色是需要被信任的。因为这个点子还很新所以这边只做简短介绍，如果未来讨论更热烈会再展开来介绍：https://hackmd.io/@echno/rollup-relay
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。