---
title: Front Running과 MEV
tags: security, 보안, MEV, Flash Bot, Front Running, Back Running
---

<style>

html, body, .ui-content {
background-color: #333;
color: #ddd;
}

.markdown-body h1,
.markdown-body h2,
.markdown-body h3,
.markdown-body h4,
.markdown-body h5,
.markdown-body h6 {
color: #ddd;
}

.markdown-body h1,
.markdown-body h2 {
border-bottom-color: #ffffff69;
}

.markdown-body h1 .octicon-link,
.markdown-body h2 .octicon-link,
.markdown-body h3 .octicon-link,
.markdown-body h4 .octicon-link,
.markdown-body h5 .octicon-link,
.markdown-body h6 .octicon-link {
color: #fff;
}

.markdown-body img {
background-color: transparent;
}

.ui-toc-dropdown .nav>.active:focus>a, .ui-toc-dropdown .nav>.active:hover>a, .ui-toc-dropdown .nav>.active>a {
color: white;
border-left: 2px solid white;
}

.expand-toggle:hover,
.expand-toggle:focus,
.back-to-top:hover,
.back-to-top:focus,
.go-to-bottom:hover,
.go-to-bottom:focus {
color: white;
}

.ui-toc-dropdown {
background-color: #333;
}

.ui-toc-label.btn {
background-color: #191919;
color: white;
}

.ui-toc-dropdown .nav>li>a:focus,
.ui-toc-dropdown .nav>li>a:hover {
color: white;
border-left: 1px solid white;
}

.markdown-body blockquote {
color: #bcbcbc;
}

.markdown-body table tr {
background-color: #5f5f5f;
}

.markdown-body table tr:nth-child(2n) {
background-color: #4f4f4f;
}

.markdown-body code,
.markdown-body tt {
color: #eee;
background-color: rgba(230, 230, 230, 0.36);
}

a,
.open-files-container li.selected a {
color: #5EB7E0;
}

</style>

# Front Running과 MEV

우리가 보낸 트랜잭션 (Tx) 정당하게 처리되고 있을까?
---
0. Front Running과 Back Running이란?
1. 우리의 tx는 어디에: EVM의 mempool이란?
2. 채굴자들을 위한 추가 세금: Maximal Extractable Value (MEV) 란?
3. MEV를 방지하기 위한 해결책: Flash Bot

Front Running과 Back Running 이란? [[1]](https://en.wikipedia.org/wiki/Front_running)[[2]](https://www.btcnews.kr/%ED%94%84%EB%A1%A0%ED%8A%B8-%EB%9F%AC%EB%8B%9D%EC%9D%80-%EC%9D%B4%EB%8D%94%EB%A6%AC%EC%9B%80%EC%97%90%EC%84%9C-%ED%95%B4%EB%A1%AD%EB%8B%A4/)[[3]](https://medium.com/@m.vanderwijden1/backrunning-in-defi-301f3cade30a)[[4]](https://www.bitcoinsuisse.com/research/decrypt/arbitrage-and-frontrunning-in-defi)
---
[WallStreetMojo](https://www.wallstreetmojo.com/front-running/)

### Front Running 이란?
- 전통적인 금융에서의 `Front Running`은 브로커나 트레이더가 **대규모의 자금에 대해서 주문을 넣기 전, 먼저 개인이 매수를 한 다음 가격이 오르면 이득을 보는 행위**를 의미한다.* 이러한 행위는 다른 시장 참여자들보다 한 발 앞서 달려간다라는 의미에서 `Front Running`(선행 매매)이라고 부른다. `Front Running`은 전통 시장에서는 공개되어 있지 않는 내부 소식(non-public data)을 먼저 접하고 개인의 이익을 취하기 때문에 **비윤리적인 행동**이라고 생각할 뿐만 아니라 **법적으로 문제가 된다**.

[선행매매 관련 법](https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=songpha69&logNo=220917864768)

- Defi 에서의 `Front Running`은 공개되어 있는 다른 사용자의 tx을 보고, 더 높은 가스비를 지불하고 자신의 tx를 먼저 처리하도록 만드는 수법이다. 이는 블록체인(이더리움)의 특성을 이용한 방법으로, `Front Running`이라는 단어가 주는 의미 그대로 다른 사람보다 앞서서 (사실은 새치기하여) tx를 체결하는 모습을 생각해보면 된다.

> \* Front Running은 한국말로는 '선행매매'로서 '선취매'와는 다른 의미이다. 선취매는 주식을 미리 취득하고, 미디어 등을 통해서 가격을 부풀린 다음 매도하는 수법인데, 선행매매는 이와 다르게, 내부 소식을 통해서 대규모 자금이 들어올 것을 알고 개인의 이익을 위해서 미리 주식을 사두는 행위이다.

### Back Running 이란?
[Bonding Curve](https://www.steemcoinpan.com/hive-101145/@donekim/defi-bonding-curve)

- `Back Running` 은 bonding curve* 에 기반하여 가격이 결정될 때, 앞선 거래자의 거래에 의해서 변경된 가격을 이용해서 이득을 보는 전략이다.
- 사실, `Back Running`은 탈중앙화된 거래소(Dex)에서 유용하게 사용되는 전략이다. 예를 들어, Uniswap의 BTC/ETH 풀에서 ETH의 급격한 출금 또는 입금이 발생했고, 이로 인해 크게 가격 변동이 있다면, 이 기회를 포착하고 arbitrage bot들이 `Back Running`을 통해서 다른 거래소와의 가격을 맞춘다. 그 결과, bot들은 시세 차익을 얻게 되고, 전체적으로 거래소의 가격은 큰 차이없이 평균으로 수렴하여 시장 전반적으로 긍정적인 효과가 가져온다.

> \* Bonding Curve 는 거래소에 의존하지 않고 토큰에 대한 자체 시장을 생성하고 운영하는 스마트하게 설계된 컨트랙트으로, Defi 에서 유동성 풀 예치를 했을 때, 수요와 공급에 따라 가격이 자동적으로 결정되는 모델을 의미한다.

#### 블록체인에서의 Front Running과 Back Running의 문제점

- 하지만, 데이터가 공개가 되어있는 (public) 블록체인의 환경에서도 `Front Running`은 발생하고, `Back Running`을 악의적으로 활용하는 경우가 많다. 악의적인 사용자는 검증은 되었지만 아직 블록에 추가되지 않은 pending tx들 중에서 수익이 될만한 tx를 골라서 그대로 복사한 다음, `Front Running`으로 더 많은 가스비를 주고 자신의 tx로 처리되도록 할 수 있다. 또한, Dex의 유동성 풀에서 가격을 올려 놓은 다음, 비싼 가격에 사용자의 tx가 처리되도록 한 후, `Back Running`을 하여 더 비싼 가격에 본인이 교환한 토큰을 덤핑해버리는 방식을 사용할 수 있다.
- 위에서 언급한 `Front Running` 과 `Back Running`을 잘 조합하여 **샌드위치 공격**을 할 수 있다. 샌드위치 공격은 다음과 같이 진행된다.
1. 아래의 그림과 같이, 악의적인 사용자는 총 13.79 ETH가치의 MANA를 구입한다. 이 tx는 가운데에 위치한 사용자의 tx보다 더 많은 가스비를 지급해서 의도적으로 먼저 처리되도록 한다. (Front Running)
2. 그 다음 사용자의 tx가 처리가 되도록 한다. 앞서 처리된 tx때문에 풀의 상태가 업데이트가 되었고, 이에 따라 MANA의 가격도 올라가게 된다.
3. 사용자의 tx로 인해서 MANA의 가치는 더 오르게 되었고, 바로 뒤 이어서 MANA를 전량 매도 함으로써 0.04 ETH 만큼의 이득을 볼 수 있다. (Back Running)
- 이러한 샌드위치 공격을 막기 위해서는 tx에 더 높은 가스비를 지급하거나 Defi에서 거래할 때 max slippage를 낮게 설정하는 것도 방법일 수 있다.

[샌드위치 공격의 예시](https://www.bitcoinsuisse.com/research/decrypt/arbitrage-and-frontrunning-in-defi)
- 결과적으로 `Front Running`과 `Back Running`은 블록체인 생태계에 있어서 안 좋은 영향을 끼치게 된다. `Front Running`의 경우 악의적인 사용자들이 먼저 자신의 tx가 처리되기 위해서 가스비 인상을 유도하기 때문에 **일반 사용자들은 정상적인 tx에 대해서 비싼 가스비를 지불**해야한다. 뿐만 아니라 수많은 arbitrage bot들이 시도하는 스팸성 `Back Running` 때문에, **블록체인 내에서 network congestion이 많이 발생**할 수 있다. 이는 실사용자들의 tx처리를 늦춰 사용성을 현격히 저하시킬 수 있다.
- 실제로 분석을 해보면, 가스비를 가장 많이 지불한 상위 20개의 거래에 Arbitrage Bot, Front Running Bot, Back Running Bot의 거래가 모두 포함되어 있었다고 한다.

EVM의 Mempool 이란? [[5]](https://99bitcoins.com/bitcoin/mempool/)[[6]](https://velog.io/@stella_y/BlockchainBitcoin-mining-step-by-step)
---
[Etherscan](https://etherscan.io/txsPending)

- Mempool 이라는 개념은 이더리움에만 존재하는 것이 아니다. 사실, 비트코인에서 먼저 도입된 개념으로 BIP-35에서 제안된 내용이다.
- Mempool은 **블록에 아직 추가되지 않은 검증된 tx들이 pending 되고 있는 공간**이다. Mempool은 full node가 새로운 tx를 검증한 후에 miner에 의해서 가져가기 전까지 tx들이 기다리는 공간이다. 아직 블록에 추가되지 않은 mempool에 존재하는 tx를 **unconfirmed tx**라고 부른다. Miner가 이 mempool에서 tx를 꺼내서 새로 생성하려는 블록에 추가하면 그 때 tx는 mempool에서 제거된다.

> **비트코인에서의 특징**
> - 비트코인의 블록 내부 첫 50KB에는 우선순위가 높은 tx들이 담기고, 나머지 공간에는 수수료를 높게 지불한 순서대로 tx이 담긴다. 우선순위를 결정하는 로직은 priority = sum (input value * age)/tx size 이다. 여기서 수수료를 더 높게 낸다면 더 높은 우선순위를 가질 수 있고, pending tx 상태에서 얼마나 오래 있었는지를 나타내는 age를 고려한다는 것이 특징적이다.
> - 만약 블록체인 네트워크 상황이 좋지 않아 많은 tx가 pending 상태가 되어 mempool의 용량이 차게 되면 가장 적은 수수료를 지불한 tx가 mempool에서 제거된다. 그런 tx를 **dust tx** 이라고 부른다. (참고: Dusting Attack란?)
> - 블록을 생성할 때 생기는 첫 번째 tx은 코인베이스 거래로, 블록의 생성으로 인한 보상 거래를 의미한다. 이 코인베이스는 최초에 50 BTC였지만 매 21만번째 블록 마다 반감기가 이뤄지기 때문에, 그만큼 채굴되는 코인베이스는 매 반감기마다 줄어들고 있다고 볼 수 있다.
> - miner 는 블록을 생성하게 되면 이 코인베이스에 추가로 블록 안에 있는 tx들의 fee 를 보상으로 얻게 된다. tx fee 를 계산하는 방법은 output의 총합 - input 총합 으로 계산할 수 있다.

Maximal/Miner Extractable Value (MEV) 란? [[7]](https://www.ddengle.com/mining/13100028)
---
[MEV](https://www.flickr.com/photos/hikingartist/5727282498)

### MEV 란?
- MEV란 이더리움의 블록을 생성하는 권한을 가진 채굴자가 **일반 사용자보다 더 높은 우위에 있는 포지션을 활용해 얻게 되는 이익**에서 유래되었다. 하지만, 이러한 MEV 기회를 포착하는 것은 채굴자 뿐만 아니라 이더리움의 mempool을 관찰하고 있는 `searcher`도 가능하기 때문에 후에는 'Miner'가 'Maximal'로 변환되었다.* MEV는 EVM 내 설계되어 있는mempool이 공개되어 있다는 취약점을 이용해서 얻는 이익으로, MEV에는 양성 (benign) MEV 와 악성 (malignant) MEV 가 있는데, 이 두 가지 경우 모두 사용자들 입장에서는 예상하지 못했던 **추가적인 세금**으로 볼 수 있다.
- 양성 MEV는 위에서 언급한 arbitrage bot에 의한 거래소 간 시세 차익 행위가 있고, 악성 MEV로는 샌드위치 공격이 있다. 각각에 대해서는 위에서 자세히 설명했으니까 생략한다.

> \* Miner 입장에서도 억울했던 것이 MEV의 88% searcher 에게 돌아갔고, miner 는 겨우 12%만 가져갔다. miner 입장에서는 대부분의 이익이 searcher에게 돌아가는데 MEV에 Miner 라는 단어가 들어가는 것은 억울했을 것 같다.

### 악성 MEV에 대한 해결책
- MEV 에 대한 해결책으로는 **배치 옥션**이 있다. 배치 옥션은 여러 개의 거래 내역을 일괄 처리하는 방식으로, 전통 금융시장에서는 개장 전후 거래를 처리할 때 주로 사용한다. 이 방법은 **각 블록의 결제 가격이 같도록 토큰쌍들의 가격을 정확하게 매길 수 있는 가격 결정 메커니즘**을 제공하고 있다.
> 기본적으로 이러한 문제를 해결하기 위해서 이더리움 핵심 프로토콜을 변경해야하는데, 그렇게 하는 것은 많은 변경과 합의를 거쳐야 하기 때문에 Dapp 수준에서의 프로토콜 변경이 필요하다.
- 배치 옥션은 검증자 또는 채굴자가 트랜잭션의 순서를 재배치할 수 있는 권한을 무효화시키는 역할을 한다. **배치 옥션의 결제 가격은 균일하기 때문에 거래 주문 순서는 가격에 아무런 영향을 끼치지 못한다**. 추가적으로, 배치 옥션은 사용자들에게 다음과 같은 트레이딩 기법을 제공한다.
1. gasless 제출 및 서명된 메시지를 통해 오프체인 주문. 온체인 주문이 아닌 오프체인 주문을 통하게 되면, 트랜잭션은 개별적으로 mempool 에 전송되는 대신, 추후 배치 옥션 거래시 한 번에 결제. 모든 거래가 주문과 상관없이 동일한 가격을 가지기 때문에 트랜잭션 복사가 어려워지고 재배치 또한 무의미해짐.
2. 트레이더가 다르더라도 동시에 발생한 거래에 대해 같은 가격을 적용
3. 제 3자의 유동성 풀에 의존하지 않고 욕망의 일치 'coincidence of wants'에 따라 사용자들을 직접 매칭

여담
---
***다음 스터디에서 다룰 예정 (은밀한 블록체인 사용이 가능할까?)***
### Episode 1. Mempool은 Dark Forest 다. [[11]](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest)
[Stefan Kierek](https://www.behance.net/gallery/75491081/Dark-forest)
- Dark Forest의 최상위 포식자는 Arbitrage bot 이다. 이들은 mempool 을 탐색하면서 oracle update 나 dex 거래와 같은 특정 타입의 tx를 찾아 다닌다. 그리고는 tx값을 복사해서 주소만 바꾸고 tx를 mempool에 더 높은 가스비를 주고 넣는다. 이러한 포식자들의 눈을 피하기 위해서는 customizing 된 contract 를 작성해서 배포해야 한다.
- bot의 눈을 피해 일부러 setter (contract call) 과 getter (rescue money) 두 개의 contract 로 나눠서 수행했다. setter는 getter를 사용할 수 있도록 하는 스위치 역할이고, getter는 uniswap pool 컨트랙트의 burn 이라는 함수를 호출하는 역할을 했다. 이들이 같은 블록 안에서 수행될 때 성공적으로 잘못보낸 돈을 찾을 수 있었다. 하지만, 이 사례의 경우 조금 지체하는 바람에 다른 블록에 set 따로 get 따로 담겼고, 결국 돈을 찾을 수 없게 되었다.

참고 자료
---
1. https://twitter.com/BitMEXResearch/status/1522593288502616065?cxt=HHwWgoC9qeyhq6EqAAAA
2. https://losslesscash.medium.com/your-intro-into-time-bandit-attacks-on-eth-5a578e3ae6a4
3. https://ethresear.ch/t/matching-strategy-for-multi-asset-batch-auctions/6248