brunch

매거진 개발썰

You can make anything
by writing

C.S.Lewis

by 한상훈 Sep 28. 2024

이더리움과 MEV

최근 이더리움 포럼에서 논의되고 있는 논제에 관하여

이 글은 시리즈 글로 앞선 내용에서 설명한 내용은 재설명하지 않으니 읽지 않으신 분은 먼저 읽어보시길 추천드립니다.


1편: https://brunch.co.kr/@skykamja24/944




MEV로 넘어가 보도록 하자. MEV는 재밌는 단어다. 처음에는 MEV의 M이 지칭하는 바가 광부를 뜻하는 Miner였으나 이제는 최대를 뜻하는 Maximal로 변경되었다. 이 변화가 생긴 이유는 PoW에서 PoS로 변경됨에 따름인데, 기존 작업 증명에서는 작업을 진행하는 각각의 채굴자의 수익을 최대화하는 전략이었다면 지분 증명으로 바뀐 현재에서는 채굴자라는 것이 이더리움에 존재하지 않고, 노드 검증자(벨리데이터 노드)가 보상을 획득하기 때문이다. 이 과정에서 최대화된 수익을 가져가는 가치를 MEV라 부르게 됐다.


이더리움에서는 거래가 발생하면 해당 거래를 검증하는 노드에 대해 보상을 지불하는데(가스비), 이때 더 높은 대가를 받는 검증자가 될 수 있다면 보상이 최대화될 것이고, 가격이 낮은 거래 검증만 하게 된다면 수익률이 낮아질 것이다. 내가 검증 자라면 참으로 안타까운 일일 것이다. 


MEV가 실현되는 곳은 비단 이더리움 자체 스테이킹 시스템뿐만 아니라 경쟁이 훨씬 강한 DEX에서 쉽게 찾아볼 수 있다. Uniswap과 같은 DEX에서 발생하는 거래에는 거래에 제공되는 모든 페어에 대해 유동성 공급자가 수수료 수익(0.3%)을 가져가게 된다. 프로그래밍적으로 생각해 보면 인기 있는 거래 풀의 경우에는 유동성 공급을 하려는 풀은 많을 것이고, 이 과정에서 어떤 풀에 우위를 두고 거래가 발생할지에 대해서도 논리적으로 연산이 가능할 것이다. 


이때 거래에 참여하는 존재는 유동성 공급자와 이를 검색하는 검색자가 있는데, 검색자는 가장 합리적인 거래를 찾아다닐 것이고, 반대로 공급자는 가장 많은 수익을 확보하고 싶을 것이다. 이 과정에서 경쟁력의 기준이 되는 가스 수수료에 따라 수익성이 결정될 것이며, 수익성에 따라 내가 제공한 거래가 더 많이 거래되어 실제적으로 더 많은 수익을 창출할 수도 있게 되는 것이다.


출처: https://ethereum.org/en/developers/docs/mev/


이를 이더리움 공식 문서에서도 설명하고 있는데, 검색자는 90% 또는 그 이상에 해당하는 MEV revenue를 가스 비용으로 검증자에게 제공해야 할 수 있다고 한다. 


최대화된 수익인 MEV를 뽑아냄에 있어서 추출이라는 표현을 자주 사용하는데, MEV를 추출하기 위한 대표적 전략은 DEX 간 차익 거래, 단일 AMM(Auto Market Maker)에서 발생하는 샌드위치 전략, 대출 프로토콜의 청산 시나리오 등이 있다. 




여기서부터 이더리움 커뮤니티에서 어떻게 이것을 감소시키려고 하는지 설명해보고자 한다. 앞서 설명한 것들은 시스템적으로 생길 수밖에 없는 수익 추출 전략에 해당한다. 또한 이를 활용해서 현재까지도 이를 시스템화하여 수익을 가져가는 집단이 존재한다. 물론 경쟁이 치열해짐에 따라 MEV 추출 전략이 이전만큼의 수익성은 나타나지 않지만 결과적으로 MEV가 커질수록 반대로 일반 사용자들이 의도치 않게 피해를 보는 상황도 생길 수 있다.


대표적으로 샌드위치 전략이 이에 해당한다. 샌드위치 전략은 이더리움을 비롯한 블록체인 시스템의 블록 생성 시간과 거래 처리 순서 로직의 빈 틈을 노린 전략이다. 초기 블록체인 시스템에서는 크게 두곽될 수 없었지만 AMM 기반의 DEX, 심지어는 오더북 방식의 DEX에서도 발생할 수 있는 문제이다. 


AMM은 전통적인 주식 거래 방식에 해당하는 호가 매매가 아니다. 유동성 풀이 있으면 그 유동성 풀에 내가 원하는 토큰을 교환하여 교환비가 실시간으로 변동되는 방식을 뜻한다. 예를 들어 유동성 풀의 토큰 A와 토큰 B가 각각의 유동성 L(a), L(b), 각각의 현재 가격 P(a), P(b)를 가질 때 다음과 같은 식으로 표현될 수 있다.


P(a) * L(a) = P(b) * L(b)


이 과정에서 내가 토큰 A를 매도하고, 토큰 B를 얻고자 하면 유동성 풀의 수량이 변동될 것이다. 내가 매도한 토큰 A를 S(a), 얻은 토큰 B를 E(b)라고 한다면 식은 다음과 같다.


P(a) * (L(a) + S(a)) = P(b) * (L(b) - E(b))


물론 이렇게 하게 되면 금액은 거래 당시보다 변동된 교환비가 적용이 되어야 하고, 이때 변동된 교환비(가격)가 몇 퍼센트인지를 부르는 표현이 바로 슬리피지(Slippage, 가격의 미끄러짐)에 해당한다. 또한 이 미끄러지는 정도는 실시간으로 차이가 생길 수 있는데 내가 실행한 시점에 교환비가 바로 앞 거래가 발생한다면 교환비가 또 달라질 수 있다. 이것까지 모두 포함하여 발생하는 교환비의 차이를 우리는 슬리피지라 부른다.

 

각각의 AMM마다 구체적인 로직은 차이가 있을 수 있지만 큰 구현 방식은 위의 식인데, 이러한 AMM 방식의 거래가 언제나 순차적으로 이뤄진다면 문제가 없다. 그러나 블록이 생성되기 전 거래가 맴풀(mempool)에 있을 때, 공격자가 해당 거래를 보고 먼저 매수하고, 거래가 끝난 직후 매도를 하게 된다면 여기서 샌드위치 공격의 MEV가 발생한다.


공격자가 거래가 발생할 트렌젝션보다 높은 가스비를 지불하여 대기열 앞 쪽으로 올라서게 되면, 나보다 뒤에 발생하는 거래는 더욱 비싼 교환비로 토큰을 교환할 것이다. 이를 극단적으로 비유하면 다음과 같다.


예시:


당신은 토큰 1개를 사기 위해서 100원에 거래를 요청했다. 또한 당신은 슬리피지 한도를 5%로 설정했다. 즉 가격이 105원이 되어도 토큰을 사겠다는 의미다. 


공격자는 맴풀에 들어온 당신의 트렌젝션을 확인하고 대기열 앞으로 거래를 보낸다. 공격자는 100원에 토큰을 1개 구매하고, 당신의 바로 뒤에 매도 요청을 보내둔다. 


공격자가 가격을 끌어올리는 거래가 발생하여 당신은 최대 손실에 해당하는 105원에 토큰을 구매했다. 물론 당신은 슬리피지 한도를 5%로 걸었기 때문에 당신이 허락한 범주에서 발생한 가격 변동이긴 하다. 그러나 공격자는 100원에 사서 가격을 끌어올려두었고, 당신은 105원에 이 토큰을 샀고, 공격자는 바로 매도하여 105원을 기준으로 매도하여 수익을 얻었다.




이것이 샌드위치 공격을 통한 전략인데 이 전략이 최초로 나타났을 때는 대형 DEX에서도 대응이 안 됐기 때문에 실시간으로 어마어마한 수익이 공격자들에게 들어가게 됐다. 당연하게도 이러한 거래는 가격 변동이 거의 발생하지 않는 소액의 거래에는 사용되기 힘들고, 대량의 거래가 발생할 때(많은 슬리피지를 유발) 공격자들이 사용하는 전략이었다.


이를 해결하기 위해 이더리움 네트워크에서는 근본적인 해결책들을 내기 시작했는데, 재밌게도 TPS가 압도적으로 높고, 블록 생성 시 간이 극단적으로 짧다면 이 문제가 생기기 매우 어려워진다. 공격자가 공격을 감지하고, 대기열에 들어오기까지의 텀이 짧기 때문에 온체인 데이터를 모니터링하는 비용이 지수적으로 상승하기 때문이다. 반면 이더리움은 상대적으로 중앙화된 네트워크가 아니며 또한 TPS나 블록 생성 시간이 비교적 긴 편에 속했다.(점진적으로 발전하고 있지만 과거에는 극심했다) 그렇다 보니 이를 해결하기 위해서 MEV 추출을 줄이기 위한 논의가 다각도로 진행되고 있다.


MEV를 대응하기 위한 논의는 꽤나 활발해서 지속적으로 많은 글이 올라오고 있고, 블록 생성 시간을 개선하여 대응하는 방식은 트릴레마와도 연결되는 문제에 해당한다. 이전 글에서 아이겐레이어가 데이터 가용성과 검증자 문제를 이더리움 네트워크와 독립적으로도 해결해가고 있는 것과 유사하게, MEV의 문제는 MEV가 발생할 수 있는 모든 형태의 DeFi 또는 DApp들도 자체적으로 해결해가고 있다. 


대표적으로 Uniswap의 경우 꾸준히 버전 업그레이드를 하면서 AMM 뿐만 아니라 MEV에 대응하기 위해 힘쓰고 있고, 대출 청산 프로토콜에서 생길 수 있는 MEV 역시 마찬가지로 대출을 제공하는 AAVE 등의 서비스에서 노력하고 있다. 

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari