66개 제안 중 헤고타가 고른 것은 두 개뿐

Hegotá의 범위 확정 과정에서 실제로 결정된 것은 무엇일까?

Glamsterdam 이후 이어질 Ethereum의 다음 업그레이드는 몇 년치 로드맵을 채울 만큼 많은 후보 제안에서 출발했다. 하지만 9일 뒤 트래커가 보여준 것은, 일정이라는 현실과 마주하자 그중 얼마나 적은 것만 살아남았는가였다.

지금까지 Hegotá의 범위 확정 과정에서 최종적으로 결정된 것은 거의 없다. 다만 두 가지는 정해졌다. 2026년 8월 검토 범위에 오른 66개 제안 가운데, 현재 EIP-8081 메타 문서에서 Scheduled for Inclusion(SFI) 상태를 유지하는 것은 정확히 두 개다. EIP-7805(FOCIL)와 EIP-8141(Frame Transaction)이다 . 약 50개 EIP는 여전히 Proposed for Inclusion 상태로 남아 있으며, 공식적으로 거절된 것은 없다 . 나머지는 아직 논의가 진행 중이다.

짧게 답하면: Glamsterdam 이후 Ethereum 업그레이드인 Hegotá는 2026년 8월 66개 후보 제안을 바탕으로 범위 검토가 진행됐다. EIP-8081 트래커에서 Scheduled for Inclusion에 오른 것은 EIP-7805(FOCIL)와 EIP-8141(Frame Transaction) 두 개뿐이다. 약 50개는 Proposed for Inclusion 상태로 남아 있으며, 목표 시점은 2027년 2분기로 예상되지만 아직 확정되지는 않았다.

“66개”라는 숫자는 Ethereum Foundation 연구원 Toni Wahrstätter가 2026년 8월 16일 추진한 범위 검토에서 비롯됐고, 다음 날 CoinDesk, Cointelegraph, Decrypt가 이를 보도했다 . 그 보도는 승인된 기능 목록이 아니라 후보군의 한 시점 스냅샷이며, 이미 공식 기록보다 뒤처져 있다. 당시 기사들은 FOCIL만 유일한 SFI 항목이고 Frame Transactions는 단지 Considered for Inclusion 단계라고 설명했다. 그러나 2026년 8월 27일 All Core Devs Execution call #244에서 EIP-8141은 Scheduled for Inclusion으로 올라갔고, 동시에 사양은 아직 바뀔 수 있다는 점도 표시됐다 .

범위를 좁혀야 한다는 Wahrstätter의 주장은 그 절충을 직설적으로 드러냈다.

“포크는 위시리스트가 될 수 없다” — 개발자들은 “모든 것을 한꺼번에 할 수 없다,” — Toni Wahrstätter, Ethereum Foundation 연구원 (source: Decrypt, 2026-08)

추적 문서 자체는 EIP-8081, “Hardfork Meta - Hegotá,”로, Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo, Parithosh Jayanthi가 작성했으며 2025년 11월 11일 생성됐고 아직 Draft 상태다 . 문서의 일정 항목만 봐도 아직 초기 단계임을 알 수 있다. Sepolia와 Hoodi 테스트넷, 그리고 메인넷 활성화 항목은 모두 비어 있으며, 클라이언트 팀들이 시점을 정한 뒤 채워질 예정이다. Ethereum.org의 Hegotá 로드맵 초안 페이지는 2027년 2분기를 예상 시점으로 제시하지만, 명시적으로 확정된 것은 아니라고 밝힌다 . 2026년 하반기를 목표로 하는 Glamsterdam이 Hegotá 작업이 본격적으로 시작되는 시점을 좌우한다. 실행 클라이언트 팀들은 2026년 9월 10일까지 Hegotá 선호도 순위를 제출해 달라는 요청을 받았다. 이는 약 50개 PFI 항목 가운데 실제 구현 지원을 받는 항목이 무엇인지 보여줄 다음 실질적 신호다 .

66개 후보가 두 개로 좁혀지는 과정: EIP-7723 단계 모델

대규모 후보군이 실제 포크에 실리는 과정은 EIP-7723에 정의되고 EIP-8081 메타 문서를 통해 적용되는 3단계 모델로 정리된다. Proposed for Inclusion(PFI), Considered for Inclusion(CFI), Scheduled for Inclusion(SFI) 단계다 . PFI는 공개 청원에 가깝다. 누구나 제안할 수 있다. CFI는 클라이언트 개발자들이 해당 제안을 프로토타입으로 검토할 가치가 있다고 본다는 신호다. SFI는 명세 변경 가능성을 남긴 채 해당 포크에 포함될 예정이라는 뜻이다. 대부분의 PFI 항목은 첫 단계 이후로 올라가지 못한다. 널리 인용되는 66개 제안이라는 숫자가 기능 목록이 아니라 신청 후보군을 가리키는 이유다.

이렇게 좁혀진 배경에는 명확한 범위 설정 논리가 있었다. 이더리움 재단 연구원 Toni Wahrstätter는 2026년 8월 16일 문제를 직설적으로 정리했다. “포크는 위시리스트가 될 수 없다”는 것이었고, 개발자들이 “모든 것을 한꺼번에 할 수는 없다”고 경고했다 . 그가 제시한 기준은 개념적 장점이 아니라 전달 가능성을 보여주는 증거였다. 현실적인 클라이언트 구현이 있는가, devnet 커버리지가 있는가, testnet에서 검증할 시간이 있는가, 2027년에 출시할 신뢰할 만한 경로가 있는가가 핵심이다. 이 파이프라인을 입증하지 못하는 제안은 거절이 아니라 연기 후보가 된다. 이번 기준을 통과하지 못한 제안도 이후 업그레이드에서 다시 검토될 수 있다 .

실행 클라이언트 팀의 선호 순위 제출 마감일인 2026년 9월 10일은 실질적인 관문이다. 순위는 어떤 PFI 항목 뒤에 작성자의 열의가 아니라 엔지니어링 지원이 있는지를 드러내며, 제안을 CFI로, 이어 SFI로 이동시키는 입력값이 된다 .

이 절차가 얼마나 빠르게 움직이는지는 이미 확인된다. 2026년 8월 17일 CoinDesk와 8월 16일 Cointelegraph가 보도한 8월 중순 시점의 언론 스냅샷에서는 FOCIL이 유일한 SFI 항목이었고, Frame Transaction은 아직 CFI에 머물러 있었다 . 11일 뒤인 2026년 8월 27일 All Core Devs Execution 콜 #244에서는 EIP-8141이 Scheduled for Inclusion으로 이동했으며, 명세가 아직 변경될 수 있다는 점도 함께 언급됐다 . 현재 EIP-8081은 EIP-7805와 EIP-8141을 모두 Scheduled for Inclusion 아래에 올려두고 있다 .

이 포크를 추적하는 사람에게는 두 가지 운영상 교훈이 따른다. 첫째, 66이라는 숫자는 로드맵이 아니라 특정 시점의 범위 설정 스냅샷으로 봐야 한다. 둘째, SFI는 일정 결정이지 기술적 동결이 아니다. SFI에 오른 EIP도 EIP-8081에 mainnet activation 항목이 채워지기 전까지는 명세가 수정되거나, 범위가 다시 조정되거나, 제외될 수 있다 . 단계 라벨은 특정 날짜에 합의가 어디까지 와 있는지를 알려줄 뿐, 2027년에 메인넷에서 실제로 무엇이 실행될지를 보장하지는 않는다.

FOCIL(EIP-7805): 포함 목록이 실제로 강제하는 것

FOCIL, 즉 EIP-7805에 명시된 Fork-Choice Enforced Inclusion Lists는 트랜잭션 포함 여부를 빌더의 재량이 아니라 블록 유효성의 조건으로 만드는 검열 저항 메커니즘이다. 각 슬롯마다 16명의 검증자로 구성된 위원회(IL_COMMITTEE_SIZE = 2^4)가 선택되어 각자 자신의 멤풀 관점에서 포함 목록을 만들어 공개하며, 다음 블록은 그 목록들을 충족해야 정식 체인으로 투표받을 수 있다 . 이 EIP는 Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann, Jihoon Song이 2024-11-01에 만들었으며, 현재도 Draft 상태로 남아 있다 .

이 메커니즘은 슬롯 내부의 촘촘한 시간표에 맞춰 작동한다. 슬롯 N의 처음 약 8초 동안 16명의 위원회 구성원은 각자 로컬에서 볼 수 있는 대기 트랜잭션으로 포함 목록을 만들고 이를 네트워크에 가십으로 전파한다. 검증자들은 대략 9초 지점까지 포함 목록을 계속 수락하며, 그 이후에는 관점이 고정되어 해당 슬롯에 더 이상의 목록은 반영되지 않는다. 그런 다음 슬롯 N+1의 제안자 또는 빌더는 목록에 오른 트랜잭션을 포함해야 하며, 어테스터들은 이중 제안하지 않은 위원회 구성원들로부터 저장된 모든 목록을 충족하는 블록에만 투표한다 .

실질적인 변화는 바로 마지막 조건에 있다. 제안자-빌더 분리 구조에서는 특정 트랜잭션을 마음에 들어 하지 않거나 외부 정책 때문에 제외해야 하는 빌더가 그 트랜잭션 없이 블록을 만들 수 있고, 프로토콜은 이를 문제 삼지 않는다. FOCIL은 이런 누락을 포크 선택상의 불이익으로 바꾼다. 준수하지 않은 블록은 어테스테이션을 끌어오지 못하고, 따라서 정식 체인이 되기 어려워진다. 준수는 더 이상 빌더의 선의에 기대는 호의가 아니라, 블록이 받아들여지기 위한 경제적 요구사항이 된다. 단일 제안자가 아니라 독립적인 위원회 구성원 16명을 일부러 사용하는 설계 덕분에, 트랜잭션을 검열하려면 한 명을 설득하는 것이 아니라 여러 검증자를 억눌러야 한다.

FOCIL이 하지 않는 일도 분명히 짚어둘 필요가 있다. Hegotá를 둘러싼 프라이버시 논의와 자주 뒤섞이기 때문이다. FOCIL은 아무것도 숨기지 않는다. 트랜잭션 내용, 송신자와 수신자 주소, 금액은 지금과 똑같이 모두 온체인에서 완전히 보인다 . 프라이버시 스택에서 FOCIL이 기여하는 부분은 기밀성이 아니라 가용성이다. 유효하고 수수료를 내는 프라이버시 풀 입금 또는 출금이 어느 한 빌더나 제안자에 의해 블록에서 빠지기 훨씬 어려워진다 . 온체인에서 작동하는 프라이버시 프로토콜은 선택적 배제에 가장 노출된 범주이기 때문에, 포함 보장과 프라이버시 도구가 서로 다른 문제를 해결함에도 같은 맥락에서 논의되는 것이다.

FOCIL은 새 제안으로 Hegotá에 들어온 것이 아니라, 한 차례 미뤄진 끝에 도달했다. 원래 Glamsterdam 범위에 포함되어 있었지만, 내장형 제안자-빌더 분리(ePBS)와 FOCIL을 같은 포크에서 함께 출시하면 메인넷 규모에서 검증되지 않은 상호작용 복잡성이 생길 수 있다는 우려로 제외되었다 . 두 변경 모두 블록 구성과 포크 선택 동작을 건드리며, 결합된 표면이 한 번의 릴리스 주기 안에서 검증하기에는 너무 크다고 판단되었다. 이 이력이 EIP-8081에서 FOCIL이 현재 어떤 위치에 있는지 설명해준다. FOCIL은 아직 Proposed for Inclusion에 머물러 있는 약 50개의 제안 대부분보다 더 많은 devnet 노출과 클라이언트 친숙도를 갖고 Hegotá에 들어왔고, 이것이 Scheduled for Inclusion에 가장 먼저 오른 큰 이유다 .

EIP-8141 프레임 트랜잭션: 이더리움의 네이티브 계정 추상화 베팅

EIP-8141, “Frame Transaction”은 Hegotá에서 Scheduled for Inclusion 단계에 오른 두 번째 제안으로, 새로운 EIP-2718 트랜잭션 유형인 FRAME_TX_TYPE 0x06을 도입합니다. 이 유형은 하나의 트랜잭션을 여러 개의 독립된 프레임으로 분해해 트랜잭션을 검증하고, 가스 결제를 승인하며, 사용자 작업을 실행하게 합니다 . 이 제안은 2026년 1월 29일 Vitalik Buterin, lightclient, Felix Lange, Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang, Toni Wahrstätter, Stavros Vlachakis를 포함한 10명의 저자가 만들었고, 2026년 8월 27일 ACDE #244에서 SFI로 이동한 뒤에도 사양이 여전히 변경될 수 있다는 단서와 함께 Draft 상태로 남아 있습니다 .

제안이 내세우는 동기는 프로토콜 수준의 계정 추상화입니다. 프레임 모델에서는 저자들의 표현처럼 계정이 하나의 고정된 ECDSA 서명 경로에 영구적으로 묶인 주소가 아니라, “코드를 가진 주소”가 됩니다 . 사양이 언급하는 이점은 이 분리에서 바로 이어집니다. 타원곡선 인증에서 포스트퀀텀 서명 체계로 이동할 수 있는 네이티브 출구, 네이티브 키 로테이션, 배치 호출 처리, 더 단순한 스마트 계정, 중앙화된 제3자 릴레이어를 거치지 않는 대체 수수료 결제가 가능해집니다 .

일반 지갑 입장에서는 현재 컨트랙트나 릴레이어 계층에서 구현되는 기능들이 네이티브 트랜잭션 형식 안으로 들어오는 셈입니다. 후원 가스, 여러 작업을 하나의 원자적 제출로 묶는 트랜잭션, 소셜 복구, 멀티시그 방식 검증, 지출 정책, 대체 서명 체계가 여기에 해당합니다. 실질적인 차이는 완전히 새로운 기능이라기보다 의존성 제거에 가깝습니다. 오늘날 후원 가스를 제공하는 지갑은 사용자와 네트워크 사이에 번들러나 페이마스터 인프라가 필요하지만, 프레임 모델에서는 지불자 역할이 트랜잭션 봉투의 필드가 됩니다.

사양의 상수들은 비용 모델과 구조적 한계를 함께 정의합니다.

출처: EIP-8141 사양, eips.ethereum.org .

12,000 gas의 고정 내재 비용과 프레임당 475 gas의 증분 비용은 설계 신호로 읽을 만합니다. 고정 오버헤드가 지배적이기 때문에 프레임을 추가하는 한계 비용을 의도적으로 낮게 두었고, 이는 배칭에 유리합니다. 64개 프레임 상한은 단일 트랜잭션이 블록 빌더에게 부과할 수 있는 최악의 검증 작업량을 제한합니다.

이 모든 것 위에는 하나의 미해결 질문이 놓여 있습니다. EIP-8141은 논의 테이블에 올라온 유일한 네이티브 계정 추상화 설계가 아닙니다. 클라이언트 팀들은 경쟁 제안인 EIP-8130과 이를 비교해 왔고, 그 비교는 실행 클라이언트 선호 순위 제출 마감일을 2026년 9월 10일로 정한 같은 논의 흐름 안에서 진행되고 있었습니다 . SFI 상태는 EIP-8141이 일정에 포함되었다는 뜻이지, 동결되었다는 뜻은 아닙니다. 사양은 바뀔 수 있으며, Hegotá 안의 계정 추상화 문제는 완전히 해결됐다기보다 합의에 더 가까워진 상태입니다.

아직 SFI에 오르지 못한 프라이버시 묶음: EIP-8250과 EIP-8272

EIP-8250과 EIP-8272는 계정 추상화를 실제로 쓸 수 있는 프라이버시 기본 요소로 바꾸는 두 가지 프레임 트랜잭션 확장이지만, 둘 다 Hegotá 일정에는 올라 있지 않습니다. 두 제안 모두 EIP-8081 메타 문서에서 Proposed for Inclusion 상태이고, 둘 다 Draft이며, 둘 다 EIP-8141을 필수 요건으로 명시합니다 . 이 의존성은 가능성을 읽는 데 중요합니다. 일정에 오른 상위 제안이 하위 제안까지 함께 끌어올리지는 않기 때문에, 현재 Hegotá에 붙은 프라이버시 기대는 실제로 일정에 오른 세 EIP 중 하나에 기대고 있는 셈입니다.

EIP-8250, 즉 프레임 트랜잭션용 키 기반 논스는 2026년 4월 16일 Thomas Thiery, Toni Wahrstätter, lightclient, Vitalik Buterin이 만들었습니다. 이 제안은 단일 선형 발신자 논스를 nonce_keys/nonce_seq 쌍으로 대체합니다. 각 키는 0x0000000000000000000000000000000000008250의 NONCE_MANAGER 시스템 컨트랙트가 추적하는 독립 시퀀스를 관리합니다. MAX_NONCE_KEYS는 16이고 MAX_NONCE_SEQ는 2⁶⁴ − 1이며, 키 0은 하위 호환성을 위해 기존 계정 논스의 별칭으로 동작합니다 . 이 제안이 해결하는 문제는 선두 대기 차단입니다. 프라이버시 풀은 서로 관련 없는 많은 사용자를 하나의 공유 발신자 주소로 라우팅하므로, 현재의 선형 논스에서는 트랜잭션 하나가 멈추거나 지연되면 그 뒤에 대기 중인 모든 출금이 막히거나 무효화됩니다. 서로 겹치지 않는 0이 아닌 키 집합은 재생 공격 관점에서 독립적이므로, 같은 발신자에서 여러 트랜잭션이 동시에 나갈 수 있습니다. 명세에서는 프라이버시 널리파이어에서 파생된 논스 도메인을 예시로 듭니다 . 놓치기 쉬운 단서도 있습니다. EIP-8250은 발신자당 대기 중인 공개 멤풀 프레임 트랜잭션을 하나로 제한하는 EIP-8141의 지침을 완화하지 않습니다. 프로토콜 수준의 장애물을 제거할 뿐, 키를 인식하는 멤풀 정책은 아직 마무리되지 않은 작업입니다.

EIP-8272, 즉 프레임 트랜잭션용 최근 루트는 2026년 5월 15일 Thomas Thiery, Vitalik Buterin, Toni Wahrstätter가 만들었으며, 다른 병목인 검증을 다룹니다. 프레임 트랜잭션은 서명된 봉투 안에 검증된 최근 커밋먼트 트리 루트를 선언할 수 있으므로, 지출 증명은 다른 계정에 속한 변경 가능한 스토리지를 읽지 않고도 확인될 수 있습니다 . 공개 멤풀 규칙은 변경되는 제3자 스토리지의 임의 읽기를 안전하게 허용할 수 없습니다. 읽는 대상 아래에서 상태가 바뀌면 대기 중인 트랜잭션이 무효화되고 서비스 거부 공격 경로가 열리기 때문입니다. 0x0000000000000000000000000000000000008272의 시스템 컨트랙트는 source_id와 슬롯을 기준으로 루트를 저장합니다. 클라이언트는 프레임 실행 전에 참조된 각 소스, 슬롯, 루트가 존재하며 여전히 최근 값인지 확인합니다. RECENT_ROOT_LENGTH는 8192이고 실제 사용 가능한 창은 8191이며, MAX_RECENT_ROOT_REFERENCES는 16입니다 .

이더리움 재단의 Protocol Architecture 그룹은 왜 세 EIP를 개별 제안이 아니라 하나의 묶음으로 봐야 하는지 설명했습니다. EIP-8141, EIP-8250, EIP-8272가 모두 갖춰지면 프라이버시 풀이 발신자이자 수수료 납부자 역할을 할 수 있고 누구나 트랜잭션을 브로드캐스트할 수 있으므로, 브로드캐스터에게 더 이상 특별 권한이 필요하지 않으며 신뢰된 릴레이어도 설계에서 빠집니다 . Wahrstätter의 공개 설명도 비슷했습니다. 그는 프로토콜 수준의 포함 보장과 지갑 활동 노출 감소가 결합되는 방식을 설명하며, "Together with Frames, these enable privacy pools where the pool itself can pay fees,"라고 말했습니다 (source: Decrypt, 2026-08).

트레이더가 이를 촉매로 읽는다면 붙잡아야 할 구분은 일정 확정과 후보의 차이입니다. 현재 약 50개의 EIP가 PFI 상태에 있으며 공식적으로 거절된 것은 없기 때문에, PFI는 최종 후보 명단이라기보다 넓은 대기 공간에 가깝습니다 . EIP-8250과 EIP-8272가 빠지더라도 이후 포크에 포함될 자격은 남습니다. 하지만 Hegotá 동안 프라이버시 풀은 계속 릴레이어에 의존하게 되고, 업그레이드에 붙은 "native privacy"라는 헤드라인은 미완성 스택을 가리키게 됩니다 (source: Cointelegraph, 2026-08).

개인정보 보호가 작동하려면 FOCIL과 Frame Transactions가 함께 적용되어야 하는 이유

FOCIL과 Frame Transactions는 같은 문제의 서로 다른 절반을 해결하며, 둘 중 하나만으로는 프라이버시 풀이 신뢰해야 하는 중개자에 계속 의존하게 된다. EIP-7805는 트랜잭션이 블록에 들어갈 수 있는지를 다루고, EIP-8141은 누가 그 비용을 지불할 수 있으며 어떻게 인증되는지를 다룬다 . 2026년 8월 27일 ACDE #244 이후 EIP-8141이 SFI로 이동하면서, 두 제안은 현재 EIP-8081에서 Scheduled for Inclusion 상태가 됐다 . 이 조합이 있기에 Hegotá에 붙은 프라이버시 서사가 비로소 신뢰할 만해진다.

둘을 따로 떼어 생각해보자. FOCIL 없는 Frames는 프라이버시 풀 출금에 깔끔한 프로토콜 네이티브 형태를 부여한다. 풀이 송신자이자 수수료 지불자가 되고, 가스는 전용 프레임에서 승인되며, 어떤 릴레이어도 이를 브로드캐스트하기 위해 특별 권한을 가질 필요가 없다 . 하지만 단일 빌더나 제안자는 여전히 이를 포함하지 않기로 할 수 있다. proposer-builder separation에서는 주소나 calldata 패턴으로 트랜잭션을 선별할 수 있는 주체들이 블록 내용을 정하고, 프라이버시 풀 출금은 식별 가능한 표적이 된다. 더 사적인 트랜잭션 형식이 포함될 권리까지 만들어주지는 않는다.

Frames 없는 FOCIL은 반대쪽 빈틈을 드러낸다. 16명의 검증자로 구성된 inclusion-list 위원회가 슬롯 N의 대략 첫 8초 동안 자신들의 멤풀 관점에서 목록을 만들고, attester들은 equivocation을 하지 않은 구성원이 저장한 모든 목록을 충족하는 슬롯 N+1 블록에만 투표한다. 따라서 포함 여부는 빌더의 재량이 아니라 정식 체인으로 인정받기 위한 조건이 된다 . 이 보장은 이미 멤풀에 들어와 있는 유효하고 수수료를 낼 수 있는 트랜잭션에만 적용된다. 바로 그 지점이 현재의 마찰이다. 새 주소로 출금하는 사용자는 가스를 낼 ETH가 없기 때문에 릴레이어가 대신 서명하고 브로드캐스트하게 되며, 설계가 없애려는 바로 그 중개자가 다시 들어온다.

Ethereum Foundation 연구원 Toni Wahrstätter는 이 조합이 번들의 핵심이라고 설명했다. Frames와 함께라면 이러한 변화가 풀이 직접 수수료를 낼 수 있는 프라이버시 풀을 가능하게 하고, 프로토콜 수준의 포함 보장과 지갑 활동 노출 감소를 결합한다는 것이다 . Hegotá 메타 스레드에 올라온 Ethereum Foundation의 Protocol Architecture 글도 구현 관점에서 같은 주장을 한다. 풀이 송신자이자 수수료 지불자가 되면 누구나 브로드캐스트할 수 있으므로, 브로드캐스터는 더 이상 특권적 역할이 아니게 된다 .

이 업그레이드를 둘러싼 축약된 설명이 자주 과장되기 때문에, 한 가지 단서는 특히 강조할 필요가 있다. 이 변화가 Ethereum을 프라이빗 체인으로 만드는 것은 아니다. 일반 ETH 전송은 Hegotá 이후에도 지금과 똑같이 완전히 투명하다. 금액, 주소, 내용은 모두 온체인에서 공개된다. FOCIL 자체는 아무것도 숨기지 않는다. 내용이 여전히 전부 보이는 트랜잭션의 포함을 강제할 뿐이다 . 이 조합이 제거하는 것은 현재 프라이버시 애플리케이션을 신뢰 기반 릴레이어로 밀어 넣는 프로토콜 수준의 마찰이다. 사용자가 프라이버시를 체감하는 것은 애플리케이션이 그 위에 프라이버시 프로토콜을 얹는 경우에 한하며, 그마저도 지갑, 클라이언트, 멤풀 정책, 감사가 따라온 뒤의 일이다 .

Hegotá 일정: 2027년 2분기 전까지 필요한 단계

Hegotá의 2027년 2분기 일정은 기대치이지 확정된 약속은 아니다. Ethereum.org의 Hegotá 로드맵 초안 페이지는 2027년 2분기를 예상 시점으로 적고 있지만 확정은 아니라고 밝히고 있으며 , 추적 문서인 EIP-8081도 Sepolia, Hoodi, mainnet 활성화 항목을 아직 비워두고 있다. 이 항목들은 클라이언트 팀들이 일정을 정한 뒤 채워질 예정이다 . 그 필드들이 채워지기 전까지는 누구에게도 적용할 수 있는 devnet이나 testnet 일정이 없다.

첫 번째 관문은 그보다 앞선 포크다. Glamsterdam은 2026년 하반기를 목표로 하며, Hegotá 작업은 그 업그레이드가 통과된 뒤에야 본격적으로 시작된다. 후속 포크가 devnet, 공개 testnet, mainnet 활성화 과정에서 선행 포크를 앞지를 수는 없기 때문이다 . Glamsterdam이 밀리면 Hegotá의 시기도 함께 이동하므로, 2027년이라는 표현은 계속 느슨하게 유지되고 있다.

다음의 구체적인 체크포인트는 더 가깝다. 실행 클라이언트 팀들은 2026년 9월 10일까지 Hegotá 선호 순위를 제출해 달라는 요청을 받았다 . 이 순위는 Proposed for Inclusion 상태인 약 50개 항목 중 무엇이 클라이언트의 관심을 받을지 가르는 실질적인 필터다. 어떤 제안이 devnet에 도달하는지는 회의에서의 호응이 아니라 구현 역량에 달려 있기 때문이다 . EIP-8250과 EIP-8272도 모두 그 풀 안에 있으므로, 이 순위는 프라이버시 번들이 함께 이동할지 조각나 이동할지를 읽을 수 있는 가장 가까운 신호다.

현재 정보 기준의 대략적인 순서는 다음과 같다.

• 2026년 9월 10일 — 클라이언트 선호 순위 제출 기한. 클라이언트 후원자가 없는 PFI 항목은 추진력을 잃는다 .
• 2026년 하반기 — Glamsterdam 활성화. Hegotá 사양 작업이 대기열 전면으로 이동한다 .
• 미정 — devnet, 이후 Sepolia와 Hoodi 활성화 epoch가 EIP-8081에 기록되고, 그다음 mainnet 블록이 정해진다 .

확정된 맥락도 하나 있다. 바로 이름이다. Ethereum은 실행 레이어 포크에 Devcon 개최 도시 이름을, 합의 레이어 포크에 별 이름을 붙인다. 그래서 Hegotá는 EL 릴리스 "Bogotá"와 CL 릴리스 "Heze"를 합친 이름이다 . EIP-8081 자체는 Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo, Parithosh Jayanthi가 2025년 11월 11일 만들었으며, 여전히 Draft 상태다 .

아직 바뀔 수 있는 것과 다음에 볼 신호

현재 Hegotá의 범위에서 확정된 것은 없습니다. Scheduled for Inclusion은 계획 단계의 상태일 뿐, 사양 동결을 뜻하지 않습니다. 2026년 8월 27일 All Core Devs Execution call #244에서 EIP-8141이 SFI로 이동했을 때, 개발자들은 Frame Transaction 사양이 여전히 바뀔 수 있다고 명확히 언급했습니다 . 예정 항목인 EIP-7805와 EIP-8141은 둘 다 아직 Draft 상태이며, 범위 조정 과정을 다룬 보도에서도 이번에 포함되지 못한 제안이 이후 업그레이드에서 다시 검토될 수 있다고 설명했습니다 .

범위에 들어온 항목은 다시 줄어들기 전에 더 늘어날 수도 있습니다. 현재 약 50개의 EIP가 Proposed for Inclusion 상태에 있으며, 공식적으로 거절된 제안은 아직 없습니다 . 이 대기열에는 메인넷에 실제 영향을 줄 가스 회계와 상태 증가 관련 작업도 포함돼 있습니다. 사용자 제어 트랜잭션 바이트당 64 gas의 균일한 하한을 두는 EIP-8131, 그 회계를 Block Access List 데이터로 확장하는 EIP-8279, 가스 한도가 500~600M을 향해 올라갈 때 상태 증가 가격 책정을 재조정하는 EIP-8368이 여기에 해당합니다 . 클라이언트 팀들이 relayer 없는 출금보다 처리량과 상태 건전성을 더 높게 평가한다면, 이 중 어느 하나가 프라이버시 항목을 밀어낼 수도 있습니다.

사양을 내놓는 것과 코드를 실제로 배포하는 것은 별개의 관문입니다. Frame transaction을 위해서는 실행 클라이언트가 트랜잭션 타입 0x06, 프레임 실행, APPROVE/TXPARAM/SIGPARAM 의미론, 가스 회계, mempool 제한을 구현해야 합니다. 지갑은 프레임별 영수증, payer 의미론, 새로운 검증 경로가 필요하고, 익스플로러와 인덱서는 프레임 영수증과 payer 필드를 파싱해야 합니다 . EIP-8250은 자체 공백도 솔직히 인정합니다. 이 제안은 하나의 주소에서 동시에 여러 전송을 보내는 데 막혀 있던 프로토콜 수준의 장애물은 제거하지만, 송신자당 대기 중인 공개 mempool frame transaction을 하나로 두라는 EIP-8141의 지침은 완화하지 않습니다. 결국 keyed nonce를 인식하는 mempool 정책은 아직 설계가 남아 있습니다 .

구체적으로는 가까운 순서대로 세 가지 신호를 추적할 만합니다.

• 클라이언트 선호도 순위. 실행 클라이언트 팀들은 2026년 9월 10일까지 Hegotá 순위를 제출해 달라는 요청을 받았습니다. 이는 이번 포크에서 프라이버시, 계정 추상화, 가스 재가격 책정 중 무엇이 앞서는지 보여줄 첫 번째 구체적 신호입니다 .
• EIP-8250과 EIP-8272의 PFI에서 CFI로의 이동. 두 제안 모두 아직 Considered for Inclusion을 통과하지 못했습니다. 통과 전까지는 relayer 없는 privacy pool 구상은 이론에 머뭅니다. 이 구상이 작동하려면 세 EIP가 모두 필요하기 때문입니다 .
• EIP-8141과 EIP-8130 사이의 결론. 개발자들은 예정된 Frame Transaction 설계와 경쟁안인 EIP-8130의 네이티브 계정 추상화 접근법을 비교해 왔습니다. 여기서 방향이 뒤집히면 프라이버시 묶음의 기반도 다시 설정됩니다 .

트레이더와 빌더에게 실무적으로 중요한 결론은 이렇습니다. Hegotá를 이미 출시된 기능 묶음이 아니라, 두 개의 중심 항목과 아직 정리되지 않은 중간 영역을 가진 2027년 로드맵 항목으로 봐야 합니다. Ethereum.org의 초안 로드맵 페이지는 2027년 2분기를 예상 시점으로 적고 있지만 확정이라고 하지는 않으며, EIP-8081에도 Sepolia, Hoodi, mainnet 활성화 항목은 아직 비어 있습니다 . 헤드라인보다 ACDE 콜 노트를 보는 편이 낫습니다. EIP-8081의 단계 전환이 실제로 무엇이 만들어지고 있는지를 안정적으로 추적할 수 있는 유일한 기록입니다.

자주 묻는 질문

Hegotá의 범위는 확정됐나요?

아닙니다. Hegotá의 범위는 아직 열려 있습니다. 2025-11-11에 Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo, Parithosh Jayanthi가 만든 추적 문서인 EIP-8081, “Hardfork Meta - Hegotá”는 여전히 Draft 상태이며 Sepolia, Hoodi, mainnet 활성화 항목도 비어 있습니다 . 2026년 8월 범위 조정 과정에서 논의된 약 66개 후보 중 EIP-7805(FOCIL)와 EIP-8141(Frame Transaction) 두 개만 Scheduled for Inclusion 상태이고, 약 50개는 Proposed for Inclusion에 머물러 있으며 공식적으로 거절된 것은 없습니다 . 이 목록은 확정된 기능 세트가 아니라 작업 중인 후보 목록으로 보는 것이 맞습니다.

Hegotá가 이더리움 거래를 비공개로 만드나요?

아닙니다. Hegotá 이후에도 일반 ETH 전송은 완전히 투명하게 유지됩니다. 송신자, 수신자, 금액은 온체인에서 계속 보이며, 특히 FOCIL은 거래 내용에 대해 아무것도 숨기지 않습니다 . 프라이버시 번들이 바꾸는 것은 프로토콜 수준의 마찰입니다. EIP-8141, EIP-8250, EIP-8272가 적용되면 프라이버시 풀이 송신자이자 수수료 지불자 역할을 할 수 있어, 특별한 권한 없이도 누구나 거래를 브로드캐스트할 수 있고 오늘날 프라이버시 앱이 의존하는 신뢰 기반 릴레이어를 없앨 수 있습니다 . 프라이버시는 여전히 베이스 레이어가 아니라 그 위에 구축되는 애플리케이션에서 나옵니다.

FOCIL과 Frame Transactions는 무엇이 다른가요?

두 제안은 서로 다른 문제를 해결합니다. FOCIL(EIP-7805)은 검열 저항 메커니즘입니다. 16명의 검증자로 구성된 inclusion-list 위원회(IL_COMMITTEE_SIZE = 2^4)가 슬롯마다 선택되고, 대략 처음 8초 동안 각자의 멤풀 관점에서 inclusion list를 만들며, attester는 그 목록을 충족하는 블록에만 투표합니다. 즉 포함 여부가 블록의 정식성 조건이 됩니다 . EIP-8141은 거래 자체를 재구성해 FRAME_TX_TYPE 0x06을 추가하고, 검증, 가스 승인, 실행 프레임을 분리해 네이티브 계정 추상화를 가능하게 합니다. 여기에는 스폰서 가스, 키 로테이션, 배치 호출, 대체 서명 방식이 포함됩니다 . 릴레이어 없는 프라이버시 풀에는 둘 다 필요합니다. Frame Transactions는 자체 수수료 지불을 가능하게 하고, FOCIL은 그 결과로 나온 거래가 조용히 배제되지 못하게 합니다.

EIP-8250과 EIP-8272는 왜 아직 예정되지 않았나요?

둘 다 EIP-8081에서 여전히 Proposed for Inclusion 상태인 의존 제안이며, 각각 EIP-8141이 먼저 적용되어야 한다고 명시하고 있습니다 . EIP-8250, Keyed Nonces(2026-04-16 생성)는 단일 선형 송신자 논스를 0x…8250의 시스템 컨트랙트가 관리하는 최대 16개의 독립 논스 키로 대체합니다. 이를 통해 하나의 멈춘 거래가 공유 풀 주소의 무관한 출금을 지연시키는 head-of-line blocking 문제를 해결합니다 . EIP-8272, Recent Roots(2026-05-15 생성)는 프레임 거래가 검증된 커밋먼트 트리 루트를 선언할 수 있게 합니다. RECENT_ROOT_LENGTH 8192, MAX_RECENT_ROOT_REFERENCES 16 조건 아래에서 지출 증명은 변경 가능한 제3자 스토리지를 위험하게 읽지 않고도 검증됩니다 . 둘 다 클라이언트 검토를 통과하지 않았고, 여전히 Draft 상태입니다.

Hegotá는 메인넷에서 언제 활성화되나요?

확정된 날짜는 없습니다. Ethereum.org의 Hegotá 로드맵 초안 페이지는 2027년 2분기를 예상 시점으로 제시하지만 확정은 아니며, EIP-8081에도 클라이언트 팀들이 일정을 정하기 전까지 Sepolia, Hoodi, mainnet 활성화 항목이 없습니다 . 일정은 상위 단계인 Glamsterdam에 의해 좌우됩니다. Glamsterdam은 2026년 하반기를 목표로 하며, 본격적인 Hegotá 구현 작업은 해당 포크가 마무리된 뒤에야 시작되기 때문입니다 . 실행 클라이언트 팀들은 2026년 9월 10일까지 Hegotá 선호도 순위를 제출해 달라는 요청을 받았고, 이것이 다음 구체적인 체크포인트입니다 .