이더리움의 현재 컨센서스와 MEV 간의 상호 작용은 PoW에서 PoS로 전환된 그날부터 거슬러 올라가야 한다...
글: 티아, Techub News
MEV 문제를 해결하는 과정은 실질적으로 블록 공간 배분 규칙을 재정립하는 과정이다. MEV는 이제 낯설지 않은 개념이지만, 이더리움의 MEV 거버넌스 제안들이 구체적으로 무엇을 다루고 있는지 이해하려면 여전히 몇 가지 배경 지식이 필요하다. 본 기사에서는 이더리움이 PoS로 전환된 이후 제안된 PBS, ePBS, PEPC 등의 MEV 거버넌스 제안들을 정리하여 독자들에게 배경 정보를 제공하고자 한다.
PBS(Proposer-Builder Separation)
이더리움 머지 이전에는 Flashbots가 개발한 MEV-Geth를 통해 MEV 문제를 해결했다. MEV-Geth는 수정된 go-ethereum 클라이언트로, 핵심 아이디어는 마이너가 본연의 작업인 채굴에만 집중하고 MEV 경쟁에 참여하지 않도록 하여 잠재적인 리오더닝(reorg) 문제를 방지하는 것이다. MEV-Geth의 메커니즘은 매우 간단하며 시장 기반 솔루션이다. 즉, 마이너가 블록 생성 시 서치(Searcher)가 제출한 번들(bundle)의 수익 크기에 따라 선택할 수 있도록 하는 것이다. 이처럼 교묘한 시장 메커니즘을 통해 각 당사자는 이익을 얻는 동시에 일정한 제약도 받게 된다. 서치는 일부 수익을 마이너에게 분배해야 하지만, 그 대신 자신의 MEV 수익이 마이너에게 도난당하지 않을 안전성을 확보한다. 서치라는 주요 수익원이 묶이게 되면, 마이너들도 자연스럽게 MEV-Geth를 사용하게 되고, 그 메커니즘에 의해 추가로 제약받게 된다. MEV-Geth는 마이너들의 화이트리스트를 관리하며, 오직 화이트리스트에 등재된 마이너만이 서치의 번들을 수신할 수 있다. 마이너가 서치의 성과물을 도난하면 이를 화이트리스트에서 제외함으로써, 마이너가 서치의 MEV 수익을 탈취하는 것을 방지할 수 있다.
그러나 머지 이후 블록 생성 방식이 검증자 중에서 무작위로 선택된 프로포저(proposer)가 블록을 제안하는 방식으로 바뀌었기 때문에, 명성 기반의 제약 방식으로 프로포저의 MEV 탈취를 막는 것은 더 이상 불가능해졌다.
가능한 해결책 중 하나는 블록 내용을 검증자가 볼 수 없도록 하는 것이다. 이 아이디어를 한층 더 발전시킨 것이 바로 PBS(Proposer-Builder Separation, 제안-구성 분리)다. PBS는 프로포저 역할을 가진 검증자의 책임을 블록 구성(building)과 블록 제안(proposing)으로 더욱 세분화하여, 복잡하고 이익 다툼에 개입될 수 있는 블록 구성 권한을 빌더(builder)에게 외주한다. 이렇게 되면 프로포저의 업무는 단순해지며, 빌더가 제출한 블록의 수익 크기에 따라 블록을 선택하여 제안하는 것만으로 충분하다.
초기에는 이더리움이 머지를 진행하면서 PBS를 프로토콜 내부에 통합하려 했으나, 잠재적 복잡성 때문에 해당 계획이 보류되었고, 그 사이에 MEV-Boost가 PBS 영역에 진입할 기회를 얻었다. 현재 PBS는 Flashbots가 개발한 MEV-Boost를 통해 구현되고 있다. 빌더와 프로포저 외에도 중요한 역할을 하는 또 다른 주체가 있는데, 바로 리레이(relay)다. 빌더는 블록을 프로포저에게 직접 보내는 것이 아니라, 제3의 주체인 리레이를 통해 전달한다.
빌더가 반드시 프로포저에게 수수료를 지불할 것인지, 마지막에 반드시 프로포저에게 블록 내용을 공개하여 프로포저가 빈 블록을 제출함으로써 슬래싱되는 일이 없도록 할 것인지, 빌더가 제출한 블록이 신뢰로 체인에 반드시 포함될 것인지 등을 보장해야 하는 추가적인 문제가 존재한다. 이러한 빌더와 프로포저의 권익을 보호하는 문제들은 주로 리레이를 통해 해결된다.
빌더는 블록을 리레이에 보내고, 리레이는 각 블록이 가져오는 수익에 따라 순위를 매긴 후 가장 높은 수익을 내는 블록의 헤더를 프로포저에게 전송하여, 프로포저가 블록 내용을 알 수 없도록 한다. 프로포저가 블록 제안을 약속하기 위해(블록 헤더에 서명한 후), 리레이야 비로소 프로포저에게 완전한 블록을 공개한다. 빌더가 프로포저에게 지불하는 수수료 역시 리레이를 통해 안정적으로 처리된다. 프로포저에게 지급되는 거래는 제출된 블록에 포함되지만, 프로포저가 블록 내용을 볼 수 없기 때문에 리레이가 미리 확인해주는 과정이 필요하다.
In-protocol & Out-of-protocol
MEV-Boost 기반 시장에 참여하기 위해 검증자는 이더리움 컨센서스 클라이언트와 실행 클라이언트를 운영하는 동시에, 제3자 소속의 비(非)이더리움 프로그램인 MEV-Boost도 추가로 실행해야 한다. 이것이 현재 작동 중인 PBS의 특이한 점인데, 프로토콜 외부의 제3자가 이더리움 컨센서스 형성 규칙 설계에 참여하게 되는 것이다. 소유권의 관점에서 보면 이는 상상하기 어려운 일이다.
이는 또한 프로토콜 메커니즘의 '신뢰성(trustworthiness)'에 대한 고민을 자극한다. 신뢰성은 어떻게 강화되는가, 그리고 어떤 다른 메커니즘을 통해 오히려 약화되는가? MEV-Boost는 이에 대한 좋은 예시다. 외부 프로토콜이 기존 메커니즘을 변경할 가능성이 있기 때문이다. 프로토콜 자체가 느려지는 상황이 발생하면, 그러한 변경은 외부에서부터 시작될 수 있으며, 외부 메커니즘의 등장은 분명 당시의 시장 수요에 부합할 것이다. 그러나 외부 메커니즘이 정말로 신뢰할 수 있는지, 잠재적 문제를 방지하기 위한 철저한 설계를 거쳤는지, 심지어 프로토콜 자체를 파괴할 가능성은 없는지 등은 여전히 불확실하다.
중앙화된 리레이
MEV-Boost가 가장 많이 비판받는 부분은 중앙화된 리레이 시장이다. 이러한 구조는 신뢰 문제를 야기한다. 빌더는 리레이가 자신의 MEV를 훔치지 않을 것이라고 믿어야 하며, 프로포저 역시 리레이로부터 수신하고 서명한 블록 헤더가 유효하다고 믿어야 한다. 그러나 중요한 역할을 수행함에도 불구하고 리레이는 어떠한 경제적 인센티브도 받지 않으며, 리레이 운영에는 상당한 비용이 소요된다. 작년에는 11개의 리레이가 이더리움 네트워크를 지원했지만, 현재는 9개만이 서비스를 제공하고 있다.
특히 주목할 점은 리레이가 사실상 진입 장벽이 있다는 것이다. Eden과 같은 리레이는 자신만의 빌더만을 중계하며, bloXroute와 같은 리레이는 프론트런 및 삼각거래(Sandwich Attack) 관련 거래를 필터링한다고 주장하기도 한다. 어느 정도로 보면, 리레이는 일정한 규칙 설정 권한도 가지고 있다고 볼 수 있다.
데이터 출처: Rated Network
또한 생존성(liveness) 측면에서, 리레이가 존재함으로써 빌더와 프로포저 사이에 원자성(atomicity) 수준의 보장을 제공할 수 없다. 만약 프로포저가 블록 헤더에 커밋먼트(commitment)를 서명하고, 빌더가 페이로드(payload) 내용을 제공했음에도 불구하고 리레이의 실수(악의적이든 비악의적이든)로 인해 내용이 제때 제출되지 못하면, 빌더와 프로포저 모두 손해를 입게 된다.
ePBS: PBS를 이더리움 프로토콜 내부에 통합
리레이의 중앙화 문제를 해결하거나, 외부 메커니즘을 프로토콜 내부로 옮기려는 목적에서, PBS를 이더리움에 내장하는 ePBS는 거의 필수적인 선택지로 여겨지고 있다. 현재 ePBS는 더 이상 논의 단계를 넘어섰으며, 이더리움 EIP 편집자가 이미 EIP-7732라는 번호를 할당했다.
ePBS는 프로포저와 빌더가 블록 구성 권한을 외주할 수 있는 신뢰할 필요 없는 인프라를 제공한다. 기존에 프로토콜 외부에 있던 빌더의 역할이 프로토콜 내부로 들어오며, 검증자 내에서 별도의 빌더 역할이 추가된다. 빌더로서의 검증자 역시 이더리움에 스테이킹을 해야 한다. 기존 컨센서스 레이어의 프로포저 책임을 분리하기 때문에, ePBS를 구현하려면 컨센서스 레이어의 수정이 필요하다. 여기서 빌더는 execution payload(블록 내에서 실행될 거래의 최종 목록)를 구성하는 책임을 진다. 프로포저의 책임은 신뢰로 블록을 제안하는 것이다. 구체적인 절차는 다음과 같다:
-
프로포저로 선정된 후 Inclusion List(IL, 해당 슬롯에 반드시 포함되어야 할 거래 목록)를 작성하고 브로드캐스트한다.
-
빌더들은 execution payload를 포함한 블록 해시와 프로포저에게 지불할 수수료 약속인 'SignedExecutionPayloadHeader'를 프로포저에게 전송한다(execution payload는 IL을 만족해야 함).
-
프로포저는 빌더들로부터 받은 'SignedExecutionPayloadHeader' 중 하나를 선택해 포함시키고(일반적으로 프로포저에게 가장 많은 수수료를 주는 것을 선택), 신뢰로 블록 'SignedBeaconBlock'을 브로드캐스트한다.
-
검증자들이 검증(witness) 의무를 수행한다.
-
애그리게이터(aggregators)가 attestation aggregates를 제출하고, 동시에 빌더가 execution payload를 브로드캐스트한다.
-
PTC(Payload Timeliness Committee, 각 슬롯마다 512명의 검증자가 PTC 멤버로 선정됨)가 빌더가 execution payload를 제시간에 공개했는지 확인하고 그 결과를 브로드캐스트한다.
ePBS는 처음 제안된 후 EIP 번호를 받기까지 여러 차례 논의를 거쳤다. 초기에 빌털릭(Vitalik)이 2021년 6월 PBS를 제안했고, 4개월 후 Two-slot 방식을 완성하였으며, 3개월 후 Single-slot PBS를 발표하였다. 그리고 2023년 7월에 이르러서야 PTC 아이디어가 공식적으로 제안되었다.
PEPC(Protocol-Enforced Proposer Commitments)
물론 ePBS에 반대하며 다른 대안을 제시하는 입장도 있다. PEPC가 바로 그런 대안이다. ePBS는 특정 규칙을 프로토콜에 고정하는 방식이라면, PEPC는 프로포저가 프로그래밍 가능한 블록 구성 권한을 판매한다는 점에서 다르다.
PEPC는 barnabe가 2022년 10월에 제안했다. barnabe는 PBS 메커니즘을 프로토콜 내에 구현할 경우, 특정한 신뢰 신호(예: 내가 블록을 구성하면 당신에게 xx ETH를 돌려주겠다)를 구현하는 것이 아니라, 신뢰 신호 전달을 위한 일반적인 메커니즘을 구현해야 한다고 주장한다.
PEPC(Protocol-Enforced Proposer Commitments)라는 이름에서 알 수 있듯이, 빌더와 프로포저의 권익을 보장하는 메커니즘은 프로토콜 내에서 프로포저가 제출하는 커밋먼트(commitment)를 통해 이루어진다. 이러한 커밋먼트는 체인 상에서 검증 가능하며, 주로 'BEACONROOT' 오퍼코드(opcode)를 통해 구현된다. 이것은 보다 일반적인 메커니즘으로, 커밋먼트는 블록 구성 권한 전체를 외주하는 것도, 일부만 외주하는 것도 가능하다. 즉, 프로포저가 판매하는 것은 프로그래밍 가능한 블록 구성 권한이다.
요약
이상으로 PBS, ePBS, PEPC에 대한 간략한 소개를 마친다. 프로토콜 설계 측면에서 보면, 단순히 MEV를 재분배하는 시장 메커니즘을 설계하는 것뿐 아니라, 검증자를 더욱 탈중앙화하고 검열 저항성을 높이는 방법도 함께 고려해야 한다. 또한 프로토콜 설계에는 많은 균형 타협이 존재한다. 이미 EIP 번호를 부여받은 ePBS를 예로 들면, ePBS 설계는 중앙화된 리레이 문제를 해결하지만, 프로토콜 외부의 제3자 리레이라는 핵심 역할이 정말로 부정적인 영향만 있었을까? 빌더의 지불 메커니즘을 예로 들면, 리레이를 사용하는 것이 ePBS보다 오히려 유리하다. ePBS는 선불제 메커니즘인데, 빌더가 매우 높은 수익을 내는 블록을 구성했을 때, 선불제 구조상 프로포저에게 높은 보상을 제공할 수 없기 때문이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@News_Techub
