원제: "Ethereum All Core Developers Execution Call #189 Writeup" 원저자: Christine Kim 원문 편집: Luccy, BlockBeats 편집자 주: Ethereum All Core Developers Execution Call(ACDE)은 주로 토론과 조정을 위해 2주마다 개최됩니다. 이더리움 실행 계층(EL). 이번 회의는 ACDE의 189번째 컨퍼런스 콜로, 개발자들은 EOF 및 EIP 7702를 포함한 변경 사항, Pectra 범위 개선, Verkle 전환 측면 준비 등 Pectra 업그레이드와 관련된 몇 가지 중요한 문제에 대해 논의했습니다. 회의에서는 또한 EOF 및 기타 Pectra EIP가 패키지되는 방법과 이러한 코드 변경 사항을 테스트하는 방법에 대해 논의했습니다. 또한 ACD 컨퍼런스 콜 주제 논의 빈도 조정, 새로운 EIP 라벨 제안 등 이더리움 네트워크 업그레이드 프로세스를 개선하기 위한 몇 가지 제안이 도입되었습니다. EIP 4444와 Portal Network의 통합 진행 상황도 언급되었습니다. 갤럭시디지털의 크리스틴 김 부사장은 이번 회의의 핵심 내용을 구체적으로 기록해 블록비스트가 원문을 다음과 같이 정리했다.

2024년 6월 6일, 이더리움 개발자들은 ACDE(All Core Developers Execution) 통화 #189 회의에 참여하기 위해 Zoom에 모였습니다. ACDE 컨퍼런스 콜은 이더리움 재단의 프로토콜 지원 책임자인 Tim Beiko가 주최하는 격주 일련의 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주 개발자들은 Pectra 업그레이드에 EOF 및 EIP 7702를 포함하는 데 동의했습니다. 이러한 코드 변경으로 인한 다중 클라이언트 테스트 업그레이드의 지연을 피하기 위해 개발자는PeerDAS를 테스트할 계획인 것처럼 다른 EIP와 다른 활성화 주기로 개발 후 네트워크에서 EOF를 활성화하는 데 동의했습니다. 또한 Verkle을 준비하기 위해 오사카 업그레이드에서 EIP 158을 폐기하는 방법과 Portal Network와의 통합을 통해 EIP 4444를 구현하기 위한 다음 단계에 대해서도 논의했습니다. 마지막으로 Beiko와 EF 개발자 운영(DevOps) 팀은 Ethereum 업그레이드 계획을 위한 거버넌스 프로세스 및 커뮤니케이션 채널에 대한 최신 업데이트를 공유했습니다.

펙트라의 범위

이번 주 ACD 회의를 앞두고 다양한 EL 클라이언트 팀과 EF DevOps 팀이 Pectra의 범위에 대한 생각을 공유했습니다.

회의 전에 공유된 의견에 따르면 대다수의 클라이언트 팀이 Pectra에 EOF를 포함하는 것을 지지하는 것이 분명합니다. EOF에 강력하게 반대하는 유일한 클라이언트 팀은 Geth입니다. Geth 개발자인 Guillaume Ballet은 다음과 같이 말했습니다. "기다릴수록 Verkle이 전환하는 데 시간이 더 오래 걸릴까 걱정됩니다. EOF가 정말 그렇게 긴급한가요? 그렇게 생각하지 않습니다. 저는 EOF 출시에 대한 여러 주장을 읽었습니다. 프라하 "읽을수록 EOF가 필요하다는 것을 실제로 증명하는 것이 없다는 것을 더 많이 깨달았습니다." 몇몇 개발자들이 이의를 제기했습니다.

"Kamil Sliwak"이라는 개발자는 Ethereum 스마트 계약 프로그래밍 언어 Solidity의 컴파일러와 상호 작용하는 사용자의 관점에서 EOF가 "큰 개선"이 될 것이라고 말했습니다. Reth 개발자 Dragan Rakita는 EOF가 Verkle 전환을 크게 지연시킬 것이라고 생각하는 것은 솔직하지 못할 것이라고 덧붙였습니다. Rakita는 "우리는 전환 시간을 10~20% 연장하는 것에 대해 이야기하고 있습니다. EOF는 상태를 증가시키지 않으며 추가 부분 포크를 출시하기 위한 추가 3개월은 Verkle을 크게 지연시키지 않을 것입니다"라고 말했습니다. EOF가 무엇인지, EVM(Ethereum Virtual Machine)을 어떻게 개선할지에 대한 자세한 내용을 보려면 Infinite Jungle 팟캐스트의 이번 에피소드를 들어보세요.

Beiko는 개발자들에게 EOF를 다른 Pectra의 EIP와 번들로 묶는 것을 선호하는지, 아니면 Pectra의 EIP를 두 개의 하드 포크로 분할하는 것을 선호하는지 물었습니다. Erigon 개발자 Andrew Ashikhmin은 개발자가 Pectra의 모든 EIP를 함께 출시하거나 Verkle 전환이 완료될 때까지 EOF를 연기해야 ​​한다고 말했습니다. “내가 마지막으로 원하는 것은 Pectra와 Verkle 사이의 포크가 EOF를 출시하는 것입니다. 저는 State가 성장하고 있다는 Guillaume의 의견에 동의하기 때문에 Verkle이 EOF보다 더 중요하다고 생각합니다. 따라서 이것이 가능한 최악의 결과입니다. "라고 Ashikhmin이 말했습니다. Beiko는 하나의 클라이언트 릴리스에서 EOF를 포함한 모든 Pectra의 EIP를 릴리스할 것을 권장합니다. 그러나 그는 테스트 목적으로 개발자가 개발 네트워크를 사용하여 이러한 코드 변경 사항을 단계적으로 구현하는 것을 고려해야 한다고 말했습니다. Beiko는 "개발 네트워크를 다중 클라이언트 테스트 측면에서 우선순위를 정하는 방법으로 사용하고 EOF로 인해 작업이 오랫동안 지연되는 것을 확인하면 분할하기로 결정할 수 있습니다"라고 Beiko는 말했습니다.

EOF를 Pectra에 통합하는 방법에 대한 논의 중에 Geth 개발자는 Zoom 채팅과 회의 전반에 걸쳐 EOF가 업그레이드에 포함되어야 하는지에 대해 계속해서 의구심을 표명했습니다. EOF에 대한 Geth 팀의 지속적인 논쟁에 대해 Reth 개발자 George Konstantinopoulos는 다음과 같이 말했습니다. "그냥 해보자. 대화가 어디로 가는지 약간 혼란스럽습니다. 우리는 Verkle 전환을 며칠 연장해도 괜찮습니다. 상태가 쇠퇴하고 있다는 것은 혼란스러운 주장이고, 좋은 기능이라고 말하는 앱이 많이 있는데, 대부분의 사람들이 이를 지지하는데 왜 우리는 그것을 하지 않는 것을 고려해야 합니까?”

Beiko는 EOF가 Pectra에 포함되어야 하지만 개발 네트워크의 단계에서 테스트되어야 한다는 점에 동의하고 반복했습니다. 즉, 클라이언트 팀은 이미 Devnet 0에 구현된 Devnet 1 EIP에서 테스트해야 함을 의미합니다. 그런 다음 향후 개발 네트워크에 테스트를 위해 EOF를 추가합니다. 이 전략은 클라이언트 팀이 동일한 일정에 Pectra의 EIP 일부를 출시하는 데 집중하고 다중 클라이언트 개발 네트워크에서 계속 발전할 수 있도록 보장합니다. 이더리움 재단(EF)의 DevOps 엔지니어인 Mario Vega는 2개월 이내에 EOF의 실행 계층(EL) 사양 테스트가 준비될 것으로 예상한다고 말했습니다. EF DevOps 엔지니어 Parithosh Jayanthi는 EOF가 Pectra의 다른 실행 계층(EL) EIP와 별도로 테스트될 수 있다고 말했습니다. 그러나 그는 Pectra의 합의 계층(CL) EIP 간의 상호 의존성과 이러한 코드 변경 사항을 테스트하는 복잡성에 대해 우려하고 있습니다.

Vyper 컴파일러 개발자 Charles Cooper는 재진입 공격에 대한 보호를 저렴하고 일반적으로 만들기 위해 제안한 코드 변경만큼 EOF가 긴급하지 않다고 말했습니다. Beiko는 Cooper에게 EOF에 대한 폭넓은 합의는 분명하지만 클라이언트 팀이 재진입 공격과 관련된 코드 변경 사항을 더 추가할 만큼 충분한 에너지를 갖고 있는지 여부는 불분명하다고 상기시켰습니다. Beiko는 "EOF를 추진하면 다른 작업을 수행할 에너지가 거의 남지 않을 것이 분명하다고 생각합니다. 이는 이미 현재까지 가장 큰 포크가 될 것"이라고 말했습니다.

EOF를 포함하는 것 외에도 개발자는 EIP 3074를 대체하는 EIP 7702에도 동의했습니다. 개발자들은 여전히 ​​별도의 그룹 회의 에서 EIP 7702 사양을 논의하고 있습니다. Beiko는 EIP 7702에 대해 EOF와 유사한 접근 방식을 권장합니다. "포크에 포함하고 싶지만 사양이 만족스럽지 않으면 Devnet 1 또는 2의 일부로 만들지 말고 다음 달에 사양을 정리하여 더 나은 철회를 할 수 있도록 하세요. 지금 제안된 것보다 메커니즘이 너무 크지 않은 EIP가 나중에 프로세스에 추가될 것입니다."라고 Beiko는 말했습니다. Geth 개발자 "Lightclient"는 클라이언트 팀이 준비가 되었다면 가능한 한 빨리 EIP 7702를 구현해야 한다고 말했습니다. 차기 비상 Pectra 개발 네트워크인 Devnet 1에 EIP 7702를 포함하는 데에는 이의가 없습니다.

펙트라 사양

나중에 Teku 개발자 Mikhail Kalinin은 기존 Pectra EIP 사양에 대한 일부 업데이트를 공유했습니다. 첫 번째는 실행 계층(EL) 블록에서 직접 처리하지 않고 사이드카 메커니즘을 통해 합의 계층(CL) 요청 트리거를 처리하는 제안입니다. Prysm 개발자 "Potuz"는 이 전략이 향후 코드 변경에 필요한 논리, 즉 명확한 제안자-작성자 분리(ePBS)를 깨뜨릴 것이라고 지적했습니다. "비콘 블록은 이미 존재하는 페이로드에 의존해서는 안 됩니다. 따라서 출금이든 입금이든 비콘 블록이 페이로드에 의존하는 것을 원하지 않습니다. 그렇게 하면 ePBS의 흐름이 중단될 수 있기 때문입니다."라고 Potuz는 말합니다. 말했다. 이 문제로 인해 Kalinin은 권장 사항을 철회하고 GitHub의 끌어오기 요청을 종료하는 데 동의했습니다.

Kalinin은 Pectra의 EL 및 엔진 API 사양에 대한 몇 가지 다른 변경 사항을 공유했으며, 그 중 하나는 EIP 7251에서 EL 트리거 병합을 활성화하여 MAX_EFFECTIVE_Balance를 증가시키는 것입니다. Beiko는 개발자가 다음 ACD 호출 전에 이러한 변경 사항을 검토하여 Devnet 1에서 마무리하고 테스트할 준비를 할 것을 권장합니다.

버클 준비

Verkle 전환에 대한 그의 작업을 바탕으로 Ballet은 EIP 158이 더 이상 사용되지 않는 opcode SELFDESTRUCT와 유사한 문제를 일으킬 것이라고 말했습니다. 전환 후 네트워크 문제를 방지하기 위해 Ballet에서는 Pectra 업그레이드에서 EIP 158을 비활성화할 것을 권장합니다. 그러나 그는 EIP 7702의 구현이 Pectra에서 미세 조정되면 EIP 158의 폐기가 지연되고 Verkle 전환과 동시에 이루어질 수 있다고 지적했습니다. Beiko는 Guillaume에게 EIP 158을 비활성화하기 위한 제안 초안 작성을 시작할 것을 제안했습니다.

기록 만료

Pectra 및 Verkle 외에도 이더리움 프로토콜 개발자들은 역사적인 만료 날짜인 EIP 4444를 작업하고 있습니다. EIP 4444 계획 및 요약 문서 에 명시된 바와 같이, 이번 코드 변경 이유는 "블록 히스토리는 노드에서 많은 공간을 차지하며, 일단 블록이 완료되면 제한된 비합의에만 필요하기 때문입니다. 중요한 사용 사례입니다." 문서 에는 "블록 기록은 더 이상 전체 노드에 의해 영구적으로 저장되지 않습니다. 일정 시간이 지나면 노드에서 제거되며 이를 필요로 하는 엔터티는 이를 쿼리해야 합니다. 다른 곳." 포털 네트워크는 노드가 이더리움 기록 데이터를 쿼리하는 데 사용되는 대안적인 분산형 네트워크입니다.

Merriam은 EL 계정 팀에 Portal Network와의 통합 지원을 제공하려는 그의 팀의 의지를 반복했습니다. 어떠한 지원도 없다면 통합을 개발하는 데 약 6개월이 걸릴 것이라고 그는 말했습니다. 그러나 그는 지침과 긴밀한 협력을 통해 향후 2개월 이내에 EIP 4444에서 의미 있는 진전이 이루어질 수 있다고 낙관하고 있습니다. Jayanthi는 Portal Network 사양에 대한 보안 감사가 있었는지 물었습니다. 메리암은 아니라고 대답했습니다. 이더리움 재단 연구원인 Ansgar Dietrichs는 고객 팀이 기존 클라이언트와의 통합 번들링, 새 클라이언트 구축 또는 통합 전혀 수행하지 않음을 포함하여 네트워크와 인터페이스하는 방법을 스스로 결정할 수 있는지 물었습니다. Merriam은 이 결정이 고객 팀의 재량에 따른 것임을 확인합니다.

Merriam은 전화 통화에서 EL 계정 팀에게 EIP 4444의 진행 상황과 의도에 대해 물었습니다. Nethermind 개발자 Łukasz Rozmej는 "전반적으로 우선순위입니다. 어제 Portal 팀과 회의도 했습니다. 문제는 우선순위가 너무 많다는 것입니다. 때로는 모든 것을 올바르게 균형을 맞추는 것이 어렵습니다. 예를 들어 하드포크가 있지만 Nethermind가 작업을 진행하고 우선순위를 정할 것입니다." Besu 개발자 Matt Nelson도 같은 생각을 한다고 말했습니다. Geth 개발자 Guillaume Ballet은 그의 팀이 Portal Network 통합에 대해 논의하지 않았다고 말했습니다.

ACD 프로세스 개선

ACD 프로세스 개선 다음으로 Beiko는 Ethereum 네트워크 업그레이드 프로세스를 개선하기 위한 몇 가지 제안을 공유했습니다. 그는 먼저 계정 팀이 아직 자세히 검토하지 않은 주제에 대한 ACD 통화에 대한 토론 빈도를 줄일 것을 권장했습니다. Beiko는 개발자가 전문적인 토론에 참여할 수 있도록 하기 전에 ACD 통화에서 검토할 수 있도록 이러한 주제를 플래그 지정하고 필요에 따라 후속 ACD 통화에서 이에 대해 더 자세히 논의할 것을 권장합니다.

Beiko가 제안한 두 번째 제안은 일반적으로 하드포크에 포함되도록 고려되는 EIP(Ethereum Improvement Proposals)에 첨부되는 "포함 고려"(CFI) 상태와 관련됩니다. 이 상태는 역사적으로 EIP가 하드포크에 포함될 가능성이 더 높은지를 나타내는 유용한 지표가 아니었습니다. Beiko는 개발자가 하드 포크에 포함될 가능성이 높은 EIP와 그렇지 않은 EIP를 더 잘 구분할 수 있도록 "PFI(Pending for Inclusion)"라는 또 다른 레이블을 만들 것을 제안했습니다.

Ethereum Foundation 연구원인 Ansgar Dietrichs는 Zoom 채팅에서 EIP에 대한 새 레이블을 만드는 것은 "잘못된 방향"이며 CFI 레이블이 "완전히 쓸모 없게" 될 뿐이라고 썼습니다. Beiko는 개발자들이 GitHub 및 EthMagicians에서 네트워크 업그레이드 프로세스 개선에 대해 계속 논의할 수 있다고 말했습니다.

또한 Ethereum Foundation의 DevOps 엔지니어인 Mario Vega는 테스트 관련 업데이트를 위한 새로운 Discord 하위 채널을 만들고 싶다고 말했습니다. Vega는 현재 Ethereum R&D Discord에서 테스트 릴리스 정보가 여러 채널에 분산되어 있다고 말했습니다. 그러나 그는 새로운 포럼이 고객 팀이 Ethereum Foundation의 DevOps 팀으로부터 테스트 업데이트를 얻을 수 있는 "원스톱" 참조가 되기를 바라고 있습니다. 그는 회계팀에 이에 대한 피드백을 요청했습니다.

마지막으로 Beiko는 개발자들에게 앞으로 며칠 동안 두 개의 그룹 회의가 예정되어 있음을 상기시켰습니다. 하나는 6월 7일에 ePBS에서, 다른 하나는 6월 11일에 PeerDAS에서 열릴 예정입니다.