以太坊Glamsterdam升级：最大规模底层重构，主网日期仍悬而未决

Original | Odaily Planet Daily (@OdailyChina)

Author | jk

이더리움의 곧 다가올 Glamsterdam 업그레이드는, The Merge 이후 핵심 개발자들이 보기에 가장 큰 변경 폭을 가진 프로토콜 수준의 재구성입니다. 이 이름은 두 부분의 조합에서 비롯되었습니다: 실행 계층 업그레이드 부분은 이전 Devconnect 개최지인 암스테르담에서 이름을 따온 "Amsterdam"을 계승했고, 합의 계층 업그레이드 부분은 별의 이름을 따서 "Gloas"로 명명되었습니다. 이전 Fusaka 업그레이드에 이어, Glamsterdam은 네트워크가 거래를 처리하고 증가하는 데이터베이스를 관리하는 방식을 재구성하여 L1 확장을 추진하며, 이더리움이 블록을 생성하고 검증하는 방식을 근본적으로 업데이트합니다.

이번 업그레이드는 세 가지 핵심 목표를 중심으로 전개됩니다:

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

업그레이드의 두 가지 헤드라인 제안은 각각 합의 계층과 실행 계층에 있습니다:

두 가지 헤드라이너(Headliner) 제안이 있습니다. 출처: 이더리움

헤드라인 제안 1: ePBS, "외주 중개인"을 "내장 규칙"으로

먼저 합의 계층의 헤드라인 제안인 프로토콜 내 제안자-빌더 분리, 영어 약칭 ePBS (EIP-7732)입니다.

이더리움은 블록을 생성할 때마다 실제로 두 단계로 나뉩니다: 한 사람은 "어떤 블록을 선택할지"(제안자)를 담당하고, 다른 한 사람은 "블록 내 거래를 실제로 조립하는 일"(빌더)을 담당합니다. 현재 이 분업은 이더리움 프로토콜 자체에 규정된 것이 아니라, 일련의 체인 외 "중개 회사"(업계 용어로 릴레이)에 의존하여 중개됩니다. 이러한 체인 외 관계는 또한 블록 검증 중에 검증자들이 촉박한 2초 창 안에 거래 브로드캐스팅과 실행을 서두르게 하는 경로를 만들어, 네트워크가 처리할 수 있는 데이터 양을 제한합니다. 비유하자면, 레스토랑의 주문과 요리 과정이 원래 별도의 외부 조정자가 조리와 서빙을 조율해야 하는데, 이 조정자가 문제를 일으키면 주방과 홀이 서로 맞지 않을 수 있습니다.

ePBS가 하는 일은 이 "주문-요리" 분업 규칙을 레스토랑 자체 운영 규정 매뉴얼에 적어 넣어 외부 조정자에 의존하지 않게 하는 것입니다. 이를 통해 체인 상 신뢰할 수 있는 블록 전달 및 결제 메커니즘이 프로토콜 자체에 직접 구축되어 제3자 미들웨어에 의존할 필요가 없어지지만, 양측이 프로토콜에 아직 규정되지 않은 복잡한 기능을 사용하려면 계속 외부 조정자를 이용할 수 있습니다. 동시에 "요리 전달" 단계에서의 혼란을 없애기 위해, ePBS는 "누가 주문했는지"와 "요리가 제때 완성되어 나왔는지"를 각각 검사하는 "요리 검수 팀"을 별도로 설립했으며, 기존 2초의 요리 전달 시간 창은 약 9초로 확장되어 레스토랑이 한 번에 더 많은 주문을 처리할 수 있게 되었습니다. 즉, 이더리움이 더 많은 Layer2 지향 데이터를 수용할 수 있게 되었습니다.

헤드라인 제안 2: BALs, 출발 전에 "쇼핑 목록"을 먼저 작성

다음은 실행 계층의 헤드라인 제안인 블록 수준 액세스 목록, 영어 약칭 BALs (EIP-7928)입니다.

현재 이더리움이 거래를 처리하는 방식은 마치 한 사람이 눈을 가린 채 슈퍼마켓에서 물건을 사는 것과 같습니다: 먼저 물건을 만져보고 무엇인지 확인해야만 다음 단계를 결정할 수 있으므로, 하나씩 줄을 서서 처리할 수밖에 없습니다. 거래가 어떤 데이터를 사용할지(예: 어떤 계정이 관련될지) 미리 알 수 없기 때문에, 시스템은 거래를 엄격히 순서대로 처리해야 합니다. 그렇지 않으면 두 거래가 동시에 같은 데이터(예: 같은 주소의 잔액)를 수정하려고 시도하여 충돌과 오류가 발생할 수 있습니다.

BALs는 이 사람이 출발하기 전에 "어느 선반에 가서 무엇을 가져와야 하는지"가 명확히 적힌 쇼핑 목록을 미리 받는 것과 같습니다. 이 목록이 있으면 시스템은 어떤 거래들이 서로 전혀 충돌하지 않는지 미리 파악할 수 있으므로, 관련 없는 거래들을 여러 그룹으로 나누어 동시에 병렬 처리할 수 있으며, 더 이상 하나씩 줄을 서서 기다릴 필요가 없습니다. 이 목록에는 추가적인 이점도 있습니다: 새로운 노드가 네트워크에 합류할 때 이 목록에 기록된 최종 결과를 그대로 복사할 수 있어 복잡한 과거 거래를 모두 다시 계산할 필요가 없으므로, 새 노드의 동기화 진행 속도가 훨씬 빨라집니다. 이 목록이 실제로 네트워크에서 유통되도록 하기 위해, Glamsterdam은 노드 간에 이러한 액세스 목록을 실제로 공유할 수 있게 하는 전송 프로토콜 업그레이드도 포함시켰으며, 현재 이 전송 프로토콜은 모든 실행 계층 클라이언트의 필수 요구 사항이 되었습니다.

보조 제안: "공간을 차지하는" 작업에 대한 재계산

이 두 가지 헤드라인 제안 외에도, Glamsterdam은 두 가지 재가격 책정 보조 제안을 포함시켰는데, 이는 네트워크의 "보관 수수료"와 "조회 수수료"에 대한 가격표 조정으로 이해할 수 있습니다.

• 첫 번째는 계정 생성, 컨트랙트 배포처럼 네트워크에서 "영구적으로 공간을 차지하는" 작업으로, 기존 수수료는 실제 차지하는 공간과 비례하지 않았습니다. 이제는 "공간을 차지하는 만큼 비용을 지불"하는 방식으로 재계산되며, 목표는 네트워크 전체의 데이터 증가 속도를 연간 120 GiB라는 안전하고 예측 가능한 수준으로 제어하여 일반 하드웨어로도 네트워크를 지속적으로 운영할 수 있게 하는 것입니다. 동시에 이 보관 수수료는 별도의 계정으로 계산되며, 거래 처리 자체의 계산 비용과 혼합되지 않습니다. 개발자가 보관 수수료를 더 많이 지불할 의향이 있다면 더 크고 복잡한 애플리케이션을 배포할 수 있으며, 총 Gas 상한선에 의해 갑자기 막히지 않습니다.
• 두 번째는 네트워크의 기존 데이터를 조회하고 읽는 작업으로, 기존 가격은 너무 낮아 데이터 양이 증가한 후의 실제 조회 비용을 따라가지 못했습니다. 이번에는 이러한 연산 코드의 수수료 기준을 인상하여 가격이 현대 하드웨어의 실제 부하 상황에 더 가깝게 만들고, 수수료가 너무 저렴한 허점을 이용해 대량의 조회 요청으로 네트워크를 의도적으로 막는 것을 방지합니다.

메인넷 출시 시기: 아직 확정되지 않음

일정 측면에서 Glamsterdam은 현재 상당히 미묘한 단계에 있습니다. 공식적으로, 가장 최근에 확인 가능한 전체 핵심 개발자 실행 계층 회의(ACDE)는 제241차로 7월 16일에 열렸으며, 주요 의제에는 Glamsterdam Devnet 단계의 최신 진행 상황 보고와 차기 업그레이드 Hegota를 위한 헤드라인 제안 투표가 포함되었습니다. 업계에서 널리 인용된 일정에 따르면, Devnet 단계는 0부터 7까지 총 8차례의 반복이 2026년 3월 28일부터 7월 8일까지 진행되었으며, 이후 Sepolia 테스트넷 포크는 원래 2026년 8월 3일, Hoodi 테스트넷 포크는 원래 2026년 8월 17일로 예정되어 있었고, 메인넷 활성화 목표 날짜는 2026년 9월 16일이었습니다.

원래 일정은 2026년 상반기였습니다. 출처: 이더리움

하지만 최근 동향을 보면 이 일정은 연기될 가능성이 높습니다. EthPandaOps 팀은 최근 Glamsterdam을 위해 설계된 첫 번째 단기 공공 테스트넷인 Plataberget이라는 새 테스트넷을 출시했으며, 공식 Sepolia 및 Hoodi 배포는 9월로 연기될 것으로 예상되며, 메인넷 출시 목표도 2026년 4분기로 미뤄졌습니다. 이는 Glamsterdam이 당초 2026년 상반기에서 연기된 이후 두 번째로 날짜가 변경된 것입니다. 핵심 개발자들은 업그레이드의 정확성이 특정 날짜를 맞추는 것보다 우선한다고 여러 차례 강조해 왔으며, 공식 ACD 회의에서 특정 블록 높이가 확정되기 전까지는 4분기 또는 연말에야 이번 업그레이드를 볼 수 있을 것입니다.