Ethereum — All Core Devs — Testing (ACDT), August 18 2025

Ethereum All Core Devs의 미팅 내용을 정리하고 공부해보자!

• All Core Devs repo: https://github.com/ethereum/pm/issues/1680
• https://www.youtube.com/watch?v=KuAtOO46Bxs
• 글의 하단에는 All Core Devs 미팅에 나온 여러 용어들에 대한 설명이 있습니다.

1. Fusaka DevNet 상태

• DevNet-4는 현재 중단된 상태입니다.
• DevNet-3는 계속 운영되며, 별도 종료 계획은 없습니다.
• DevNet-5는 다음 주 화요일 런칭을 목표로 하며, spec 변경이나 추가 clarifications 없이 진행될 예정입니다.
• DevNet-5는 규모가 크고 DevNet-4 수준의 강도 있는 테스트넷이 될 것입니다.
• 클라이언트 팀들의 주요 과제는 main/master branch에 최신 코드 병합을 완료하는 것입니다.

2. BPO Static Tests

새로운 Static Test(정해진 시나리오를 반복적으로 실행해 결과를 검증하는 테스트) 릴리스가 준비되었습니다.

이 테스트에는 DevNet-4에서 실제로 발생했던 문제 상황도 그대로 포함되어 있습니다. 즉, 과거에 문제가 되었던 케이스를 다시 재현해서 각 클라이언트가 올바르게 동작하는지 확인하는 방식입니다.

이 릴리스는 Hive라는 테스트 프레임워크에 업데이트될 예정입니다. Hive를 통해 동일한 테스트를 모든 클라이언트에게 적용하면, 특정 클라이언트에서만 문제가 발생하는지 여부를 쉽게 비교할 수 있습니다.

핵심 목적은 BPO 관련 이슈가 모든 클라이언트에서 제대로 해결되었는지 검증하는 것입니다.

3. Gas Limit Testing — 60M Gas (Pre-Fusaka)

Fusaka 업그레이드 전에 가스 한도를 60M으로 올릴 수 있을지 논의가 있었습니다.

현재 테스트에서는 대부분의 클라이언트는 60M 환경에서도 큰 문제가 없었지만, 일부 클라이언트에서 성능 저하가 뚜렷하게 나타났습니다. 특히 ecrecover와 ModExp 같은 연산, 그리고 몇몇 opcode나 precompile이 병목 구간이 될 수 있다는 우려가 제기되었습니다.

그중에서도 ModExp precompile은 원래부터 처리 속도가 낮은 편인데, 모든 클라이언트가 공통적으로 사용하는 KZG 라이브러리 때문에 구조적으로 개선이 어려울 수 있습니다. 따라서 라이브러리 자체 최적화나 연산 비용 재조정(repricing)이 필요할 수 있습니다.

성능 기준은 다음과 같이 정리되었습니다.

• 최악의 경우에도 3초 안에 블록을 처리할 수 있어야 한다.
• 4초에 가까워지는 것은 허용할 수 없다.

결론적으로, 가스 한도를 실제로 60M까지 올릴지는 더 많은 벤치마크와 성능 분석을 한 뒤에 최종 결정하기로 했습니다.

4. Snap Sync 문제

perfnet-devnet-2에서 모든 클라이언트가 70시간 이내 snap sync에 실패한 사례가 보고되었습니다.

이 네트워크의 데이터 크기는 메인넷의 약 2배였는데, 그럼에도 불구하고 어느 클라이언트도 동기화를 끝내지 못했습니다. 따라서 특정 클라이언트만의 문제가 아니라 모든 클라이언트에게 공통적으로 영향을 주는 성능 한계일 가능성이 높습니다.

이 문제를 해결하려면 각 클라이언트 팀이 자신들의 로컬 환경에서 snap sync를 다시 시도해보고, 실패 원인을 분석해야 합니다.

5. Consensus Layer Spec PR (#4508)

현재 minimal preset(테스트를 위한 최소 설정)에서는 blob의 개수 제한이 낮게 잡혀 있습니다. 이 제한을 mainnet 수준으로 올리자는 제안(PR #4508)이 나왔습니다.

이렇게 되면 개발자들이 로컬 환경에서도 mainnet과 동일한 조건으로 더 많은 blob을 처리하는 테스트를 할 수 있습니다.

지금까지는 제한 때문에 실제 네트워크 상황과 차이가 있었지만, 상한을 올리면 더 현실적인 성능 검증이 가능해집니다.

회의에서는 기술적인 반대 의견이 나오지 않았고, 이 변경은 알파 릴리스에 포함될 가능성이 큽니다.

6. Sunnyside Labs 업데이트

새로운 변경 사항은 없으며, 지난주 Discord에 공유된 리포트 외에는 업데이트가 없습니다.

7. Safe Head 논의

Execution Layer safe head endpoint의 semantics/behavior 변경 논의가 있었으나, 이번 회의에서는 별도 업데이트나 추가 토론이 없었습니다. 추후 ACDE 회의에서 다시 다뤄질 예정입니다.

요약

• DevNet-5는 다음 주 런칭 예정이며, 주요 클라이언트 코드 병합만 남아 있습니다.
• BPO static tests는 DevNet-4 문제 재현을 기반으로 Hive에 반영되어 검증됩니다.
• 60M gas limit 상향은 아직 합의되지 않았으며, 성능 문제 해결과 추가 분석이 필요합니다.
• Snap sync 실패는 전 클라이언트 공통 이슈로, 원인 분석이 요구됩니다.
• CL Spec PR(#4508)은 merge될 가능성이 높습니다.
• Sunnyside Labs와 Safe Head는 큰 업데이트 없이 넘어갔습니다.

1. DevNet-4 중단 이유

이번 미팅에서 DevNet-4중단 이유가 다뤄지진 않았지만, 이전 ACDE 미팅에서 DevNet-4의 문제들이 다뤄졌습니다. EL 클라이언트 불일지 문제, 동기화 문제, 부트노드 구성 문제등으로 안정적으로 운영되지 않았고, 최종적으로 중단된것으로 보입니다.

2. ecrecover

ecrecover는 Ethereum에서 사용되는 연산으로, 특정 메시지와 그에 대한 서명이 주어졌을 때 그 서명을 만든 지갑 주소를 찾아내는 기능입니다. 쉽게 말해, “이 서명이 정말 이 주소에서 나온 게 맞는지” 확인하는 도구입니다. 트랜잭션 검증이나 오프체인 서명을 온체인에서 확인할 때 활용됩니다.

3. perfnet-devnet-2

PerfNet-DevNet-2는 ethpandaops 팀이 운영하는 Ethereum 개발자용 DevNet 중 하나로, 주로 성능(performance) 검증을 목적으로 만들어졌습니다. 이 네트워크는 메인넷보다 약 2배 큰 데이터 크기를 갖고 있으며, 클라이언트들이 얼마나 빠르고 안정적으로 snap sync를 수행할 수 있는지를 실험하는 데 사용됩니다. 최근 보고에서는 모든 클라이언트가 70시간 이내에 동기화를 완료하지 못한 사례가 확인되어, 공통 성능 한계를 점검해야 하는 상황입니다.

• https://github.com/ethpandaops