작성자: Christine Kim
편집자: Luccy, BlockBeats
편집자 주: 이더리움 ACDC(All Core Developers Consensus Call)는 Ethereum Consensus Layer(CL) 구현을 논의하고 조정하기 위해 2주마다 개최됩니다. ) 변화. 이번 컨퍼런스 콜은 제134회 ACDC 컨퍼런스 콜에서 개발자들은 EIP 7549, EIP 7251, EIP 6110, EIP 7688 등을 포함한 여러 핵심 EIP의 구현 세부 사항과 기술적 과제에 대해 논의했습니다.
또한 개발자들은 Ethereum 네트워크의 롤업 지원 기능과 데이터 가용성 요구 사항을 크게 향상시킬 것으로 예상되는 데이터 가용성 샘플링 기술인 PeerDAS의 구현에 대해서도 심도 있게 논의했습니다. 회의에서는 업그레이드를 위해 Pectra를 두 개의 하드 포크로 분할하자는 제안이 이루어졌고, 활성화 시간과 서로 다른 EIP의 상호 의존성에 대한 문제가 논의되었습니다.
갤럭시디지털 연구담당 크리스틴 김 부사장은 이번 회의의 핵심 내용을 자세히 기록했고, BlockBeasts는 원문을 다음과 같이 편집했습니다.
2024년 5월 30일 이더리움 개발자들이 Zoom에 모여 All Core Developers Consensus에 참여했습니다. (ACDC) 통화 #134 회의. ACDC 통화는 개발자들이 Ethereum Consensus Layer(CL, 비콘 체인이라고도 함)에 대한 변경 사항을 논의하고 조정하는 Ethereum Foundation 연구원 Alex Stokes가 주최하는 격주 일련의 회의입니다. 이번 주에는 개발자들이 Pectra Devnet 0 출시 이후의 경험과 공개된 문제에 대해 논의합니다. 그들은 또한 PeerDAS 및 SSZ 컨테이너 코드 변경 사항을 포함하도록 Pectra 업그레이드 범위를 확장하는 가능성에 대해서도 논의했습니다.
Pectra가 Devnet 0에서 출시됨에 따라 클라이언트 팀은 하드 포크 활성화 중에 EIP 7549의 영향을 받는 검증 동작을 변경하지 않고 유지하는 데 동의했습니다. 이전 ACDC 회의에서 개발자는 EIP 7549의 영향으로 인해 포크 중에 잘못된 검증이 많이 발생하지 않도록 다양한 옵션을 고려했습니다. 업그레이드가 더 복잡해지는 것을 피하기 위해 클라이언트 팀은 포크 전후의 검증 동작을 변경하지 않고 다른 Pectra EIP와 동일한 에포크에서 EIP 7549를 활성화하기로 결정했습니다.
EIP 7251과 관련하여 개발자는 스테이킹된 ETH의 병합이 실행 계층(EL)에서 트리거되도록 허용해야 하는지 여부를 여전히 확신하지 못합니다. 이는 Lido와 같은 스테이킹 풀에 이상적인 기능이므로 스테이크 병합이 노드 운영자에 의존할 필요 없이 대신 스마트 계약을 통해 수행될 수 있습니다. Stokes는 EL 작업인지 CL 작업인지 결정하기 전에 몇 주 안에 검증인 스테이킹 병합을 구현하는 클라이언트의 진행 상황을 확인할 것을 권장했습니다.
그런 다음 개발자들은 EIP 6110에 따른 검증인 예금의 최종 확인과 관련하여 답변되지 않은 몇 가지 질문에 대해 논의했습니다. Teku 개발자 Mikhail Kalinin은 컨퍼런스 전에 GitHub 댓글에서 이러한 문제를 해결하기 위한 지침을 요약했습니다. Lighthouse 개발자 "sean"이 Engine API의 "GetPayloadBodies" 요청 버전 관리에 대한 질문을 제기했습니다. Stokes는 개발자가 GitHub의 문제에 대해 생성된 풀 요청에 의견을 게시할 것을 권장했습니다.
Nimbus 개발자 Etan Kissling은 EIP 7549 구현에 대한 작은 변경을 제안했습니다. "이것은 일반화된 인덱스의 안정성에 관한 것입니다. 컨테이너 중간에 새 필드를 추가하면 후속 필드에 새 인덱스가 할당되며, 이는 실행 수준(EL)에서 EIP 4788 기반 증명을 깨뜨립니다. 그리고 약간의 오해를 불러일으킬 수 있습니다... 따라서 두 가지 문제를 모두 피하기 위해 새 필드를 끝으로 옮기는 것이 좋습니다."라고 Kissling은 설명했습니다. 이번 변경에 대해서는 이의가 없었습니다. Stokes는 개발자가 GitHub에서 Kissling의 끌어오기 요청을 확인할 것을 권장합니다.
회의에서 제안된 EIP 7549의 또 다른 변경 사항은 EL 블록에 대한 추가 기능으로 EL에 의해 트리거되는 요청 및 기타 요청을 설계하는 것이었습니다. 이 변경 사항에 대해 Kalinin은 "내 생각에는 이것은 매우 좋은 설계 솔루션이며 EL을 단순화하고... 기본적으로 실행 계층 블록의 일반화된 요청에 대한 대안입니다."라고 말했습니다. 개발자들이 GitHub에서 제안을 검토할 수 있는 더 많은 시간을 가질 수 있도록 다음 CL 회의에서 다시 논의했습니다.
Pectra 업그레이드에 아직 공식적으로 포함되거나 제외되지 않은 합의 계층(CL) 중심 EIP가 있습니다. 이번 주 회의에서 개발자들은 EIP 7688과 PeerDAS를 Pectra에 추가할지 여부를 논의했습니다. EIP 7688은 EIP 7549의 증명 변경 사항에 대한 향후 호환성을 보장하기 위해 "StableContainer" SSZ 데이터 구조의 일부를 채택합니다. 배경 소개로 SSZ는 CL에서 사용하는 데이터 구조인데, 개발자들은 이를 실행 계층(EL)에서도 사용하고 싶어합니다. SSZ 전환에 대한 자세한 내용은 이전 회의록을 참조하세요. PeerDAS는 롤업 및 데이터 가용성 요구 사항을 지원하는 네트워크의 능력을 크게 향상시킬 것으로 예상되는 Ethereum의 데이터 가용성 샘플링 구현입니다. 실제로 PeerDAS는 검증자가 블록에 연결할 수 있는 Blob 트랜잭션 수를 블록당 3개에서 64개 이상으로 늘릴 것으로 예상됩니다.
Ethereum Foundation의 개발자 운영 엔지니어인 Barnabas Busa는 개발자들이 개발 네트워크에서 PeerDAS의 초기 버전을 출시했다고 말했습니다. Busa는 "많은 고객이 많은 문제를 발견했다고 생각하며 상당한 진전을 이루면 언제든지 새로운 개발 네트워크를 다시 시작할 수 있습니다"라고 말했습니다. Stokes는 개발자들에게 업그레이드 지연 없이 PeerDAS를 Pectra에 추가할 의향이 있는지 물었습니다.
"Nishant"라는 별명을 가진 개발자가 Pectra에서 PeerDAS 활성화와 다른 EIP 활성화를 분리하라는 제안을 부활시켰습니다. 이것이 가능하기는 하지만 "atd"라는 닉네임을 사용하는 또 다른 개발자는 개발자가 단기간에 이러한 업그레이드를 차례로 활성화할 계획이라면 사용자는 여전히 소프트웨어를 동시에 업그레이드해야 한다고 강조했습니다. atd는 다음과 같이 말했습니다. "다음 업그레이드 후 두 달 후에 포크를 수행하는 것은 조금 미친 것 같습니다. 클라이언트를 업그레이드하기 위해 모든 사람을 조정하려면 두 달 후에 모든 사람이 클라이언트를 업그레이드하도록 하고 싶지 않습니다. , 한 번의 릴리스 주기만으로는 충분하지 않습니다."
atd는 PeerDAS가 Pectra에 포함되고 논의된 EIP에서 가장 "흥미로운" 코드 변경이라고 덧붙였습니다. Stokes는 업그레이드 지연이 발생하더라도 PeerDAS를 Pectra에 포함시키기를 희망한다고 말했습니다. Grandine 클라이언트 개발자 Saulius Grigaitis는 PeerDAS를 위해 Pectra에서 EIP 7549 및 EIP 7688을 제거할 것을 제안했습니다. 이로 인해 EIP 7688의 구현 세부 사항에 대한 논의가 촉발되었습니다. 개발자들은 코드 변경에 동의하지 않았으며 제안은 다음 ACDC 회의에서 재검토될 것입니다.
PeerDAS 주제와 관련하여 개발자들은 Pectra를 두 개의 하드 포크로 분할하는 아이디어를 계속해서 고려하고 있습니다. Ethereum Foundation 개발자 옵션 엔지니어 Parithosh Jayanthi는 개발자가 Pectra를 두 개의 업그레이드로 분할할 경우 향후 Pectra Part 2에서 더 많은 EIP를 추가하지 않도록 주의해야 한다고 경고했습니다. Jayanthi는 다음과 같이 말했습니다. “한 가지 언급하고 싶은 점은 두 개의 포크로 분할하는 것을 고려할 때 다음 포크에 새로운 EIP를 추가하지 않도록 매우 조심해야 한다는 것입니다. 1년 또는 1년 반 전에 뭔가를 약속했다면, 우리는 항상 새로운 아이디어를 내놓고 우선순위가 바뀌기 때문입니다."
Lighthouse 개발이라는 두 가지 업그레이드 아이디어에 대해 계속 논의하세요. 저자 "sean"은 PeerDAS와 현재 Pectra EIP 목록 사이에 많은 상호 의존성을 예상하지 못했다고 말했습니다. 따라서 두 가지 작업을 별도로 수행할 수 있으며 나중에 개발자가 구현에 대한 자신감을 갖게 되면 쉽게 병합할 수 있습니다. Atd는 Pectra EIP, PeerDAS 및 EIP 7688을 별도로 개발하고 테스트한 후 병합하는 데 큰 위험이 없을 것이라고 주장하면서 이에 동의했습니다.
Busa는 Pectra EIP 및 PeerDAS를 계속 테스트할 것을 권장하지만, PeerDAS가 개발 및 테스트 네트워크에서 Pectra EIP보다 한 epoch 늦게 활성화되도록 코드 변경을 설계하는 것이 좋습니다. 그는 이것이 이미 Devnet 0에서 Pectra EIP 및 PeerDAS 테스트가 수행되는 방식이라고 언급했습니다. Busa는 "실제로 변경해야 할 사항은 없습니다."라고 말하면서 다른 Pectra EIP가 준비되어 있는데 PeerDAS가 준비되지 않은 경우 개발자는 업그레이드에서 해당 코드 변경 사항을 제거할 수 있다고 덧붙였습니다. 이는 PeerDAS의 다양한 활성화 시대가 클라이언트 팀의 작업에 어떤 영향을 미치는지에 대한 몇 가지 질문을 제기합니다. 결국 개발자들은 PeerDAS와 Pectra EIP를 계속 개발하기로 합의했지만 PeerDAS는 개발 네트워크와 테스트 네트워크에서 서로 다른 시대에 활성화된다는 것이 전제였습니다.
위에서 언급했듯이 개발자들은 EIP 7688이 Pectra에 포함될지 여부에 대한 논의를 다음 ACDC 회의까지 남겨두기로 합의했습니다.
위 내용은 이더리움 핵심 개발자들의 최신 회의 요약: Pectra 업그레이드는 두 개의 하드 포크로 나눌 수 있습니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
