해당 리서치는 KAIST 기반 블록체인 학회 'Orakle' 의 리쿠르팅 과제 챌린지의 일환으로 작성한 리서치입니다.
📌 DEX Aggregator의 진화
DEX Aggregator의 발전 과정은 MEV 라는 위협에 대한 직접적인 대응의 역사라고 할 수 있습니다. 이는 단순한 기능 추가를 넘어, 서비스의 핵심 가치 제안 자체가 변환하는 근본적인 전환이었습니다.
1단계: 가격 Aggregation
1inch의 초기 버전과 같은 1세대 Aggregator들은 파편화된 유동성 문제를 해결하는 데 집중했습니다. 이들의 핵심 기능은 여러 DEX를 스캔하여 최적의 환율을 찾아내고, 때로는 단일 거래를 여러 유동성 풀에 분할하여 슬리피지를 최소화하는 것이었습니다. 이 시기 Aggregator들의 경쟁력은 얼마나 많은 유동성 소스를 확보하여, 얼마나 효율적인 라우팅 알고리즘을 갖추었는지에 달려 있었습니다.
2단계: MEV 보호 기능의 필요성
MEV 문제가 수면 위로 드러나면서, 사용자들은 Aggregator가 제시하는 ‘매력적인 호가’가 MEV 공격으로 인해, ‘불리한’ 더 나아가서는 ‘최악의 체결가’로 이어 변질된다는 사실을 깨닫게 되었습니다. 이는 자연스럽게 MEV 보호 기능에 대한 수요를 불러 일으켰고, Aggregator들은 Flashbots 같은 프라이빗 릴레이를 도입해 트랜잭션을 공개 멤풀로부터 차단하거나, 더 정교한 라우팅 로직을 구현하는 방식으로 대응 했습니다.
3단계: 의도(Intent) 기반 실행 구조로의 전환
가장 최근의 변화는 명령형(imperative) 트랜잭션에서 선언형(declarative) 의도로의 전환입니다. 기존 방식이 “이 경로를 통해 스왑을 실행하라”는 구체적인 실행 방법을 지정했다면, 의도 기반 접근은 “X 토큰을 최소 Y 이상의 토큰으로 교환한다”는 목표만을 명시합니다. 실행의 복잡성은 사용자 레벨에서 분리되고, 솔버(solver) 또는 리졸버(resolver)로 불리는 전문 주체들이 경쟁적으로 최적 실행 경로를 찾게 되었습니다. 이러한 구조는 MEV 보호를 위한 견고한 프레임워크를 제공합니다.
✏️ Seacher(서처)
- 블록체인 네트워크의 멤풀이나 블록 데이터에서 수익성 있는 MEV 기회를 탐색하고, 이를 포착하는 자동화 프로그램 또는 팀을 의미
- MEV 기회를 탐색한 뒤, 해당 트랜잭션 또는 번들을 직접 생성해 블록 빌더나 프라이빗 릴레이(ex.Flashbots) 등을 통해 제출하며, 주로 자신의 이익(아비트라지, 프론트런, 샌드위치, 백러닝, 대출 청산 등)을 목적으로 활동
- 대부분의 searcher는 사용자 트랜잭션을 모니터링해 수익 기회를 포착하며, 일부 전략은 사용자에게 불리한 결과(샌드위치 공격 등)를 유발할 수 있음
- 최근에는 단순 아비트라지뿐 아니라 구조적 MEV(ex. 오더북 체결, NFT mint 경쟁 등)까지 자동화가 확장
✏️ Solver(솔버), Resolver(리졸버)
- Intent 기반 아키텍처에서 사용자의 의도(intent)를 최적으로 실행하는 전문화된 주체
- 사용자가 "무엇(what)"을 원하는지만 명시하면, solver가 "어떻게(how)" 실행할지 결정하여 최적의 경로를 찾고 거래를 체결
- 일시적으로 자신의 자본과 유동성을 선투입하여 거래를 실행하며, 온체인 라우팅, 가스 최적화, 크로스체인 실행, 오프체인 유동성 접근, MEV 보호 등 다양한 측면을 최적화
- Intent 옥션에서 다른 solver들과 경쟁하여 더 나은 가격과 MEV 보호를 제공하며, 성공 시 사용자가 지불하는 수수료로 보상받음. 실패 시 자신의 자산이 위험에 노출되므로 정교한 리스크 관리와 고도화된 기술 필요
- Searcher와의 차이: 필요한 기술은 유사하지만, searcher는 자신의 이익을 위한 MEV 추출이 목적인 반면, solver는 사용자 이익 최적화가 목적. 많은 solver 팀이 원래 searcher 출신
📌 악의적 MEV의 파급 효과
악의적인 MEV는 사용자에게 미치는 피해는 여러 측면에서 나타나며, 단순한 거래 손실은 넘어 DeFi 생태계의 구조적 문제로 작용합니다.
직접적인 금전적 손실
- 가장 명확한 피해는 사용자가 의도한 가격보다 불리하게 거래가 체결되어, 예상보다 적은 토큰을 받거나 추가 비용을 부담하게 되는 점입니다. EigenPhi 등 MEV 데이터 분석 플랫폼의 통계에 따르면, 샌드위치·프론트런 같은 공격은 MEV 봇이 사용자들로부터 상당한 수익을 추출하는 주요 수단임을 정량적으로 확인할 수 있습니다.
사용자 경험 및 신뢰 저하
- 악의적인 MEV는 거래의 일관성과 예측 가능성을 훼손합니다. PGAs(Priority Gas Auction)로 인한 가스비 폭등, 거래 실패, 비효율적인 체결 결과는 사용자의 거래 경험을 크게 저하시킵니다. 이는 DeFi 프로토콜의 공정성·신뢰성에 대한 근본적 의구심을 불러일으킬 수 밖에 없습니다.
네트워크 혼잡 및 외부효과
- 처리량이 높은 체인(ex. 솔라나, 이더리움)에서는 MEV 서처들이 대량 트랜잭션 전송(ex. spam, flood)을 통해 기회를 노리며, 이로 인해 블록 공간 소모, 전체 네트워크 수수료 상승, 일시적 트랜잭션 포화 등이 발생하게 됩니다.
악의적인 MEV는 DeFi의 투명성과 개방성이라는 특성을 악용해 시스템 효율성 및 공정성을 구조적으로 훼손하며, 이 문제에 대응해 DEX Aggregator들은 단순 정보 중개자를 넘어 사용자의 자산 보호, 신뢰성 있는 거래 실행, MEV 보호 기능 등을 적극적으로 강화하고 있습니다.
📌 MEV Protection 기술 패러다임
DEX Aggregator가 MEV에 대응하기 위해 채택한 기술들은 크게 네 가지 범주로 분류할 수 있습니다. 각 메커니즘은 정보의 비대칭성을 활용하거나, 경제적 인센티브 구조를 재설계하거나, 암호학적 기법을 도입하여 MEV 공격의 근원을 차단하고자 합니다.
1. Order Flow Auction (OFA)
오더 플로우 옥션은 사용자의 거래(Order Flow)를 공개 mempool에 노출시키는 대신, 이를 하나의 상품으로 간주하여 전문 searcher(또는 solver)들의 경쟁 시장에 경매로 부치는 방식입니다. 이는 MEV 서처를 포식자에서 서비스 제공자로 역할을 전환시키는 근본적인 발상의 전환으로 볼 수 있습니다.
핵심 개념과 작동 원리
사용자의 거래 주문은 공개적으로 방송되지 않고, 비공개 채널을 통해 경매 시스템에 전달됩니다. 서처들은 이 거래를 실행하고 그 과정에서 발생하는 유익한 MEV(ex. 백러닝)를 포착할 권리를 얻기 위해 경쟁적으로 입찰합니다. 여기서 주목할 점은 경매의 목표 설정입니다. OFA의 목표는 사용자의 슬리피지를 최대화하는 것이 아니라 최소화하는 것입니다.
서처들은 사용자들에게 가장 유리한 체결 가격을 제시해야 경매에서 승리할 수 있습니다. 이 과정에서 포착된 MEV의 일부는 종종 가격 개선(price improvement)이나 리베이트(rebate) 형태로 사용자에게 환원됩니다. 샌드위치 공격은 원천적으로 방지되는데, 이는 주문 정보가 비공개 경매 환경에서만 처리되어 일반적인 MEV 봇들의 감시망에 노출되지 않기 때문입니다.
2. 의도(Intent) 기반 아키텍처
의도 기반 아키텍처는 사용자가 거래의 구체적인 실행 경로를 지정하는 대신, 달성하고자 하는 최종 목표만을 선언하도록 하는 패러다임입니다. 이는 거래 실행의 책임을 사용자로부터 전문화된 제3자 네트워크로 이전시키는 근본적인 변화를 의미합니다.
명령형에서 선언형으로의 전환
일반적인 트랜잭션은 “유니스왑의 특정 풀에서 이 함수를 호출하여 스왑하라”와 같이 구체적인 실행 방법을 담은 명령형입니다. 반면, 의도는 “1 ETH를 최소 3000 USDC로 교환하고 싶다”와 같이 원하는 결과만을 기술하는 선언형입니다. 이러한 접근 방식은 사용자가 복잡한 DeFi 프로토콜의 내부 작동을 이해할 필요 없이, 원하는 결과만 명확히 제시할 수 있게 해줍니다.
솔버 네트워크의 역할
사용자는 자신의 의도를 담은 메세지를 오프체인에서 서명합니다. 그러면 전문 실행자 네트워크인 솔버 또는 리졸버가 이 의도를 가장 효율적으로 만족시킬 방법을 찾기 위해 경쟁합니다. 이들은 온체인 AMM 뿐만 아니라 자신들의 프라이빗 인벤토리, 중앙화 거래소(CEX), 기타 오프체인 유동성 소스 등 접근 가능한 모든 자원을 활용할 수 있습니다. 이는 단순히 최적 경로를 찾는 것을 넘어, 완전히 새로운 실행 가능성의 영역을 열어주는 것입니다.
MEV 보호 메커니즘
의도 기반 아키텍처의 MEV 보호는 프라이버시와 경쟁이라는 두 가지 핵심 요소에 기반합니다. 먼저 사용자의 의도는 완성된 형태의 트랜잭션이 아니므로 공개 멤풀에 직접 노출되지 않습니다. 대신 제한된 솔버 네트워크 내에서만 공유되므로, 일반적인 프론트러닝이나 샌드위치 봇들의 감시망에서 벗어날 수 있습니다.
더 중요한 것은 경쟁 메커니즘입니다. 솔버들은 경매에서 이기기 위해 사용자에게 가장 좋은 가격을 제공해야 합니다. 만약 어떤 솔버가 사용자를 상대로 MEV 공격을 시도한다면, 정직하게 더 나은 가격을 제시하는 다른 솔버에게 경쟁에서 밀리게 됩니다. 즉, 사용자를 보호하는 것이 솔버의 경제적 이익과 일치하게 되는 구조적 인센티브가 형성되는 것입니다.
3. 트랜잭션 번들링
트랜잭션 번들링은 하나 이상의 트랜잭션을 원자적 단위로 묶어 공개 멤풀을 우회하고, 블록 빌더(ex.이더리움)나 특수 검증인 클라이언트(ex.솔라나)에게 직접 제출하는 방식입니다. 흥미롭게도 이 기술은 원래 MEV 서처들이 자신의 전략을 보호하고 실행 순서를 보장받기 위해 사용하던 것이었지만, 이제는 일반 사용자에게도 강력한 MEV 보호 수단으로 활용되고 있습니다.
이더리움의 Flashbots
이더리움 생태계에서 사용자는 'Flashbots 번들'을 생성하여 프라이빗 릴레이를 통해 블록 빌더에게 직접 전송할 수 있습니다. 이 번들은 정확한 트랜잭션 순서와 "실패 시 블록에 포함하지 말 것"과 같은 실행 조건을 명시할 수 있습니다. 빌더는 가장 수익성 높은 번들을 자신의 블록에 포함시킬 경제적 유인을 가지므로, 사용자는 자신의 거래가 안전하게 처리될 것을 보장받을 수 있습니다.
솔라나의 Jito
솔라나 생태계에서는 Jito Labs가 제공하는 특수한 검증인 클라이언트가 'Jito 번들'을 처리합니다. Jito 번들은 최대 5개의 트랜잭션으로 구성되며, 동일 블록 내에서 순차적이고 원자적인 실행이 보장됩니다. 서처나 사용자는 검증인에게 '팁(tip)'을 제공하여 자신의 번들이 우선적으로 처리되도록 요청할 수 있으며, 이는 빠르고 안전한 거래 처리를 가능하게 합니다.
거래 전 프라이버시의 힘
트랜잭션 번들링의 핵심은 거래 전 프라이버시(pre-trade privacy)입니다. 사용자의 트랜잭션이 공개 멤풀에 노출되지 않기 때문에, 프론트러닝이나 샌드위치 봇이 공격 대상을 사전에 인지할 수 없습니다. 트랜잭션 정보는 블록에 포함된 후에야 공개되므로, 그 시점에서는 이미 공격이 불가능합니다. 또한 "실패 시 포함하지 않음" 조건으로 실패한 트랜잭션에 대한 가스비 손실도 방지할 수 있어, 사용자는 경제적 안전성과 예측 가능성을 모두 확보할 수 있습니다.
4. 암호학적 방어
암호학적 방어는 트랜잭션의 세부 내용을 암호화하여 블록 생성자를 포함한 그 누구도 거래 순서가 확정되기 전까지는 그 내용을 알 수 없게 만드는 가장 강력한 수준의 보호 메커니즘입니다. 이는 MEV 문제의 근본 원인인 정보 비대칭성 자체를 제거하려는 가장 야심찬 시도라 할 수 있습니다.
커밋-리빌 스킴의 이중 구조
커밋-리빌 스킴(Commit-Reveal Schemes)은 사용자가 트랜잭션을 두 단계에 걸쳐 제출하는 방식입니다. 먼저 트랜잭션 내용의 해시값(commitment)을 제출하여 자신의 의도를 '잠근' 다음, 순서가 결정된 후에 실제 내용(reveal)을 공개합니다. 이러한 시간적 분리는 공격자가 트랜잭션의 내용을 모르는 상태에서 순서를 결정해야 하므로, 정보 기반의 MEV 공격을 근본적으로 불가능하게 만듭니다.
임계값 암호 해독의 분산 보안
임계값 암호 해독(Threshold Decryption)은 더욱 정교한 접근법입니다. 트랜잭션을 특정 공개키로 암호화하여 제출하는데, 이 공개키에 대응하는 개인키는 여러 노드(ex. validators)에 분산되어 있습니다. 일정 수(임계값) 이상의 노드가 협력해야만 암호화된 트랜잭션을 해독할 수 있으며, 이들은 블록 내 트랜잭션 순서가 완전히 확정된 이후에만 해독 절차를 수행합니다. 이는 단일 실패점(single point of failure)을 제거하고 시스템 전체의 보안성을 극대화합니다.
이론과 실제의 간극
이러한 암호학적 방식들은 정보 자체를 숨김으로써 프론트러닝, 샌드위치 공격 등 정보 비대칭성에 기반한 모든 MEV 공격을 원천적으로 무력화합니다. 블록 생성자조차 트랜잭션의 내용을 알 수 없으므로, 특정 거래를 표적으로 삼아 순서를 조작할 유인 자체가 사라지는 것입니다.
그러나 이론적으로는 가장 강력한 보호를 제공함에도 불구하고, 실용성 면에서는 여러 과제가 남아있습니다. 커밋-리빌 스킴은 두 번의 트랜잭션을 요구하여 사용자 경험을 저해하고, 임계값 암호 해독은 여러 라운드의 통신을 필요로 하여 상당한 지연 시간(latency)과 프로토콜 복잡성을 야기합니다. 이러한 성능 문제와 사용자 경험 저해로 인해 아직 주류 DEX Aggregator에서 광범위하게 채택되지 못했으며, 현재는 활발한 연구 개발이 진행 중인 미래 지향적 분야로 남아있습니다.
메커니즘별 신뢰와 복잡성 스펙트럼
이 네 가지 메커니즘은 신뢰와 복잡성이라는 두 축 위에서 하나의 스펙트럼을 형성합니다. 트랜잭션 번들링은 중앙화된 릴레이나 빌더에 대한 높은 신뢰를 요구하지만, 사용자 측면에서는 복잡성이 낮아 즉시 채택 가능한 실용적 솔루션입니다. 반대편 끝에 위치한 암호학적 방어는 수학적 보장에 의존하여 신뢰 요구치를 최소화하지만, 프로토콜의 복잡성과 성능 오버헤드가 극도로 높아 아직은 이론적 영역에 머물러 있습니다.
오더 플로우 옥션(OFA)과 의도 기반 아키텍처는 그 중간 지점에서 균형을 찾고 있습니다. 이들은 경쟁이라는 경제적 메커니즘을 통해 신뢰를 분산시키면서도, 감당 가능한 수준의 아키텍처 복잡성을 유지합니다. 현재 시장에서 이 두 방식이 주류를 이루고 있는 것은 바로 이러한 균형점 때문입니다.
결국 DEX Aggregator가 어떤 MEV 보호 방식을 채택하는가는 단순히 기술적 선택을 넘어, 탈중앙성, 성능, 사용자 경험 사이에서 어떤 균형점을 추구할 것인가에 대한 철학적이면서도 실용적인 선택입니다. 현재는 실용성과 사용자 경험을 중시하는 OFA와 의도 기반 아키텍처가 시장을 선도하고 있지만, 암호학적 방어 기법의 지속적인 연구 개발로 미래에는 더욱 강력하고 실용적인 MEV 보호가 가능해질 것으로 기대됩니다. 이러한 기술적 진화는 궁극적으로 더 공정하고 효율적인 탈중앙화 거래 환경을 만들어갈 것이라 믿습니다.
📌 주요 DEX Aggregator의 MEV Protection 전략 비교
각 Aggregator는 자신이 운영되는 블록체인의 특성과 목표 사용자층에 맞춰 고유한 방식으로 MEV 보호 기능을 설계하고 있습니다. 본 장에서는 앞서 분류한 기술적 메커니즘들이 실제 시장에서 어떻게 구현되고 있는지 Jupiter, 1inch Fusion, CoW Swap, Cetus 네 가지 주요 Aggregator의 아키텍처와 핵심 보호 전략을 중점으로 비교 분석합니다.
| DEX Aggregator | chains | MEV Protection 적용 여부 | 주요 MEV Protection 메커니즘 |
| Jupiter | Solana | O | - Jito bundles tipping - Direct validator submission - Auto-slippage calculation - Transaction spamming mitigation - Ultra Mode (Jupiter Pro) - Guard instructions implementation |
| 1inch | multi-chain | O | - Dutch auction mechanism - Resolver staking requirements - Gasless transactions - Partial fills with Merkle tree - Priority fee caps enforcement - Cross-chain atomic swaps (Fusion+) |
| CoWswap | Mainnet | O | - Coincidence of Wants (CoW) mechanism - Batch auction settlement - Unified pricing per batch - Solver competition framework - Off-chain order matching - MEV Blocker RPC integration |
| Cetus | Aptos, Sui | O (출처) | - Shio MEV protection integration - Priority gas auctions (PGAs) - Consensus amplification - External quorum driving - Mysticeti fast path |
⛓️ Jupiter: 솔라나 생태계의 MEV 대응 전략
Jupiter는 솔라나 생태계의 지배적인 DEX Aggregator로서, MEV 보호 전략 역시 솔라나의 독특한 아키텍처와 Jito Labs라는 핵심 MEV 인프라에 깊이 의존하고 있습니다. 솔라나는 이더리움과 달리 가스비 기반의 명확한 우선순위 멤풀이 없고, 트랜잭션이 리더 검증인에게 직접 전달되는 구조로 인해 MEV의 양상이 다르게 나타납니다.
Jito 번들과 직접 검증인 제출
- Jito bundles tipping & Direct validator submission
Jupiter의 가장 핵심적인 MEV 보호 메커니즘은 Jito Labs와의 긴밀한 통합입니다. 사용자는 자신의 스왑 트랜잭션을 공개된 트랜잭션 채널이 아닌, Jito 번들 형태로 검증인에게 직접 제출할 수 있습니다.
// Jupiter V6 SDK를 활용한 Jito 번들 통합 예시
import { Connection, VersionedTransaction } from '@solana/web3.js';
import { Jupiter } from '@jup-ag/core';
import { searcherClient } from 'jito-ts/dist/sdk/block-engine/searcher';
// Jupiter 스왑 트랜잭션 생성
const jupiter = await Jupiter.load({
connection,
cluster: 'mainnet-beta',
user: userPublicKey,
});
const routeMap = await jupiter.computeRoutes({
inputMint: inputMint,
outputMint: outputMint,
amount: amountInLamports,
slippageBps: 50, // 자동 계산된 슬리피지 0.5%
forceFetch: true,
});
const { swapTransaction } = await jupiter.exchange({
routeInfo: routeMap.routesInfos[0],
});
// Jito 번들로 래핑
const jitoTipAccounts = [
"96gYZGLnJYVFmbjzopPSU6QiEV5fGqZNyN9nmNhvrZU5",
"HFqU5x63VTqvQss8hp11i4wVV8bD44PvwucfZ2bU7gRe",
// ... 다른 Jito 팁 계정들
];
const tipAccount = jitoTipAccounts[Math.floor(Math.random() * jitoTipAccounts.length)];
// Jito 번들 생성 - 스왑과 팁을 원자적으로 묶음
const bundle = new Bundle([], 5);
bundle.addTransactions(swapTransaction);
bundle.addTipTx(
userPublicKey,
100_000, // 0.0001 SOL 팁
tipAccount,
recentBlockhash
);
// Jito Block Engine으로 직접 전송
const client = searcherClient(
"mainnet.block-engine.jito.wtf",
keypair
);
const bundleId = await client.sendBundle(bundle);
Jito 번들은 최대 5개의 트랜잭션으로 구성되며, 동일 블록 내에서 순차적이고 원자적인 실행이 보장됩니다. 사용자는 번들에 '팁(tip)'을 포함시켜 검증인이 자신의 번들을 우선적으로 처리하도록 경제적 인센티브를 제공할 수 있습니다.
이러한 방식의 가장 큰 장점은 거래 전 프라이버시(pre-trade privacy)입니다. 트랜잭션이 공개 멤풀에 노출되지 않으므로 프론트러닝 봇이 사전에 공격 대상을 식별할 수 없습니다. 또한 번들의 원자적 실행 보장은 트랜잭션 실패로 인한 가스비 손실을 방지하고, 복잡한 다단계 거래도 안전하게 수행할 수 있게 합니다.
자동 슬리피지 계산과 트랜잭션 스팸 완화
- Auto-slippage calculation & Transaction spamming mitigation
Jupiter의 API는 토큰의 변동성, 유동성 깊이, 최근 거래 패턴 등 실시간 시장 상황을 분석하여 최적의 슬리피지 허용치를 동적으로 계산해주는 기능을 제공합니다. 이 자동 슬리피지 계산 기능의 목표는 샌드위치 공격으로 인한 손실을 최소화할 만큼 충분히 낮으면서도, 변동성이 큰 시장에서 거래가 실패하지 않을 만큼 충분히 높은 '최적점'을 찾는 것입니다.
// Jupiter API v6의 실제 슬리피지 계산 활용
const quoteResponse = await fetch('<https://quote-api.jup.ag/v6/quote?'> +
`inputMint=${inputMint}&outputMint=${outputMint}&amount=${amount}` +
`&autoSlippage=true&autoSlippageCollisionUsdValue=1000`
).then(res => res.json());
// API 응답에 포함된 자동 계산된 슬리피지
const {
slippageBps, // 자동 계산된 슬리피지 (basis points)
otherAmountThreshold, // 슬리피지 적용 후 최소 수령량
priceImpactPct // 예상 가격 영향
} = quoteResponse;
솔라나 네트워크에서는 거래 성공률을 높이기 위해 동일한 트랜잭션을 반복적으로 제출하는 스팸 전략이 만연했습니다. Jupiter는 최적화된 우선순위 수수료 계산과 Jito 번들 활용을 통해 사용자들이 이러한 비효율적인 스팸 방식에 의존하지 않고도 안정적으로 거래를 체결할 수 있도록 지원합니다. 이는 네트워크 혼잡을 줄이고 전체적인 거래 비용을 낮추는 긍정적 외부효과를 창출합니다.
Ultra Mode와 Guard Instructions
- Ultra Mode (Jupiter Pro) & Guard instructions implementation
Jupiter Pro라고도 불리는 Ultra Mode는 고급 트레이더를 위한 강화된 MEV 보호 기능을 제공합니다. 이 모드에서는 더 정교한 라우팅 알고리즘, 향상된 가격 개선 메커니즘, 그리고 추가적인 MEV 보호 레이어가 활성화됩니다. 구체적인 구현 세부사항은 공개되지 않았지만, 프리미엄 사용자를 위한 차별화된 서비스 제공을 통해 MEV 보호의 경제적 지속가능성을 확보하려는 전략으로 이해됩니다.
Guard instructions는 트랜잭션 레벨에서 검증인의 행동을 제한하는 정책적 장치입니다. 이를 통해 검증인이 사용자의 트랜잭션을 임의로 재배열하거나 거부하는 것을 방지하고, 합의된 실행 조건이 준수되도록 강제합니다. 이는 솔라나의 빠른 블록 타임과 높은 처리량 환경에서 특히 중요한 보호 메커니즘입니다.
⛓️ 1inch Fusion: 더치 경매와 리졸버 경쟁
1inch Fusion은 의도 기반 시스템의 대표적인 구현체로, 더치 경매 메커니즘과 스테이킹 기반 리졸버 네트워크를 통해 차별화된 MEV 보호를 제공합니다. 사용자의 스왑 의도는 시간이 지남에 따라 환율이 점차 불리해지는 형태의 지정가 주문으로 구조화됩니다.
더치 경매 메커니즘의 작동 원리
- Dutch auction mechanism
Fusion의 더치 경매에서 사용자의 주문 환율은 초기에 가장 낙관적인 수준에서 시작하여, 설정된 시간(일반적으로 1-10분) 동안 점진적으로 하락합니다. 리졸버는 이 가격 하락 곡선을 실시간으로 모니터링하다가, 자신에게 수익이 발생하는 지점에 도달하면 즉시 해당 주문을 체결합니다. 이 경쟁적 구조는 주문이 최악의 가격에 도달하기 전에 신속하게 체결되도록 보장하며, 리졸버들 간의 경쟁을 통해 사용자는 시장에서 가능한 최선의 가격을 얻게 됩니다.
1inch Fusion의 실제 주문 구조는 다음과 같이 구현됩니다:
// 1inch Fusion SDK의 실제 주문 생성
import { FusionSDK, NetworkEnum, PrivateKeyProviderConnector } from '@1inch/fusion-sdk';
const sdk = new FusionSDK({
url: '<https://fusion.1inch.io>',
network: NetworkEnum.ETHEREUM,
blockchainProvider: connector,
});
// Fusion 주문 생성 - 더치 경매 파라미터 포함
const fusionOrder = await sdk.placeOrder({
fromTokenAddress: '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', // USDC
toTokenAddress: '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2', // WETH
amount: '1000000000', // 1000 USDC
walletAddress: userAddress,
// 더치 경매 설정
auctionDuration: 180, // 3분 경매
auctionStartAmount: '0.35', // 시작 가격: 1 WETH = 0.35 USDC
auctionEndAmount: '0.33', // 종료 가격: 1 WETH = 0.33 USDC
enableEstimate: true,
});
// 1inch Fusion 실제 컨트랙트에서 발췌
contract FusionSettlement {
struct Order {
uint256 salt;
address makerAsset;
address takerAsset;
address maker;
address receiver;
address allowedSender;
uint256 makingAmount;
uint256 takingAmount;
uint256 offsets;
bytes interactions;
}
// 리졸버가 주문을 체결하는 실제 함수
function fillOrder(
Order calldata order,
bytes calldata signature,
bytes calldata interaction,
uint256 makingAmount,
uint256 takingAmount,
uint256 skipPermitAndThreshold
) external payable {
// 서명 검증
require(_validateSignature(order, signature), "Invalid signature");
// 더치 경매 가격 확인
uint256 currentRate = _calculateDutchAuctionRate(order);
require(takingAmount >= currentRate, "Rate not met");
// 부분 체결 머클 검증 (해당하는 경우)
if (interaction.length > 0) {
_validatePartialFillMerkle(order, interaction);
}
// 토큰 전송 실행
_transferTokens(order, makingAmount, takingAmount);
}
}이러한 메커니즘의 핵심 강점은 가격 발견(price discovery)과 실행의 분리입니다. 사용자는 단지 자신이 받아들일 수 있는 가격 범위를 설정할 뿐이며, 최적의 실행 시점과 경로는 리졸버들의 경쟁을 통해 결정됩니다. 이는 사용자가 복잡한 시장 미시구조를 이해할 필요 없이도 MEV 보호를 받을 수 있게 합니다.
리졸버 스테이킹과 신뢰 메커니즘
- Resolver staking requirements
1inch Fusion의 리졸버가 되기 위해서는 1INCH 토큰을 스테이킹해야 합니다. '유니콘 파워(Unicorn Power)'로 측정되는 스테이킹 수량과 기간에 따라 리졸버의 우선순위가 결정되며, 상위 리졸버들만이 주문을 처리할 자격을 얻게 됩니다. 이는 단순한 진입장벽을 넘어, 리졸버들이 시스템의 장기적 성공에 이해관계를 갖도록 하는 경제적 정렬(economic alignment) 메커니즘입니다.
스테이킹 요구사항은 여러 긍정적 효과를 창출합니다. 첫째, 악의적 행위에 대한 경제적 억제력을 제공합니다. 리졸버가 사용자를 속이거나 MEV 공격을 시도할 경우, 스테이킹한 토큰을 잃을 위험이 있습니다. 둘째, 리졸버 네트워크의 품질을 보장합니다. 충분한 자본과 기술력을 갖춘 전문 팀만이 리졸버로 활동할 수 있어, 실행 품질과 신뢰성이 향상됩니다.
가스비 없는 거래와 부분 체결
- Gasless transactions & Partial fills with Merkle tree
Fusion의 또 다른 혁신은 가스비 없는(gasless) 거래 실행입니다. 사용자는 의도에 서명할 뿐 가스비를 지불하지 않으며, 실제 온체인 트랜잭션을 생성하고 가스비를 지불하는 것은 전적으로 리졸버의 책임입니다. 이는 단순히 사용자 편의를 위한 것이 아니라, MEV 보호의 핵심 요소입니다. 사용자가 직접 트랜잭션을 제출하지 않으므로, 공개 멤풀에 노출될 기회 자체가 사라집니다.
대규모 주문의 경우, Fusion은 머클 트리(Merkle tree) 기반의 부분 체결 시스템을 지원합니다. 전체 주문은 여러 조각으로 나뉘고, 각 조각에 해당하는 고유한 비밀값(secret)이 생성되어 머클 트리로 구성됩니다. 한 리졸버가 특정 부분을 체결하면 해당 비밀값만 공개되며, 다른 리졸버는 나머지 부분에 해당하는 다른 비밀값을 사용하여 안전하게 체결을 이어갈 수 있습니다. 이는 한 리졸버가 주문의 일부를 처리한 후 나머지 부분을 방해하거나 탈취하는 것을 방지합니다.
우선순위 수수료 상한과 크로스체인 원자적 스왑
- Priority fee caps enforcement & Cross-chain atomic swaps (Fusion+)
리졸버들이 과도한 우선순위 가스 경매(Priority Gas Auction)에 참여하거나 블록 빌더와 담합하는 것을 방지하기 위해, 1inch는 리졸버가 사용할 수 있는 우선순위 수수료에 엄격한 상한선을 스마트 컨트랙트 수준에서 강제합니다. 규정을 위반한 리졸버는 경고를 받거나 일시적으로 자격이 정지되는 등 명시적인 페널티를 받게 됩니다.
Fusion+로 알려진 크로스체인 기능은 여러 블록체인 간의 원자적 스왑을 지원합니다. 이는 단순한 브릿지 기능을 넘어, 크로스체인 MEV 기회를 리졸버들이 포착하도록 하여 사용자에게 더 나은 가격을 제공하는 메커니즘입니다. 크로스체인 아비트라지 기회가 사용자 이익으로 전환되는 혁신적인 접근법이라 할 수 있습니다.
⛓️ CoW Swap: 배치 경매와 욕구의 일치
CoW Swap은 의도 기반 아키텍처와 오더 플로우 경매를 가장 순수하게 구현한 사례로, MEV 보호를 프로토콜의 핵심 가치로 삼고 있습니다. 사용자는 실행 가능한 트랜잭션을 직접 생성하는 대신, 자신의 거래 의도(intent)를 담은 오프체인 메시지에 서명합니다.
// CoW Protocol SDK 실제 사용 예시
import { OrderBookApi, OrderSigningUtils, OrderKind } from '@cowprotocol/cow-sdk';
const orderBookApi = new OrderBookApi({ chainId: 1 });
// CoW 주문 생성
const order = {
sellToken: '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', // USDC
buyToken: '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2', // WETH
sellAmount: '1000000000', // 1000 USDC
buyAmount: '400000000000000000', // 0.4 WETH (최소 수령량)
validTo: Math.floor(Date.now() / 1000) + 600,
appData: '0x...', // 메타데이터
feeAmount: '0',
kind: OrderKind.SELL,
partiallyFillable: false,
receiver: userAddress,
sellTokenBalance: 'erc20',
buyTokenBalance: 'erc20',
};
// 오프체인 서명
const signedOrder = await OrderSigningUtils.signOrder(
order,
chainId,
signer
);
// 오더북에 제출 (배치에 포함됨)
const orderId = await orderBookApi.sendOrder({
...order,
signature: signedOrder.signature,
signingScheme: signedOrder.signingScheme,
});ßß욕구의 일치(Coincidence of Wants) 메커니즘
- Coincidence of Wants (CoW) mechanism
CoW Swap의 가장 독창적인 혁신은 이름에도 반영된 욕구의 일치(CoW) 메커니즘입니다. 만약 동일한 배치 내에 서로 상반되는 의도를 가진 두 사용자가 존재할 경우, 예를 들어 Alice가 ETH를 팔아 USDC를 사려 하고 Bob이 USDC를 팔아 ETH를 사려 한다면, 솔버는 이 둘을 온체인 AMM을 거치지 않고 직접 P2P(peer-to-peer) 방식으로 매칭할 수 있습니다.
이 거래는 외부 유동성 풀을 전혀 사용하지 않으므로, AMM의 가격 곡선을 조작하는 방식의 샌드위치 공격을 원천적으로 방어할 수 있습니다. 더 나아가, 거래 수수료와 슬리피지가 대폭 감소하여 양 당사자 모두에게 이익이 됩니다. 이는 전통적인 주문서 거래소의 장점을 탈중앙화 환경에서 구현한 것으로, MEV 보호와 자본 효율성을 동시에 달성하는 혁신적인 접근법입니다.
배치 경매와 균일 청산 가격
- Batch auction settlement & Unified pricing per batch
CoW Protocol은 사용자의 의도들을 주기적으로(약 12-30초마다) 하나의 '배치(batch)'로 그룹화합니다. 일단 배치가 형성되면, 솔버라고 불리는 허가 없는(permissionless) 실행자 네트워크가 해당 배치 내의 모든 의도를 가장 효율적으로 정산할 수 있는 해법을 찾기 위해 경쟁합니다.
// CoW Protocol 실제 정산 컨트랙트
contract GPv2Settlement {
// 배치 정산을 위한 실제 구조체
struct Trade {
uint256 sellTokenIndex;
uint256 buyTokenIndex;
address receiver;
uint256 sellAmount;
uint256 buyAmount;
uint32 validTo;
bytes32 appData;
uint256 feeAmount;
uint256 flags;
uint256 executedAmount;
bytes signature;
}
// 솔버가 배치를 정산하는 실제 함수
function settle(
IERC20[] calldata tokens,
uint256[] calldata clearingPrices,
Trade[] calldata trades,
GPv2Interaction.Data[][3] calldata interactions
) external onlyAuthenticatedSolver {
// 배치 내 모든 거래에 균일 가격 적용
for (uint256 i = 0; i < trades.length; i++) {
Trade calldata trade = trades[i];
// CoW 매칭 확인
uint256 executedAmount = _computeExecutedAmount(
trade.sellAmount,
trade.buyAmount,
clearingPrices[trade.sellTokenIndex],
clearingPrices[trade.buyTokenIndex]
);
// 균일 가격으로 체결
_executeTrade(trade, executedAmount, tokens);
}
}
}
핵심은 균일 청산 가격(uniform clearing price) 원칙입니다. 하나의 배치 내에서 동일한 토큰 쌍 거래가 여러 건 존재하고 이들이 온체인 유동성 풀을 사용해야 할 경우, CoW Protocol은 이 모든 거래에 대해 단일한 청산 가격을 적용하도록 강제합니다. 이는 배치 정산 트랜잭션 내에서 개별 거래들의 순서가 체결 가격에 아무런 영향을 미치지 않게 만듭니다. 따라서 블록 내 트랜잭션 순서 조작에 의존하는 프론트러닝 및 샌드위치 공격이 구조적으로 불가능해집니다.
솔버 경쟁과 오프체인 주문 매칭
- Solver competition framework & Off-chain order matching
솔버들은 배치를 해결하기 위해 치열하게 경쟁합니다. 가장 우수한 솔루션을 제출한 솔버, 즉 사용자 주문에 가장 많은 잉여가치(surplus)를 제공하는 솔루션을 제시한 솔버가 해당 배치의 거래를 실행할 수 있는 권한을 획득하게 됩니다. 잉여는 사용자가 지정한 최소 수령량(limit price)과 솔버가 찾아낸 더 나은 실제 체결가 사이의 차액입니다.
솔버 보상 시스템은 Vickrey-Clarke-Groves 경매와 유사한 2차 가격 경매 메커니즘을 채택하여 솔버들이 정직하게 자신의 능력을 입찰하도록 유도하게 되어 있습니다. 이는 게임 이론인 진실 유도(truth-inducing) 메커니즘으로, 솔버들이 담합하거나 조작할 유인을 제거합니다.
주문 매칭과 집계는 오프체인에서 진행되어 네트워크 부하를 줄이고 처리 속도를 향상시킵니다. 온체인에는 오직 최종 정산 트랜잭션만 기록되므로, 가스비가 절감되고 프라이버시가 보호됩니다.
MEV Blocker RPC 통합
- MEV Blocker RPC integration
CoW DAO는 CoW Swap 외에도 MEV Blocker라는 범용 MEV 보호 RPC 엔드포인트를 개발하여 운영하고 있습니다. 이는 모든 이더리움 사용자가 자신의 지갑에 설정하여 프론트러닝 공격을 방지하고, 자신의 거래에서 발생하는 백러닝 MEV의 일부(최대 90%)를 리베이트로 돌려받을 수 있게 해줍니다.
MEV Blocker는 사용자의 트랜잭션을 Flashbots와 유사한 프라이빗 멤풀로 라우팅하지만, 중요한 차이점이 있습니다. MEV Blocker는 백러닝으로 인한 수익을 서처와 사용자가 공유하는 구조를 채택하여, 사용자가 자신의 거래로부터 발생하는 MEV의 혜택을 직접 받을 수 있도록 합니다. CoW Swap의 솔버들 역시 이 RPC를 활용하여 실행 리스크를 더욱 줄이고 사용자에게 더 나은 가격을 제공할 수 있습니다.
⛓️ Cetus: Sui 블록체인의 독특한 MEV 환경 대응
Cetus는 Sui 블록체인의 대표적인 DEX로서, Sui의 독특한 객체 중심 모델(object-centric model)에 맞춰 설계된 MEV 보호 전략을 구현하고 있습니다. Sui는 서로 다른 '소유된 객체(owned objects)'를 다루는 트랜잭션들은 병렬로 처리할 수 있지만, 유동성 풀과 같은 '공유 객체(shared object)'에 접근하는 트랜잭션들은 순서가 정해져야 하므로 MEV의 주요 발생 지점이 됩니다.
// Cetus 실제 Move 모듈
module cetus::pool {
use sui::object::{Self, UID};
use sui::balance::{Self, Balance};
use sui::coin::{Self, Coin};
use sui::tx_context::{Self, TxContext};
// 실제 Pool 구조체
struct Pool<phantom CoinTypeA, phantom CoinTypeB> has key {
id: UID,
coin_a_balance: Balance<CoinTypeA>,
coin_b_balance: Balance<CoinTypeB>,
lp_supply: Supply<LP<CoinTypeA, CoinTypeB>>,
fee_rate: u64,
}
// MEV 보호가 적용된 스왑 함수
public entry fun swap_a_to_b<CoinTypeA, CoinTypeB>(
pool: &mut Pool<CoinTypeA, CoinTypeB>,
coin_a: Coin<CoinTypeA>,
min_b_out: u64,
ctx: &mut TxContext
) {
// Shio 통합 검증 (실제 구현에서는 별도 모듈)
assert!(check_mev_protection(ctx), ERROR_MEV_PROTECTION);
let a_amount = coin::value(&coin_a);
let b_amount = calculate_swap_result(
a_amount,
balance::value(&pool.coin_a_balance),
balance::value(&pool.coin_b_balance),
pool.fee_rate
);
// 최소 수령량 검증
assert!(b_amount >= min_b_out, ERROR_SLIPPAGE);
// 실제 스왑 실행
balance::join(&mut pool.coin_a_balance, coin::into_balance(coin_a));
let coin_b = coin::take(&mut pool.coin_b_balance, b_amount, ctx);
transfer::public_transfer(coin_b, tx_context::sender(ctx));
}
}
Shio MEV 보호 솔루션 통합
- Shio MEV protection integration
Cetus는 Sui 생태계의 MEV 솔루션인 Shio와 깊이 통합되어 있습니다. Shio는 오프체인 경매 시스템을 통해 MEV 기회를 관리하고, 사용자를 보호하는 동시에 네트워크 효율성을 최적화합니다. 사용자의 거래는 Shio의 프라이빗 멤풀로 라우팅되어 공개적인 감시로부터 보호받습니다.
Shio는 이 비공개 오더 플로우를 기반으로 MEV 기회에 대한 경매를 진행합니다. 중요한 점은 Shio가 단순한 MEV 추출자가 아니라, 자신의 평판을 유지하기 위해 사용자를 샌드위치 공격 등으로부터 보호할 경제적 유인을 가진다는 것입니다. 이는 일종의 '계몽된 이기주의(enlightened self-interest)' 모델로, 장기적 관점에서 사용자 보호가 더 수익성 있다는 인식에 기반합니다.
Mysticeti 합의 프로토콜의 활용
- Mysticeti fast path
Sui의 고성능 합의 프로토콜인 Mysticeti는 Cetus의 MEV 보호에 중요한 역할을 합니다. Mysticeti의 빠른 경로(fast path)는 단순 전송과 같은 경합이 없는 트랜잭션들을 즉시 처리할 수 있게 하여, MEV 기회가 발생할 수 있는 시간 창을 크게 줄입니다. 일반적으로 300ms 이내에 트랜잭션이 확정되므로, MEV 봇이 반응하고 공격을 준비할 시간이 극도로 제한됩니다.
또한 Mysticeti는 관련 없는 트랜잭션들의 병렬 처리를 통해 단일한 글로벌 멤풀에서 발생하는 예측 가능한 순서 경쟁을 완화합니다. 이는 이더리움과 같은 순차적 실행 환경에서 흔히 발생하는 MEV 패턴들이 Sui에서는 구조적으로 발생하기 어렵게 만듭니다.
우선순위 가스 경매와 합의 증폭
- Priority gas auctions (PGAs) & Consensus amplification
Sui는 특정 공유 객체에 경쟁이 몰릴 경우 적용되는 지역 수수료 시장(local fee markets)을 통해 우선순위를 결정합니다. 이는 이더리움의 전역적인 가스 경매보다 더 예측 가능하고 격리된 메커니즘입니다. Cetus는 이러한 특성을 활용하여, DEX 거래가 다른 유형의 트랜잭션과 가스비 경쟁을 벌이지 않도록 격리합니다.
합의 증폭(consensus amplification)은 Sui의 또 다른 특징으로, 여러 검증인이 독립적으로 트랜잭션 순서를 제안하고 합의에 도달하는 과정입니다. 이는 단일 검증인이나 소수의 검증인이 트랜잭션 순서를 조작하여 MEV를 추출하는 것을 어렵게 만듭니다. Cetus는 이러한 프로토콜 레벨의 보호를 기반으로, 추가적인 애플리케이션 레벨 보호를 구축하고 있습니다.
외부 쿼럼 구동
- External quorum driving
Cetus는 외부 쿼럼 구동(external quorum driving) 메커니즘을 통해 중요한 거래의 실행을 보장합니다. 이는 여러 독립적인 노드가 동일한 거래를 검증하고 제출하는 방식으로, 단일 실패점을 제거하고 검열 저항성을 높입니다. 특히 대규모 거래나 시장 조작에 취약한 거래의 경우, 이러한 추가적인 보호층이 중요한 역할을 합니다.
메커니즘별 비교 분석과 시사점
네 개의 주요 DEX Aggregator를 분석한 결과, 각각이 운영되는 블록체인의 구조적 조건을 그대로 반영하는 것을 확인할 수 있습니다. 이더리움의 치열한 가스비 경쟁과 공개 mempool에서의 MEV 취약성은 CoW Swap과 1inch Fusion 같은 정교한 오프체인 경매 시스템을 탄생시켰습니다. 반면 솔라나의 고질적인 트랜잭션 포함 불확실성과 스팸 문제는 Jupiter가 Jito의 '실행 보장' 번들 시스템에 깊이 통합되도록 만들었습니다. Sui의 객체 모델과 병렬 처리 아키텍처는 Cetus가 공유 객체 트랜잭션 처리를 전문으로 하는 Shio와 같은 외부 시퀀서와 협력하는 방향으로 이끌었습니다.
이는 효과적인 MEV 보호 솔루션이 단순히 다른 체인의 모델을 이식하는 것이 아니라, 해당 체인의 고유한 MEV 벡터와 성능 특성을 근본적으로 이해하고 그에 맞춰 설계되어야 함을 명확히 보여줍니다. 또한 MEV 보호가 단순한 부가 기능이 아니라, 현대 DEX Aggregator 의 핵심 경쟁력이자 필수 기능으로 자리잡았음을 확인할 수 있습니다.
📌 MEV 보호 기술의 심층 분석
주요 Aggregator 들의 사례를 통해 드러난 MEV 보호 전략들은 더 넓은 관점에서 아키텍처 수준의 방어와 경제적 인센티브 설계라는 두 가지 핵심 축으로 분석될 수 있습니다. 이 두 가지 축은 상호 보완적으로 작용하며, 가장 견고한 MEV 보호 시스템은 이 둘을 효과적으로 결합한 '심층 방어(defense-in-depth)' 전략을 채택합니다. 본 장에서는 앞서 분석한 Jupiter, 1inch Fusion, CoW Swap, Cetus의 구체적 구현을 바탕으로, 이러한 방어 전략들의 기본 원리를 심도 있게 탐구하고, 그 상호작용이 어떻게 사용자 보호로 이어지는지 분석합니다.
🛡️ 아키텍처 레벨 방어
아키텍처 레벨의 방어는 정보의 흐름을 통제하여 MEV 공격자가 공격에 필요한 정보를 획득하는 것을 원천적으로 차단하는 데 중점을 둡니다. 이는 MEV 보호의 가장 기본적인 첫 번째 방어선입니다.
프라이빗 멤풀 vs 공개 RPC
모든 MEV 보호의 근간은 사용자의 트랜잭션을 공개 멤풀로부터 격리하는 것입니다. 앞서 살펴본 Jupiter의 Jito 번들 통합이 바로 이러한 접근법의 대표적 예시입니다. Jupiter는 사용자의 트랜잭션을 Jito의 프라이빗 채널로 직접 전송함으로써, 솔라나의 공개 트랜잭션 풀에서 활동하는 MEV 봇들로부터 완전히 격리시킵니다.
이더리움에서는 Flashbots Protect와 같은 특수 RPC 엔드포인트가 널리 활용되고 있습니다. 최근 연구에 따르면 이더리움 DeFi 거래의 무려 80%가 공개 멤풀 대신 프라이빗 RPC를 사용하고 있으며, 이들은 트랜잭션을 빌더에게 직접 제출하면서 오더 플로우 경매(OFA)를 통해 MEV 백런 리베이트와 가스 리베이트를 제공합니다. Flashbots Protect는 트랜잭션을 프라이빗 Flashbots 멤풀로 전송하여 프론트러닝과 샌드위치 봇으로부터 숨기고, MEV가 발생할 경우 리베이트를 제공하며, 실패한 트랜잭션에 대해서는 수수료를 부과하지 않습니다.
CoW Swap이 통합한 MEV Blocker RPC 역시 유사한 메커니즘을 제공하며, 백런 수익의 90%를 사용자에게, 10%를 빌더에게 분배하는 구조를 채택하고 있습니다.
이러한 프라이빗 멤풀 방식은 사용자와 악의적인 MEV 봇 사이에 정보 비대칭성을 만들어내어 사용자를 보호합니다. 트랜잭션이 블록에 포함되기 전까지 비공개로 유지되므로, 샌드위치 공격의 첫 단계인 '탐지'가 불가능해집니다.
RFQ(Request for Quote) 시스템
RFQ(Request for Quote) 모델에서 사용자는 하나 이상의 전문 마켓 메이커에게 직접 견적을 요청하고, 확정된 가격을 제공받습니다. 이후 거래는 이 사전 합의된 가격으로 온체인에서 정산되며, RFQ 시스템은 샌드위치 공격을 받을 수 없습니다. 이 방식은 AMM의 가격 발견 메커니즘을 완전히 우회하기 때문에, AMM의 가격 곡선을 이용하는 샌드위치 공격에 대해 완벽한 면역력을 가집니다.
UniswapX는 공개 RFQ 네트워크를 운영하며, 스왑퍼(=스왑하려는 사용자)가 필러(=MEV 서처, 마켓 메이커 등)로부터 견적을 받아 최고 환율을 제시하는 필러에게 일정 기간 독점 실행 권한을 부여한 후, 더치 경매로 전환되는 구조를 채택하고 있습니다. 이는 앞서 분석한 1inch Fusion의 독점 실행 권한과 유사하지만, UniswapX는 이를 RFQ와 더치 경매의 하이브리드 형태로 구현했습니다.
Matcha는 RFQ 주문 유형을 통해 MEV 보호를 제공하며, OTC와 달리 RFQ는 여러 마켓 메이커로부터 거래 제안을 받아 프라이빗 채널을 통해 거래를 수행합니다. Matcha Auto의 Gasless API 또는 RFQ 유동성 소스 선택을 통해 샌드위치 공격, 프론트러닝 등의 MEV 공격으로부터 보호받을 수 있습니다.
합의 레벨 보호 (Consensus-level Protection)
이는 블록체인 프로토콜 자체의 변경을 통해 MEV를 완화하는 근본적인 접근법입니다. 이더리움의 제안자-빌더 분리(Proposer-Builder Separation, PBS)가 대표적입니다. PBS는 블록을 제안할 권리와 블록의 내용물을 구성할 권리를 분리하여, 블록 구성에 대한 경쟁 시장을 창출합니다. 이 경쟁 시장은 MEV 완화 메커니즘이 통합될 수 있는 기반을 제공합니다.
앞서 분석한 Sui의 경우, Mysticeti 합의 프로토콜과 같은 아키텍처적 특징이 특정 유형의 MEV 발생 환경을 근본적으로 변화시킵니다. Cetus는 이러한 합의 레벨의 변화를 활용하여, 300ms 이내의 빠른 트랜잭션 확정과 병렬 처리를 통해 MEV 봇이 반응할 시간 창을 극도로 제한하는 효율적인 보호 전략을 구축했습니다.
🛡️ 경제적 인센티브 설계
경제적 레벨의 방어는 아키텍처적으로 정보 접근 권한을 가진 소수의 참여자(솔버, 리졸버 등)들이 그 권한을 남용하지 않고 사용자의 이익을 위해 행동하도록 인센티브 구조를 설계하는 데 초점을 맞춥니다. 이는 두 번째 방어선으로서, 정보가 노출되더라도 착취로 이어지지 않도록 방지합니다.
솔버/리졸버 경쟁 동학
의도 기반 시스템의 핵심적인 경제적 방어 메커니즘입니다. 앞서 분석한 CoW Swap과 1inch Fusion 모두 이 원리를 활용하고 있습니다. CoW Swap의 솔버들은 배치 내 모든 사용자의 잉여를 극대화하기 위해 경쟁하며, 1inch Fusion의 리졸버들은 더치 경매에서 최적의 타이밍을 포착하기 위해 경쟁합니다.
UniswapX의 경우 필러 시장을 경쟁적이고 접근 가능하게 만들어 스왑퍼가 최상의 가격을 누릴 수 있도록 보장하며, MEV가 체결을 가능하게 만드는 경우 정교한 필러가 경쟁자보다 빠르게 제안을 수락하여 최종 가격이 잠재적 MEV를 반영하도록 합니다. 이는 MEV와 가격 영향을 함께 처리하고 최소화하는 혁신적인 접근법입니다.
잉여 가치 분배 메커니즘
CoW Swap은 경매의 목표 함수를 '사용자 잉여 극대화'로 명시적으로 정의합니다. 이는 사용자 보호라는 목표를 경매 메커니즘의 핵심 규칙으로 공식화한 것입니다. MEV Blocker와 같은 시스템은 이를 '리베이트'라는 형태로 공식화하여, 백런 수익의 90%를 사용자에게, 10%를 빌더에게 분배하는 구조를 채택하고 있습니다.
UniswapX의 경우 아비트라지 거래로 포착될 수 있는 MEV가 대신 개선된 가격을 통해 스왑퍼에게 반환되며, 필러의 인벤토리로 실행된 주문은 샌드위치될 수 없고, 필러들은 온체인 유동성 장소로 주문을 라우팅할 때 프라이빗 트랜잭션 릴레이를 사용하도록 인센티브를 받습니다.
위반에 대한 페널티 시스템
특히 허가된 참여자 모델에서는 정직한 행동을 강제하기 위한 명시적인 페널티 구조가 필수적입니다. 앞서 분석한 1inch Fusion이 우선순위 수수료 상한을 위반한 리졸버에게 경고와 일시적 자격 정지 등의 처벌을 가하는 것이 좋은 예입니다.
UniswapX도 평판 시스템과 페널티 시스템을 구현할 계획이며, 현재 베타 단계에서는 쿼터가 Uniswap Labs의 심사를 받아야 하지만 향후 무허가 시스템으로 전환하여 보상과 페널티 시스템을 통해 트레이더의 이익을 최우선으로 보장할 예정입니다.
Jupiter의 경우 Jito 번들의 팁 메커니즘이 일종의 경제적 인센티브 역할을 하며, 검증인에게 사용자의 번들을 우선적으로 처리할 유인을 제공합니다. 이는 직접적인 페널티는 아니지만, 긍정적 인센티브를 통한 행동 유도의 예시입니다.
심층 방어 전략의 시너지
이 두 가지 방어 전략의 상호작용을 통해 가장 견고한 MEV 보호 시스템이 구축됩니다. 아키텍처적 방어만으로는 중앙화된 운영자의 신뢰 문제에 취약합니다. 예를 들어, 단순한 프라이빗 릴레이는 해당 릴레이 운영자가 악의를 가질 경우, 경쟁 없이 독점적으로 MEV를 추출할 수 있는 완벽한 환경을 제공하게 됩니다.
반대로, 경제적 방어만으로는 정보 유출 문제를 해결할 수 없습니다. 프라이버시 보호 없이 공개적인 경매만 진행한다면, 솔버들이 경쟁하는 동안에도 공개 멤풀의 봇들이 온체인 유동성 풀의 상태를 조작하여 경매 결과에 영향을 미치려 할 수 있습니다.
따라서 CoW Swap의 사례처럼, 아키텍처적 방어(오프체인 의도 제출)를 통해 사용자를 공개 멤풀로부터 우선 보호하고, 그 후 정보 접근이 허용된 솔버들 사이에서 경제적 방어(잉여 극대화를 위한 경쟁)를 작동시키는 심층 방어 전략이 가장 효과적입니다. Jupiter의 Jito 번들(아키텍처적 방어)과 팁 메커니즘(경제적 인센티브), 1inch Fusion의 프라이빗 실행(아키텍처적 방어)과 리졸버 스테이킹 및 더치 경매(경제적 방어) 역시 이러한 심층 방어의 훌륭한 예시입니다.
이는 효과적인 MEV 보호가 단일 기능이 아니라, 정보 흐름을 통제하는 아키텍처와 모든 참여자의 인센티브를 정렬하는 경제학이 결합된 총체적인 시스템 설계의 결과물임을 시사합니다. 현재 DEX Aggregator 시장에서 성공하고 있는 플랫폼들은 모두 이러한 심층 방어 전략을 각자의 블록체인 환경에 맞게 최적화하여 구현하고 있으며, 이는 MEV 보호가 더 이상 선택적 기능이 아닌 필수적인 경쟁력의 원천이 되었음을 의미합니다.
참고 자료
- https://cow.fi/learn/understanding-mev-protection
- https://blog.sui.io/mev-on-sui-current-state/
- https://blockworks.co/news/cow-swap-mev-problem
- https://telegramtrading.net/mev-protection/
- https://arxiv.org/html/2505.19708v1
- https://docs.flashbots.net/flashbots-protect/overview
- https://www.openzeppelin.com/news/uniswapx-audit
- https://blog.matcha.xyz/article/mev-protection
- https://blog.uniswap.org/uniswapx-protocol
- https://superscrypt.medium.com/uniswapx-moving-toward-intent-centric-swaps-f1660b7e1cb9
- https://medium.com/@to.epochprotocol/intent-solver-mechanisms-the-evolution-of-defi-order-execution-3714551b2f4a
- https://research.coinone.co.kr/primer/COW_digital_asset_info_TNMA35Q7TB5XG1OA.pdf
- LLM
- Perplexity Pro
- Sonnet 4.0, Opus 4.1
- Gemini 2.5 Pro
부록: 추후 더 리서치해보고 싶은 내용들
- 체인별 MEV 특성과 대응 전략
- MEV Protection의 trade-offs와 한계
- 실제 구현된 MEV Protection 코드 예시
- 각 MEV Protection 마다 정량적으로 메트릭스 비교 분석
- Gas 비용 절감률, 거래 성공률 등