Fusaka 업그레이드 이후 이더리움 노드 타입별 대역폭 변화

Fusaka 업그레이드 이후 이더리움 노드 타입별 대역폭 변화 이더리움 인프라 운영과 관련한 오픈소스 빌더 ethPandaOps팀이 Fusaka의 PeerDAS 적용과 관련해 devnet 환경에서 검증한 멋진 자료가 있어 공유드립니다. Fusaka의 가장 핵심 업그레이드는 PeerDAS 인데요, 이더리움은 L2들이 롤업을 하는 Blob이라는 공간을 따로 가지고 있습니다. L2사용이 늘면서 이 Blob공간을 빠르게 확장할 수요가 생깁니다. 하지만, 무한정 Blob을 늘리는것은 이더리움 L1의 스팩 증가를 불러오고 이는 중앙화로 이어지게 됩니다. 때문에 이더리움은 이 Blob공간을 샤딩해 밸리데이터들이 나눠 보관하는 샤딩(댕크샤딩)을 도입할 계획을 세우는데, 그 중간 단계가 이번에 도입하는 PeerDAS라고 할수 있습니다. PeerDAS를 통해 Blob의 수를 단계적으로 확장 하더라도 개별 노드의 네트워크의 대역폭 증가를 최소화 할수 있게 됩니다. ethPandaOps팀이 이를 실험한 과정과 결과가 원문 자료에 나와있습니다. 이 포스트에는 결론 부분만 옮기자면, 다음과 같습니다. Fusaka 이후 이더리움 메인넷의 Blob을 14개까지 확장할 경우를 기준으로 노드 타입별 요구 스팩과 대역폭의 변화입니다. 1️⃣ 슈퍼노드(4096ETH 이상의 스테이킹 노드) 슈퍼노드의 경우, 128개 컬럼의 서브넷을 전부 subscribe 해야 하며, blob의 데이터 보유 기간인 18일간 모든 데이터를 보관해야 합니다. 슈퍼노드들은 사실상 이더리움 네트워크의 "백본" 역할을 하게 되며, P2P대역폭과 DA처리를 위한 컴퓨팅 부하가 가장 큽니다. 네트워크 대역폭은 평시 100Mb/s이상이며, 피크시 400Mb/s에 달하는 수준의 대역폭을 감당해야 합니다. 일반적으로 인프라 전문 인력과 설비를 기반으로 한 전문 밸리데이터 팀이 운영하게 됩니다. 2️⃣ 홈 스테이커(솔로 스테이커, 32ETH) 32ETH를 스테이킹하는 솔로 스테이커 노드의 경우, 자신에게 배정된 8개의 서브넷과 랜덤 컬럼에 대한 서브넷만 구독하면 됩니다. 슈퍼노드 대비 1/8 미만의 데이터만 처리하면 되기 때문에, 요구 스팩이 크게 감소하게 됩니다. 대역폭의 경우, 약 25Mb/s 수준의 대역폭이면 충분합니다. 3️⃣ 풀노드 (밸리데이터 없음) 밸리데이팅을 하지 않는 단순 풀노드의 경우, 4개 컬럼 서브넷만 구독하면 됩니다. 슈퍼노드 대비 정확히 1/32 데이터만 처리하면 되며, P2P대역폭, 디스크 사용량, CPU요구사항이 크게 감소합니다. 네트워크 참여를 위해 4 8Mb/s 라는 매우 적은 대역폭으로 네트워크에 참여가 가능해집니다. 이처럼 Fusaka 업그레이드를 통해 blob의 수를 6개 에서 14개까지 늘리더라도, 홈 스테이커들과 풀노드의 스팩은 크게 증가하지 않거나 오히려 지금보다도 줄어들게 됩니다. 물론 네트워크의 백본이 되는 슈퍼노드들은 더 많은 데이터 가용성(DA) 부하를 감당해야 하므로 요구 스팩이 증가합니다. 하지만 그 부담을 스테이킹 규모가 크고 인프라 여력이 있는 전문 운영자들이 주로 맡도록 설계했다는 점이 PeerDAS의 핵심입니다. 덕분에 네트워크 참여를 위한 최소 스팩을 낮추면서도 L2 확장에 필요한 blobspace를 단계적으로 늘릴 수 있는 길이 열린 것입니다.