검열 저항은 메모리풀에서 시작된다: FOCIL로 보는 ‘포함 보장’의 합의 설계

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 블록 빌더가 거래를 계속 빼먹을 수 있다면, 체인은 그 거래를 어떻게 “반드시 보게” 만들 수 있을까?
• 핵심 출처:
  • EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL) - 2024-11-01, 확인일 2026-06-11
  • FOCIL Breakout #35, June 2, 2026 - 2026-06-02, 확인일 2026-06-11
  • EIP-7805 Implementation Tracker: FOCIL - 2025-12-11, 확인일 2026-06-11
  • Ethereum Foundation Checkpoint #8: Jan 2026 - 2026-01-20, 확인일 2026-06-11

1. 왜 지금 봐야 하나

Ethereum의 다음 업그레이드 논의에서 FOCIL(Fork-choice enforced Inclusion Lists)이 다시 중요해졌다. 2026년 6월 2일 FOCIL Breakout #35 메모에 따르면 Hegotá는 devnet-0을 준비 중이고, Nethermind 쪽 구현이 모든 FOCIL 테스트를 통과했다는 업데이트가 있었다. 동시에 아직 어려운 문제가 남아 있다. 노드가 동기화 중일 때 inclusion list(IL)를 어떻게 다룰지, sidechain/분기 이동 중 IL 시야가 달라졌을 때 실행 계층(EL)이 어떤 payload를 ACCEPTED로 봐야 할지 같은 문제다.

이 주제는 “Ethereum에 어떤 EIP가 들어간다”라는 뉴스보다 더 기본적인 질문을 던진다. 블록체인은 상태 전이(state transition)를 합의하지만, 사용자가 낸 거래가 블록 후보에 올라갈 기회 자체가 차단되면 상태 전이의 공정성도 흔들린다. 특히 proposer-builder separation(PBS) 구조에서는 블록을 실제로 구성하는 builder가 전문화되고 집중될 수 있다. 그 결과 “검증자는 탈중앙화되어 있는데, 거래 선택은 소수 빌더가 좌우하는” 이상한 병목이 생길 수 있다.

FOCIL은 이 병목을 consensus/fork-choice 규칙 안으로 끌어들인다. 핵심은 간단하다. 일부 검증자 위원회가 공용 mempool에서 본 거래 목록을 만들고, 다음 블록이 그 목록의 조건을 만족하지 않으면 attester가 그 블록에 투표하지 않게 만드는 것이다.

2. 핵심 개념

FOCIL을 한 문장으로 줄이면 “거래 포함 조건을 블록 빌더의 선의가 아니라 fork-choice의 입력으로 바꾸는 설계”다.

기본 흐름은 이렇다.

1. 어떤 슬롯 N에서 inclusion list committee가 선택된다.
2. 위원회 멤버들은 자신이 본 public mempool 기준으로 inclusion list를 만들고 P2P 네트워크에 전파한다.
3. proposer 또는 external builder는 그 IL들을 수집한다.
4. 다음 블록의 execution payload는 수집된 IL 거래들을 포함하거나, 이미 유효하지 않거나, 용량상 들어갈 수 없다는 조건을 만족해야 한다.
5. attester는 자신이 가진 IL view 기준으로 블록이 조건을 만족하는지 검사하고, 만족하지 않으면 그 블록을 head로 확장하지 않는다.

여기서 중요한 단어는 “fork-choice enforced”다. 단순히 “이 거래를 넣어주세요”라고 제안하는 목록이면 builder가 무시할 수 있다. 하지만 attester가 IL을 만족하지 않은 payload에 투표하지 않으면, 그 payload는 canonical chain이 되기 어렵다. 포함 목록이 사회적 권고가 아니라 합의 안전장치가 되는 셈이다.

개발자 관점에서 이 설계는 세 가지 층으로 나뉜다.

• mempool 관측 문제: 각 노드가 본 pending transaction 집합은 완전히 같지 않다.
• 블록 구성 문제: builder는 수익, MEV, gas limit, transaction validity를 고려해 payload를 만든다.
• 합의 검증 문제: consensus layer와 execution layer가 “이 payload는 IL 조건을 만족했는가”를 같은 방식으로 판단해야 한다.

FOCIL이 어려운 이유는 검열 저항이라는 정치적 목표를 네트워크 지연, mempool 불일치, 실행 유효성, fork-choice 규칙이라는 기계적 조건으로 바꿔야 하기 때문이다.

3. 최신 이슈와 연결

최근 확인한 출처들은 FOCIL이 단순 아이디어 단계가 아니라 구현·테스트 단계의 문제로 이동하고 있음을 보여준다.

• EIP-7805는 FOCIL을 draft 상태의 Core EIP로 설명하며, inclusion list committee, view freeze deadline, attester 검증, builder/proposer 역할을 정의한다.
• Ethereum Foundation의 2026년 1월 Checkpoint는 FOCIL이 Glamsterdam 범위에서 빠져 Hegotá 후보로 이동했다고 정리했다. 이유는 fork scope를 줄이기 위해서다. 즉 FOCIL은 중요하지만, ePBS·BAL 같은 큰 변경과 한 번에 묶기에는 복잡하다는 신호다.
• execution-specs의 구현 트래커는 테스트 프레임워크가 inclusion list를 state transition 및 engine payload 검증에 전달해야 한다고 적고 있다. “IL을 만족한 블록”, “IL을 만족하지 않은 블록”, “리스트 크기 제한 같은 경계 조건”을 테스트해야 한다는 체크리스트도 있다.
• 2026년 6월 Breakout #35는 더 구체적인 난점을 드러낸다. 동기화 중에는 CL이 IL을 언제 전달해야 하는가? FCU(forkchoiceUpdated)로 다른 branch로 이동했는데 그 branch에 대한 IL view가 없다면 어떻게 하나? 중간 payload가 IL-compliant가 아니지만 tip은 compliant한 경우 EL은 무엇을 반환해야 하나?

이 질문들은 모두 같은 원리로 이어진다. “검열 저항”은 추상 가치지만, 구현에서는 payload status, fork-choice weight, P2P 전파 deadline, client sync 상태 같은 낮은 수준의 인터페이스로 표현되어야 한다.

4. 개발자 관점 해석

FOCIL은 dApp 개발자가 당장 API를 바꿔야 하는 기능은 아닐 수 있다. 하지만 블록체인 시스템을 설계하거나 운영하는 개발자라면 세 가지 교훈을 가져갈 수 있다.

첫째, 검열 저항은 최종성(finality)과 다르다. Finality는 이미 체인에 들어간 블록을 되돌리기 어려운 성질이다. Inclusion은 사용자의 거래가 블록 후보에 올라갈 기회를 얻는 성질이다. finality가 강해도 특정 거래가 계속 제외된다면 사용자는 체인이 “살아 있다”고 느끼지 못한다.

둘째, builder 중심 구조에서는 거래 선택 권한이 별도 공격면이 된다. MEV 경매와 PBS는 검증자 수익과 블록 생산 효율을 높일 수 있지만, 거래 ordering·inclusion 권한을 전문 builder에게 집중시킨다. 그래서 protocol은 builder가 만든 payload를 그대로 신뢰하지 않고, 검증자 집합이 본 mempool 조건을 payload 검증에 반영하려 한다.

셋째, cross-layer EIP는 인터페이스가 보안 경계다. FOCIL은 consensus layer만의 기능이 아니다. execution layer가 payload를 평가할 때 “IL 만족/불만족” 상태를 정확히 반환해야 하고, consensus layer는 sync 상태와 fork-choice 상황에 따라 그 신호를 일관되게 사용해야 한다. 이 경계가 애매하면 client마다 canonical 판단이 달라질 수 있다.

실패 모드도 명확히 봐야 한다.

• mempool view split: 어떤 validator는 IL을 봤고 어떤 validator는 못 봤다면, 같은 블록에 대한 판단이 갈릴 수 있다.
• equivocation: IL committee 멤버가 여러 IL을 내면 어떤 것을 신뢰할지 규칙이 필요하다.
• invalidated transaction: IL에 있던 거래가 nonce, balance, state 변화 때문에 더 이상 유효하지 않을 수 있다.
• builder griefing: IL 조건을 일부러 만족하지 않는 payload를 만들어 네트워크 지연이나 재구성을 유발할 수 있다.
• sync/branch 이동 문제: 노드가 뒤늦게 따라오거나 다른 branch로 이동할 때 과거 IL view가 없으면 검증 기준이 흔들릴 수 있다.

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

FOCIL 자체를 구현하지 않더라도, 지갑·릴레이어·L2·브리지·인덱서·거래 제출 서비스를 만드는 팀은 아래 질문을 점검할 수 있다.

• 거래 제출 경로가 단일 RPC나 단일 builder relay에 의존하지 않는가?
• 사용자가 “전송됨”을 봤을 때, 그것이 로컬 서명 완료인지, mempool 전파인지, 블록 포함인지, finality인지 UI에서 구분하는가?
• pending transaction이 오래 머무를 때 replacement transaction, nonce 관리, fee bump 정책을 어떻게 처리하는가?
• 특정 relayer 또는 bundler가 거래를 제외할 때 대체 경로가 있는가?
• 인덱서가 “거래가 없다”와 “거래가 아직 포함되지 않았다”를 구분해 표시하는가?
• bridge나 oracle이 source chain transaction inclusion을 기다릴 때 confirmation 수만 보지 않고 censorship/withholding 가능성을 별도 timeout으로 다루는가?
• account abstraction bundler를 쓴다면 UserOperation이 public mempool, private mempool, bundler 내부 큐 중 어디에 있는지 관측할 수 있는가?

핵심은 사용자의 intent가 체인 상태로 반영되기 전까지 여러 단계의 신뢰 가정이 있다는 점이다. 서명은 권한 증명이고, mempool 전파는 가용성 신호이며, 블록 포함은 상태 전이 후보가 된 것이고, finality는 되돌리기 어려워진 것이다. 이 단계들을 하나로 뭉개면 장애 대응도, UX도, 보안 분석도 흐려진다.

6. 오늘 10분 액션

10분만 투자해서 내가 쓰는 지갑이나 dApp의 거래 상태 문구를 네 단계로 나눠 적어보자.

1. Signed: 사용자가 어떤 payload에 서명했는가?
2. Broadcast: 어느 RPC, relayer, bundler, mempool로 보냈는가?
3. Included: 어떤 block number/hash에 들어갔는가?
4. Finalized: 몇 confirmation 또는 어떤 finality 기준을 만족했는가?

그다음 코드나 로그에서 이 네 상태를 실제로 구분하고 있는지 확인한다. 만약 “pending” 하나로 모두 표현하고 있다면, 최소한 내부 로그에는 submitted_at, first_seen_at, included_at, finalized_at, submission_path를 남기는 작은 티켓을 만들어보자. FOCIL의 교훈은 프로토콜 레벨에서도 결국 “누가 보았고, 언제 보았고, 어떤 규칙으로 포함을 강제했는가”를 기록해야 한다는 것이다.

7. 더 볼 자료

• EIP-7805: Fork-choice enforced Inclusion Lists: FOCIL의 역할, committee, attester 검증, builder/proposer timeline을 보는 1차 문서.
• FOCIL Breakout #35: 2026년 6월 기준 devnet 준비, Nethermind 구현, sync/sidechain IL validation 논의.
• EIP-7805 Implementation Tracker: state transition 테스트와 engine payload 검증에 inclusion list를 넣어야 하는 이유.
• Ethereum Foundation Checkpoint #8: FOCIL이 Glamsterdam에서 빠져 Hegotá 후보가 된 배경과 fork scope 관점.

중복 회피 메모

최근 blockchain_dev 글은 Solana Alpenglow finality, Ethereum EIP-7928 block-level access list, PeerDAS/data availability, Arbitrum Nova 오프보딩, Ethereum native account abstraction, Zcash 비상 차단, Gnosis Pay 모듈 권한 검증을 다뤘다. 이번 글은 finality나 병렬 실행이 아니라 “거래가 블록에 포함될 기회를 합의 규칙으로 강제하는 방식”에 집중한다. FOCIL을 통해 mempool 관측, builder 검열, fork-choice enforcement, CL/EL payload status라는 별도 신뢰 경계를 설명하므로 기존 글과 관점을 분리했다.