이더리움 핵심 개발자들의 최신 회의 요약: EIP 3074 구현 준비, 롤업 로드맵

원제: "Ethereum All Core Developers Execution Call #186 Writeup"

원작자: Christine Kim

원본: Frost, BlockBeats

편집자 주:

ACDE(All Core Ethereum Developers Consensus Call)는 EL(Ethereum Execution Layer)에 대한 변경 사항을 논의하고 조정하기 위해 2주마다 개최됩니다. ACDE의 186차 전화 회의에서 개발자들은 Pectra Devnet 0 및 EIP 3074 구현 준비에 대해 논의했습니다. 그들은 Pectra Devnet 0을 준비하는 다양한 고객 팀의 진행 상황을 자세히 설명하고 EIP 3074 사양에 대한 제안된 변경 사항 및 관련 테스트 진행 상황에 대해 논의했습니다.

또한 이 문서에서는 Pectra 업그레이드에 포함될 수 있는 기타 코드 변경 사항에 대한 논의, 이더리움 EIP 프로세스 변경 사항이 L2/RIP 프로세스에 의해 어떻게 영향을 받는지에 대한 논의 등 다른 중요한 주제도 다룹니다. . 갤럭시 디지털의 크리스틴 김(Christine Kim) 리서치 부사장은 이번 회의의 핵심 사항을 자세히 기록했으며, BlockBeasts는 원문을 다음과 같이 편집했습니다.

2024년 4월 25일 이더리움 개발자들이 Zoom에 모여 All Core Developers에 참여했습니다. 실행( ACDE ) 호출 # 186 회의. ACDE 컨퍼런스 콜은 이더리움 재단의 프로토콜 지원 책임자인 Tim Beiko가 주최하는 격주 일련의 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주에 개발자들은 Pectra Devnet 0 및 EIP 3074 구현 준비에 대해 논의했습니다. 그들은 또한 Pectra 업그레이드에 포함하기 위해 고려해야 할 다른 EIP와 Ethereum의 "롤업 중심 로드맵"을 고려한 거버넌스 변경에 대한 더 넓은 생각에 대해 논의했습니다.

Pectra Devnet 0 최신 진행 상황

Beiko는 컨퍼런스 콜에서 회계팀에 Pectra Devnet 0의 최신 진행 상황을 공유해달라고 요청했습니다. Nethermind 팀의 Marek Moraczyński는 Nethermind가 모든 Pectra EIP를 구현했으며 테스트 중이라고 말했습니다. Besu 팀의 Justin Florentine은 Besu가 Pectra EIP를 구현하고 Devnet 0 출시를 준비하기 위해 협력하고 있다고 말했습니다. Erigon 팀의 Andrew Ashikhmin은 "Erigon이 Devnet 0의 전체 제품군에 대한 EIP 수를 감당할 준비가 되었는지 잘 모르겠습니다. 부분적으로는 이러한 EIP에 대한 사양이 계속 변경되고 있고 Erigon 클라이언트가 새로운 버전으로 전환하고 있기 때문입니다. 주요 버전은 Erigon 3입니다. Erigon 3과 Pectra EIP가 최종 완성되어 Erigon 클라이언트에 함께 구축되므로 팀의 리소스와 시간이 소요됩니다." Geth 팀의 "Lightclient"는 Geth가 Devnet 0을 준비하는 데 "며칠 남았습니다"라고 말했습니다. Ethereum JS 팀의 Gajinder Singh은 Ethereum JS도 Devnet 0에 "준비"될 것이라고 말했습니다.

EIP -7685

Lightclient는 EL이 트리거한 요청을 CL(Consensus Layer)에 저장하고 EIP 6110 및 7002에 미치는 영향을 저장하기 위한 공통 프레임워크를 생성하는 EIP 7685를 병합합니다. Beiko는 개발자가 Devnet 0 릴리스에 이 EIP를 포함하고 Pectra EIP를 계속 개선해야 한다고 말했습니다.

테스트 측면에서 EF 테스트 팀의 Mario Vega는 EIP 6110 및 2537에 대한 테스트가 완료되었으며 EIP 7002 및 EIP 2935에 대한 테스트는 이번 주 또는 다음 주에 완료될 것이라고 말했습니다. EIP 3074 테스트는 아직 Devnet 0에 준비되지 않았습니다. EF 연구원 Antonio Sanso는 EIP 2537 사양이 업데이트되었고 새로운 테스트 벡터가 GitHub 저장소에 추가되었다고 밝혔으며 모든 사람이 GitHub에서 이를 확인해 볼 것을 권장합니다. EF 연구원인 Hsiao Wei Wang은 CL 사양 테스트 벡터에 오류가 있음을 지적했고, 해당 오류는 빠르게 수정되어 새 버전이 출시되었습니다.

EIP -3074 업데이트

이번 주 EIP 3074 사양에 대한 ACDE 요청에서는 몇 가지 변경 사항을 제안합니다. Ahmad Mazen Bitar는 AUTH CALL 이전에 DELEGATECALL을 허용하도록 EIP 3074의 동작을 변경하여 EIP의 사용 사례를 확장할 것을 제안했습니다. 블록체인 지갑 운영 체제인 ZeroDev의 설립자이자 CEO인 Derek Jiang은 필요할 때 AUTH 메시지의 전역 취소 및 기타 변경을 용이하게 하기 위해 "noncemanager"를 만들 것을 제안했습니다. 통화에 참여한 일부 개발자는 EIP 3074에 대한 변경 사항이 구현을 훨씬 더 어렵게 만들기 때문에 연기되어야 한다고 생각했습니다.

Beiko는 개발자가 별도의 세부 세션에서 EIP 3074에 대해 제안된 변경 사항을 논의할 것을 권장합니다. 그는 Pectra에서 EIP 3074를 구현할 충분한 시간을 갖기 위해 개발자는 "다음 달 또는 두 달 안에" 사양을 마무리하도록 노력해야 한다고 언급했습니다. Lightclient는 EIP 3074 세부 세션을 조직하는 데 동의합니다. Devnet 0의 경우 Beiko는 개발자가 향후 devnet이 EIP를 다르게 구현하거나 업그레이드에서 완전히 제거하기로 결정할 수 있더라도 고객 팀이 변경 없이 EIP 3074를 구현해야 함을 확인했습니다.

EIP 3074의 구현 세부 사항 외에도 개발자들은 EIP가 충분한 커뮤니티 지원을 가지고 있는지 진지하게 논의했습니다. 화면 이름이 "Siri"인 한 개발자는 통화 중에 "EIP 3074는 원칙적으로 좋지 않으며 전체 계정 추상화를 달성하는 능력을 저하시킬 것"이라는 우려를 표명했습니다. Beiko는 Ethereum Magician 및 ACD 통화 토론을 기반으로 계정 팀이 AA(계정 추상화)와 관련된 다른 제안보다 EIP 3074를 지원하는 것으로 보인다고 응답했습니다. Beiko는 "이것은 단기적으로 가장 합의된 제안인 것으로 보이며 실제로 다음 포크에서 EOA의 상태를 개선할 수 있습니다."라고 말했습니다. 이와 관련하여 Siri는 고객 팀이 단독으로 이러한 결정을 내려서는 안 된다고 믿습니다. Siri는 “우리는 다른 이해관계자의 의견을 들어야 합니다. 우리는 논쟁의 여지가 있는 하드 포크를 만드는 영역으로 방향을 바꾸고 싶지 않습니다. 다른 이해관계자가 말하는 것과 이를 어떻게 보는지 이해하는 것이 좋을 것이라고 생각합니다. . 제안. "

Beiko와 Siri는 ACD 통화를 넘어 EIP에 대한 보다 폭넓은 합의를 구축하는 방법에 대해서도 논의했습니다. Chiang은 먼저 EIP 3074 브레이크아웃 회의를 개최하여 EIP의 기술 사양을 심도 있게 논의한 다음 EIP가 Pectra 업그레이드에 남아 있어야 하는지 여부를 결정할 것을 제안했습니다. EF 연구원 Ansgar Dietrichs는 "충분한 진전을 이루지 않으면 EIP 3074가 철회될 것이라는 점을 이해해야 합니다."라고 말했습니다.

Ethereum 공동 창립자 Vitalik Buterin은 "사용자 계정 기능은 향후 몇 년 내에 변경될 예정입니다. , 특히 외부 소유 계정(EOA) EIP 3074 등과 같은 활성화 계정 추상화 관련 EIP

기타 Pectra 제안

개발자는 Pectra 업그레이드에 포함하기 위해 고려해야 할 다른 코드 변경 사항에 대해 계속 논의합니다. Geth 개발자인 Marius van der Wijden은 EOF와 같은 더 복잡한 EIP가 Pectra로 진출하는지 여부에 달려 있다고 말했습니다. van der Wijden은 "EOF를 포함한다면 포크 포화로 이어질 것입니다. EOF를 포함하지 않으면 더 많은 것을 포함할 수 있을 것입니다"라고 말했습니다.

Siri는 보안 검토 없이 Pectra에 EIP 3074를 포함하는 것에 대해 우려를 표시했습니다. Beiko는 EIP 3074의 사양이 확정될 때까지 이 논의를 보류할 것을 제안했습니다.

Bitar는 Pectra에 EIP 7212가 추가되는 것을 보고 싶다고 말했습니다. EIP 7212는 secp256 r1 타원 곡선에서 서명 확인을 수행하는 새로운 사전 컴파일을 생성합니다. 이는 사용자 생체 인식을 지원하는 하드웨어 장치와 함께 사용할 수 있습니다. Bitar는 Ethereum 거래에 서명하기 위해 생체인식을 지원하는 것이 사용자 경험을 크게 향상시킬 것이라고 말했습니다. 아시헤민은 자신도 이 제안에 찬성한다고 말했다. Dietrichs는 이것이 "RIP(롤업 개선 제안)" 프로세스를 통해 레이어 2 롤업 구현이 승인된 유일한 솔루션이라고 지적했습니다.

Dietrichs, van der Wijden 및 Moraczyński를 포함한 다른 개발자들은 통화 데이터 비용이 증가하여 최대 블록 크기가 제한되는 EIP 7623에 대한 지원을 표명했습니다. Beiko는 EIP 7623 및 EIP 7212를 Pectra에 "고려용" 또는 CFI로 표시하고 클라이언트 팀의 대역폭을 다시 방문하여 Devnet 0 출시 후 이 두 가지 개선 제안을 지원할 것을 권장합니다.

EL의 직렬화 방법을 SSZ로 업데이트하는 것과 관련된 EIP 번들과 관련하여 van der Wijden은 이러한 번들을 Pectra로 전송하기가 너무 어려울 것이라는 우려를 표명했습니다. Geth 팀의 동료인 Guillaume Ballet도 이러한 평가에 동의합니다. 부테린은 최소한 거래 영수증을 업데이트하기 위한 직렬화 방법은 이더리움 위에 구축된 레이어 2 롤업의 추가 보안 감사 오버헤드를 제거하기 때문에 이더리움 자체를 넘어 "상당한 가치"를 가질 것이라고 말했습니다. ". SSZ 관련 EIP의 주요 후원자인 Nimbus 팀의 Etan Kissling은 통화에 참석하지 않았지만 GitHub에 이러한 코드 변경이 왜 중요하고 Pectra에 포함되어야 하는지에 대한 자세한 설명을 썼습니다.

개발자들도 EOF를 다시 방문했습니다. 독립적인 이더리움 프로토콜 개발자인 Danno Ferrin은 EOF 팀이 코드 변경에 대한 EL 사양 테스트를 수행하고 있다고 말했습니다. EVMOne과 Reth는 EOF 구현을 완료한 것으로 알려진 두 EL 클라이언트 팀입니다. Ferrin은 Geth 팀이 구현에 있어 "좋은 진전"을 이루었다고 말했습니다. Ferrin은 Ballet이 EOF 및 Verkle 호환성에 대한 우려를 해결하기 위해 Solidity 팀의 "Daniel"과 협력하고 있다고 덧붙였습니다.

Ballet은 Daniel 및 Dietrichs와 같은 다른 개발자와의 대화를 바탕으로 EOF의 목적을 무너뜨리지 않고 EOF의 범위를 좁히고 개발자가 다른 EOF와 유사한 코드 변경 세트를 구현할 수 있는 더 많은 기회를 만드는 것이 어려울 것이라고 지적했습니다. 미래.

"Charles C"라는 대화명을 사용하는 개발자는 크고 작은 EOF 업그레이드보다는 Side Car 메커니즘(예: Blob 트랜잭션에 사용되는 메커니즘)을 통해 쉽게 EOF를 반복적으로 구현할 수 있는 방법을 찾을 것을 제안했습니다. . Dietrichs는 채팅에서 EOF 복잡성이 줄어들면 계정 팀이 Pectra에 더 관심을 가질 것인지 물었습니다. Ipsilon 팀은 EOF에서 가장 높은 복잡성을 야기한 코드 변경(예: "TX create")이 해결되었으며 "EOF create"와 같은 기능에 대한 특정 요청을 제거해도 전체 EOF 복잡성이 크게 줄어들지 않는다는 점에 주목했습니다. 맥락상 Ipsilon은 EF가 자금을 지원하는 EVM R&D 팀의 이름입니다. Beiko는 개발자들이 반복되는 EOF 세부 세션에서 EOF 구현에 대해 계속 논의할 것을 권장합니다.

ACD/EIP 및 L2/RIP

ACDE #186에서 논의된 마지막 주제로 개발자들은 새로운 RIP 프로세스를 고려하기 위해 Ethereum EIP 프로세스의 변경 사항에 대해 논의했습니다. Dietrichs는 개발자들이 롤업 조정, RollCall 및 RIP 프로세스에 대한 일련의 회의를 시작한 지 6개월이 지났다고 언급했습니다. 이러한 프로세스가 Ethereum EIP 프로세스에 어떻게 영향을 미치고 영향을 주어야 하는지에 대한 몇 가지 공개적인 질문이 여전히 남아 있습니다. Dietrichs는 L2에서 진행 중인 연구 질문 중 하나는 EVM(Ethereum Virtual Machine)과의 장기적 동등성이 Rollup에 바람직한지 여부라고 말했습니다. 그는 또한 L2에 구현된 변경 사항이 궁극적으로 이더리움 레이어 1의 프로토콜 결정에 어느 정도 영향을 미칠 것인지에 대한 열린 질문이 있다고 덧붙였습니다.

Geth 개발자 Péter Szilágyi는 L2에서 제공되는 일부 기능이 L1에서 제공하기에 적합하지 않을 수 있으며, 어떤 경우에는 L2에서 제공되는 기능을 그대로 따르더라도 L2 간에 차이가 있을 수 있어 혼란을 야기할 수 있다고 밝혔습니다. 이더리움 프로토콜 개발자. EF 연구원 Carl Beekhuizen은 RollCalls 및 RIP 프로세스에서는 Ethereum 프로토콜 개발자가 L2의 기능을 릴리스하도록 요구하지 않고 오히려 Szilágyi가 설명한 것과 같은 혼란스러운 상황을 피하기 위해 Rollups와 Ethereum 개발자 간의 통신을 개선한다고 지적했습니다. Van der Wijden은 프로토콜 개발자가 L2 자체가 종료되거나 사용이 중단됨에 따라 결국 쓸모 없거나 불필요하게 될 L2에 구현된 변경 사항을 지원하는 데 시간을 소비한다는 우려를 표명했습니다.

이러한 우려에 대해 Dietrichs는 다음과 같이 말했습니다. "사람들은 항상 Layer 2가 실험하고 더 이상해질 수 있다고 생각했습니다. 실제로 우리가 보는 것은 대부분이 그렇게 하지 않기로 결정하거나 적어도 아마도 시작했을 것이라는 것입니다. 그리고 시간이 지남에 따라 대부분의 사람들은 그렇게 하는 것을 중단했습니다. 그래서 지금은 실제로 대부분 첫 번째 계층 사양을 따르고 있습니다. 적어도 롤업 중심 로드맵을 고려하면 이것이 생태계를 위한 최선의 방법이라고 생각합니다. 진화하려면 최선의 방법처럼 최소한 레이어 2의 명확한 지침과 의사소통이 필요합니다."

위 내용은 이더리움 핵심 개발자들의 최신 회의 요약: EIP 3074 구현 준비, 롤업 로드맵의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!