저자: 크리스틴 김, Galaxy, 편집: 5 바트, Golden Finance
2024년 9월 12일, 이더넷 프로토콜 개발자들은 196차 올 코어 개발자 임원(ACDE) 컨퍼런스 콜을 위해 Zoom을 통해 화상으로 만났습니다. 이번 주에는 이더넷 재단(EF)의 프로토콜 지원 책임자인 팀 베이코가 이 통화를 주최했습니다. ACDE 통화는 개발자들이 이더넷 이그제큐티브 레이어(EL)의 변경 사항을 논의하고 조율하는 격주 단위 회의 시리즈입니다.
196번 ACDE에서는 개발자들이 Pectra Devnet 3 출시에 대한 업데이트를 공유하고 향후 개발 네트워크에 구현될 다양한 Pectra 코드 변경 사항에 대해 논의했습니다. 개발자들은 내년 2월까지 더 빠른 일정으로 Devnet 3의 코드 변경 사항을 릴리스할 수 있도록 업그레이드를 두 부분으로 나누는 방안에 대해 진지한 논의를 진행했습니다. 개발자들은 다음 ACD 컨퍼런스 콜에서 이에 대한 최종 결정을 내리기로 합의했습니다. 마지막으로 "pk910"이라는 스크린네임의 EF 개발자 운영 엔지니어가 이더넷 공용 테스트 네트워크 GitHub 저장소를 정리하고 사용하기 쉽도록 재구성하는 작업에 대한 업데이트를 공유했습니다.
펙트라 데브넷 3
파리토시 자얀티 EF 개발자 운영 엔지니어가 펙트라 데브넷 3의 출시를 발표했습니다. 데브넷은 9월 11일 수요일에 출시되었습니다. 여기에는 EIP 7251의 유효성 검사기 병합에 대한 수정 사항과 EIP 7702의 업데이트된 사양이 포함되어 있습니다. 지금까지 데브넷 3에 대한 테스트 결과, EIP 7251과 EIP 7702 모두 예상대로 작동하는 것으로 보입니다. jayanthi는 이더마인드와 이더리움JS 클라이언트에서 몇 가지 문제가 발견되었으며, 두 클라이언트 팀이 이를 해결하기 위해 노력 중이라고 언급하며, 데브넷 3 릴리스에 EIP 7702가 포함되어 있으므로, EIP 7702를 출시하는 것이 가장 좋다고 덧붙였습니다. 데브넷 3이 출시되면 지갑 개발자들이 구현을 테스트하고 피드백을 제공하는 것이 가장 좋을 것입니다. 테스트넷 이더리움 요청 탭을 포함하여 펙트라 데브넷 3에 대한 모든 정보는 이 사이트에서 확인할 수 있습니다.
펙트라 사양 업데이트
Geth 개발자 Felix Lange가 Pectra에서 EL 트리거 요청의 인코딩에 대한 변경을 제안했습니다. 그 배경으로, 펙트라는 EL의 스마트 컨트랙트가 CL에서 검증자 인출 및 병합을 시작할 수 있도록 할 것입니다. 지난 ACD 컨퍼런스 콜에서 랭은 EL 클라이언트가 이러한 요청을 파싱하는 데 필요한 작업량을 줄이기 위한 제안을 공유했습니다. 지난주 통화 이후, Lange는 다음 네 가지 EIP의 코딩을 업데이트하기 위해 EL 클라이언트 팀이 해야 할 작업과 권장 사항을 공식화했습니다.
개발자들은 대체로 랑게의 제안에 동의했습니다. 그러나 "Dustin"이라는 스크린네임을 사용하는 한 Nimbus 개발자는 이 제안이 "무의미하게 유연하다"고 생각하며 향후 EL 직렬화 형식의 변경과 호환되지 않는다고 생각합니다. 그는 또한 EL 클라이언트의 요청 순서와 EL이 CL에 잘못된 요청을 제출할 때 CL 클라이언트의 동작을 명시적으로 규제하기 위한 추가 사양이 필요하다고 강조했습니다. Lange는 요청 순서를 지정하기 위해 엔진 API에 더 많은 텍스트를 추가하는 데 동의했습니다. 또한 CL 클라이언트가 EL 클라이언트의 유효하지 않은 요청을 감지했을 때 CL 클라이언트의 동작에 대한 더 깊은 고려가 필요하다는 데 더스틴의 의견에 동의했습니다.
이더넷 재단의 연구원 피터 밀러는 현재 사양에 따른 CL 클라이언트의 논리적 동작에 따라 CL 클라이언트는 올바른 방식으로 주문되지 않은 EL의 블록을 거부해야 한다고 언급했습니다. 또한 EL이 CL에 공유한 목록에 유효하지 않은 요청이 있는 경우 CL은 목록의 모든 유효한 요청을 처리하고 유효하지 않은 요청은 무시해야 합니다. 더스틴은 밀러의 의견에 동의하며 개발자들이 이 동작을 적절한 문서에 명시할 것을 제안했고 베이코는 개발자들이 랭의 제안에서 문제를 해결하기 위해 노력하여 다음 ACD 호출이 이루어질 때 까지 이 문제를 해결해야 한다고 말했죠. 베이코는 개발자들이 랑게의 제안에 있는 문제를 해결하기 위해 노력해야 하며 다음 ACD 요청이 있기 전에 완료해야 한다고 말했습니다.
이후, Erigon 개발자 Andrew Ashikhmin은 EOA 계정 코드를 설정하는 EIP 7702에 대한 업데이트를 제안했습니다. 그는 EIP에 지정된 유효성 검사가 이전 EIP에 지정된 유효성 검사와 일치하지 않는다고 지적했습니다. Geth 개발자 매트 가넷(일명 "라이트클라이언트")은 일관성 문제를 해결하고 EIP 7702의 유효성 검사를 간소화할 수 있는 대안이 있다고 말했습니다. 개발자들은 대부분 라이트클라이언트 제안을 확정하고 이를 펙트라 데브넷 4에 추가하는 것에 찬성했습니다.
다음 펙트라 관련 논의는 EIP 2537에 따른 BLS 사전 컴파일에 대한 가격 책정에 관한 것이었습니다. Geth 개발자 Jared Wasinger는 자신의 벤치마킹 분석에 따라 BLS 사전 컴파일의 가격을 현재보다 두 배로 책정해야 한다고 말했습니다. 현재 비용은 멀티스레드 실행을 기준으로 책정되어 있는데, 이는 다른 프리컴파일의 가격을 책정할 때 적용되는 기준이 아닙니다. 따라서 와싱어는 싱글 스레드 실행을 사용한 분석을 바탕으로 EIP 2537에서 운영되는 할인 테이블을 변경할 것을 제안했고, Nethermind 팀은 다른 고객 팀도 EIP에 대한 자체 벤치마킹 분석을 쉽게 수행할 수 있도록 도구를 개발 중이라고 보고했습니다. 베이코는 팀이 자체적으로 BLS 프리컴파일을 벤치마킹하고 향후 2주 내에 이러한 작업의 가격을 재조정하기 위한 아이디어를 제시할 것을 제안했습니다.
펙트라 EIP 추가
개발자들은 펙트라 업그레이드를 위해 새로운 EIP를 추가하는 주제에 대해 논의하기 시작했습니다. 토론을 시작할 때 베이코는 "이미 펙트라에는 많은 수의 EIP가 있습니다. EIP의 수로만 보면 이미 지금까지 가장 큰 포크입니다."라고 경고했습니다. 통화 전에 개발자들이 공유한 의견을 바탕으로 베이코는 EIP 7742(EL과 CL의 블롭 수 분리)가 아직 업그레이드에 포함될 것으로 고려되고 있는 EIP 목록 중 가장 논란이 적은 것이 분명하다고 말했습니다.
EF의 연구원 알렉스 스톡스는 펙트라를 두 개의 작은 하드 포크로 분리하자는 아이디어를 다시 제기했습니다. "저는 이것이 매우 큰 포크라는 것에 모두가 동의한다고 생각합니다. 따라서 자연스럽게 두 개로 나누는 것이 좋습니다. 일반적으로 포크가 작을수록 덜 위험합니다. 특히 펙트라는 현재 많은 교차 계층 EIP를 보유하고 있어 테스트, 보안, 검토 부담이 가중되고 있습니다."라고 스톡스는 말했습니다. 이전 컨퍼런스 콜에서도 이 아이디어를 제기했던 자얀티는 여전히 이 아이디어를 지지한다고 말했습니다. "주된 이유는 현재 우리는 많은 EIP를 보유하고 있고 스택의 많은 계층을 건드리는 경향이 있으며, 더 많이 추가할수록 한 사람이 모든 변경 사항을 전체적으로 보기가 어렵기 때문입니다."라고 Jayanthi는 말했습니다.
스톡스는 현재 펙트라 EIP를 두 가지로 분할하는 방법에 대해 현재 개발 네트워크에서 실행 중인 모든 EIP를 사용하여 펙트라의 첫 번째 부분을 릴리스한 다음 PeerDAS, EOF 및 기타 몇 가지 추가 EIP를 사용하여 펙트라의 두 번째 부분을 릴리스할 것을 제안합니다. 개발자들은 이렇게 하면 내년 2월까지 펙트라의 첫 번째 부분을 출시할 수 있을 것이라고 확신하고 있습니다. "6월에 전반부만 출시한다면 이번 포크는 실패할 것 같습니다."라고 EF 연구원 안스가르 디트리히스는 Zoom 채팅에서 말했습니다.
베이코는 포크에 찬성하지만, 개발자넷에서 EIP를 제거하면 클라이언트 팀의 업무가 늘어나고 메인넷에서 활성화하기 위해 코드 변경을 준비하는 기간이 단축되기는커녕 길어질 수 있다고 경고했습니다. 독립 이더넷 프로토콜 개발자인 단노 페린은 메인넷 활성화를 위해 가능한 한 빨리 데브넷 3에서 EIP를 개선한 다음, 데브넷 4 또는 5에서 PeerDAS와 EOF를 Pectra EIP로 이전하는 작업을 병행할 것을 제안합니다. 사실 펙트라 이후의 업그레이드에서 Devnet 4 또는 5는 Devnet 0이 될 것이며, 개발자들은 그 이름을 어떻게 지을지 불확실합니다.
이전 컨퍼런스 콜에서 개발자들은 펙트라 후사카의 이름을 따서 업그레이드 이름을 짓는 데 동의했지만, 이 업그레이드는 버클 전환을 위해 유보하는 데도 동의했습니다. 이때 페린은 개발자들에게 코드 변경 사항이 메인넷 활성화에 사용될 준비가 되었다는 확신이 들 때까지 업그레이드를 미리 예약하지 말라고 조언했습니다. 이는 버클 전환 노력을 주도해 왔으며 버클 전환이 "오래 전에" 준비되었다고 주장해 온 Geth 개발자 기욤 발레의 분노를 불러일으켰습니다. 베이코는 긴장을 완화하기 위해 펙트라를 둘로 나눈 목적은 궁극적으로 펙트라 코드 변경 사항을 더 빠른 일정에 공개하여 이후 버클 전환을 위한 길을 닦는 데 도움이 되기 위해서였다고 말했습니다.
그러나 펙트라 업그레이드의 두 번째 부분은 더 많은 EIP가 추가됨에 따라 규모가 커질 수 있으므로 현재 펙트라 EIP 목록을 동시에 릴리스할 때보다 더 오래 걸릴 수 있는 위험이 있습니다. Nethermind 개발자 Ben Adams는 업그레이드가 두 부분으로 나뉠 경우 Pectra의 테스트 프로세스가 어떻게 작동할지 의문을 제기했습니다. 이러한 결정은 이더리움의 다음 업그레이드 범위를 완전히 바꿀 수 있기 때문에 베이코는 개발자들에게 일주일 동안 이 아이디어를 검토할 시간을 가질 것을 제안했습니다. 그는 개발자들에게 다음 주 목요일 전체 핵심 개발자 컨센서스 콜에서 이 문제에 대한 최종 결정을 내릴 준비를 해달라고 요청했습니다.
네트워크 구성 구조 조정
마지막으로, EF DevOps 엔지니어 "pk910"은 이더넷 퍼블릭 테스트 네트워크 GitHub 저장소를 정리하고 사용하기 쉽도록 재구성하는 작업에 대한 업데이트를 공유했습니다. 그는 클라이언트 팀에 메인 이더넷 네트워크와 테스트 네트워크 모두의 노드 구성을 확인하고 누락된 정보를 적절한 리포지토리에 추가해 달라고 요청했습니다.
JinseFinance
Weiliang
Alex
Kikyo
Bitcoinworld
Catherine
cryptopotato
Beincrypto
decrypt
Others