• 이더리움 개발자들은 새로운 검증자를 위한 ETH를 인출할 수 있었던 예정된 Glamsterdam 업그레이드의 결함을 수정했습니다.
• 이 취약점은 빌더와 검증자 예치금이 공개 키를 공유하여, 두 예치금이 모두 빌더에게 크레딧될 수 있었고 스테이킹 서비스가 자금을 회수할 수 없게 만들 수 있었습니다.
• 보고된 손실은 없으며, 클라이언트 팀은 이제 Glamsterdam이 메인넷 출시로 진행되기 전에 수정된 예치 규칙을 통합해야 합니다.

이더리움 개발자들은 새로운 검증자를 위한 스테이킹 서비스의 ETH를 빼앗길 수 있었던 예정된 Glamsterdam 업그레이드의 결함을 수정했습니다.

검증자 예치금 처리 규칙을 변경한 수정은 개발자들이 이를 거부한 지 일주일 만인 월요일에 병합되었습니다.

Glamsterdam은 현재 함께 묶여 있는 두 작업을 분리합니다. 빌더는 거래 블록을 조합하고, 네트워크 보안을 위해 ETH를 스테이킹하는 검증자는 이를 선택하고 확인합니다. 둘 다 ETH를 예치할 수 있으며, 그들의 자금은 별도로 추적되어야 합니다.

자금이 사라질 수 있는 방법

문제는 업그레이드 자체에서 나타났으며, 이더리움이 아직 크레딧되지 않은 예치금을 처리할 때 발생했습니다.

연구원 avsetsin은 한 운영자가 특정 공개 키를 사용하여 빌더로 먼저 등록하는 시나리오를 식별했습니다. 스테이킹 서비스가 해당 키로 검증자를 시작하기 위해 ETH를 예치하면, 초안 규칙은 두 예치금을 모두 빌더에게 크레딧합니다.

“운영자는 프로토콜의 자금을 인출할 수 있습니다,”라고 avsetsin은 썼습니다. 검증자가 생성되지 않으므로, 스테이킹 서비스는 자금을 회수하는 데 필요한 증거를 생성할 수 없습니다.

Lido의 GitHub 조직의 일원으로 나열된 avsetsin은 Lido, Origin 및 Rocket Pool이 어떻게 영향을 받을 수 있는지를 살펴보았으며, 연구자는 이를 “빠른 AI 연구”라고 불렀습니다. 결과는 각 프로토콜이 예치금을 처리하는 방식에 따라 달라졌습니다.

“이들은 조건부 코드 발견이며, 라이브 익스플로잇으로 확인된 것은 아닙니다,”라고 avsetsin은 썼으며, 초기 빌더 예치를 거부하는 기존 검사가 공격을 막을 수 있다고 덧붙였습니다. 보고된 손실은 없습니다.

거부 후 병합

개발자들은 10월 19일에 제안된 수정을 닫았습니다. “이 시점에서 이 변경을 지원하는 클라이언트가 충분하지 않았습니다,”라고 이더리움의 합의 사양을 유지하는 Justin Traglia가 썼습니다. 클라이언트는 네트워크에 참여하기 위해 검증자가 실행하는 별도의 소프트웨어 프로그램입니다.

추가 검토 후 수정이 다시 열렸고, avsetsin은 10월 23일에 테스트를 추가했으며, Traglia는 월요일에 이를 병합했습니다.

새로운 규칙에 따라, 대기 중인 예치금은 예치금의 자금이 결국 어디로 갈 수 있는지를 나타내는 인출 자격 증명에 따라 정렬됩니다. 검증자 예치금은 빌더가 동일한 키를 사용하더라도 검증자와 함께 유지됩니다.

이 변경은 이제 이더리움의 합의 사양의 일부이며, 클라이언트 팀은 여전히 이를 소프트웨어에 통합해야 합니다. Glamsterdam은 이미 Sepolia 테스트 네트워크에서 실행되었지만, 두 번째 테스트 네트워크인 Hoodi에서의 10월 26일 출시는 연기되었습니다.

Glamsterdam은 메인넷 출시를 예약하기 전에 새로운 Hoodi 날짜가 필요합니다.

더 읽기: 보안 개발자가 기존 계약에 대한 위험을 경고한 후 이더리움이 Glamsterdam 테스트를 연기하다