TL;DR
- crLists 限制了 Builder 的權益，允許 PBS 從 Proposer 的去中心化屬性中獲得抗審查能力，而不要求身為 Proposer 的節點性能高低與否。
- crLists 的基本原理是讓 Proposer 有權力發布他們認為正在被審查的交易清單。這可以讓 Proposer 在不破壞 PBS 的前提下，起到監督中心化的區塊 Builder 市場。
- Forward Inclusion List 目前最受市場認可，它能夠巧妙的避免 Proposer 和 Builder 有利益沖突。
- Proposer prefixes 和 Proposer suffixes 也是 crList 的實現方式，它們分別在區塊前后時間插入 Proposer 自己安排的交易。
當審查 Builder 能夠實現利潤最大化時，Proposer 將面臨以下兩種選擇：
- 選擇經濟理性——即使面臨審查，也會選擇價值最高的區塊
- 選擇利他主義——避免審查，選擇價值稍低的區塊
理想的情況是，應當盡可能減少甚至消除利他主義的假設。
然而，在 PBS 之后，Builder 獲得了更大的權力。在市場上占主導地位的 Builder 能夠行使審查權，并壟斷交易排序的能力，這導致了中心化風險的出現。Vitalik 在抗審查中提到了必須有一種機制：「讓誠實的 Proposer 可以在不太大幅度地犧牲自身回報的情況下，強制地通過他們懷疑受到審查的交易。」那么，Proposer 可以在確保主網的中立性的前提下，同時實現最大化 MEV 利潤。從整個系統的角度來看，crList 限制了 Builder 的權利，通過 Proposer 的去中心化屬性獲得抗審查能力，而不必關注這些 Proposer 節點的性能水平。
什么是 Censorship Resistance List（crList）？
「crList」，又被人們稱為「混合 PBS 」，它能在不破壞 PBS 的情況下，限制 Builder 的權力，從而起到監督中心化的構建者市場的作用。
他的基本原理是讓 Proposer 有權力發布他們認為正在被審查的交易清單。假設我們對 Builder 審查某一筆交易有所懷疑，那么 Proposer 可以制定一個交易清單，這個清單包含了符合標準但未被收錄的交易。這些清單中的交易必須被 Builder 打包進區塊。當 Builder 在拍賣中勝出后，他們需要證明 crList 中的所有交易都已被包含在區塊中，只有一種情況下可以不做收錄，即當區塊已滿，無法插入新的交易時，可以不包含列表交易。若 Builder 堅持審查交易，并忽視 Proposer 的 crList ，那么證明者將會判定該區塊為無效。在整個過程中，證明者是隨機選取的，他們在提議者提出區塊后，對規范鏈的區塊頭進行投票。如果發現新區塊不符合 crList 的要求，那么證明者就不會投票給該區塊，因此區塊便不會被添加到區塊鏈中。
原始具體方案
原文中 Censorship Resistance List（crList）具體方案如下：
crList 指的是 Proposer 看到的應該被打包的交易列表，即它們的狀態里有正確的隨機數和充足余額，以及足夠被打包的 priority fee 和最高 base fee。這個 crList 只能包含一名 sender ( 發送人 ) 的一筆交易。Proposer 也要對一個 crListSummary 簽名和廣播，它包含在 crList 上每筆 tx 的 tx.sender 和 tx.gaslimit。
Source: NIC Lin；當 crList 裡有交易，Builder 就被迫要收入交易，除非區塊滿載或原本就已經滿了
舉個簡單的例子︰
- Bob 作為 Proposer，他會創建一個 crList 和 crList 摘要，這個列表包含了一些他認為重要的交易。這些交易可能是他自己的，也可能是他認為應該被優先處理的。然后，Bob 將這個 crList 發布到網絡中。
- Alice 作為 Builder，她會看到 Bob 發布的 crList。根據 crList 的內容，Alice 需要在她的新區塊中包含 crList 中的所有交易。
- 如果 Alice 的新區塊符合 crList 的要求，那么證明者會投票給 Alice 的區塊，Alice 的區塊就有可能被添加到區塊鏈中。
- 如果 Alice 的新區塊不符合 crList 的要求，比如沒有包含 crList 中的某些交易，那么證明者就不會投票給 Alice 的區塊，Alice 的區塊就不會被添加到區塊鏈中。
通過這一機制，Proposer 可能會無意間減少其潛在的可捕獲利潤，因為其提交的 crList 會占據區塊的部分空間。這種情況的機會成本則在于，Builder 可能會有機會打包更有利可圖的交易。
在 crList 中，Proposer 通過發布他們認為正在被審查的交易清單，從而限制了 Builder 的中心化。一旦 Builder 忽視了 Proposer 的 crList 并堅持審查交易，那么證明者將會判定該區塊為無效。然而，這種做法也增加了 Proposer 的負擔，因為他們需要花費時間和資源來創建和發布 crList。盡管如此，這種機制仍然是必要的，因為它可以防止 Builder 濫用他們的權力，從而保護了區塊鏈系統的公正性和透明性。
那么，回到上文我們提到的 Proposer 將面臨 2 種選擇：
- 假設有 Proposer 是善意的，他們寧愿減少收益也不會理會 Builder 的威脅，這自然是件好事。
- 但如果假設 Proposer 都是理性的，他們可能會基于獲利情況與否同 Builder 合作。在這種情況下，提議者提交 crList 的意愿可能會降低，從而影響審查的過程。
對此，很多理性的 Proposer 將會提交一個空白的 crList 從而獲取利潤最大化。
Source：Uncommons censorship-resistance workstream如果我們希望在所有提議者都是理性的情況下仍能實現抗審查，那必須要對 crList 機制做一點調整，而不是依賴利他主義假設。
Forward Inclusion List，避免 Proposer 和 Builder 之間的利益沖突
Forward Inclusion List 是目前最受認可的 crList 模型，該模型能夠巧妙地避免 Proposer 和 Builder 之間的利益沖突。在 Forward Inclusion List 中，由 slot n-1 的 Proposer 來決定 slot n 區塊的 crList。這是因為 slot n-1 的 Proposer 收取的是 slot n-1 而不是 slot n 的競標收益，因此不存在利益沖突。這種設計巧妙地避免了 Proposer 和 Builder 之間的潛在利益沖突，使得系統能夠在保持高效運行的同時，有效地抵抗審查。
Source：NIC Lin；Proposer 不必擔心 crList 會影響到來競標的 Builder，影響的是下一個 Slot 的 Builder。
另外，之前我們在 Block Auction 和 Slot Auction 中提到過讓 Proposer 在區塊中直接插入交易：Proposer prefixes 和 Proposer suffixes，在區塊前后時間插入 Proposer 自己安排的交易也是 crList 的實現方式。
Proposer prefixes，預先安插交易
Proposer prefixes 能夠確保某些特定的交易能夠優先被處理。Proposer 在 commit 時會先插入他自己安排的交易，然后再告訴 Builder 剩下多少 gas 可以用以及這些交易執行完的狀態，讓 Builder 能夠調整區塊內容。
Proposer prefixes 在確保 Proposer 的交易能夠被優先處理基礎上，也可以防止 Builder 濫用權力，因為 Builder 不能隨意更改 Proposer 插入的交易。然而，這種策略可能會增加 Proposer 的負擔，因為他們需要花費時間和資源來選擇和插入交易。
Source：NIC Lin；Proposer 先插入他安排的 tx，然后 Builder 在構建區塊的時候必須將這筆 tx 打包進去
Proposer suffixes，空余位置安插交易
Proposer suffixes 充分利用區塊的空間。Proposer commit 時會順便 commit 一個他想插入的交易清單并交給 Builder，Builder 發布區塊內容后 Proposer 再按照清單里的順序，一一安插交易到 Builder 的區塊內容之后，直到區塊空間不夠或沒有剩余交易。
Proposer suffixes 可以充分利用區塊的空間，提高區塊鏈系統的效率。然而，這也可能導致 Proposer 的交易被延遲處理，因為他們必須等待 Builder 填充完區塊后才能插入自己的交易。
Source：NIC Lin；Proposer 先 commit 他想插入的交易，最后如果有空間再一一插入
Source：Uncommons censorship-resistance workstream
小結
crList 給 Proposer 更多的權利以實現抗審查，也同時給 Builder 帶上了枷鎖。如果 Proposer 反過來威脅 Builder 必須將交易包含其中，或者當他們與 Builder 私下勾結，并告訴 Builder 不要包含交易呢？