이더리움 핵심 개발자 최신 회의 요약: Pectra 업그레이드에 EOF와 EIP-7702 추가
이번 회의에서 개발자들은 Pectra 업그레이드와 관련된 몇 가지 중요한 주제에 대해 논의했습니다. 여기에는 EOF 및 EIP 7702를 포함한 변경 사항, Pectra 범위 개선, Verkle 전환 준비 등이 포함됩니다.원문 제목：《Ethereum All Core Developers Execution Call #189 Writeup》
저자：Christine Kim
편집：Luccy，BlockBeats
편집자 주：
이더리움 모든 핵심 개발자 실행 전화(ACDE)는 2주마다 열리며, 주로 이더리움 실행 레이어(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번은 ACDE 제 189차 전화 회의로, 개발자들은 Pectra 업그레이드에서 EOF 및 EIP 7702를 포함한 변경 사항, Pectra 범위 개선, Verkle 전환 준비 등 몇 가지 중요한 주제를 논의했습니다.
회의에서는 또한 EOF 및 기타 Pectra EIPs를 패키징하는 방법과 이러한 코드 변경 사항을 테스트하는 방법에 대해서도 논의했습니다. 또한 ACD 전화 회의 주제 논의 빈도 조정 및 새로운 EIP 태그 제안 등 이더리움 네트워크 업그레이드 프로세스를 개선하기 위한 몇 가지 제안이 소개되었습니다. EIP 4444 및 Portal Network 통합 진행 상황에 대해서도 언급되었습니다.
Galaxy Digital 연구 부사장 Christine Kim은 이번 회의의 주요 사항을 자세히 기록하였으며, BlockBeats는 원문을 다음과 같이 편집하였습니다:
2024년 6월 6일, 이더리움 개발자들은 Zoom에서 All Core Developers Execution (ACDE) call #189 회의에 참석했습니다. ACDE 전화 회의는 이더리움 재단 프로토콜 지원 책임자 Tim Beiko가 주재하는 2주마다 열리는 시리즈 회의로, 개발자들은 이더리움 실행 레이어(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주, 개발자들은 EOF 및 EIP 7702를 Pectra 업그레이드에 포함시키기로 합의했습니다. 이러한 코드 변경으로 인한 다중 클라이언트 테스트 업그레이드 지연을 피하기 위해, 개발자들은 후속 개발 네트워크에서 EOF를 활성화하고, 다른 EIP와는 다른 활성화 주기 내에서 활성화할 가능성에 대해 동의했습니다. 그들은 또한 Osaka 업그레이드에서 EIP 158을 비활성화하여 Verkle을 준비하는 방법과 Portal Network와의 통합을 통해 EIP 4444의 다음 단계를 구현하는 방법에 대해 논의했습니다. 마지막으로, Beiko와 EF 개발자 운영(DevOps) 팀은 거버넌스 프로세스 및 이더리움 업그레이드 계획의 커뮤니케이션 채널에 대한 최신 업데이트를 공유했습니다.
Pectra의 범위
이번 주 ACD 회의 이전에, 각 EL 클라이언트 팀과 EF DevOps 팀은 Pectra 범위에 대한 그들의 의견을 공유했습니다.
회의 전 공유된 의견에 따르면, 대부분의 클라이언트 팀은 Pectra에 EOF를 포함하는 것을 지지하는 것으로 보입니다. EOF에 강력히 반대하는 클라이언트 팀은 Geth뿐입니다. Geth 개발자 Guillaume Ballet는 "우리가 기다릴수록 Verkle 전환에 필요한 시간이 더 길어질 것이라고 걱정합니다. EOF가 정말 그렇게 긴급한가요? 저는 그렇게 생각하지 않습니다. 저는 Prague에서 EOF를 발표하는 것에 대한 몇 가지 주장을 읽었습니다. 읽을수록 EOF가 필요하다는 것을 증명할 수 있는 것은 아무것도 없다는 것을 깨달았습니다."라고 말했습니다. 이에 대해 몇몇 개발자들은 반대 의견을 제시했습니다.
"Kamil Sliwak"이라는 개발자는 이더리움 스마트 계약 프로그래밍 언어 Solidity의 컴파일러와 상호작용하는 사용자 관점에서 EOF가 "거대한 개선"이 될 것이라고 말했습니다. Reth 개발자 Dragan Rakita는 EOF가 Verkle 전환을 상당히 지연시킬 것이라는 주장은 정직하지 않다고 덧붙였습니다. "우리는 10%에서 20%의 전환 시간 연장을 이야기하고 있습니다. EOF는 상태를 증가시키지 않으며, 추가적인 3개월 동안 추가적인 부분 분기를 발표하는 것은 Verkle을 상당히 지연시키지 않을 것입니다."라고 Rakita는 말했습니다. EOF가 무엇인지 및 그것이 이더리움 가상 머신(EVM)을 어떻게 개선할 것인지에 대한 더 많은 정보는 《무한 정글》 팟캐스트의 이 에피소드를 들어보시기 바랍니다.
Beiko는 개발자들에게 EOF를 다른 Pectra의 EIP와 함께 묶어서 발표하는 것이 좋을지, 아니면 Pectra의 EIP를 두 개의 하드 포크로 나누는 것이 좋을지 물었습니다. Erigon 개발자 Andrew Ashikhmin은 개발자들이 모든 Pectra의 EIP를 함께 발표하거나 Verkle 전환 이후까지 EOF를 연기해야 한다고 생각한다고 말했습니다. "제가 가장 원하지 않는 것은 Pectra와 Verkle 사이에 EOF를 발표하기 위해 분기를 하는 것입니다. 왜냐하면 저는 Guillaume의 의견에 동의하기 때문입니다. 상태가 증가하고 있으며, Verkle이 EOF보다 더 중요하다고 생각합니다. 그래서 제게는 이것이 최악의 결과입니다."라고 Ashikhmin은 말했습니다. Beiko는 모든 Pectra의 EIP, 포함하여 EOF를 하나의 클라이언트 버전으로 발표할 것을 제안했습니다. 그러나 테스트 목적을 위해, 그는 개발자들이 개발 네트워크를 사용하여 이러한 코드 변경 사항을 단계적으로 구현하는 것을 고려해야 한다고 말했습니다. "개발 네트워크를 다중 클라이언트 테스트에서 우선적으로 사용하는 방식으로 사용하고, 만약 EOF가 오랜 시간 동안 지연될 것 같다면, 우리는 그것을 분리할 수 있는 결정을 내릴 수 있습니다."라고 Beiko는 말했습니다.
EOF를 Pectra에 포함하는 방법에 대한 이러한 논의에서, Geth 개발자들은 Zoom 채팅과 전체 회의에서 EOF를 업그레이드에 포함해야 하는지에 대한 의문을 계속 표현했습니다. Geth 팀의 EOF에 대한 지속적인 논쟁에 대응하기 위해, Reth 개발자 George Konstantinopoulos는 "그냥 하자고요. 대화의 방향이 다소 혼란스럽습니다. 우리는 Verkle 전환을 며칠 연장하는 것에 개의치 않습니다. 데이터는 상태가 감소하고 있음을 보여주므로, 이는 혼란스러운 주장입니다. 그리고 당신은 이것이 좋은 기능이라고 말하는 많은 애플리케이션이 있습니다. 대다수가 지지를 표명했는데, 왜 우리는 하지 말아야 할지 고민해야 하나요? 이는 매우 혼란스럽습니다."라고 말했습니다.
Beiko는 이 의견에 동의하며 EOF가 Pectra에 포함되어야 한다고 재확인했지만, 개발 네트워크에서 단계적으로 테스트해야 한다고 말했습니다. 이는 클라이언트 팀이 Devnet 0에서 구현된 EIP를 Devnet 1에서 테스트하도록 해야 함을 의미합니다. 그런 다음, 향후 개발 네트워크에서 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에 대한 광범위한 합의가 명확하지만, 클라이언트 팀이 재진입 공격과 관련된 변경 사항과 같은 더 많은 코드 변경을 추가할 충분한 에너지가 있는지는 불확실하다고 상기시켰습니다. "우리가 EOF를 추진한다면, 다른 일을 할 에너지가 거의 없을 것이라는 것은 분명합니다. 이는 지금까지 가장 큰 분기가 될 것입니다."라고 Beiko는 말했습니다.
EOF를 포함하는 것 외에도, 개발자들은 EIP 7702를 EIP 3074의 대안으로 포함시키기로 합의했습니다. 개발자들은 여전히 개별 소그룹 회의에서 EIP 7702의 규격에 대해 논의하고 있습니다. Beiko는 EIP 7702에 대해 EOF와 유사한 접근 방식을 채택할 것을 제안했습니다. "저는 그것을 분기에 포함시키겠지만, 만약 우리가 규격에 대해 그리 만족하지 않는다면, Devnet 1 또는 2의 일부로 포함시키지 않고, 다음 한 달 동안 규격을 명확히 하여 현재 제안된 것보다 더 나은 철회 메커니즘을 갖추도록 하겠습니다. 이후 과정에서 그렇게 큰 EIP를 추가하겠습니다."라고 Beiko는 말했습니다. Geth 개발자 "Lightclient"는 클라이언트 팀이 준비가 되면 EIP 7702를 가능한 한 빨리 구현해야 한다고 말했습니다. 아무도 다음 긴급한 Pectra 개발 네트워크 Devnet 1에 EIP 7702를 포함하는 것에 반대하지 않았습니다.
Pectra 규격
이후, Teku 개발자 Mikhail Kalinin은 기존 Pectra EIP 규격의 몇 가지 업데이트를 공유했습니다. 첫 번째는 사이드카 메커니즘을 통해 합의 레이어(CL) 요청을 처리하자는 제안으로, 실행 레이어(EL) 블록에서 직접 처리하지 않도록 하는 것입니다. Prysm 개발자 "Potuz"는 이 전략이 미래 코드 변경에 필요한 논리를 파괴할 것이라고 지적했습니다. 즉, 명확한 제안자 빌더 분리(ePBS)가 필요합니다. "신호 블록은 유효한 페이로드가 이미 존재하는 것에 의존해서는 안 됩니다. 따라서 인출이든 예치이든, 신호 블록이 유효한 페이로드의 내용에 의존하는 것을 원하지 않습니다. 이는 ePBS의 프로세스를 파괴할 것입니다."라고 Potuz는 말했습니다. 이 문제로 인해 Kalinin은 그의 제안을 철회하고 GitHub에서의 풀 리퀘스트를 닫기로 동의했습니다.
Kalinin은 Pectra의 EL 및 엔진 API 규격에 대한 다른 변경 사항 몇 가지를 공유했습니다. 그 중 하나는 EIP 7251 하에서 EL 트리거 병합을 활성화하여 MAXEFFECTIVEBalance를 증가시키는 것입니다. Beiko는 개발자들이 다음 ACD 전화 회의 전에 이러한 변경 사항을 검토하여 Devnet 1에서 테스트하기 전에 완료하고 준비할 수 있도록 할 것을 제안했습니다.
Verkle 준비
Verkle 전환을 위한 작업에 따라, Ballet는 EIP 158이 더 이상 사용되지 않는 연산 코드 SELFDESTRUCT와 유사한 문제를 초래할 것이라고 말했습니다. 전환 후 네트워크에서 복잡한 상황을 피하기 위해, Ballet는 Pectra 업그레이드에서 EIP 158을 비활성화할 것을 제안했습니다. 그러나 그는 Pectra에서 EIP 7702의 구현이 조정된다면 EIP 158의 비활성화가 지연될 수 있으며 Verkle 전환과 동시에 발생할 수 있다고 언급했습니다. Beiko는 Guillaume에게 EIP 158 비활성화 제안을 초안할 것을 제안했습니다.
역사 만료
Pectra와 Verkle 외에도, 이더리움 프로토콜 개발자들은 EIP 4444, 역사 만료에 대해 작업하고 있습니다. EIP 4444 계획 및 요약 문서에 설명된 바와 같이, 이러한 코드 변경을 수행하는 이유는 "블록 역사로 인해 노드가 많은 공간을 차지하며, 해당 블록이 완료되면 제한된 비합의 주요 용도로만 필요하기 때문입니다." 문서는 계속해서 설명합니다, "블록 역사는 더 이상 전체 노드에 의해 영구적으로 저장되지 않습니다. 일정 시간이 지나면 노드에서 삭제되며, 이를 필요로 하는 엔티티는 다른 곳에서 조회해야 합니다." Portal Network는 노드가 이더리움 역사 데이터를 조회하기 위한 대체 분산 네트워크입니다.
Merriam은 그의 팀이 EL 클라이언트 팀에 Portal Network와의 통합 지원을 제공할 의향이 있다고 재확인했습니다. 그는 지원이 없으면 통합 개발이 약 6개월이 걸릴 것이라고 말했습니다. 그러나 지침과 긴밀한 협력을 통해, 그는 향후 2개월 내에 EIP 4444에서 의미 있는 진전을 이룰 수 있을 것이라고 낙관적으로 생각하고 있습니다. Jayanthi는 Portal Network 규격에 대한 보안 감사가 이루어졌는지 질문했습니다. Merriam은 그렇지 않다고 답했습니다. 이더리움 재단 연구원 Ansgar Dietrichs는 클라이언트 팀이 네트워크와 인터페이스하는 방법을 스스로 결정할 수 있는지, 기존 클라이언트와 통합하거나 새로운 클라이언트를 구축하거나 아예 통합하지 않을 수 있는지를 질문했습니다. Merriam은 이 결정이 클라이언트 팀에 의해 이루어질 것이라고 확인했습니다.
Merriam은 전화 회의에서 EL 클라이언트 팀에 EIP 4444에 대한 그들의 진행 상황과 의도를 질문했습니다. Nethermind 개발자 Ł ukasz Rozmej는 "전반적으로 이는 우선 사항입니다. 우리는 어제 Portal 팀과 회의를 가졌습니다. 문제는 우선 사항이 너무 많다는 것입니다. 때때로 모든 것을 올바르게 균형 잡기가 어렵습니다. 따라서 하드 포크와 비교할 때 덜 긴급한 우선 사항이지만, Nethermind는 이를 처리할 것이며 우선적으로 다룰 것입니다."라고 말했습니다. Besu 개발자 Matt Nelson도 같은 의견을 표명했습니다. Geth 개발자 Guillaume Ballet는 그의 팀이 Portal Network 통합에 대해 아직 논의하지 않았다고 말했습니다.
ACD 프로세스 개선
ACD 프로세스 개선에 이어, Beiko는 이더리움 네트워크 업그레이드 프로세스를 개선하기 위한 몇 가지 제안을 공유했습니다. 그는 먼저 ACD 전화 회의에서 클라이언트 팀이 아직 자세히 검토하지 않은 주제에 대한 논의 빈도를 줄일 것을 제안했습니다. Beiko는 개발자들이 전문적인 논의를 할 수 있도록 허용하기 전에, ACD 전화 회의에서 이러한 주제를 검토를 위해 표시한 다음, 필요에 따라 후속 ACD 전화 회의에서 더 자세히 논의할 것을 제안했습니다.
Beiko가 제안한 두 번째 제안은 하드 포크에 포함될 가능성이 있는 이더리움 개선 제안(EIP)에 일반적으로 추가되는 "포함 고려"(CFI) 상태와 관련이 있습니다. 이 상태는 역사적으로 어떤 EIP가 하드 포크에 포함될 가능성이 더 높은지를 효과적으로 나타내지 않았습니다. Beiko는 개발자들이 어떤 EIP가 하드 포크에 포함될 가능성이 더 높은지를 더 잘 구분할 수 있도록 "예정 포함"(PFI)이라는 또 다른 태그를 만들 것을 제안했습니다.
이더리움 재단 연구원 Ansgar Dietrichs는 Zoom 채팅에서 EIP에 대한 새로운 태그를 만드는 것이 "잘못된 방향"이라고 언급하며, CFI 태그가 "완전히 쓸모없게" 될 것이라고 말했습니다. Beiko는 개발자들이 GitHub 및 EthMagicians에서 네트워크 업그레이드 프로세스를 개선하는 문제에 대해 계속 논의할 수 있다고 말했습니다.
또한, 이더리움 재단의 DevOps 엔지니어 Mario Vega는 테스트와 관련된 업데이트를 위해 새로운 Discord 하위 채널을 만들고 싶다고 밝혔습니다. Vega는 현재 이더리움 개발 Discord에서 테스트 릴리스 정보가 여러 채널에 분산되어 있다고 말했습니다. 그러나 그는 이 새로운 포럼이 클라이언트 팀이 이더리움 재단 DevOps 팀으로부터 테스트 업데이트를 얻는 "원스톱" 참조가 되기를 희망한다고 말했습니다. 그는 클라이언트 팀에게 이에 대한 피드백을 요청했습니다.
마지막으로, Beiko는 개발자들에게 다음 며칠 동안 두 번의 소그룹 회의가 예정되어 있다고 알렸습니다. 하나는 ePBS에 관한 것이며, 6월 7일에 열리고, 다른 하나는 PeerDAS에 관한 것이며, 6월 11일에 열립니다.
