이더리움 컨센서스와 MEV의 현재 게임은 PoW가 지분 증명으로 전환된 날부터 시작되었습니다!

글: 티아, 테크큐브뉴스

메가메브 문제를 해결하는 과정은 실제로 블록 공간 할당 규칙을 다시 작성하는 것입니다. MEV에 대해 더 이상 익숙하지 않으시겠지만, 이더리움 MEV 거버넌스 제안 중 일부에 대해 알고 싶다면 여전히 배경 정보가 필요할 수 있으므로 이 기사에서는 이더리움이 지분 증명으로 전환한 이후 PBS, ePBS, PEPC와 같은 MEV 거버넌스에 대한 일련의 제안을 정리하여 배경 정보를 제공하고자 합니다.

PBS(제안자 생성자 분리)

이더리움 합병 이전에는 수정된 고이더리움 클라이언트인 플래시봇이 개발한 MEV-Geth를 통해 MEV를 처리하는 방식이 사용되었습니다. 핵심 아이디어는 채굴자가 MEV를 놓고 경쟁하는 대신 채굴에 집중할 수 있도록 하여 발생할 수 있는 구조조정 문제를 피하는 것입니다. MEV-Geth의 메커니즘은 간단합니다. 채굴자가 블록을 포장할 때 검색자가 제출하는 번들 수익의 크기를 선택할 수 있는 시장 기반 솔루션입니다. MEV-Geth 메커니즘은 단순한 시장 기반 솔루션입니다. 이 영리한 시장 기반 메커니즘을 통해 모든 당사자는 이익을 얻는 동시에 특정 제약 조건을 형성할 수 있습니다. 검색자는 수익의 일부를 채굴자와 공유해야 하지만, 그 대가로 채굴자의 도난으로부터 더 안전하게 보장받습니다. 서처가 주요 수익원으로 포착되면 채굴자는 수동적으로 MEV-Geth를 사용하기 시작하고, 채굴자의 화이트리스트를 유지하고 화이트리스트에 있는 채굴자만 서처 번들을 받을 수 있는 MEV-Geth의 메커니즘에 의해 더욱 제약을 받게 될 것입니다. 채굴자에게 평판 제약을 부과하고 검색자로부터 결과를 훔친 채굴자를 화이트리스트에서 제외함으로써 채굴자가 검색자로부터 MEV 수익을 훔치는 것을 방지할 수 있습니다.

가능한 해결책은 블록 콘텐츠를 검증자에게 보이지 않게 만드는 것입니다. 이보다 더 세분화된 방식은 제안자로서의 검증자의 업무를 블록 빌딩과 블록 제안으로 세분화하여 이해관계가 얽혀 있을 수 있는 복잡한 빌딩 권한을 빌더에게 아웃소싱하고, 이 경우 제안자의 업무는 매우 단순해지고 제안자에게는 블록 내용만 보이게 하는 PBS(Proposer Builder Seperatioin, 제안자 분리 방식)입니다. 제안자의 작업은 매우 간단해지며, 블록을 제안할 이익의 크기를 선택하기 위해 건축업자에 따라 블록을 제출하기만 하면 됩니다.

원래 이더리움은 병합 시점에 PBS를 프로토콜에 포함시키려 했으나, 잠재적인 복잡성으로 인해 해당 프로세스가 보류되었고, MEV-Boost가 PBS를 도입할 기회를 얻게 되었습니다. 현재 PBS는 플래시봇에서 개발한 MEV-Boost를 통해 구현되고 있습니다. 빌더와 제안자 외에 또 다른 중요한 역할인 릴레이가 있습니다. 빌더는 제안자에게 직접 블록을 보내지 않고 제 3의 역할인 릴레이를 통해 블록을 전송합니다.

빌더가 항상 제안자에게 보상을 지급하고 제안자가 빈 블록을 제출하는 것을 방지하기 위해 마지막에 블록의 내용을 항상 제안자에게 공개하는 방법 등 해결해야 할 다른 문제들이 많기 때문입니다. 제안자가 빈 블록을 제출해도 제안자의 권리가 박탈되지 않도록 하는 방법, 예를 들어 빌더가 제출한 블록이 비콘 체인에 포함될 수 있도록 하는 방법 등이 있습니다. 이러한 빌더와 제안자의 권리와 이익을 보호하는 문제는 주로 릴레이를 통해 이루어집니다. 빌더가 릴레이에 블록을 보내면 각 블록에 따라 릴레이는 블록 정렬에 대한 이익을 얻을 수 있으며, 블록의 내용에 대한 제안자가 보이지 않도록 하기 위해 블록 헤어의 이익이 가장 높은 블록을 제안자에게 보냅니다. 제안자가 블록 제안에 동의한 후에야(블록 헤더에 서명함으로써) 릴레이는 제안자에게 전체 블록을 공개합니다. 빌더가 제안자에게 지불하는 금액도 릴레이를 통해 보호됩니다. 제안자에 대한 지불은 제출된 블록에 포함되어 있지만 제안자는 블록의 내용을 볼 수 없으므로 릴레이는 이를 미리 확인해야 합니다.

인 프로토콜 & 아웃 프로토콜

MEV-Boost가 구축된 시장에 참여하려면 검증자는 이더 컨센서스 클라이언트 및 실행 클라이언트와 함께 제3자 비이더 MEV-Boost 프로그램을 실행해야 합니다. 이것이 현재 운영되고 있는 PBS의 마법으로, 프로토콜 외부의 제3자가 이더 합의 형성 규칙 설계에 참여할 수 있습니다. 소유권 관점에서 볼 때 이는 놀라운 일입니다. 이는 또한 프로토콜 메커니즘의 '신뢰성', 그 신뢰성이 어떻게 강화되고 다른 메커니즘을 통해 어떻게 약화될 수 있는지에 대한 생각으로 이어집니다. 외부 프로토콜이 기존 메커니즘을 변경할 수 있는 상황이 있을 수 있으므로 MEV-Boost가 이에 대한 좋은 예가 될 수 있습니다. 프로토콜 자체가 지체되기 시작하면 외부에서 이러한 변화가 싹트기 시작할 수 있습니다. 외부 메커니즘의 싹트는 것은 현재 시장의 요구에 맞아야 하지만, 외부 메커니즘이 신뢰할 수 있는지, 잠재적인 문제를 방지하기 위해 신중하게 설계되었는지, 심지어 외부 메커니즘이 프로토콜을 약화시킬 수 있는지 여부는 아직 알려지지 않았습니다.

중앙화된 릴레이

메브-부스트의 가장 비판적인 측면은 중앙화된 릴레이 시장입니다. 하지만 이러한 구조는 신뢰 문제를 야기합니다. 구축자는 릴레이가 자신의 MEV를 훔치지 않을 것이라는 믿음을 가져야 하고, 제안자 또한 릴레이에서 받고 서명한 블록헤드가 유효하다는 것을 믿어야 합니다. 그러나 릴레이는 중요한 역할에도 불구하고 재정적 인센티브가 없으며, 이를 운영하는 데 상당한 비용이 듭니다. 작년에는 11개의 릴레이가 이더넷 네트워크를 지원했지만 현재는 9개의 릴레이만 서비스되고 있습니다.

한 가지 주목할 점은 릴레이가 접속 중립적이지 않다는 점입니다. Eden과 같은 릴레이는 자체 빌더만 중계하고 bloXroute 같은 릴레이는 로보콜 및 샌드위치 공격과 관련된 트랜잭션을 걸러낸다고 주장합니다. 어떤 의미에서 릴레이는 규칙을 만드는 힘도 가지고 있습니다.

데이터 출처:  Rated Network

그리고 Liveness 관점에서 보면, 릴레이가 존재하기 때문에 건설사 와 제안자는 원자 수준의 확인을 제공할 수 없습니다. 제안자가 블록 헤더에 대한 커밋에 서명하고 빌더가 페이로드 콘텐츠를 제공했지만 릴레이가 실수(악의적이든 아니든)로 인해 콘텐츠를 제때 커밋하지 못하면 빌더와 제안자 모두 손해를 입게 됩니다.

ePBS: 이더에 PBS 캡슐화하기

중계 중앙성 문제를 해결하기 위해서든 프로토콜의 프로토콜 외부 부분을 프로토콜 안으로 옮기기 위해서든, 이더의 ePBS에 PBS를 캡슐화하는 것은 필수적인 것처럼 보였습니다. 현재 ePBS는 더 이상 논의 중인 제안이 아니며, 이더 EIP 편집자들은 EIP-7732라는 번호를 부여했습니다.

ePBS는 제안자와 빌더가 블록 생성 권한을 아웃소싱할 수 있는 신뢰 없는 인프라를 제공합니다. 프로토콜 외부에 있던 빌더의 역할이 프로토콜 내부로 통합되어 검증자에게서 빌더 역할이 분리되었으며, 검증자인 빌더는 이더로 서약을 완료해야 합니다. 합의 레이어에서 원래 제안자의 역할이 분할되었으므로 ePBS를 완료하려면 합의 레이어를 변경해야 합니다. 이 경우 빌더는 실행 페이로드(블록에서 실행될 트랜잭션의 최종 목록)를 구축할 책임이 있습니다. 제안자의 책임은 비콘 블록을 제안하는 것입니다. 프로세스는 다음과 같습니다:

1. 제안자로 선정되었음을 확인한 후 포함 목록(IL, 해당 슬롯에 포함되어야 하는 트랜잭션)을 작성하여 브로드캐스트합니다.

2. 구축자는 제안자에게 실행 페이로드가 포함된 블록의 해시와 제안자에게 실행 페이로드에 대한 수수료를 지불하겠다는 약속 "SignedExecutionPayloadHeader"를 전송합니다(실행 페이로드는 실행 페이로드는 IL을 만족해야 함)

3. 제안자는 빌더가 보낸 "SignedExecutionPayloadHeader" 중 하나를 선택하여 통합합니다(일반적으로 제안자에게 가장 높은 가격을 지불하는 것을 선택합니다). 그리고 제안된 비콘 블록 "SignedBeaconBlock"을 브로드캐스트합니다.

4. 증인은 증인 의무를 이행합니다

5. 합산자는 증명 집계를 제출하고, 빌더는 실행 페이로드를 브로드캐스트합니다

6. PTC( 동시에 빌더는 실행 페이로드를 브로드캐스트합니다

7. PTC(각 슬롯에서 512명의 검증인이 선정되는 페이로드 적시성 위원회)는 빌더가 실행 페이로드를 제때 공개하는지 확인하고 결과를 브로드캐스트합니다

제안 시점과 ePBS의 EIP 번호 획득 시점 사이에는 많은 논의가 있었습니다. 그 사이에도 많은 논의가 있었습니다. 처음에 비탈릭이 제안한 것은 6월 21일이었고, 4개월 후 <투 슬롯> 방식이 완성되었고, 다시 3개월 후 <싱글 슬롯> PBS가 도입되었으며, 7월 23일이 되어서야 PTC라는 아이디어가 정식으로 제안되었습니다.

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

물론 ePBS에 동의하지 않고 다른 방식으로 대체하자는 사람들도 있습니다. ePBS는 프로토콜에 결정론적 규칙을 삽입하는 방식이지만, PEPC의 경우 제안자 ePBS는 프로토콜에 정의된 규칙을 삽입하는 방식이지만, PEPC의 경우 제안자가 프로그래밍 가능한 블록을 만들 수 있는 권리를 판매합니다.

PEPC는 2022년 10월 barnabe에 의해 제안되었습니다. barnabe는 PBS 메커니즘이 프로토콜 내에서 구현되려면 특정 신뢰 신호를 위한 메커니즘(예: 블록을 만들게 해주면 xx ETH를 돌려드립니다)이 아니라 신뢰 신호를 위한 일반적인 메커니즘으로 간주되어야 한다고 주장했습니다.

PEPC(프로토콜 강제 제안자 커밋)라는 이름에서 알 수 있듯이, 빌더와 제안자의 권리와 이익을 보장하는 메커니즘 중 일부는 프로토콜 내에서 제안자가 제출한 커밋을 통해 이루어지며, 이는 온체인에서 검증할 수 있습니다. 이러한 커미트먼트는 주로 "비콘루트" 연산 코드를 통해 체인에서 검증됩니다. 이는 보다 일반적인 메커니즘으로, 블록 생성 권한을 모두 위탁하거나 블록의 일부만 위탁할 수 있으며, 즉 제안자가 프로그래밍 가능한 블록을 생성할 수 있는 권리를 판매할 수도 있습니다.

요약

위 내용은 PBS, ePBS, PEPC에 대한 간략한 소개입니다. 프로토콜 설계의 관점에서, 우리는 MEV를 재분배하기 위한 시장 메커니즘을 설계해야 할 뿐만 아니라 검증자를 더 탈중앙화할 수 있는 방법과 검열 저항성을 개선할 수 있는 방법도 고려해야 합니다. 또한 프로토콜 설계에는 많은 트레이드오프가 있습니다. 이미 EIP 번호를 획득한 ePBS를 예로 들어보겠습니다. ePBS의 설계는 중앙화된 릴레이의 문제를 해결했지만, 프로토콜 외부의 제3자로서의 릴레이의 핵심 역할이 과연 부정적인 영향만 끼칠까요? 빌더의 지불 메커니즘 측면에서 보면 ePBS는 선불 메커니즘이며, 빌더가 수익성이 매우 높은 블록을 패키징하면 선불 메커니즘 하에서는 제안자에게 높은 수익을 제공할 수 없기 때문에 ePBS 메커니즘보다 릴레이를 사용하는 것이 더 바람직합니다.