이 글은 Jon Charbonneau의 Censorship... wat do? 를 요약 및 저의 생각 및 설명을 일부 추가한 글입니다.

[요약]

1. MEV-Boost는 밸리데이터의 탈중앙화를 위해 플래시 봇이 만들었다.
2. 그러나 MEV-Boost는 릴레이어/빌더의 중앙화 문제를 낳았고, 이는 검열 저항성을 해치게 되었다.
3. MEV-Boost에서 검열은 약한 검열이기 때문에 시간이 지나면 검열 대상 트랜잭션도 포함이 되지만, 많은 밸리데이터가 동참하면 문제가 심각해질 수 있다.
4. 밸리데이터 레벨에서 이를 막으려면 검열을 하는 릴레이어를 사용하지 않는 것이다. 그러나 이는 근본적인 해결책이 아니다.
5. 프로토콜 레벨에서는 1) crList의 도입과 2) EigenLayer의 도입으로 검열을 막을 수 있다.
6. 만약 플래시 봇이 사라진다면 EOF 등을 이용하여 독점하는 빌더가 생겨날 수 있다. 이는 플래시 봇보다 훨씬 더 큰 검열 및 악영향을 생태계에 끼칠 수 있다.
7. 플래시 봇이 진정으로 검열을 막고 싶다면 커뮤니티에 다른 비검열 릴레이/빌더를 지원하고 빌더 코드를 오픈 소스화 하는 것도 좋은 방법일 것이다.

원 글의 흐름을 간단하게 말하면 다음과 같습니다.

MEV 탈중앙화 -> MEV-Boost 도입 -> 검열 저항성 약화 -> 어떻게 해결해야할까

원 글은 검열을 막기 위해 이더리움의 참여자들이 어떻게 행동해야 하는지 제시하는 글이라고 할 수 있습니다.

이 글은 원 글을 단순히 번역함을 넘어 이해하기 쉽게 저의 추가적인 지식 및 생각을 덧붙였습니다.

Devs... wat do?

이더리움은 확장성과 같은 문제들은 잠시 뒤로 미뤄놔도 여전히 잘 운영이 될 수 있습니다. 이더리움은 지금까지 높은 가스비로도 잘 살아남았기 때문입니다. 그러나 검열이 이루어진다면 이더리움은 살아남을 수 없을 것입니다.

이더리움 개발자들이 검열 저항성을 우선 순위로 개발하지 않는다면 커뮤니티에 안좋은 신호을 보내게 될 수 있습니다. 핵심 프로토콜 개발이 검열 저항성을 우선시 하지 않으면, 밸리데이터와 플래시봇, 릴레이어 역시도 이를 중요하게 생각하지 않을 것이기 때문입니다.

현재 하락장이기에, 가스비 문제는 일단 괜찮아졌습니다😢. 그래서 어떻게 하면 검열을 막을 수 있을지 우선시해도 좋을 것입니다.

MEV-Boost

검열에 대해서 이야기하기 전에 먼저 MEV-Boost의 구조에 대해서 설명해야합니다. MEV가 무엇인지는 이 글에서 설명하지 않겠습니다.

MEV 를 포착하는 것은 여러 복잡한 문제가 관련되어 있습니다. 예를 들어 MEV를 추출할 수 있는 밸리데이터는 일부이기에 밸리데이터의 중앙화 문제가 생길 수 있습니다.

PBS(Proposer-builder separation)는 "빌더"라는 최적화된 블록을 만드는 역할을 만듬으로써 이를 해결하고자 했습니다. 빌더는 프로포저(밸리데이터)에게 블록을 제출하며 비딩을 합니다. 프로포저의 역할은 비교적 쉽기 때문에 탈중앙화가 될 수 있습니다. PBS는 아직 준비 중이며, 최종적으로 프로토콜 안에 구축이 될 것입니다.

PBS는 아직 도입이 안되었기 때문에 현재 MEV-Boost가 그 중간 단계 역할을 해주고 있습니다. MEV-Boost는 프로토콜 밖의 소프트웨어로 밸리데이터가 아웃 소싱한 블록 생성을 쿼리할 수 있게 해줍니다. 프로토콜 외 소프트웨어이기 때문에 MEV-Boost를 사용하더라도 밸리데이터가 자체적으로 생성한 블록을 사용할 수 있습니다.

간략하게 MEV-Boost의 로직을 설명하면 다음과 같습니다.

1. MEV 서쳐(Searcher)가 자신의 전략을 사용해 트랜잭션 번들을 모아 빌더에게 비딩을 합니다.
2. 빌더는 이러한 번들들과 퍼블릭 멤풀, 프라이빗 orderflow들을 합쳐 블록을 만듭니다.
3. 릴레이는 프로포저와 빌더 사이에서 블록과 비드를 모아 결정된 블록을 프로퍼저에게 전달합니다.

위 그림을 보면 알 수 있듯이 플래시봇 릴레이가 밸리데이터(Block proposer)에게 블록 헤더와 비드를 전달하고 서명된 헤더를 받아옵니다.

위 구조는 일부 채굴자(밸리데이터)를 신뢰해야 하는 MEV-Geth의 문제를 극복하였습니다(MEV-Geth는 PoW 이더리움에서 사용했던 MEV를 위한 클라이언트입니다). MEV-Geth에서는 플래시봇이 밸리데이터에게 번들만 보냈기 때문에 밸리데이터가 훔칠 수 있었습니다. 그러나 MEV-Boost에서 밸리데이터가 블록의 내용을 보기 전에 헤더에 사인을 해 밸리데이터는 별개의 자신의 블록을 만들 수 없게 되었습니다. 블록의 내용을 보고 자신이 똑같은 블록을 만들어 제출하게 되면 double-signing이 발생해 슬래싱이 될 것입니다.

그러나 이 구조는 밸리데이터의 탈중앙화에는 성공하였으나 릴레이/빌더 레벨에서 검열 이슈를 낳는 단점이 있습니다. 검열을 하는 릴레이어에게 블록을 받으면 밸리데이터가 탈중앙화되어도 검열을 피할 수 없습니다.

또 다른 MEV-Boost의 장점은 Sidecar로서 모든 consensus & execution 클라이언트와 호환이 됩니다(클라이언트 프로그램의 다양성 증가). MEV-Geth는 Geth를 포크했기 때문에 플래시봇 옥션을 사용하려는 채굴자들은 전부 Geth에 영향을 받았습니다. 이는 Geth에 문제가 있다면 많은 채굴자들이 영향을 받기 때문에 네트워크의 보안성을 저해할 수 있는 요소가 됩니다.

Censorship

검열은 두 가지로 나누어 생각할 수 있습니다.

• 약한 검열(Weak censorship)
• 강한 검열(Strong censorship)

약한 검열에서 트랜잭션은 블록에 포함되는 것이 미뤄질 수 있지만 결국 포함됩니다. 만약 50%의 밸리데이터가 OFAC 트랜잭션을 검열하더라도 평균적으로 두 블록 이후에는 OFAC 트랜잭션은 블록에 포함이 될 것입니다.

강한 검열에서 검열된 트랜잭션은 온체인에 포함되지 않습니다. 51%의 밸리데이터가 자신의 블록에 포함하지 않을 뿐 아니라 OFAC 트랜잭션을 포함하는 블록들을 무시한다면 생길 수 있습니다.

이러한 검열 위험은 밸리데이터보다 릴레이/빌더 레벨에서 더 큽니다.

한 밸리데이터라도 검열을 하는 릴레이를 사용하면 약한 검열이 적용이 됩니다. 모든 밸리데이터가 검열을 하는 릴레이를 사용하면 강한 검열이 적용될 것입니다.

이미 22.12.25 기준 검열을 하는 릴레이어로부터 생성된 블록은 67%입니다. MEV-Boost를 사용하지 않는 밸리데이터로부터 생성된 블록은 11.35%에 불과합니다.

Validators... wat do?

밸리데이터는 MEV-Boost를 이용하되 검열을 하지 않는 릴레이를 사용하면 MEV 보상을 받으면서 이더리움의 검열 저항성을 증가시킬 수 있습니다. MEV-Boost를 이용하지 않는 것이 검열을 할 가능성을 없앤다는 면에서 최고의 방법이겠지만, 보상에서 차이가 난다는 점에서 현실적으로 어렵습니다.

또한 밸리데이터에게 검열하는 릴레이를 사용하지 않게해 검열을 막자는 방법은 이타주의에 의존하기 때문에 근본적인 해결책이 아닙니다. 만약 검열하는 릴레이가 검열을 하지 않는 릴레이보다 성능이 훨씬 좋아 보상 차이가 크게 난다면, 감정에 호소하기는 어려울 것입니다.

Protocol... wat do?

위에서 말했듯이 밸리데이터에게 릴레이어를 선택하게 하는 방법은 근본적인 해결책이 아닙니다. 프로토콜 레벨에서 막을 수 있어야 진정한 검열 저항성을 이룰 수 있을 것입니다.

방법1) Enshrined PBS & crList

MEV-Boost는 PBS로 가기 전 MEV를 탈중앙화하기 위한 소프트웨어이기에, PBS가 프로토콜에 구축되면 릴레이는 없어집니다.

릴레이가 없기 때문에 빌더는 프로토콜 내부 경매에서 프로포저에게 직접 블록을 전달합니다. 여기서 빌더는 신뢰의 필요를 제거하기 위해 무조건적인 지불을 약속합니다. 즉, 프로포저가 빌더가 보낸 블록 헤더에 사인을 하면 빌더는 블록이 잘못되었더라도 무조건 비드를 지불해야합니다.

crList는 프로포저가 멤풀을 관찰해 포함 가능한 트랜잭션들을 모아놓은 리스트입니다. 프로포저가 crList를 만들면 빌더들은 블록이 꽉 차지 않는 이상 무조건 해당 트랜잭션들을 포함시켜야 합니다.

빌더는 crList에 포함된 트랜잭션이 전부 블록에 포함되어 있음을 증명하는 증거를 같이 제출해야 합니다.

아직 구체적인 구현은 정해지지 않았고, 여러 프로포절들이 나오고 있는 상황입니다.

방법2) EigenLayer를 사용한 MEV-Boost를 이용

이 방법은 EigenLayer를 사용해 MEV-Boost의 검열 저항성을 강화합니다.

내년에 출시될 것으로 예상되는 EigenLayer는 restaking을 가능하게 해주는 이더리움 스마트 컨트랙트입니다. 이더리움 밸리데이터는 EigenLayer의 스마트 컨트랙트에 자신의 출금 주소를 셋팅함으로써 새로운 슬레싱 조건을 추가합니다. 대신 스테이킹된 ETH를 다른 어플리케이션에 스테이킹해 추가적인 보상을 얻을 수 있게 됩니다. 어플리케이션은 EigenLayer를 이용해 이더리움의 보안을 사용해 어플리케이션의 보안을 레버리지할 수 있는 장점이 있습니다.

MEV-Boost에 EigenLayer를 적용하면 블록 빌더 중앙화를 해결할 수 있습니다.

(아래 과정은 글쓴이가 요약했습니다. 머클 루트 및 커밋먼트의 전송을 생략하였습니다. 자세한 과정은 원문을 보는 것을 추천합니다)

1. 빌더는 릴레이에게 블록을 전부 보내는 것이 아니라 블록의 일부(Builder_part)만 보냅니다.
2. 릴레이는 받은 트랜잭션을 저장하고 프로포저에게 비드를 보냅니다.
3. 프로포저는 가장 높은 비드를 선택하고 자신이 대체 블록(B_alt)을 생성합니다.
4. 릴레이는 빌더에게 받은 트랜잭션을 공개하여 프로포저에게 보냅니다.
5. 프로포저는 릴레이어로부터 받은 트랜잭션(Builder_part)과 자신이 추가한 트랜잭션(Proposer_part)으로 새로운 블록을 생성합니다. 릴레이가 트랜잭션을 공개하는데 실패하면 블록은 아까 자신이 만든 대체 블록을 제안합니다.

프로포저가 대체 블록을 제안하지 않고 새 블록을 제안한다면 builder_part가 무조건 포함이 되어야 하고 그렇지 않는다면 EigenLayer로부터 슬래시 당합니다. 만약 MEV를 훔쳐 새로운 블록을 제안하면 B_alt가 아닌 블록을 제안한 것이므로 슬래시 당합니다.

이를 통해 프로포저는 수익을 극대화하면서도 검열된 트랜잭션을 추가할 수 있습니다.

The Devil You Know vs. The Devil You Don't

이 문단은 글이 너무 길어진다고 생각되어 글쓴이가 원문을 간추려 소개합니다.

원문은 exculsive order flow(EOF)에 대해서 설명합니다. 만약 FlashBot이 없어진다면 검열이 없어질 것 같지만 독점적으로 트랜잭션을 받는 빌더(EOF) 등이 등장해서 더 검열이 심각해질 수도 있다는 시나리오를 제시합니다.

유저에게 프론트 러닝을 하지 않고 백러닝 수익을 유저에게 공유한다는 등 약속을 통해 독점적으로 트랜잭션을 공급받는 빌더가 생겨나면 다른 빌더들보다 항상 많은 비딩을 해 독점하는 빌더가 생길 수 있다고 경고합니다. 독점하는 빌더가 수수료를 크게 올려도 다른 빌더들은 너무 작거나 없어졌기에 블록을 생성할 수 없어 유저들은 계속해서 독점적인 빌더를 사용해야 하는 상황이 올 수 있습니다.

또한 검열 저항성에도 문제가 생길 수 있습니다. 경쟁적이고 합리적인 시장에서는 모든 빌더가 동일한 조건에서 자신의 전략을 구사하기에 비딩 차이가 크게 나지 않을 것입니다. 그러나 EOF 등을 사용해 특정 빌더가 유리한 환경에서 블록을 만들면 비딩의 차이가 생기게 됩니다. 프로포저들은 당연히 비딩이 높은 블록을 선택하기에 EOF를 사용하는 빌더들이 계속해서 선택될 것입니다. 이런 빌더가 검열을 하게 되면 거의 모든 블록은 검열될 것입니다.

crList가 해결책이 될 수 있다고 생각하겠지만, 완벽한 해결책은 아닙니다. 비딩 차이가 크게 난다면 밸리데이터 입장에서는 crList를 비워놓는게 경제적으로 제일 좋은 선택입니다. crList에 트랜잭션을 넣으면 검열을 하지만 보상이 제일 좋은 블록을 얻지 못하게 되니까요.

Decentralized Builders

자세한 내용은 원문 저자가 작성한 Decentralizing the Builder Role에 나와 있습니다.

원문에서는 Winning 빌더 그 자체를 탈중앙화 프로토콜로 만드는 것이 빌더를 탈중앙화시키는 방법이라 말합니다. 그리고 위에 링크된 글은 Trusted Hardware 등을 이용해 탈중앙화 빌더를 만드는 다양한 아이디어를 소개하고 있습니다.

Flashbots... wat do?

앞 EOF 시나리오에서 보았듯이 다른 빌더들이 네트워크에 피해를 끼칠 수 있기에 플래시 봇이 자신들의 주도권을 다른 빌더들에게 주지 않는 것을 이해할 수 있습니다. 지금처럼 점유율을 가진 상태에서 탈중앙화 빌더를 만드는 것이 더 쉬울 수 있을 것입니다.

그러나 현재 플래시 봇은 어쨌든 검열을 하고 있습니다. 위에서 말한 아이디어들이 실현이 된다면 이런 검열들은 사라질 수도 있을 것입니다. 그렇지만 미래에 누가 검열하는 것을 막는다는 것을 이유로 현재 검열을 정당화하는 것은 어렵다고 생각합니다.

플래시봇이 검열을 하고 싶지 않다면 커뮤니티에 비검열 릴레이/빌더를 지원해야할 것입니다. 플래시봇은 이미 AGPL 라이선스(상호 작용해야 하는 소프트웨어의 소스코드도 공개)로 릴레이의 코드를 공개했습니다. 그 다음 스텝으로 생각할 수 있는 것은 빌더도 오픈소스로 공개입니다. 빌더 소스가 공개되면 빌더 시장에 들어올 수 있는 진입 장벽이 낮아지기 때문에 플래시봇이 검열을 하고 싶어하지 않는다는 의도를 알릴 수 있을 것입니다.

플래시봇이 직접 릴레이를 운영하는 문제는 옳고 그른지 판단하기 어렵습니다. 플래시봇이 릴레이 운영을 중단해도 또다른 검열 릴레이가 그만큼 점유율을 채울 수 있습니다.

만약 릴레이를 계속 운영하고 싶다면 밸리데이터 비율에 상한선을 두는 것이 가장 적절해보입니다. 약한 검열이어도 검열 당하는 밸리데이터의 퍼센티지가 높아진다면 큰 차이가 있을 것입니다.

Final thought

플래시 봇은 검열의 발원지이지만 이더리움 생태계에 긍정적인 영향을 끼치는 중심지이기도 합니다. 또한 중립적인 커뮤니티 빌더와 전통적인 기업 운영에서 경계를 지키기 위해 생태계에 상당한 책임감을 가지고 있을 것이라 생각합니다.

이 글은 플래시 봇의 과거 행동을 비난하기 위한 것이 아닙니다. 플래시 봇을 포함한 생태계의 중요 플레이어들은 생산적이고 공개적인 논의가 필요합니다.

Reference

Censorship... wat do?