[Xangle Digest]

※해당 컨텐츠는 지난 2월 10일 외부에서 기발간 된 컨텐츠입니다. 컨텐츠에 대한 추가적인 주의사항은 본문 하단에서 확인해주세요.

목차

1. 들어가며

2. MEV-Boost

 2.1. 개요

 2.2. 문제점

3. 검열

 3.1. OFAC의 제재

 3.2. 프로토콜 단에서의 검열

 3.3. MEV-Boost 단에서의 검열

4. 검열 방지

 4.1 밸리데이터 관점

 4.2 프로토콜 관점

5. 마치며

1. 들어가며

이 글의 전편에서 MEV에 대한 기본 개념과, 이더리움이 작업증명 방식을 사용할 때 MEV로 인해 발생하는 부정적인 외부 효과를 어떻게 감소시키는지 플래시봇의 MEV 경매 방식을 통해 알아보았다. 2022년 9월 15일, 머지 업그레이드가 활성화되며 이제 이더리움 네트워크는 작업증명이 아닌 지분증명 방식을 사용하게 되었다. 합의 알고리즘이 바뀌면서, MEV의 탈중앙화를 위한 새로운 방법이 필요해졌으며, 새로운 방법으로 인해 네트워크에서의 검열 문제도 불거졌는데, 본 글에선 이들에 대해 자세히 살펴보려고 한다.

기존 작업증명 이더리움 네트워크에서 사용하던 MEV 경매 방식에서는 검열이 큰 문제가 되지 않았다. 채굴자는 Searcher들로부터 완전한 블록이 아닌, 트랜잭션 몇 개가 묶여있는 번들을 받고, 이를 블록에 포함하는 형태였기 때문에, 만약 Searcher 및 릴레이가 검열을 진행해서 번들을 보내주어도, 채굴자 자신이 받은 번들에 더해서 검열된 트랜잭션까지 포함시켜 완전한 블록을 만들 수 있었기 때문이다.

하지만, 이 방식을 지분증명으로 전환된 이더리움 네트워크에 적용하려하니 문제가 생겼다. 기존 MEV 경매 방식에선 Searcher 및 릴레이가 채굴자를 신뢰해야만 했다. 왜냐하면 Searcher가 릴레이를 통해 트랜잭션 번들을 채굴자에게 보내면, 채굴자는 이를 그대로 자신이 만들 블록에 포함시키는 것이 아니라 트랜잭션을 까보고 이를 그대로 복사 붙혀넣기 하여 자신이 MEV를 추출한 것 마냥 MEV를 훔칠 수 있었기 때문이다. 따라서 이를 막기 위해 플래시봇에선 MEV-Geth를 사용하는 채굴자를 화이트리스팅을 하여서, 채굴자가 악의적인 행동을 하지 못하도록 방지했다.

이러한 신뢰 관계 및 화이트리스팅 제도는 지분증명 이더리움 네트워크에 적용할 수 없었다. 어느정도 이름이 알려져있고 물리적 기반을 가지고 있는 채굴자들과 달리, 지분증명 이더리움 네트워크의 밸리데이터는 수십만개가 존재하며, 익명으로 운영이 가능하기 때문에 화이트리스팅을 진행할 수 없는 것이었다. 화이트리스팅 제도 없이 그대로 MEV 경매 방식을 지분증명 이더리움 네트워크에서 사용하게 된다면, MEV를 훔치는 것과 같은 악의적인 행동이 매우 빈번하게 일어날 수 있으며, 이를 막을 방법이 없었던 것이다.

2. MEV-Boost

2.1 개요

이러한 문제에 대응하기 위해 플래시봇 팀은 지분증명 이더리움 네트워크에서 MEV를 효과적으로 탈중앙화시킬 수 있는 MEV-Boost라는 새로운 시스템을 선보였다. MEV-Boost는 Searcher와 릴레이 사이에 블록 빌더라는 새로운 역할군을 추가했다. 블록 빌더는 Searcher로부터 트랜잭션 번들을 받고, 여러 번들과 다음 편에서 자세히 살펴볼 ‘프라이빗 오더 플로우’를 통해 받은 트랜잭션을 묶어서 완전한 블록을 만들어 이를 릴레이를 통해 프로포저(밸리데이터)에게 보낸다.

MEV-Boost가 작동하는 모식도는 위의 그림과 같으며, 자세한 과정은 다음과 같다:

1. 블록 빌더는 Searcher 및 프라이빗 오더 플로우를 통해 트랜잭션을 받고, 이를 자체 MEV 추출 알고리즘을 통해 가장 수익성이 좋도록 트랜잭션을 재 정렬하여 하나의 완전한 블록을 만들고, 이에 대한 bid를 붙여서 릴레이에게 전달한다.
2. 릴레이는 빌더들로부터 받은 블록들이 타당한지 검증하고, 블록을 저장한다.
3. 릴레이는 블록의 헤더들을 bid와 함께 프로포저에게 전달한다.
4. 프로포저는 릴레이로부터 받는 블록 헤더들 중 가장 높은 bid를 가지고 있는 블록 헤더를 선택하고, 이에 대해 서명한다.
5. 서명된 헤더를 받은 릴레이는 그 헤더에 해당하는 블록 내용 전부를 프로포저에게 공개한다.
6. 프로포저는 릴레이로부터 받은 완전한 블록을 네트워크에 제출하고, 블록 빌더가 그 블록에 붙힌 bid를 수령한다.

MEV-Boost는 MEV-Geth와 같은 클라이언트가 아닌, 기존 모든 클라이언트에 호환되는 미들웨어로 밸리데이터들은 누구나 MEV-Boost를 설치하여 MEV-Boost내에 프로포저로 활동할 수 있다. MEV-Boost를 사용하면, MEV 추출에 특화된 블록 빌더들이 MEV를 가장 수익성 좋게 추출하고, 이들이 자신들의 블록이 네트워크에 추가될 수 있도록 자유 경쟁 시장에서 경쟁을 하며 자신들이 추출한 MEV에 거의 비슷한 수준의 bid를 붙혀서, 릴레이를 통해 프로포저에게 블록을 전달하기 때문에 MEV 추출에 대해서 하나도 모르는 프로포저도 bid를 분배 받음으로써 MEV 수익을 간접적으로 얻을 수 있다. 즉, MEV 수익이 네트워크 전체적으로 탈중앙화되는 것이다. 실제로 MEV 보상은 블록 보상 중 가스비와 비교하여 유의미한 비율을 차지하고 있기 때문에 이를 탈중앙화시키는 것이 매우 중요하다고 할 수 있다.

개인 밸리데이터도 MEV-Boost를 사용하면 블록 보상, 트랜잭션 수수료 보상에 더해 MEV 수익까지 분배 받기 때문에, ETH 스테이킹에 대한 연이율이 높아짐에 따라 많은 밸리데이터들이 MEV-Boost를 도입하기 시작했다. 2022년 11월 21일 기준, 이더리움 네트워크의 밸리데이터 중 MEV-Boost의 사용율은 현재 거의 90%에 육박할 정도로 많이 사용되고 있다. 현재 릴레이는 총 10개가 존재하며, 지금까지 각 릴레이를 통해 전달된 블록의 개수와 블록당 평균 bid의 가치는 아래와 같다.

다양한 릴레이들의 차이점은 뭘까? 아래는 Ethstaker에서 정리한 10개의 릴레이 간 차이점 표이다. 첫 번째로 릴레이가 특정 트랜잭션을 필터링하거나, 검열하거나, 특정 기관의 규제에 준수하는지에 대한 여부에 따라 분류할 수 있다. Aestus, Agnostic Gnosis, bloXroute Max profit, Manifold, Ultra Sound 총 5개의 릴레이는 아무런 필터링을 하지 않으며, bloXroute Ethical은 프론트러닝 및 샌드위치 공격과 같은 악의적인 MEV 추출을 필터링, Blocknative, bloXroute Regulated, Eden Network, Flashbots는 OFAC 규제에 준수하는 것을 볼 수 있다. 이는 두 번째, MEV 전략과 도덕적인 규칙에 많은 영향을 주는데, 기본적으로 OFAC 규제에 준수하는 릴레이들은 관련 트랜잭션을 제외한 후 최대로 MEV를 추출하려는 모습을 보이고 있다. 또한, 눈 여겨 볼만한 점은 각 릴레이마다 빌더 및 searcher들에게 오픈되어 있는 정도가 다르다는 것이다. 모두에게 퍼블릭하고 퍼미션리스하게 열려있는 릴레이가 있는 반면, Blocknative와 같이 내부 빌더의 블록만 받아서 전달해주는 릴레이도 존재한다.

각종 통계를 통해 Flashbots 릴레이의 점유율이 매우 높은 것을 확인할 수 있는데, 이더리움 리퀴드 스테이킹 프로토콜인 라이도같은 경우 화이트리스팅된 릴레이를 강조하기 때문이기도 하고, 또 다른 이유로는 수익성과도 연관이 있다. 아래 차트를 확인하면 지금까지 Flashbots 릴레이를 통해 넘어오는 블록의 평균 MEV 보상은 0.14 ETH, 중간값은 0.052 ETH인데 반해서 그 외의 릴레이를 사용할 경우 평균 MEV 보상은 0.067 ETH, 중간값은 0.03 ETH이다. 이는 빌더들마다 MEV를 추출하는 알고리즘이 다르고, 릴레이마다 연결되어있는 빌더의 종류가 다르기 때문이다. 결국 많은 프로포저들이 더 큰 수익을 얻기 위해 Flashbots 릴레이에 연결을 많이 하려고 하기 때문에 릴레이 중앙화 문제가 발생하는 것이다. 릴레이에 대한 문제는 아래에서 더 자세히 살펴볼 예정이다.

그럼에도 불구하고 긍정적인 점은 시간이 지날수록 Flashbots 릴레이와 그 외의 릴레이들이 전달하는 블록의 MEV 보상이 평준화되고 있다는 것이다. 아래 그래프를 보면 둘의 격차가 점차 줄어드는 것을 확인할 수 있다. 이는 최근 11월, Flashbots에서 블록 빌더의 알고리즘을 오픈소스화 한 영향이 크다고 생각된다.

Flashbots 팀이 빌더를 오픈소스화 한 후, 실제로 빌더는 릴레이에 비해서 굉장히 탈중앙화된 모습을 띠고 있는 것을 확인할 수 있다. 아래 그림의 왼쪽은 빌더, 오른쪽은 릴레이를 뜻하며 어떠한 빌더와 어떠한 릴레이가 서로 연결되어있는지 나타내고 있다. (참고로 재미있는 것은 위에서 Blocknative는 내부 빌더와만 연결되어있다고 했는데, 실제로 그림에서 봤을 때 Blocknative 릴레이는 Blocknative 빌더의 블록만 중개하는 것을 볼 수 있다.)

공개된 빌더의 문서를 보면 빌더는 아래와 같이 작동한다. 빌더가 되기 위해선 우선 수정된 버전의 컨센서스 클라이언트가 필요하며, 프리즘 포크를 수정한 버전을 사용할 수 있다. 빌더엔 크게 릴레이와 커뮤니케이팅을 담당하는 ./builder부분과 블록을 빌딩하는 ./miner부분으로 구성되어있다. 빌더의 시작은 컨센서스 클라이언트가 onPayloadAttributes를 호출하는 것으로부터 시작하여, 릴레이로부터 밸리데이터 데이터를 요청한 후 runBuildingJob을 통해 빌딩을 시작한다. 마이너(worker.go)는 실제로 블록 구성을 담당하며, 구체적인 과정은 builder의 요청이 worker.go로 라우팅되고 generatework가 블록을 구성하는 역할을 한다. 트랜잭션은 Searchers들로 부터 받은 번들을 받아 fillTransactionsAlgoWorker\fillTransactions 에서 빌더의 알고리즘에 따라 트랜잭션의 삽입이 이루어진다. 이렇게 생성된 블록은 마지막에 릴레이에게 전달된다.

2.2 문제점

MEV-Boost가 이렇게 좋은 서비스임에도 불구하고 여전히 각 주체들에 있어서 몇몇 관계에 있어서 신뢰가 필요하다는 문제가 남아있다. 첫 번째로 Searcher는 여전히 블록 빌더를 신뢰해야 한다는 것이다. 블록 빌더는 Searcher로부터 받은 트랜잭션 번들을 볼 수 있기 때문에 MEV를 훔칠 수 있는 것인데, 이로 인해 Searcher는 블록 빌더를 선택하는 것에 있어 딜레마에 빠지게 된다. 자신의 번들이 블록에 포함될 확률을 높이기 위해서, 번들을 많은 수의 빌더들에게 보내자니 그만큼 자신의 MEV가 도난당할 위험이 커지며, 반대로 MEV 도난의 확률을 줄이기 위해 번들을 소수의 블록 빌더에게만 보내자니, 자신의 번들이 이더리움 네트워크 블록에 추가될 확률이 줄어드는 것이다. 그럼에도 불구하고, 만약 MEV-Boost가 없었다면 Searcher는 수십만 명의 프로포저를 신뢰했어야 했으므로, MEV-Boost로 인해 100명 이하의 블록 빌더들을 신뢰해야하는 현재의 상황은 매우 긍정적인 변화라고 볼 수 있다.

두 번째로 여전히 블록을 중개하는 중앙화된 릴레이라는 역할군의 존재로 인해서, 릴레이에 대한 신뢰가 필요하다는 문제점이 남아있다. 블록 빌더는 릴레이를 신뢰해야 하는데, 릴레이가 블록 빌더로부터 받은 블록의 내용물을 보고 자신이 똑같은 블록을 만들어서 MEV를 훔칠 수도 있으며, 악의적으로 특정 빌더의 블록에 대한 검열을 진행할 수도 있기 때문이다. 마찬가지로 프로포저도 릴레이를 신뢰해야하는데, 릴레이가 일부로 수익성이 낮은 블록만 중개해준다거나, 서명한 블록 헤더에 대한 블록 바디를 일부러 공개하지 않는 등의 악의적인 행위을 할 수 있기 때문이다. 또한, 릴레이가 오작동하는 경우도 있을 수 있기 때문에 프로포저와 블록 빌더는 릴레이에 전적으로 의존하는 꼴이 된다. 물론, 이더리움 로드맵에 있는 PBS가 도입된다면, 빌더가 블록을 프로포저에게 공개하지 않는 등 악의적인 행동을 하여도, 무조건 프로포저는 서명한 블록 헤더에 대한 bid를 수령받을 수 있게 하는 시스템을 프로토콜에 내재함으로써 릴레이 역할군을 아예 없애버릴 수 있지만, PBS가 언제 도입될지 모르는 현재의 상황에선 릴레이에 대한 신뢰 필요의 문제를 다룰 필요가 있다. 아래와 같이 릴레이의 점유율은 Flashbots가 지속적으로 우위를 가지고 있는 것을 볼 수 있다.

위에서 Flashbots 릴레이가 그 동안 점유율이 높았던 이유 중 하나로 평균 MEV 수익이 높았다는 것을 알아봤다. 그 외에도 한 가지 이유가 더 있는데 바로 릴레이의 안정성이다. 릴레이는 결국 빌더와 프로포저를 이어주는 중개인이며, 사람 및 기업이 운영하는 주체이기 때문에, 갑자기 릴레이의 작동이 멈추거나, 릴레이가 악의적으로 행동할 수 있는 가능성이 있다.

릴레이의 작동이 멈추면 어떤 일이 발생할까? 릴레이의 역할은 결국 두 가지로 1) 프로포저에게 블록헤더와 bid를 제공해주고, 2) 프로포저가 블록헤더에 서명을 하면 블록 전체 내용을 공개한다. 1번 과정에서 릴레이가 멈출 경우 프로포저는 다른 릴레이로부터 블록을 받아서 블록을 제출하거나, 아예 자체적으로 블록을 만들어서 제출할 수 있다. 만약 작동을 멈춘 릴레이가 평균 MEV 수익이 가장 높은 릴레이라고 가정한다면, 여기서 프로포저가 입는 손실은 다른 릴레이로부터 블록을 받거나, 블록을 자체적으로 만들어서 제출했음으로부터 오는, 다소 낮은 MEV 수익밖에 추출해지 못했다는 점이다. 사실 이는 그리 큰 문제는 아니며, 2번 과정에서 릴레이가 멈출 경우는 더 큰 손실을 초래한다.

만약 프로포저가 1번 과정에서 정상적으로 릴레이로부터 블록 헤더를 받고 서명까지 다 했는데, 이제 2번 과정인 블록 전체 내용을 받아야하는 시점에서 릴레이가 작동을 멈췄다고 가정하자. 프로포저는 블록 전체 내용을 받지 못하기 때문에, 네트워크에 블록을 제출할 수 없게 된다. 또한, 다른 릴레이로부터 블록을 받거나, 자체적으로 블록을 빌딩할 수도 없는 것이, 이미 블록헤더에 서명한 상태에서 다른 블록을 제출할 경우 이중 서명으로 인해 슬래싱을 당할 수 있기 때문에, 이 경우 프로포저는 자신의 차례에 아무런 블록을 제출하지 못한다. 블록을 놓칠 경우 블록 보상, 트랜잭션 수수료 보상, MEV 보상을 모두 놓치기 때문에 이는 큰 문제라고 할 수 있다. 실제로 bloXroute 릴레이가 수 시간동안 오작동하여 이러한 사태가 발생한적이 있으며, 88명의 프로포저가 자신의 슬롯(블록을 제출할 차례)에 블록을 제출하지 못하고 보상을 놓쳤다고 한다. 릴레이 오작동 외에 악의적인 릴레이에서도 비슷한 문제점들이 나오고 있고, 이에 대한 해결법으로 릴레이 모니터라는 것이 논의되고 있다.

세 번째로 요즘 가장 화제가 되고 있는 이슈이기도 한 검열의 문제가 발생했다. 블록을 생성하는 프로포저는 기존 트랜잭션 번들만 받을 수 있었던 MEV 경매 방식과 달리, 이제 릴레이를 통해서 완전한 블록밖에 받을 수 없게 되었다. 따라서 만약 프로포저가 뒤에서 살펴볼 OFAC 제재를 따르는 빌더, 릴레이로부터 블록을 받게 된다면, 프로포저는 검열된 블록을 이더리움 네트워크에 제출하는 것 말고는 딱히 큰 선택지가 없다. 기존 작업증명 이더리움 네트워크의 MEV 경매 방식에서는 채굴자가 번들에 더해서 원하는 트랜잭션을 함께 포함시켜 블록을 만들 수 있었기 때문에 검열에서 자유로웠던 반면, 지분증명 네트워크에서 MEV-Boost를 사용하는 프로포저는 검열에 자유로울 수 없게 된 것이다. 이에 대해선 다음 파트에서 자세히 살펴볼 것이다.

3. 검열

3.1 OFAC의 제재

22년 8월, 토네이도 캐시가 북한의 자금 세탁과 연루되어있다고 판단되자 미국 재무부의 부서 중 하나인 OFAC(Office of Foreign Asset Control)은 토네이도 캐시 및 연관된 56개의 이더리움 주소들을 제재 리스트에 올렸다. 이에 따라 노드 API 제공 업체인 인퓨라(Infura)와 알케미(Alchemy)는 토네이도 캐시의 프론트엔드에서의 API 접근을 중단시켰으며, 깃헙(Github)에선 토네이도 캐시의 레포지토리와 관련 컨트리뷰터를 정지시키고, dYdX와 같은 탈중앙 거래소에서도 관련 계정들을 정지시키는 등 검열에 대한 우려가 수면 위로 떠오르기 시작했다.

3.2 프로토콜 단에서의 검열

이러한 우려덕에 프로토콜 단에서의 검열 문제도 관심을 받게 되었는데, 이더리움 밸리데이터들은 블록을 만들 권한을 가지고 있기 때문에, 특정 트랜잭션에 대해서 검열을 할 수 있는 권한도 가지길 마련인데, 이더리움 코어 개발자 미팅 #145에서 비탈릭 부테린이 말하길 프로토콜 단에는 두 가지 종류의 검열이 발생할 수 있다고 했다.

첫 번째로는 ‘약한 검열(Weak censorship)’으로 일부 밸리데이터들이 단순히 특정 트랜잭션들을 블록에 포함시키지 않는 것이다. 하지만, 이는 전체 네트워크 수준에서 큰 위기는 아닌 것이, 만약 특정 트랜잭션이 검열을 단행하는 밸리데이터들로 인해 몇 번 블록에 포함되지 않는다 해도, 검열을 진행하지 않는 밸리데이터의 블록 생성 순서가 온다면 그 트랜잭션은 결국 블록에 포함될 예정이기 때문이다. 즉, 검열을 당하는 사용자 입장에서는 자신의 트랜잭션이 블록에 포함되는 시간이 지연될 뿐이지, 영구적인 문제는 아닌 것이다.

두 번째로는 ‘강한 검열(Strong censorship)’으로 아예 트랜잭션이 영구적으로 이더리움 네트워크에 포함되지 않을 수 있는 경우가 있다. 이더리움 네트워크의 개스퍼 합의 알고리즘을 살펴보게 되면, 메인 체인(Canonical chain)을 결정하는 LMD GHOST 합의 알고리즘이 있는데, 블록을 생성하지 않는 밸리데이터들도 블록에 대한 투표(attestation)을 진행하게 된다. 투표를 더 많이 받은 블록이 포함된 체인으로 메인 체인이 결정되게 되는데, 만약 51% 이상의 밸리데이터가 검열을 위해 특정 트랜잭션이 포함된 블록에 투표를 하지 않음으로써 악의적으로 거부하게 되면, 그 트랜잭션은 영영 네트워크에 포함될 수 없는 결과가 발생한다.

강한 검열은 블록체인의 검열 저항성에 완전히 위배되는 현상으로, 해결할 필요성이 있는데, 이는 두 가지 방법으로 해결할 수 있다. 첫 번째는 minority soft fork이다. 소수의 정직한 밸리데이터들이 공격자의 체인이 검열되고 있다는 사실에 합의 한 후에 이들은 공격자의 체인에 블록을 만드는 것이 아닌 자신들의 체인을 꾸준히 이어나가는 것이다. 개스퍼 알고리즘엔 투표가 제대로 진행되지 않아 체인이 완결되지 않는 상태가 유지된다면 Inactivity Leak이라는 비상 상태가 활성화되는데, 투표를 진행하지 않는 밸리데이터들의 토큰을 빠른 속도로 슬래싱 하여 투표를 진행하는 밸리데이터들이 전체의 2/3 이상이 되도록 한다. Minority soft fork에는 공격자들이 attestation을 진행하지 않으므로 이들의 토큰은 inactivity leak 메커니즘에 의해 빠르게 슬래싱되고, 이로 인해 minority soft fork에선 강한 검열을 진행하는 악의적인 밸리데이터들의 영향력이 줄어들고, 강한 검열을 방지할 수 있게 된다.

두 번째로는 사회적 합의(Social consensus)에 의한 슬래싱이다. 이는 프로토콜 규칙에 의해 프로그래밍 되어 있진 않지만, 사회적인 합의를 통해 어떠한 밸리데이터가 검열에 참여하는지 알 수 있고, 그들의 스테이킹 물량을 임의로 슬래싱하여 더 이상 검열을 진행할 수 없도록 하는 것이다. 이는 검열을 진행하는 밸리데이터가 스테이킹한 ETH를 임의로 슬래싱하는 것이기 때문에 일종의 하드포크이다.

3.3 MEV-Boost 단에서의 검열

다행인 것은 이더리움 프로토콜 단에서의 검열은 OFAC에 의해 강제되지 않았다는 것이다. 그렇다면 도대체 뭐가 문제인 것일까? 바로 위에서 살펴보았듯이 MEV-Boost의 릴레이 역할군에서 검열이 발생하고 있는 것이다. 모든 릴레이가 규제에 따라야 하는 것은 아니지만, 미국의 관할 내에 있는 MEV-Boost의 릴레이들은 OFAC의 규제를 따라야한다. 가장 대표적인 릴레이로는 플래시봇 팀에서 운영하는 Flashbots 릴레이가 있으며, 이 릴레이가 MEV-Boost에서 점유하는 비율이 73.74%나 되기 때문에 큰 문제가 되고 있다. MEV Watch에서 실시간으로 이더리움 네트워크의 어느 정도의 블록이 MEV-Boost를 사용하여 만들어지며, 그 중에서도 검열을 진행하는 릴레이로부터 어느 정도의 블록이 만들어지는지 보여주는데, 22년 11월 16일 기준 총 73.58%의 블록이 검열을 진행하는 릴레이로부터, 15.24%의 블록이 검열을 진행하지 않는 릴레이로부터, 나머지 11.19%의 블록은 MEV-Boost를 사용하지 않고 생성된다.

이말은 즉슨, 한 사용자가 토네이도 캐시와 관련된 트랜잭션을 전송하면 바로 네트워크에 포함되는 것이 아닌, 기존보다 100/(100–73.58) = 3.78 배 느리게 포함되는 약한 검열이 이미 진행되고 있는 것이다. 트랜잭션이 영구적으로 포함되지 않는 강한 검열은 아니기 때문에 괜찮게 들릴 수도 있지만, 우려되는 점은 점점 검열을 진행하는 릴레이로부터 만들어지는 블록의 비율이 높아지고 있다는 것이다. 만약 검열을 진행하는 릴레이가 90%를 차지한다면 트랜잭션은 10배, 99%를 차지한다면 100배 느리게 포함될 수 있는 것이고, 이는 상당한 불편함을 야기할 것이다.

4. 검열 방지

현재 실제로 발생하고 있는 MEV-Boost의 릴레이단에서의 검열을 방지하기 위해 이더리움 커뮤니티에서는 다양한 의견들이 오고가고 있다. 이에 대해서 Jon Charbonneau가 잘 정리한 아티클이 있는데, 이 글을 중심으로 하나씩 살펴보도록 하려고 한다.

4.1 밸리데이터 관점

밸리데이터가 MEV-Boost 자체를 아예 사용하지 않는 것도 하나의 방법이 될 수도 있다. 애초에 현재 검열의 원인이 MEV-Boost에서 도입한 릴레이라는 신뢰 주체로부터 오는 것이니, 이를 아예 사용하지 않는 것이다. 하지만 MEV-Boost를 사용하면 MEV를 추출하는 알고리즘이 없는 밸리데이터도 MEV 수익을 분배받을 수 있으므로, 이는 밸리데이터의 이타심에 기대하는 행동이기 때문에 근본적인 해결책이 될 수 없다.

그렇다면 밸리데이터가 MEV-Boost를 사용하되, 검열을 진행하지 않는 릴레이로부터 블록을 받는 방법이 있다. MEV-Boost에서 릴레이 서비스를 제공하는 릴레이가 굉장히 다양하게 있는데, 검열을 진행하는 릴레이(Flashbots, Eden Network, Blocknative, BloXroute Regulated)외의 다른 릴레이(BloXroute Max Profit, BloXroute Ethical, Relayooor, Manifold, Aestus, Agnostic Gnosis)를 사용하는 방법이 있다. 하지만 이것도 어느정도 이타심에 기대하는 행동인 것이, 위에서 살펴보았듯이 MEV-Boost에서 릴레이의 안정성이 굉장히 중요하다. 만약 한 밸리데이터가 검열 방지에 대한 개인적인 신념으로 검열을 진행하지 않는 릴레이를 사용하다가, 그 릴레이에서 문제가 발생한다면 경제적인 타격으로 이어질 수 있는 문제가 있다. Flashbots의 릴레이가 가장 안정하기 때문에, 이를 사용하는 것이 가장 합리적인 선택이며, 검열을 진행하지 않는 릴레이를 선택하라고 강요하는 것도 근본적인 해결책이 될 수 없다.

4.2 프로토콜 관점

방금 살펴본 밸리데이터 관점에서의 검열 방지는 결국 이타심에 의존한 것이기 때문에, 보다 프로토콜에 의해 강제되는 해결법을 살펴볼 필요가 있다. 첫 번째 방법은 이더리움 로드맵 상에도 존재하는 PBS (Proposer/Builder Separation)와 crLists (censorship resistant Lists)의 도입이다. 이에 대해 자세한 내용은 다음 편에서 다룰 예정이지만, 간단히만 살펴보면 PBS란 현재 미들웨어 수준으로 존재하는 MEV-Boost의 메커니즘을 아예 이더리움의 프로토콜 단계로 도입해버리는 것이다. 이 과정에서 블록을 중개하는 역할을 수행하는 릴레이가 사라지기 때문에, 기존 MEV-Boost에서 존재했던 신뢰문제가 해결된다.

하지만 PBS가 도입된다고 해도 검열을 막을 수 있는 것은 아닌데, 이를 막기 위해 crLists가 추가적으로 도입된다. 간단히 살펴보면 프로포저는 멤풀의 트랜잭션들을 포함하고 있는 crList를 공표하고, 블록 빌더는 블록이 꽉 차지 않는 이상 crList에 포함된 모든 트랜잭션을 블록에 포함시켜야 하는 것이 강제된다. 즉, 빌더 입장에서 검열의 선택권이 사라지기 때문에 검열을 막을 수 있게 되는 것이다. 이더리움 커뮤니티에서는 지금 당장 검열 문제를 다루기 위해 crLists 시스템을 PBS가 프로토콜 단에 도입되기 전에 미리 도입하자는 논의도 이루어지고 있다. 이에 대해서 간단히 살펴보도록 하자.

아래 내용은 Quintus가 제시한 내용이다. 기본 골자는 MEV-Boost에도 crLists를 도입하자는 것이며 다음과 같은 방식을 제안했다:

1. 프로포저는 블록 빌더로부터 블록 헤더를 받기 이전에 crList를 공표한다.
2. 릴레이는 빌더들에게 crList를 전달한다.
3. 빌더는 crList에 존재하는 트랜잭션을 포함하여 블록을 만들고 이를 릴레이를 통해 프로포저에게 전달한다.
4. 프로포저에게 블록 헤더가 전달되기 전, 릴레이는 블록이 1) 꽉 찼거나, 혹은 2) crList의 트랜잭션을 모두 포함하고 있는지 확인한다.
5. 프로포저가 받은 블록 헤더에 서명하면 블록 빌더는 릴레이를 통해 프로포저에게 블록 전체를 보낸다.
6. 프로포저는 마지막으로 받은 블록이 crList에 대한 조건을 만족하는지 확인하고 네트워크에 블록을 제출한다. 만약 조건을 만족하지 않는다면 릴레이의 레퓨테이션을 깎는 것과 같은 처벌을 진행한다.

이 방식에는 몇 가지 문제점이 있는데, 여전히 릴레이가 중개하고 있기 때문에 이 방식을 사용하기 위해서 릴레이를 신뢰해야한다는 점, crList를 구성하고 확인하는데 있어서 프로포저와 릴레이에 부하가 더 걸린다는 점, crList를 공표하기 위해선 멤풀을 확인해야 하는데 MEV-Boost는 멤풀에 대한 접근권이 없기 때문에 이더리움 클라이언트 단에서의 몇 가지 수정사항이 필요하다는 단점이 있다. 또한, 규제 당국에서 빌더나 릴레이에게 crList 시스템을 따르지 말라고 강제한다면, crList를 사용하고 있는 프로포저가 블록을 제안할 차례가 올 때 받는 블록헤더에 딸린 bid의 양이 평균보다 낮을 수 있는 문제가 있다.

검열을 프로토콜 단에서 막을 수 있는 두 번째 방법은 EigenLayer을 활용하는 것이다. 이더리움이 PoW 방식을 사용할 땐 검열이 이루어지지 않다가, PoS로 전환한 후 검열 문제가 불거지게된 가장 큰 이유는 프로포저의 블록을 받는 방식이 바뀌었기 때문이다. PoW 시절에는 블록의 일부분만 받고, 채굴자가 나머지 부분을 구성할 수 있는 자유도가 있기 때문에 검열이 이루어지지 않았던 반면에, 현재 PoS에서는 프로포저는 블록 빌더에게 완전한 블록을 받을 수 밖에 없게 강제되기 때문에 빌더나 릴레이가 검열을 진행하면 프로포저는 검열된 블록을 받는 방법밖에 없는 것이다. EigenLayer을 활용하면 MEV-Boost를 사용하면서도 프로포저가 완전한 블록을 받는 것이 아닌, 블록의 일부만 받을 수 있도록 할 수 있다.

자세한 내용을 설명하기 전에 EigenLayer가 어떠한 프로젝트인지 간단히 살펴보고 넘어가자. EigenLayer는 이미 스테이킹한 토큰을 다시 스테이킹에 사용한다는 리스테이킹(Re-staking)의 개념을 처음 제시한 프로토콜이다. 사용자는 이미 네트워크에 스테이킹한 ETH를 EigenLayer을 통해서 다른 메인넷이나 브릿지, 오라클 등과 같은 미들웨어에 한번 더 스테이킹을 진행할 수 있게 되면서, 더 많은 슬래싱 조건에 노출되는 대신, ETH 보상외에도 리스테이킹한 프로토콜로부터 추가 보상을 얻을 수 있는 장점이 있다.

EigenLayer을 MEV-Boost에서 검열을 방지하는데 어떻게 사용한다는 것일까? 전체적인 모식도는 위와 같으며, 과정은 아래와 같다:

1. 프로포저는 EigenLayer을 통해서 자신들이 스테이킹하고 있는 ETH를 리스테이킹한다. 프로포저는 리스테이킹을 2가지 방식으로할 수 있는데, 자신이 스테이킹한 ETH의 withdrawl credential을 EigenLayer의 스마트 컨트랙트로 지정하거나, 혹은 다른 사용자가 리스테이킹용으로 프로포저를 대신하여 ETH를 위임해주는 방식이 있다.
2. 블록 빌더는 이전과 같이 완전한 블록을 만드는 것이 아니라, 블록의 일부분(Builder_part)을 만들고 이에 대한 merkle_root와 bid를 릴레이에게 전달한다.
3. 릴레이는 빌더로부터 받은 Builder_part에 대한 트랜잭션을 저장하고, merkle_root와 bid를 프로포저에게 전달한다.
4. 프로포저는 기존과 비슷한 방식대로 릴레이로부터 받은 여러개의 merkle_root 중 가장 bid가 높은 것을 선택한다. 또한, 프로포저는 혹시 모를 상황을 대비하여 예비 블록 B_alt를 만들어 놓는다.
5. 프로포저는 릴레이에게 자신이 선택한 merkle_root에 대한 서명 및 B_alt에 대한 commitment를 보낸다.
6. 릴레이는 프로포저로부터 선택된 merkle_root에 해당하는 Builder_part가 어떠한 트랜잭션들로 구성되어잇는지 공개한다.
7. 프로포저는 이를 보고 Builder_part가 포함된 채로 나머지 빈 공간을 자신이 원하는 트랜잭션(Proposer_part)을 끼워넣어서 완전한 블록을 만들고 이더리움 네트워크에 제출한다.
8. 만약 6번 과정에서 릴레이가 악의적인 행위로 Builder_part를 공개하지 않는다면, 프로포저는 기존에 예비용으로 만들어 두었던 B_alt를 대신 이더리움 네트워크에 제출한다.

이 과정에서 가장 첫 번째로 드는 의문은 바로 악의적인 프로포저에 대해서 어떻게 대처할 것이냐이다. MEV-Boost가 기존 작업증명 방식에서 사용되던 MEV-Geth와 달리 블록 생성자에게 완전한 블록을 전달해준 이유는 블록 생성자(프로포저)가 MEV를 훔칠 수 있기 때문이었다 (물론 MEV-Geth의 블록생성자(채굴자)도 MEV를 훔칠 수 있었지만, 채굴자는 물리적인 실체가 존재하는 주체이기 때문에 화이트리스팅이라는 방법으로 이를 제한했었다). 하지만, EigenLayer을 도입한 MEV-Boost에선 프로포저가 자신의 ETH를 EigenLayer을 통해서 리스테이킹한 상태이기 때문에, 만약 블록 빌더가 구성한 Builder_part에 포함되어있는 MEV를 훔치는 악위적인 행위를 한다면, 프로포저의 리스테이킹된 ETH는 슬래싱될 수 있는 것이다. 즉, 정리하면 이 방식에서 프로포저는 이더리움 네트워크에 제출한 블록에 Builder_part가 포함되어 있지 않거나, 혹은 B_alt 블록이 아니라면 슬래싱을 통해 처벌받게되는 것이다.

MEV-Boost에 EigenLayer을 도입하면 시스템이 복잡해져서 레이턴시가 증가하는 것 아니냐는 의문이 생길 수 있다. 이에 대해선 EigenLayer팀에서 잘 서술해주었는데, 결론적으로 말하면 EigenLayer이 도입되든, 안되든 거의 차이가 없다는 것이다. 이를 설명하기 위해 다시 기존 MEV-Boost와 EigenLayer가 도입된 MEV-Boost의 모식도를 살펴보자.

첫 번째 그림을 보면 기존 MEV-Boost에서는 각 주체별로 상호작용하는 과정이 [1], [3], [6], [7], [8] 총 5번 존재하며, EigenLayer가 도입된다고 하여도 두 번째 그림을 보면 주체별로 상호작용하는 과정이 [1], [4], [8], [9], [11]로 똑같이 5번 존재한다. 즉 주체 간 통신을 통해 발생하는 레이턴시의 차이는 거의 없는 것이다.

종합적으로 정리하면, MEV-Boost에 EigenLayer을 도입한다면 다시 기존 MEV-Geth와 같이 블록 생성자(프로포저)는 블록의 일부분만 받고, 나머지는 자신이 원하는 트랜잭션을 넣어 블록을 구성할 수 있기 때문에 빌더, 릴레이 단에서 검열을 진행해도 블록은 검열의 영향을 받지 않게 될 것이다. 프로포저가 Proposer_part로 검열당하고 있는 트랜잭션을 골라서 완전한 블록을 만들고, 네트워크에 추가하면되기 때문이다. 만약 OFAC이 빌더, 릴레이뿐만 아니라 프로포저까지 제재를 가한다면 이러한 방법이 무용지물이 될 수 있겠지만, 이럴 가능성은 극히 드물어 보이며, 실현가능성 또한 낮다고 판단된다. 첫 번째 이유로 현재 이더리움의 프로포저(밸리데이터)들은 전세계에 퍼져있으며, 그 개수 또한 굉장히 많고, 기업 밸리데이터를 제외하고선 대부분 익명이다. 즉, 현실적으로 제재를 가하기 굉장히 어려운 상황인 것이다. 두 번째 이유로 프로포저 단에 마저 규제를 가한다는 것은 블록체인의 검열 저항성 및 탈중앙성에 완벽하게 위배되는 상황이다. 이러한 상황이 벌어질 경우 코인베이스의 CEO 브라이언 암스트롱은 검열을 진행하느니 아예 이더리움 밸리데이터 사업을 철수할 것이라고 강력하게 의견을 표방하기도 했으며, 그 외에도 이더리움 네트워크는 검열 하에 놓인 이더리움과 검열에 자유로운 이더리움 두 개로 포크될 가능성이 매우 클 것이다.

5. 마치며

본 글에서는 PoS 이더리움에서 MEV를 효과적으로 탈중앙화시킬 수 있는 MEV-Boost를 알아보고, MEV-Boost의 빌더, 릴레이로 인한 검열 문제와 이를 해결할 수 있는 방법들에 대해 알아보았다. crLists나 EigenLayer의 도입 등 다양한 논의가 이루어지고 있으나 결국 이는 어플리케이션 단에서의 해결법일 뿐 근본적인 해결법이 아니다. 이더리움 로드맵 상에는 이를 궁극적으로 해결할 수 있도록 프로토콜 단에서의 PBS와 crLists의 도입이 예정되어있지만, 언제 업그레이드 될 수 있을진 기약이 없는 상태이다. 또한, 더 나아가 PBS, crLists가 도입이 되면 검열은 방지할 수 있겠지만, 또 다른 문제가 있다. 바로 빌더의 중앙화이다. 특정 빌더에게만 트랜잭션을 넣을 수 있는 EOF(Exclusive orderflow)로 인해 생기는 문제인데, 이에 대해선 3편에서 자세히 살펴보도록 하겠다.

-> '[MEV 시리즈 ②] MEV-Boost & Censorship' 원문 보러가기 

※ 참고 문헌

• https://joncharbonneau.substack.com/p/censorship-wat-do
• https://members.delphidigital.io/reports/mev-manifesto
• https://hackmd.io/@layr/SkBRqvdC5
• https://github.com/flashbots/mev-boost/issues/215
• https://github.com/flashbots/builder