작성자: Tia, Techub News

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

PBS(Proposer Builder 분리)

이더리움 합병 이전에는 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는 제안자의 검증인의 책임을 블록 구축과 블록 제안으로 더욱 분해하고, 이해관계 경쟁이 수반될 수 있는 복잡한 구축 권한을 구축자에게 아웃소싱함으로써 제안자의 작업이 매우 단순해지고 블록 제안만 하면 됩니다. 빌더가 제출한 블록의 수익 규모를 기준으로 합니다.

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

빌더가 제안자에게 비용을 지불하고 제안자가 빈 블록을 제출한 것에 대해 처벌을 받지 않도록 마지막에 블록 내용을 제안자에게 공개하는 방법과 같은 해결해야 할 다른 문제가 있기 때문입니다. 예를 들어, 빌더 블록이 제출한 영역이 비콘 체인에 확실히 포함되는지 확인하는 방법 등이 있습니다. 이러한 건설자 및 제안자의 권익 보호 문제는 주로 릴레이를 통해 실현됩니다.

빌더는 해당 블록을 릴레이로 보내며, 릴레이는 각 블록에서 얻을 수 있는 수익에 따라 블록을 정렬한 후 가장 높은 수익을 가진 블록 헤더를 제안자에게 전송하여 제안자가 그렇지 않은지 확인합니다. 블록 내용에 표시됩니다. 제안자가 블록 제안을 커밋한 후(블록 헤더에 서명) 릴레이는 전체 블록을 제안자에게 공개합니다. 건설사가 제안자에게 지불하는 수수료 역시 완료를 보장하기 위해 릴레이의 도움이 필요합니다. 제안자에게 지불된 거래는 제출된 블록에 포함되지만, 제안자는 블록의 내용을 볼 수 없기 때문에 릴레이를 통해 사전 확인이 필요합니다.

인 프로토콜 및 아웃 프로토콜

MEV-Boost가 구축한 시장에 참여하려면 검증인은 이더리움 합의 클라이언트 및 실행 클라이언트를 실행하는 동안 이더리움이 아닌 제3자 MEV-Boost 프로그램을 실행해야 합니다. 이는 프로토콜 외부의 제3자가 이더리움의 합의 형성을 위한 규칙 설계에 참여할 수 있도록 허용하는 현재 실행 중인 PBS의 마법입니다. 소유권 관점에서 볼 때 이는 놀라운 일입니다.

이는 또한 프로토콜 메커니즘의 "신뢰성", 신뢰성이 어떻게 강화되고 다른 메커니즘을 통해 신뢰성이 어떻게 약화되는지에 대한 생각을 촉발시켰습니다. 외부 프로토콜이 기존 메커니즘을 변경하는 상황이 있을 수 있으므로 MEV-Boost가 좋은 예입니다. 프로토콜 자체가 뒤처지기 시작하면 그러한 변화가 외부에서 싹트기 시작할 수 있습니다. 외부 메커니즘의 출현은 현재 시장 수요를 충족해야 하지만 외부 메커니즘이 신뢰할 수 있는지, 잠재력의 출현을 방지하도록 엄격하게 설계되었는지 여부입니다. 문제가 있으며, 합의를 훼손할 수 있는 외부 메커니즘도 아직 알려지지 않았습니다.

중앙 집중식 릴레이

MEV-Boost의 가장 비판적인 측면은 중앙 집중식 릴레이 시장입니다. 그러나 이 설정은 신뢰 문제를 야기합니다. 빌더는 릴레이가 MEV를 훔치지 않을 것이라는 점을 신뢰해야 합니다. 제안자는 또한 릴레이에서 수신하고 서명한 블록 헤더가 유효하다는 것을 신뢰해야 합니다. 그러나 중요한 역할에도 불구하고 릴레이에 대한 재정적 인센티브가 없으며 이를 운영하려면 상당한 비용이 필요합니다. 작년에는 이더리움 네트워크를 지원하는 릴레이가 11개 였지만 현재는 9개의 릴레이만이 여전히 서비스를 제공하고 있습니다.

Eden과 같은 릴레이는 자체 빌더만 릴레이할 필요가 없다는 점은 주목할 가치가 있습니다. 선행 공격 및 샌드위치 공격과 관련된 트랜잭션을 필터링한다고 주장하는 bloXroute와 같은 릴레이도 있습니다. 어느 정도까지 릴레이에는 특정 규칙 제정 권한도 있습니다.

데이터는 정격 네트워크 에서 제공됩니다.

게다가 Liveness 관점에서 보면 Relay의 존재로 인해 Builder와 Proposer 사이에 원자 수준의 확인이 존재하지 않습니다. 제안자가 블록 헤더에 대한 커밋에 서명하고 빌더가 페이로드 콘텐츠도 제공하지만 중계 오류(악성이든 비악성이든)로 인해 콘텐츠를 제때 제출하지 못한 경우 빌더와 제안자 모두 손실을 입게 됩니다. .

ePBS: PBS를 이더리움으로 캡슐화

중계 중앙화 문제를 해결하기 위해서든, 프로토콜 외부의 부분을 프로토콜 안으로 옮기기 위해서든, PBS를 이더리움의 ePBS에 캡슐화하는 것은 필수가 된 것 같습니다. 현재 ePBS는 더 이상 논의 중인 제안이 아니며 Ethereum EIP 편집자는 EIP-7732 라는 번호를 할당했습니다.

ePBS는 제안자와 구축자가 블록 건설 권한을 아웃소싱할 수 있도록 무신뢰 인프라를 제공합니다. 원래 프로토콜 외부에 있던 빌더의 역할이 프로토콜에 통합되었습니다. 즉, 빌더의 또 다른 역할이 검증자 간에 분할되어 이더리움에서 서약을 완료해야 합니다. 합의 계층의 원래 제안자의 책임이 분할되었으므로 ePBS를 완성하려면 합의 계층에 대한 변경이 필요합니다. 그 중 빌더는 실행 페이로드(블록에서 실행될 최종 트랜잭션 목록)를 구축하는 역할을 담당합니다. 제안자의 책임은 비콘 블록을 제안하는 것입니다. 구체적인 과정은 다음과 같습니다.

ePBS 역시 제안 당시부터 EIP 번호를 최종적으로 획득하기까지 많은 논의를 거쳤습니다. 처음에는 6월 21일에 Vitalik이 PBS를 제안했고 , 4개월 후에는 2슬롯 솔루션 이 개선되었습니다. 3개월 후에는 7월 23일이 되어서야 PTC 의 아이디어가 공식적으로 제안되었습니다. .

PEPC (프로토콜 시행 제안자 약속)

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

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

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

요약

위 내용은 PBS, ePBS, PEPC에 대한 간략한 소개입니다. 프로토콜 설계 관점에서는 MEV를 재분배하기 위한 시장 메커니즘을 설계해야 할 뿐만 아니라 검증자를 보다 분산화하는 방법과 검열 저항을 개선하는 방법도 고려해야 합니다. 게다가 프로토콜 설계에는 많은 장단점이 있습니다. EIP 번호를 획득한 ePBS를 예로 들어보겠습니다. ePBS의 설계로 중앙 집중식 릴레이 문제가 해결되었지만 계약 외부의 제3자 릴레이로서의 핵심 역할은 실제로 부정적인 영향만 미칠까요? 빌더의 결제 메커니즘 관점에서 보면 ePBS 메커니즘보다 릴레이를 사용하는 것이 더 좋습니다. 왜냐하면 ePBS는 선불 메커니즘이기 때문입니다. 빌더가 초고수익 블록을 패키징하면 제안자에게 높은 금액을 제공할 수 없습니다. 선불 메커니즘.