신규: Parsed Events Scan API를 사용해 보세요
Agave 4.4 업데이트 배너
블로그/업데이트

Agave 4.4 업데이트: 꼭 알아야 할 모든 것

연구원X의 Lostin
읽는 데 7분

소개

Agave 4.4에서 Solana의 핵심 검증인 클라이언트는 Alpenglow 도입을 바탕으로 블록 검증을 단순화하고, 스테이킹 보상 계산을 효율화하며, 프로그램과 계정 데이터를 저장하는 데 필요한 SOL을 줄입니다. 이러한 변경 사항은 일상적인 운영 효율을 높이는 동시에 비동기 실행을 위한 기반을 더욱 강화합니다. 최근 목표 슬롯 시간이 200ms로 단축되면서 에포크가 약 하루로 줄어들었고, 기능 게이트를 훨씬 더 빠르게 활성화할 수 있게 되었습니다.

Agave 4.4 릴리스 주기의 주요 업데이트

  • 유효하지 않은 수수료 지불자 허용: 비동기 실행을 지원하기 위한 핵심 단계
  • 프로그램 크기 자동 조정: 프로그램 업그레이드 시 초과 임대료 환불
  • 샤드 표준화: 프로토콜이 이제 데이터 32개, 코딩 32개로 구성된 FEC 세트를 강제 적용
  • 비활성 스테이크 정리: 보상 계산에서 비활성 스테이크 제외
  • 임대료 인하: 상태 보증금을 90% 인하하는 계획의 마지막 3단계

유효하지 않은 수수료 지불자 허용

SIMD-0290: 수수료 지불자 제약 완화의 기능 게이트는 Agave 4.4 릴리스 주기 중 활성화될 예정입니다. 이에 따라 SOL 부족 등의 이유로 수수료 지불자 검증에 실패한 트랜잭션이 블록에 포함될 때의 처리 방식이 달라집니다. 이전에는 이러한 트랜잭션이 포함되면 블록 전체가 무효화되었습니다. 새로운 합의 규칙에서는 트랜잭션이 블록에 남지만 검증인은 실행을 건너뛰며 계정 상태도 변경하지 않습니다.

수수료 지불자의 잔액은 앞선 트랜잭션이 실행되면서 달라질 수 있습니다. 따라서 모든 트랜잭션에 유효한 수수료 지불자를 요구하면 검증인은 블록의 유효성을 판단하기 전에 일부 선행 트랜잭션을 실행해야 합니다. 수수료 지불자 검증 실패를 건너뛴 트랜잭션으로 처리하면 이러한 의존성이 사라집니다.

이는 검증인이 실행을 완료하기 전에 블록과 트랜잭션 순서에 합의할 수 있는 비동기 실행을 위한 기반입니다. 실행은 별도로 진행되며 합의된 트랜잭션을 계정 상태에 적용합니다. Solana는 더 짧은 블록 시간과 여러 동시 블록 제안자 같은 향후 개선 사항을 지원하기 위해 이 설계로 전환하고 있습니다.

Agave는 건너뛴 트랜잭션을 무연산으로 처리합니다. 명령을 실행하지 않고 수수료도 지불하지 않습니다. 다만 요청한 전체 리소스 예산 또는 기본 리소스 예산에 따라 블록 용량을 계속 사용하므로 리더가 포함할 수 있는 수가 제한됩니다. 또한 이 구현은 검증인이 블록을 재생할 때 해당 트랜잭션을 허용하더라도 리더가 블록 생성 중 이를 필터링할 수 있도록 합니다.

SIMD-0290은 유효 기간 지정자로 최근 블록 해시를 사용하는 트랜잭션에만 적용됩니다. 영구 nonce 트랜잭션에는 추가 처리가 필요하며, 이는 SIMD-0297: 유효하지 않은 nonce 트랜잭션 제약 완화에서 별도로 다룹니다. 이 변경 사항은 완전한 하위 호환성을 제공하므로 이전에 유효했던 모든 트랜잭션과 블록은 계속 유효합니다.

업그레이드 시 프로그램 크기 자동 조정

Agave 4.4에는 SIMD-0433: Loader V3: 프로그램 데이터를 ELF 길이로 설정의 기능 게이트 활성화가 포함됩니다. 이에 따라 프로그램 업그레이드 시 컴파일된 프로그램 코드를 저장하는 계정의 크기가 자동으로 조정됩니다.

Loader v3(현재 Solana 프로그램 배포 및 업그레이드에 사용되는 기본 로더)는 프로그램의 컴파일된 ELF 바이너리를 업그레이드 권한 같은 메타데이터와 함께 ProgramData 계정에 저장합니다. 이전에는 개발자가 이 계정을 확장할 수만 있었고 축소할 수는 없었습니다. 따라서 더 작은 바이너리로 업그레이드해도 사용하지 않는 공간이 남았으며, 이 공간을 임대료 면제 상태로 유지하는 데 필요한 SOL도 계정에 계속 잠겨 있었습니다.

이 변경으로 Upgrade 명령은 메타데이터 헤더와 새 ELF 길이에 맞춰 계정 크기를 조정합니다. 바이너리가 더 작아지면 초과 lamport가 남은 자금을 받도록 지정된 업그레이드의 잔여금 계정으로 반환됩니다. 바이너리가 더 크면 계정이 자동으로 확장되므로 일반적인 업그레이드에서 별도의 확장 단계가 필요하지 않습니다. ProgramData 및 버퍼 계정에는 새로운 임대료 요건을 충족할 만큼 충분한 lamport가 이미 있어야 합니다. 그렇지 않으면 업그레이드가 실패합니다.

따라서 더 작은 바이너리를 도입하는 개발자는 다음 업그레이드에서 SOL을 회수할 수 있습니다. 이전에 예약해 둔 여유 용량도 제거됩니다. CPI를 통해 호출하는 업그레이드에는 계정 증가 한도 10KiB가 계속 적용됩니다. 이보다 크게 늘리려면 사전에 확장하거나 최상위 업그레이드 명령을 사용해야 합니다. 개발자는 환불액이 원하는 수신자에게 전달되도록 업그레이드 전에 잔여금 계정의 대상을 확인해야 합니다.

이 변경은 개발자가 Pinocchio처럼 더 새롭고 성능이 뛰어난 라이브러리와 프레임워크로 업그레이드하도록 유도합니다. 또한 Accounts DB에서 프로그램이 차지하는 공간도 줄입니다.

샤드 표준화

Agave 4.4에는 SIMD-0317: 데이터 샤드 32개 + 코딩 샤드 32개 강제 적용에 명시된 Solana 블록 전파 규칙 강화가 포함됩니다. 이를 통해 검증인이 블록 데이터를 배포하고 재구성하는 데 사용하는 구조가 표준화됩니다.

Solana는 Turbine을 통해 블록을 배포합니다. Turbine은 블록 데이터를 샤드로 나누고 여러 검증인 계층을 거쳐 전달합니다. 샤드는 데이터 샤드와 복구 정보가 담긴 코딩 샤드를 결합한 순방향 오류 정정(FEC) 세트로 그룹화됩니다. 데이터 32개, 코딩 32개로 올바르게 구성된 세트에서는 수신자가 64개 샤드 중 아무 32개만으로 원본 데이터를 재구성할 수 있어 패킷 손실을 견디는 데 도움이 됩니다.

각 샤드에는 세트의 Merkle 루트로 연결되는 Merkle 증명도 포함되며, 이는 리더의 서명으로 인증됩니다. 64개 샤드로 구성된 세트에서는 리프와 루트 사이의 6개 레벨에 해당하는 6개 항목이 증명에 포함됩니다. Agave의 증명 크기 검사는 이 고정된 32:32 구조에 필요한 크기를 요구합니다.

클라이언트는 이미 세트마다 데이터 샤드 32개와 코딩 샤드 32개를 생성하지만, 수신 검증인은 지금까지 더 유연한 구성을 허용했습니다. SIMD-0317은 고정된 32:32 구조를 프로토콜 요건으로 지정해 이러한 차이를 해소합니다. 이를 통해 검증이 단순해집니다. 수신자는 코딩 샤드가 세트의 크기를 알려줄 때까지 기다리지 않고 유효한 샤드 인덱스 경계를 판단할 수 있습니다.

고정된 구조는 리더가 동일한 데이터의 상충하는 버전을 배포하는 이중 전파 감지도 단순화합니다. 서로 다른 Merkle 루트와 유효한 리더 서명을 가진 동일한 FEC 세트의 샤드 2개는 이러한 충돌의 증거가 됩니다. 따라서 형식을 표준화하면 구현 복잡성이 줄고 이중 전파도 더 쉽게 식별할 수 있습니다.

보상 계산에서 비활성 스테이크 제외

Agave 4.4 릴리스 주기에는 SIMD-0599: 스테이크 위임에서 비활성 스테이크 제거의 기능 게이트 활성화가 포함됩니다. 이는 각 에포크가 시작될 때 분할 에포크 보상을 처리하는 과정에서 검증인이 비활성 스테이크 계정을 다루는 방식을 단순화합니다. 비활성 스테이크 계정은 임대료 면제 최저액을 초과하는 SOL을 보유할 수 있지만 활성 상태이거나 활성화 중인 스테이크는 없습니다. 해당 SOL은 위임되지 않았거나 비활성화가 완전히 끝난 상태입니다.

이러한 계정은 프로토콜 보상을 받지 않지만, 포함 여부에 따라 보상 배포 파티션 수와 계정 상태를 추적하는 데 사용되는 lattice 해시가 달라질 수 있습니다. 모든 검증인 클라이언트가 이 동작을 정확하게 재현해야 하므로 합의에 중요한 코드에 불필요한 복잡성이 더해집니다.

이 변경은 보상 대상 에포크 동안 비활성 상태였던 스테이크를 제외하고, 활성화 중이거나 활성 상태이거나 비활성화 중인 스테이크는 유지합니다. 따라서 새 에포크가 시작될 때 비활성 상태가 된 스테이크 계정도 비활성화 중이던 이전 에포크에서 획득한 보상을 계속 받습니다.

추가 임대료 인하

Agave 4.4에서는 Solana의 단계적 임대료 인하 계획 중 마지막 3단계가 활성화될 예정입니다. SIMD-0437에 명시된 계획에 따라 계정 스토리지의 바이트당 최소 잔액은 5단계에 걸쳐 기존 6,960 lamport에서 696 lamport로 낮아집니다. 즉, 90% 인하됩니다.

활성화새로운 바이트당 lamport기존 대비 총인하율
SIMD-0437-32,575~ 63%
SIMD-0437-41,322~ 81%
SIMD-0437-569690%

각 활성화에는 별도의 기능 게이트가 있어 네트워크가 다음 단계로 진행하기 전에 계정 생성과 상태 증가에 미치는 영향을 평가할 수 있습니다.

이 요건을 낮추면 개발자와 사용자가 토큰 계정, PDA 및 기타 온체인 상태를 생성할 때 투입해야 하는 자본이 줄어듭니다. 대규모 결제 서비스처럼 사용자를 대신해 계정 생성 비용을 부담하는 애플리케이션에 특히 유용합니다.

Ghost의 추정치에 따르면 3백만 SOL(~$300m) 이상을 회수할 수 있습니다. 사용자가 계정의 초과 SOL을 회수하도록 돕는 여러 도구도 개발되었습니다.

결론

Agave 4.4의 주요 변경 사항은 Alpenglow를 기반으로 하며, 오랫동안 기다려 온 스테이킹 보상, 프로그램 배포, 계정 비용 개선을 진전시킵니다. 이러한 변화는 Solana를 더 빠르고 접근성 높은 네트워크로 발전시킵니다. 다음은 Breakpoint London이며, 이후 Agave 4.5가 이어집니다.

추가 자료

Helius 구독하기

최신 Solana 개발 소식을 확인하고 새 게시물 알림을 받아보세요

확대 이미지