현재 이더리움 합의와 MEV 사이의 게임은 PoW가 PoS로 전환되는 날부터 시작됩니다...

Written by Tia, Techub News

MEV 문제를 해결하는 과정은 실제로 블록 공간의 할당 규칙을 다시 공식화하는 것입니다. 모든 사람이 더 이상 MEV에 익숙하지 않다고 생각합니다. 하지만 일부 Ethereum MEV 거버넌스 제안이 무엇을 말하는지 알고 싶다면 여전히 일부 배경 정보를 보충해야 할 수도 있습니다. 따라서 이 기사에서는 거버넌스에 관한 일련의 질문을 정리했습니다. 이더리움이 PoS로 전환한 이후 PBS, ePBS, PEPC 등의 제안에 대해 몇 가지 배경 정보를 제공하고자 합니다.

PBS (Proposer Builder Seperatioin)

이더리움 합병 이전에는 MEV를 해결하는 방법은 Flashbots에서 개발한 MEV-Geth를 변형한 go-ethereum 클라이언트를 사용하는 것이었습니다. 핵심 아이디어는 채굴자들이 MEV 경쟁에 참여하기보다는 채굴이라는 직업에 집중할 수 있도록 하여 발생할 수 있는 잠재적인 구조 조정 문제를 방지하는 것입니다. MEV-Geth의 메커니즘은 매우 간단합니다. 즉, 채굴자가 블록을 패키지할 때 검색자가 제출한 번들의 수익 규모에 따라 선택할 수 있습니다. 이 독창적인 시장 지향 메커니즘을 통해 모든 당사자는 특정 제약을 형성하면서 이익을 얻을 수 있습니다. 검색자는 수익의 일부를 광부와 공유해야 하지만 그 대가로 얻는 것은 광부에게 도난 당하지 않도록 더 안전한 보장입니다. 주요 수익원인 검색자가 갇히게 되면 채굴자 역시 수동적으로 MEV-Geth를 사용하기 시작하게 되며 MEV-Geth의 메커니즘에 의해 더욱 제약을 받게 됩니다. MEV-Geth는 화이트리스트에 있는 채굴자만 검색자 번들을 받을 수 있습니다. 채굴자에게 평판 제한을 가하고 검색자의 결과를 훔치는 채굴자를 화이트리스트에서 제거함으로써 채굴자가 검색자의 MEV 이익을 강탈하는 것을 방지할 수 있습니다.

그러나 합병 후에는 블록 생성 방식이 검증자 중에서 제안자를 무작위로 선택하여 블록을 제안하는 방식으로 변경되므로 제안자가 MEV를 강탈하는 것을 방지하는 평판 제약 방식은 더 이상 실현 가능하지 않습니다.

가능한 해결책은 블록 내용을 검증자에게 보이지 않게 만드는 것입니다. 이러한 사고방식에 따른 추가 개선은 PBS(Proposer Builder Seperatioin, Proposer Builder Seperatioin)입니다. PBS는 제안자의 검증인의 책임을 블록 구축과 블록 제안으로 더욱 분해하고, 이해관계 경쟁이 수반될 수 있는 복잡한 구축 권한을 구축자에게 아웃소싱함으로써 제안자의 작업이 매우 단순해지고 블록 제안만 하면 됩니다. 빌더가 제출한 블록의 수익 규모를 기준으로 합니다.

처음에 이더리움은 병합 중에 PBS를 프로토콜에 포함하기를 원했지만 잠재적인 복잡성으로 인해 이 프로세스가 보류되어 MEV-Boost가 PBS에 개입할 수 있는 기회를 제공했습니다. 현재 PBS는 Flashbots가 개발한 MEV-Boost를 통해 구현됩니다. 빌더와 제안자 외에도 릴레이라는 매우 중요한 역할도 있습니다. 빌더는 블록을 제안자에게 직접 보내는 것이 아니라 세 번째 역할 릴레이를 통해 보냅니다.

빌더가 반드시 제안자에게 비용을 지불할 것인지, 제안자가 피해를 입지 않도록 블록 내용을 마지막에 제안자에게 확실히 공개할 것인지 등 해결해야 할 문제가 몇 가지 더 있기 때문입니다. 빌더가 제출한 블록이 비콘 체인에 포함되는지 확인하는 방법 등 빈 블록을 제출하면 처벌을 받습니다. 이러한 구축자와 제안자의 권익 보호 문제는 주로 릴레이를 통해 실현됩니다.

Builder는 해당 블록을 Relay로 보내고, Relay는 각 블록에서 얻을 수 있는 이익에 따라 블록을 정렬한 다음 제안자가 이해할 수 있도록 이익이 가장 높은 블록 헤더를 제안자에게 보냅니다. 블록 내용은 보이지 않습니다. 릴레이는 제안자가 블록 제안을 커밋(블록 헤더에 서명)할 때까지 제안자에게 전체 블록을 공개하지 않습니다. 건설사가 제안자에게 지불하는 수수료 역시 완료를 보장하기 위해 릴레이의 도움이 필요합니다. 제안자에게 지급된 거래는 제출된 블록에 포함되지만, 제안자는 블록의 내용을 볼 수 없기 때문에 중계기의 사전 확인이 필요합니다.

In protocol & out protocol

为了能参与到 MEV-Boost 构建的市场中去，验证者需要在运行以太坊共识客户端和执行客户端的同时，再运行一个第三方的非以太坊的 MEV-Boost 程序。这就是目前所运行着的 PBS 神奇的之处，它让协议外的第三方参与到了以太坊的共识形成的规则设计中。从所有权的角度来看，这是匪夷所思的。

这也引发了对协议机制「可信度」的思考，可信度是如何被加强的以及又是如何通过其他机制被侵蚀的。MEV-Boost 就是一个很好的例子，因为可能存在外部协议会对现有机制进行更改的情况。当协议本身开始出现滞后性时，这种更改可能就会从外部开始萌发，外部机制的萌发一定是契合目前的市场需求的，但是外部机制是否可信，是否经过严密设计以防止潜在问题的出现，甚至外部机制可能会破坏协议，这都尚未可知。

中心化的 Relay

MEV-Boost 被诟病最多的地方在于其中心化的 relay 市场。但这种设置引入了信任问题。builder 需要相信 relay 不会窃取他们的 MEV。proposer 也必须相信他们从 relay 收到并签署的区块头是有效的。然而，尽管发挥着至关重要的作用，中继却没有任何经济激励，并且运行 relay 也需要一笔不小的开支。去年，还有11 个 relay 为以太坊网络提供支持，但如今，只有 9 个 relay 还在提供服务。

值得注意的是，relay 并不是无需准入的，如Eden 这样的 relay 就只中继自己的 builder。还有一些 relay 如 bloXroute 则声称会过滤掉抢跑和三明治攻击相关的交易。从某种程度上来说，relay 也拥有一定的规则制定权。

数据来自Rated Network

并且，从 Liveness 的角度来看，由于 relay 的存在，builder 与 proposer 之间无法提供原子级别的确认。假如当 proposer 对区块头签署了 commitment，并且 builder 也提供了 payload 内容，但由于 relay 的失误（无论是恶意还是非恶意的）而无法及时提交该内容，都会使 builder 和 proposer 承担损失。

ePBS：将 PBS 封装进以太坊

不论是出于解决 relay 中心化的问题，还是为了将协议外的部分移至协议内， 将 PBS 封装进以太坊的 ePBS 似乎成了一个必选项。目前，ePBS 已不再是讨论中的提案了，以太坊 EIP 编辑已经为其分配编号——EIP-7732。

ePBS 为 proposer 和 builder 提供了一个无需信任的基础设施，以供他们来完成区块构建权的外包。原本在协议外的 builder 的角色被纳入了协议内，即验证者中多拆分出一个 builder 的角色，作为验证者的 builder 也需要在以太坊完成质押。由于将共识层原本 proposer 的职责进行了拆分，因此完成 ePBS 需要对共识层进行改动。其中，builder 负责构建 execution payload（该区块中要被执行的交易的最终列表）。proposer 的职责则是提议信标区块。具体流程如下：

1. Proposer가 선정된 것을 확인한 후 Inclusion List(IL, 즉 이 슬롯에 포함되어야 하는 거래)를 만들어 방송합니다.

2. 빌더는 실행 페이로드와 제안자에게 지불하겠다는 약속이 포함된 블록 해시 "SignedExecutionPayloadHeader"를 제안자에게 보냅니다(실행 페이로드는 IL을 충족해야 함). 포함할 항목 중 하나를 선택합니다. (보통 제안자에게 지불된 가격이 가장 높은 항목이 선택됩니다.) 그리고 제안된 비콘 블록 "

   SignedBeaconBlock
"을 방송합니다.

3. 증인은 증인 임무를 수행합니다

집계자는 동시에 증명 집계를 제출하고 빌더는 실행 페이로드를 방송합니다
PTC(페이로드 적시성 위원회), 각 슬롯에서 512명의 검증자가 PTC 회원으로 선택됩니다. 빌더가 적시에 실행 페이로드를 공개하고 결과를 방송하는지 확인하세요
ePBS도 제안 시점부터 최종 EIP 번호까지 많은 논의를 거쳤습니다. 처음에는 6월 21일에 Vitalik이 PBS를 제안했고, 4개월 후에는 2슬롯 솔루션이 개선되었습니다. 또 3개월 후에는 7월 23일이 되어서야 PTC의 아이디어가 공식적으로 제안되었습니다. .

6. PEPC (Protocol-Enforced Proposer Commitments)

물론 ePBS에 동의하지 않고 대신 다른 솔루션을 사용하기를 희망하는 사람들도 있습니다. PEPC가 그렇습니다. ePBS는 프로토콜에 특정 규칙을 포함하지만 여기 PEPC에서는 제안자가 프로그래밍 가능한 블록 구성 권한을 판매합니다.

PEPC는 2022년 10월 barnabe가 제안했습니다. barnabe는 PBS 메커니즘이 프로토콜 내에서 구현되려면 특정한 신뢰할 수 있는 신호 메커니즘을 구현하는 대신(예를 들어 블록을 구축하라는 요청을 받은 경우) 신뢰할 수 있는 신호 전송을 위한 일반적인 메커니즘을 구현하는 것을 고려해야 한다고 믿습니다. xx ETH를 반환합니다).

PEPC(Protocol-Enforced Proposer Commitments)라는 이름처럼, 프로토콜 내에서 제안자가 제출한 약속을 통해 빌더와 제안자의 권리와 이익을 보장하는 일부 메커니즘이 완성됩니다. 주로 작업 코드 "BEACONROOT"를 통해 구현됩니다. 이는 보다 일반적인 메커니즘으로, 모든 블록 생성 권한을 아웃소싱하거나 블록의 일부만 아웃소싱할 수 있습니다. 즉, 제안자는 프로그래밍 가능한 블록 생성 권한을 판매합니다.

요약

위 내용은 현재 이더리움 합의와 MEV 사이의 게임은 PoW가 PoS로 전환되는 날부터 시작됩니다...의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!