Glamsterdam: Ethereum 개발자를 위한 완전 가이드
작성자: Alchemy

Glamsterdam이 가동됐습니다. Ethereum의 다음 네트워크 업그레이드가 Sepolia testnet에서 10월 6일 13:53:36 UTC에 활성화됐습니다. 이를 실행하는 첫 공개 testnet이자, mainnet 전 마지막 리허설 중 하나입니다. 우리는 몇 주 동안 이 업그레이드를 준비하며 Glamsterdam devnet에서 인프라를 스트레스 테스트했습니다. 중단 없이 계속 빌드할 수 있게 하기 위해서입니다. 우리가 한 일과, 그것이 의미하는 바는 다음과 같습니다.
알아둘 점:
- Glamsterdam은 Sepolia에서 활성화됐고, 프로토콜에 포함한 proposer-builder 분리(EIP-7732), 블록 단위 액세스 리스트(EIP-7928), 상태 증가에 맞춰 다시 매긴 gas 모델(EIP-8037)을 함께 가져옵니다
- Sepolia는 업그레이드의 스케일링 변경을 검증하기 위해, 현재 mainnet 한도의 3배를 넘는 2억 gas 한도를 테스트하고 있습니다
- 개발자가 가장 크게 느낄 변화는 EIP-8037입니다. 컨트랙트 배포와 storage를 많이 쓰는 다른 쓰기의 gas가 더 듭니다
- 오늘에 앞서 몇 주 동안 업계를 이끄는 bundler를 Glamsterdam devnet에서 스트레스 테스트하고, 새 규칙에서도 스폰서 트랜잭션이 계속 동작하도록 gas 추정 개선을 배포했습니다. mainnet으로 가는 길에 나타나는 엣지 케이스도 모니터링하며 처리하고 있습니다.
- Hoodi와 mainnet 활성화 날짜는 아직 정해지지 않았습니다. 클라이언트 팀이 Sepolia 결과를 보고 결정합니다
Glamsterdam이란
Glamsterdam은 Ethereum의 다음 조율된 네트워크 업그레이드입니다. 이름은 과거 Devconnect 장소를 딴 실행 레이어 업그레이드 Amsterdam과, 합의 레이어 업그레이드 Gloas를 합친 것입니다. 두 레이어를 모두 건드리므로, 모든 노드 운영자는 실행 클라이언트와 합의 클라이언트를 함께 업데이트해야 합니다.
여기서 가장 중요한 EIP는 두 개입니다.
- EIP-7732 (프로토콜에 포함한 proposer-builder 분리). proposer와 builder의 분리는 지금 프로토콜 밖의 릴레이 시스템인 MEV-Boost로 돌아갑니다. EIP-7732는 그 분리를 프로토콜 안으로 옮기고, 블록 빌드와 블록 제안 및 어테스트를 나눕니다. 효과 중 하나: 네트워크의 데이터 전파 창이 약 2초에서 약 9초로 늘어, 블록이 데이터를 실을 여지가 커집니다.
- EIP-7928 (블록 단위 액세스 리스트). 이제 모든 블록은 트랜잭션이 실행되기 전에, 어떤 계정과 storage 슬롯을 건드리는지 보여주는 맵을 함께 담습니다. 노드가 블록이 건드릴 대상을 미리 알면, 트랜잭션을 하나씩이 아니라 그 블록의 독립된 부분을 병렬로 실행할 수 있습니다.
Sepolia testnet에서 바뀐 점
Sepolia의 Glamsterdam 포크는 2억 gas 한도를 테스트하고 있습니다. 새 ePBS와 병렬 실행 규칙에서 클라이언트가 블록당 더 많은 실행 작업을 감당하는지 보기 위한 상향입니다. Prysm과 Teku를 포함한 일부 클라이언트의 밸리데이터는 더 높은 한도를 자동으로 잡지 않습니다. 노드 운영자는 포크 전에 이를 설정해야 했습니다. EIP-8037이 공개 네트워크에서 가동된 것도 이번이 처음입니다.
EIP-8037은 gas 비용을 바꿉니다
EIP-8037은 상태 생성의 gas를 다시 매깁니다. 작업 비용을 지금의 더 평평한 가격이 아니라, 새로 쓰는 영구 상태의 양에 묶습니다. 목표는 더 많은 앱이 컨트랙트를 배포하고 storage를 쓰면서 상태 데이터베이스가 제한 없이 커지는 대신, Ethereum 상태 데이터베이스가 예측 가능한 속도로 자라게 하는 것입니다. 실제로는 이렇습니다.
- 새 컨트랙트 배포는 Glamsterdam 전보다 gas가 더 듭니다
- 컨트랙트 생성뿐 아니라, 새 storage를 쓰는 작업은 모두 영향을 받습니다
- Glamsterdam 이전 가정으로 만든 gas 추정은, 새 가격이 적용되면 실제 비용을 낮게 잡을 수 있습니다
우리가 준비한 것
오늘 활성화에 앞서, 업계를 이끄는 bundler를 몇 주 동안 Glamsterdam devnet에서 돌려, EIP-8037의 새 상태 gas 가격이 프로덕션 트래픽에 닿기 전에 스폰서 트랜잭션에서 어떻게 나타나는지 확인했습니다. 그 테스트로, 새 규칙에 맞춰 gas 추정의 어디를 고쳐야 하는지 정확히 알 수 있었습니다. 그다음 한 일은 다음과 같습니다.
- 실시간 모니터링을 만들었습니다. 추정, mempool, 블록 빌드의 각 단계에서 gas 비용을 추적해, 새 가격의 영향을 사후가 아니라 바로 잡습니다. 트랜잭션이 반환하는 값이나 처리 방식은 바뀌지 않습니다. 안정성과 선제적인 가시성을 위한 것입니다.
- 우리 노드를 업그레이드했습니다. 이번 활성화에 앞서, 네트워크 전반에서 진행했습니다.
- 대기 팀이 있습니다. 지금 Sepolia를 보며 엣지 케이스를 보고 있습니다. 특히 새 규칙이 커스텀 paymaster와 배치 트랜잭션과 어떻게 상호작용하는지입니다.
결과: 사용하는 API, RPC, 가스리스 트랜잭션, 그 사이의 모든 것이 Glamsterdam 변경 속에서도 그대로 동작합니다. 직접 바꿀 것은 없습니다.
앱에 의미하는 것
API를 호출하는 방식은 달라지지 않습니다. Sepolia가 가동된 지금 확인해 둘 만한 점은 다음과 같습니다.
- 컨트랙트 배포. 사용자마다 컨트랙트를 배포하는 앱이라면, Sepolia의 새 가격으로 gas 예산을 다시 확인하세요.
- 스폰서 트랜잭션과 paymaster. gas를 스폰서하거나 고정 예산의 paymaster를 운영한다면, mainnet 활성화 이후가 아니라 그 전에 Sepolia에서 테스트하세요.
- gas 추정 캐시. gas 추정을 캐시하거나 스택 어딘가에 gas 한도를 하드코딩해 두었다면, 그 숫자는 이제 오래됐을 수 있습니다.
계속 빌드하세요. 지원 센터를 방문하거나, 문서를 읽거나, 규모에 맞는 솔루션과 가격은 팀에 문의하세요.
자주 묻는 질문
Glamsterdam이란 무엇인가요?
Glamsterdam은 Ethereum의 다음 네트워크 업그레이드입니다. 실행 레이어 업그레이드(Amsterdam)와 합의 레이어 업그레이드(Gloas)를 합칩니다. 10월 6일 Sepolia testnet에서 활성화됐습니다.
Glamsterdam이 mainnet에서 활성화됐나요?
아니요. 오늘의 활성화는 Sepolia뿐입니다. Hoodi와 mainnet 활성화 날짜는 아직 정해지지 않았습니다. 클라이언트 팀이 Sepolia 결과를 보고 정합니다.
EIP-8037은 개발자에게 무엇을 바꾸나요?
상태 생성의 gas를 다시 매깁니다. 그래서 컨트랙트 배포와 새 storage를 쓰는 다른 작업은 이전보다 gas가 더 듭니다.
Alchemy API를 호출하는 방식에 영향이 있나요?
없습니다. 전환에 따른 노드와 bundler 인프라는 우리가 처리합니다. 앱이 컨트랙트를 배포하거나, gas를 스폰서하거나, paymaster를 운영한다면, 가동 중인 Sepolia 네트워크에서 gas 가정을 다시 테스트하세요.
Alchemy 뉴스레터
출시 소식을 가장 먼저 받아보세요
뉴스레터 구독하기
Alchemy의 최신 제품 업데이트와 리소스 받기
이메일 주소를 입력하면 마케팅 커뮤니케이션 및 제품 업데이트 수신에 동의하게 됩니다. Alchemy는 저희 개인정보 처리방침에 따라 수집한 정보를 처리합니다. 언제든지 구독을 취소할 수 있습니다.
관련 아티클

도쿄에서 구축한다면 어떤 RPC 제공업체를 선택해야 할까
도쿄를 서비스하는 RPC 제공업체 다섯 곳을 다섯 개 체인에서 벤치마크했습니다. 비교 결과와, 지연 시간에 민감한 팀에게 차이가 어디서 나는지 정리합니다.

업계 최고 수준의 속도와 안정성을 위한 Solana RPC 읽기 아키텍처
Alchemy는 가장 낮은 Solana 읽기 지연 시간을 제공합니다: 9.21ms로, 차순위 제공업체보다 약 26% 빠릅니다.

Alchemy, 도쿄 리전 지원 출시
Node RPC, WebSockets, Dedicated Clusters가 도쿄에서 지원되며, 일본에서의 요청 중간 지연 시간이 최대 8배 감소합니다.