이더리움 개발자 회의 리뷰: 칸쿤 업그레이드, 하드포크 및 프라하
글: Christine Kim, Galaxy 연구 부사장
번역: 진진, 카본체인 밸류
2024년 1월 4일, 이더리움 개발자들이 Zoom을 통해 올 코어 디벨로퍼스 익스큐션(ACDE) #178 회의에 모였다. ACDE 회의는 일반적으로 이더리움 재단 프로토콜 책임자 팀 베이코(Tim Beiko)가 주최하며, 이더리움 실행 계층(EL)의 변경 사항에 대해 개발자들이 논의하고 조율하는 격주 회의 시리즈다. 이번 회의는 'Lightclient'라는 익명의 Geth EL 개발자가 진행했다. 개발자들은 Cancun/Deneb(Dencun) 업그레이드를 위한 다음 세 가지 공개 테스트넷 활성화 일정을 다시 한번 확인했다. 또한 Dencun 이후의 다음 하드포크 업그레이드인 Prague/Electra에서 코드 변경(EIPs) 우선순위에 대해서도 논의했다.
Dencun 업데이트
연휴 기간 동안 Dencun 업그레이드에 관한 구체적인 업데이트는 없었다. 지난 12월 21일 ACDE #177 회의 이후 클라이언트 팀은 Goerli 테스트넷용 새 버전 준비에 집중해왔다. 이전에 Prysm으로 인해 업그레이드 테스트가 지연되었던 점을 감안해, Geth 개발자 마리우스 반 더 비덴(Marius van der Wijden)은 Prysm 클라이언트 팀에게 새 버전 출시 계획의 최신 상황을 요청했다. Prysm 개발자 테런스 차오(Terence Tsao)는 Prysm 팀이 다음 주 안에 Goerli 하드포크용 새 버전을 준비할 수 있을 것이라고 확인했다. 다만, Goerli용 버전은 '프리릴리스(pre-release)' 버전이 될 것이며, 즉 메인넷에서 사용하기 위한 권장 버전은 아닐 것이라고 밝혔다. Goerli 하드포크 이후에는 특정 수정 및 업데이트를 포함한 또 다른 버전을 출시하여 사용자들에게 메인넷 운영을 위해 추천하고, Sepolia 또는 Holesky 테스트넷에서 테스트할 예정이다.
차오는 ACDE #177에서 논의된 바와 같이 Goerli 하드포크 활성화 날짜가 1월 17일인 데 대해 만족한다고 언급하면서도, Goerli 하드포크 이후에야 Sepolia 및 Holesky 하드포크 활성화 날짜를 결정하자고 제안했다. ACDE #177 이후로, 이더리움 재단 프로토콜 지원 담당자 팀 베이코(Tim Beiko)는 Goerli, Sepolia, Holesky 세 개의 이더리움 공개 테스트넷에 대한 테스트넷 포크 일정을 제안했다. 제안된 포크 활성화 시간은 다음과 같다:
-
Goerli--2024년 1월 17일 -- 에포크 231680-- 타임스탬프 1705473120
-
Sepolia--2024년 1월 30일 -- 에포크 132608-- 타임스탬프 1706655072
-
Holesky--2024년 2월 7일 -- 에포크 29696—타임스탬프 1707305664
Lightclient는 Prysm 외의 다른 클라이언트 팀들이 베이코가 제안한 Goerli 하드포크 활성화 시간에 동의하는지 물었다. 회의에 참석한 모든 클라이언트 팀(Geth, Lodestar, Lighthouse, Teku, Besu 포함)은 적절한 시기라고 확인했으며, 늦어도 다음 주까지 Goerli 노드 운영자를 위한 버전을 출시할 수 있다고 답했다. Lighthouse 클라이언트 팀은 여전히 클라이언트의 일부 네트워크 기능을 테스트 중이라며, 그들의 버전 역시 Prysm과 마찬가지로 프리릴리스 버전이 될 수 있다고 언급했다.
Dencun 일정 논란
이후 Lightclient는 Sepolia와 Holesky 테스트넷의 제안된 활성화 일정에 관해 논의를 이어갔다. 'Potuz'라는 가명을 사용하는 또 다른 Prysm 개발자는 메인넷 이전 마지막 두 개 테스트넷의 업그레이드 날짜를 지금 바로 확정하지 말 것을 제안했다. "Goerli에서 문제가 생길 가능성을 고려해 지금 당장 날짜를 약속하려 하지 말아야 한다. 거기서 돌아오는 것은 문제다. 올바른 에포크를 가진 새 버전을 추가하는 것은 쉽지만, 버전을 삭제하고 오류를 수정하는 것은 문제가 된다. 이건 몇 주보다 훨씬 긴 시간이 소요된다"고 Potuz는 말했다.
Lightclient는 클라이언트 팀들이 Goerli 하드포크 후 일주일 뒤에만 새 버전을 출시하면 되므로, 1월 24일 이후가 아니라면 Goerli에서 문제가 발견되지 않는 한 반드시 새 버전을 삭제할 필요는 없다고 강조했다. Geth 개발자 마리우스 반 더 비덴은 Sepolia와 Holesky 테스트넷에 날짜를 정하는 데 별 해가 없다고 생각하며, 만약 Goerli에서 문제가 발생하면 언제든지 날짜를 조정할 수 있다고 말했다.
이더리움 재단 DevOps 엔지니어 바르나바스 부사(Barnabas Busa)는 줌 채팅에서, Sepolia와 Holesky 업그레이드를 위한 새 버전을 출시해야 하는 유일한 경우는 Goerli 버전이 정상 작동함이 확인된 후라고 주장했다. 'Sean'이라는 가명의 Lighthouse 개발자는 이 견해에 동의하며, Sepolia 하드포크에 대해 '임시' 날짜를 설정할 수 있지만 1월 30일 전까지는 먼저 Goerli 상황을 지켜보자고 말했다.
Potuz는 Goerli와 Sepolia 하드포크 활성화 사이에 일주일의 테스트 기간을 추가할 것을 제안하며, 기본적으로 분석 기간을 세 주에서 두 주로 줄이자고 주장했다. 일주일의 추가 테스트 기간은 클라이언트 배포판이 며칠간 '침지(soak)'될 수 있게 하고, 클라이언트 팀이 다음 테스트넷 업그레이드를 위해 다시 새 버전을 잘라내야 할 필요성을 줄여준다고 설명했다. "두 주 간격은 너무 짧다. 그것이 제가 지적하고자 하는 점이다." Potuz는 이어, Goerli 클라이언트 배포판이 충분히 분석되고 테스트된다면, Sepolia와 Holesky 하드포크 활성화 사이에 세 주의 준비 기간이 필요하지 않을 수도 있다고 덧붙였다.
Potuz의 견해는 논란을 불러일으켰다. 이더리움 재단의 안스가르 다이트릭스(Ansgar Dietrichs)는 첫 번째 공개 테스트넷 활성화와 메인넷 활성화 사이의 시간이 보통 개발자들에게 '마감 기한(deadline)' 역할을 하며, 이를 연장할 필요가 없다고 말했다. 그러나 다이트릭스는 테스트넷 업그레이드 간격을 늘리고자 하는 바람은 하드포크 맥락에서 더 진지하게 논의되어야 하며, 단지 Dencun 업그레이드만을 위한 특별한 조치가 되어서는 안 된다고 지적했다. 그는 "누군가 더 긴 과정을 원한다면, 하드포크 직전이 아니라 충분한 시간을 갖고 이 문제를 논의해야 한다"고 말했다.
Lightclient은 다이트릭스의 견해에 동의하며, 만일 10월 초부터 이 문제를 논의했다면 개발자들이 Dencun 테스트넷 일정 연장을 더 너그럽게 받아들였을 것이라고 말했다. 그는 "저는 우리가 작년 가을에 업그레이드를 마무리하려 했기 때문에, 지금 우리는 정말로 목표를 이루기 위해 노력하고 있으며, 따라서 우리의 일정을 좀 더 적극적으로 잡아야 한다고 생각한다"고 말했다.
적극적인 일정 유지
개발자들이 회의에서 나눈 의견을 바탕으로, 이더리움 재단 DevOps 엔지니어 파리토쉬 자얀티(Parithosh Jayanthi)는 Sepolia 하드포크 업그레이드를 약 일주일 미루고, Goerli 업그레이드 후인 1월 25일 ACDE 회의에서 Sepolia 하드포크 날짜를 정하자고 제안했다. 마리우스 반 더 비덴은 테스트넷 업그레이드 활성화 날짜를 재논의하기 위해 ACDE 회의에 완전히 의존하는 것에 반대했다. 그는 "저는 All Core Devs 회의를 다시 열어 날짜를 확인해야 하는 상황을 정말 피하고 싶다"며, "Sepolia 이제 시작해도 좋다는 말을 하기 위해 All Core Devs 회의를 다시 열고, 그 후 두 주를 기다려야 Sepolia를 실제로 시작할 수 있게 되는 건 정말 싫다"고 덧붙였다.
모든 당사자의 우려를 완화하기 위해, Geth 개발자 기욤 발레(Guillaume Ballet)는 Sepolia 하드포크를 위한 두 가지 임시 일정을 제안했다. Goerli 하드포크 결과가 긍정적이면 하나의 일정을 따르고, 부정적이면 다른 일정을 따르자는 제안이었다. 그러나 Lightclient와 다이트릭스 모두 이 아이디어에 반대했는데, Sepolia 하드포크를 위한 새로운 일정을 설정하기 전에 먼저 Goerli에서 발생한 오류와 문제의 성격을 평가해야 한다고 판단했기 때문이다.
참고로, 이더리움 재단 테스트팀의 'Danceratopz'라는 가명을 사용하는 개발자는, 개발자들이 Sepolia 업그레이드 전에 Goerli 테스트넷에서 blob 만료 문제를 평가하고 싶은지 물었다. 참고로 blob 만료란 약 2주 후 이더리움 상태에서 blob 데이터를 삭제하는 현상을 말한다.
Lighthouse의 Sean과 Besu 팀의 저스틴 플로렌타인(Justin Florentine) 모두 Dencun 메인넷 활성화 전에 세 테스트넷 중 하나에서 blob 만료 상황을 평가하는 것이 좋다고 찬성했다. 플로렌타인은 테스트넷에서 blob 만료를 기다리는 것이 2단계 롤업 프로토콜 팀과 애플리케이션 개발자들이 Dencun 업그레이드를 준비하는 데에도 도움이 될 것이라고 강조했다. Lighthouse의 Sean은 Goerli에서 blob 만료를 관찰하는 것이 필수적이지는 않지만, Sepolia와 Holesky 사이의 테스트 기간을 늘리는 이유가 될 수 있으며, 이를 통해 개발자들과 2단계 팀들이 Sepolia에서 blob의 전체 생명주기를 경험할 수 있다고 말했다. 그러나 회의에서 다른 개발자들은 Sean의 제안에 명확히 동의하지 않았다.
오히려 Lightclient은 회의 중 개발자들에게 Beiko가 제안한 일정—즉, 1월 30일 Sepolia 업그레이드, 일주일 뒤인 2월 7일 Holesky 업그레이드—을 유지할 의사가 있는지 물었다. 추가 이견이 없었기 때문에, Lightclient은 개발자들이 기존 일정을 유지하기로 했다고 발표했다. Potuz는 줌 채팅에서, Sepolia를 일주일 앞서 업그레이드하는 대신, 2월 7일에 Sepolia와 Holesky 테스트넷을 동시에 업그레이드하고 싶다고 밝혔다. 통화 후 디스코드 메시지에서, Lightclient은 Dencun 테스트넷 일정이 당분간 그대로 유지된다고 다시 한번 확인했다.
Prague/Electra
이어서 개발자들은 Dencun 이후의 다음 업그레이드(Prague/Electra)에서 어떤 EIP들을 우선시해야 할지 논의했다. 마리우스 반 더 비덴은 개발자들이 다른 EIP보다 Prague/Electra의 머클 트리 업그레이드에 집중해야 한다고 말했다. 그는 이 견해에 대해 두 가지 주의점을 덧붙였다. 첫째는 머클 트리 준비 상태다. ACDE #177에서 논의된 바와 같이, 개발자들은 머클 트리 구현 세부사항과 하드포크 업그레이드 준비 상태를 깊이 있게 논의하기 위한 특별한 ACDE 회의를 계획하고 있다.
반 더 비덴이 언급한 두 번째 주의점은 EL의 업그레이드와 컨센서스 레이어(CL)를 분리할 수 있는 가능성이다. 그는 CL에는 EL의 머클 트리 업그레이드보다 더 빠르게 시행되어야 할 '높은 우선순위, 매우 시급한' EIP들이 존재할 수 있다고 말했다. "중요한 것은 컨센서스 레이어 담당자들이 이러한 [긴급한] 변경을 위해 하드포크가 필요한지, EL 참여 없이도 완료할 수 있는지, 아니면 EL 참여가 필요해서 어쨌든 공동 하드포크를 해야 하는지를 논의하는 것이다. 그렇게 되면 나는 작은 하드포크를 수용할 수 있다"고 반 더 비덴은 말했다. "따라서 머클 트리는 확실히 최우선이며, 이 두 가지를 고려해 추진해야 한다."
이더리움 재단 연구원 안스가르 다이트릭스(Ansgar Dietrichs)는 줌 채팅에서 머클 트리를 중심으로 Prague/Electra 업그레이드를 진행하는 것에 '강력히 반대'한다고 밝혔다. 머클 트리에 필요한 코드 변경의 복잡성을 고려하면, 이는 업그레이드가 2025년까지 연기될 가능성이 크기 때문이라고 설명했다. Nethermind 클라이언트 개발자 루카슈 로즈메이(Lukasz Rozmej)도 다이트릭스의 견해에 동의했다. 그는 "제 경험상 상태 재설계는 매우 어렵고 아주 오랜 시간이 걸린다"며, "머클 트리가 매우 좋고 큰 진전을 이루고 있다고 생각하지만, 머클에만 집중한다면 다음 하드포크는 최소 1년 이상 걸릴 것"이라고 말했다. "따라서 제 제안은, 각 팀이 머클 트리에 계속 집중하면서도, 작은 하드포크에 집중하는 것이 좋다는 것이다. 그리고 이 주제에 적절한 자원, 작업량, 인력을 배정해야 한다"고 덧붙였다.
머클 트리 중심
Prague/Electra가 머클 트리에 집중해야 할지, 아니면 머클보다 빠르게 출시 가능한 작은 코드 변경을 우선시해야 할지에 대해 개발자들 사이에 의견이 분분했다. 발레(Ballet)는 자신의 입장에서 '작은 포크'란 존재하지 않으며, 머클 트리 구현을 더 오래 미룰수록 이더리움 상태 업데이트의 난이도가 증가한다고 강조했다. Nethermind 클라이언트 개발자 토마시 스탄차크(Tomasz K. Stańczak)는 더 야심 찬 접근법을 제안하며, Prague/Electra가 포함할 수 있는 것보다 더 많은 EIP를 수용하자고 말했다. "팀의 역량을 활용해, 우리 해야 할 가장 큰 도전에 대응할 수 있음을 입증해야 한다. 만약 머클 트리가 3월까지 점점 더 많은 어려움을 드러낸다면, 사람들은 다시 질문을 던지고 '좋아, 머클은 내려놔'라고 말할 수 있다. 하지만 우리는 그때까지 포함하기로 한 꽤 괜찮은 다른 EIP 세트를 계속 사용할 수 있을 것이다"고 Stańczak은 말했다. 그는 머클 외에도 Prague/Electra에 포함될 수 있는 중요한 EIP들로 스테이킹, 리스테이킹, 계정 추상화 관련 EIP들을 언급했다.
Stańczak의 질문에 답하며, Lightclient은 개발자들이 머클 트리처럼 '18~24개월이 소요되는 프로젝트'를 포함한 일련의 EIP를 약속한 후에는 Prague/Electra에 무엇을 포함할지 논의하기 어려울 수 있다고 말했다. Erigon 클라이언트 개발자 앤드류 아시크민(Andrew Ashikhmin)은 Prague/Electra 포크에서 작은 EIP를 출시하면서 동시에 머클 트리를 개발하고, 이후 포크에서 적용하는 것을 선호한다고 밝혔다. 발레는 Stańczak의 제안—즉 Prague/Electra에서 머클 트리 개발에 집중하다가, 구현 중 심각한 문제가 발견되어 더 많은 시간이 필요하면 업그레이드에서 제외하는 것—에 찬성했다.
CL 업그레이드 중심
EL(실행 계층)과 CL(컨센서스 계층) 업그레이드를 분리하는 문제에 관해, Potuz는 Prague/Electra에서 CL 변경만 필요한 EIP는 하나뿐이라고 언급했다. "유일한 변화는 인증 인덱스 위원회 취소뿐이며, Max EB처럼 CL에만 관련된 것으로 보이는 다른 변화들도 EL의 다른 변화에 의존한다. 따라서 순수한 CL 포크는 일어나지 않을 것이라고 생각한다. 적어도 올해도, 내년도 아니다. 순수한 CL 제안이 충분하지 않다"고 Potuz는 말했다.
그럼에도 불구하고, 안스가르 다이트릭스는 일부 EIP들이 주로 CL 중심의 업그레이드이며 EL의 사소한 변경만 필요해 EL 클라이언트 팀이 쉽게 수행할 수 있다고 말했다. 이런 EIP들도 여전히 EL과 CL의 조정된 하드포크가 필요하다. 다이트릭스는 이어 CL 측면에서 데이터 가용성 샘플링(DAS)이 EIP 4844 이후 가장 중요한 코드 변경이라고 생각한다고 덧붙였다. 다이트릭스와 Lightclient 사이에는 DAS가 하드포크를 통해 구현되어야 하는지 여부에 대해 다소 견해 차이가 있었다.
EOF 및 기타 EIP에 주목
'Rodiazet'라는 가명을 사용하는 개발자는 이더리움 재단의 Ipsilon 팀에서 일하며, 이더리움 가상 머신(EVM) 연구를 담당한다. 참고로 EOF는 EVM Object Format의 약자로, EVM에 대한 일련의 개선 사항이며, 원래 Cancun/Deneb 업그레이드에 포함되려 했다.
머클 트리 외에도 개발자들은 EIP 5920(PAY 오퍼코드), EIP 2537(BLS12-381 곡선 연산 프리컴파일) 등의 다른 EIP들을 검토 대상으로 제시했다. Prague/Electra 후보 EIP의 전체 목록은 이더리움 매직사(Ethereum Magicians) 웹사이트의 업그레이드 메타 스레드에서 확인할 수 있다. 대부분의 개발자들이 Cancun/Deneb 이후 어느 정도 머클 트리를 우선시하는 데 동의했지만, 2024년에 더 빠르고 쉽게 실현 가능한 소규모 EIP들과 비교해 얼마나 머클 트리가 Prague/Electra에서 우선시되어야 할지는 아직 불확실하다. Lightclient은 개발자들이 이번 주 회의에서 Prague/Electra 내용에 대해 최종 결정을 내릴 필요는 없다고 강조하며, 곧 있을 ACDE 회의에서 이 주제를 계속 논의하자고 제안했다.
이후 개발자들은 회의에서 논의되지 않은 Prague/Electra 주제 내 EIP들에 대해 간략히 언급했다. 다음 EIP들을 포함하여:
-
EIP-7002: 실행 계층에서 트리거 가능한 탈퇴
-
EIP-7549: 인증 외부로 위원회 인덱스 이동
-
EIP-3074: AUTH 및 AUTHCALL 오퍼코드
-
EIP-6110: 체인 상에서 검증인 입금 제공
-
EIP-6913: SETCODE 명령어
-
EIP-7377: 마이그레이션 트랜잭션
-
EIP-4444: 실행 클라이언트의 바운드 역사 데이터
-
EIP-6404: SSZ 트랜잭션 루트
-
EIP-6465: SSZ 추출 루트
-
EIP-6466: SSZ 영수증 루트
-
EIP-7212: secp256r1 곡선 지원을 위한 프리컴파일
위 EIP들에 대한 상세한 견해 요약은 유튜브에 게시된 전체 회의 녹음에서 확인할 수 있다.
EIP 7587 공식화
마지막으로, 이더리움 재단 연구원 칼 비쿠이젠(Carl Beekhuizen)은 2단계 프로토콜이 사용할 수 있도록 미리 정의된 프리컴파일 주소 세트를 보존하는 EIP 7587에 관한 논의를 다시 꺼냈다. 비쿠이젠은 개발자들에게 이 EIP를 정보성 EIP로 공식화하고, 향후 이더리움 거버넌스 프로세스에 대한 규범을 만들기 위해 어떻게 하는 것이 가장 좋은지 물었다. Nethermind 개발자 아흐마드 비타르(Ahmad Bitar)는 EIP 프로세스 지침을 개괄하는 EIP 1 파일에 이 EIP를 포함시키는 것을 제안했다. Lightclient은 이더리움 매직사 웹사이트에서 이 주제를 추가로 논의하고, 필요시 다음 ACDE 회의에서 다시 논의하자고 제안했다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@galaxyhq
