이더넷 개발자 컨퍼런스 요약: 칸쿤 업그레이드, 하드 포크 그리고 프라하

글: 크리스틴 김 갤럭시 리서치 부사장, 작성:: Chin Jin 탄소 체인 가치

이더리움 개발자들이 2024년 1월 4일에 열린 모든 핵심 개발자 실행(ACDE) 콜 #178에 모였습니다.ACDE 콜은 보통 이더리움 재단의 팀 베이코가 주최합니다. 프로토콜 리드인 팀 베이코가 주최하며, 개발자들이 이더넷 실행 레이어(EL)의 변경 사항을 논의하고 조율하기 위해 격주로 진행되는 회의 시리즈입니다. 이번 주 회의는 '라이트클라이언트'라는 스크린네임의 익명의 Geth EL 개발자가 주최했습니다. 개발자들은 칸쿤/데네브(덴쿤) 업그레이드를 위한 다음 세 번의 공개 테스트넷 활성화 날짜를 재확인했습니다. 또한 덴쿤 이후의 다음 하드포크 업그레이드인 프라하/일렉트라의 코드 변경(EIP)에 대한 우선순위를 논의했습니다.

Dencun 업데이트

연휴 기간 동안 Dencun 업그레이드에 대한 구체적인 업데이트는 없었습니다. 12월 21일에 있었던 마지막 ACDE 텔레컨퍼런스 이후, 클라이언트 팀은 Goerli 테스트 네트워크를 위한 새로운 릴리스를 개발 중입니다. 이전에 Prysm으로 인해 업그레이드 테스트가 지연된 적이 있었기 때문에, Geth 개발자 마리우스 반 데르 비덴은 Prysm 클라이언트 팀에 새 버전 커팅 진행 상황에 대한 업데이트를 요청했고, Prysm 개발자 테렌스 차오는 다음 주에 새로운 버전의 Goerli 하드포크가 준비될 예정이라고 확인했습니다. 그러나 Goerli용 버전은 '사전 릴리스' 버전으로, 메인 이더 네트워크에서 사용하도록 권장되는 Prysm 버전이 아닙니다. 골리 하드포크 이후, Prysm 팀은 사용자가 메인넷에서 실행하고 세폴리아 또는 홀스키 테스트넷에서 테스트할 수 있도록 일부 변경 및 업데이트가 포함된 다른 버전을 출시할 계획입니다.

차오는 ACDE #177에서 논의된 대로 Prysm 팀은 1월 17일의 Goerli 하드포크 활성화 날짜에 만족하지만, Sepolia 및 Holesky 하드포크 활성화 날짜는 Goerli 하드포크 이후에 설정할 것을 권장한다고 말했습니다. 이더넷 재단의 프로토콜 지원 책임자인 팀 베이코는 ACDE #177 이후 이더넷 퍼블릭 테스트넷 세 곳(Goerli, Sepolia, Holesky)에 대한 퍼블릭 테스트넷 포크 타이밍을 제안했습니다. 제안된 포크 활성화 시간은 다음과 같습니다.

Goerli - 2024년 1월 17일 - 에포크 231680 - 타임스탬프 1705473120

세폴리아 - 2024년 1월 30일 - 에포크 132608 - 타임스탬프 1706655072

홀스키 - 2024년 2월 7일 - 에포크. 29696 - timestamp 1707305664

라이트클라이언트는 프라이즘을 제외한 다른 클라이언트 팀들에게 베이코가 제안한 고어리 하드포크 활성화 시점에 동의하는지 물었습니다. 이 통화에 참여한 모든 클라이언트 팀(Geth, Lodestar, 라이트하우스, 테쿠, 베수 포함)은 타이밍이 좋다고 생각하며 늦어도 다음 주까지는 Goerli 노드 운영자를 위한 버전을 출시할 수 있을 것이라고 확인했습니다. 라이트하우스 클라이언트 팀은 아직 클라이언트의 일부 네트워크 기능을 테스트 중이라는 점을 고려할 때 의 출시는 Prysm과 같은 사전 릴리스가 될 수 있습니다.

덴쿤 타임라인 발산

라이트클라이언트가 제안한 세폴리아 및 홀스키 테스트 네트워크의 활성화 시기에 대한 토론이 이어졌습니다. 토론을 시작할 시간입니다. 'Potuz'(가명)라는 아이디를 사용하는 한 Prysm 개발자는 메인 네트워크에 앞서 마지막 두 테스트 네트워크의 업그레이드 날짜를 미루자고 제안했습니다. "고를리에서 상황이 좋지 않을 수 있고 거기서 돌아오는 것도 문제가 될 수 있으므로 지금 날짜를 정하지 않는 것이 좋습니다. 변경 없이 올바른 에포크로 새 버전을 추가하는 것은 쉽습니다. 버전을 제거하고 버그를 수정하는 것은 문제입니다. 몇 주보다 훨씬 더 오래 걸립니다."라고 포투즈는 말합니다.

라이트클라이언트는 클라이언트 팀이 Goerli 하드포크 후 일주일이 지나야 새 버전을 출시할 수 있기 때문에 1월 24일 이후에 Goerli에서 업그레이드 문제를 발견하지 않는 한 새 버전을 제거할 필요가 없다고 강조했습니다.Geth 개발자 Marius van 데르 비덴은 Goerli에 문제가 발생하면 개발자가 언제든지 날짜를 변경할 수 있기 때문에 세폴리아 및 홀스키 테스트넷의 날짜를 설정하는 데 아무런 해가 없다고 말했습니다.

이더넷 재단의 데브옵스 엔지니어인 바르나바스 부사는 Zoom 채팅방에서 자신의 의견으로는 Goerli 버전이 제대로 작동하는 것을 확인한 후에야 새로운 버전의 Sepolia 및 Holesky 업그레이드를 출시하면 된다고 말했습니다. 버전이 제대로 작동하는지 확인한 후에 출시해야 한다고 말했습니다. 'Sean'이라는 아이디를 사용하는 라이트하우스의 개발자도 이에 동의하며, 개발자들이 세폴리아 하드포크의 '잠정' 날짜를 정할 수는 있지만 1월 30일 이전에 Goerli가 어떻게 진행되는지 지켜봐야 한다고 말합니다.

포투즈는 골리와 세폴리아 하드포크 활성화 사이에 일주일의 테스트 기간을 추가하여 3주가 아닌 2주 동안 분석할 것을 제안했습니다. 그는 테스트 기간을 일주일 추가하면 클라이언트 팀이 다음 테스트넷 업그레이드를 위해 새 버전을 다시 잘라내야 하기 전에 며칠 동안 클라이언트 배포를 '흡수'할 수 있을 것이라고 말했습니다. "2주라는 시간은 너무 짧습니다. 제가 지적하고자 하는 것은 바로 이 점입니다." 포투즈는 골리 클라이언트 배포를 충분히 분석하고 테스트했다면 세폴리아 하드포크 활성화까지 3주가 소요되지 않았을 수도 있다고 덧붙였습니다.

포투즈의 지적은 논란을 불러일으켰습니다. 이더리움 재단의 안스가 디트리히스는 업그레이드의 첫 번째 공개 테스트넷 활성화와 업그레이드의 메인넷 활성화 사이의 시간은 일반적으로 개발자들에게 '마감 시간'이므로 연장할 필요가 없다고 주장했습니다. 그러나 디트리히스는 테스트넷 업그레이드 사이의 시간 연장에 대한 요구는 덴쿤 업그레이드뿐만 아니라 하드포크의 맥락에서 개발자들이 더 진지하게 논의해야 한다고 언급하며, "누군가 더 긴 프로세스를 원한다면 하드포크 전에가 아니라 시간이 있을 때 논의해야 한다"고 말했습니다.

라이트클라이언트는 10월 초에 논의가 이루어졌다면 개발자들이 덴쿤의 테스트넷 타임라인을 연장하는 데 더 관대했을 것이라는 디트리히스의 의견에 동의하며, 다음과 같이 말했습니다. 작년 가을에 업그레이드를 완료하고 싶었기 때문이라고 생각합니다. 그래서 지금은 정말 그렇게 하려고 노력하고 있기 때문에 일정을 좀 더 공격적으로 잡았어야 한다고 생각합니다.

공격적인 일정 고수

이번 통화에서 의견을 나눈 이더넷 재단의 개발 엔지니어인 Parithosh에 따르면 다음과 같이 말합니다. 자얀티는 세폴리아 하드포크 업그레이드를 일주일 정도 연기하고 1월 25일 ACDE 콜에서 Goerli 업그레이드 이후 세폴리아 하드포크 날짜를 정하자고 제안했으며, 마리우스 반 데르 비덴은 테스트넷 업그레이드 활성화 날짜를 재검토하기 위해 ACDE 콜에만 의존하는 것에 대해 반대했습니다. "제가 정말 피하고 싶은 것은 날짜를 확정하기 위해 또다시 모든 핵심 개발자와 통화해야 하는 것입니다."라고 말하며 "이제 세폴리아를 시작할 수 있습니다."라고 말하기 위해 또다시 모든 핵심 개발자와 통화해야 하는 것이 싫습니다."라고 그는 덧붙였습니다. 이제 실제로 세폴리아 구현을 시작하려면 2주를 기다려야 합니다.

모든 당사자를 달래기 위해 Geth 개발자 Guillaume Ballet은 세폴리아 하드포크의 잠정 날짜를 두 가지로 설정하여 Goerli 하드포크의 결과가 긍정적이면 개발자들은 한 날짜를 고수하고, Goerli 하드포크의 결과가 부정적이면 다른 날짜를 사용할 수 있습니다. 그러나 라이트클라이언트와 디트리히스는 개발자가 세폴리아 하드포크의 새로운 타임라인을 설정하기 전에 Goerli의 버그와 이슈의 특성을 평가해야 하기 때문에 이 아이디어에 반대하고 있습니다.

그런데 이더리움 재단의 테스트 팀에서 "Danceratopz"라는 화면명을 사용하는 익명의 개발자가 개발자들이 Goerli 테스트 네트워크의 블롭 만료 문제 평가를 마칠 때까지 Sepolia 업그레이드를 기다릴 수 있는지 물었습니다. 블롭 만료란 은 약 2주 후에 이더리움 상태에서 블롭 데이터가 제거되는 것을 의미합니다.

라이트하우스의 션과 베수 팀의 저스틴 플로렌타인은 모두 메인넷에서 덴쿤을 활성화하기 전에 세 개의 테스트넷 중 하나에서 블롭 만료를 평가하는 것에 찬성했습니다. 플로렌타인은 테스트넷에서 블롭 만료를 기다리는 것도 도움이 될 것이라고 강조했습니다. 플로렌타인은 테스트 네트워크에서 블롭이 만료될 때까지 기다리는 것이 레이어 2 롤업 프로토콜 팀과 애플리케이션 개발자들이 덴쿤 업그레이드를 준비하는 데에도 도움이 될 것이라고 강조했습니다. 라이트하우스의 Sean은 Goerli에서 블롭이 만료되는 것을 지켜볼 필요는 없지만, 개발자와 레이어 2 팀이 세폴리아에서 전체 블롭 수명 주기를 거칠 수 있도록 세폴리아와 홀스키 간의 테스트 기간을 연장해야 할 이유가 될 수 있다고 말했습니다. 컨퍼런스 콜에 참석한 다른 개발자들은 Sean의 제안에 명시적으로 동의하지 않았습니다.

대신, 라이트클라이언트는 컨퍼런스 콜에 참여한 개발자들에게 1월 30일에 베이코가 제안한 일정과 일주일 후인 2월 7일에 홀스키가 제안한 일정에 따라 세폴리아를 업그레이드할 의향이 있는지 물었고, 개발자들은 더 이상의 이견이 없었기 때문에 이 일정을 고수할 의향이 있는지 물었습니다. 라이트클라이언트는 개발자들이 원래 일정을 고수할 것이라고 말했고, 포투즈는 줌 채팅에서 세폴리아 테스트넷과 홀스키 테스트넷을 일주일 일찍 업그레이드하는 대신 2월 7일에 모두 업그레이드하고 싶다고 썼습니다. 통화 후 디스코드 메시지에서 라이트클라이언트는 덴쿤의 테스트넷 일정이 현재로서는 변함이 없음을 재확인했습니다.

프라하/일렉트라

다음으로 개발자들은 덴쿤 이후 다음 업그레이드에 어떤 우선순위를 부여해야 하는지 논의했습니다. 일렉트라)에 우선순위를 두어야 할 EIP에 대해 논의했는데, 마리우스 반 데르 비덴은 개발자들이 다른 EIP보다 프라하/일렉트라의 머클 트리 업그레이드를 완료하는 데 집중해야 한다고 말하며, 이 견해에 두 가지 주의 사항을 추가했는데, 첫 번째는 머클 트리의 준비 상태입니다. ACDE #177에서 논의된 바와 같이, 개발자들은 메르켈 트리 구현의 세부 사항과 하드포크 업그레이드에 대한 준비 상태를 자세히 알아보기 위해 전용 ACDE 컨퍼런스 콜을 계획하고 있습니다.

반 데르 비덴이 언급한 두 번째 주의사항은 EL의 업그레이드를 합의 레이어(CL)에서 분리할 수 있다는 점으로, 반 데르 비덴은 CL에 "우선순위가 높고 매우 긴급한" EIP가 있어 EL의 머클 트리 업그레이드보다 빠르게 구현해야 할 수 있다고 언급했습니다. 구현. "저는 합의 계층 사람들이 이러한 [긴급한] 변화를 하드포크할 필요가 있는지, EL의 개입 없이 할 수 있는지, 아니면 EL의 개입이 필요하지만 어쨌든 공동 하드포크를 해야 하는지, 아니면 더 작은 하드포크로도 살 수 있는지를 논의하는 것이 중요하다고 생각합니다." 반 데르 비덴은 "따라서 머클 트리는 확실히 최우선 순위이며 최우선 순위이며, 이 두 가지를 모두 염두에 두고 추진해야 합니다."라고 말했습니다.

이더넷 재단의 연구원 안스가르 디트리히스는 Zoom 채팅방에서 프라하/일렉트라 업그레이드를 머클 트리에 집중하는 것에 "강력히 반대한다"며, 머클 트리에 필요한 코드 변경의 복잡성을 고려할 때 다음과 같은 이유로 반대한다고 밝혔습니다. 복잡성을 고려할 때, 이는 2025년까지 업그레이드가 지연될 가능성이 높다는 것을 의미하기 때문입니다."라고 말했습니다.Nethermind 클라이언트 개발자 Lukasz Rozmej는 Dietrichs의 의견에 동의했습니다."내 경험에 따르면 상태 재설계는 매우 어렵고 시간이 오래 걸린다는 것을 알게되었습니다."라고 Rozmej는 덧붙여 "머클 트리가 매우 훌륭하다고 생각하지만 큰 진전을 이루고 있다고 생각하지만, 머클에만 집중한다면 다음 하드포크는 적어도 1년 이상 걸릴 것이라고 생각합니다. 그래서 저는 각 팀이 머클에 집중하는 동안 몇 가지 작은 하드포크에 집중하고 적절한 리소스, 작업량, 인력을 해당 주제에 할당하는 것이 좋겠다고 제안하고 싶습니다."

머클에 집중

프라하/일렉트라가 머클에 집중해야 할지 아니면 머클보다 더 빨리 출시될 소규모 코드 변경에 우선순위를 둘지에 대한 의견이 엇갈리고 있습니다. 발레는 자신의 의견으로는 "마이너 포크 같은 것은 없다"며 개발자들이 머클을 구현하기 전에 더 오래 기다릴수록 이더리움 상태 업데이트를 구현하기가 더 어려워질 것이라고 강조했습니다.Nethermind 클라이언트 개발자이기도 한 토마스 스탄작(Tomasz K. Stańczak)은 야심찬 접근 방식을 제안하며, 프라하/일렉트라에 포함된 것보다 작은 코드 변경에 집중하자고 제안했습니다. /팀의 역량을 활용하고 일 년 동안 가장 큰 도전 과제를 해결할 수 있다는 것을 증명해야 합니다. 메르켈 총리가 3월까지 팀에게 점점 더 많은 어려움이 산적해 있다는 것을 보여주면 사람들은 다시 의문을 제기하고 '메르켈 퇴진'을 말할 수 있습니다. 하지만 우리는 꽤 많은 다른 EIP를 계속 포함할 것이라고 스탄차크는 말하며, 프라하/엘렉트르가 메르켈 외에 포함할 수 있는 다른 중요한 EIP로 서약, 재약정, 계정 추상화 등을 꼽았습니다.

CL 업그레이드에 집중

EL(실행 레이어)과 CL(합의 레이어) 업그레이드 분리 문제에 대해 포투즈는 프라하/. 일렉트라는 CL만 변경하는 단 하나의 EIP 제안을 가지고 있습니다. "유일한 변경 사항은 인증 인덱스 위원회(......)를 제거하는 것입니다. 그리고 다른 모든 변경 사항, 심지어 Max EB와 같이 CL 전용으로 보이는 변경 사항도 EL에 대한 다른 변경 사항에 따라 달라집니다. 따라서 순수한 CL 포크는 일어나지 않을 것 같습니다. 적어도 올해는 그럴 것 같지 않고 내년에도 그럴 것 같지 않습니다. 순수한 CL 제안이 충분하지 않기 때문입니다."라고 포투즈는 말합니다.

그럼에도 불구하고 안스가 디트리히스는 EL 고객 팀이 쉽게 구현할 수 있는 EL에 약간의 변경만 필요한 CL 중심 업그레이드인 일부 EIP가 있다고 말했습니다. 이러한 EIP는 여전히 EL과 CL이 하드 포크를 조율해야 하며, 디트리히스는 CL 측에서는 데이터 가용성 샘플링(DAS)이 EIP 4844 이후 가장 중요한 코드 변경이라고 생각한다고 덧붙였습니다. 디트리히스와 라이트클라이언트 사이에는 DAS를 구현하기 위해 하드 포크를 해야 하는지에 대해 약간의 이견이 있습니다.

EOF 및 기타 EIP 따라잡기

Ethernet 재단의 입실론 팀에서 "Rodiazet"이라는 화면명을 가진 익명의 개발자가 일하고 있습니다. 이더넷 가상 머신(EVM)에서 작동합니다. 배경 설명을 덧붙이자면, EOF는 EVM Object Format의 약자로, 처음에 칸쿤/데넵 업그레이드에 포함될 것으로 고려되었던 EVM의 개선 사항입니다.

머클 외에도 개발자들은 EIP 5920(PAY 옵코드), EIP 2537(BLS12-381 커브 연산 사전 컴파일) 등 여러 가지 다른 EIP를 고려할 것을 제안했습니다. 프라하/일렉트라 후보 EIP의 전체 목록은 이더넷에서 확인할 수 있습니다. 업그레이드 메타 스레드에서 확인할 수 있습니다. 대부분의 개발자들은 칸쿤/데넵 회의 이후 어느 정도 머클의 우선순위를 정하는 데 찬성하고 있지만, 2024년에 더 빠르고 쉽게 구현할 수 있는 소규모 EIP보다 프라하/일렉트라에 머클을 어느 정도 우선순위로 둬야 하는지는 불분명합니다. 컨퍼런스 콜에서 프라하/일렉트라에 대한 최종 결정을 내릴 필요가 없다고 강조했습니다. 그는 다가오는 ACDE 컨퍼런스 콜에서 이 주제를 계속 논의할 것을 제안했습니다.

그런 다음 개발자들은 프라하/일렉트라 주제에서 아직 논의되지 않은 EIP에 대해 빠르게 이야기했는데, 여기에는 다음과 같은 EIP가 포함되나 이에 국한되지 않습니다.

EIP- 7002: 경영진 계층 트리거 가능 종료

EIP-7549: 인증 외부로 위원회 색인 이동

EIP-3074: AUTH 및 AUTHCALL 옵코드

EIP-6110: 체인 내 검증자 예치금 제공

EIP-6110. ">EIP-6913: SETCODE 명령

EIP-7377: 트랜잭션 마이그레이션

< EIP-4444: 클라이언트에서 바인딩 히스토리 데이터 실행

EIP-6404: SSZ 트랜잭션 루트

EIP-6465: SSZ 출금 루트

EIP-6466: SSZ 영수증 루트

< strong>EIP-7212: 미리 컴파일된 secp256r1에 대한 커브 지원

위 EIP에 대한 자세한 개요는 YouTube에 게시된 전체 통화 녹취를 참조하세요.

EIP 7587 공식화

마지막으로, 이더리움 재단 펠로우 칼 비크하이젠은 EIP 7587에 대한 논의를 다시 한 번 살펴봤습니다. 레이어 2 프로토콜에서 사용할 수 있도록 미리 컴파일된 주소 세트를 보존할 것입니다. 비크후이젠은 개발자들에게 향후 이더마인드 거버넌스 프로세스에 대한 사양을 생성하는 유익한 EIP를 공식화하는 최선의 방법을 물었고, 이더마인드 개발자 아마드 비타르는 EIP를 EIP 1 문서에 통합할 것을 제안했습니다. 라이트클라이언트는 이더마인드 매지션 웹사이트에서 이 주제에 대해 더 자세히 논의하고 다음 ACDE 콜에서 필요에 따라 이 주제를 다시 다룰 것을 제안합니다.