메인 콘텐츠로 건너뛰기

Glamsterdam

이더리움의 다가오는 Glamsterdam 업그레이드는 차세대 확장을 위한 길을 열도록 설계되었습니다. Glamsterdam은 "Amsterdam"(이전 Devconnect 개최지 이름을 딴 실행 레이어 업그레이드)과 "Gloas"(별의 이름을 딴 합의 레이어 업그레이드)의 조합에서 이름을 따왔습니다.

Fusaka 업그레이드의 진행 상황에 따라 Glamsterdam은 네트워크가 트랜잭션을 처리하고 증가하는 데이터베이스를 관리하는 방법을 재구성하여 L1을 확장하는 데 중점을 두며, 이더리움이 블록을 생성하고 검증하는 방법을 근본적으로 업데이트합니다.

Fusaka가 기본적인 개선에 중점을 둔 반면, Glamsterdam은 다양한 네트워크 참여자 간의 업무 분리를 명시하고 처리량이 많은 병렬화를 위해 를 준비하기 위한 보다 효율적인 데이터 처리 방법을 도입하여 "L1 확장" 및 "블롭 확장" 목표를 발전시킵니다.

이러한 개선을 통해 이더리움은 더 많은 활동을 처리하면서도 빠르고 저렴하며 탈중앙화된 상태를 유지하는 동시에 집에서 를 실행하는 사람들을 위해 관리 가능한 하드웨어 요구 사항을 유지할 수 있습니다.

Glamsterdam에서 고려되는 개선 사항

Glamsterdam 업그레이드는 세 가지 주요 목표를 중심으로 이루어집니다.

  • 처리 속도 향상(병렬화): 네트워크가 데이터 종속성을 기록하는 방식을 재구성하여 느린 순차적 방식 대신 여러 트랜잭션을 동시에 안전하게 처리할 수 있도록 합니다.
  • 용량 확장: 블록 생성 및 검증의 부담이 큰 작업을 분할하여 네트워크 속도를 늦추지 않고 더 많은 양의 데이터를 전파할 수 있는 시간을 늘립니다.
  • 데이터베이스 팽창 방지(지속 가능성): 네트워크 수수료를 조정하여 새 데이터를 저장하는 데 드는 장기적인 하드웨어 비용을 정확하게 반영하고, 하드웨어 성능 저하를 방지하면서 향후 가스 한도를 늘릴 수 있도록 합니다.

요약하면, Glamsterdam은 네트워크 용량이 증가함에 따라 지속 가능성을 유지하고 높은 성능을 유지하기 위한 구조적 변경을 도입할 것입니다.

L1 확장 및 병렬 처리

의미 있는 L1 확장을 위해서는 오프 프로토콜 신뢰 가정과 직렬 실행 제약에서 벗어나야 합니다. Glamsterdam은 특정 블록 구축 의무의 분리를 명시하고 네트워크가 병렬 처리를 준비할 수 있도록 하는 새로운 데이터 구조를 도입하여 이 문제를 해결합니다.

헤드라이너 제안: 명문화된 제안자-빌더 분리(ePBS)

  • 오프 프로토콜 신뢰 가정 및 타사 릴레이에 대한 의존성 제거
  • 확장된 전파 창을 통해 훨씬 더 큰 페이로드를 허용하여 L1 확장 지원
  • 신뢰가 필요 없는 빌더 결제를 프로토콜에 직접 도입

현재 블록 제안 및 구축 과정에는 블록 제안자와 블록 빌더 간의 핸드오프가 포함됩니다. 제안자와 빌더 간의 관계는 핵심 이더리움 프로토콜의 일부가 아니므로 신뢰할 수 있는 타사 미들웨어, 소프트웨어(릴레이) 및 엔티티 간의 오프 프로토콜 신뢰에 의존합니다.

제안자와 빌더 간의 프로토콜 외부 관계는 또한 블록 검증 중에 "핫 패스"를 생성하여 가 2초의 짧은 시간 내에 트랜잭션 브로드캐스팅 및 실행을 서두르게 하여 네트워크가 처리할 수 있는 데이터 양을 제한합니다.

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

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

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

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

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

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

헤드라이너 제안: 블록 수준 접근 목록(BAL)

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

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

블록 수준 접근 목록(BAL 또는 EIP-7928)은 모든 블록에 포함된 지도와 같아서 작업이 시작되기 전에 데이터베이스의 어떤 부분에 접근할지 네트워크에 알려줍니다. BAL은 모든 블록에 트랜잭션이 영향을 미칠 모든 계정 변경의 해시와 해당 변경의 최종 결과(모든 상태 접근 및 실행 후 값의 해시 기록)를 포함하도록 요구합니다.

BAL은 어떤 트랜잭션이 겹치지 않는지에 대한 즉각적인 가시성을 제공하기 때문에 노드는 병렬 디스크 읽기를 수행하여 여러 트랜잭션에 대한 정보를 동시에 가져올 수 있습니다. 네트워크는 관련 없는 트랜잭션을 안전하게 그룹화하고 병렬로 처리할 수 있습니다.

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

BAL이 지원하는 병렬 디스크 읽기는 이더리움이 많은 트랜잭션을 한 번에 처리하여 네트워크 속도를 크게 높이는 미래를 향한 중요한 단계가 될 것입니다.

eth/71 블록 접근 목록 교환

블록 접근 목록 교환(eth/71 또는 EIP-8159)은 블록 수준 접근 목록의 직접적인 네트워킹 동반자입니다. BAL이 병렬 실행을 가능하게 하는 동안 eth/71은 P2P 프로토콜을 업그레이드하여 노드가 네트워크를 통해 이러한 목록을 실제로 공유할 수 있도록 합니다. 블록 접근 목록 교환을 구현하면 더 빠른 동기화가 가능해지고 노드가 실행 없는 상태 업데이트를 수행할 수 있게 됩니다.

참고 자료:

네트워크 지속 가능성

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

상태 생성 가스비 증가

  • 새 계정이나 스마트 컨트랙트를 생성하는 수수료가 이더리움 데이터베이스에 가하는 장기적인 부담을 정확하게 반영하도록 보장합니다.
  • 네트워크의 전체 용량을 기반으로 이러한 데이터 생성 수수료를 자동으로 조정하여 표준 물리적 하드웨어가 네트워크를 계속 실행할 수 있도록 안전하고 예측 가능한 성장률을 목표로 합니다.
  • 이러한 특정 수수료에 대한 회계를 새 리저버로 분리하여 이전 트랜잭션 한도를 제거하고 개발자가 더 크고 복잡한 애플리케이션을 배포할 수 있도록 합니다.

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

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

조정하지 않으면 네트워크가 1억 가스 한도로 확장될 경우 이더리움의 상태가 연간 거의 200GiB씩 증가하여 결국 일반 하드웨어를 능가할 수 있습니다.

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

EIP-8037은 또한 이러한 비용을 보다 예측 가능하게 관리하기 위해 리저버 모델을 도입합니다. 상태 가스비는 먼저 state_gas_reservoir에서 인출되고 GAS 연산 부호는 gas_left만 반환하여 실행 프레임이 사용 가능한 가스비를 잘못 계산하는 것을 방지합니다.

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

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

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

상태 접근 가스비 업데이트

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

이더리움의 상태가 커짐에 따라 오래된 데이터를 검색하고 읽는 행위("상태 접근")는 노드가 처리하기에 더 무겁고 느려졌습니다. 이러한 작업에 대한 수수료는 (컴퓨팅 성능 측면에서) 정보를 조회하는 데 약간 더 비싸졌음에도 불구하고 동일하게 유지되었습니다.

결과적으로 일부 특정 명령은 현재 노드가 수행해야 하는 작업에 비해 저평가되어 있습니다. EXTCODESIZE 및 EXTCODECOPY는 예를 들어 계정 객체에 대한 데이터베이스 읽기와 실제 코드 크기 또는 바이트코드에 대한 두 번째 데이터베이스 읽기가 필요하기 때문에 저평가되어 있습니다.

상태 접근 가스비 업데이트(또는 EIP-8038)는 계정 및 컨트랙트 데이터 조회와 같은 상태 접근 연산 부호의 가스 상수를 최신 하드웨어 성능 및 상태 크기에 맞게 증가시킵니다.

상태 접근 비용을 조정하는 것은 이더리움을 더욱 탄력적으로 만드는 데도 도움이 됩니다. 이러한 과도한 데이터 읽기 작업이 인위적으로 저렴하기 때문에 악의적인 공격자는 네트워크의 수수료 한도에 도달하기 전에 단일 블록에서 수천 개의 복잡한 데이터 요청으로 네트워크를 스팸으로 공격하여 잠재적으로 네트워크가 중단되거나 충돌(서비스 거부 공격)할 수 있습니다. 악의적인 의도가 없더라도 네트워크 데이터 읽기 비용이 너무 저렴하면 개발자는 효율적인 애플리케이션을 구축할 경제적 동기가 부여되지 않습니다.

상태 접근 작업의 가격을 보다 정확하게 책정함으로써 이더리움은 우발적이거나 의도적인 속도 저하에 대해 더욱 탄력적으로 대처할 수 있으며, 네트워크 비용을 하드웨어 부하와 일치시킴으로써 향후 가스 한도 증가를 위한 보다 지속 가능한 기반을 마련할 수 있습니다.

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

네트워크 탄력성

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

지분 삭감된 검증자를 제안에서 제외

  • 페널티를 받은(지분 삭감된) 검증자가 향후 블록을 제안하도록 선택되는 것을 중단하여 보장된 누락 슬롯을 제거합니다.
  • 대규모 지분 삭감 이벤트가 발생할 경우 심각한 중단을 방지하여 이더리움을 원활하고 안정적으로 실행합니다.

현재, 검증자가 지분 삭감(규칙 위반 또는 예상대로 작동하지 않은 것에 대한 처벌)을 받더라도 시스템은 향후 제안자를 미리 생성할 때 가까운 미래에 블록을 이끌도록 선택할 수 있습니다.

지분 삭감된 제안자의 블록은 자동으로 무효로 거부되기 때문에 이는 네트워크가 슬롯을 놓치게 하고 대규모 지분 삭감 이벤트 동안 네트워크 복구를 지연시킵니다.

지분 삭감된 검증자를 제안에서 제외(또는 EIP-8045)는 지분 삭감된 검증자가 향후 의무를 위해 선택되지 않도록 간단히 필터링합니다. 이는 건강한 검증자만 블록을 제안하도록 선택되도록 보장하여 네트워크 중단 시 서비스 품질을 유지함으로써 체인 복원력을 향상시킵니다.

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

출금이 통합 대기열을 사용하도록 허용

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

Pectra 업그레이드가 이더리움 검증자의 최대 유효 잔액을 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)

사용자 및 개발자 경험 개선

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

내재적 트랜잭션 가스비 절감

  • 트랜잭션의 기본 수수료를 낮추어 간단한 기본 ETH 지불의 전체 비용을 절감합니다.
  • 소액 송금을 더 저렴하게 만들어 이더리움이 일상적인 교환 매체로서의 실행 가능성을 높입니다.

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

내재적 트랜잭션 가스비 절감은 트랜잭션 수수료를 분해하여 네트워크를 실행하는 컴퓨터가 실제로 수행하는 기본적이고 필수적인 작업(예: 디지털 서명 확인 및 잔액 업데이트)만 반영하도록 작동합니다. 기본적인 ETH 지불은 복잡한 코드를 실행하거나 추가 데이터를 전달하지 않기 때문에 이 제안은 경량의 발자취에 맞춰 수수료를 줄일 것입니다.

이 제안은 새로운 계정을 생성하는 데 대한 예외를 도입하여 낮은 수수료가 네트워크의 상태를 압도하지 않도록 합니다. 이체가 비어 있고 존재하지 않는 주소로 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은 네트워크의 통신 프로토콜에 대한 페이지네이션 시스템을 도입하여 노드가 블록 영수증 목록을 분해하고 더 작고 관리하기 쉬운 청크로 데이터를 안전하게 요청할 수 있도록 합니다.

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

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

더 읽어보기

자주 묻는 질문

Glamsterdam 하드 포크 이후 ETH는 어떻게 변환할 수 있나요?

  • 귀하의 ETH에 대해 조치가 필요하지 않음: Glamsterdam 업그레이드 이후 ETH를 변환하거나 업그레이드할 필요가 없습니다. 계정 잔액은 그대로 유지되며, 현재 보유한 ETH는 하드 포크 이후에도 기존 형태로 계속 접근 가능합니다.
  • 사기를 조심하세요! ETH를 "업그레이드"하라고 지시하는 사람은 사기를 시도하는 것입니다. 이 업그레이드와 관련하여 귀하가 해야 할 일은 아무것도 없습니다. 여러분의 자산은 전혀 영향을 받지 않을 것입니다. 정보를 잘 아는 것이 사기를 막는 가장 좋은 방어책임을 기억하세요.

사기 인식과 예방에 대해 더 알아보기

Glamsterdam 업그레이드는 모든 이더리움 노드와 검증자에게 영향을 미치나요?

예, Glamsterdam 업그레이드는 실행 클라이언트와 합의 클라이언트 모두에 대한 업데이트가 필요합니다. 이 업그레이드는 명문화된 제안자-빌더 분리(ePBS)를 도입하므로 노드 운영자는 자신의 클라이언트가 네트워크에서 블록이 구축, 검증 및 증명되는 새로운 방식을 처리하도록 업데이트되었는지 확인해야 합니다.

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

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

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

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

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

Glamsterdam은 L1 확장을 위해 어떤 개선 사항을 포함할까요?

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

Glamsterdam이 이더리움(레이어 1)의 수수료를 낮출까요?

네, Glamsterdam은 일반 사용자의 수수료를 낮출 가능성이 높습니다! 내재적 트랜잭션 가스비 절감(또는 EIP-2780)은 ETH 전송의 기본 수수료를 줄여 일상적인 지불에 ETH를 훨씬 저렴하게 사용할 수 있도록 합니다.

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

Glamsterdam 이후 기존 스마트 컨트랙트에 변경 사항이 있나요?

기존 계약은 Glamsterdam 이후에도 정상적으로 계속 작동합니다. 개발자는 몇 가지 새로운 도구를 얻게 될 것이며 가스 사용량을 검토해야 합니다.

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

Glamsterdam은 노드 저장 공간 및 하드웨어 요구 사항에 어떤 영향을 미치나요?

Glamsterdam에 대해 고려 중인 여러 EIP는 상태 성장의 성능 절벽 문제를 해결합니다.

  • 상태 생성 가스비 증가(또는 EIP-8037)는 연간 100GiB의 상태 데이터베이스 성장률을 목표로 하는 동적 가격 모델을 도입하여 표준 물리적 하드웨어가 네트워크를 효율적으로 계속 실행할 수 있도록 보장합니다.
  • eth/70 부분 블록 영수증 목록(또는 EIP-7975)은 노드가 페이지가 매겨진 블록 영수증을 요청할 수 있도록 하여 데이터가 많은 블록 영수증 목록을 더 작은 청크로 분할하여 이더리움이 확장될 때 충돌과 동기화를 방지합니다.

이 문서가 도움이 되셨나요?