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

원문 제목：《Ethereum All Core Developers Execution Call #186 Writeup》

원문 저자：Christine Kim

원문 번역：Frost，BlockBeats

편집자 주：

이더리움 모든 핵심 개발자 합의 전화(ACDE)는 2주마다 열리며, 주로 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번은 ACDE 제 186차 전화 회의로, 개발자들은 Pectra Devnet 0 및 EIP 3074 구현 준비 작업에 대해 논의했습니다. 그들은 각 클라이언트 팀이 Pectra Devnet 0 준비에 대한 진행 상황을 자세히 설명하고, EIP 3074 규격에 대한 수정 제안 및 관련 테스트 진행 상황에 대해 논의했습니다.

또한, 본문에서는 Pectra 업그레이드에 포함될 수 있는 다른 코드 변경 사항에 대한 논의와 이더리움 EIP 프로세스의 변경이 L2/RIP 프로세스에 어떻게 영향을 미치는지에 대한 논의와 같은 다른 중요한 주제도 언급되었습니다. Galaxy Digital 연구 부사장 Christine Kim은 이번 회의의 요점을 자세히 기록하였으며, BlockBeats는 원문을 다음과 같이 번역하였습니다：

2024년 4월 25일, 이더리움 개발자들은 Zoom에서 All Core Developers Execution (ACDE) call #186 회의에 참석했습니다. ACDE 전화 회의는 이더리움 재단 프로토콜 지원 책임자 Tim Beiko가 주재하는 2주마다 열리는 시리즈 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주, 개발자들은 Pectra Devnet 0 및 EIP 3074 구현 준비 작업에 대해 논의했습니다. 그들은 또한 Pectra 업그레이드에 포함할 다른 EIP를 고려해야 할지와 이더리움의 "롤업 중심 로드맵"을 고려한 거버넌스 변화에 대한 폭넓은 사고를 논의했습니다.

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는 EIP 7685를 통합하여 EL에서 발생한 요청을 합의 계층(CL)에 저장하기 위한 일반적인 프레임워크를 생성하고, EIP 6110 및 7002에 미치는 영향을 설명했습니다. 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의 업데이트

이번 주 ACDE에서는 EIP 3074 규격에 대한 몇 가지 변경 사항이 제안되었습니다. Ahmad Mazen Bitar는 EIP 3074의 동작을 변경하여 AUTH CALL 이전에 DELEGATECALL을 수행할 수 있도록 하여 EIP의 사용 사례를 확장할 것을 제안했습니다. 블록체인 지갑 운영 체제 ZeroDev의 창립자이자 CEO인 Derek Jiang은 필요할 때 AUTH 메시지와 기타 변경 사항을 전 세계적으로 철회할 수 있도록 "noncemanager"를 생성할 것을 제안했습니다. 전화 회의에 참석한 일부 개발자들은 EIP 3074의 변경을 연기해야 한다고 생각했으며, 이는 구현의 난이도를 크게 증가시킬 것이라고 주장했습니다.

Beiko는 개발자들이 EIP 3074의 제안된 변경 사항에 대해 별도의 그룹 회의에서 논의할 것을 제안했습니다. 그는 Pectra에서 EIP 3074를 구현할 충분한 시간을 확보하기 위해 개발자들이 "앞으로 한두 달 내에" 최종 규격을 결정하려고 노력해야 한다고 지적했습니다. Lightclient는 EIP 3074 그룹 회의를 조직하는 데 동의했습니다. Devnet 0에 대해 Beiko는 클라이언트 팀이 변경 없이 EIP 3074를 구현해야 한다고 확인했으며, 개발자들이 향후 devnet에서 EIP를 다르게 구현하거나 업그레이드에서 완전히 제거하기로 결정할 수 있다고 하더라도 말입니다.

EIP 3074의 구현 세부 사항 외에도 개발자들은 EIP가 충분한 커뮤니티 지원을 받고 있는지에 대해 진지하게 논의했습니다. "Siri"라는 이름을 가진 개발자는 전화 회의에서 "EIP 3074는 원칙적으로 나쁘며, 우리가 완전한 계정 추상화를 구현하는 속도를 늦출 것이다."라고 우려를 표명했습니다. Beiko는 이더리움 마법사 및 ACD 통화 논의에 따르면 클라이언트 팀이 EIP 3074를 지지하는 것처럼 보인다고 응답했습니다. Beiko는 "이것은 단기적으로 가장 합의가 이루어진 제안으로 보이며, 우리는 실제로 다음 분기에서 EOA의 상태를 개선할 수 있습니다."라고 말했습니다. 이에 대해 Siri는 클라이언트 팀이 이 결정을 고립적으로 내려서는 안 된다고 주장했습니다. "우리는 다른 이해관계자의 의견을 들어야 한다."고 Siri는 말하며, "우리는 논란이 있는 하드 포크 영역으로 전환하고 싶지 않다. … 나는 다른 이해관계자의 의견과 그들이 이 제안에 대해 어떻게 생각하는지를 아는 것이 가장 좋다고 생각한다."라고 덧붙였습니다.

Beiko와 Siri는 ACD 통화 외부에서 EIP에 대한 더 넓은 합의를 어떻게 구축할 것인지에 대해서도 논의했습니다. Chiang은 먼저 EIP 3074 그룹 회의를 열어 EIP의 기술 규격에 대해 심도 있게 논의한 후 Pectra 업그레이드에 포함할지 여부를 결정할 것을 제안했습니다. EF 연구원 Ansgar Dietrichs는 "우리는 충분한 진전을 이루지 않는 한 EIP 3074가 철회될 것이라는 점을 이해해야 한다."고 말했습니다.

이더리움 공동 창립자 Vitalik Buterin은 "앞으로 몇 년 동안 사용자 계정 기능이 변화할 것이며, 특히 외부 소유 계정(EOA)에서 그러할 것이다. 계정 추상화와 관련된 EIP를 활성화해야 한다."고 덧붙였습니다.

기타 Pectra 제안

개발자들은 Pectra 업그레이드에 포함될 수 있는 다른 코드 변경 사항에 대해 계속 논의했습니다. Geth 개발자 Marius van der Wijden은 이것이 EOF와 같은 복잡한 EIP가 Pectra에 포함될지 여부에 따라 달라져야 한다고 말했습니다. "우리가 EOF를 포함해야 한다면, 이는 분기 포화로 이어질 것입니다. 만약 우리가 EOF를 포함하지 않는다면, 아마도 더 많은 내용을 포함할 수 있을 것입니다."라고 van der Wijden은 말했습니다.

Siri는 EIP 3074를 Pectra에 포함하는 것에 대해 보안 감사 없이 진행하는 것에 대해 우려를 표명했습니다. Beiko는 EIP 3074의 규격이 최종 결정될 때까지 이 논의를 보류할 것을 제안했습니다.

Bitar는 Pectra에 EIP 7212를 추가하고 싶다고 밝혔습니다. EIP 7212는 secp256 r1 타원 곡선에서 서명 검증을 수행하는 새로운 프리컴파일을 생성할 것입니다. 이는 사용자 생체 인식을 지원하는 하드웨어 장치와 함께 사용할 수 있습니다. Bitar는 이더리움 거래에 서명하기 위해 생체 인식을 지원하는 것이 사용자 경험의 중대한 개선이 될 것이라고 말했습니다. Ashikhmin도 이 제안에 찬성한다고 밝혔습니다. Dietrichs는 이것이 "롤업 개선 제안"(RIP) 프로세스를 통해 Layer-2 롤업에 의해 승인된 유일한 제안이라고 지적했습니다.

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

EL의 직렬화 방법을 SSZ로 업데이트하는 것과 관련된 EIP 번들에 대해 van der Wijden은 Pectra에서 이를 운반하는 것이 너무 어렵다고 우려를 표명했습니다. Geth 팀의 Guillaume Ballet의 동료도 이 평가에 동의했습니다. Buterin은 "최소한 거래 영수증의 직렬화 방법을 업데이트하는 것은 이더리움 자체를 넘어서는 '중대한 가치'를 가질 것이며, 이는 이더리움 위에 구축된 제2층 롤업의 추가 보안 감사 비용을 제거하기 때문입니다."라고 말했습니다. SSZ 관련 EIP의 주요 지지자인 Nimbus 팀의 Etan Kissling은 전화 회의에 참석하지 않았지만, GitHub에 이러한 코드 변경이 왜 중요한지에 대한 자세한 설명을 작성하여 Pectra에 포함될 수 있도록 고려해야 한다고 밝혔습니다.

개발자들은 EOF에 대해서도 다시 논의했습니다. 독립 이더리움 프로토콜 개발자 Danno Ferrin은 EOF 팀이 코드 변경에 대한 EL 규격 테스트를 진행하고 있다고 밝혔습니다. EVMOne과 Reth는 EOF 구현을 완료한 것으로 보고된 두 개의 EL 클라이언트 팀입니다. Ferrin은 Geth 팀이 구현에서 "좋은 진전을 이루었다."고 말했습니다. Ferrin은 Ballet가 Solidity 팀의 "Daniel"과 협력하여 EOF와 Verkle 호환성에 대한 우려를 해결하고 있다고 덧붙였습니다.

Ballet는 Daniel 및 Dietrichs와 같은 다른 개발자와의 대화에 따르면, EOF의 범위를 좁히는 것이 그 목적을 위반하지 않으면서 개발자들이 향후 유사한 EOF 코드 변경을 구현할 수 있는 더 많은 작업을 창출하는 것이 어렵다고 지적했습니다.

"Sirius C"라는 스크린 이름을 가진 개발자는 작은 EOF 업그레이드와 큰 EOF 업그레이드 사이에서 선택하는 대신, Side Car 메커니즘(예: Blob 트랜잭션에 대한 메커니즘)을 통해 EOF를 쉽게 반복적으로 구현할 수 있는 방법을 찾을 것을 제안했습니다. Dietrichs는 대화 중에 Pectra의 EOF 복잡성을 줄이면 클라이언트 팀이 더 큰 관심을 가질 것인지 물었습니다. Ipsilon 팀은 EOF에서 가장 높은 복잡성을 초래하는 코드 변경(예: "TX create")이 이미 해결되었으며, "EOF create"와 같은 기능을 삭제하는 특정 요청이 전체 EOF 복잡성을 크게 줄이지 않을 것이라고 지적했습니다. 배경으로, Ipsilon은 EF가 자금을 지원하는 EVM 연구 개발 팀의 이름입니다. Beiko는 개발자들이 반복적으로 발생하는 EOF 그룹 논의에서 EOF 구현에 대해 계속 논의할 것을 제안했습니다.

ACD / EIP 및 L2 / RIP

ACDE #186 논의의 마지막 주제로, 개발자들은 새로운 RIP 프로세스가 이더리움 EIP 프로세스에 미치는 변경 사항을 고려했습니다. Dietrichs는 개발자들이 롤업 조정, RollCall 및 RIP 프로세스의 회의 시리즈를 시작한 지 6개월이 지났다고 지적했습니다. 이러한 프로세스가 이더리움 EIP 프로세스에 어떻게 그리고 어떤 방식으로 영향을 미칠 것인지에 대한 몇 가지 미결 문제가 여전히 존재합니다. Dietrichs는 L2에서 진행 중인 연구 문제 중 하나는 롤업에 대해 이더리움 가상 머신(EVM)과의 장기적인 동등성이 바람직한지 여부라고 덧붙였습니다. 그는 또한 L2에서 구현된 변경 사항이 이더리움 1층의 프로토콜 결정에 얼마나 영향을 미칠 것인지에 대한 미결 문제가 있다고 추가했습니다.

Geth 개발자 Péter Szilágyi는 L2에서 제공되는 특정 기능이 L1에서 제공되는 것과 적합하지 않을 수 있으며, 경우에 따라 L2에서 제공되는 기능을 따르더라도 L2 간에 차이가 있을 수 있어 이더리움 프로토콜 개발자에게 혼란을 줄 수 있다고 말했습니다. EF 연구원 Carl Beekhuizen은 RollCalls 및 RIP 프로세스가 이더리움 프로토콜 개발자가 L2에서 기능을 게시할 필요가 없도록 개선되어야 하며, Szilágyi가 설명한 것과 같은 혼란스러운 상황을 피하기 위해 롤업과 이더리움 개발자 간의 커뮤니케이션을 개선해야 한다고 지적했습니다. Van der Wijden은 프로토콜 개발자가 L2에서 구현된 변경 사항을 지원하는 데 시간을 할애하는 것에 대해 우려를 표명했으며, 이러한 변경 사항이 결국 구식이 되거나 불필요해질 수 있다고 언급했습니다. L2 자체가 종료되거나 사용이 중단될 수 있기 때문입니다.

이러한 우려에 대해 Dietrichs는 "사람들은 항상 Layer 2가 실험을 하고 더 미친 짓을 할 수 있다고 생각해 왔습니다. 그러나 실제로 우리는 그들 중 대부분이 그렇게 하지 않기로 결정했으며, 심지어 그렇게 시작할 수도 있지만 시간이 지남에 따라 대부분이 중단되었습니다. 그래서 이제 그들은 실제로 주로 1층 규격을 따릅니다. 적어도 롤업 중심 로드맵을 고려할 때, 또는 우리가 모두 이것이 생태계 발전의 최선의 방법이라고 생각하는 경우, 우리는 적어도 Layer 2에 명확한 지침과 커뮤니케이션을 제공해야 합니다. 여기서 최선의 진행 방향처럼요."라고 말했습니다.