작성자: Tia, Techub News
MEV 문제를 해결하는 과정은 실제로 블록 공간의 할당 규칙을 다시 공식화하는 것입니다. 모든 사람이 더 이상 MEV에 익숙하지 않다고 생각합니다. 하지만 일부 이더 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는 제안자의 검증인의 책임을 블록 구축과 블록 제안으로 더욱 분해하고, 이해관계 경쟁이 수반될 수 있는 복잡한 구축 권한을 구축자에게 아웃소싱함으로써 제안자의 작업이 매우 단순해지고 블록 제안만 하면 됩니다. 블록 제출로 인한 건축업자의 이익을 기준으로 합니다.
처음에 이더 병합 중에 PBS를 프로토콜에 포함하기를 원했지만 잠재적인 복잡성으로 인해 이 프로세스가 보류되어 MEV-Boost가 PBS에 개입할 수 있는 기회를 제공했습니다. 현재 PBS는 Flashbots가 개발한 MEV-Boost를 통해 구현됩니다. 빌더와 제안자 외에 릴레이라는 매우 중요한 역할도 있습니다. 빌더는 블록을 제안자에게 직접 보내는 것이 아니라 세 번째 역할 릴레이를 통해 보냅니다.
빌더가 제안자에게 비용을 지불하고 제안자가 빈 블록을 제출한 것에 대해 처벌을 받지 않도록 마지막에 블록 내용을 제안자에게 공개하는 방법과 같은 해결해야 할 다른 문제가 있기 때문입니다. 예를 들어, 빌더 블록이 제출한 영역이 비콘 체인에 확실히 포함되는지 확인하는 방법 등이 있습니다. 이러한 건설자 및 제안자의 권익 보호 문제는 주로 릴레이를 통해 실현됩니다.
빌더는 해당 블록을 릴레이로 보내며, 릴레이는 각 블록에서 얻을 수 있는 수익에 따라 블록을 순서 한 후 가장 높은 수익을 가진 블록 헤더를 제안자에게 전송하여 제안자가 그렇지 않은지 확인합니다. 블록 내용에 표시됩니다. 제안자가 블록 제안을 커밋한 후(블록 헤더에 서명) 릴레이는 전체 블록을 제안자에게 공개합니다. 건설사가 제안자에게 지불하는 수수료 역시 완료를 보장하기 위해 릴레이의 도움이 필요합니다. 제안자에게 지불된 거래는 제출된 블록에 포함되지만, 제안자는 블록의 내용을 볼 수 없기 때문에 사전에 릴레이의 확인이 필요합니다.
인 프로토콜 및 아웃 프로토콜
MEV-Boost가 구축한 시장에 참여하려면 검증인은 이더 합의 클라이언트 및 실행 클라이언트를 실행하는 동안 이더 이 아닌 타사 MEV-Boost 프로그램을 실행해야 합니다. 이는 프로토콜 외부의 제3자가 이더 의 합의 형성을 위한 규칙 설계에 참여할 수 있도록 하는 현재 실행 중인 PBS의 마법입니다. 소유권 관점에서 볼 때 이는 놀라운 일입니다.
이는 또한 프로토콜 메커니즘의 "신뢰성", 신뢰성이 어떻게 강화되고 다른 메커니즘을 통해 신뢰성이 어떻게 약화되는지에 대한 생각을 촉발시켰습니다. 외부 프로토콜이 기존 메커니즘을 변경하는 상황이 있을 수 있으므로 MEV-Boost가 좋은 예입니다. 프로토콜 자체가 뒤처지기 시작하면 그러한 변화가 외부에서 싹트기 시작할 수 있습니다. 외부 메커니즘의 출현은 현재 시장 수요를 충족해야 하지만 외부 메커니즘이 신뢰할 수 있는지, 잠재력의 출현을 방지하도록 엄격하게 설계되었는지 여부입니다. 문제가 있으며, 합의를 훼손할 수 있는 외부 메커니즘도 아직 알려지지 않았습니다.
중앙 집중식 릴레이
MEV-Boost의 가장 비판적인 측면은 중앙 집중식 릴레이 시장입니다. 그러나 이 설정은 신뢰 문제를 야기합니다. 빌더는 릴레이가 MEV를 훔치지 않을 것이라는 점을 신뢰해야 합니다. 제안자는 또한 릴레이에서 수신하고 서명한 블록 헤더가 유효하다는 것을 신뢰해야 합니다. 그러나 중요한 역할에도 불구하고 릴레이에 대한 재정적 인센티브가 없으며 이를 운영하려면 상당한 비용이 필요합니다. 지난해 이더 네트워크를 지원하는 릴레이는 11개였지만, 현재는 9개의 릴레이만이 여전히 서비스를 제공하고 있다.
Eden과 같은 릴레이는 자체 빌더만 릴레이할 뿐 권한이 필요하지 않다는 점은 주목할 가치가 있습니다. 선행 공격 및 샌드위치 공격과 관련된 트랜잭션을 필터링한다고 주장하는 bloXroute와 같은 릴레이도 있습니다. 어느 정도 릴레이에는 특정 규칙 제정 권한도 있습니다.
데이터는 정격 네트워크에서 제공됩니다.
게다가 Liveness 관점에서 보면 Relay의 존재로 인해 Builder와 Proposer 사이에 원자 수준의 확인이 존재하지 않습니다. 제안자가 블록 헤더에 대한 약속에 서명하고 빌더가 페이로드 콘텐츠도 제공하지만 중계 오류(악성이든 비악성이든)로 인해 콘텐츠를 제때 제출할 수 없는 경우 빌더와 제안자 모두 손실을 감수하게 됩니다.
ePBS: PBS를 이더 으로 캡슐화
중계 중앙화 문제를 해결하기 위해서든, 프로토콜 외부의 부분을 프로토콜 내부로 옮기기 위해서든, PBS를 이더 의 ePBS에 캡슐화하는 것은 필수가 된 것 같습니다. 현재 ePBS는 더 이상 논의 중인 제안이 아니며 이더 EIP 편집자는 EIP-7732라는 번호를 할당했습니다.
ePBS는 제안자와 구축자가 블록 건설 권한을 아웃소싱할 수 있도록 무신뢰 인프라를 제공합니다. 원래 프로토콜 외부에 있던 빌더의 역할이 프로토콜에 통합되었습니다. 즉, 검증자로서 빌더 역할이 하나 더 분할되어 이더 에서 스테이킹 완료해야 합니다. 컨센서스 레이어 원래 제안자의 책임이 분할되었으므로 ePBS를 완성하려면 컨센서스 레이어 에 대한 변경이 필요합니다. 그 중 빌더는 실행 페이로드(블록에서 실행될 최종 트랜잭션 목록)를 구축하는 역할을 담당합니다. 제안자의 책임은 비콘 블록을 제안하는 것입니다. 구체적인 과정은 다음과 같습니다.
Proposer로 선정된 것을 알고 Inclusion List(IL, 즉 슬롯에 반드시 포함되어야 하는 트랜잭션)를 만들어 브로드캐스팅한다.
빌더는 실행 페이로드가 포함된 블록 해시와 제안자에게 제안자에게 지불할 의사가 있는 "SignedExecutionPayloadHeader" 약속을 보냅니다(실행 페이로드는 IL을 충족해야 함).
제안자는 이를 포함하기 위해 빌더가 보낸 "SignedExecutionPayloadHeader" 중 하나를 선택합니다(일반적으로 제안자에게 지불된 가격이 가장 높은 것). 그리고 제안된 비콘 블록 "SignedBeaconBlock"을 방송합니다.
증인은 증거 임무를 수행합니다
집계자는 동시에 증명 집계를 제출하고 빌더는 실행 페이로드를 브로드캐스트합니다.
PTC(Payload Timelies Committee, 각 슬롯마다 512명의 검증자를 PTC 회원으로 선정)는 Builder가 적시에 실행 페이로드를 공개하는지 확인하고 결과를 방송합니다.
ePBS 역시 제안 당시부터 EIP 번호를 최종적으로 획득하기까지 많은 논의를 거쳤습니다. PBS는 6월 21일 Vitalik에 의해 처음 제안되었습니다. 4개월 후 2슬롯 솔루션이 개선되었습니다. 또 3개월 후 PTC 아이디어가 공식적으로 제안된 것은 7월 23일이었습니다. .
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는 선불 메커니즘이기 때문입니다. 빌더가 초고수익 블록을 패키징하면 제안자에게 높은 금액을 제공할 수 없습니다. 선불 메커니즘.
