SOC 2 Type II 인증 · ISO 27001

Ethereum 다음 하드 포크는 ‘글램스텔담(Glamsterdam)’으로, 합의 측면의 ‘글로아스(Gloas)’와 실행 측면의 ‘암스테르담(Amsterdam)’을 결합한 2단계 업그레이드입니다.

이번 포크는 Ethereum 전반에 걸쳐 프로토콜 수준에서 블록이 생성, 검증 및 실행되는 방식에 영향을 미치는 변경 사항을 도입합니다. 구체적인 업그레이드 항목을 살펴보기 전에, 대부분의 포크는 대개 가스 비용을 조정하거나, 오프코드를 추가·변경하는 등 영향이 적고 주로 시스템 상태를 점검하는 수준의 작업을 수행한다는 점을 먼저 짚어둘 필요가 있습니다.

그렇긴 하지만, 글램스터담(Glamsterdam)은 Ethereum 블록을 Ethereum 실행하는 방식을 구조적 차원에서 개선하는 것을 목표로 하는 보다 포괄적인 업그레이드입니다.

이 글에서는 ‘글램스터담(Glamsterdam)’, 확정된 2개의 EIP, 검토 중인 다른 EIP들, 그리고 이번 업그레이드와 관련된 모든 사항을 설명하겠습니다.

‘글램스터담’ 업그레이드 요약

1. 글램스터담은 2026년에 예정된 Ethereum 차기 하드 포크로, 푸사카의 후속 버전입니다.

2. 확정된 EIP는 단 두 개뿐입니다: EIP-7732 (ePBS) 그리고 EIP-7928 (BALs).

3. ePBS 또는 EIP-7732는 제안자와 빌더 간의 협업을 릴레이에서 프로토콜 내로 이전합니다.

4. EIP-7928은 블록 상태 접근 권한을 사전에 선언하는 블록 수준 접근 제어 목록(BAL)을 도입합니다.

5. ePBS와 BALs는 서로 결합되어 블록 생성 및 실행 과정에서 발생하는 사각지대를 해소합니다.

6. Glamsterdam은 병렬 실행, 검증, 그리고 향후 확장성 향상을 위한 기반을 마련합니다.

‘글램스텔담’ 업그레이드와 관련해 실제로 확정된 내용은 무엇인가요?

글램스터담에서 논의되고 있는 모든 사항 중에서, 공식적으로 포함될 예정인 EIP는 단 두 개뿐입니다:

• EIP-7732( 제안자와 구현자 분리 원칙의 명문화), 그리고

• EIP-7928 ( 블록 수준 액세스 목록)

현재 검토 중인 다른 제안들도 몇 가지 있지만, 우선 확정된 이 두 가지 개선 사항을 먼저 살펴보도록 합시다.

EIP-7732: 제안자와 구현자 분리(ePBS)의 제도화

EIP-7732 제안자와 빌더의 분리를 오프체인 인프라에서 Ethereum 자체로 이전합니다.

문제: 블록 빌드 작업이 외부 신뢰 모드에서 실행되고 있습니다.

오늘날, 대부분의 검증자 는 블록 생성을 전문 빌더에게 외주하고 있으며, 이 빌더들은 외부 릴레이(주로 MEV-Boost를 통해)를 통해 블록을 생성하고 전달합니다.

이러한 검증자-빌더 간의 관계는 Ethereum 외부에 위치한 제3자 ‘중계자’에 의해 ‘나를 믿어달라’는 전제 Ethereum 이루어지며, 암호화적 보장은 전혀 제공되지 않습니다.

ePBS는 이러한 신뢰 의존성을 제거합니다. 제안자와 빌더 간의 거래는 온체인에서 실시간으로 빌더의 입찰과 페이로드 약정을 가능하게 함으로써 프로토콜 자체로 통합됩니다.

ePBS의 실제 작동 방식

ePBS ePBS는 Ethereum 전체 블록 생성 과정의 Ethereum 삼고, 전 과정에 걸쳐 커밋-리빌 파이프라인을 적용합니다.

방법은 다음과 같습니다:

1. 건설사 입찰 및 적재량 약정

빌더들은 후보 블록을 생성하고 새로운 가십 토픽에 입찰을 게시합니다. 각 입찰에는 다음이 포함됩니다:

• 제안자에게 제공되는 가치

• 페이로드 약정 (실행 페이로드의 해시)

• 시공사의 서명

이 시점에서 네트워크는 어떤 페이로드가 제공될지는 알고 있지만, 그 내용은 알지 못합니다. 그리고 제안자가 빌더로부터 받는 대금은 프로토콜을 통해 정산됩니다.

이제 검증자들은 트랜잭션을 실행하지 않고도 비콘 블록을 즉시 인증할 수 있습니다.

2. 빌더가 실행 페이로드를 노출한다

비콘 블록이 승인된 후, 승리한 빌더는 앞서 제출한 커밋먼트와 일치하는 전체 실행 페이로드를 브로드캐스트합니다.

‘페이로드 적시성 위원회(PTC)’라고 불리는 검증자 그룹은 페이로드 적시성 위원회(PTC) 라고 불리는 유효성 검사자 그룹이 다음과 같은 기본 검증을 수행합니다:

• 시공사의 서명은 유효합니다

• 공개된 페이로드 해시가 커밋과 일치합니다.

• 블록이 참조하는 블롭 데이터가 사용 가능합니다.

PTC 구성원들은 블록을 생성하지 않습니다. 이들은 단지 페이로드가 제시간에 도착했는지, 그리고 커밋먼트와 일치하는지 확인하기만 합니다.

3. 네트워크 전반에 걸친 실행 검증

페이로드가 공개되면, 노드들은 트랜잭션을 실행하고 그 결과로 발생한 상태 전환이 블록과 일치하는지 확인합니다.

페이로드는 이미 이전에 확정되었기 때문에, 빌더는 입찰에 성공한 후에도 블록 내용을 수정할 수 없습니다.

시공사가 페이로드를 공개하지 않거나 제때 인도하지 못하는 경우:

• 해당 슬롯은 다음과 같이 기록됩니다. 비어 있음

• 제안자는 입찰 보증금을 보유한다

• 시공사는 입찰 금액 전액을 잃게 된다

이 과정에서 중개자나 기타 제3자는 개입하지 않습니다. Ethereum 프로토콜로서 그 결과를 온체인에서 직접 적용할 것입니다.

지금까지 EIP-7732 또는 ePBS가 주로 합의 수준에서 발생하는 블록 생성 문제를 해결한다는 사실을 알아보았습니다. Glamsterdam 업그레이드의 두 번째 확정된 변경 사항인 EIP-7928은 블록이 네트워크로 전달되어 실행될 때 발생하는 문제를 해결하는 것을 목표로 합니다. Ethereum

EIP-7928 — 블록 수준 액세스 목록(BAL)

EIP-7928 블록 수준 액세스 목록(BAL)을 도입합니다. 이는 블록 실행 중에 액세스된 계정 및 스토리지 슬롯을 기록한 것입니다.

문제: 상태 접근이 Ethereum 노드들의 발목을 잡고 있다

Ethereum 블록이 실행되는 동안 어떤 계정과 저장 슬롯에 영향을 미치는지만 파악합니다.

그때까지는 노드들이 블록의 상태 접근 패턴을 파악할 수 없습니다.

왜냐하면 Ethereum 상태가 디스크에 저장되어 있기 때문에, 실행 과정에서는 임의의 디스크 읽기 작업을 기다려야 하므로 상태 액세스가 주요 병목 현상이 됩니다.

EVM은 계산을 빠르게 완료할 수 있지만, 매일 용량이 늘어나는 데이터베이스를 오가며 각 저장소 읽기 작업이 완료되기를 기다려야 합니다.

EIP-7928이 이 문제를 해결합니다.

BAL의 실제 작동 원리

블록을 생성하는 동안, 빌더의 실행 클라이언트는 트랜잭션이 수행한 모든 상태 액세스 정보를 다음과 같이 기록합니다:

• 영향을 받은 계정

• 저장 슬롯 읽기

• 저장 슬롯 기록됨

그리고 이 지도는 블록 단위 액세스 목록입니다.

이 해시, 즉 ‘BAL 루트’는 블록 헤더에 포함됩니다. 전체 목록은 블록과 함께 네트워크상의 모든 노드로 전송됩니다.

간단히 말해, 이제 각 블록은 자신이 의존하는 상태에 대한 검증 가능한 지도를 담고 있습니다.

BAL이 Ethereum에 가져다주는 것

1. 실행이 시작되기 전에 전체 작업 상태가 미리 불러오기되므로, 실행 도중 발생하는 저장소 왕복 통신이 사라집니다.

2. BAL은 Ethereum병렬 트랜잭션 실행 전략을 가능하게 합니다 .

3. 상태 루트 계산 방법을 알고 있다 .

4. 또한 BAL은 모든 트랜잭션을 다시 실행하지 않고도 업데이트 내용을 명시하므로, ZK 검증에 유용합니다.

이제 우리는 ePBS와 BAL에 대해 깊이 있게 이해했으니,위험 이 무엇인지, 그리고 무엇을 개선하고자 하는지에 대해 파악했습니다. 하지만 이 두 가지가 함께 Ethereum 도움이 될까요?

‘글램스터담’이 Ethereum에서 실제로 가져오는 변화는 무엇인가

개별적으로, EIP-7732 와 EIP-7928 는 서로 매우 다른 문제를 해결합니다.

하지만 종합해 보면, 이들은 더 근본적인 역할을 수행합니다: Ethereum 내에서 ‘날 믿어’ 모델로 Ethereum 두 가지 부분을 드러내고, 이에 대한 해결책을 온체인에 구현합니다.

ePBS 덕분에 Ethereum 누가 블록을 생성했는지 파악하게 되었다

ePBS가 도입되기 전에는 프로토콜에서 빌더를 인식하지 못했습니다.

블록이 도착했고, Ethereum 는 누가 이를 구축했는지, 무엇을 약속했는지, 또는 그 약속을 지켰는지에 대한 기록이 전혀 없었습니다.

해당 정보는 외부 중계 인프라 내부의 오프체인 환경에 저장되어 있었습니다.

ePBS 이후, 빌더는 일류 프로토콜 참여자가 됩니다: 등록된 신원, 서명된 입찰, 그리고 프로토콜에 의해 강제되는 책임성을 갖춘 주체입니다.

하지만 솔직히 말해서, 이 점은 글램스터담 그 자체보다는 이를 통해 앞으로 어떤 가능성이 열릴지에 더 큰 의미가 있습니다.

FOCIL, 암호화된 멥풀과 같은 메커니즘, MEV라우팅 변경, 향후 빌더에 대한 제재 등은 모두 프로토콜이 빌더를 식별하고 약속을 이행하도록 강제할 수 있는 환경에서는 설계하기가 훨씬 더 쉬워집니다.

BAL은 Ethereum 블록이 어떤 상태에 영향을 미치는지 Ethereum 데 도움을 줍니다

BAL이 등장하기 전에는, Ethereum 또한 블록이 어떤 상태에 접근하게 될지 파악할 수 없었습니다.

BAL 이후에는 상태 접근 권한이 사전에 선언되고, 블록 헤더에 기록되며, 실제 실행 추적 기록과 대조하여 검증됩니다.

다음은 차세대 Ethereum 기술들이 모두 의존하고 있는 정보 계층입니다:

1. 병렬 실행을 위해서는 트랜잭션 충돌을 미리 파악해야 합니다 .

2. ZK 증명을 기반으로 한 실행은 상태 접근 내역이 명시적으로 기록된다는 점에서 이점을 얻습니다 .

3. 블록이 자신의 상태 점유 범위를 미리 선언해 두면, ‘분할된 상태’와 같은 보다 실험적인 설계에 대해서도 훨씬 쉽게 추론할 수 있게 됩니다 .

BAL은 이 모든 것들을 구조적으로 실현 가능하게 만듭니다.

이제 Ethereum 의존성 그래프로 간주할 수 있다

순차적 실행은 하나의 선택지입니다 Ethereum 필요에 의해 내린 선택입니다.

트랜잭션이 어떤 상태에 영향을 미치는지 미리 알지 못하면, 동시에 진행되는 두 트랜잭션 사이에 심각한 충돌이 발생할 위험이 있습니다. 한 트랜잭션이 다른 트랜잭션이 읽고 있던 상태를 덮어쓰게 되는 것입니다.

직렬화가 유일한 안전한 선택지였습니다.

BAL은 블록 실행을 의존성 그래프에 더 가까운 형태로 전환함으로써 이러한 문제를 해결합니다. 또한 그래프는 여러 스레드가 동시에 탐색할 수 있습니다.

독립적인 상태를 다루는 트랜잭션은 병렬로 스케줄링할 수 있으며, EVM이 실행되기 전에 필요한 상태를 미리 가져올 수 있습니다.

이 두 가지 EIP는 함께 Ethereum아키텍처에 오랫동안 존재해 온 두 가지 사각지대를 해소합니다.

이 두 가지 확정된 EIP 외에도, 이번 업그레이드와 관련해 더 광범위한 제안들이 검토되고 있습니다. 다음은 전체적인 현황입니다.

Glamsterdam 업그레이드와 관련된 EIP

포함 예정

‘예정’ = 이 포크에서 확정됨.

수록 검토 대상

‘검토 중’ = 평가 단계에 있으며, 확정된 것은 아닙니다.

참고: Glamsterdam 업그레이드와 관련해 검토 중인 EIP가 몇 가지 더 있습니다.

Glamsterdam 신청이 거절되었습니다

다음과 같은 30개 이상의 제안이 포크 대상에서 명시적으로 제외되었습니다:

• FOCIL 포함 목록

• 슬롯 시간 단축

• 다차원 가스 계량

• 포스트 양자 서명 검증

이것이 글램스텔담 업그레이드와 관련해 현재 논의되고 있는 제안들입니다. 하지만, 이것이 건설사나 개발사에게는 실제로 어떤 의미일까요?

실질적인 영향: ‘글램스텔담’이 여러분에게 주는 의미

‘글램스터담’이 미치는 영향은 우리 각자가 그 구조 내에서 어떤 위치에 있느냐에 따라 다르게 나타납니다.

대부분의 DApp 개발자들은 이를 거의 눈치채지 못하겠지만, 인프라 우선 접근 방식을 취하는 팀들은 상당한 노력을 기울여야 합니다. 이를 좀 더 자세히 살펴보겠습니다:

블록 프로덕션 스택

대상이 누구인가: 검증자, 빌더, 릴레이, MEV 인프라

운영 측면에서 가장 큰 변화는 ePBS에서 비롯됩니다.

릴레이 동작, 빌더 API 또는 현재의 제안자-빌더 핸드셰이크를 기반으로 구축된 모든 인프라는 새로운 모델에 비추어 재평가되어야 합니다.

• 빌더들은 온체인 신원을 통해 스테이킹 프로토콜 참여자가 됩니다.

• 검증자들은 페이로드의 적시성과 관련하여 위원회 구성원 자격, 새로운 시간 관련 민감 사항, 새로운 모니터링 요건 등 새로운 의무를 부여받게 됩니다 .

• MEV 인프라 업체들은 사적 주문 flow , 묶음 제출 방식, 그리고 타이밍에 대한 가정을 재검토해야 한다

데이터 및 툴링 스택

대상: RPC 제공업체, 인덱서, 블록 탐색기, 시뮬레이터

BAL에서는 ‘블록 상태 액세스 맵(Block State Access Map)’이라는 새로운 아티팩트를 도입합니다. 블록 데이터를 파싱, 인덱싱, 저장 또는 제공하는 모든 시스템은 스키마가 변경된다는 점에 유의하시기 바랍니다.

추적해야 할 항목:

• 블록 헤더에 block_access_list_root라는 새로운 필드가 추가됩니다.

• 엔진 API가 확장되어 페이로드에 BAL을 포함할 수 있게 되었습니다.

• eth/71은 BAL을 피어 투 피어 방식으로 제공하는 새로운 와이어 프로토콜입니다.*

• EL 클라이언트는 BAL을 최소 3,533 에포크 동안 저장해야 합니다. 이는 아카이빙 및 저장 비용에 대한 가정치가 변경됨을 의미합니다.

*이를 구현하지 않은 노드는 피어에게 BAL을 제공하거나 요청할 수 없습니다.

Dapp 레이어

대상: DApp 팀, 프로토콜 팀, 스마트 계약 개발자

솔직히 말해서, 대부분의 앱 레이어 팀은 당장 Glamsterdam에 대응할 필요가 없습니다.

다시 말해, Glamsterdam은 Ethereum 즉시 확장하는 것은 아닙니다. 이더리움의 확장 기술을 안전하게 적용하는 데 방해가 되었던 구조적인 병목 현상을 해소합니다.

하지만 실행 능력의 향상 다음은 무엇이 있을까요?

Ethereum의 향후 전망: 헤고타(Hegotá) 업그레이드

Glamsterdam이 Ethereum 정보 계층 Ethereum 누가 블록을 생성하는지, 그리고 어떤 상태를 다루는지 )을 드러낸다면, 다음 단계는 그 정보를 활용하여 검열 저항성을 강화하고 블록 포함 보장을 개선하는 것입니다.

여기서 가장 유력한 후보는 FOCIL(Fork-Choice Enforced Inclusion Lists)입니다.

FOCIL을 넘어, Ethereum 전반적인 Ethereum 한 가지 방향을 향하고 있습니다: 대규모 ZK 검증 실행을 향한 것입니다.

비탈릭의 확장성 프레임워크는 명확합니다. ePBS와 BAL은 단기적으로 실행 속도를 10~30배 향상시킵니다. ZK-EVM은 장기적으로 1,000배의 성능 향상을 가져옵니다.

Glamsterdam은 이러한 경로를 가능하게 하는 인프라 계층입니다.