메인 콘텐츠로 건너뛰기

페이지가 마지막으로 업데이트됨: 2026년 2월 23일

Fusaka

모두가 기대하던 이더리움 Fusaka 업그레이드가 2025년 12월 3일에 라이브되었습니다

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

Fusaka의 개선 사항

블롭 확장

PeerDAS

이것은 Fusaka 포크의 핵심 내용으로, 이번 업그레이드에 추가된 주요 기능입니다. 레이어 2는 현재 데이터를 이더리움에 블롭 형태로 게시합니다. 블롭은 레이어 2를 위해 특별히 생성된 임시 데이터 유형입니다. Fusaka 이전에는 모든 전체 노드가 데이터 존재를 보장하기 위해 모든 블롭을 저장해야 했습니다. 블롭 처리량이 증가함에 따라 이 모든 데이터를 다운로드하는 것은 감당할 수 없을 정도로 리소스 집약적이 됩니다.

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

이를 통해 노드의 하드웨어 및 대역폭 요구 사항을 감당할 수 있는 수준으로 유지하면서 블롭 확장을 활성화하여 레이어 2의 수수료를 낮추고 더 큰 확장을 이룰 수 있습니다.

PeerDAS에 대해 더 알아보기

참고 자료:

블롭 파라미터 전용 포크

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

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

이러한 조정된 업그레이드는 일반적으로 많은 변경 사항을 포함하고 많은 테스트를 필요로 하므로 시간이 걸립니다. 변화하는 레이어 2 블롭 요구에 더 빨리 적응하기 위해, 블롭 파라미터 전용 포크는 업그레이드 일정을 기다릴 필요 없이 블롭을 늘리는 메커니즘을 도입합니다.

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

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

블록당 평균 블롭 수와 업그레이드에 따른 목표 증가를 보여주는 차트

그래프 출처: 이더리움 블롭 - @hildobby, Dune Analytics (opens in a new tab)

참고 자료: EIP-7892 기술 사양 (opens in a new tab)

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

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

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

  • 블롭 수수료 시장은 항상 혼잡에 반응합니다.
  • 레이어 2는 노드에 강제하는 계산량의 의미 있는 일부를 최소한 지불합니다.
  • 실행 레이어(EL)의 기본 수수료 급등은 더 이상 블롭 수수료를 1wei에 머물게 할 수 없습니다.

참고 자료:

L1 확장

히스토리 만료 및 더 간단한 영수증

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

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

참고 자료: 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의 거듭제곱이므로 여러 클라이언트에 걸쳐 구현하기 쉽습니다. 이 새로운 최대 트랜잭션 크기는 Pectra 이전의 평균 블록 크기와 유사하여 이더리움의 모든 작업에 대한 합리적인 한도가 됩니다.

참고 자료: EIP-7825 기술 사양 (opens in a new tab)

MODEXP 가스 비용 증가

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

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

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

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

비용을 실제 처리 시간에 더 잘 맞춤으로써 MODEXP는 더 이상 블록 검증에 너무 오랜 시간이 걸리게 하지 않습니다. 이 변경은 미래에 이더리움의 블록 가스 리밋을 안전하게 늘리기 위한 여러 가지 목표 중 하나입니다.

참고 자료: EIP-7883 기술 사양 (opens in a new tab)

RLP 실행 블록 크기 제한

이는 블록이 허용되는 크기에 대한 상한을 만듭니다. 이는 네트워크를 통해 전송되는 것에 대한 제한이며, 블록 내부의 작업을 제한하는 가스 리밋과는 별개입니다. 블록 크기 상한은 10MiB이며, 모든 것이 잘 맞고 깨끗하게 전파되도록 합의 데이터를 위해 작은 여유 공간(2MiB)이 예약되어 있습니다. 이보다 큰 블록이 나타나면 클라이언트는 이를 거부합니다. 매우 큰 블록은 네트워크 전체에 전파되고 검증되는 데 더 오랜 시간이 걸리며 합의 문제를 일으키거나 DoS 벡터로 남용될 수 있으므로 이것이 필요합니다. 또한 합의 레이어의 가십은 이미 ~10MiB 이상의 블록을 전달하지 않으므로, 실행 레이어를 해당 제한에 맞추면 "일부는 보고, 다른 일부는 버리는" 이상한 상황을 피할 수 있습니다.

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

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) 클라이언트 팀이 Fusaka를 위해 오늘날의 4,500만을 초과하여 기본 가스 리밋을 높이도록 조정합니다. 이것은 정보 제공용 EIP이지만, 클라이언트에게 개발넷에서 더 높은 한도를 테스트하고, 안전한 값에 수렴하며, Fusaka 릴리스에 해당 수치를 포함하도록 명시적으로 요청합니다.

개발넷 계획은 약 6,000만 스트레스(합성 부하가 있는 전체 블록)와 반복적인 증가를 목표로 합니다. 연구에 따르면 최악의 블록 크기 병리학은 약 1억 5,000만 미만에서는 제약이 되지 않아야 합니다. 배포는 트랜잭션 가스 리밋 상한(EIP-7825)과 함께 이루어져야 하므로 한도가 높아져도 단일 트랜잭션이 지배할 수 없습니다.

참고 자료: EIP-7935 기술 사양 (opens in a new tab)

UX 개선

결정적 제안자 미리 보기

EIP-7917을 통해 비콘 체인은 다음 에포크의 예정된 블록 제안자를 인지하게 됩니다. 어떤 검증자가 미래의 블록을 제안할지에 대한 결정적 뷰를 가지면 사전 확인 (opens in a new tab)을 활성화할 수 있습니다. 이는 예정된 제안자와의 약속으로, 실제 블록을 기다리지 않고 사용자 트랜잭션이 해당 블록에 포함될 것을 보장합니다.

이 기능은 검증자가 제안자 일정을 조작할 수 있는 극단적인 경우를 방지하므로 클라이언트 구현과 네트워크 보안에 이점을 줍니다. 미리 보기는 또한 구현의 복잡성을 줄여줍니다.

참고 자료: EIP-7917 기술 사양 (opens in a new tab)

선행 0 개수(CLZ) 연산 코드

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

참고 자료: EIP-7939 기술 사양 (opens in a new tab)

secp256r1 곡선 지원을 위한 사전 컴파일

고정 주소 0x100에 내장된 패스키 스타일의 secp256r1(P-256) 서명 검사기를 도입합니다. 이는 많은 L2에서 이미 채택한 동일한 호출 형식을 사용하고 극단적인 사례를 수정하므로, 해당 환경용으로 작성된 계약이 변경 없이 L1에서 작동합니다.

UX 업그레이드! 사용자에게는 장치 네이티브 서명과 패스키를 사용할 수 있게 합니다. 지갑은 Apple Secure Enclave, Android Keystore, 하드웨어 보안 모듈(HSM) 및 FIDO2/WebAuthn에 직접 액세스할 수 있습니다. 시드 구문이 없고, 온보딩이 더 원활하며, 최신 앱처럼 느껴지는 다중 요소 흐름을 제공합니다. 이는 더 나은 UX, 더 쉬운 복구 및 수십억 개의 장치가 이미 수행하는 것과 일치하는 계정 추상화 패턴을 제공합니다.

개발자에게는 160바이트 입력을 받아 32바이트 출력을 반환하므로 기존 라이브러리와 L2 계약을 쉽게 포팅할 수 있습니다. 내부적으로는 유효한 호출자를 손상시키지 않고 까다로운 극단적인 사례를 제거하기 위해 무한대 점 및 모듈러 비교 검사를 포함합니다.

참고 자료:

메타

eth_config JSON-RPC 메서드

이것은 현재 실행 중인 포크 설정을 노드에 문의할 수 있는 JSON-RPC 호출입니다. 이는 current, next, last 세 가지 스냅샷을 반환하여 검증자와 모니터링 도구가 클라이언트가 예정된 포크를 위해 정렬되었는지 확인할 수 있도록 합니다.

실질적으로 이는 2025년 초 Holesky 테스트넷에서 Pectra 포크가 가동되었을 때 발견된 단점을 해결하기 위한 것입니다. 사소한 잘못된 구성으로 인해 완결되지 않는 상태가 발생했습니다. 이를 통해 테스트 팀과 개발자는 주요 포크가 개발넷에서 테스트넷으로, 그리고 테스트넷에서 메인넷으로 이동할 때 예상대로 작동하는지 확인할 수 있습니다.

스냅샷에는 다음이 포함됩니다: chainId, forkId, 예정된 포크 활성화 시간, 활성 상태인 사전 컴파일, 사전 컴파일 주소, 시스템 계약 종속성 및 포크의 블롭 일정.

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

참고 자료: EIP-7910 기술 사양 (opens in a new tab)

자주 묻는 질문

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

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

하드 포크 이후 ETH는 어떻게 변환해야 하나요?

  • ETH에 대한 조치 필요 없음: 이더리움 Fusaka 업그레이드 이후 ETH를 변환하거나 업그레이드할 필요가 없습니다. 계정 잔액은 그대로 유지되며, 현재 보유한 ETH는 하드 포크 이후에도 기존 형태로 계속 접근 가능합니다.
  • 사기 주의! ETH를 "업그레이드"하라고 지시하는 사람은 사기를 시도하는 것입니다. 이번 업그레이드와 관련하여 여러분이 해야 할 일은 전혀 없습니다. 여러분의 자산은 전혀 영향을 받지 않을 것입니다. 정보를 잘 아는 것이 사기를 막는 가장 좋은 방어책임을 기억하세요. 여러분의 자산은 전혀 영향을 받지 않을 것입니다. 정보를 잘 아는 것이 사기를 막는 가장 좋은 방어책임을 기억하세요.

사기 인식과 예방에 대해 더 알아보기/security/

왜 얼룩말인가요?

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

2022년의 더 머지는 실행 레이어와 합의 레이어의 결합을 알리기 위해 판다 (opens in a new tab)를 마스코트로 사용했습니다. 그 이후로 각 포크마다 비공식적으로 마스코트가 선택되었고 업그레이드 시 클라이언트 로그에 ASCII 아트로 나타납니다. 그저 재미있게 기념하는 방법일 뿐입니다.

L2 확장을 위해 어떤 개선 사항이 포함되어 있나요?

PeerDAS는 포크의 주요 기능입니다. 이는 롤업에 더 많은 확장성을 제공하는 데이터 가용성 샘플링(DAS)을 구현하며, 이론적으로 블롭 공간을 현재 크기의 최대 8배까지 확장합니다. 블롭 수수료 시장도 개선되어 혼잡에 효율적으로 대응하고 L2가 노드에 부과하는 계산 및 공간에 대해 의미 있는 수수료를 지불하도록 보장합니다.

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

블롭 파라미터 전용 포크는 PeerDAS가 활성화된 후 완전한 조정 업그레이드를 기다릴 필요 없이 블롭 수(target 및 max 모두)를 지속적으로 늘리는 메커니즘을 제공합니다. 각 증가는 Fusaka를 지원하는 클라이언트 릴리스에 사전 구성되도록 하드코딩됩니다.

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

BPO 일정은 어떻게 되나요?

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

예시는 다음과 같을 수 있습니다.

  • Fusaka 이전: target 6, max 9
  • Fusaka 활성화 시점: target 6, max 9
  • BPO1, Fusaka 활성화 몇 주 후: target 10, max 15, 3분의 2 증가
  • BPO2, BPO1 몇 주 후: target 14, max 21

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

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

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

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

"결정적 제안자 미리 보기"(EIP-7917)가 검증자에게 영향을 미치나요?

이 변경 사항은 검증자 클라이언트의 기능 방식을 바꾸지는 않지만, 검증자 임무의 미래에 대한 더 많은 통찰력을 제공할 것입니다. 새로운 기능에 맞춰 모니터링 툴링을 업데이트해야 합니다.

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

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

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

전체 노드

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

솔로 스테이커

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

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

대규모 검증자

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

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

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

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

Fusaka는 새로운 사소한 변경 사항과 기능으로 EVM을 강화합니다.

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

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

일반 사용자 트랜잭션은 이 한도에 도달하는 것과는 거리가 멉니다. 크고 복잡한 디파이 작업, 대규모 스마트 계약 배포 또는 여러 계약을 대상으로 하는 일괄 트랜잭션과 같은 특정 극단적인 사례는 이 변경의 영향을 받을 수 있습니다. 이러한 트랜잭션은 더 작은 트랜잭션으로 나누거나 다른 방식으로 최적화해야 합니다. 한도에 도달할 가능성이 있는 트랜잭션을 제출하기 전에 시뮬레이션을 사용하세요.

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

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

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

기존 스마트 계약에 변경 사항이 있나요?

Fusaka는 기존 계약을 깨뜨리거나 동작을 변경하는 직접적인 영향이 없습니다. 실행 레이어에 도입된 변경 사항은 하위 호환성을 고려하여 만들어졌지만, 항상 극단적인 경우와 잠재적인 영향에 유의해야 합니다.

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

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

더 읽어보기

페이지 마지막 업데이트됨: 2026년 2월 23일

mnelsonBTm (opens in a new tab)
konopkjak (opens in a new tab)
architr4a (opens in a new tab)
+5

이 문서가 도움이 되셨나요?