이더리움 블록 레벨 액세스 리스트: EIP-7928 상태 지도 이해하기

이더리움이 더 많은 작업을 병렬로 처리하려면 먼저 각 트랜잭션이 어느 상태를 읽고 바꾸는지 알아야 해요. **이더리움 블록 레벨 액세스 리스트(Block-Level Access List, BAL)**는 바로 이 가시성 문제를 다룹니다. EIP-7928은 한 블록이 건드린 상태와 만들어 낸 값을 검증 가능한 지도로 정리해요. 이 글에서는 이를 블록체인 인프라 기초와 연결해 설명하되, 아직 진행 중인 명세를 성능 보장처럼 다루지는 않겠습니다.

2026년 9월 18일 기준 EIP-7928의 상태는 Review예요. 글램스테르담 메타 EIP에는 포함 예정으로 올라가 있고, ethereum.org는 개발망 테스트 중이며 2026년 4분기를 예상한다고 안내합니다. 메인넷 날짜는 아직 확정되지 않았어요. 아래 필드와 일정은 활성화된 메인넷 규칙이 아니라 현재 프로토콜 작업으로 보셔야 합니다.

블록 레벨 액세스 리스트란 무엇인가요?

블록 레벨 액세스 리스트는 이더리움 블록 실행 중 접근한 계정과 스토리지 위치를 RLP로 인코딩한 기록이에요. 트랜잭션 실행 뒤 바뀐 스토리지, 잔액, 논스(Nonce), 코드 값도 담습니다. 블록 헤더에는 전체 목록 자체가 아니라 block_access_list_hash라는 커밋먼트가 들어가고, 실행 클라이언트는 전체 목록을 별도로 저장·교환해요.

바쁜 창고의 피킹 목록을 떠올려 보세요. 여러 작업자가 출발하기 전에 각 주문이 방문할 선반을 지도에 표시합니다. 서로 다른 선반을 쓰는 주문은 동시에 가져올 수 있고, 같은 선반을 쓰는 주문은 안전한 순서를 지켜야 해요. 작업이 끝난 목록에는 재고가 어떻게 바뀌었는지도 남습니다.

단, 블록 빌더가 희망 사항을 적는 목록은 아니에요. 검증 클라이언트가 블록을 실행해 실제 접근 목록을 만들고 제공된 BAL과 비교합니다. 현재 EIP에서는 빠진 항목이나 불필요한 항목이 있으면 블록이 무효가 될 수 있어요.

EIP-7928은 상태를 어떻게 기록하나요?

제안은 계정 주소별로 데이터를 묶습니다. 각 AccountChanges 항목에는 다음 정보가 들어갈 수 있어요.

필드	기록 내용
storage_changes	작성된 스토리지 슬롯과 트랜잭션 실행 후 값
storage_reads	읽었지만 쓰지 않은 슬롯
balance_changes	바뀐 계정의 트랜잭션 실행 후 잔액
nonce_changes	트랜잭션 실행 후 논스
code_changes	새로 배포되거나 수정된 런타임 바이트코드

변경에는 block_access_index가 붙어요. 인덱스 0은 실행 전 시스템 호출, 1부터 n까지는 블록 순서대로 각 트랜잭션, n + 1은 실행 후 시스템 작업과 출금을 뜻합니다. 최종 스냅숏 하나만 보는 것이 아니라 상태가 어떤 순서로 바뀌었는지 재구성할 수 있는 구조예요.

인코딩도 결정적이어야 합니다. 계정과 스토리지 키를 정렬하고, 블록 헤더는 RLP 인코딩된 목록의 Keccak-256 해시를 저장해요. 이더리움 RLP 가이드에서 서로 다른 클라이언트가 같은 해시에 합의하려면 왜 표준 표현이 필요한지 확인해 보세요.

EIP-7928은 읽기 전용 접근도 포함합니다. 잔액이나 컨트랙트 코드, 스토리지 슬롯을 읽기만 해도 노드는 데이터베이스 작업을 하기 때문이에요. 읽기를 빼면 실제로는 의존 관계가 있는 작업을 독립적이라고 잘못 판단할 수 있습니다.

이 지도가 병렬 작업을 돕는 원리

이더리움 트랜잭션은 변경 가능한 상태를 공유해요. 트랜잭션 B가 트랜잭션 A가 쓴 값을 읽을 수 있으므로 모든 거래를 CPU 코어에 하나씩 무작정 나누면 결과가 틀릴 수 있습니다. 현재 클라이언트는 이런 의존 관계를 순서대로 실행하면서 발견하는 경우가 많아요.

BAL은 의존 관계가 생기는 표면을 드러냅니다. EIP가 목표로 제시하는 기능은 네 가지예요.

1. 병렬 디스크 읽기: 필요한 계정과 슬롯을 하나씩 발견하지 않고 동시에 가져올 수 있어요.
2. 병렬 트랜잭션 검증: 겹치지 않는 상태를 쓰는 거래는 병렬 작업으로 묶고, 충돌하는 거래는 순서를 유지합니다.
3. 병렬 상태 루트 계산: 알려진 실행 후 변경을 서로 독립적인 상태 가지별로 처리할 수 있어요.
4. 무실행 상태 업데이트(Executionless State Update): 동기화 노드가 과거의 모든 명령을 다시 실행하지 않고 인증된 실행 후 변경을 적용할 수 있습니다.

이 기능은 아키텍처의 가능성이지 고정 처리량 보장은 아니에요. 하드웨어, 클라이언트 구현, 블록 구성, 가스 한도와 충돌하는 거래 수에 따라 실제 성능이 달라집니다. 인기 컨트랙트 하나를 많은 거래가 함께 건드리는 블록은 서로 독립적인 전송만 있는 블록보다 병렬화하기 어려워요.

EIP-7928과 EIP-2930 액세스 리스트의 차이

이름은 비슷하지만 서로 다른 레이어의 문제를 해결해요.

질문	EIP-2930 트랜잭션 액세스 리스트	EIP-7928 블록 레벨 액세스 리스트
누가 제공하나요?	트랜잭션 발신자 또는 도구	블록 빌더가 제공하고 클라이언트가 검증
범위	트랜잭션 하나	시스템 작업을 포함한 블록 전체
주목적	가스 계산을 위해 나열된 상태를 미리 웜 처리	실제 상태 의존 관계와 실행 후 변경 공개
실행이 목록 안에 머물러야 하나요?	아니요	BAL이 실제 블록 실행과 일치해야 해요
결과 값을 담나요?	아니요	기록 대상 변경의 결과 값을 담아요

EIP-2930 액세스 리스트는 선택적으로 미리 비용을 내는 힌트예요. 트랜잭션이 목록 밖 상태에 접근해도 해당 콜드 액세스 비용을 내고 실행할 수 있습니다. BAL은 합의와 관련된 블록 데이터예요. 검증자는 실제 실행이 무엇을 건드렸는지와 비교합니다. EIP-2930에 적힌 항목이 BAL로 자동 복사되는 것도 아니에요. 실제로 접근하거나 변경한 상태만 들어갑니다.

노드는 BAL을 어떻게 받고 검증하나요?

일반적인 블록 처리에서 EIP-7928은 실행 페이로드가 RLP 인코딩된 blockAccessList를 전달하도록 엔진 API를 확장합니다. 실행 레이어는 해시를 계산하고 블록을 실행한 뒤 실제 목록을 만들어요. 두 목록이 다르면 거부합니다.

과거 데이터나 피어 기반 동기화에는 네트워크 경로도 필요해요. 현재 Review 상태인 EIP-8159는 GetBlockAccessLists와 BlockAccessLists 메시지를 갖는 eth/71 프로토콜을 제안합니다. 목록을 받은 클라이언트는 해당 블록 헤더에 커밋된 해시와 BAL을 대조해요. 모든 동기화 방식이 BAL을 필요로 하는 것은 아니고 보존 정책도 블록 본문과 다르므로, 제안은 일반 블록 본문과 별도로 목록을 전달합니다.

현재 EIP-7928 본문은 실행 클라이언트가 최소 약한 주관성 기간(Weak Subjectivity Period)인 3,533에포크 동안 BAL을 보관하도록 요구해요. 더 오래된 전체 목록은 커밋먼트를 남기고 제거될 수 있습니다. 운영자는 모든 노드가 모든 과거 목록을 제공한다고 가정하지 말고 최종 클라이언트 문서를 확인해야 해요.

사용자·개발자·노드 운영자에게 달라지는 점

일반 사용자

새 자산, 지갑 이전, 토큰 교환은 없어요. BAL은 프로토콜 내부 기반 시설입니다. “EIP-7928 활성화”를 위해 ETH를 보내거나 시드 구문을 알려 달라는 메시지는 사기예요.

애플리케이션 개발자

일반 스마트 컨트랙트의 의미가 애플리케이션용 허용 목록으로 바뀌지 않습니다. BAL이 컨트랙트에 안전한 동시성을 선언하게 하거나 트랜잭션 순서를 우회한다고 가정하면 안 돼요. 직접적인 작업 대상은 클라이언트, 트레이싱 도구, 블록 빌더, 동기화 시스템, 데이터 파이프라인 같은 저수준 인프라입니다.

노드·인프라 운영자

최종 페이로드, 검증, 저장, 프루닝, 피어 교환 규칙을 지원하는 클라이언트 릴리스가 필요해요. 자원 계획에서는 검증 속도 향상 가능성뿐 아니라 추가 데이터 처리 비용도 봐야 합니다. 일반화된 처리량 주장보다 테스트넷 결과와 클라이언트별 지침이 중요해요.

글램스테르담 상태 가스 가이드는 다른 확장 제약을 다룹니다. 데이터베이스 성장과 상태 접근에 비용을 매기는 문제예요. BAL은 작업을 보이게 만들고, 재책정은 그 작업의 지속 가능성을 높이려 합니다. 어느 쪽도 단독으로 수수료 인하를 보장하지 않아요.

리스크와 한계

• 명세 리스크: EIP-7928과 EIP-8159는 Review 상태예요. 활성화 전에 인코딩, 보존, 한도, 예외 규칙이 바뀔 수 있습니다.
• 일정 리스크: ethereum.org는 현재 2026년 4분기를 예상하지만 메인넷 활성화 날짜는 확정되지 않았어요.
• 검증 오버헤드: 클라이언트는 BAL 데이터를 수집·인코딩·해시·전송·비교해야 합니다. 한 단계의 속도 향상이 다른 단계에 비용을 더할 수 있어요.
• 데이터 가용성 리스크: 무실행 업데이트에는 관련 BAL이 제공되고 인증되어야 해요. 데이터가 제거됐거나 구할 수 없다면 그 동기화 경로를 쓸 수 없습니다.
• 충돌 한계: 많은 거래가 같은 상태를 공유하면 지도가 있어도 모두 독립적으로 실행할 수 없어요.
• 구현 리스크: 클라이언트마다 합의 규칙을 다르게 구현하면 무효 블록이나 체인 분리 위험이 생깁니다. 개발망과 상호운용성 테스트가 중요한 이유예요.
• 시장 리스크: 프로토콜 확장 작업은 ETH 가격을 예측하지 않습니다. 암호화폐는 변동성이 크므로 잃어도 되는 금액만 사용하고 스스로 조사하세요.

검증 체크리스트

BAL 관련 주장이나 구현을 평가할 때 다음 순서로 확인해 보세요.

1. EIP-7928의 현재 상태와 리비전을 확인합니다.
2. EIP-7773과 공식 클라이언트 릴리스에서 포함·활성화 여부를 확인해요.
3. “포함 예정”과 “메인넷 활성화”를 구분합니다.
4. 헤더 커밋먼트가 RLP 인코딩된 BAL과 일치하는지 검증해요.
5. 읽기 전용 위치와 시스템 작업까지 실제 상태 접근과 목록이 맞는지 확인합니다.
6. 충돌하는 거래 묶음과 충돌하지 않는 묶음을 나눠 테스트해요.
7. 병렬 벤치마크 하나가 아니라 전체 검증·동기화 비용을 측정합니다.
8. 결과와 함께 클라이언트 버전, 네트워크, 블록 번호, 명세 리비전을 기록해요.

자주 묻는 질문

BAL은 이미 이더리움 메인넷에서 작동하나요?

아니요. 2026년 9월 18일 기준 EIP-7928은 Review 상태이며 글램스테르담에 포함 예정입니다. ethereum.org는 개발망 테스트 중이고 2026년 4분기를 예상하지만 메인넷 날짜는 확정하지 않았어요.

모든 트랜잭션을 병렬로 실행하게 되나요?

아니요. BAL은 의존 관계를 드러내 독립 작업을 찾게 해 줍니다. 같은 상태를 건드리는 거래는 여전히 순서가 필요하고, 실제 속도는 클라이언트와 작업 구성에 따라 달라져요.

지갑이 eth_createAccessList로 EIP-7928 목록을 만들 수 있나요?

아니요. eth_createAccessList는 트랜잭션 단위의 EIP-2930 목록과 관련돼요. EIP-7928 BAL은 완전한 블록의 실제 상태 접근을 다루며 블록 처리 과정에서 검증됩니다.

무실행 동기화라면 노드가 블록 검증을 멈추나요?

아니요. 인증된 실행 후 데이터와 프로토콜 커밋먼트를 이용하는 상태 업데이트 경로이지, 임의의 값을 믿어도 된다는 뜻이 아닙니다. 노드는 관련 합의·헤더·BAL 검증 규칙을 따라야 해요.

BAL이 가스비를 자동으로 낮추나요?

고정된 절감은 보장되지 않아요. BAL은 검증과 동기화를 개선해 용량 여지를 만들 수 있지만, 수수료는 가스 계산, 블록 한도, 수요, 최종 클라이언트 성능의 영향도 받습니다.

주요 1차 출처

• EIP-7928: 블록 레벨 액세스 리스트
• EIP-7773: 글램스테르담 하드포크 메타
• Ethereum.org: 글램스테르담 로드맵
• EIP-8159: eth/71 블록 액세스 리스트 교환
• Ethereum.org: 보안 로드맵과 현재 진행 상황

핵심 정리

EIP-7928은 블록 안에 숨어 있던 상태 의존 관계를 결정적이고 커밋된 지도로 바꿉니다. 이 지도는 병렬 읽기와 검증, 더 빠른 상태 루트 작업, 무실행 상태 업데이트를 도울 수 있어요. 다만 실제 충돌, 데이터 가용성, 정확한 클라이언트 구현이라는 한계 안에서 작동합니다.

테스트넷부터 활성화까지 공식 명세를 계속 확인하세요. 이 글은 교육 목적이며 투자 조언이 아닙니다. 프로토콜 계획은 바뀔 수 있고 암호화폐 자산은 손실이 날 수 있어요. 행동하기 전에 최신 1차 출처를 직접 검증하세요(DYOR/NFA).