원제: "Ethereum All Core Developers Consensus Call #135 Writeup"
편집자 주: Ethereum All Core Developers Consensus Call(ACDC)은 주로 합의를 논의하고 조정하기 위해 2주마다 개최됩니다. Ethereum 합의 계층(CL)이 변경되었습니다. 이번 컨퍼런스 콜은 135회 ACDC 컨퍼런스 콜로 주로 Pectra Devnet 1, PeerDAS Devnet 1 및 Simple Serialize(SSZ) Ethereum Improvement Proposals(EIP)의 테스트 네트워크 준비에 중점을 두고 있습니다.
개발자들은 소프트웨어 패키지 유지 관리, EIP 포함 프로세스 및 새로운 이더리움 합의 계층 업그레이드 이름 지정에 대해 심도 있는 논의를 했습니다. 또한 세션에서는 Electra 사양에 따른 구현 진행 상황, Ethereum 노드가 데이터를 처리하고 검증하는 방법에 대한 PeerDAS 네트워크 변경의 영향, 증가하는 blob 가스 제한과 관련된 복잡한 엔지니어링 문제에 대해 다루었습니다.
갤럭시디지털 연구담당 크리스틴 김 부사장은 이번 회의의 핵심 내용을 자세히 기록했고, BlockBeasts는 원문을 다음과 같이 편집했습니다.
2024년 6월 13일, 이더리움 개발자들이 All Core Developers Consensus에 참여하기 위해 Zoom에 모였습니다. (ACDC) 135번 회의에 전화하세요. ACDC 통화는 Ethereum Foundation 연구원 Alex Stokes가 주최하는 격주 시리즈로, 개발자들은 Ethereum Consensus Layer(CL, 비콘 체인이라고도 함)에 대한 변경 사항을 논의하고 조정합니다. 이번 주에 개발자들은 Pectra Devnet 1, PeerDAS Devnet 1 및 SSZ(Simple Serialize) EIP(Ethereum Improvement Proposals)를 위한 세 번째 전용 테스트 네트워크에 대한 준비에 대해 논의했습니다.
개발자들은 두 가지 공지로 회의를 시작했습니다. Ethereum Foundation DevOps 엔지니어 Parithosh Jayanthi는 Ethereum Foundation DevOps(EF DevOps)에서 근무하는 엔지니어 그룹인 ethPandaOps 팀이 이더리움 패키지 Kurtosis 모듈의 유지 관리 및 개발을 맡을 것이라고 말했습니다. 이 패키지는 과거 개발자들이 다양한 클라이언트 구현을 모니터링하고 테스트하기 위한 Grafana 데이터 대시보드와 같은 Ethereum 테스트 네트워크 및 관련 도구를 시작하는 데 사용되었습니다. Kurtosis 기술 팀에서 ethPandaOps 팀으로 이 패키지를 마이그레이션하면 일부 링크가 더 이상 Kurtosis 팀이 아닌 ethPandaOps 팀이 관리하는 GitHub 저장소로 리디렉션되므로 사용자에게 영향을 미칠 수 있습니다. Jayanthi는 사용자에게 소프트웨어 링크를 업데이트하고 ethPandaOps 팀의 새 릴리스를 주시하라고 조언합니다.
두 번째 발표는 이더리움 재단의 프로토콜 지원 책임자인 Tim Beiko가 했습니다. Beiko는 Ethereum 업그레이드에 EIP를 단계적으로 포함하는 새로운 프로세스를 도입하기 위해 노력하고 있다고 말했습니다. 그는 "포함 제안", "포함 고려" 및 "포함 예정" 레이블을 정의하는 EIP 초안을 만들었습니다. 그는 개발자들이 문서를 검토하고 피드백을 제공해주기를 바랍니다. 그는 다음 ACD 회의 전에 문서가 완성되기를 바랐습니다.
다음 주요 Electra 버전 v1.5.0-alpha.3의 코드 사양이 거의 완료되었습니다. 개발자들은 합의 사양 GitHub 저장소의 PR(풀 요청) #3768을 다음 버전에 병합하는 데 동의했습니다. 끌어오기 요청은 Nimbus 개발자 Etan Kissling이 작성했는데, 그는 데이터 직렬화 문제를 피하기 위해 "committee_bits" 필드를 데이터 중간이 아닌 "증명" 끝에 추가해야 한다고 지적했습니다. PR #3768 외에도 Stokes는 Electra 사양의 다음 주요 버전이 출시되기 전에 해결해야 할 다른 미해결 문제가 있는지 물었습니다. Jayanthi는 Zoom 채팅에서 실행 계층(EL)을 통해 트리거된 유효성 검사기 통합에 몇 가지 뛰어난 문제가 있다고 언급했습니다. Stokes는 회의 후 EL 트리거 검증인 통합 상태에 대한 후속 조치를 기록했습니다.
최신 Electra 사양의 구현 진행 상황과 관련하여 회의에 참석한 대부분의 CL(합의 계층) 클라이언트 팀은 v1.5.0-alpha 이후 1~2주 내에 테스트를 위한 새 버전을 준비할 수 있을 것이라고 밝혔습니다. .3이 확정되었습니다. 개발자들은 몇 주 안에 다음 Pectra 개발 네트워크인 Pectra Devnet 1의 시기를 재검토하기로 합의했습니다.
다음으로 개발자들은 PeerDAS 구현 과정에 대해 논의했습니다. PeerDAS는 Blob 트랜잭션을 통해 사용자가 제출한 대량의 임의 데이터를 처리하고 확인하는 노드의 능력을 향상시키는 Ethereum의 네트워크 개선 사항입니다. Stokes는 개발자가 개발 네트워크에서 PeerDAS에 대한 별도의 활성화 주기를 활성화하여 다른 Pectra EIP와 병행하여 PeerDAS를 개발하겠다는 지난 ACDC 회의의 결정을 회상했습니다.
Lodestar 개발자 Gajinder Singh은 PeerDAS에 대한 최근 브레이크아웃 세션의 논의를 바탕으로 개발자들이 Deneb 업그레이드와 다른 Pectra EIP와 별도의 개발 네트워크에서 PeerDAS를 활성화할 것이라고 말했습니다. Teku 개발자 Enrico Del Fante는 개발자가 끊임없이 변화하는 Pectra 코드 사양보다는 이전 Ethereum 업그레이드 Deneb에서 이미 확립된 안정적인 코드 사양에서 PeerDAS를 구축하는 것이 더 쉬울 것이라고 말했습니다. Jayanthi는 PeerDAS 구현을 다른 Pectra EIP 구현과 병합하면 테스트 중에, 특히 오류의 원인을 정확히 찾아내려고 할 때 복잡해질 수 있다는 점에 동의했습니다. 그는 두 워크플로를 별도로 유지한 다음 구현이 더욱 안정적이 되면 병합할 것을 제안했습니다. Stokes는 개발자가 약 한 달 안에 PeerDAS와 기타 Pectra EIP 구현을 병합하는 작업을 다시 검토할 수 있다고 동의했습니다.
PeerDAS Devnet 1 출시 주제와 관련하여 클라이언트 팀은 테스트넷 출시 준비 시기를 명확히 예측하지 못했습니다. 세션의 개별 추정치는 대략 2주에서 1개월까지였습니다. Stokes는 클라이언트 팀이 PeerDAS 구현 작업에 더 많은 시간을 할애할 수 있는 몇 주 후에 네트워크 개발 일정을 다시 검토할 것을 제안했습니다.
Beiko는 PeerDAS가 이더리움 코어 프로토콜의 변경이 아닌 네트워크 개선이지만 여전히 Pectra 업그레이드를 위한 메타-EIP에 코드 변경 사항이 포함되기를 원한다고 지적했습니다. Meta-EIP 문서는 이더리움 업그레이드에 포함된 모든 핵심 프로토콜 변경 사항을 나열하는 공개 문서입니다. Beiko는 PeerDAS가 Pectra의 "가장 큰 기능"이며 하드 포크 활성화가 필요하지 않지만 문서에 포함되어 개발자가 Pectra 메인넷 활성화에 맞춰 준비하는 것에 대해 진지하게 생각하고 있음을 보여주어야 한다고 지적했습니다. 이에 대해 이의가 없습니다.
PeerDAS는 노드가 Ethereum P2P 네트워크 계층을 통해 데이터를 처리하고 전파하는 방식을 변경합니다. 사용자, 특히 레이어 2 롤업이 이러한 변경 사항의 이점을 누리려면 개발자는 블록당 6개의 blob이라는 현재 제한을 더 높은 임계값으로 늘려야 합니다. 이렇게 하면 더 높은 blob(임의 데이터) 처리량을 허용할 수 있습니다. Blob 제한을 변경하려면 Ethereum 핵심 프로토콜을 변경해야 하며, 이번 주 컨퍼런스에서 개발자가 논의한 것처럼 단순히 프로토콜 스택의 상수 값을 조정하는 것보다 더 복잡한 엔지니어링 작업이 필요할 수 있습니다.
Stokes는 Blob 가스 제한을 변경할 때 실행 계층(EL)과 합의 계층(CL) 간의 종속성을 분리할 것을 제안했습니다. 현재 Blob 가스 한도를 변경하려면 EL 및 CL 프로토콜을 변경해야 합니다. Stokes는 개발자가 EL에서 하드 코딩된 블롭 가스 제한을 안전하게 제거하고 완전히 CL에 맡길 수 있도록 이러한 종속성을 깨는 방법을 제안했습니다. 이더리움 재단(EF) 연구원인 단크라드 파이스트(Dankrad Feist)는 EL과 CL 간의 종속성 문제 외에도 블록의 가스 계산에 있어 블롭 가스 한도 변경에 따른 연쇄 효과도 중요하다고 지적했습니다. 파이스트는 "가장 좋은 방법은 계산 방식을 바꾸는 것이다. 휘발유 계산이 EL에서 일어나는 버그인 것 같다. CL에도 있어야 하는데 지금은 바꾸기가 더 어렵다.... 쉽지 않다"고 말했다. "
개발자는 블롭 가스 제한 및 블록 내 가스 계산을 변경하는 가장 좋은 방법을 계속 조사하는 데 동의했습니다. 개발자들은 또한 Pectra에서 PeerDAS를 활성화하면 블롭 가스 한도가 증가하는지에 대한 논의를 계속하기로 합의했습니다. 개발자들은 변경 사항을 함께 출시해야 하는지 아니면 여러 하드 포크에 걸쳐 단계적으로 구현해야 하는지에 대해 의견이 분분합니다.
Jayanthi는 PeerDAS가 메인넷에서 활성화될 때까지 개발자가 PeerDAS의 성능을 알 수 없기 때문에 이러한 변경 사항을 통합하는 것은 "위험한" 결정이라고 말했습니다. Ethereum Foundation(EF) DevOps 엔지니어 Barnabas Busa는 Pectra 하드 포크의 범위가 이미 매우 크며 추가 코드 변경이 필요하지 않다고 덧붙였습니다. Busa는 "핵심은 우리가 이미 많은 EIP를 보유하고 있고 계속해서 더 추가하면 끝나지 않을 것 같다는 것입니다. 그래서 우리는 어딘가에 선을 긋고 거기서 끝나는 것입니다."라고 말했습니다. 다음 1년 반 동안의 테스트 동안 PeerDAS를 출시하고 blob 수를 늘리는 것은 불가능합니다. "
"Francesco"라는 화면 이름을 가진 개발자는 네트워크 변경으로 인해 blob 수가 증가하지 않을 것이라고 제안했습니다. PeerDAS는 "Pectra의 위험을 줄이기 위해" 제거될 수 있습니다. Francesco가 질문했습니다. "Blob 수를 늘리지 않으면 Pectra의 PeerDAS의 이점은 무엇입니까?"
PeerDAS 테스트의 어려움을 더 설명하기 위해 Jayanthi는 Ethereum에 Blob을 도입한 EIP 4844 테스트가 Blob을 완전히 시뮬레이션하지 못했다는 점을 지적했습니다. 이더리움 메인넷의 실제 성능과 영향에 대해 알아봅니다. Jayanthi는 다음과 같이 말했습니다: "문제는 네트워크 테스트가 매우 어렵다는 것입니다. 우리는 4844와 관련된 훌륭한 테스트를 많이 했지만 블롭은 테스트에서와 마찬가지로 메인넷에서 정확히 동일한 성능을 발휘하지 못했습니다. 우리는 더 약한 노드를 보았습니다. 질문. 타이밍 문제 등이 있기 때문에 PeerDAS가 작동하고 Blob 수를 늘리는 개발 네트워크에서 완벽한 상황을 시뮬레이션할 수 있지만 메인넷에는 실질적인 영향을 미치지 않습니다. 즉, 한꺼번에 하기보다는 차근차근 해야 한다고 생각하는 가장 큰 이유입니다.”
EF 연구원 Ansgar Dietrichs는 PeerDAS만으로는 이미 개발자가 blob 수에 대한 값을 선택하도록 요구하기 때문에 blob 수를 늘리는 것을 PeerDAS와 연결하는 것은 실수라고 말했습니다. 개발자는 이더리움 메인넷에서와 동일한 번호를 선택할 수 있지만 PeerDAS가 어떤 번호를 사용해야 하는지 결정해야 합니다. 동일한 번호를 선택한 유일한 이유는 개발자가 오류 발생 시 현재 Deneb 사양의 Blob 전파 메커니즘으로 폴백할 수 있도록 PeerDAS의 복잡성을 증가시켰기 때문입니다. Dietrichs는 복잡성 테스트에 대한 우려가 Pectra가 하나가 아닌 두 개의 하드 포크를 통해 활성화되어야 한다는 그의 견해를 더욱 강화한다고 덧붙였습니다. 그렇다고 PeerDAS가 블롭 수 변경과 분리되어야 한다고 생각하는 것은 아닙니다.
Kissling은 SSZ 관련 EIP 3개에 대한 진행 상황 업데이트를 공유했습니다. 그는 이러한 EIP의 구현이 Teku, Grandine 및 Lighthouse를 포함한 여러 클라이언트에서 이미 진행 중이라고 언급했습니다. 개발자들은 이러한 SSZ EIP에 대한 개발 네트워크 타임라인에 대해 논의하기 시작할 수 있으며 다음 ACDC 회의에서 이를 Pectra 업그레이드 범위에 포함시킬 수도 있다고 그는 말했습니다.
Electra 이후의 Ethereum Consensus Layer(CL) 업그레이드 이름을 논의하는 Ethereum Magicians 게시물이 있습니다. 개발자들은 프라하 이후 EL(Executive Layer) 업그레이드 이름을 오사카로 결정했습니다. 후보 CL 업그레이드 이름은 Fulu, Felis, Formosa 및 Funi입니다. 이 이름은 모두 "F"로 시작하는 주요 별 명명 규칙을 따르며 비콘 체인의 6번째 네트워크 전체 업그레이드에 적합합니다. Stokes는 통화 중 개발자들에게 Magicians 스레드의 주제에 대해 의견을 묻도록 요청했습니다.
위 내용은 이더리움 핵심 개발자들의 최근 회의 요약: PeerDAS 활성화, 블롭 가스 한도 증가의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
