암호화된 멤풀은 왜 프라이버시 기능이 아니라 순서 결정 장치일까: EIP-8184 LUCID로 보는 MEV 방어

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 거래 내용을 숨기면 MEV가 사라질까, 아니면 “언제 공개할지”를 프로토콜이 정해야 할까?
• 핵심 출처:
  • EIP-8184: LUCID encrypted mempool - 생성일 2026-03-04, 확인일 2026-06-25
  • Glamsterdam | ethereum.org - 최종 업데이트 2026-06-06, 확인일 2026-06-25
  • EIP-7805: Fork-choice enforced Inclusion Lists - 생성일 2024-11-01, 확인일 2026-06-25
  • EIP-7732: Enshrined Proposer-Builder Separation - 생성일 2024-06-28, 확인일 2026-06-25
  • Ethereum Magicians: EIP-8184 discussion - 게시일 2026-03-18, 확인일 2026-06-25

1. 왜 지금 봐야 하나

Ethereum의 다음 큰 흐름은 “더 많은 트랜잭션을 처리한다”에서 끝나지 않는다. ethereum.org의 Glamsterdam 페이지는 H2 2026 업그레이드 후보로 ePBS, block-level access list, state growth repricing 같은 구조 변화를 설명하면서, 블록을 만들고 검증하는 방식을 다시 나누려 한다고 정리한다. 최근 공부방에서도 ePBS, FOCIL, blob fee, EIP-7702를 다뤘다.

그 다음 질문은 이것이다. 블록 생산이 builder 중심으로 전문화되고, inclusion list로 검열 저항성을 높이더라도, 사용자가 public mempool에 거래 내용을 그대로 올리면 어떤 일이 생길까? swap, liquidation, NFT mint, arbitrage unwind처럼 순서에 민감한 거래는 공개되는 순간 front-running, sandwiching, copy-trading의 대상이 된다. 그래서 중요한 order flow는 private relay, builder API, order-flow auction으로 빠진다.

EIP-8184 LUCID는 이 균열을 겨냥한 Draft Core EIP다. 설명은 “public encrypted mempool”이지만, 핵심은 단순히 암호화가 아니다. 거래 내용을 숨긴 채 public inclusion pipeline에 올리고, builder가 먼저 포함을 약속한 뒤, 그 다음에 복호화되게 만드는 commit-before-reveal 순서 규칙이다.

오늘 가져갈 한 문장은 이것이다.

암호화된 멤풀의 목적은 거래를 영원히 숨기는 것이 아니라, 순서 결정이 끝나기 전에는 내용을 악용하지 못하게 만드는 것이다.

2. 핵심 개념

일반 public mempool에서는 거래가 이런 순서로 흘러간다.

사용자 서명 → plaintext 거래 전파 → builder/searcher 관찰 → 순서 경쟁 → 블록 포함

문제는 plaintext 거래 전파와 순서 경쟁 사이에 있다. 누군가 거래 내용을 먼저 보면, 그 거래 앞뒤에 자신의 거래를 넣어 이익을 만들 수 있다. 그래서 “public mempool은 permissionless하지만, 경제적으로 중요한 거래에는 위험하다”는 모순이 생긴다.

LUCID는 sealed transaction, 줄여서 ST를 도입한다. EIP-8184에 따르면 ST는 크게 두 부분으로 구성된다.

1. ST ticket: sender가 서명한 티켓이다. 수수료 부과, commitment, inclusion list 참조에 쓰인다.
2. ciphertext envelope: 실제 plaintext transaction을 암호화해 담는 봉투다.

여기서 중요한 점은 ST ticket의 signer와 나중에 복호화되는 plaintext transaction의 from이 다를 수 있다는 점이다. 즉 “누가 public mempool에 암호문을 올리고 비용을 책임지는가”와 “복호화 후 어떤 계정의 거래가 실행되는가”를 분리할 수 있다.

LUCID의 흐름은 대략 이렇다.

1. 사용자는 plaintext transaction을 암호화한 ST를 public mempool에 올린다.
2. inclusion list committee 또는 builder가 ST/ST bundle을 참조한다.
3. builder는 ExecutionPayloadBid 안에서 ST 포함을 먼저 commit한다.
4. beacon block에서 scheduling decision이 고정된다.
5. key publisher 또는 self-decryption 경로가 key를 공개한다.
6. 복호화된 거래가 다음 payload의 top-of-block 영역에서 실행된다.

즉 LUCID가 보장하려는 순서는 “먼저 약속, 나중에 내용 공개”다. 거래 내용이 공개되기 전에 이미 builder의 commitment가 고정되어 있으면, builder나 searcher가 내용을 본 뒤 순서를 바꾸는 여지가 줄어든다.

3. 최신 이슈와 연결

EIP-8184가 흥미로운 이유는 혼자 떨어진 아이디어가 아니라, Glamsterdam 이후 Ethereum 블록 생산 설계의 빈칸을 메우려는 제안이기 때문이다.

첫째, EIP-7732 ePBS는 proposer와 builder 역할을 프로토콜 안에서 분리한다. EIP-7732는 beacon block body에서 execution payload를 직접 제거하고, builder가 나중에 reveal할 execution payload에 대한 signed commitment를 넣는 방향을 제안한다. ethereum.org는 ePBS가 현재 약 2초 수준의 빡빡한 hot path를 넓혀 더 큰 payload와 blob 처리를 가능하게 한다고 설명한다.

둘째, EIP-7805 FOCIL은 inclusion list committee가 관찰한 거래를 block에 강제 포함시키는 검열 저항성 장치다. 하지만 FOCIL은 기본적으로 public mempool 관측에 의존한다. 순서에 민감한 거래가 plaintext로 public mempool에 나오지 못한다면, inclusion list가 보호할 대상도 줄어든다.

셋째, EIP-8184는 이 둘 사이의 간극을 다룬다. “FOCIL로 public inclusion path를 만들었지만, MEV-sensitive transaction은 공개되면 공격받는다”는 문제를 encrypted ST로 풀려 한다. EIP-8184는 특정 암호 시스템을 Ethereum 안에 고정하지 않고, key publisher, trustless self-decryption 등 여러 off-protocol 복호화 방식을 열어둔다. Ethereum Magicians 논의도 아직 resource pricing 같은 세부가 남아 있음을 명시한다.

개발자에게 중요한 해석은 이것이다. LUCID는 “거래 내용 비공개”라는 UX 기능이 아니라, ePBS·FOCIL·builder commitment·key release deadline이 함께 맞물리는 블록 생산 프로토콜의 타이밍 설계다.

4. 개발자 관점 해석

1) 암호화는 MEV를 없애지 않고 정보 공개 시점을 늦춘다

암호화된 멤풀을 들으면 “이제 sandwich가 사라지나?”라고 생각하기 쉽다. 하지만 LUCID가 직접 줄이는 것은 “commitment 전에 plaintext를 보고 순서를 바꾸는 능력”이다. 복호화 후에는 거래가 실행되어야 하고, state transition은 여전히 공개 검증된다. 또한 gas, ticket, bundle 크기, key publisher 같은 메타데이터는 일부 남을 수 있다.

따라서 dApp 개발자는 “encrypted mempool 지원”을 보안 만능패로 팔면 안 된다. 사용자가 보호받는 범위는 다음 질문으로 좁혀야 한다.

• plaintext calldata가 commitment 전에 공개되는가?
• builder가 commit한 뒤 key가 공개되는가?
• key가 늦거나 누락될 때 거래는 어떻게 처리되는가?
• gas reservation, top-of-block execution cap 때문에 내 거래가 실패할 수 있는가?

2) public inclusion path와 private order flow의 경쟁이 바뀐다

오늘날 많은 dApp은 MEV 방어를 위해 private RPC나 solver network를 붙인다. 이 방식은 UX는 좋아질 수 있지만, 사용자가 특정 중개자를 믿게 만들고, builder 집중을 더 강하게 만들 수 있다. EIP-8184의 문제의식은 “MEV-sensitive transaction도 public path에 남길 수 있어야 한다”에 가깝다.

만약 LUCID류 설계가 성숙하면, wallet과 dApp은 거래 전송 옵션을 이렇게 나눠야 할 수 있다.

일반 거래: public mempool
검열 저항이 중요한 거래: FOCIL/inclusion-list 경로
순서 노출이 위험한 거래: sealed transaction 경로
복잡한 실행 품질이 중요한 거래: solver/private path, 단 신뢰 가정 표시

즉 “어느 RPC로 보낼까?”가 아니라 “이 거래의 정보 노출, 포함 보장, 실행 실패 리스크 중 무엇을 우선할까?”를 선택하는 제품 문제가 된다.

3) 실패 조건은 key release와 resource cap에 있다

암호화된 거래는 새로운 실패 조건을 만든다. plaintext 거래는 보통 nonce, balance, gas, calldata validity를 보면 된다. ST는 여기에 다음 조건이 추가된다.

• key publisher가 제때 key를 공개하는가?
• builder commitment와 실제 ciphertext가 일치하는가?
• inclusion list가 참조한 ST bytes를 네트워크가 얻을 수 있는가?
• decrypt 후 거래들이 top-of-block gas cap 안에 들어가는가?
• key가 늦거나 payload가 invalid일 때 recovery rule이 사용자에게 어떤 결과를 주는가?

EIP-8184는 decrypted ST 실행을 block gas의 일부로 제한하는 파라미터를 둔다. 추출 결과 기준으로 기본값은 TOB_GAS_FRACTION_DENOMINATOR = 8, 즉 top-of-block 영역을 block gas의 1/8로 제한하는 형태다. 이 값은 “암호화된 거래가 무제한으로 다음 블록 실행을 점유하면 안 된다”는 자원 경계다.

5. 내 프로젝트에 적용할 체크포인트

• swap, liquidation, mint, batch settlement 중 public mempool 노출이 사용자 손실로 이어지는 경로가 있는가?
• private RPC를 쓰고 있다면 사용자에게 어떤 중개자 신뢰 가정이 생기는지 문서화했는가?
• transaction submission abstraction이 “public / private / protected / inclusion-list” 경로를 분리할 수 있는가?
• calldata를 숨겨도 gas limit, value, account, timing metadata에서 의도가 새지 않는가?
• key release 실패, late reveal, invalid reveal을 UX에서 어떻게 표현할 것인가?
• bundle이나 batch 기능이 top-of-block gas cap 같은 자원 제한을 초과하지 않는가?
• order-sensitive 기능에 slippage, deadline, commit hash, replay protection을 같이 두었는가?
• monitoring에서 “submitted”, “committed”, “revealed”, “executed”, “expired” 상태를 분리할 수 있는가?

6. 오늘 10분 액션

1. 내 dApp에서 mempool 노출이 가장 위험한 action 하나를 고른다. 예: swap, liquidation repay, vault rebalance, NFT mint.
2. 그 action의 거래 전송 경로를 그린다: wallet → RPC → mempool/private relay → builder → block.
3. 사용자가 믿는 주체를 표시한다: wallet, RPC provider, relay, solver, builder.
4. README나 이슈에 “public path에서 calldata가 먼저 공개되면 생기는 공격”을 한 문장으로 적는다.
5. 앞으로 protected transaction을 붙일 때 필요한 상태 모델을 만든다: created → encrypted/submitted → committed → revealed → executed/expired.

7. 더 볼 자료

• EIP-8184: LUCID encrypted mempool
• Glamsterdam | ethereum.org
• EIP-7805: Fork-choice enforced Inclusion Lists
• EIP-7732: Enshrined Proposer-Builder Separation
• Ethereum Magicians: EIP-8184 discussion

중복 회피 메모

최근 blockchain_dev 글은 EIP-7702 delegate 권한, Syscoin cross-layer parsing, Axelar-Secret IBC source channel 인증, EIP-7732 ePBS, EIP-7918 blob fee reserve, Chainlink CCIP TokenPool upgrade, Aztec Connect L1/L2 settlement mismatch, OP Stack interop을 다뤘다. 이번 글은 ePBS 자체나 FOCIL의 inclusion-list enforcement를 다시 설명하는 대신, EIP-8184 LUCID를 통해 “MEV-sensitive 거래를 public inclusion path에 남기려면 commit-before-reveal 타이밍과 key release 실패 조건을 어떻게 설계해야 하는가”에 집중해 기존 글과 관점을 분리했다.