MEV, PBS, Private Orderflow
도입
스테이블코인 checkout이 단순 transfer만 수행한다면 MEV는 멀게 느껴질 수 있다. 하지만 실제 제품은 swap, treasury rebalance, bridge settlement, oracle update, liquidation keeper와 연결된다. 사용자가 100 USDC를 결제하더라도 backend가 route를 바꾸거나 merchant 정산을 위해 DEX를 거치면 transaction ordering이 곧 가격과 실패율에 영향을 준다.
이 레슨은 MEV를 "나쁜 bot" 정도로 이해하는 수준에서 멈추지 않는다. public mempool, private orderflow, builder, proposer, relay, ePBS의 신뢰 경계를 제품 상태 머신으로 옮겨 본다. 핵심 질문은 하나다. 어떤 transaction을 어떤 경로로 제출하고, 그 경로가 실패했을 때 checkout을 어떻게 끝낼 것인가.
학습 목표
- MEV와 PBS가 결제와 swap UX에 미치는 영향을 설명한다.
- private orderflow의 보호와 중앙화 tradeoff를 평가한다.
개념 설명
Adopt
Trial
Assess
Hold
block building을 제품 경로로 읽기
MEV는 block 안에서 transaction의 순서, 포함 여부, 앞뒤 배치가 바뀌며 생기는 가치다. swap이 public mempool에 노출되면 sandwich, backrun, liquidation 경쟁, oracle update 선점 같은 영향을 받을 수 있다. private orderflow는 노출을 줄일 수 있지만, relay나 builder provider를 신뢰해야 하고 inclusion 실패나 censorship risk를 새로 만든다.
PBS와 ePBS의 위치
ethereum.org는 PBS를 block proposer와 builder의 역할을 분리하는 연구 방향으로 설명한다. proposer는 block을 직접 만들지 않고 여러 builder가 제안한 block 중 하나를 선택한다. EIP-7732는 execution validation과 consensus validation을 논리적, 시간적으로 분리하는 enshrined PBS draft다. 2026-05-15 기준 EIP-7732는 Draft이고, PBS 역시 앱 개발자가 "이미 모든 문제가 해결됐다"고 가정할 단계가 아니다.
| 개념 | 제품팀이 이해할 말 | 남는 리스크 |
|---|---|---|
| MEV | transaction ordering에서 생기는 실행 가격/포함 리스크 | sandwich, adverse execution, priority gas auction |
| PBS | block proposer와 builder 역할 분리 | builder concentration, relay 의존, censorship |
| MEV-Boost | 현재 PoS Ethereum에서 쓰이는 out-of-protocol PBS류 구현 | relay 신뢰, builder bid 선택 |
| ePBS / EIP-7732 | builder 역할을 protocol 안으로 더 가져오려는 draft | payload timeliness, payment, consensus complexity |
| Private orderflow | public mempool을 우회하는 제출 경로 | provider 신뢰, inclusion 실패, 검증 어려움 |
stablecoin 업무에서 중요한 장면
| 상황 | MEV 영향 | 방어 정책 |
|---|---|---|
| 사용자의 swap 기반 checkout | sandwich로 merchant 수령액 부족 | minAmountOut, deadline, route allowlist |
| treasury rebalance | 큰 주문 노출과 adverse execution | RFQ, TWAP, private route, size cap |
| peg defense | depeg 구간에서 toxic flow 증가 | pool depth check, circuit breaker |
| oracle update | stale price를 이용한 backrun | update delay, deviation limit, OSM류 완충 |
| bridge/intent fill | solver가 ordering advantage를 사용 | fill proof, deadline, price bound |
| liquidation keeper | priority gas auction과 실패 반복 | max gas policy, keeper diversity |
코드로 확인하기
MEV와 private orderflow는 추상적인 시장 구조가 아니라 transaction routing 정책으로 내려온다. checkout 시스템은 어떤 거래를 public mempool에 보낼지, 어떤 거래를 private relay로 보낼지 기준을 가져야 한다.
백엔드transaction route 분류
type TxIntent = { kind: "swap" | "stablecoin_payment" | "liquidation" | "settlement"; valueUsd: number; slippageBps: number; userRequiresPrivacy: boolean;};function chooseOrderflowRoute(intent: TxIntent) { if (intent.userRequiresPrivacy) return "private_relay"; if (intent.kind === "swap" && intent.slippageBps > 30) return "private_relay"; if (intent.valueUsd > 50_000) return "simulation_then_private"; return "public_mempool";}이 분류는 사용자의 돈이 어느 경로로 이동하는지 설명하는 운영 정책이다. 큰 거래와 slippage 민감 거래를 public mempool에 그냥 보내면 학습자가 위험을 체감하기 어렵다.
운영orderflow 정책 파일
orderflow_policy: public_mempool: allowed: - low_value_stablecoin_payment - non_price_sensitive_settlement private_relay: required_when: - high_slippage_swap - user_privacy_requested - value_usd_above_threshold logging: store_route_reason: true store_simulation_result: trueroute reason을 남기지 않으면 나중에 "왜 이 거래가 private relay로 갔는가" 또는 "왜 public mempool로 갔는가"를 설명할 수 없다.
인덱서orderflow 결과를 숫자로 남기기
select route, count(*) as tx_count, avg(included_at_block - submitted_at_block) as avg_inclusion_blocks, sum(case when status = 'price_mismatch' then 1 else 0 end) as price_mismatch_count, sum(case when status = 'manual_review' then 1 else 0 end) as manual_review_countfrom transaction_routeswhere created_at >= now() - interval '7 days'group by routeorder by tx_count desc;private route 채택 여부는 홍보 문구가 아니라 이 숫자로 판단한다. public route보다 inclusion이 느리거나 manual_review가 늘어난다면 보호 효과가 있어도 checkout 기본값으로 쓰기 어렵다.
강의 포인트
MEV 방어는 "private RPC를 쓰자"로 끝나지 않는다. public route와 private route 모두 실패 모드가 있다. public route는 노출과 sandwich가 문제이고, private route는 provider liveness, inclusion, censorship, price improvement 검증이 문제다.
강의에서는 transaction을 가치와 위험에 따라 나눈다.
| transaction 유형 | 기본 경로 | 예외 처리 |
|---|---|---|
| 소액 stablecoin transfer | public route | 실패 시 재시도 또는 사용자 안내 |
| swap 포함 checkout | route provider + slippage bound | price bound 이탈 시 fail/refund |
| high-value treasury swap | RFQ/private route/TWAP | provider failure 시 중단, manual approval |
| oracle/keeper 작업 | dedicated keeper route | stale state 감지 시 pause 또는 fallback |
실무 예시
100 USDC checkout과 1,000,000 USDC treasury rebalance를 같은 경로로 제출하면 안 된다.
| 항목 | 100 USDC checkout | 1,000,000 USDC rebalance |
|---|---|---|
| 우선 목표 | 빠른 UX와 낮은 실패율 | 가격 보호와 실행 추적 |
| 제출 경로 | public 또는 wallet default 가능 | RFQ, TWAP, private orderflow 우선 |
| 허용 slippage | 좁게 제한하되 UX 고려 | 더 엄격한 price policy |
| 실패 상태 | user retry, expired quote, refund | manual approval, partial fill 금지 |
| 저장할 증거 | quote id, minAmountOut, deadline, tx signature | venue, route, execution price, benchmark, approver |
이 표는 backend 상태 머신에도 들어간다. quote가 만료되면 checkout은 새 quote를 요구해야 하고, private provider가 inclusion을 보장하지 못하면 무한 재시도 대신 ManualReview 또는 Expired로 끝내야 한다.
흔한 오해와 실패 시나리오
| 오해 | 실패 장면 | 바로잡는 기준 |
|---|---|---|
| private orderflow는 MEV를 없앤다. | provider가 transaction을 포함하지 않아 checkout이 멈춘다. | 보호 효과와 liveness/censorship risk를 함께 기록한다. |
| PBS가 도입되면 앱은 신경 쓸 필요가 없다. | builder concentration과 route provider 의존이 남는다. | protocol roadmap과 app execution policy를 분리한다. |
| transfer만 하면 MEV와 무관하다. | 결제 직후 settlement swap에서 adverse execution이 발생한다. | checkout, swap, treasury, reconciliation을 한 흐름으로 본다. |
| slippage만 있으면 충분하다. | price는 보호했지만 failed payment와 refund 상태가 없다. | price bound, deadline, retry, user message를 함께 설계한다. |
실습 과제
- MEV, PBS, Private Orderflow 이해 점검: public mempool, private route, builder/proposer, relay/provider 신뢰 경계를 표로 정리한다. 각 경로에 censorship, liveness, price improvement 검증 항목을 붙인다.
- MEV, PBS, Private Orderflow 적용 과제: 스테이블코인 스왑 결제에서 public route와 private route의 risk matrix를 작성한다.
Quoted,Submitted,Included,PriceMismatch,Expired,ManualReview,Refunded상태를 포함한다.
완료 기준
- MEV/PBS 개념을 stablecoin swap과 treasury rebalance 사례로 설명했다.
- private orderflow의 보호 효과, provider trust, censorship/liveness tradeoff를 정리했다.
- public route와 private route 각각의 retry/fallback 정책을 만들었다.
근거 자료
- 인프라 MEV 리스테이킹 학습맵: 10-인프라-MEV-리스테이킹/00-인프라-MEV-리스테이킹-학습맵.md
- MEV PBS Private Orderflow: 10-인프라-MEV-리스테이킹/01-MEV-PBS-Private-Orderflow.md
- Ethereum Roadmap: Proposer-Builder Separation: https://ethereum.org/en/roadmap/pbs/
- EIP-7732: Enshrined Proposer-Builder Separation: https://eips.ethereum.org/EIPS/eip-7732