0% read
마지막 업데이트:
Ethereum Glamsterdam Upgrade
Glamsterdam은 Fusaka 이후 계획된 Ethereum의 차기 주요 업그레이드로, Layer 1 및 블롭(blob) 처리량 확장을 목표로 합니다.[10] Sepolia는 2026년 10월 6일에 업그레이드를 활성화했습니다. Hoodi의 10월 26일 활성화 계획은 10월 22일에 연기되었으며, 11월 3일까지 대체 Hoodi 일정은 발표되지 않았습니다. Ethereum 로드맵은 여전히 2026년 4분기를 예상 mainnet 시기로 제시하고 있으나, 확정된 메인넷 날짜는 없습니다. Sepolia의 활성화가 Glamsterdam의 메인넷 활성화를 의미하는 것은 아니며, Hoodi의 연기 또한 메인넷 날짜를 확정 짓지 않았습니다.[16][20][21]
개요
Glamsterdam은 네트워크 확장성 및 높은 transaction fees와 같은 지속적인 과제를 해결하는 것을 목표로 하는 Ethereum의 지속적인 진화에서 중요한 단계를 나타냅니다. Fusaka 업그레이드의 후속으로 계획된 이 업그레이드는 2026년 4분기에 mainnet에 적용될 것으로 예상되나 정확한 날짜는 아직 확정되지 않았습니다. 이 목표는 고정되거나 예정된 mainnet 날짜가 아니며, 2026년 11월 3일 현재 특정 mainnet 에포크(epoch)나 타임스탬프는 설정되지 않았습니다.[21] Ethereum Foundation은 연구 및 개발 부서를 Tim Beiko와 Ansgar Dietrichs와 같은 베테랑들이 이끄는 더 가볍고 집중적인 엔티티인 "Protocol"로 재편했습니다. 이러한 재편은 Layer 1 (L1) 확장, 블록 공간(blobspace) 확대, 그리고 사용자 경험(UX) 개선을 우선시하며, 이는 Glamsterdam의 예상 우선순위와 직접적으로 일치하는 과업들입니다.[2]
Glamsterdam의 개발 방식은 blockchain 개발의 반복적인 특성을 반영하여 안정성과 철저한 테스트를 강조합니다. 2026년 9월까지 이 업그레이드는 여러 전용 프라이빗 개발 네트워크(devnets)를 통과했으며, Meta‑EIP‑7773에 따라 Sepolia testnet fork는 에포크 353,024, 슬롯 11,296,768(2026년 10월 6일 13:53:36 UTC)에 고정 활성화가 할당되었습니다. 반면 Hoodi testnet 및 mainnet의 활성화 매개변수는 예정되지 않은 상태로 남았습니다.[16][21] Sepolia 업그레이드는 해당 일정에 맞춰 성공적으로 활성화 및 완료되어 Glamsterdam 범위의 주요 공개 리허설 역할을 했으나, 그 자체가 Hoodi 또는 mainnet 활성화 날짜를 정의하지는 않았습니다.[18][19] 2026년 10월 22일, 핵심 개발자들은 10월 26일로 계획되었던 Hoodi 활성화를 연기했으며, 11월 3일까지 대체 날짜는 발표되지 않았습니다. 로드맵은 메인넷 날짜를 확정하지 않은 채 2026년 4분기를 예상 mainnet 분기로 계속 나열했습니다. Sepolia 활성화와 Hoodi 연기는 메인넷 활성화 날짜를 설정하지 않았습니다.[20][21] Sepolia fork에 앞서 node 운영자들은 실행 및 합의 클라이언트를 모두 Sepolia 호환 릴리스로 업데이트해야 했습니다.[16] 이러한 단계적 테스트에 대한 헌신은 새로운 기능들이 견고하고 네트워크의 광범위한 로드맵에 잘 통합되도록 보장하기 위한 것입니다. Glamsterdam의 성공적인 구현은 전체 Ethereum 생태계에 상당한 영향을 미칠 것으로 예상되며, 향상된 네트워크 효율성을 통해 투자자에게, 새로운 기능과 도구를 통해 개발자에게, 그리고 더 stable하고 안전하며 비용 효율적인 경험을 통해 사용자에게 혜택을 줄 것입니다.[2][3]
Naming Convention
Ethereum 네트워크 업그레이드는 전통적으로 다양한 출처에서 이름을 따오며, 종종 합의 계층(CL) 업그레이드를 위한 별 이름과 실행 계층(EL) 업그레이드를 위한 도시 이름을 결합합니다. 역사적으로 Devcon 개최 도시들이 업그레이드 명명에 사용되었습니다. 그러나 Devcon이 격년제 행사가 됨에 따라, 연간 업그레이드를 위해 암스테르담과 같은 Devconnect 개최 도시 이름을 사용하는 방식이 채택되었습니다. Glamsterdam의 경우, G형 항성인 "Gloas"와 최근 Devconnect 행사를 주최한 도시인 "Amsterdam"을 결합한 이름입니다. 이러한 명명 규칙은 메타 Ethereum 개선 제안(EIP-7773: Hardfork Meta - Amsterdam)의 일부입니다.[1]
Development Roadmap
Glamsterdam 업그레이드는 Fusaka 업그레이드의 후속 단계로 위치해 있습니다. 2025년 초의 계획에서는 Fusaka의 mainnet 배포를 2025년 11월 초로 잠정 결정했었으나, 이는 과거의 예측일 뿐 Glamsterdam에 대한 현재의 예측은 아닙니다.[4][5] Ethereum 핵심 개발자들은 기능 선택부터 mainnet 활성화에 이르는 여러 중요한 단계를 포함하는 Glamsterdam의 상세 로드맵을 개설했습니다. 이러한 구조화된 접근 방식은 네트워크의 원활하고 안전한 전환을 보장하는 것을 목표로 합니다.
Headliner Selection Phase
초기 단계에서는 Glamsterdam의 주요 초점을 정의하기 위한 "헤드라이너(headliner)" 기능 선택이 진행되었습니다. All Core Developers Consensus Call #162에서 Ethereum 핵심 개발자들은 공식적으로 EIP-7732(내재된 제안자-빌더 분리, ePBS로도 알려짐)를 업그레이드의 합의 계층 헤드라이너로 선택했습니다. 이 결정으로 업그레이드의 테마 방향이 확정되었으며, 다른 후보들보다 프로토콜 수준의 탈중앙화와 검열 저항성을 우선시하게 되었습니다.[4][7]
Proposal Deadline and Specification Freeze
범위 확장(scope creep)을 방지하고 적시 진행을 보장하기 위해, 헤드라이너 선택을 확정하고 일반 EIPs를 제출하는 엄격한 마감 기한이 설정되었습니다. 2025년 8월 21일로 설정된 이 컷오프를 통해 개발자들은 네트워크가 엄격한 테스트 단계에 진입하기 전에 포함된 모든 EIP를 병합, 감사 및 문서화할 수 있었습니다. 이러한 훈련된 접근 방식은 주요 blockchain 업그레이드의 복잡성을 관리하는 데 필수적입니다. 그러나 일부 개발자들은 2026년에나 예정된 Glamsterdam 계획에 집중하는 것이 곧 다가올 Fusaka 업그레이드로부터 주의와 자원을 분산시켜, 잠재적으로 2025년 4분기 일정을 위험에 빠뜨릴 수 있다는 우려를 제기했습니다.[4][8]
Testing and Audit Windows
Glamsterdam의 출시 프로세스는 동결된 사양을 추적하는 전용 클라이언트 릴리스 브랜치 생성으로 시작되며, 이후 일련의 비공개 및 공개 testnets이 이어집니다. 2026년 9월까지 Ethereum 클라이언트 팀은 여러 비공개 개발 네트워크(devnets)를 거쳤으며, 이는 내재된 제안자-빌더 분리(ePBS), 블록 수준 병렬 실행 및 부하 조건에서의 상태 비용 재산정(state-cost repricing)을 연습하기 위해 설계된 Devnet-11에서의 최종 리허설로 정점에 달했습니다.[11][12]
2026년 9월 17일, Ethereum Foundation은 Meta‑EIP‑7773에 명시된 대로 2026년 10월 6일 13:53:36 UTC에 해당하는 에포크 353,024, 슬롯 11,296,768에서 Sepolia testnet에 Glamsterdam 업그레이드가 활성화될 예정이라고 발표했습니다.[16] Sepolia fork는 계획대로 발생하여 성공적으로 완료되었으며, Glamsterdam의 새로운 메커니즘에 대한 용량 스트레스 테스트로서 Sepolia의 목표 gas 한도를 block당 약 6,000만 가스에서 약 2억 gas로 상향 조정했습니다.[17][18][19] 이러한 공개 testnets은 실제 네트워크 조건 하에서 상호운용성 문제를 식별하고 광범위한 커뮤니티 참여를 유도하는 데 필수적이며, dApp 개발자, node 운영자 및 연구원들이 새로운 변경 사항에 대해 자신의 애플리케이션과 인프라를 테스트할 수 있도록 합니다. Ethereum.org 및 로드맵 업데이트에 따르면 Glamsterdam은 2026년 4분기에 mainnet에 적용될 것으로 예상되지만, 2026년 11월 3일 현재 구체적인 mainnet 날짜나 에포크는 확정되지 않았습니다. 목표 일정은 testnet 결과에 따라 변경될 수 있습니다. Sepolia의 성공적인 활성화는 testnet의 이정표였으며 mainnet 활성화는 아니었습니다. 마찬가지로 Hoodi 테스트의 연기도 메인넷 날짜를 확정 짓지 않았습니다.[21][20]
Hoodi 테스트넷 연기
ACDE #248에서 핵심 개발자들은 EIP-8037의 상태 생성 gas 회계가 mainnet에 배포된 smart contracts와 어떻게 상호작용하는지 추가로 검토하기 위해 2026년 10월 26일로 예정되었던 Hoodi Glamsterdam 활성화를 연기했습니다.[20] 이전에 계획된 17:42:48 UTC, 에포크 132,352의 활성화 일정은 취소되었으며, 가스 한도를 2억으로 상향 조정하려던 Hoodi 가스 한도 일정 또한 취소되었습니다.[20] 2026년 11월 3일 기준으로 대체 에포크나 타임스탬프는 발표되지 않았습니다.[20]
이 변경 사항은 미래 업그레이드 구성을 제거하는 것이며 Hoodi 체인 기록을 되돌리는 것은 아닙니다. Glamsterdam은 Hoodi에서 활성화되지 않았습니다. Hoodi 운영자들은 폐기된 활성화 일정을 사용하는 대신 수정된 실행 및 합의 클라이언트 지침을 따르도록 안내받았습니다.[20] Hoodi 테스트는 시기가 결정되지 않은 미래의 이정표로 남아 있습니다. 이는 활성화 날짜가 정해지지 않은 2026년 4분기 mainnet 목표와는 별개입니다. Hoodi 연기 자체가 mainnet 날짜를 결정하지는 않습니다.[20][21]
개발자들은 데브넷과 testnets에서 발견된 버그, 완결성 문제 또는 클라이언트 분기에 대응하여 이 일정을 조정할 의사가 있음을 나타냈으며, 이는 Pectra 및 Fusaka 업그레이드에서 취했던 신중한 접근 방식을 반영합니다.[12][3] 공식 보안 감사 및 커뮤니티 버그 바운티는 공개 testnet 활성화와 최종 mainnet 일정 확정 사이의 기간에 집중되며, Ethereum Foundation 발표를 통해 Sepolia fork 전후의 버그 바운티 적용 범위가 확인되었습니다.[10][16] Sepolia가 완료됨에 따라, 개발자들은 남은 Hoodi 리허설 및 후속 테스트를 mainnet 활성화 결정 전의 마지막 주요 이정표 중 하나로 설명하고 있습니다. Hoodi 일정은 연기된 이후 아직 결정되지 않았습니다.[18][20]
주요 기능
Glamsterdam은 Ethereum 네트워크에 몇 가지 중요한 개선 사항을 도입할 것으로 예상되며, 그 범위의 상당 부분은 Meta‑EIP‑7773에 정의되어 있으나 테스트 결과에 따라 최종 포함 여부가 결정될 예정입니다. 이러한 기능들은 현재 계획 중이거나 테스트 단계에 있으며 mainnet에 활성화된 상태는 아닙니다.[10] 높은 수준에서 볼 때, 이번 업그레이드는 프로토콜 내장형 제안자‑빌더 분리(ePBS), block 레벨 액세스 리스트(BALs), 그리고 장기적인 상태(state) 성장과 단기적인 연산을 더 잘 구분하기 위한 광범위한 gas 가격 재산정 및 회계 변경에 초점을 맞추고 있습니다.[16] 이러한 변화들은 비전문 하드웨어로도 풀 node 요구 사항을 충족할 수 있는 수준을 유지하면서, 레이어 1 및 롤업을 위한 블록 데이터(blob) 처리량을 늘리는 것을 목표로 합니다.[10]
Meta‑EIP‑7773에 따라 Glamsterdam의 Sepolia 배포는 해당 testnet에 포함될 예정인 일련의 EIP들을 추적합니다. 여기에는 ePBS(EIP‑7732), BALs(EIP‑7928), 스토리지 및 해싱에 대한 gas 가격 재산정(EIP‑8037 및 EIP‑8038 등), EIP‑2780을 통한 리소스 기반 내재적 gas, ETH 전송 로그(EIP‑7708), 결정론적 팩토리 사전 배포(EIP‑7997), SLOTNUM 옵코드 및 관련 실행 변경 사항, 컨트랙트 크기 제한 상향, validator 퇴출 및 이탈(churn) 조정, 최근 슬래싱된 제안자의 block 생성 제외, 그리고 BAL 및 ePBS 데이터 전파에 필요한 네트워킹 지원 EIP들이 포함됩니다.[16][10] 발표된 범위는 mainnet 활성화 전에 변경될 수 있으며, EIP‑7805(FOCIL)나 컨트랙트 코드 크기 규칙 수정과 같은 일부 제안은 Glamsterdam fork의 확정된 구성 요소라기보다 "포함 고려 대상"으로 취급됩니다.[3][10] EIP-8037 및 EIP-8038의 가격 재산정은 상태 리소스 비용을 반영하고 용량 증설을 지원하기 위한 것입니다. 기존 컨트랙트와의 호환성 검토는 별도의 메인넷 이전 고려 사항이며, 이로 인해 개발자들은 Hoodi 테스트를 연기하게 되었습니다.[20][22]
이 범위 내에서 **EIP‑7732 (ePBS)**는 Glamsterdam의 합의 계층(consensus-layer) 핵심 요소로 남아 있으며 업그레이드에 포함될 예정이지만 아직 mainnet에 적용되지는 않았습니다.[7][10] 이는 block 제안자와 빌더를 공식적으로 분리하고 빌더의 약속(commitment)과 지불을 프로토콜 내부로 가져옵니다. 이를 통해 데이터 전파 및 검증 창을 넓히고, 특히 레이어 2 롤업에서 사용하는 블록 데이터에 대해 더 큰 페이로드와 높은 처리량을 가능하게 합니다.[15][14] ePBS는 페이로드 적시성 위원회(PTC) 및 이중 마감 증명 로직과 같은 메커니즘을 도입하여 적시에 block이 전달되도록 강제하고 활성(liveness) 보장을 강화하는 한편, block 구축 시장에서 외부 MEV 릴레이 및 기타 중앙 집중식 중개자에 대한 의존도를 낮춥니다.[15][14] 이 EIP가 해결하는 주요 과제는 빌더가 block 약속을 제출하고도 시장 상황이 불리해지면 전체 block을 공개하지 않기로 선택하여 네트워크 활성을 해칠 수 있는 "무료 옵션 문제(free option problem)"입니다.
BAL, 수정된 gas 회계, 자원 기반 고유 gas를 포함한 Glamsterdam의 실행 레이어 변경 사항은 영구 상태의 보다 효율적인 사용을 장려하고, 후속 로드맵 단계에서 Ethereum이 더 높은 병렬성과 더 큰 블롭 사용량을 확보할 수 있도록 준비하기 위해 설계되었습니다.[16][10] 임계값 암호화(threshold encryption) 및 사일런트 임계값 암호화와 같이 ePBS 무료 옵션 문제를 완화하기 위한 암호학적 접근 방식은 Shutter와 같은 프로젝트와 연구자들에 의해 계속 탐구되고 있지만, 이러한 메커니즘은 Glamsterdam fork의 핵심 부분은 아니며 향후 업그레이드에 영향을 미칠 수 있는 별도의 연구 방향으로 남아 있습니다.[9] “The Verge” 로드맵에 따른 Verkle 트리와 block 시간을 6초로 단축하자는 제안과 같은 장기적인 아이디어들은 광범위한 Ethereum 로드맵에서 논의되고 있으나, EIP-7773에 정의된 Glamsterdam hard fork의 예정된 구성 요소는 아닙니다.[10][6]
Impact and Challenges
Glamsterdam은 내재화된 제안자-빌더 분리(enshrined Proposer-Builder Separation, ePBS)를 BAL을 통한 블록 레벨 병렬 실행 및 광범위한 gas 및 상태 비용 재산정과 결합했기 때문에, 많은 핵심 개발자와 논평가들로부터 The Merge 이후 가장 중요한 프로토콜 수준의 구조 조정으로 평가받고 있습니다.[14][10] 데브넷(Devnet) 실험과 Sepolia testnet fork 결과에 따르면, BAL 활성화 실행을 통해 Sepolia의 gas 한도를 약 6,000만에서 block당 약 2억 gas로 높였을 때, mainnet에서도 유사한 조건이 유지된다면 많은 일반적인 작업의 평균 트랜잭션 수수료가 약 70~80% 하락할 수 있음을 시사합니다. 다만, 이 수치들은 실제 운영 네트워크에서의 보장이 아닌 모델링 및 testnet 환경에서의 예측치입니다.[11][17][18] 공식적인 Sepolia 일정과 버그 바운티 적용 하에서의 성공적인 완료는 Glamsterdam이 설계 단계에서 완전한 공개 테스트 단계로 넘어갔음을 나타냅니다. 2026년 10월 26일로 예정되었던 Hoodi 활성화는 mainnet에 배포된 smart contracts와 EIP-8037의 상호작용을 조사하기 위해 10월 22일에 연기되었으며, 11월 3일까지 대체 날짜는 발표되지 않았습니다. Hoodi 테스트는 시기가 결정되지 않은 미래의 이정표로 남아 있으며, 2026년 4분기 mainnet 목표는 여전히 잠정적이며 확정된 활성화 날짜가 없습니다. Sepolia의 활성화는 mainnet 활성화가 아니었으며, Hoodi의 연기 또한 메인넷 날짜를 확정 짓지 못했습니다.[16][20][21]
동시에 2026년 11월 현재 몇 가지 위험과 미결 과제가 남아 있습니다. 연구원들은 공개 testnets에서 ePBS에 대한 잠재적인 빌더 남용 벡터를 강조해 왔으며, 여기에는 더 긴 타이밍 윈도우를 악용하거나 페이로드 선택을 조작하려는 전략이 포함됩니다. 이러한 행동들은 완료된 Sepolia fork의 중점 사항이었으며, 추가적인 Hoodi 테스트 시기는 연기 이후 결정되지 않은 상태입니다.[13][20] 개발자들은 또한 EIP-8037의 상태 생성 gas 회계 방식이 메인넷에 배포된 smart contracts와 어떻게 상호작용하는지 조사하기 위해 Hoodi 활성화를 연기했습니다.[20] 클라이언트 팀들 또한 안정적인 Glamsterdam 지원 버전을 출시하고 이를 각 testnet에서 활성화하는 사이의 촉박한 일정에 직면해 있어, 조율된 테스트 및 롤백 계획의 중요성이 커지고 있습니다.[12] 더 넓게는, 2026년 4분기 목표에도 불구하고 고정된 mainnet 날짜가 없다는 점은 데브넷이나 testnet 결과에서 해결되지 않은 문제가 발견될 경우 활성화를 늦추겠다는 개발자들의 의지를 뒷받침합니다.[21]
투자자들에게 성공적인 업그레이드는 네트워크 효율성과 유틸리티를 향상시켜 Ethereum (ETH)의 장기적인 가치 제안을 잠재적으로 강화할 수 있는 반면, 차질이나 지연은 일시적으로 불확실성을 높일 수 있지만 속도보다 안전을 우선시한다는 신호가 될 수도 있습니다. 개발자들에게 Glamsterdam의 새로운 EIPs(ePBS, BALs 및 개정된 gas 회계 포함)는 상당한 코드 변경이 필요할 수 있지만, 더 정교하고 효율적이며 안전한 decentralized applications의 문을 여는 새로운 기능, 도구 및 최적화를 도입합니다. 사용자들에게 이 업그레이드의 순효과는 시간이 지남에 따라 더 안정적이고 안전하며 잠재적으로 더 빠르고 저렴한 네트워크 경험이 될 것으로 예상되며, 전환 기간 동안의 단기적인 복잡성은 장기적인 용량 이득과 균형을 이룰 것입니다.
예상되는 이점에도 불구하고, Ethereum만큼 크고 복잡한 네트워크를 위한 hard fork를 조정하는 것은 상당한 과제를 안겨줍니다. 수천 명의 기여자는 하위 호환성을 보장하고, 클라이언트 다양성을 유지하며, 모든 변경 사항을 엄격하게 테스트해야 합니다. Fusaka에서 EIP-7907을 연기하고 Glamsterdam 범위의 요소를 testnet 결과에 따라 조건부로 처리하기로 한 결정은 이러한 복잡성을 강조하며, 성급한 구현보다 신중함과 철저함을 기하려는 개발자들의 의지를 보여줍니다. 또 다른 주요 과제는 Ethereum이 확장됨에 따라 검열 저항성 및 프라이버시를 포함한 핵심 정신을 보존하는 것이며, 일부 개발자들은 이를 전략적 목표로 명시적으로 재확인하지 않을 경우에 대해 우려를 제기해 왔습니다.
프로젝트 코디네이터인 Tim Beiko는 "프로토콜은 이제 더 집중된 팀과 함께 더욱 통합되고 효율적인 조직이 되었으며... EF의 자원이 최대의 영향력을 발휘할 수 있도록 할당되도록 보장하고 있습니다"라고 말했습니다. 그는 또한 "Ethereum은 중대한 돌파구의 직전에 서 있습니다... 이것은 우리의 기술뿐만 아니라 우리의 가치를 행성 규모로 배포할 수 있는 최고의 기회일 수 있습니다"라고 언급했습니다. Ansgar Dietrichs는 "Glamsterdam의 경우... 우리는 blob 확장을 계속할 수 있는 몇 가지 방법을 찾아야 할 것입니다... EL 측면의 확장 기회도 있을 수 있습니다"라고 덧붙였습니다. 이러한 발언들은 Glamsterdam 업그레이드의 전략적 중요성과 야심 찬 목표를 강조합니다.[2][3]
Gas-Repricing Compatibility Review
EIP-8037은 상태 가스 저장소(state-gas reservoir)를 포함하여 상태 생성에 대한 별도의 회계를 도입하고, EIP-8038은 상태 액세스 가격을 재조정합니다. 제안된 EIP-8037 회계 방식에 따르면, 저장소 펀딩은 gasleft()에 의해 보고되는 실행 gas와 구별됩니다. 트랜잭션 초기에 생성된 스토리지를 삭제하면 미결제 실행 펀딩 상태 생성 비용까지 실행 가스를 보충할 수 있으며, 되돌리기(reverting) 중개자 또한 실행 펀딩 상태 생성 비용을 복구할 수 있습니다. 이러한 변경 사항은 외부 호출 실패 후 사용 가능한 실행 가스를 변경할 수 있으며, 호출 후 남은 가스를 확인하거나 가스 부족으로 실행되는 실패 핸들러에 의존하는 컨트랙트에 영향을 미칠 수 있습니다.[23]
예를 들어, 이전에는 실패 처리기에 가스가 너무 적게 남아 재시도나 리버트(revert)를 강제했던 가스 부족 외부 호출이, 제안된 회계 방식 하에서는 처리기가 완료되고 실패를 커밋하기에 충분한 실행 가스를 남길 수 있습니다. 이는 조건부 동작이며, 외부 호출이나 가스 체크를 사용하는 모든 컨트랙트가 취약하다는 주장은 아닙니다. 사전 호출 가스 체크가 허용된 경로를 포함하고 전달 오버헤드가 새로운 스케줄 하에서 재검증된다면, 올바르게 범위가 지정된 체크는 여전히 작동할 수 있습니다. ChainSecurity는 실패 처리 경로를 검토하고 변경된 규칙에 따라 테스트할 것을 권장합니다.[23]
ChainSecurity는 13개의 실제 사례를 식별했으며 책임 있는 공개(responsible disclosure)를 진행 중이라고 밝혔습니다. 이 사례들은 13개의 확인된 익스플로잇이 아니라 잠재적으로 영향을 받을 수 있는 사례로 보고되었습니다.[24] Ethereum Foundation의 과거 mainnet 리플레이 분석 결과, 대다수의 컨트랙트는 영향을 받지 않는 것으로 나타났습니다. 플래그가 지정된 많은 사례는 가스 한도를 높임으로써 해결될 수 있는 반면, 고정된 가스 수당(stipends), 하드코딩된 가스 값, gasleft() 분기 또는 가스에 민감한 실패 처리에 의존하는 소수의 사례는 코드 변경이 필요할 수 있습니다. 애플리케이션 팀은 영향을 받는 컨트랙트 결과를 조사하고, 플래그가 지정된 호출 지점을 검토하며, Glamsterdam 개발 네트워크에서 변경 사항을 테스트하고 가스 추정치를 업데이트하라는 권고를 받았습니다.[22]
잘못된 내용이 있나요?
