본문으로 건너뛰기

푸사카 🦓

페이지 편집 (opens in a new tab)

이더리움의 큰 기대를 모았던 푸사카 업그레이드가 2025년 12월 3일에 활성화되었습니다

푸사카 네트워크 업그레이드는 펙트라의 뒤를 이어 모든 이더리움 사용자와 개발자를 위한 더 많은 새로운 기능을 제공하고 경험을 개선합니다. 이 이름은 실행 계층 업그레이드인 오사카(Osaka)와 풀루(Fulu) 별의 이름을 딴 합의 레이어 버전으로 구성됩니다. 이더리움의 두 부분 모두 이더리움의 확장성, 보안 및 사용자 경험을 미래로 이끄는 업그레이드를 받게 됩니다.

푸사카 업그레이드는 이더리움의 장기적인 개발 목표 중 한 단계에 불과합니다. 프로토콜 로드맵과 이전 업그레이드에 대해 자세히 알아보세요.

Ethereum's latest upgrade: Fusaka

A short overview of Ethereum's Fusaka upgrade featuring Ethereum Foundation contributors and ecosystem builders.

대본과 함께 시청하기 

푸사카의 개선 사항

블롭 확장

PeerDAS

이것은 푸사카 포크의 _헤드라이너_이자 이번 업그레이드에 추가된 주요 기능입니다. 레이어 2(l2)는 현재 레이어 2(l2)를 위해 특별히 생성된 임시 데이터 유형인 블롭으로 이더리움에 데이터를 게시합니다. 푸사카 이전에는 모든 풀 노드가 데이터가 존재하는지 확인하기 위해 모든 블롭을 저장해야 했습니다. 블롭 처리량이 증가함에 따라 이 모든 데이터를 다운로드해야 하는 것은 리소스 집약적이어서 감당할 수 없게 됩니다.

데이터 가용성 샘플링(DAS) (opens in a new tab)을 사용하면 모든 블롭 데이터를 저장하는 대신 각 노드가 블롭 데이터의 하위 집합을 담당하게 됩니다. 블롭은 네트워크의 노드 전체에 균일하게 무작위로 분산되며 각 풀 노드는 데이터의 1/8만 보유하므로 이론적으로 최대 8배까지 확장할 수 있습니다. 데이터의 가용성을 보장하기 위해, 잘못되거나 누락된 데이터의 확률을 암호학적으로 무시할 수 있는 수준(1020분의 1에서 1024분의 1)으로 낮추는 방법을 사용하여 전체의 기존 50%에서 데이터의 모든 부분을 재구성할 수 있습니다.

이는 노드에 대한 하드웨어 및 대역폭 요구 사항을 유지하는 동시에 블롭 확장을 가능하게 하여 레이어 2(l2)에 대해 더 적은 수수료로 더 많은 확장을 제공합니다.

PeerDAS에 대해 자세히 알아보기

리소스:

블롭 매개변수 전용(Blob-Parameter-Only) 포크

레이어 2(l2)는 이더리움을 확장합니다. 네트워크가 성장함에 따라 이더리움에 더 많은 데이터를 게시해야 합니다. 이는 시간이 지남에 따라 이더리움이 사용할 수 있는 블롭의 수를 늘려야 함을 의미합니다. PeerDAS를 사용하면 블롭 데이터를 확장할 수 있지만 점진적이고 안전하게 수행해야 합니다.

이더리움은 동일한 규칙에 대한 합의가 필요한 수천 개의 독립적인 노드에서 실행되는 코드이기 때문에 웹사이트 업데이트를 배포하는 방식처럼 블롭 수를 늘리는 것과 같은 변경 사항을 단순히 도입할 수 없습니다. 모든 규칙 변경은 모든 노드, 클라이언트 및 검증자 소프트웨어가 미리 결정된 동일한 블록 이전에 업그레이드하는 조정된 업그레이드여야 합니다.

이러한 조정된 업그레이드에는 일반적으로 많은 변경 사항이 포함되고 많은 테스트가 필요하며 시간이 걸립니다. 변화하는 레이어 2(l2) 블롭 요구 사항에 더 빠르게 적응하기 위해 블롭 매개변수 전용 포크는 해당 업그레이드 일정을 기다릴 필요 없이 블롭을 늘리는 메커니즘을 도입합니다.

블롭 매개변수 전용 포크는 가스 한도와 같은 다른 구성과 유사하게 클라이언트에서 설정할 수 있습니다. 주요 이더리움 업그레이드 사이에 클라이언트는 target 및 max 블롭을 예를 들어 9와 12로 늘리는 데 동의할 수 있으며, 그런 다음 노드 운영자는 해당 소규모 포크에 참여하기 위해 업데이트합니다. 이러한 블롭 매개변수 전용 포크는 언제든지 구성할 수 있습니다.

덴쿤 업그레이드에서 네트워크에 블롭이 처음 추가되었을 때 목표는 3이었습니다. 펙트라에서는 6으로 증가했으며, 푸사카 이후에는 이러한 주요 네트워크 업그레이드와 독립적으로 지속 가능한 속도로 증가할 수 있습니다.

Chart showing average blob count per block and increasing targets with upgrades

그래프 출처: Ethereum Blobs - @hildobby, Dune Analytics (opens in a new tab)

리소스: EIP-7892 기술 사양 (opens in a new tab)

실행 비용에 의해 제한되는 블롭 기본 수수료

레이어 2(l2)는 데이터를 게시할 때 두 가지 비용을 지불합니다. 블롭 수수료와 해당 블롭을 검증하는 데 필요한 실행 가스입니다. 실행 가스가 지배적인 경우 블롭 수수료 경매는 1 Wei까지 떨어져 가격 신호로서의 기능을 멈출 수 있습니다.

EIP-7918은 모든 블롭 아래에 비례하는 예약 가격을 고정합니다. 예약 가격이 명목 블롭 기본 수수료보다 높으면 수수료 조정 알고리즘은 블록을 목표 초과로 간주하고 수수료를 낮추는 것을 중단하여 정상적으로 증가하도록 허용합니다. 결과적으로:

  • 블롭 수수료 시장은 항상 혼잡에 반응합니다.
  • 레이어 2(l2)는 노드에 강제하는 컴퓨팅의 의미 있는 부분 이상을 지불합니다.
  • 실행 계층(EL)의 기본 수수료 급증으로 인해 더 이상 블롭 수수료가 1 Wei에 머물지 않습니다.

리소스:

레이어 1 (l1) 확장

기록 만료 및 더 간단한 영수증

2025년 7월, 이더리움 실행 클라이언트는 부분적인 기록 만료를 지원하기 시작했습니다 (opens in a new tab). 이는 이더리움이 계속 성장함에 따라 노드 운영자에게 필요한 디스크 공간을 줄이기 위해 머지 (opens in a new tab) 이전의 기록을 삭제했습니다.

이 EIP는 포크가 실제로 변경 사항을 구현하지 않기 때문에 "핵심 EIP"와 별도의 섹션에 있습니다. 이는 클라이언트 팀이 푸사카 업그레이드까지 기록 만료를 지원해야 한다는 공지입니다. 실질적으로 클라이언트는 언제든지 이를 구현할 수 있지만 업그레이드에 추가함으로써 구체적으로 할 일 목록에 올리고 이 기능과 함께 푸사카 변경 사항을 테스트할 수 있게 되었습니다.

리소스: EIP-7642 기술 사양 (opens in a new tab)

MODEXP에 대한 상한 설정

지금까지 MODEXP 프리컴파일은 사실상 모든 크기의 숫자를 허용했습니다. 이로 인해 테스트하기 어렵고 남용하기 쉬우며 클라이언트 안정성에 위험이 되었습니다. EIP-7823은 명확한 한도를 설정합니다. 각 입력 숫자는 최대 8192비트(1024바이트) 길이일 수 있습니다. 이보다 큰 것은 거부되고 트랜잭션의 가스가 소각되며 상태 변경이 발생하지 않습니다. 가스 한도 계획 및 보안 검토를 복잡하게 만드는 극단적인 경우를 제거하면서 실제 요구 사항을 매우 편안하게 충족합니다. 이 변경 사항은 사용자나 개발자 경험에 영향을 주지 않으면서 더 많은 보안 및 DoS 보호를 제공합니다.

리소스: EIP-7823 기술 사양 (opens in a new tab)

트랜잭션 가스 한도 상한

EIP-7825 (opens in a new tab)는 트랜잭션당 16,777,216(2^24) 가스의 상한을 추가합니다. 블록 가스 한도를 높일 때 단일 트랜잭션의 최악의 경우 비용을 제한함으로써 선제적인 DoS 강화를 수행합니다. 검증 및 전파를 모델링하기 쉽게 만들어 가스 한도를 높여 확장을 다룰 수 있게 해줍니다.

왜 정확히 2^24 가스일까요? 오늘날의 가스 한도보다 편안하게 작고, 실제 컨트랙트 배포 및 무거운 프리컴파일에 충분히 크며, 2의 거듭제곱이므로 클라이언트 전체에서 구현하기 쉽습니다. 이 새로운 최대 트랜잭션 크기는 펙트라 이전의 평균 블록 크기와 유사하므로 이더리움의 모든 작업에 대한 합리적인 한도입니다.

리소스: EIP-7825 기술 사양 (opens in a new tab)

MODEXP 가스 비용 증가

MODEXP는 RSA 서명 검증 및 증명 시스템에 사용되는 큰 수 수학의 한 유형인 모듈러 거듭제곱을 계산하는 프리컴파일 내장 함수입니다. 이를 통해 컨트랙트는 직접 구현할 필요 없이 이러한 계산을 직접 실행할 수 있습니다.

개발자와 클라이언트 팀은 현재 가스 가격 책정이 특정 입력에 필요한 컴퓨팅 성능을 과소평가하는 경우가 많기 때문에 MODEXP를 블록 가스 한도를 늘리는 데 주요 장애물로 파악했습니다. 이는 MODEXP를 사용하는 하나의 트랜잭션이 전체 블록을 처리하는 데 필요한 시간의 대부분을 차지하여 네트워크 속도를 늦출 수 있음을 의미합니다.

이 EIP는 다음과 같이 실제 계산 비용과 일치하도록 가격 책정을 변경합니다.

  • 최소 요금을 200가스에서 500가스로 인상하고 일반 비용 계산에서 EIP-2565의 1/3 할인을 제거합니다.
  • 지수 입력이 매우 길 때 비용을 더 급격하게 늘립니다. 지수(두 번째 인수로 전달하는 "거듭제곱" 숫자)가 32바이트 / 256비트보다 길면 추가 바이트마다 가스 요금이 훨씬 빠르게 상승합니다.
  • 큰 밑(base) 또는 모듈러스(modulus)에 대해서도 추가 요금을 부과합니다. 다른 두 숫자(밑과 모듈러스)는 최소 32바이트로 가정되며, 둘 중 하나가 더 크면 크기에 비례하여 비용이 상승합니다.

비용을 실제 처리 시간과 더 잘 일치시킴으로써 MODEXP는 더 이상 블록 검증에 너무 많은 시간이 걸리게 할 수 없습니다. 이 변경 사항은 향후 이더리움의 블록 가스 한도를 안전하게 늘리기 위한 여러 가지 변경 사항 중 하나입니다.

리소스: EIP-7883 기술 사양 (opens in a new tab)

RLP 실행 블록 크기 제한

이것은 블록이 허용되는 크기에 대한 상한선을 만듭니다. 이것은 네트워크를 통해 전송되는 것에 대한 제한이며 블록 내부의 _작업_을 제한하는 가스 한도와는 별개입니다. 블록 크기 상한은 10 MiB이며, 모든 것이 깔끔하게 맞고 전파되도록 합의 데이터를 위해 예약된 작은 허용량(2 MiB)이 있습니다. 블록이 그보다 크게 나타나면 클라이언트는 이를 거부합니다. 매우 큰 블록은 네트워크 전체에 확산되고 검증되는 데 더 오래 걸리며 합의 문제를 일으키거나 DoS 벡터로 악용될 수 있기 때문에 이것이 필요합니다. 또한 합의 레이어의 가십은 이미 ~10 MiB를 초과하는 블록을 전달하지 않으므로 실행 계층을 해당 한도에 맞추면 "일부에서는 보이고 다른 일부에서는 삭제되는" 이상한 상황을 피할 수 있습니다.

핵심 세부 사항: 이것은 RLP로 인코딩된 실행 블록 크기에 대한 상한입니다. 총 10 MiB이며 비콘 블록 프레이밍을 위해 2 MiB의 안전 여유가 예약되어 있습니다. 실질적으로 클라이언트는 다음을 정의합니다.

MAX_BLOCK_SIZE = 10,485,760 바이트 및

SAFETY_MARGIN = 2,097,152 바이트,

그리고 RLP 페이로드가 다음을 초과하는 모든 실행 블록을 거부합니다.

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

목표는 최악의 경우 전파/검증 시간을 제한하고 합의 레이어 가십 동작과 일치시켜 가스 회계를 변경하지 않고 재구성/DoS 위험을 줄이는 것입니다.

리소스: EIP-7934 기술 사양 (opens in a new tab)

기본 가스 한도를 6천만으로 설정

2025년 2월에 가스 한도를 3,000만에서 3,600만으로(이후 4,500만으로) 올리기 전까지 이 값은 머지(2022년 9월) 이후 변경되지 않았습니다. 이 EIP는 일관된 확장을 우선순위로 삼는 것을 목표로 합니다.

EIP-7935는 실행 계층(EL) 클라이언트 팀을 조정하여 푸사카의 기본 가스 한도를 현재의 4,500만 이상으로 높입니다. 정보성 EIP이지만 클라이언트에게 데브넷에서 더 높은 한도를 테스트하고 안전한 값으로 수렴하여 푸사카 릴리스에 해당 숫자를 포함하도록 명시적으로 요청합니다.

데브넷 계획은 ~6,000만 스트레스(합성 부하가 있는 전체 블록) 및 반복적인 증가를 목표로 합니다. 연구에 따르면 최악의 블록 크기 병리는 ~1억 5,000만 미만에서 묶이지 않아야 합니다. 한도가 높아짐에 따라 단일 트랜잭션이 지배할 수 없도록 롤아웃은 트랜잭션 가스 한도 상한(EIP-7825)과 쌍을 이루어야 합니다.

리소스: EIP-7935 기술 사양 (opens in a new tab)

UX 개선

결정론적 제안자 예측(Deterministic proposer lookahead)

EIP-7917을 통해 비콘 체인은 다음 에포크의 다가오는 블록 제안자를 인식하게 됩니다. 어떤 검증자가 미래의 블록을 제안할지에 대한 결정론적 관점을 가지면 사전 확인(preconfirmations) (opens in a new tab)이 가능해집니다. 이는 실제 블록을 기다리지 않고 사용자 트랜잭션이 해당 블록에 포함될 것임을 보장하는 다가오는 제안자와의 커밋먼트입니다.

이 기능은 검증자가 제안자 일정을 조작할 수 있는 엣지 케이스를 방지하므로 클라이언트 구현 및 네트워크 보안에 이점을 제공합니다. 예측을 통해 구현의 복잡성도 줄일 수 있습니다.

리소스: EIP-7917 기술 사양 (opens in a new tab)

선행 제로 카운트(CLZ) 연산 코드

이 기능은 작은 EVM 명령어인 **선행 제로 카운트(CLZ)**를 추가합니다. EVM의 거의 모든 것은 256비트 값으로 표시되며, 이 새로운 연산 코드는 앞에 0 비트가 몇 개 있는지 반환합니다. 이는 더 효율적인 산술 연산을 가능하게 하므로 많은 명령어 세트 아키텍처에서 일반적인 기능입니다. 실제로 이것은 오늘날의 수동 비트 스캔을 한 단계로 축소하므로 첫 번째 설정 비트를 찾거나 바이트를 스캔하거나 비트 필드를 구문 분석하는 것이 더 간단하고 저렴해집니다. 연산 코드는 낮고 고정된 비용이며 기본 추가와 동등한 것으로 벤치마킹되어 바이트코드를 줄이고 동일한 작업에 대한 가스를 절약합니다.

리소스: EIP-7939 기술 사양 (opens in a new tab)

secp256r1 곡선 지원을 위한 프리컴파일

이미 많은 레이어 2(l2)에서 채택한 것과 동일한 호출 형식을 사용하고 엣지 케이스를 수정하여 고정 주소 0x100에 내장된 패스키 스타일의 secp256r1(P-256) 서명 검사기를 도입하므로 해당 환경을 위해 작성된 컨트랙트가 변경 없이 레이어 1 (l1)에서 작동합니다.

UX 업그레이드! 사용자의 경우 기기 기본 서명하기 및 패스키가 잠금 해제됩니다. 지갑은 Apple Secure Enclave, Android 키스토어, 하드웨어 보안 모듈(HSM) 및 FIDO2/WebAuthn을 직접 활용할 수 있습니다. 시드 구문이 없고 더 원활한 온보딩이 가능하며 최신 앱처럼 느껴지는 다중 요소 흐름을 제공합니다. 그 결과 더 나은 UX, 더 쉬운 복구, 수십억 대의 기기가 이미 수행하는 것과 일치하는 계정 추상화 패턴이 생성됩니다.

개발자의 경우 160바이트 입력을 받아 32바이트 출력을 반환하므로 기존 라이브러리 및 레이어 2(l2) 컨트랙트를 쉽게 이식할 수 있습니다. 내부적으로는 유효한 호출자를 손상시키지 않고 까다로운 엣지 케이스를 제거하기 위해 무한원점(point-at-infinity) 및 모듈러 비교 검사를 포함합니다.

리소스:

메타

eth_config JSON-RPC 메서드

이것은 노드에 실행 중인 포크 설정이 무엇인지 물어볼 수 있는 JSON-RPC 호출입니다. 검증자와 모니터링 도구가 클라이언트가 다가오는 포크에 맞춰 정렬되어 있는지 확인할 수 있도록 current, next 및 last의 세 가지 스냅샷을 반환합니다.

실질적으로 이것은 2025년 초 홀스카이 테스트넷에서 펙트라 포크가 활성화되었을 때 사소한 잘못된 구성으로 인해 최종화되지 않는 상태가 발생한 단점을 해결하기 위한 것입니다. 이는 테스트 팀과 개발자가 데브넷에서 테스트넷으로, 테스트넷에서 메인넷으로 이동할 때 주요 포크가 예상대로 작동하는지 확인하는 데 도움이 됩니다.

스냅샷에는 chainId, forkId, 계획된 포크 활성화 시간, 활성화된 프리컴파일, 프리컴파일 주소, 시스템 컨트랙트 종속성 및 포크의 블롭 일정이 포함됩니다.

이 EIP는 포크가 실제로 변경 사항을 구현하지 않기 때문에 "핵심 EIP"와 별도의 섹션에 있습니다. 이는 클라이언트 팀이 푸사카 업그레이드까지 이 JSON-RPC 메서드를 구현해야 한다는 공지입니다.

리소스: EIP-7910 기술 사양 (opens in a new tab)

자주 묻는 질문(FAQ)

이 업그레이드는 모든 이더리움 노드와 검증자에게 영향을 미치나요?

예, 푸사카 업그레이드에는 실행 클라이언트와 합의 클라이언트 모두에 대한 업데이트가 필요합니다. 모든 주요 이더리움 클라이언트는 높은 우선순위로 표시된 하드 포크를 지원하는 버전을 출시할 것입니다. 클라이언트 GitHub 리포지토리, 디스코드 채널 (opens in a new tab), EthStaker 디스코드 (opens in a new tab)에서 이러한 릴리스가 언제 제공되는지 확인하거나 이더리움 블로그를 구독하여 프로토콜 업데이트를 받을 수 있습니다. 업그레이드 후 이더리움 네트워크와의 동기화를 유지하려면 노드 운영자는 지원되는 클라이언트 버전을 실행하고 있는지 확인해야 합니다. 클라이언트 릴리스에 대한 정보는 시간에 민감하므로 사용자는 최신 세부 정보에 대한 최신 업데이트를 참조해야 합니다.

하드 포크 이후 ETH는 어떻게 변환할 수 있나요?

  • ETH에 대해 아무런 조치도 필요하지 않습니다: 이더리움 푸사카 업그레이드 이후에는 ETH를 변환하거나 업그레이드할 필요가 없습니다. 계정 잔액은 동일하게 유지되며 현재 보유하고 있는 ETH는 하드 포크 이후에도 기존 형태로 계속 액세스할 수 있습니다.
  • 사기에 주의하세요! ETH를 "업그레이드"하라고 지시하는 사람은 사기를 치려는 것입니다. 이 업그레이드와 관련하여 수행해야 할 작업은 없습니다. 귀하의 자산은 전혀 영향을 받지 않습니다. 정보를 지속적으로 파악하는 것이 사기에 대한 최선의 방어임을 기억하세요.

사기 인식 및 예방에 대한 자세한 내용

얼룩말은 무엇인가요?

얼룩말은 푸사카의 개발자가 선택한 "마스코트"입니다. 그 줄무늬가 노드가 특정 열 서브넷을 보관하고 각 피어 슬롯에서 몇 개의 다른 열을 샘플링하여 블롭 데이터를 사용할 수 있는지 확인하는 PeerDAS의 열 기반 데이터 가용성 샘플링(DAS)을 반영하기 때문입니다.

2022년의 머지는 실행 계층과 합의 레이어의 결합을 알리기 위해 판다를 마스코트로 사용했습니다 (opens in a new tab). 그 이후로 각 포크에 대해 마스코트가 비공식적으로 선택되었으며 업그레이드 시 클라이언트 로그에 ASCII 아트로 표시됩니다. 이것은 단지 축하하는 재미있는 방법일 뿐입니다.

레이어 2(l2) 확장을 위해 어떤 개선 사항이 포함되어 있나요?

PeerDAS는 포크의 주요 기능입니다. 롤업에 대한 더 많은 확장성을 잠금 해제하는 데이터 가용성 샘플링(DAS)을 구현하여 이론적으로 블롭 공간을 현재 크기의 최대 8배까지 확장합니다. 블롭 수수료 시장도 혼잡에 효율적으로 반응하고 레이어 2(l2)가 블롭이 노드에 부과하는 컴퓨팅 및 공간에 대해 의미 있는 수수료를 지불하도록 보장하기 위해 개선될 것입니다.

BPO 포크는 어떻게 다른가요?

블롭 전용 매개변수(Blob Only Parameter) 포크는 전체 조정된 업그레이드를 기다릴 필요 없이 PeerDAS가 활성화된 후 블롭 수(목표 및 최대 모두)를 지속적으로 늘리는 메커니즘을 제공합니다. 각 증가는 푸사카를 지원하는 클라이언트 릴리스에 사전 구성되도록 하드코딩됩니다.

사용자 또는 검증자로서 각 BPO에 대해 클라이언트를 업데이트할 필요가 없으며 푸사카와 같은 주요 하드 포크만 따르면 됩니다. 이는 이전과 동일한 관행이며 특별한 조치가 필요하지 않습니다. 하드 포크 이후에 수정 또는 최적화가 따를 수 있으므로 업그레이드 및 BPO 전후에 클라이언트를 모니터링하고 주요 릴리스 사이에도 업데이트를 유지하는 것이 좋습니다.

BPO 일정은 어떻게 되나요?

BPO 업데이트의 정확한 일정은 푸사카 릴리스와 함께 결정될 것입니다. 프로토콜 공지 (opens in a new tab) 및 클라이언트의 릴리스 노트를 따르세요.

예상되는 모습의 예:

  • 푸사카 이전: 목표 6, 최대 9
  • 푸사카 활성화 시: 목표 6, 최대 9
  • BPO1, 푸사카 활성화 몇 주 후: 목표 10, 최대 15, 2/3 증가
  • BPO2, BPO1 몇 주 후: 목표 14, 최대 21

이것이 이더리움(레이어 1 (l1))의 수수료를 낮출까요?

이 업그레이드는 적어도 직접적으로는 레이어 1 (l1)의 가스 수수료를 낮추지 않습니다. 주요 초점은 롤업 데이터를 위한 더 많은 블롭 공간이므로 레이어 2(l2)의 수수료를 낮추는 것입니다. 이는 레이어 1 (l1) 수수료 시장에 약간의 부작용을 미칠 수 있지만 큰 변화는 예상되지 않습니다.

스테이커로서 업그레이드를 위해 무엇을 해야 하나요?

모든 네트워크 업그레이드와 마찬가지로 클라이언트를 푸사카 지원이 표시된 최신 버전으로 업데이트해야 합니다. 메일링 리스트 및 EF 블로그의 프로토콜 공지 (opens in a new tab)의 업데이트를 팔로우하여 릴리스에 대한 정보를 얻으세요. 메인넷에서 푸사카가 활성화되기 전에 설정을 검증하려면 테스트넷에서 검증자를 실행할 수 있습니다. 푸사카는 테스트넷에서 더 일찍 활성화되어 (opens in a new tab) 모든 것이 작동하는지 확인하고 버그를 보고할 수 있는 더 많은 공간을 제공합니다. 테스트넷 포크도 메일링 리스트와 블로그에 공지됩니다.

"결정론적 제안자 예측"(EIP-7917)이 검증자에게 영향을 미치나요?

이 변경 사항은 검증자 클라이언트의 작동 방식을 변경하지 않지만 검증자 임무의 미래에 대한 더 많은 통찰력을 제공합니다. 새로운 기능을 따라잡기 위해 모니터링 도구를 업데이트해야 합니다.

푸사카는 노드 및 검증자의 대역폭 요구 사항에 어떤 영향을 미치나요?

PeerDAS는 노드가 블롭 데이터를 전송하는 방식에 상당한 변화를 가져옵니다. 모든 데이터는 128개의 서브넷에 걸쳐 열(column)이라는 조각으로 나뉘며 노드는 그 중 일부만 구독합니다. 노드가 보관해야 하는 서브넷 열의 양은 구성 및 연결된 검증자 수에 따라 다릅니다. 실제 대역폭 요구 사항은 네트워크에서 허용되는 블롭의 양과 노드 유형에 따라 다릅니다. 푸사카 활성화 시점에 블롭 목표는 이전과 동일하게 유지되지만 PeerDAS를 사용하면 노드 운영자는 블롭의 디스크 사용량과 네트워크 트래픽이 감소하는 것을 볼 수 있습니다. BPO가 네트워크에서 더 많은 수의 블롭을 구성함에 따라 필요한 대역폭은 각 BPO마다 증가합니다.

노드 요구 사항은 푸사카 BPO 이후에도 여전히 권장 여유 범위 (opens in a new tab) 내에 있습니다.

풀 노드

검증자가 없는 일반 노드는 4개의 서브넷만 구독하여 원본 데이터의 1/8에 대한 보관을 제공합니다. 이는 동일한 양의 블롭 데이터로 노드가 이를 다운로드하는 대역폭이 8배 더 작아짐을 의미합니다. 일반 풀 노드의 블롭 디스크 사용량 및 다운로드 대역폭은 약 80% 감소하여 몇 Mb에 불과할 수 있습니다.

솔로 스테이커

노드가 검증자 클라이언트에 사용되는 경우 더 많은 열을 보관해야 하므로 더 많은 데이터를 처리해야 합니다. 검증자가 추가되면 노드는 최소 8개의 열 서브넷을 구독하므로 일반 노드보다 두 배 많은 데이터를 처리하지만 여전히 푸사카 이전보다는 적습니다. 검증자 잔액이 287 ETH를 초과하면 점점 더 많은 서브넷을 구독하게 됩니다.

솔로 스테이커의 경우 이는 디스크 사용량과 다운로드 대역폭이 약 50% 감소함을 의미합니다. 그러나 로컬에서 블록을 빌드하고 모든 블롭을 네트워크에 업로드하려면 더 많은 업로드 대역폭이 필요합니다. 로컬 빌더는 푸사카 시점에 이전보다 2~3배 더 높은 업로드 대역폭이 필요하며 15/21 블롭의 BPO2 목표를 사용하면 최종적으로 필요한 업로드 대역폭은 약 5배 더 높은 100Mbps가 되어야 합니다.

대규모 검증자

구독된 서브넷의 수는 노드에 더 많은 잔액과 검증자가 추가됨에 따라 증가합니다. 예를 들어, 약 800 ETH 잔액에서 노드는 25개의 열을 보관하며 이전보다 약 30% 더 많은 다운로드 대역폭이 필요합니다. 필요한 업로드는 일반 노드와 유사하게 증가하며 최소 100Mbps가 필요합니다.

4096 ETH, 2개의 최대 잔액 검증자에서 노드는 모든 열을 보관하는 '슈퍼노드'가 되므로 모든 것을 다운로드하고 저장합니다. 이러한 노드는 누락된 데이터를 다시 제공하여 네트워크를 적극적으로 치유하지만 훨씬 더 많은 대역폭과 스토리지가 필요합니다. 최종 블롭 목표가 이전보다 6배 더 높기 때문에 슈퍼 노드는 약 600GB의 추가 블롭 데이터를 저장해야 하고 약 20Mbps의 더 빠른 지속 다운로드 대역폭을 가져야 합니다.

예상되는 요구 사항에 대한 자세한 내용을 읽어보세요. (opens in a new tab)

어떤 EVM 변경 사항이 구현되나요?

푸사카는 새로운 사소한 변경 사항과 기능으로 EVM을 공고히 합니다.

새로운 1,600만 가스 한도는 컨트랙트 개발자에게 어떤 영향을 미치나요?

푸사카는 단일 트랜잭션의 최대 크기를 1,670만 (opens in a new tab)(2^24) 가스 단위로 제한합니다. 이는 대략 이전의 평균 블록 크기이므로 전체 블록을 소비할 복잡한 트랜잭션을 수용할 수 있을 만큼 충분히 큽니다. 이 한도는 클라이언트를 보호하여 향후 더 높은 블록 가스 한도에서 잠재적인 DoS 공격을 방지합니다. 확장의 목표는 단일 트랜잭션이 전체 블록을 소비하지 않고 더 많은 트랜잭션이 블록체인에 들어갈 수 있도록 하는 것입니다.

일반 사용자 트랜잭션은 이 한도에 도달하기에는 거리가 멉니다. 크고 복잡한 탈중앙화 금융 (DeFi) 작업, 대규모 스마트 컨트랙트 배포 또는 여러 컨트랙트를 대상으로 하는 일괄 트랜잭션과 같은 특정 엣지 케이스는 이 변경 사항의 영향을 받을 수 있습니다. 이러한 트랜잭션은 더 작은 트랜잭션으로 나누거나 다른 방식으로 최적화해야 합니다. 한도에 도달할 가능성이 있는 트랜잭션을 제출하기 전에 시뮬레이션을 사용하세요.

RPC 메서드 eth_call는 제한되지 않으며 실제 블록체인 한도보다 더 큰 트랜잭션의 시뮬레이션을 허용합니다. 남용을 방지하기 위해 클라이언트 운영자가 RPC 메서드의 실제 한도를 구성할 수 있습니다.

CLZ는 개발자에게 무엇을 의미하나요?

Solidity와 같은 EVM 컴파일러는 내부적으로 0을 세는 새로운 기능을 구현하고 활용할 것입니다. 새로운 컨트랙트는 이러한 종류의 작업에 의존하는 경우 가스 절감의 이점을 얻을 수 있습니다. 잠재적인 절감에 대한 문서는 스마트 컨트랙트 언어의 릴리스 및 기능 공지를 따르세요.

기존 스마트 컨트랙트에 변경 사항이 있나요?

푸사카는 기존 컨트랙트를 손상시키거나 동작을 변경하는 직접적인 영향을 미치지 않습니다. 실행 계층에 도입된 변경 사항은 이전 버전과의 호환성을 유지하면서 이루어지지만 항상 엣지 케이스와 잠재적인 영향을 주시하세요.

ModExp 프리컴파일의 비용이 증가함에 따라 (opens in a new tab) 이에 의존하는 컨트랙트는 실행에 더 많은 가스를 소비하게 됩니다. 컨트랙트가 이에 크게 의존하고 사용자에게 더 비싸진다면 활용 방법을 재고하세요.

컨트랙트를 실행하는 트랜잭션이 비슷한 크기에 도달할 수 있는 경우 새로운 1,670만 한도 (opens in a new tab)를 고려하세요.

더 읽을거리

페이지 최근 업데이트: 2026년 6월 6일

UaittU (opens in a new tab)
architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
+6