Ethereum Consensus Layer Call #99 Writeup

https://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

2022년 12월 1일, 이더리움 개발자들이 모여99번째 컨센서스 레이어(CL) 전화. 이더리움 재단의 Danny Ryan이 의장을 맡은 CL 통화는 이더리움 개발자들이 이더리움 프로토콜에 대한 변경 사항을 논의하고 조정하는 두 개의 격주 회의 시리즈 중 하나입니다. 이번 주 개발자들은 지난 주 ACD(All Core Developers) 통화에서 내린 결정을 재확인했습니다. 즉, 개발자들은 상하이 이후 별도의 업그레이드에서 활성화될 가능성이 있는 proto-danksharding(EIP 4844) 작업과 별도로 이더리움의 다음 업그레이드인 상하이에 대한 스테이킹된 ETH 인출을 활성화하는 작업에 동의했습니다. 개발자들은 또한 이더리움의 컨센서스 레이어 사양과 관련된 수많은 연구 주제와 이니셔티브에 대해 논의했습니다. 마지막으로 통화가 끝날 무렵 개발자들은 2020년 12월 1일에 출시된 이더리움 비콘 체인의 2주년을 축하했습니다.

스테이킹된 ETH 인출 및 EIP 4844

통화를 시작하기 위해 Danny Ryan은 ACD 통화 #150에서 CL 클라이언트 팀이 상하이에 대한 스테이킹된 ETH 인출에만 집중하는 것에 대해 합의한 논의를 반복했습니다. “Consensus Layer 팀이 분명히 밝힌 것은 EIP 4844가 [스테이킹된 ETH] 인출과 거의 동일한 준비 상태에 있지 않으며 이들을 결합하면 인출이 상당히 지연될 것이라고 믿는다는 것입니다. 우리는 그것들을 연결하지 않을 것입니다. 우리는 현재 형태로 Capella에 대해 전력을 다해 작업할 것입니다.”라고 Ryan이 통화에서 말했습니다. Capella는 핵심 개발자가 스테이킹된 ETH 인출을 위한 코드 변경을 테스트하는 전용 테스트 네트워크의 이름입니다.

이더리움 재단의 데브옵스 엔지니어인 Barnabas Busa는 스테이킹된 ETH 인출을 가능하게 하는 진행 상황에 대한 업데이트를 제공했습니다. Busa는 인출을 테스트하는 두 개의 다중 클라이언트 개발자 네트워크가 있다고 언급했습니다. 하나는 병합 전 환경을 모방하고 다른 하나는 병합 후 환경을 모방합니다. 이러한 devnet 중 어느 것도 현재 모든 EL 및 CL 클라이언트를 지원하지 않습니다. 병합 후 환경에서 인출을 테스트하는 최신 테스트는 Prysm, Lighthouse 및 Teku CL 클라이언트와 Geth 및 Nethermind EL 클라이언트를 지원합니다. Nethermind(EL) 및 Besu(EL)와 같은 다른 클라이언트의 구현이 준비되면 개발자는 인출을 위해 수명이 더 긴 다중 클라이언트 테스트넷을 가동할 것입니다.

그런 다음 Ethereum Foundation의 연구원인 Alex Stokes는 제한된 스윕을 구현하는 풀 요청에 대한 짧은 업데이트를 제공했습니다. 요컨대, 이것은 부분 및 전체 인출을 위해 전체 유효성 검사기 세트를 스캔해야 하는 프로토콜이 필요한 엣지 케이스 시나리오를 방지하기 위한 메커니즘입니다. Stokes 제안은 스캔을 다음으로 제한합니다.최대 1,024개의 검증자 . Stokes의 제안에 대한 이의는 없었으며 개발자는 다음 주 말까지 제한된 스윕을 중심으로 더 많은 인출 테스트 케이스를 진행하기로 동의했습니다.

EIP 4844에 대한 개발은 상하이로 가는 개발 작업과 스테이킹된 ETH 출금과는 별도로 진행될 것이지만 개발자들은 여전히 proto-danksharding 구현과 관련된 일부 공개 토론 항목에 대해 논의했습니다. Lighthouse(CL) 클라이언트를 구축하는 소프트웨어 엔지니어 Sigma Prime인 Sean Anderson은 네트워크가 BLOB 동기화를 처리하는 방법에 대한 열린 질문이 있다고 언급했습니다. 블롭은 EIP 4844에 도입될 새로운 유형의 트랜잭션으로 레이어 2 롤업에서 이더리움의 기본 레이어로 트랜잭션 데이터를 독점적으로 커밋합니다. Ryan은 Blob 동기화에 대한 엣지 케이스에 대한 추가 논의를 다음과 같이 할 것을 권장했습니다.오픈 GitHub 문제.

Ethereum Foundation의 생태계 담당자인 Trent Van Epps는 EIP 4844 구현에 필요한 신뢰할 수 있는 설정 행사의 진행 상황에 대한 업데이트를 제공했습니다. EIP 4844에서 사용될 보안 코드를 생성하도록 설계된 행사는 공개 기부 기간에 대한 준비가 거의 완료되었습니다. Van Epps는 이번 행사가 8,000명에서 10,000명 사이의 기부금을 모아 암호화폐 업계에서 가장 큰 행사 중 하나가 되기를 희망한다고 말했습니다. 행사를 위한 공익기여 기간은 약 2개월이며 12월 중으로 시작될 예정입니다. 자세한 내용은 다음을 참조하십시오.이 웹사이트 가입이 Twitter Spaces 세션 2022년 12월 2일.

연구 토론

개발자는 Ethereum CL 사양의 잠재적인 최적화 및 변경과 관련된 몇 가지 토론 항목을 검토했습니다. 첫째, Sigma Prime의 공동 설립자인 Adrian Manning은 두 가지 제안을 강조했습니다. 둘 다 이전 버전과 호환되므로 구현하기 위해 시스템 전체의 하드 포크 업그레이드가 필요하지 않습니다. 첫 번째 상세한여기 Ethereum의 스테이킹 노드 간의 피어 검색을 개선하는 것을 목표로 합니다. 두 번째는 IPv6으로 알려진 최신 인터넷 통신 프로토콜을 실행하는 CL 노드에 대한 지원을 활성화합니다. 후자의 토론 항목은 지난 5월 Sigma Prime 팀에서 제기했습니다. 이전 CL 통화의 통화 메모를 찾을 수 있습니다.여기 .

체크포인트 동기화는 신뢰할 수 있는 노드에서 최신 블록 상태를 가져와서 비콘 체인에 연결된 새 노드가 체인의 헤드와 빠르게 동기화되도록 하는 작업을 말합니다. Checkpointz는 신뢰할 수 있는 노드가 체크포인트 동기화 엔드포인트를 쉽게 노출할 수 있도록 하기 위해 Ethereum Foundation DevOps 팀이 구축한 도구입니다. 회의에서 ConsenSys의 수석 연구원인 Mikhail Kalinin은 Checkpointz가 노드의 중앙 장애 지점이 되는 것에 대한 우려가 있다고 설명하고 지적했습니다.몇 가지 제안 Checkpointz에서 다른 도구로의 의존도를 다양화할 수 있습니다.

그런 다음 DVT(분산 유효성 검사기 기술) 솔루션을 구축하는 회사인 Obol Technologies의 공동 설립자인 Oisin Kyne은 집계 의무의 유효성 검사기 할당 문제를 강조했습니다. Kyne은 임무가 분산된 검증자 세트에 의해 실행되도록 설계되지 않았다고 설명했습니다. 따라서 그는 분산 유효성 검사기의 운영을 더 잘 지원하기 위해 CL 클라이언트를 위한 두 개의 새로운 끝점을 제안했습니다. Kynes의 제안에 대한 추가 정보여기 DVT에 대한 높은 수준의 배경여기 .

마지막으로 Kalinin은 Ethereum Engine API 사양에 대해 두 가지 질문을 제기했습니다. 첫 번째 항목은 EL 클라이언트에서 지원하는 기능을 검색하기 위한 오래된 메서드인 "engine_getCapabilities .” 개발자는 이 제안에 대한 피드백을 GitHub에서 비동기식으로 제공하는 데 동의했습니다. Kalinin의 두 번째 질문은 엔진 API 사양 문서에 사용할 구조에 관한 것이었습니다. 접근 방식 중 하나는 포크를 통해 엔진 API에 대한 변경 사항을 문서화합니다. 즉, 시스템 수준의 하드 포크 업그레이드를 의미합니다. 다른 구조 문서는 Engine API 기능에 따라 변경됩니다. 각 접근 방식의 장단점에 대해 자세히 설명합니다.여기 . 통화 중 어떤 개발자도 어느 쪽에도 강한 편향을 가지고 있지 않았지만 Ryan은 자신이 포크 접근 방식이 더 편하다고 언급했고 Kalinin은 기능적 접근 방식을 사용하는 전문가가 강력하다고 생각한다고 언급했습니다.

기타 항목

개발자들은 GitHub에 대한 토론을 검토하기로 동의했습니다.engine_getCapabilities 상하이에 앞서 엔진 API 변경 사항을 문서화하기 위한 구조에 대해 더 생각해 보십시오. 통화를 끝내기 전에 독립적인 이더리움 개발자인 Micah Zoltu는 웹사이트 뒤에 있는 데이터에 대해 간단한 질문을 했습니다.clientdiversity.org . Zoltu는 웹 사이트가 두 가지 다른 소스에서 데이터를 가져오며 이로 인해 매우 다른 결과가 나온다고 설명했습니다. Ryan은 이러한 방법 중 하나가 스테이킹된 ETH에 의한 클라이언트 분포를 계산한다고 응답했습니다. 다른 하나는 노드와 피어를 식별하는 크롤러를 사용하여 클라이언트 분포에 대한 데이터를 기록합니다. Ryan이 아는 한, 노드 크롤러가 수집한 데이터는 정확하지 않으며 완벽하지는 않지만 블록 인쇄 및 스테이킹된 ETH 배포에 의존하는 방법이 훨씬 더 안정적입니다.

Nimbus(CL) 클라이언트를 구축하고 있는 Status의 연구 개발 책임자인 "Arnetheduck"으로도 알려진 Jacek Sieka는 그의 팀이 새로운 클라이언트 릴리스를 추진했다고 언급했습니다. 이 릴리스는 공식적으로 Nimbus 클라이언트를 베타에서 프로덕션 준비 상태로 전환합니다. 이 릴리스의 개선 사항에 대한 자세한 내용은 찾을 수 있습니다.여기 . 통화를 종료하기 전에 Ryan은 2022년 12월 15일의 다음 CL 통화가 올해의 마지막 통화가 될 것이라고 언급합니다. 개발자는 새해 1월 언젠가 통화를 재개할 것입니다.