MEV-Share : 유저들을 위한 MEV 재분배 메커니즘

Key Takeaways

• MEV-Share는 MEV 파이프 라인에서 MEV 수익을 User에게 분배하고자 하는 프로토콜이다.

• User, Searcher, Builder 외에 Matchmaker라는 새로운 주체가 등장하며, Matchmaker는 트랜잭션의 전달, 최종 bundle 생성, User 트랜잭션의 보호 등의 역할을 수행한다.

• MEV-Share는 Matchmaker에 대한 지나친 의존도 및 MEV 보상의 구조적 문제 등 아직은 몇몇 한계들이 존재한다.

1. Introduction

올해 2월, Flashbots 포럼에 MEV (Maximal Extractable Value)를 재분배하는 새로운 디자인인 MEV-Share 가 처음 소개되었고, 3월에 있었던 ETH Denver 의 MEV 트랙에서도 다루어졌다. 본 글에서는 MEV-Share 를 쉽게 이해하기 위해 이전 MEV-Boost 와 비교되는 핵심적인 특징을 알아보고, 글에서 제시한 high-level 상에서의 작동 과정을 살펴본다. 그리고 MEV-Share와 관련한 여러 한계점들을 알아보고, 필자의 견해도 간략히 밝히고자 한다. 본 글을 잘 이해하기 위해서 MEV-Boost에 관한 사전 지식이 필요하며, MEV-Boost가 익숙하지 않은 분들은 “MEV-Boost: The Merge 이후 MEV의 탈중앙화 (by 100y)” 아티클을 읽고 오는 것을 추천한다.

2. MEV-Share란?

이더리움 네트워크에서 MEV 트랜잭션이 만들어지고 그 추출된 이익이 분배되기까지 다양한 주체들이 개입된다. 일반 사용자(User)들이 트랜잭션을 만들면 , Searcher들이 이 트랜잭션들과 자신이 만든 MEV 트랜잭션을 합쳐서 bundle로 만든다. Bundle이 Builder에게 전달되면, Builder는 bundle들과 다른 트랜잭션들을 종합해서 하나의 완전한 블록을 만들고, 이를 Proposer 에게 전달한다.

MEV-Boost와 MEV-Share는 이러한 다양한 주체들 사이에서 공정한 MEV 분배를 목적으로, 각 주체들 간의 상호작용을 정의한 프로토콜로 이해할 수 있다. MEV-Boost에서는 Validator와 Builder의 관계에 초점을 맞추어 서로 악의적인 행동을 하지 못하게 막는 목적이 강했다면, MEV-Share에서는 이와 더불어 Searcher와 User간의 관계에 관한 로직을 추가한 것으로 이해할 수 있다. MEV-Share는 MEV-Boost 와 별개의 프로토콜이 아닌, MEV-Boost를 한 단계 발전시키고자 하는 시도이다.

MEV-Share가 가지는 가장 큰 특징은 유저들에게 MEV를 재분배하는 데에 있다. 기존 MEV-boost 디자인에서는, 유저들의 트랜잭션을 가지고 Searcher들이 MEV 트랜잭션을 만들 때, 유저들에게 직접적인 보상이 돌아가지 않았다. MEV-Share에서는 이 MEV 수익의 일부를 유저들에게 돌려주자는 것이 가장 핵심이다.

예컨대, 한 유저가 Uniswap에서 대량의 ETH를 USDC로 스왑하는 트랜잭션을 만들었다고 해보자. 이 스왑 트랜잭션으로 인해 DEX들 사이의 ETH-USDC 풀 가격 차이가 발생하여, Searcher가 이를 보고, 한 유저의 스왑 트랜잭션 바로 뒤에 차익 트랜잭션을 넣은 bundle을 통해 1 ETH의 차익을 얻을 수 있다고 가정하자. MEV-Boost에서는 Searcher가 Builder에게 bid를 제시하여 Searcher와 Builder가 1 ETH 의 수익을 남겼다면, MEV-Share 상에서는 1 ETH 중 0.8 ETH 를 유저에게 다시 나누어 주게 된다 (유저에게 제공되는 80%라는 숫자는 그저 예시일 뿐이다). 여기에 깔린 기저의 생각은, 결국 블록체인 생태계의 사용량을 결정하는 것은 유저이고, 유저의 트랜잭션이 있어야만 MEV도 발생할 수 있기 때문에, 유저들에게 보상을 제공하고 이들을 보호해야 체인이 더 활성화될 수 있다는 것이다.

3. 동작 과정

MEV-Share는 User, Searcher, Builder 외에 Matchmaker라는 새로운 주체가 등장한다. Matchmaker는 악의적인 행동을 하지 않을 것으로 기대되는 신뢰 주체이고, User, Searcher, Builder 사이에서 트랜잭션의 전달, 최종 bundle 생성, User 트랜잭션의 보호 등의 역할을 한다. 이들 간의 상호작용은 아래 순서로 이루어지는 것이 일반적인데, 하나씩 살펴보도록 하자.

3.1 User → Matchmaker → Searcher

User가 자신의 트랜잭션을 Matchmaker에게 보내는데, Matchmaker는 Searcher들에게 User의 트랜잭션에 대한 정보 중 일부만을 공유한다. 예를 들어, 아래 json 형태와 같이 트랜잭션의 내용을 전부 공개하는 대신, 트랜잭션이 Uniswap V3 컨트랙트를 호출했고, ETH와 USDC 토큰을 거래한다는 정보만 선택해서 보내는 것이다.

이때 User는 직접 privacy preference를 지정하여 트랜잭션에서 공유되는 정보를 지정할 수 있다. 번거롭게 트랜잭션의 일부만을 가려서 Searcher에게 보여주는 이유는 유저의 트랜잭션을 보호하기 위해서이다. Searcher들이 만약 트랜잭션에 대한 모든 정보를 가지고 있다면, MEV-Share를 거치지 않고 따로 Builder 또는 Proposer에게 bundle을 전달하는 것이 가능해진다. 이 bundle을 블록에 담게 하면 Searcher가 추출한 MEV에 대해 User에게 보상을 지급하지 않아도 된다. 따라서, 유저의 트랜잭션들이 공개된 채로 MEV가 추출되는 것은 현재의 MEV-Boost 상에서와 같은 과정을 거치는 셈이다.

3.2 Searcher → MatchMaker

[Case 1] Searcher가 User의 트랜잭션을 정확히 알고 있을 때

Searcher들은 퍼블릭 멤풀에서 얻은 온전한 트랜잭션들과, Matchmaker로부터 받은 위와 같은 부분적인 트랜잭션들을 바탕으로, 추출 가능한 MEV 트랜잭션을 만들어서 다시 MatchMaker에게 보낸다. 만약 온전한 트랜잭션들로 MEV를 만들면 정확한 MEV bundle을 만들어서 Matchmaker에게 보내줄 수 있을 것이다. (Builder에게 직접 보내도 상관 없다.)

아래 json 데이터를 예시로 들면, 유저의 특정 트랜잭션인 “0xhash” 뒤에 Searcher 자신이 직접 만든 MEV 트랜잭션인 “0xf145bh0t5” 를 묶어서 “txs” 필드의 bundle로 지정한 후, Matchmaker 에게 보내게 된다.

[Case 2] Searcher가 User의 트랜잭션을 정확히 알고 있을 때

그러나 앞서 언급했듯이 Searcher 들은 User의 모든 트랜잭션에 대한 접근이 없다. 그래서 Searcher 가 MEV bundle을 만들 때, User의 트랜잭션들 중 자신이 원하는 특정한 조건을 만족하는 트랜잭션이 있다면 그걸 찾아 달라고 Matchmaker에게 요구해야한다. User의 트랜잭션을 모르는 상태이므로 bundle을 만들 때 User의 트랜잭션 부분을 비워서 bundle의 일부만을 (partial bundle) 전달할 수 밖에 없다.

아래 Searcher가 Matchmaker에게 보내는 json 데이터의 예시를 보자. bundle의 앞이 “” **로 되어있는 것은, 아래 조건에 맞는 트랜잭션이 있으면 이 위치에 넣어달라는 의미이다. hints 필드에 있는 데이터들이 Searcher가 요구하는 조건이다. User의 트랜잭션을 실행시켰을 때, “0x7a25”와 “0xd14b” 컨트랙트와 상호작용하고, “0x41000”이라는 이벤트 로그가 발생한 트랜잭션이면 “” 필드에 들어가야 한다는 것이다.

3.3 Matchmaker -> Builder

Matchmaker는 Searcher가 준 partial bundle을 받아서 Searcher가 원하는 조건에 맞는 트랜잭션이 있는지 검색한다. 그리고 최종적으로 bundle을 만드는데, 유저가 트랜잭션에 대한 보상을 일부 돌려받을 수 있게끔 Validity condition을 설정해준다. User가 받아야 할 보상을 Matchmaker 가 최종적으로 명시해주는 셈이다.

아래 예시의 validity condition에 따르면 Builder는 0xprivsender라는 user에게 1 ETH을 보내야 한다는 것이다. Builder 또한 신뢰주체로 가정해서 선의로 validity condition을 지켜 User에게 보내주게 된다. User는 이러한 과정을 통해 자신의 트랜잭션이 bundle에 섞여 MEV 가 창출되었을 때 그 일부를 보상받을 수 있다는 것이고, 이것이 MEV-Share가 나오게 된 주된 목적이다.

4. 한계점 및 의견

MEV-Share는 비교적 최근에 개념적으로 제시되었고 실제 구현체는 아직까지 초보적인 단계에서만 지원되고 있다. 이와 관련하여, 플래시봇의 MEV-Share 소개 글의 Further Discussion 부분에서 여러 가지 추가적인 고려사항들과 개선이 필요한 부분들에 대해 언급하고 있다. 이를 통해 필자가 생각하는 MEV-Share의 가장 큰 한계점들을 살펴보고, 아직 MEV-Share의 적용 가능성에 대해 부정적인 시각을 가지고 있는 이유를 밝히고자 한다.

4.1 Matchmaking에 대한 언급 거의 없음

동작과정에서 살펴보았듯이 Matchmaker가 Searcher가 준 Hint에 맞는 User들의 트랜잭션들을 찾아준다고 하였으나, 사실 Matchmaking이 어떻게 일어나는지에 대한 구체적인 설명이 거의 찾을 수 없었다.

먼저 Searcher가 MEV bundle을 만들어 Matchmaker에게 자신이 만든 bundle에 대한 bid를 제시해야 한다. 그러나, User 트랜잭션에 대한 정보를 일부만 가지고 있다면 온전한 bundle을 만들기가 힘들어질 것이다. 또한, Searcher 입장에서는 자신이 손해를 보는 상황을 원치 않기 때문에 제시하는 bid 에 대해 보수적일 수 밖에 없을 것이다. Searcher로 하여금 bundle을 부분적으로 만들어 제시하게 하는 것이 오히려 Searcher의 복잡성과 불확실성을 증가시키지 않을까라는 우려가 생긴다.

특정 조건에 맞는 트랜잭션들을 찾아달라고 Matchmaker에게 요구하는 것 또한 전체 효율성을 감소시킬 수 있다. 기존 MEV-boost 에서는 Searcher들이 bundle 전체를 모두 만들었다면, MEV-Share에서는 Searcher들이 특정 조건의 트랜잭션을 요구하고, Matchmaker가 모든 Searcher가 요구하는 조건에 해당하는 트랜잭션들이 있는지 하나하나 다 찾아봐야 하는 과정이 추가되기 때문이다. 유저 트랜잭션을 숨기기 위해 Matchmaker라는 신뢰 주체를 만들고, 이 전지전능한 Matchmaker에게 모든 작업을 떠넘기는 구조가 되는 것은 아닐지 고민해볼 필요가 있다.

4.2 Matchmaker에 대한 지나친 의존

Matchmaker는 User들의 모든 트랜잭션을 받아 Searcher들에게 일부만을 제공하고, Searcher들이 요구하는 조건의 트랜잭션들을 찾으며, bundle을 완성시켜 Builder에게 전달하는 중요한 역할을 한다. 유저들 트랜잭션의 보호라는 역할 뿐 아니라 MEV-Boost 상에서 Searcher들이 하는 역할을 거의 그대로 물려받기 때문에, 높은 연산능력이 요구될 것이다.

Builder라는 소수의 중앙화된 주체들이 존재하는 MEV-Boost에서, Matchmaker라는 또다른 중앙화된 주체를 만드는 것은 중앙화로 인한 또다른 공격 벡터들을 발생시킬 위험이 있다. Matchmaker가 악의적인 노드일 수 있다는 가능성을 배제시켜도 DoS 공격 등에 취약해질 수 있는데, 이에 대해 글에서 제시된 추후 해결책들이 그다지 완전해보이지는 않는다.

하나는 Searcher들에게 bundle 제출 비용을 받는 방법이고, 다른 하나는 Searcher들의 reputation을 관리하는 방법을 언급하고 있다. 전자의 방법을 적용하면 프로토콜이 한 번 더 복잡해질 것이고, Searcher의 참여 유인을 낮추며 제출받은 비용 운영까지도 고려의 대상이 된다. 후자의 방법이 가장 현실적으로 느껴지지만 이 또한 Matchmaker 의 운영 복잡성을 증가시키고, 하나의 Searcher 노드가 여러 노드를 통해 요청하는 Sybil Attack 의 우려가 있다.

초기 Matchmaker는 플래시봇에 의해 운영되고, 추후에 Matchmaker를 탈중앙화한다는 이야기가 있지만 이 또한 구체적인 방향에 대한 논의는 전혀 없는 상황이다.

4.3 User 에 대한 MEV 보상 방법의 구조적 문제

동작 과정을 보면 Matchmaker가 Validity condition을 지정하여, Builder가 User에게 MEV의 일부를 돌려준다고 하였다. 여기에 숨겨진 문제 중 하나는 Matchmaker가 어떤 User에게 보상을 해줘야 하는지에 대해 판단하기가 애매하다는 것이다. MEV bundle에 포함된 User 트랜잭션이 한 User로 부터 나왔고, Searcher는 누구인지 아는 상황이라면 MEV 분배가 상대적으로 간단하겠지만, 그렇지 않은 경우도 존재한다. User 여러 명이 포함된 bundle의 경우 어떤 User 에게 얼마나 많은 보상이 돌아가야 하는지를 정하는 것도 어려울 수 있다.

가장 문제인 것은, Searcher가 자신이 다른 User인 척을 하고 bundle에 자신의 트랜잭션을 포함시키는 경우 이를 구분해내기가 힘들다는 것이다. 만약 User 트랜잭션이 만들어내는 MEV가 굉장히 크다면, Searcher는 보상을 나누어 갖기 위해 자신이 User가 되는 트랜잭션을 bundle 안에 최대한 많이 넣어 보상의 일부를 빼앗아가는 전략을 취할 것이다. Matchmaker가 이를 찾아서 막는 것은 현실적으로 어려워 보인다.

5. 맺으며

본 글에서는 MEV-Boost 이후 다음 스텝으로 소개된 MEV-Share 프로토콜에 대해 살펴보았고, 현재 디자인의 한계점과 필자의 의견도 밝혔다. User 들에게 MEV 보상이 직접적으로 돌아가는 첫 시도라는 점에서 의의가 있으며 User 입장에서는 안 쓸 이유가 없는 프로토콜이라고 생각한다. 그러나, 아직까지는 현실적으로 Matchmaker에 대한 지나친 신뢰구조와 MEV 보상 방법의 어려움이 큰 한계점이라고 여겨진다. 이러한 문제들에 대한 MEV-Share의 현실적인 해결책이 나오고, 프로토콜이 앞으로 더 고도화될지 지켜봐야 할 것이다. 그러나, 해결책들이 단순히 새로운 규칙을 끊임없이 만들어내서 프로토콜을 복잡하게 하거나, 새로운 신뢰주체에 의존하는 방법이 아니어야 발전의 가능성이 더 커질 것이라 생각한다.

이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.