글램스테르담

이더리움의 다가오는 글램스테르담 업그레이드는 차세대 확장을 위한 길을 열기 위해 설계되었습니다. 글램스테르담이라는 이름은 "암스테르담(Amsterdam)"(이전 Devconnect 개최지에서 따온 실행 계층 업그레이드 이름)과 "글로아스(Gloas)"(별 이름에서 따온 합의 레이어 업그레이드 이름)의 조합에서 유래했습니다.

푸사카 업그레이드의 진전에 이어, 글램스테르담은 네트워크가 트랜잭션을 처리하고 증가하는 데이터베이스를 관리하는 방식을 재구성하여 레이어 1 (l1)을 확장하는 데 중점을 두며, 이더리움이 블록을 생성하고 검증하는 방식을 근본적으로 업데이트합니다.

푸사카가 기초적인 개선에 중점을 두었다면, 글램스테르담은 다양한 네트워크 참여자 간의 역할 분리를 프로토콜에 내재화(enshrining)하고, 높은 처리량의 병렬 처리를 위해 를 준비할 수 있도록 데이터를 처리하는 더 효율적인 방법을 도입하여 "레이어 1 (l1) 확장" 및 "블롭 확장" 목표를 발전시킵니다.

이러한 개선 사항은 이더리움이 더 많은 활동을 처리하면서도 빠르고 저렴하며 탈중앙화된 상태를 유지하도록 보장하는 동시에, 집에서 를 운영하는 사람들을 위해 하드웨어 요구 사항을 관리 가능한 수준으로 유지합니다.

글램스테르담에서 고려 중인 개선 사항

글램스테르담 업그레이드는 세 가지 주요 목표에 중점을 둡니다:

• 처리 속도 향상(병렬화): 네트워크가 데이터 종속성을 기록하는 방식을 재구성하여, 느리게 하나씩 순차적으로 처리하는 대신 많은 트랜잭션을 동시에 안전하게 처리할 수 있도록 합니다.
• 용량 확장: 블록을 생성하고 검증하는 무거운 작업을 분할하여, 속도 저하 없이 더 많은 양의 데이터를 전파할 수 있는 더 많은 시간을 네트워크에 제공합니다.
• 데이터베이스 비대화 방지(지속 가능성): 새로운 데이터를 저장하는 데 드는 장기적인 하드웨어 비용을 정확하게 반영하도록 네트워크 수수료를 조정하여, 하드웨어 성능 저하를 방지하면서 향후 가스 한도 증가의 장애물을 제거합니다.

요약하자면, 글램스테르담은 네트워크가 용량을 늘리더라도 지속 가능성을 유지하고 높은 성능을 유지할 수 있도록 구조적 변화를 도입할 것입니다.

레이어 1 (l1) 확장 및 병렬 처리

의미 있는 레이어 1 (l1) 확장을 위해서는 프로토콜 외부의 신뢰 가정과 직렬 실행의 제약에서 벗어나야 합니다. 글램스테르담은 특정 블록 생성 역할의 분리를 프로토콜에 내재화하고, 네트워크가 병렬 처리를 준비할 수 있도록 하는 새로운 데이터 구조를 도입하여 이 문제를 해결합니다.

주요 제안: 내재화된 제안자-빌더 분리 (ePBS)

• 프로토콜 외부의 신뢰 가정 및 제3자 릴레이에 대한 의존성 제거
• 확장된 전파 창(propagation window)을 통해 훨씬 더 큰 페이로드를 허용하여 레이어 1 (l1) 확장 지원
• 무신뢰 빌더 지불 방식을 프로토콜에 직접 도입
• 무신뢰 모니터링을 가능하게 하기 위해 스테이킹 풀의 아키텍처 업데이트가 필요하지만, 개선된 빌더 선택 프로세스를 통해 전반적인 스테이킹 사용자 경험 향상

현재 블록을 제안하고 생성하는 프로세스에는 블록 제안자와 블록 빌더 간의 핸드오프(hand-off)가 포함됩니다. 제안자와 빌더 간의 관계는 핵심 이더리움 프로토콜의 일부가 아니므로, 신뢰할 수 있는 제3자 미들웨어, 소프트웨어(릴레이) 및 엔티티 간의 프로토콜 외부 신뢰에 의존합니다.

제안자와 빌더 간의 프로토콜 외부 관계는 또한 블록 검증 중에 "핫 패스(hot path)"를 생성하여 가 2초라는 촉박한 시간 내에 트랜잭션 브로드캐스팅 및 실행을 서둘러 처리하도록 강제하며, 이는 네트워크가 처리할 수 있는 데이터의 양을 제한합니다.

내재화된 제안자-빌더 분리 (ePBS, 또는 EIP-7732)는 제안자(합의 블록을 선택하는 역할)와 빌더(실행 페이로드를 조립하는 역할)의 작업을 공식적으로 분리하여, 이 핸드오프를 프로토콜에 직접 내재화합니다.

지불을 위한 블록 페이로드의 무신뢰 교환을 프로토콜에 직접 구축하면 제3자 미들웨어(예: MEV-Boost)의 필요성이 사라집니다. 그러나 빌더와 제안자는 아직 핵심 프로토콜의 일부가 아닌 복잡한 기능을 위해 프로토콜 외부 릴레이나 미들웨어를 계속 사용할 수도 있습니다.

"핫 패스" 병목 현상을 해결하기 위해 ePBS는 페이로드 적시성 위원회(Payload Timeliness Committee, PTC)와 이중 마감일 로직을 도입하여, 검증자가 합의 블록과 실행 페이로드의 적시성을 개별적으로 증명하여 처리량을 극대화할 수 있도록 합니다.

프로토콜 수준에서 제안자와 빌더 역할을 분리하면 전파 창(또는 네트워크 전체에 데이터를 퍼뜨리는 데 사용할 수 있는 시간)이 2초에서 약 9초로 확장됩니다.

프로토콜 외부 미들웨어 및 릴레이를 프로토콜 내부 메커니즘으로 대체함으로써, ePBS는 신뢰 의존성을 줄이고 이더리움이 네트워크에 무리를 주지 않으면서 훨씬 더 많은 양의 데이터(를 위한 더 많은 블롭 등)를 안전하게 처리할 수 있도록 합니다.

자료: EIP-7732 기술 사양 (opens in a new tab)

주요 제안: 블록 수준 액세스 목록 (BAL)

• 모든 트랜잭션 종속성에 대한 사전 맵을 제공하여 순차적 처리 병목 현상을 제거하고, 검증자가 트랜잭션을 하나씩 처리하는 대신 여러 트랜잭션을 병렬로 처리할 수 있는 기반을 마련합니다.
• 노드가 모든 트랜잭션을 다시 실행할 필요 없이 최종 결과를 읽어 기록을 업데이트할 수 있도록 허용하여(실행 없는 동기화), 노드를 네트워크에 동기화하는 속도를 훨씬 빠르게 만듭니다.
• 추측을 배제하고 검증자가 필요한 모든 데이터를 단계별로 찾는 대신 한 번에 미리 로드할 수 있도록 하여 검증 속도를 크게 높입니다.

오늘날의 이더리움은 1차선 도로와 같습니다. 트랜잭션이 실행되기 전까지는 네트워크가 트랜잭션에 어떤 데이터가 필요하거나 변경될지(예: 트랜잭션이 어떤 계정을 건드릴지) 알 수 없기 때문에, 검증자는 엄격한 순차적 라인에 따라 트랜잭션을 하나씩 처리해야 합니다. 이러한 종속성을 모르는 상태에서 트랜잭션을 한 번에 모두 처리하려고 하면, 두 트랜잭션이 우연히 동시에 정확히 동일한 데이터를 변경하려고 시도하여 오류가 발생할 수 있습니다.

블록 수준 액세스 목록(BAL, 또는 EIP-7928)은 작업이 시작되기 전에 데이터베이스의 어느 부분에 액세스할지 자세히 설명하는 네트워크의 맵 역할을 합니다. 실행 계층은 트랜잭션이 건드릴 모든 계정 변경 사항과 해당 변경 사항의 최종 결과(모든 상태 액세스 및 실행 후 값)를 포함하여 전체 블록 액세스 목록을 저장합니다. 블록을 가볍게 유지하기 위해 블록 헤더에는 이 목록의 고유한 디지털 지문(해시 기록)이 포함된 새로운 필드가 포함됩니다.

BAL은 겹치지 않는 트랜잭션을 즉시 파악할 수 있게 해주므로, 노드가 병렬 디스크 읽기를 수행하여 여러 트랜잭션에 대한 정보를 동시에 가져올 수 있도록 합니다. 네트워크는 관련 없는 트랜잭션을 안전하게 그룹화하고 병렬로 처리할 수 있습니다.

BAL에는 트랜잭션의 최종 결과(실행 후 값)가 포함되어 있으므로, 네트워크의 노드가 네트워크의 현재 상태에 동기화해야 할 때 해당 최종 결과를 복사하여 기록을 업데이트할 수 있습니다. 검증자는 무슨 일이 일어났는지 알기 위해 더 이상 처음부터 모든 복잡한 트랜잭션을 다시 실행할 필요가 없으므로, 새로운 노드가 네트워크에 더 빠르고 쉽게 참여할 수 있습니다.

BAL을 통해 가능해진 병렬 디스크 읽기는 이더리움이 한 번에 많은 트랜잭션을 처리할 수 있는 미래를 향한 중요한 단계가 될 것이며, 네트워크의 속도를 크게 높일 것입니다.

eth/71 블록 액세스 목록 교환

블록 액세스 목록 교환(eth/71 또는 EIP-8159)은 블록 수준 액세스 목록의 직접적인 네트워킹 동반자입니다. BAL이 병렬 실행을 가능하게 하는 반면, eth/71은 피어 투 피어 프로토콜을 업그레이드하여 노드가 네트워크를 통해 이러한 목록을 실제로 공유할 수 있도록 합니다. 이제 모든 실행 계층 클라이언트에 필수적인 블록 액세스 목록 교환은 더 빠른 동기화를 가능하게 하고 노드가 실행 없는 상태 업데이트를 수행할 수 있도록 합니다.

자료:

• EIP-7928 기술 사양 (opens in a new tab)
• EIP-8159 기술 사양 (opens in a new tab)

네트워크 지속 가능성

이더리움 네트워크가 더 빠르게 성장함에 따라, 사용 비용이 이더리움을 실행하는 하드웨어의 마모 정도와 일치하도록 보장하는 것이 중요합니다. 네트워크는 더 많은 트랜잭션을 안전하게 확장하고 처리하기 위해 전체 용량 한도를 늘려야 합니다.

상태 생성 가스 비용 증가

• 새로운 계정이나 스마트 컨트랙트를 생성하는 수수료가 이더리움 데이터베이스에 가하는 장기적인 부담을 정확하게 반영하도록 보장합니다.
• 연간 120 GiB의 안전하고 예측 가능한 성장률을 목표로 하는 고정된 상태 바이트당 비용(CPSB)을 설정하여, 표준 물리적 하드웨어가 네트워크를 계속 실행할 수 있도록 보장합니다.
• 이러한 특정 수수료에 대한 회계를 새로운 저장소(reservoir)로 분리하여, 기존 트랜잭션 한도를 제거하고 개발자가 더 크고 복잡한 애플리케이션을 배포할 수 있도록 합니다.

새로운 계정, 토큰 및 를 추가하면 네트워크를 실행하는 모든 컴퓨터가 무기한 저장해야 하는 영구 데이터("상태"라고 함)가 생성됩니다. 이 데이터를 추가하거나 읽는 현재 수수료는 일관성이 없으며 네트워크 하드웨어에 가하는 실제 장기적인 스토리지 부담을 반드시 반영하지는 않습니다.

새로운 계정을 생성하거나 대규모 스마트 컨트랙트를 배포하는 등 이더리움에서 상태를 생성하는 일부 작업은 네트워크 노드에서 차지하는 영구 저장 공간에 비해 상대적으로 비용이 저렴했습니다. 예를 들어, 컨트랙트 배포는 스토리지 슬롯을 생성하는 것보다 바이트당 비용이 훨씬 저렴합니다.

조정이 없다면, 네트워크가 글램스테르담을 통해 가능해진 2억 가스 한도 하한선(정확한 상태 가격 책정을 도출하기 위해 개발자들이 현재 1억 5천만 참조 블록 가스 한도에서 테스트 중)을 향해 확장됨에 따라 이더리움의 상태 성장은 지속 불가능해질 것입니다.

상태 생성 가스 비용 증가(또는 EIP-8037)는 비용을 생성되는 데이터의 실제 크기와 연계하여 조화시키며, 작업이 생성하거나 액세스하는 영구 데이터의 양에 비례하도록 수수료를 업데이트합니다.

EIP-8037은 또한 이러한 비용을 더 예측 가능하게 관리하기 위해 저장소 모델을 도입합니다. 상태 가스 요금은 먼저 state_gas_reservoir에서 차감되며, GAS 연산 코드는 gas_left만 반환하여 실행 프레임이 사용 가능한 가스를 잘못 계산하는 것을 방지합니다. 이를 지원하기 위해 필수 백그라운드 작업에는 이 전용 예비금으로 바로 들어가는 추가 연료 허용량이 부여되어, 영구 데이터를 저장하는 데 더 많은 리소스가 필요하다는 이유만으로 중요한 네트워크 작업이 실패하지 않도록 보장합니다.

EIP-8037 이전에는 계산 작업(활성 처리)과 영구 데이터 저장(스마트 컨트랙트를 네트워크 데이터베이스에 저장)이 모두 동일한 가스 한도를 공유했습니다. 저장소 모델은 회계를 분리합니다. 즉, 트랜잭션의 실제 계산 작업(처리)을 위한 가스 한도와 장기 데이터 저장(상태 가스)을 위한 가스 한도를 나눕니다. 이 둘을 분리하면 애플리케이션 데이터의 엄청난 크기로 인해 가스 한도가 초과되는 것을 방지하는 데 도움이 됩니다. 개발자가 데이터 저장을 위해 저장소를 채울 충분한 자금을 제공하는 한, 훨씬 더 크고 복잡한 스마트 컨트랙트를 배포할 수 있습니다.

데이터 스토리지 가격을 더 정확하고 예측 가능하게 책정하면 이더리움이 데이터베이스를 비대화하지 않고도 속도와 용량을 안전하게 늘리는 데 도움이 됩니다. 이러한 지속 가능성을 통해 노드 운영자는 향후 몇 년 동안 (상대적으로) 저렴한 하드웨어를 계속 사용할 수 있으며, 네트워크의 탈중앙화를 유지하기 위해 홈 스테이킹에 대한 접근성을 유지할 수 있습니다.

자료: EIP-8037 기술 사양 (opens in a new tab)

상태 액세스 가스 비용 업데이트

• 애플리케이션이 이더리움에 영구적으로 저장된 정보를 읽거나 업데이트할 때(상태 액세스 연산 코드) 발생하는 가스 비용을 늘려, 이러한 명령에 필요한 컴퓨팅 작업과 정확히 일치시킵니다.
• 인위적으로 저렴한 데이터 읽기 작업을 악용하는 서비스 거부(DoS) 공격을 방지하여 네트워크 복원력을 강화합니다.

이더리움의 상태가 커짐에 따라 오래된 데이터를 검색하고 읽는 작업("상태 액세스")은 노드가 처리하기에 더 무겁고 느려졌습니다. (컴퓨팅 파워 측면에서) 정보를 찾는 데 비용이 약간 더 들게 되었음에도 불구하고 이러한 작업에 대한 수수료는 동일하게 유지되었습니다.

결과적으로 일부 특정 명령은 현재 노드에 강제하는 작업에 비해 가격이 낮게 책정되어 있습니다. 예를 들어 EXTCODESIZE 및 EXTCODECOPY는 계정 객체에 대해 한 번, 실제 코드 크기 또는 바이트코드에 대해 두 번째로 총 두 번의 개별 데이터베이스 읽기가 필요하기 때문에 가격이 낮게 책정되어 있습니다.

상태 액세스 가스 비용 업데이트(또는 EIP-8038)는 계정 및 컨트랙트 데이터 조회와 같은 상태 액세스 연산 코드에 대한 가스 상수를 늘려 최신 하드웨어 성능 및 상태 크기에 맞춥니다.

상태 액세스 비용을 조정하는 것은 이더리움의 복원력을 높이는 데에도 도움이 됩니다. 이러한 무거운 데이터 읽기 작업이 인위적으로 저렴하기 때문에, 악의적인 공격자가 네트워크의 수수료 한도에 도달하기 전에 단일 블록에서 수천 개의 복잡한 데이터 요청으로 네트워크에 스팸을 보내 네트워크를 지연시키거나 충돌(서비스 거부 공격)을 일으킬 수 있습니다. 악의적인 의도가 없더라도 네트워크 데이터를 읽는 것이 너무 저렴하다면 개발자는 효율적인 애플리케이션을 구축하도록 경제적으로 장려받지 못합니다.

상태 액세스 작업의 가격을 더 정확하게 책정함으로써 이더리움은 우발적이거나 의도적인 속도 저하에 대해 더 큰 복원력을 가질 수 있으며, 네트워크 비용을 하드웨어 부하에 맞추는 것은 향후 가스 한도 증가를 위한 더 지속 가능한 기반이 됩니다.

자료: EIP-8038 기술 사양 (opens in a new tab)

네트워크 복원력

검증자 의무 및 종료 프로세스의 개선은 대규모 슬래싱 이벤트 동안 네트워크 안정성을 보장하고 유동성을 민주화합니다. 이러한 개선 사항은 네트워크를 더 안정적으로 만들고 크고 작은 모든 참여자가 공정하게 대우받도록 보장합니다.

슬래싱된 검증자를 제안에서 제외

• 페널티를 받은(슬래싱된) 검증자가 향후 블록을 제안하도록 선택되는 것을 막아, 확정적으로 누락되는 슬롯을 제거합니다.
• 이더리움이 원활하고 안정적으로 실행되도록 유지하여, 대규모 슬래싱 이벤트 발생 시 심각한 지연을 방지합니다.

현재는 검증자가 슬래싱(규칙을 위반하거나 예상대로 작동하지 않아 페널티를 받음)되더라도, 시스템이 향후 제안자 예측(lookahead)을 생성할 때 가까운 미래에 블록을 이끌도록 해당 검증자를 계속 선택할 수 있습니다.

슬래싱된 제안자의 블록은 유효하지 않은 것으로 자동 거부되므로, 이로 인해 네트워크에서 슬롯이 누락되고 대규모 슬래싱 이벤트 중에 네트워크 복구가 지연됩니다.

슬래싱된 검증자를 제안에서 제외(또는 EIP-8045)는 단순히 슬래싱된 검증자가 향후 임무에 선택되지 않도록 필터링합니다. 이는 건강한 검증자만 블록을 제안하도록 선택되게 하여 체인 복원력을 향상시키고, 네트워크 중단 중에도 서비스 품질을 유지합니다.

자료: EIP-8045 기술 사양 (opens in a new tab)

종료 시 통합 대기열 사용 허용

• 잔액이 많은 검증자가 통합 대기열을 통해 소규모 검증자보다 더 빨리 네트워크를 종료할 수 있도록 하는 허점을 차단합니다.
• 여유 용량이 있을 때 일반 종료가 이 두 번째 대기열로 넘어갈 수 있도록 허용하여, 대량 요청 기간 동안 스테이킹 인출 시간을 줄입니다.
• 이더리움의 핵심 안전 한도를 변경하거나 네트워크를 약화시키지 않도록 엄격한 보안을 유지합니다.

펙트라 업그레이드로 이더리움 검증자의 최대 유효 잔액이 32 ETH에서 2,048 ETH로 증가한 이후, 기술적 허점으로 인해 잔액이 많은 검증자가 통합 대기열을 통해 소규모 검증자보다 더 빨리 네트워크를 종료할 수 있게 되었습니다.

종료 시 통합 대기열 사용 허용(또는 EIP-8080)은 모든 스테이킹 종료에 대해 통합 대기열을 민주화하여 모두를 위한 단일하고 공정한 대기열을 만듭니다.

현재 작동 방식을 분석해 보면 다음과 같습니다:

• 이더리움의 변동 한도는 네트워크의 보안이 결코 불안정해지지 않도록 검증자가 스테이킹된 ETH를 입력, 종료 또는 병합(통합)할 수 있는 속도에 대한 안전 한도입니다.
• 검증자 통합은 표준 검증자 종료보다 더 많은 가동 부분이 있는 무거운 작업이므로, 이 안전 예산(변동 한도)의 더 큰 부분을 차지합니다.
• 구체적으로, 프로토콜은 하나의 표준 종료에 대한 정확한 보안 비용이 하나의 통합 비용의 3분의 2(2/3)라고 규정합니다.

더 공정한 종료 대기열은 종료 수요가 많은 기간 동안 표준 종료가 통합 대기열에서 사용되지 않은 공간을 빌릴 수 있도록 허용하며, "2개당 3개"의 교환 비율을 적용합니다(사용되지 않은 통합 자리 2개당 네트워크는 3개의 표준 종료를 안전하게 처리할 수 있음). 이 3/2 변동 계수는 통합 및 종료 대기열 전반에 걸쳐 수요의 균형을 맞춥니다.

통합 대기열에 대한 액세스를 민주화하면 네트워크 보안을 손상시키지 않으면서 수요가 많은 기간 동안 사용자가 스테이크를 종료할 수 있는 속도가 최대 2.5배 증가합니다.

자료: EIP-8080 기술 사양 (opens in a new tab)

사용자 및 개발자 경험 개선

이더리움의 글램스테르담 업그레이드는 사용자 경험을 개선하고, 데이터 검색 가능성을 높이며, 증가하는 메시지 크기를 처리하여 동기화 실패를 방지하는 것을 목표로 합니다. 이를 통해 온체인에서 일어나는 일을 더 쉽게 추적할 수 있으며, 네트워크가 확장됨에 따라 발생하는 기술적 문제를 방지할 수 있습니다.

내재적 트랜잭션 가스 비용 감소

• 트랜잭션의 기본 수수료를 낮춰 단순한 네이티브 ETH 결제의 전체 비용을 줄입니다.
• 소액 전송을 더 저렴하게 만들어 일상적인 교환 수단으로서 이더리움의 실행 가능성을 높입니다.

오늘날 모든 이더리움 트랜잭션은 처리의 단순성이나 복잡성에 관계없이 고정된 기본 가스비를 갖습니다. 내재적 트랜잭션 가스 감소(또는 EIP-2780)는 기존 계정 간의 표준 ETH 전송을 최대 71% 더 저렴하게 만들기 위해 해당 기본 수수료를 줄일 것을 제안합니다.

내재적 트랜잭션 가스 감소는 디지털 서명 검증 및 잔액 업데이트와 같이 네트워크를 실행하는 컴퓨터가 실제로 수행하는 기본적이고 필수적인 작업만 반영하도록 트랜잭션 수수료를 세분화하여 작동합니다. 기본 ETH 결제는 복잡한 코드를 실행하거나 추가 데이터를 전달하지 않으므로, 이 제안은 가벼운 공간 차지(footprint)에 맞게 수수료를 줄일 것입니다.

이 제안은 낮은 수수료가 네트워크의 상태를 압도하는 것을 방지하기 위해 완전히 새로운 계정을 생성하는 것에 대한 예외를 도입합니다. 전송이 비어 있는 존재하지 않는 주소로 ETH를 보내는 경우, 네트워크는 이에 대한 영구적인 새 기록을 생성해야 합니다. 장기적인 스토리지 부담을 충당하는 데 도움이 되도록 해당 계정 생성에 가스 할증료가 추가됩니다.

결과적으로 EIP-2780은 기존 계정 간의 일상적인 전송을 더 저렴하게 만드는 동시에, 진정한 상태 성장의 가격을 정확하게 책정하여 데이터베이스 비대화로부터 네트워크를 계속 보호하는 것을 목표로 합니다.

자료: EIP-2780 기술 사양 (opens in a new tab)

결정론적 팩토리 사전 배포

• 개발자에게 여러 체인에 걸쳐 정확히 동일한 주소에 애플리케이션과 스마트 컨트랙트 지갑을 배포할 수 있는 네이티브 방법을 제공합니다.
• 사용자가 여러 레이어 2 (l2) 네트워크에서 동일한 스마트 지갑 주소를 가질 수 있도록 하여 인지 부하를 줄이고, 혼란을 줄이며, 우발적인 자금 손실 위험을 줄입니다.
• 개발자가 현재 이러한 동등성을 달성하기 위해 사용하는 해결 방법을 대체하여, 다중 체인 지갑 및 앱을 더 쉽고 안전하게 구축할 수 있도록 합니다.

오늘날 사용자가 여러 이더리움 가상 머신(EVM) 호환 체인에 걸쳐 계정이 있는 스마트 컨트랙트 지갑을 가지고 있는 경우, 종종 다른 네트워크에서 완전히 다른 주소를 갖게 됩니다. 이는 혼란스러울 뿐만 아니라 우발적인 자금 손실로 이어질 수 있습니다.

결정론적 팩토리 사전 배포(또는 EIP-7997)는 개발자에게 이더리움 메인넷, 레이어 2 (l2) 네트워크 등을 포함한 여러 EVM 체인에 걸쳐 정확히 동일한 주소에 탈중앙화된 애플리케이션과 스마트 컨트랙트 지갑을 배포할 수 있는 네이티브 내장 방법을 제공합니다. 채택될 경우, 사용자는 참여하는 모든 체인에서 정확히 동일한 주소를 가질 수 있게 되어 인지 부하와 사용자 오류 가능성을 크게 줄일 수 있습니다.

결정론적 팩토리 사전 배포는 참여하는 모든 EVM 호환 체인의 동일한 위치(구체적으로 주소 0x12)에 최소한의 특수 팩토리 프로그램을 영구적으로 배치하는 방식으로 작동합니다. 그 목표는 모든 EVM 호환 네트워크에서 채택할 수 있는 보편적이고 표준적인 팩토리 컨트랙트를 제공하는 것입니다. EVM 체인이 참여하고 이 표준을 채택하는 한, 개발자는 이를 사용하여 해당 네트워크의 정확히 동일한 주소에 스마트 컨트랙트를 배포할 수 있습니다.

이러한 표준화는 개발자와 더 넓은 생태계를 위해 크로스체인 애플리케이션 구축 및 관리를 단순화합니다. 개발자는 더 이상 다른 네트워크에 걸쳐 소프트웨어를 함께 연결하기 위해 사용자 지정 체인별 코드를 구축할 필요가 없으며, 대신 이 범용 팩토리를 사용하여 모든 곳에서 애플리케이션에 대해 정확히 동일한 주소를 생성합니다. 또한 블록 탐색기, 추적 서비스 및 지갑은 다양한 체인에 걸쳐 이러한 애플리케이션과 계정을 더 쉽게 식별하고 연결할 수 있으므로, 모든 이더리움 기반 참여자를 위해 더 통합되고 원활한 다중 체인 환경을 조성할 수 있습니다.

자료: EIP-7997 기술 사양 (opens in a new tab)

ETH 전송 및 소각 시 로그 발생

• ETH가 전송되거나 소각될 때마다 영구적인 기록(로그)을 자동으로 생성합니다.
• 앱, 거래소 및 브릿지가 임시 추적 도구 없이도 사용자 입금을 안정적으로 감지할 수 있도록 하는 역사적인 사각지대를 수정합니다.

토큰(ERC-20)과 달리 스마트 컨트랙트 간의 일반적인 ETH 전송은 명확한 영수증(표준 로그)을 발생시키지 않으므로 거래소와 앱에서 추적하기 어렵습니다.

ETH 전송 및 소각 시 로그 발생(또는 EIP-7708)은 0이 아닌 금액의 ETH가 이동하거나 소각될 때마다 네트워크가 표준 로그 이벤트를 발생시키도록 의무화합니다.

이를 통해 지갑, 거래소 및 브릿지 운영자는 사용자 지정 도구 없이도 입금 및 이동을 훨씬 쉽고 안정적으로 정확하게 추적할 수 있습니다.

자료: EIP-7708 기술 사양 (opens in a new tab)

eth/70 부분 블록 영수증 목록

이더리움이 수행할 수 있는 작업량을 늘림에 따라, 해당 작업에 대한 영수증 목록(이러한 트랜잭션의 데이터 기록)이 너무 커져서 네트워크의 노드가 서로 데이터를 동기화하려고 할 때 잠재적으로 실패를 일으킬 수 있습니다.

이제 모든 실행 계층 클라이언트에 필수적인 eth/70 부분 블록 영수증 목록(또는 EIP-7975)은 노드가 서로 통신하는 새로운 방법(eth/70)을 도입하여 이러한 큰 목록을 더 작고 관리하기 쉬운 조각으로 나눌 수 있도록 합니다. eth/70은 네트워크의 통신 프로토콜에 대한 페이지 매김(pagination) 시스템을 도입하여 노드가 블록 영수증 목록을 나누고 더 작고 관리하기 쉬운 청크로 데이터를 안전하게 요청할 수 있도록 합니다.

이러한 변경은 활동이 많은 기간 동안 네트워크 동기화 실패를 방지할 것입니다. 궁극적으로 이는 체인을 동기화하는 물리적 하드웨어를 압도하지 않으면서 이더리움이 블록 용량을 늘리고 향후 블록당 더 많은 트랜잭션을 처리할 수 있는 길을 열어줍니다.

자료: EIP-7975 기술 사양 (opens in a new tab)

추가 자료

• 이더리움 로드맵
• Forkcast: 글램스테르담 (opens in a new tab)
• 글램스테르담 메타 EIP (opens in a new tab)
• 2026년 프로토콜 우선순위 업데이트 블로그 공지 (opens in a new tab)
• The Daily Gwei Refuel 팟캐스트 - 양자 내성 이더리움, 글램스테르담이 온다 (opens in a new tab)

자주 묻는 질문 (FAQ)

글램스테르담 하드 포크 이후 ETH는 어떻게 변환할 수 있나요?

• ETH에 대해 아무런 조치도 필요하지 않습니다: 글램스테르담 업그레이드 이후 ETH를 변환하거나 업그레이드할 필요가 없습니다. 계정 잔액은 동일하게 유지되며, 현재 보유하고 있는 ETH는 하드 포크 이후에도 기존 형태로 계속 액세스할 수 있습니다.
• 스캠에 주의하세요! ETH를 "업그레이드"하라고 지시하는 사람은 사기를 치려는 것입니다. 이 업그레이드와 관련하여 여러분이 해야 할 일은 아무것도 없습니다. 여러분의 자산은 전혀 영향을 받지 않습니다. 정보를 계속 파악하는 것이 스캠에 대한 최선의 방어임을 기억하세요.

스캠 인식 및 예방에 대한 자세한 내용

글램스테르담 업그레이드는 모든 이더리움 노드와 검증자에게 영향을 미치나요?

네, 글램스테르담 업그레이드는 실행 클라이언트와 합의 클라이언트 모두에 대한 업데이트가 필요합니다. 이 업그레이드는 내재화된 제안자-빌더 분리 (ePBS)를 도입하므로, 노드 운영자는 네트워크에서 블록을 생성, 검증 및 증명하는 새로운 방식을 처리할 수 있도록 클라이언트가 업데이트되었는지 확인해야 합니다.

모든 주요 이더리움 클라이언트는 높은 우선순위로 표시된 하드 포크를 지원하는 버전을 출시할 것입니다. 클라이언트 GitHub 리포지토리, 해당 디스코드 채널 (opens in a new tab), EthStaker 디스코드 (opens in a new tab)에서 이러한 릴리스가 언제 제공되는지 확인하거나, 이더리움 블로그를 구독하여 프로토콜 업데이트를 받을 수 있습니다.

업그레이드 후 이더리움 네트워크와의 동기화를 유지하려면 노드 운영자는 지원되는 클라이언트 버전을 실행하고 있는지 확인해야 합니다. 클라이언트 릴리스에 대한 정보는 시간에 민감하므로 사용자는 최신 세부 정보에 대한 최신 업데이트를 참조해야 합니다.

스테이커로서 글램스테르담 업그레이드를 위해 무엇을 해야 하나요?

모든 네트워크 업그레이드와 마찬가지로 클라이언트를 글램스테르담 지원이 표시된 최신 버전으로 업데이트해야 합니다. 메일링 리스트와 EF 블로그의 프로토콜 공지 (opens in a new tab)에서 업데이트를 팔로우하여 릴리스에 대한 정보를 얻으세요.

메인넷에서 글램스테르담이 활성화되기 전에 설정을 검증하려면 테스트넷에서 검증자를 실행할 수 있습니다. 테스트넷 포크도 메일링 리스트와 블로그에 공지됩니다.

글램스테르담에는 레이어 1 (l1) 확장을 위한 어떤 개선 사항이 포함되나요?

주요 기능은 네트워크 트랜잭션을 검증하는 무거운 작업과 합의에 도달하는 작업을 분리하는 ePBS(EIP-7732)입니다. 이는 데이터 전파 창을 2초에서 약 9초로 확장하여, 이더리움이 훨씬 더 높은 트랜잭션 처리량을 안전하게 처리하고 레이어 2 (l2) 네트워크를 위해 더 많은 데이터 블롭을 수용할 수 있는 능력을 열어줍니다.

글램스테르담이 이더리움(레이어 1 (l1))의 수수료를 낮추나요?

네, 글램스테르담은 일상적인 사용자의 수수료를 낮출 가능성이 높습니다! 내재적 트랜잭션 가스 감소(또는 EIP-2780)는 ETH 전송에 대한 기본 수수료를 줄여 일상적인 결제에 ETH를 사용하는 것을 훨씬 저렴하게 만듭니다.

또한 장기적인 지속 가능성을 위해 글램스테르담은 블록 수준 액세스 목록(BAL)을 도입합니다. 이는 병렬 처리를 가능하게 하고 향후 더 높은 전체 가스 한도를 안전하게 처리할 수 있도록 레이어 1 (l1)을 준비하며, 용량이 증가함에 따라 트랜잭션당 가스 비용을 줄일 가능성이 높습니다.

글램스테르담 이후 기존 스마트 컨트랙트에 변경 사항이 있나요?

기존 컨트랙트는 글램스테르담 이후에도 정상적으로 계속 작동합니다. 개발자는 몇 가지 새로운 도구를 얻게 될 것이며 가스 사용량을 검토해야 합니다:

• 최대 컨트랙트 크기 증가(또는 EIP-7954)를 통해 개발자는 더 큰 애플리케이션을 배포할 수 있으며, 최대 컨트랙트 크기 제한을 약 24KiB에서 32KiB로 높입니다.
• 결정론적 팩토리 사전 배포(또는 EIP-7997)는 보편적인 내장 팩토리 컨트랙트를 도입합니다. 이를 통해 개발자는 참여하는 모든 EVM 체인에 걸쳐 정확히 동일한 주소에 애플리케이션과 스마트 컨트랙트 지갑을 배포할 수 있습니다.
• 앱이 ETH 전송을 찾기 위해 복잡한 추적에 의존하는 경우, ETH 전송 및 소각 시 로그 발생(또는 EIP-7708)을 통해 더 간단하고 안정적인 회계를 위해 로그를 사용하는 방식으로 전환할 수 있습니다.
• 상태 생성 가스 비용 증가(또는 EIP-8037) 및 상태 액세스 가스 비용 업데이트(또는 EIP-8038)는 새로운 계정이나 영구 스토리지를 생성할 때 생성된 데이터 크기에 따라 새로운 표준화된 고정 수수료가 부과되므로 특정 컨트랙트 배포 비용을 변경할 새로운 지속 가능성 모델을 도입합니다.

글램스테르담은 노드 스토리지 및 하드웨어 요구 사항에 어떤 영향을 미치나요?

글램스테르담에서 고려 중인 여러 EIP는 상태 성장의 성능 절벽(performance cliff) 문제를 해결합니다:

• 상태 생성 가스 비용 증가(또는 EIP-8037)는 연간 120 GiB의 상태 데이터베이스 성장률을 목표로 하는 고정 비용 프레임워크(CPSB)를 도입하여, 표준 물리적 하드웨어가 네트워크를 계속 효율적으로 실행할 수 있도록 보장합니다.
• eth/70 부분 블록 영수증 목록(또는 EIP-7975)은 노드가 페이지가 매겨진 블록 영수증을 요청할 수 있도록 허용하며, 이는 데이터가 많은 블록 영수증 목록을 더 작은 청크로 나누어 이더리움이 확장됨에 따라 충돌 및 동기화 문제를 방지합니다.

페이지 최근 업데이트: 2026년 6월 6일

w (opens in a new tab)

m (opens in a new tab)

기여자 보기