소개
하드포크는 네트워크의 기능과 효율성을 재정의하는 중요한 순간입니다. 5월 7일, 이더리움 메인넷은 데네브 포크에서 일렉트라 포크로 업그레이드되었으며, 여기에는 프로토콜의 합의 및 네트워킹 계층에 대한 몇 가지 중요한 변경 사항과 개선 사항이 포함되었습니다. 이 글에서는 하드포크 이전 몇 주 동안의 네트워크 토폴로지 분석, 메시지 도착 시간 변화, 그리고 업그레이드를 통해 완화된 대역폭 요구 사항이 적용되었는지 여부를 통해 네트워크가 하드포크에 어떻게 대비했는지 자세히 살펴봅니다.
이를 위해 Nebula 와 Hermes 와 같은 일부 측정 도구가 하드포크 전, 중, 후에 수집한 데이터에 대한 전담 분석을 수행했습니다. 이 분석은 네트워크 토폴로지 , 블록 도착 시간 , 대역폭 사용량 등에 대한 주간 업데이트를 보완합니다. 1년 전 Dencun 하드포크의 P2P 계층 심층 분석(A Deep Dive into the P2P Layer of the Dencun Hardfork)을 진행한 바 있으며, 이를 통해 본 연구의 주요 초점 영역을 파악할 수 있었습니다.
요약
이것이 우리의 주요 요점입니다
- 하드 포크 2일 전 네트워크의 53%가 업그레이드 준비가 되었습니다.
- 네트워크의 70%는 즉시 업그레이드되었고, 추가로 ~18%는 포크 후 5일 이내에 업그레이드되었습니다.
- 블록 브로드캐스팅 지연 시간은 전반적으로 영향을 받지 않았습니다.
- 전반적으로 블록 도착 지연 시간이 중간값에서 약 200ms로 약간 감소한 것을 확인했습니다.
- 그러나 EU와 미국(대부분의 노드가 배치된 곳)과의 지연 시간이 길어 지리적으로 불리한 아프리카, 호주, 남미에 위치한 일부 노드는 업그레이드 전보다 블록 도착 시간이 더 느렸습니다.
- 일반적으로 블록의 약 5%가 4초 슬롯 마감 시간 내에 도착하지 않아 검증자가 증명 헤드를 놓쳐 보상을 덜 받을 가능성이 있습니다.
목차
방법론
사용된 도구
이 게시물에 제시된 작업을 위해 ProbeLab 팀은 다음 도구를 활용했습니다.
- Nebula - libp2p 및 discv5 호환 네트워크 크롤러.
- Hermes - 모든 관련 pubsub 주제를 구독하고 모든 프로토콜 상호작용을 추적하는 가벼운 GossipSub 리스너 및 추적기입니다.
- Xatu - EF EthPandaOps의 네트워크 모니터링 플랫폼.
데이터 세트
이 연구에서 제시된 결과는 2주간의 기간을 대상으로 합니다. Pectra 업그레이드 1주일 전(날짜: 2025-04-28 ~ 2025-05-07 )과 업그레이드 1주일 후(날짜: 2025-05-07 ~ 2025-05-14 )입니다.
보고서 후반부의 "하드포크가 블록 도착 시간에 미치는 영향" 섹션에서는 커뮤니티 데이터 수집 노력(Community Data Collection Effort) 에 참여하는 다양한 에이전트와 노드의 데이터 샘플을 수집하는 Xatu의 공개 데이터베이스를 참조합니다. 여기에는 다음이 포함됩니다.
- Ethereum Foundation(EF) 제어 노드는 센트리 노드 라고도 하며, 다양한 클라이언트와 지리적 위치에 배포됩니다.
- 커뮤니티가 운영하는 노드는 공공 데이터베이스에 이타적으로 데이터를 제공합니다.
나머지 섹션의 데이터는 Nebula 크롤러를 지속적으로 배포하여 얻었고, 필요한 경우 사용자 정의 스크립트도 사용했습니다.
네트워크 토폴로지 변경
포크 다이제스트
위 그래프는 하드 포크 시점에 discv5 DHT에 광고된 포크 다이제스트를 보여줍니다. 하드 포크 시점에 광고된 데네브 다이제스트가 급격히 감소한 것을 분명히 확인할 수 있습니다. 하드 포크 2시간 후, 노드의 70%가 새로운 포크를 따랐습니다. 하드 포크 이후 며칠 동안 새로운 포크로 업데이트하는 노드들이 상당수 존재합니다. 그러나 포크 5일 후에도 약 12%의 노드가 이전 포크를 따르고 있습니다. 이 노드들은 검증자를 실행하지 않는다고 가정해도 무방합니다. 검증자가 없다면 체인 헤드에 대한 후속 조치를 취할 수 없고, 결국 검증자가 임무를 수행할 수 없게 되기 때문입니다.
제때 업그레이드되지 않은 노드는 홈/취미 배포라고 가정할 수 있습니다. 그러나 포크 5일 후 온라인 노드를 1) 일렉트라(Electra)를 따르는 노드, 2) 일렉트라를 따르지 않는 노드의 두 가지 범주로 나누어 보면, 일렉트라를 따르지 않는 노드는 주로 클라우드 인프라에서 실행된다는 것을 알 수 있습니다. 따라서 홈 배포라는 가설은 무효화됩니다.
노드가 발표하는 다음 포크 버전을 살펴보면, 일부 클라이언트가 이미 다음 Fulu 포크를 광고하고 있는 것을 볼 수 있습니다.
흥미롭게도, 이미 Fulu를 발표한 곳은 거의 Prysm뿐입니다. 다른 클라이언트 구현은 여전히 Electra만 게시합니다.
클라이언트 업그레이드
하드 포크에 이르는 기간을 살펴보면서, 우리는 Prysm, Lighthouse 및 Teku 구현의 사용자가 호환되는 클라이언트 버전을 어떻게 적용했는지에 초점을 맞춥니다.
다음 그래프는 언급된 클라이언트 구현 중 하나의 특정 버전을 실행하는 노드 수를 하드 포크 후 며칠까지 시간 경과에 따라 보여줍니다. 세 그래프 모두 하드 포크가 발생한 시점과 새 포크와 호환되는 첫 번째 버전이 GitHub에 출시된 시점을 나타냅니다.
예상대로 세 가지 경우 모두 각 클라이언트의 공식 출시 직후 노드 운영자들이 업그레이드를 시작했음을 알 수 있습니다. 하드포크 이틀 전 네트워크 노드의 약 53%가 Electra 호환 클라이언트 구현을 실행하고 있었으며, 하루 전에는 60%, 한 시간 전에는 67%였습니다. 이 수치에는 Nimbus 클라이언트는 포함되지 않았는데, 버전 정보를 제공하지 않기 때문입니다. Nimbus는 네트워크 배포에서 상당한 점유율을 차지하는 네 번째 구현이므로 Electra 지원 노드 수는 몇 자릿수 퍼센트 포인트 더 높을 것으로 예상됩니다.
아래 그래프에서 볼 수 있듯이, 노드 운영자들은 하드 포크를 클라이언트 구현을 전환할 기회로 삼지 않았다고도 안전하게 말할 수 있습니다. 포크 기간 동안 클라이언트 구현의 분포는 거의 변하지 않았습니다.
테이크어웨이
- 온라인 노드의 약 70%가 새로운 포크를 즉시 따랐습니다.
- 이벤트가 발생한 지 1주일 후에 새로운 포크가 이어지면서 약 20%의 긴 꼬리가 나타났습니다.
- 나머지 노드가 가정/취미 배포인지 말하기는 어렵습니다. 왜냐하면 이러한 노드는 클라우드 인프라에서 실행되기 때문에 검증기를 실행하지 않고 노드를 구동할 가능성이 낮기 때문입니다.
- 포크에 앞서 호환되는 클라이언트 릴리스가 점차적으로 추가되었습니다.
블록 도착 시간에 대한 하드포크의 영향
Pectra 업그레이드의 핵심 추가 사항 중 하나는 블롭 대상 및 최대 값이 블록당 블롭 3개씩 증가한다는 것입니다( EthPandaOps 게시글 및 ProbeLab 게시글 참조). 네트워크가 임시 저장 공간의 50% 증가로 이득을 얻지만, 이러한 블롭 수 증가는 네트워크가 모든 슬롯에서 최대 348KB의 추가 데이터를 전송해야 한다는 것을 의미합니다. 이는 궁극적으로 노드가 블록이 전파되는 슬롯 초기 단계에서 더 많은 대역폭을 할당할 수 없을 경우 네트워크의 전반적인 메시지 브로드캐스팅 성능에 영향을 미칠 수 있습니다.
다음 그래프는 EthPandaOps 공개 Xatu 인스턴스에 제출된 모든 블록 도착 시간을 가져와서 집계한 것입니다.첫 번째 차트는 Pectra 업그레이드 전 측정값에 속하고 두 번째 차트는 업그레이드 후 측정값에 속합니다.이 데이터에는 Ethereum Foundation의 센트리 노드의 데이터 포인트뿐만 아니라 커뮤니티 데이터 수집 프로그램 에 참여하는 일부 외부 협력자의 데이터 포인트도 포함됩니다.더 명확하게 하기 위해 Pectra 이전 상태를 설명하는 그래프는 2025-04-28 에서 2025-05-07 까지의 날짜를 다루고 Pectra 이후의 그래프 2025-05-07 에서 2025-05-14 까지의 날짜를 다룹니다.또한 더 깔끔한 분포를 위해 제안된 슬롯의 시작 이후 12초를 초과한 모든 블록 도착을 삭제했습니다. 우리는 12초를 초과하는 블록 도착은 우리가 시각화하려고 하는 가십서브 메시지 방송보다는 재구성과 관련이 있을 가능성이 높다고 생각합니다.
대륙별 차이점
다음 그래프는 슬롯 시작 또는 t=0, 기준으로 블록 도착 시간을 보여줍니다.첫 번째 그래프는 Pectra 업그레이드 전 데이터에 초점을 맞춥니다.그래프는 여러 국가에서 유사한 분포를 보여주며 블록의 총 평균은 Pectra보다 2.386초 앞서 도착했습니다.하지만 가장 빠른 수신 대륙의 평균(유럽, 2.278초)과 가장 느린 대륙(남미, 2.725초) 사이에 500ms의 차이가 있다는 점을 언급할 가치가 있습니다.또한 이 그림은 블록 전파에 대한 4초의 사양 창을 준수하여 데이터 포인트의 95%가 슬롯의 3.84초 이내에 수신되었음을 보여줍니다.그러나 이것은 모든 국가에 해당하는 것은 아닙니다.아프리카와 남미에 배치된 노드는 블록 도착의 95번째 백분위수가 각각 4.327초와 4238초로 4초 표시를 초과했습니다.
Pectra 업그레이드 전:
Pectra 업그레이드 후:
두 번째 그래프는 Pectra 업그레이드 이후 블록 도착 분포를 보여줍니다. 대륙별 구분이 아닌 전체 평균 분포가 2.33초 지점에서 56ms 향상되었습니다. 흥미롭게도, 슬롯 시작 이후 3.917초가 지난 지점에서 분포의 꼬리 부분이 95번째 백분위수 지점에서 22ms 증가한 것을 확인할 수 있습니다. 블록 전파 시간 증가는 남미에서 수신된 데이터 포인트의 꼬리 부분 분포가 거의 220ms 지연되었기 때문입니다. 초기 예상과 마찬가지로, 하드웨어 리소스나 인터넷 대역폭에 대한 접근성이 더 제한적인 국가(남미와 아프리카)가 블록 도착 인지도 측면에서 가장 큰 타격을 받는 것으로 보입니다.
클라이언트 간 차이점
다음 그래프는 데이터 포인트를 제출한 클라이언트 유형별로 집계된 블록 도착의 누적 분포 함수(CDF)를 보여줍니다. 그래프는 Pectra 업그레이드 이전과 이후의 차이를 거의 보여주지 않습니다. 최소한의 차이를 보이는 유일한 클라이언트는 Prysm으로, 업그레이드 이전보다 평균 블록 도착 시간이 120ms 더 빠르다고 보고했으며, Teku와 함께 다른 클라이언트보다 먼저 블록을 인식하는 것으로 보입니다. 이 그래프는 CL 클라이언트 간의 성능 비교로만 해석할 수 있지만, 참고용으로만 활용하시기 바랍니다(차트 아래의 면책 조항 참조).
Pectra 업그레이드 전:
Pectra 업그레이드 후:
부인 성명
이러한 CL 클라이언트 수치를 성과 비교로 사용하는 것을 막는 몇 가지 이유는 다음과 같습니다.
- Xatu는 Beacon API 이벤트 스트림 엔드포인트에서 데이터 포인트를 수신했습니다. 이는 표준이지만 각 클라이언트가 내부적으로 구현 방식을 결정합니다. 즉, 각 개발팀은 내부적으로 블록 도착 타임스탬프를 기록할 단계를 결정합니다. 메시지가 gossipsub 검증을 통과하는 즉시 타임스탬프를 기록하는 팀도 있고, 애플리케이션 계층에서 검증을 완료한 후에 타임스탬프를 기록하는 팀도 있습니다.
- 이러한 노드의 분포는 여러 지리적 위치에 걸쳐 균등하거나 동질적이지 않습니다. 즉, 이러한 클라이언트에 제출된 데이터 포인트는 실행 중인 리소스에 따라 크게 영향을 받습니다. 가정적인 예: 단일 노드가 남미에서 보고하고 있고, 이 노드가 네트워크에서 상대적으로 낮은 비율을 차지하는 Nimbus 노드인 경우, Nimbus 격리 지표는 다른 지표보다 더 나빠 보일 가능성이 높습니다.
에포크 기간 동안의 도착
위 그림은 하드포크 전후 네트워크 상태를 전반적으로 보여줍니다. 그러나 특정 시점(예: 하드포크 전환) 동안 갑작스러운 성능 급증이나 저하가 발생할 수 있습니다. 이를 해결하기 위해 다음 차트는 동일한 집계된 블록 도착 시간과 집계를 시계열 형식으로 표시합니다.
다음 그래프는 시간 경과에 따라 가장 관련성이 높은 네 가지 데이터 포인트, 즉 보고된 블록 도착 시간의 최소값, 평균값, 중간값, 그리고 95번째 백분위수를 보여줍니다. 이 그림은 네트워크에서 안정적인 블록 전파를 보여주며, 5월 7일 오전 0시(UTC) 하드포크 12시간 전인 5월 7일 오전 10시(UTC)에 95번째 백분위수 선이 갑자기 4.6초에 도달했습니다. 이 급격한 상승은 몇 시간 동안 지속된 후 회복되어 최종적으로 평균 및 중간 도착 시간을 이전 평균 2.38초에서 약 2.2초로 낮추었습니다.
하드포크 시기에 블록 도착이 급증한 것은 일부 늦게 업데이트된 노드 때문이며, 실제로 메시 안정성을 방해할 수 있습니다.
다시 한번, 블록 도착이 4초에 가깝거나 4초를 넘는 경우가 여전히 5%나 된다는 점을 관찰했습니다. 이는 MEV 건설업체뿐만 아니라 입찰을 수락하는 개별 건설업체에게도 경고가 될 만한 일입니다.
다음 그래프는 대륙별 평균 블록 도착 시간을 집계한 것으로, 여기서 우리는 꽤 많은 다른 스파이크를 볼 수 있습니다.
- 첫 번째 눈에 띄는 급증은 4월 28일 오전 11시 아프리카 지역에서 나타났는데, 평균 블록 도착 시간이 3.6초였고, 이후 정상 수준(10시간 후 약 2.6초)으로 떨어졌습니다.
- 두 번째 급증은 4월 30일 오전 3시에 해당하는데, 당시 아시아 노드의 데이터 포인트는 약 8시간 동안 평균 도착 시간이 최대 3.36초라고 보고했습니다.
- 마지막으로 눈에 띄는 스파이크는 가장 큰 스파이크로, 5월 6일 오후 3시에 시작되어 하드포크 직전에 끝난 총 19시간 동안 지속되었습니다. 이 스파이크는 남미 노드에서 발생했으며, 평균 도착 시간은 약 3.8초로 보고되었습니다.
다음 그래프는 동일한 시간 분포를 보여주지만, 클라이언트당 평균 블록 도착 횟수를 집계한 것입니다. 이 그래프는 Pectra 이전 시대와 유사한 블록 도착 횟수를 보여주지만, 대부분 성능이 향상되었습니다.
- 우리는 여전히 모든 클라이언트가 하드 포크 중과 후에 위에서 논의한 급증을 경험하는 것을 봅니다.
- 프라이즘과 테쿠는 약 300ms 차이로 여전히 가장 먼저 메시지를 받았습니다.
면책 조항 :
다양한 CL 클라이언트에 대한 집계된 배포와 관련된 이전 면책 조항을 여기에서 확인하세요.
테이크어웨이
- Xatu 데이터베이스에 따르면, 블록의 5%가 데이터를 수집하는 제어 노드에 제때 도착하지 않습니다.
- 예상대로 블롭의 증가는 네트워크 핵심에는 영향을 미치지 않았습니다. 특히 예상 시간대에 비콘 블록을 브로드캐스트하고 수신하는 용량 측면에서는 그렇습니다.
- 측정 결과에 따르면, 블록 도착 시간 측면에서 네트워크의 전반적인 성능은 중간값에서 약간 증가했습니다(즉, 블록이 약 200ms 더 일찍 도착함).
- 리소스 측면에서 제한이 있는 꼬리만이 낮은 성과를 보였습니다.
네트워크 대역폭 처리량
Pectra 업그레이드의 주요 관심사 중 하나는 네트워크가 블롭 목표 및 최대값이 50% 증가할 때 어떻게 반응할지였습니다. 더 정확히 말하면, 네트워크가 대역폭 처리량 증가에 저항할 수 있을지, 그리고 여전히 한계를 뛰어넘을 준비가 되어 있을지 여부였습니다( EthPandaOps 게시글 , ProbeLab 게시글 ). 이 연구의 마지막 장에서는 하드포크 기간 동안 ProbeLab이 수행한 업로드 대역폭 처리량 측정 결과를 제시합니다.
다음 그래프는 이더리움 메인넷 네트워크의 노드에 대해 서로 다른 네 지역의 최신 20개 블록 목록을 요청했을 때 측정된 업로드 처리량의 누적 분포(CDF)를 보여줍니다. 첫 번째 그래프는 Pectra 업그레이드 전 측정된 분포를, 그 아래 그래프는 Pectra 업그레이드 후 측정된 분포를 보여줍니다.
흥미롭게도 두 그래프를 비교해 보면, 네트워크 대역폭 처리량 분포에 심각한 변화는 나타나지 않았습니다. 그러나 분포의 하위 절반(1~50번째 백분위수)에서는 가용 처리량이 소폭 감소하는 것을 확인할 수 있습니다.
전반적으로 10번째 백분위수와 50번째 백분위수 모두 1Mbps 감소한 것으로 나타났으며, 이는 홈 및 클라우드 배포의 평균 9.94Mbps와 24.78Mbps에서 각각 8.84Mbps와 23.53Mbps로 감소한 것입니다. 이러한 감소는 미국 서부 및 동남아시아 지역에서 더 두드러지는 것으로 보입니다.
하지만 아직 좋은 소식이 있습니다. 상위 백분위수 분포는 평균보다 더 높은 처리량을 보였으며, 75번째 백분위수와 90번째 백분위수는 각각 홈 및 클라우드 배포 시 37.22Mbps와 61.46Mbps에서 40.26Mbps와 82.12Mbps로 증가했습니다.
Pectra 업그레이드 전:
Pectra 업그레이드 후:
대륙별 대역폭
원격 노드의 위치를 기준으로 분포를 표시하면 다음과 같은 그래프를 얻습니다.
- 아프리카에 위치한 노드들을 대상으로 측정한 결과, 20Mbps가 측정된 피어의 20%에서 12%로 감소했습니다. 그러나 분포의 끝부분에서는 하드포크 이전보다 더 높은 대역폭 제한이 보고되었습니다.
- 상위 백분위수에서 더 높은 처리량을 보이는 추세는 대륙별로 집계된 분포에서도 동일하게 나타납니다. 이 경우 미국과 유럽의 노드가 가장 높은 처리량을 보고합니다. 측정 결과, 해당 지역의 노드 중 20% 이상이 40Mbps 이상의 처리량을 초과하는 것으로 나타났습니다.
Pectra 업그레이드 전:
Pectra 업그레이드 후:
호스팅 유형별 대역폭
Nebula에서 수집한 데이터 덕분에 프로브된 노드의 호스트 유형을 식별하고, 클라우드 서버에 호스팅된 노드의 측정값과 주요 데이터 센터와 연관시킬 수 없는 노드의 측정값을 집계할 수 있습니다.
다음 그래프는 두 경우 모두 분포가 크게 변하지 않았음을 보여줍니다. 유일하게 감지되는 변화는 클라우드 서비스에 호스팅된 노드의 30번째 백분위수에서 1Mbps 정도 소폭 감소한 것뿐입니다. 어느 쪽이든, 분포의 끝부분은 중간값을 넘어서는 처리량 증가를 보여주며, 이는 노드가 요청된 블록 전체에 대해 더 빨리 응답할 수 있었음을 나타냅니다.
Pectra 업그레이드 전:
Pectra 업그레이드 후:
일반적인 처리량만이 우리가 찾는 유일한 것은 아닙니다. 적어도 이더리움에서는 타이밍이 중요합니다. 네트워크에는 특정 시간대가 있으므로, 해당 슬롯 내에서 해당 처리량을 언제 사용할 수 있는지 확인하는 것이 중요합니다. 다음 그래프는 호스트 유형별로 집계된 평균 처리량과 비콘 블록이 요청된 슬롯 시간을 보여줍니다.
패턴은 명확합니다. 슬롯의 첫 번째와 네 번째 초 사이에 클라우드 및 비클라우드 호스팅 노드 모두에서 감소가 나타납니다. 이는 네트워크가 가십서브를 통해 비콘 블록과 블롭 사이드카를 브로드캐스트하는 시점입니다.
Pectra 업그레이드 이전과 이후의 분포를 비교해 보면, 두 가지 모두 슬롯에서 정확히 동일한 패턴을 보인다는 것을 알 수 있습니다. 이 경우 유일한 차이점은 클라우드 노드의 평균 속도가 5~6Mbps, 비클라우드 노드의 평균 속도가 2Mbps 증가했다는 것입니다.
Pectra 업그레이드 전:
Pectra 업그레이드 후:
테이크어웨이
- 3개의 추가 블롭이 있음에도 불구하고 네트워크는 전반적으로 건강한 상태입니다.
- 리소스 가용성 분포의 최상위 노드는 업그레이드 전보다 더 많은 대역폭을 사용할 수 있는 것으로 보입니다.
- 반면, 네트워크 내에서 제한을 많이 받는 피어는 업로드 처리량이 약간 감소한 것을 느꼈지만, 이는 심각하거나 중대한 문제는 아닌 것으로 여겨진다.
- ethresear.ch 게시물[ 링크 ]에 보고된 바와 같이
IDONTWANT메시지 기본형을 추가하면 중복 메시지 수가 확실히 감소하지만 노드 리소스 가용성 스펙트럼 전체에서 대역폭 가용성 측면에서 미치는 영향은 명확하지 않습니다.
결론
포크 이벤트는 노드 운영자들이 업그레이드를 마지막 순간까지 미루는 경향을 드러냈습니다. 대부분의 노드가 새로운 포크를 예정대로 적용했지만, 상당수의 노드는 최대 일주일까지 지연되었습니다. 호환되는 클라이언트 릴리스가 포크 이전에 점진적으로 도입되고 있다는 점은 네트워크 전반에 걸쳐 업그레이드의 시급성이 여전히 부족하다는 것을 보여줍니다.
전파 측면에서는 블록 전달이 아직 적시에 보장되지 않습니다. 약 5%의 블록이 제어 노드에 늦게 도착하고 있으며, 중간 시점은 개선되었지만, 꼬리 부분은 여전히 어려움을 겪고 있습니다. 이는 리소스 가용성이나 네트워크 성능에 지속적인 격차가 있음을 시사합니다.
그럼에도 불구하고, 네트워크는 포크 이후 전반적으로 안정적이고 건강한 상태를 유지하고 있습니다. 추가 블롭(blob) 추가는 큰 차질을 일으키지 않았고, IDONTWANTs 도입으로 상황이 개선되었지만, 크게 개선되지는 않았습니다. 일부 노드는 IDONTWANT 추가 또는 추가 대역폭 자원 제공으로 인해 대역폭 가용성이 향상된 것으로 보이며, 상대적으로 성능이 낮은 노드(아마도 홈 스테이커)는 업로드 처리량이 약간 감소했습니다.
