EIP-7805, 공식적으로 "포크 선택 강제 포함 목록(FOCIL)"이라고 불리는 이 제안은 핵심 이더리움 개선 제안(EIP)으로, 이더리움 네트워크의 검열 저항성을 강화하기 위해 설계되었습니다. ^{[1] [2]} 이 제안은 작성 당시 "초안" 상태였으며, 공개 멤풀에 제출된 유효한 트랜잭션이 적시에 온체인에 포함되도록 보장하는 메커니즘을 도입합니다. 이를 위해 검증인 위원회를 구성하여 트랜잭션의 "포함 목록(ILs)"을 제안하고, 프로토콜의 핵심 포크 선택 규칙을 수정하여 이를 시행합니다. 이 시스템은 제안자-빌더 분리(PBS)의 중앙 집중화 효과에 대응하고 네트워크의 신뢰할 수 있는 중립성을 강화하기 위한 것입니다. ^[1]

개요

EIP-7805의 주요 동기는 제안자-빌더 분리(PBS) 구현 후 이더리움 블록 생성 시장의 진화에서 비롯됩니다. PBS는 블록 제안자(검증자)의 역할을 블록 빌더의 복잡하고 리소스 집약적인 역할과 분리하기 위해 도입되었습니다. 이는 목표 달성에는 성공적이었지만, 네트워크에서 대부분의 블록을 구성하는 소수의 고도로 전문화된 "빌더" 그룹이 등장하게 되었습니다. 이러한 권력 집중은 거래 검열의 잠재적 벡터를 생성하여, 소수의 공모하거나 강요된 빌더가 특정 거래를 체계적으로 지연시키거나 블록체인에서 제외할 수 있게 되었습니다. ^[2]​

EIP-7805는 더 광범위한 분산 검증자에게 권한을 다시 부여함으로써 이러한 위험을 해결합니다. 이는 유효한 거래가 결국 체인에 포함될 수 있도록 보장하는 블록 빌더에 대한 제약을 집단적으로 가할 수 있는 도구를 제공합니다. 핵심 원칙은 새로운 블록을 증명하는 검증자가 무작위로 선택된 동료 위원회에서 생성된 포함 목록을 준수하는 블록에만 투표한다는 것입니다. 이는 빌더가 검열 블록을 생성하는 것이 경제적으로 실행 불가능하게 만듭니다. 왜냐하면 정직한 증명자가 이를 무시하고 궁극적으로 정식 체인에서 고아가 되기 때문입니다. 이 제안은 PBS가 해결하도록 설계된 복잡성을 다시 도입하지 않고도 강력한 포함 보장을 제공하는 것을 목표로 합니다. ^{[1] [2]}​

역사 및 개발

EIP-7805 제안은 2024년 11월 1일에 Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann 및 Jihoon Song을 포함한 연구진과 개발자 팀에 의해 공식적으로 생성되었습니다. ^[1] 커뮤니티 피드백을 수집하고 설계를 논의하기 위해 2024년 11월 4일에 Fellowship of Ethereum Magicians 포럼에서 공개 토론 스레드가 시작되었습니다. ^[2]

도입 시점부터 이 제안은 이더리움의 핵심 합의 규칙 변경을 제안하고 구현하려면 네트워크 전체의 하드 포크가 필요함을 나타내는 '표준 트랙: 코어' EIP로 '초안' 상태로 분류되었습니다. 포럼 토론에서는 잠재적인 과제와 향후 개선 사항을 모색하기 시작했습니다. 주요 주제는 특정 검증인에 대한 트랜잭션의 귀속성이었으며, 이는 그 달 말에 'FOCILIS'라는 익명성을 보존하는 확장 제안으로 이어졌습니다. ^{[1] [2]}

기술적 메커니즘

FOCIL은 검증자, 빌더 및 클라이언트에 대한 새로운 규칙 및 책임을 도입하며, 이는 이더리움의 슬롯 기반 합의 주기에 통합됩니다. 슬롯 N+1에서 블록 포함을 강제하는 전체 프로세스는 슬롯 N 동안 동시에 발생합니다. ^[1]

핵심 개념

이 메커니즘은 몇 가지 핵심 아이디어를 기반으로 구축되었습니다.

• 포함 목록 (IL): 위원회 구성원이 공개 멤풀의 관점에서 컴파일한 트랜잭션 목록입니다. 이는 구성원이 다음 블록에 포함되어야 한다고 생각하는 트랜잭션입니다.
• IL 위원회: 각 슬롯에서 16명의 검증인 그룹이 무작위로 선택되어 IL 위원회를 구성합니다. 이들의 유일한 책임은 IL을 생성하여 네트워크에 브로드캐스트하는 것입니다.
• 포크 선택 강제: 제안의 효력은 포크 선택 규칙, 즉 검증인이 어떤 체인이 정식 체인인지 결정하는 데 사용하는 규칙 집합을 수정하는 데서 비롯됩니다. FOCIL 하에서 증명 검증인은 IL 포함 요구 사항을 올바르게 충족하지 않는 블록을 거부하여 비준수 블록이 최종화되는 것을 효과적으로 방지합니다.
• 조건부 포함: 강제는 절대적이지 않습니다. 빌더는 해당 트랜잭션이 포함 시점에 유효하고 (예: 올바른 nonce, 충분한 발신자 잔액) 블록에 충분한 가스가 남아 있는 경우에만 IL에서 트랜잭션을 포함해야 합니다. 유효하지 않게 되거나 맞지 않는 트랜잭션은 필수가 아닙니다.

이러한 핵심 개념은 여러 네트워크 참가자가 참여하는 조정된 워크플로를 통해 구현됩니다. ^[1]

역할 및 워크플로

FOCIL 프로세스는 각 12초 슬롯 내에서 IL 위원회, 일반 검증인, 블록 빌더 및 다음 블록의 제안자의 활동을 조정하는 정확한 타임라인을 포함합니다. 슬롯 N+1의 블록에 대한 IL 생성 프로세스는 슬롯 N 동안 진행됩니다.

슬롯 N의 타임라인	역할	책임
t=0s – 8s	IL 위원회 위원	슬롯 N에 대한 블록을 관찰한 후, 16명의 위원회 위원 각자는 로컬 멤풀에서 포함 목록을 독립적으로 생성하고 서명된 목록을 P2P 네트워크에 브로드캐스트합니다.
t=0s – 9s	모든 검증인	위원회 위원으로부터 받은 모든 유효한 IL을 수신, 검증, 저장 및 전달합니다. 또한 동일한 회원이 여러 개의 다른 IL을 보내는 경우 (equivocation) 증거를 모니터링합니다.
t=9s	모든 검증인	"뷰 고정" 마감일에 검증인은 현재 슬롯에 대한 새로운 IL 수락을 중단합니다. 이를 통해 슬롯 N+1에서 다음 블록을 검증하는 데 사용될 안정적인 공유 IL 세트가 생성됩니다.
t=0s – 11s	블록 빌더	네트워크에서 사용 가능한 모든 IL을 수집합니다. 이 목록을 사용하여 슬롯 N+1에 대한 호환 가능한 블록 페이로드를 구성합니다.
t=11s	블록 빌더	빌더는 IL에 대한 뷰를 고정하고 최종 실행 페이로드를 완료하여 수집된 목록에서 포함 가능한 모든 트랜잭션을 포함하도록 합니다.
t=0s (슬롯 N+1)	블록 제안자	슬롯 N+1에 대한 제안자는 빌더의 호환 가능한 실행 페이로드를 포함하는 새 블록을 브로드캐스트합니다.
t=0s – 4s (슬롯 N+1)	증명자	슬롯 N+1 블록을 수신하면 해당 슬롯에 대한 모든 증명자는 슬롯 N의 IL에 대한 고정된 뷰와 교차 참조합니다. 필요한 모든 IL 트랜잭션을 올바르게 포함하는 경우에만 블록에 대한 투표 (증명)를 합니다.

이 긴밀하게 조정된 워크플로는 빌더가 호환 가능한 블록을 구성할 수 있도록 포함 목록이 제때 생성 및 배포되도록 보장하며, 이는 더 넓은 증명인 네트워크에 의해 즉시 검증됩니다. ^[1]

프로토콜 수준 변경 사항

EIP-7805를 구현하려면 합의 계층(CL), 실행 계층(EL) 및 이를 연결하는 엔진 API 전반에 걸쳐 조정된 변경이 필요합니다.

합의 계층 (CL) 수정 사항

• 포크 선택 규칙: CL의 포크 선택 로직이 업데이트되어 포함 목록 조건을 만족하는 블록만 증명에 유효한 것으로 간주합니다. 이 검사에 실패한 블록은 증명자가 무시합니다.
• 새로운 데이터 구조: 두 개의 새로운 컨테이너가 도입되었습니다. InclusionList는 슬롯 번호, 위원회 구성원 인덱스 및 트랜잭션 목록을 보유하고, SignedInclusionList는 위원회 구성원이 서명한 InclusionList입니다.
• P2P 네트워크: SignedInclusionList 객체를 브로드캐스트하기 위한 새로운 글로벌 가십 토픽이 생성되어 네트워크 전체에 빠르게 전파될 수 있도록 합니다. 또한 노드가 놓쳤을 수 있는 특정 IL을 요청할 수 있도록 새로운 RPC 메서드가 추가되었습니다. ^[1]

실행 레이어 (EL) 수정 사항

• 새로운 유효성 검사: EL은 새로운 책임을 갖게 됩니다. 새로운 블록 페이로드를 처리할 때 제공된 IL의 트랜잭션 중 포함 가능한데도 누락된 트랜잭션이 있는지 확인해야 합니다.
• 포함 가능성 정의: 트랜잭션은 다음 두 가지 조건을 충족하는 경우 '포함 가능'으로 정의됩니다. (1) 블록에 충분한 가스가 남아 있어야 하고, (2) 트랜잭션이 블록에 의해 생성된 최종 상태에 대해 유효해야 합니다(즉, 보낸 사람이 올바른 nonce와 충분한 자금을 가지고 있어야 함).
• 새로운 오류 상태: EL이 포함 가능하지만 포함되지 않은 트랜잭션을 발견하면 CL에 새로운 상태인 INCLUSION_LIST_UNSATISFIED를 반환합니다. 그러면 CL은 블록을 거부해야 한다는 것을 알게 됩니다. ^[1]

Engine API 개선

CL과 EL 간의 통신을 용이하게 하기 위해 Engine API가 새로운 메서드로 확장되었습니다.

• engine_getInclusionListV1: CL이 EL로부터 IL을 요청할 수 있도록 합니다.
• engine_updatePayloadWithInclusionListV1: CL이 빌더의 집계된 IL을 블록 구성 중에 EL로 전달하는 데 사용됩니다.
• 기존 engine_newPayload 메서드는 IL 트랜잭션을 매개변수로 허용하고 새로운 INCLUSION_LIST_UNSATISFIED 상태를 처리하도록 수정되었습니다. ^[1]

주요 매개변수

본 제안은 메커니즘을 관리하기 위해 여러 상수를 정의합니다.

매개변수	값	설명
IL_COMMITTEE_SIZE	16	각 슬롯에서 IL 위원회에 선택되는 검증자 수입니다.
MAX_BYTES_PER_INCLUSION_LIST	8192 (8 KiB)	개별 IL의 최대 크기로, 네트워크 대역폭 및 스토리지 요구 사항을 제한합니다.
DOMAIN_IL_COMMITTEE	0x0C000000	IL 서명이 다른 컨텍스트에서 재생되는 것을 방지하는 데 사용되는 고유한 서명 도메인입니다.

이러한 매개변수는 검열 저항과 네트워크 오버헤드 및 성능 간의 균형을 맞추기 위해 선택되었습니다. ^[1]

근거 및 설계 원칙

FOCIL의 설계는 견고하고 최소한의 복잡성을 가진 솔루션을 만드는 데 목표를 둔 몇 가지 핵심 원칙에 따라 이루어집니다.

• 위원회 기반 소싱: 트랜잭션 소싱에 단일 개체(제안자와 같은) 대신 16명의 검증인으로 구성된 위원회를 사용하면 시스템의 복원력이 향상됩니다. IL에 트랜잭션을 포함시키려면 단 한 명의 정직한 위원이 필요하므로 단일 위원에게 뇌물을 주거나 공격하는 것은 효과가 없습니다. 전체 위원회를 공격하는 것은 훨씬 더 어렵고 비용이 많이 듭니다.
• 포크 선택 강제: 강제를 포크 선택 규칙에 직접 연결하는 것이 가장 강력한 보장입니다. 이를 통해 준수를 합의 프로토콜의 핵심 부분으로 만들어 빌더가 네트워크에서 블록이 거부되지 않고는 이를 우회할 수 없습니다.
• 빌더 유연성: EIP는 빌더에게 두 가지 방식으로 유연성을 제공합니다. 첫째, 조건부 포함을 통해 빌더는 유효하지 않게 된 트랜잭션을 생략해도 처벌받지 않습니다. 둘째, "블록 내 어디든" 규칙은 빌더가 IL 트랜잭션을 블록 내 어디든 배치할 수 있음을 의미하므로 간섭 없이 MEV에 대한 최적화를 계속할 수 있으며, 이는 IL에 대한 복잡한 오프체인 주문 시장 생성을 방지합니다.
• 직접적인 인센티브 없음: 이 제안은 IL 위원회 위원에 대한 새로운 수수료 시장이나 직접적인 금전적 보상을 의도적으로 생략합니다. 이는 1-out-of-N 정직성 가정(N명의 위원 중 최소 1명은 정직할 것임)과 네트워크의 건전성과 중립성을 유지하려는 검증인의 일반적인 이타심에 의존합니다. 이는 새로운 게임 불가능한 인센티브 시스템을 설계하는 데 따르는 상당한 복잡성을 피합니다.

이러한 설계 선택 모음은 기존 블록 생산 생태계에 대한 혼란을 최소화하면서 강력한 검열 저항성을 제공하는 것을 목표로 합니다. ^[1]

보안 고려 사항 및 과제

FOCIL 제안은 새로운 합의 상호 작용 및 의존성을 도입하며, 이는 잠재적인 보안 고려 사항을 수반합니다.

• 합의 생존성: 메커니즘의 주요 생존성 위험은 IL 전파 지연으로 인해 블록 생성이 지연될 수 있다는 것입니다. 빌더가 마감 시간 전에 IL을 받지 못하면 비준수 블록을 생성하여 거부될 수 있으며, 잠재적으로 빈 슬롯 또는 누락된 슬롯으로 이어질 수 있습니다. 타임라인에는 검증인 뷰 고정(t=9초)과 빌더 마감 시간(t=11초) 사이에 이를 완화하기 위한 버퍼가 포함되어 있습니다.
• IL 허위 진술: 악의적인 위원회 구성원은 동일한 슬롯에 대해 여러 개의 다른 IL을 브로드캐스트하여 네트워크를 방해하려고 시도할 수 있습니다. 지정된 완화 방법은 노드가 단일 구성원에서 최대 두 개의 서로 다른 IL을 전달하지만 두 개 이상이 감지되면 해당 구성원의 모든 IL을 무시하는 것입니다. 이는 허위 진술 검증인으로 인해 발생하는 잠재적인 대역폭 영향 및 혼란을 포함합니다.
• 페이로드 구성 복잡성: IL 제약 조건을 충족하는 순진한 빌더 알고리즘은 계산 집약적일 수 있습니다. IL에 많은 수의 트랜잭션이 있는 경우 블록을 빌드하는 동안 유효성을 반복적으로 확인하는 데 시간이 오래 걸릴 수 있습니다. EIP 작성자는 빌더가 블록에 트랜잭션을 추가할 때 IL에 관련된 계정의 nonce 및 balance 변경 사항을 추적하여 더 빠른 유효성 검사를 수행하는 보다 효율적인 전략을 제안합니다.
• 검증인 귀속성: 커뮤니티에서 논의된 중요한 과제는 FOCIL이 검증인의 신원과 IL에 포함하기로 선택한 트랜잭션 간의 공개적인 온체인 링크를 생성한다는 것입니다. 이는 검증인이 법적 또는 사회적 반발에 대한 두려움 때문에 논란이 되거나 제재된 엔터티의 트랜잭션을 포함하는 것을 주저하게 만드는 "냉각 효과"를 가질 수 있습니다. 이는 아이러니하게도 시스템의 반검열 목표를 훼손할 수 있습니다. ^{[1] [2]}

제안된 확장 및 향후 방향

검증인 귀속성 문제에 대한 대응으로 커뮤니티는 개인 정보 보호 강화에 대한 논의를 시작했습니다.

FOCILIS

제안된 가장 두드러진 확장 기능은 **FOCILIS (구별할 수 없는 제출이 가능한 FOCIL)**였습니다. 2024년 11월 말 이더리움 마법사 포럼에서 제기된 이 개념은 위원회 구성원이 익명으로 IL을 제출할 수 있도록 하는 것을 목표로 합니다.

• 메커니즘: 검증인은 개인 키로 IL에 서명하는 대신 영지식 증명(ZKP)을 생성합니다. 이 증명은 특정 신원을 밝히지 않고 현재 슬롯의 IL 위원회의 합법적인 구성원임을 입증합니다. 제안된 구조는 개인 정보 보호에 중점을 둔 신호 프로토콜인 Semaphore와 유사한 것으로 설명되었습니다.
• 부정 행위 방지: 익명의 검증인이 여러 IL을 제출하는 것을 방지하기 위해 FOCILIS는 무효화 시스템을 사용합니다. 각 위원회 구성원은 고유한 일회용 ID를 약정하여 각 구성원이 슬롯당 하나의 유효한 증명(따라서 하나의 유효한 IL)만 생성할 수 있도록 합니다.

토론 스레드의 합의는 실용적인 2단계 구현으로 기울었습니다. 더 간단하고 완전히 속성이 부여된 FOCIL이 먼저 배포되어 즉각적인 검열 저항을 제공합니다. 한편, FOCILIS 및 기타 "익명 포함 목록(anon-IL)"에 대한 연구는 계속될 것이며, 향후 네트워크 업그레이드에서 개인 정보 보호 버전을 배포하는 것을 목표로 합니다. ^[2]

이전 버전과의 호환성

EIP-7805는 계획된 네트워크 전체 하드 포크를 통해서만 활성화할 수 있는 이전 버전과 호환되지 않는 제안입니다. 변경 사항은 합의 계층에서 블록 유효성 검사 규칙을 근본적으로 변경하므로 모든 클라이언트 소프트웨어(CL 및 EL 모두)를 업데이트해야 합니다. 그러나 변경 사항은 프로토콜의 백엔드에 포함되어 있으며 사용자 트랜잭션 구조나 기존 스마트 계약의 기능을 변경하지 않습니다. 따라서 업그레이드는 사용자 대상 애플리케이션을 손상시키거나 최종 사용자 또는 계약 개발자의 조치를 요구하지 않을 것으로 예상됩니다. ^[1]