Glamsterdam 업그레이드, 이더리움의 L1 확장 솔루션

원본 | Odaily 별일보 jk

이더리움이 곧迎할 Glamsterdam 업그레이드는 The Merge 이후 핵심 개발자들이 생각하는 가장 큰 변화가 있는 프로토콜 수준의 재구성입니다. 이 이름은 두 부분의 조합에서 유래되었습니다: 실행 레이어 업그레이드 부분은 "Amsterdam"을 사용하며, 이는 이전 Devconnect 개최지인 암스테르담에서 따온 것입니다; 합의 레이어 업그레이드 부분은 "Gloas"라는 이름을 붙였습니다, 이는 별의 이름에서 따온 것입니다. 이전의 Fusaka 업그레이드 이후, Glamsterdam은 네트워크 거래 처리 및 지속적으로 증가하는 데이터베이스 관리 방식을 재구성하여 L1 확장을 추진하며, 이더리움의 블록 생성 및 검증 방식을 근본적으로 업데이트했습니다.

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

• 처리 속도 향상(병렬화): 네트워크가 데이터 의존 관계를 기록하는 방식을 재구성하여, 느리게 순차적으로 처리하는 대신 안전하게 동시에 많은 거래를 처리할 수 있도록 합니다.
• 확장성: 블록 생성 및 검증의 중복 작업을 분리하여, 네트워크가 더 많은 데이터를 전파할 수 있도록 더 많은 시간을 제공합니다.
• 지속 가능성: 새로운 데이터 저장의 장기 하드웨어 비용을 정확히 반영하기 위해 네트워크 요금을 조정하여, 미래의 가스 한도 증가를 위한 장애물을 제거하고 하드웨어 성능 저하를 방지합니다.

업그레이드의 두 가지 주요 제안은 각각 합의 레이어와 실행 레이어에 있습니다:

두 가지 주요 제안이 있습니다. 출처: 이더리움

주요 제안 1: ePBS, "외부 중개인"을 "내장 규칙"으로 변환

먼저 합의 레이어의 주요 제안에 대해 이야기하겠습니다. 프로토콜 내 제안자와 구축자를 분리하는 것으로, 영어 약어는 ePBS(EIP-7732)입니다.

이더리움이 매번 블록을 생성할 때, 사실 두 단계로 나뉩니다: 한 사람이 "어떤 블록을 선택할 것인지"(제안자)를 담당하고, 다른 한 사람은 "블록 내 거래를 실제로 조립하는 것"(구축자)을 담당합니다. 현재 이 분업은 이더리움 프로토콜 자체에서 규정된 것이 아니라, 일련의 오프체인 "중개 회사"(업계 용어로 중계)가 이를 촉진하여 완료합니다. 이러한 오프체인 관계는 블록 검증 기간 동안 경로를 생성하여, 검증자가 긴 2초의 시간 내에 거래 방송 및 실행을 서두르도록 강요하여, 네트워크가 처리할 수 있는 데이터 양을 제한합니다. 비유하자면, 이는 한 식당의 주문과 요리 과정이 원래 독립적인 외부 조정자에게 의존해야 하는 것과 같습니다. 이 조정자가 문제가 생기면, 주방과 프론트가 맞지 않을 수 있습니다.

ePBS가 하는 일은 이 "주문-요리"의 분업 규칙을 식당 자체의 운영 규정 매뉴얼에 작성하여 더 이상 외부 조정자에 의존하지 않도록 하는 것입니다. 이렇게 되면, 체인 상에서 신뢰할 수 있는 블록 전달 및 결제 메커니즘이 프로토콜 자체에 직접 구축되어 더 이상 제3자 미들웨어에 의존할 필요가 없게 됩니다. 그러나 양측이 프로토콜에 아직 규정되지 않은 복잡한 기능을 사용하고 싶다면, 여전히 외부 조정자를 사용할 수 있습니다. 동시에 "요리 전달" 과정에서 혼란을 피하기 위해, ePBS는 "요리 검수 팀"을 특별히 설립하여 "누가 주문했는지"와 "요리가 제시간에 준비되었는지"를 각각 확인합니다. 원래 2초의 전달 시간 창이 약 9초로 확대되어, 식당이 한 번에 더 많은 주문을 처리할 수 있게 되며, 이는 이더리움이 Layer2를 위한 더 많은 데이터를 수용할 수 있게 합니다.

주요 제안 2: BALs, 출발 전에 "쇼핑 리스트"를 미리 작성하기

다음으로 실행 레이어의 주요 제안인 블록 수준 접근 목록, 영어 약어는 BALs(EIP-7928)입니다.

현재 이더리움이 거래를 처리하는 방식은 마치 한 사람이 눈을 가리고 슈퍼마켓에서 물건을 사는 것과 같습니다: 먼저 한 가지 상품을 만져서 확인해야 다음 단계로 나아갈 수 있으므로, 하나씩 줄을 서서 처리해야 합니다. 거래가 어떤 데이터를 사용할지 미리 알지 못하기 때문에, 예를 들어 어떤 계좌가 관련될지, 시스템은 거래를 순차적으로 처리해야 하며, 그렇지 않으면 두 거래가 우연히 동시에 동일한 데이터를 수정하려고 할 수 있어(예: 동일한 주소의 잔액) 충돌이 발생할 수 있습니다.

BALs는 마치 이 사람이 출발 전에 "어디의 어떤 선반에 가서 어떤 물건을 가져올 것인지"가 적힌 쇼핑 리스트를 미리 받는 것과 같습니다. 이 리스트가 있으면, 시스템은 미리 어떤 거래가 서로 "충돌"하지 않을지를 확인할 수 있어, 서로 관련 없는 거래를 몇 그룹으로 나누어 동시에 병렬 처리할 수 있습니다. 이 리스트에는 추가적인 이점도 있습니다: 새로운 노드가 네트워크에 가입할 때, 이 리스트에 기록된 최종 결과를 그대로 복사할 수 있어 복잡한 역사 거래를 다시 계산할 필요가 없습니다. 이렇게 하면 새로운 노드의 동기화 속도가 훨씬 빨라집니다. 이 리스트가 실제로 네트워크에서 유통될 수 있도록, Glamsterdam은 노드 간에 이러한 접근 목록을 실제로 공유할 수 있는 지원 전송 프로토콜 업그레이드를 패키징했습니다. 이 전송 프로토콜은 현재 모든 실행 레이어 클라이언트의 강제 요구 사항이 되었습니다.

지원 제안: "공간을 차지하는" 작업에 대한 재정산

이 두 가지 주요 제안 외에도, Glamsterdam은 네트워크의 "저장 비용"과 "조회 비용"을 각각 조정하는 두 가지 재정가 제안을 패키징했습니다.

• 첫 번째는 새 계정을 생성하거나 계약을 배포하는 등의 작업으로, 이는 네트워크에서 "영구적으로 공간을 차지하는" 작업입니다. 이전의 요금은 실제로 차지하는 공간과 비례하지 않았습니다. 이제는 "공간을 차지할 때마다 해당 요금을 부과"하는 방식으로 재정산하며, 목표는 전체 네트워크의 데이터 증가 속도를 매년 120 GiB라는 안전하고 예측 가능한 수준으로 제어하는 것입니다. 이를 통해 일반 하드웨어로도 지속적으로 이 네트워크를 운영할 수 있도록 합니다. 또한 이 저장 비용은 별도의 계좌에서 계산되며, 거래 처리 자체의 계산 비용과 혼합되지 않습니다. 개발자가 조금 더 많은 저장 비용을 지불할 의향이 있다면, 여전히 더 크고 복잡한 애플리케이션을 배포할 수 있으며, 총 가스 한도에 의해 갑자기 제한되지 않습니다.
• 두 번째는 네트워크에 이미 있는 데이터를 조회하거나 읽는 작업으로, 이전의 가격이 낮아 현재 데이터 양이 증가한 후 실제 조회 비용을 따라가지 못했습니다. 이번에는 이러한 작업 코드의 요금 기준을 높여, 가격이 현대 하드웨어의 실제 부하 상황에 더 가깝게 조정됩니다. 동시에 누군가가 너무 저렴한 요금을 이용해 대량의 조회 요청으로 네트워크를 막는 것을 방지할 수 있습니다.

메인넷 출시 시간: 현재로서는 정해지지 않음

일정 측면에서, 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분기 또는 연말까지 이번 업그레이드를 볼 수 없을 것입니다.