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

소개

Solana Agave 클라이언트의 최신 버전인 Agave v3.1이 출시되었습니다! 이번 업데이트에는 클라이언트 성능, 검증인 운영, 개발자 경험을 개선하는 폭넓은 업그레이드가 포함됩니다. 또한 프로토콜 내 블록 보상 분배, 의미 있는 상태 보증금(즉, 임대료) 인하, 그리고 무엇보다 곧 도입될 Alpenglow 합의 업그레이드의 기반을 마련하는 여러 중요 기능 게이트 활성화도 포함됩니다.

주목할 만한 Agave 3.1 업데이트

• 재생 중 디스크 I/O 감소
• 더 빠른 클라이언트 재시작
• 2배 빨라진 트랜잭션 처리
• CPI 계정 정보 한도 상향*
• 검증인 투표 계정 V4 및 지연된 수수료율 업데이트*
• Turbine ChaCha 라운드 축소*
• 새로운 명령어 데이터 포인터*
• RPC 개선

* 기능 게이트가 적용된 업그레이드

검증인 운영자와 개발자 모두 최신 개선 사항을 최대한 활용하는 데 필요한 업데이트와 인사이트를 이 가이드에서 확인할 수 있습니다. 각 섹션은 독립적으로 구성되어 있어 가장 관련 있는 주제에 집중할 수 있습니다. 

이 글을 작성하는 시점에 Agave 3.1.8은 메인넷 업그레이드 후보(MUC)로 간주되며, Anza는 이 릴리스가 스테이크의 25%에 도달하도록 도울 자원자를 찾고 있습니다. 검증인 여러분, 지금 업그레이드하세요!

클라이언트 성능 향상

이번 Agave 메이저 릴리스에는 다양한 성능 개선이 포함됩니다. 아래에서 가장 중요한 개선 사항 몇 가지를 살펴보겠습니다.

재생 중 디스크 I/O 감소 

Agave 3.1에서는 재생 중 디스크 활동이 크게 줄었습니다. 아래 이미지는 Agave 3.0이 실제 메인넷 트랜잭션을 처리하는 동안 재생 과정을 10초간 프로파일링한 결과입니다. 디스크 작업(빨간색 마커)이 1,100건을 넘습니다. 디스크에 액세스할 때마다 I/O 대기 시간이 발생해 뱅킹과 재생 모두에 지터가 추가되므로 이는 문제가 됩니다. 

Agave 3.1에서는 재생 중 디스크 I/O가 대폭 감소합니다. 동일한 10초 구간에서 디스크 작업은 80건 미만으로, 93% 줄었습니다. 이를 통해 재생 안정성이 향상되고 디스크 마모가 줄어 디스크 수명을 연장할 수 있습니다.

더 빠른 클라이언트 재시작

AccountsDB 최적화를 중심으로 클라이언트 재시작 성능이 계속해서 크게 향상되고 있습니다. Agave 1.* 메이저 릴리스에서는 재시작에 일반적으로 30분 이상이 걸렸습니다. Agave 2.* 릴리스에서는 10분 미만으로 줄었습니다. Agave 3.1에서는 재시작 시간이 더 짧아져 이제 일반적으로 1분이 채 걸리지 않습니다. 다음 메이저 릴리스인 Agave 4.0에서는 재시작 시간이 30초 미만으로 줄어들 것으로 예상됩니다. 검증인 가동 시간이 더욱 늘어나고 유지보수나 예기치 않은 장애 이후의 복구 시간도 단축됩니다.

더 빠른 트랜잭션 처리

Agave 3.1에는 트랜잭션 처리 효율을 크게 높이는 핵심 수정 사항이 포함됩니다. 이전에는 트랜잭션 처리 파이프라인의 버그로 인해 뱅킹 워커가 트랜잭션 실행보다 Proof of History와의 동기화에 과도한 시간을 사용했습니다. 그 결과 리더 모드에서 클라이언트는 약 61%의 시간 동안 트랜잭션을 능동적으로 스케줄링하지 못했습니다.

Agave 3.1에서 이러한 문제가 해결되면서 뱅킹 워커 스레드는 이제 시간의 ~91%를 트랜잭션 처리에 사용합니다. 그 결과 트랜잭션 처리 속도가 2배 빨라져 처리량이 실질적으로 향상되고 리더 시간을 더 효율적으로 활용할 수 있습니다.

그 밖에 주목할 만한 성능 개선으로는 기본적으로 계정 인덱스 전체를 메모리에 유지하는 기능이 있습니다. 에포크 경계 전환도 크게 개선되어, 2초 넘게 걸리던 작업이 이제 400ms 이내에 완료됩니다. 그 결과 에포크 전환 시 건너뛰는 슬롯이 훨씬 줄었습니다.

네트워크 강화

Anza는 지속적인 스트레스 테스트, 레드팀 활동, 실시간 상황 모니터링을 통해 Agave 클라이언트의 복원력에 적극 투자하고 있습니다. 이전에는 이 작업의 세부 정보를 기밀로 유지했지만, 프로그램이 충분히 성숙함에 따라 이제 이 중요한 작업을 공개할 수 있게 되었습니다. Anza의 전담 invalidator 팀은 매시간 새로운 테스트 세트로 Solana 공개 테스트넷을 적극적으로 공격합니다. 

테스트는 크게 두 가지 범주로 나뉩니다. 첫 번째는 네트워크 계층의 서비스 거부 시나리오에 초점을 맞춰 극한 상황에서의 백프레셔 처리와 부하 차단을 스트레스 테스트합니다. 두 번째는 Solana VM의 한계를 시험하도록 설계된 비정상적이고 적대적인 트랜잭션을 선별해 블록을 생성하는 테스트입니다.

Anza는 공격 시나리오를 체계적으로 구축하고 이에 대한 방어 수단을 개발합니다. 이 작업은 악의적이지만 충분한 정보를 갖고 합리적인 수준으로 스테이킹한 검증인이 할 수 있는 일과, 외부의 자본력 있고 정교한 개발자가 시도할 수 있는 일을 바탕으로 한 현실적인 위협 모델에 기반합니다.

이러한 대비 수준은 12월에 입증되었습니다. 당시 Solana는 수주간 이어진 대규모 DDoS 공격을 견뎌냈으며, 공격 규모는 최고 약 6Tbps로 보고되어 분산 시스템을 겨냥한 역대 최대 규모의 공격 중 하나로 기록되었습니다. 엄청난 규모에도 불구하고 네트워크에서 측정 가능한 영향은 거의 없었으며, 공격 기간 내내 1초 미만의 확인 시간과 안정적인 슬롯 지연 시간을 유지했습니다.

CPI 계정 정보 한도 상향

SIMD-0339: CPI 계정 정보 한도 상향은 Agave 3.1 릴리스 주기 중 메인넷에서 활성화될 예정입니다. 교차 프로그램 호출(CPI)의 계정 정보 한도가 64개에서 255개로 약 4배 늘어나, CPI를 통해 대규모 계정 목록을 전달해야 하는 프로그램 개발자들의 오랜 불편을 해결합니다. 계정 정보는 CPI syscall에 전달되는 직렬화된 계정 메타데이터로, 호출 대상 프로그램이 호출자가 제공한 계정을 읽을 수 있게 합니다.

이전에는 syscall당 CPI 계정 정보가 64개로 제한되었습니다. 이 제약으로 인해 프로그램은 CPI 호출 전에 계정 목록의 중복을 제거하고 재구성해야 했으며, 복잡성과 오버헤드가 늘어났습니다. 실제로 DFlow나 Jupiter 같은 DEX 애그리게이터의 래퍼를 비롯한 많은 실제 프로그램이 이 기준을 자주 초과합니다.

한도 상향과 함께 이 기능 게이트는 CPI에 전달되는 계정 정보와 명령어 계정 수에 따라 확장되는 컴퓨트 유닛 비용 변경 사항도 도입합니다. 이를 통해 프로그램이 계정 사용량을 최소화하도록 하는 인센티브가 유지됩니다. 

한도만 상향되므로 이번 변경은 완전한 하위 호환성을 제공하며 기존 프로그램 동작에 영향을 주지 않습니다.

검증인 투표 계정 V4 및 지연된 수수료율 업데이트

Agave 3.1 릴리스 주기 중 활성화될 기능 게이트 업데이트 두 가지는 검증인 운영자에게 특히 중요합니다. 첫 번째는 SIMD-0185: 투표 계정 V4입니다. Alpenglow, 블록 수익 분배, 수수료율 개선 등 향후 프로토콜 업그레이드를 지원하기 위해 새로운 버전의 투표 계정 상태를 도입합니다.

현재 투표 계정에는 단일 수수료율만 저장됩니다. 하지만 SIMD-0123: 블록 수익 공유에 설명된 프로토콜 내 블록 수익 분배 기능이 도입되면, 검증인은 수입원별로 서로 다른 수수료율을 설정할 수 있어야 합니다.

또한 현재 기본 수수료와 우선순위 수수료를 포함한 모든 블록 수수료 수익은 검증인 신원 계정에 예치됩니다. 신원 계정은 Turbine과 Gossip 같은 핵심 네트워킹 프로토콜의 메시지에 자주 서명해야 하므로 콜드 월렛으로 사용할 수 없습니다. 이는 운영 및 보안 문제를 일으킬 수 있습니다.

투표 계정 V4는 투표 상태에 새로운 필드(아래 코드 블록 참조)를 추가해 이러한 제약을 해결합니다. 검증인은 인플레이션 보상과 블록 수익에 대한 수수료율과 수집 계정을 모두 구성할 수 있습니다. 또한 이 업데이트는 기존 prior_voters 필드를 제거합니다.

pub struct VoteStateV4 {
    pub node_pubkey: Pubkey,
    pub authorized_withdrawer: Pubkey,

    /// REMOVED
    /// commission: u8,

    /// NEW: the collector accounts for validator income
    pub inflation_rewards_collector: Pubkey,
    pub block_revenue_collector: Pubkey,

    /// NEW: basis points (0-10,000) that represent how much of each income
    /// source should be given to this VoteAccount
    pub inflation_rewards_commission_bps: u16,
    pub block_revenue_commission_bps: u16,

    /// NEW: reward amount pending distribution to stake delegators
    pub pending_delegator_rewards: u64,

    /// NEW: compressed bls pubkey for alpenglow
    pub bls_pubkey_compressed: Option<[u8; 48]>

    pub votes: VecDeque<LandedVote>,
    pub root_slot: Option<Slot>,

    /// UPDATED: serialization structure of the AuthorizedVoters map is
    /// unchanged but will now contain entries for the previous epoch.
    pub authorized_voters: AuthorizedVoters,

    /// REMOVED
    /// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,

    pub epoch_credits: Vec<(Epoch, u64, u64)>,
    pub last_timestamp: BlockTimestamp,
}

업데이트의 일부로 수수료율 값은 베이시스 포인트 단위로 저장됩니다. 하지만 Vote Program의 기존 UpdateCommission 명령어는 정수 백분율 수수료율 값만 지원합니다. SIMD-0291: 베이시스 포인트 단위 수수료율이 채택되기 전까지 수수료율은 정수 백분율로 제한됩니다. 따라서 당분간 수수료율 계산에는 정수 백분율 값을 계속 사용해야 합니다.

스테이크 프로그램을 포함해 투표 상태를 읽는 기존 도구나 프로그램은 새로운 투표 계정 버전을 지원하도록 업데이트됩니다.

지연된 수수료율 업데이트

검증인 운영자에게 중요한 두 번째 기능 게이트 업데이트는 SIMD-0249: 수수료율 업데이트 지연입니다. 이 변경을 통해 검증인은 언제든 수수료율 업데이트를 제출할 수 있지만, 최소 한 번의 전체 에포크가 지난 뒤에만 적용됩니다.

투표 프로그램에서 에포크 전반부의 수수료율 인상을 막는 현재 제한이 제거됩니다. 수수료율 변경을 제출할 수 있는 시점을 제한하는 대신, 프로토콜은 변경 사항이 활성화되기 전까지 지연 시간을 적용합니다. 즉, 검증인은 수수료율을 자유롭게 조정할 수 있지만 새로운 요율이 적용되기까지 최소 한 번의 전체 에포크를 기다려야 합니다.

이 지연은 스테이크 위임자에게도 도움이 됩니다. 예정된 수수료율 변경에 대응할 수 있도록 한 번의 전체 에포크 동안 사전 고지하기 때문입니다. 특히 악의적인 검증인이 보상을 가로채기 위해 에포크 경계 직전에 수수료율을 일시적으로 100%까지 올린 뒤 곧바로 정상 수준으로 되돌리는 이른바 “수수료율 러그” 관행을 차단합니다.

상태 보증금(임대료) 인하

일반적으로 “임대료”라고 부르는 높은 상태 보증금 요건은 Solana 개발자의 장기적인 확장을 제한하는 가장 중요한 요소 중 하나입니다. 현재 메인넷의 상태 보증금은 기가바이트당 스토리지 비용이 약 100만 달러에 달할 정도로 비쌉니다. 예를 들어 새로운 토큰 계정(ATA) 하나를 생성하려면 0.002 SOL보다 조금 더 필요하며, 현재 가격으로 약 0.25달러입니다. 이 때문에 대규모 직접 토큰 에어드롭은 비용 부담이 지나치게 커집니다. 토큰 계정 생성 비용을 보조하거나 최종 사용자에게 전가해야 하는 소액 결제 및 스테이블코인 결제 애플리케이션에도 마찰이 생깁니다.

이 부담을 줄이기 위한 첫 단계는 Agave 3.1 릴리스 주기 중 활성화될 예정인 SIMD-0194: 임대료 면제 임계값 폐기입니다. 이는 스토리지 비용을 실질적으로 낮추고 단순화하려는 광범위한 노력의 시작입니다. 애플리케이션이 상태 관련 자본 요건이라는 과도한 부담 없이 수백만 명의 사용자로 확장할 수 있게 됩니다. 이와 함께 상태 보증금 비용을 직접 해결하고 임대료를 추가로 낮추기 위한 SIMD 세 가지도 현재 추진 중입니다.

SIMD-0194는 향후 임대료 업데이트를 단순화합니다. 현재 온체인 프로그램에서 계정의 임대료 면제 여부를 계산하는 작업은 비교적 비용이 큽니다. 현재 `Rent::minimum_balance` 계산은 부동소수점(f64) 연산을 사용하며 호출당 약 256 컴퓨트 유닛을 소비합니다. SIMD-0194에서는 임대료 면제 로직에서 부동소수점 연산을 제거해 이를 단 8 CU로 줄입니다.

이는 exempt_threshold(f64) 필드를 폐기하여 프로그램이 임대료 면제 상태를 판단할 때 부동소수점 계산을 수행할 필요를 없애는 방식으로 구현됩니다.

변경의 일부로 lamports_per_byte_year는 lamports_per_byte로 이름이 바뀌고, 기본값은 3480에서 6960으로 2배 증가합니다. 임대료 면제는 역사적으로 2년분의 임대료를 보유하는 것으로 정의되었기 때문입니다. 중요한 점은 이번 업데이트가 계정의 임대료 면제에 필요한 금액을 변경하지 않는다는 것입니다. 값의 표현 및 계산 방식을 단순화하고 표준화할 뿐입니다.

이번 업데이트는 완전한 하위 호환성을 제공하며 기존에 배포된 프로그램에는 영향을 주지 않습니다.

향후 전망: SIMD-0437

올해 후반에 도입될 것으로 예상되는 추가 임대료 관련 SIMD 중 가장 중요한 것은 SIMD-0437: `lamports_per_byte`를 696으로 점진적 인하입니다. 이 제안은 `lamports_per_byte`를 6960에서 696으로 점진적으로 낮춰 장기 상태 보증금 비용을 10분의 1로 줄이는 체계적인 일정을 제시합니다.

SIMD-0437은 단 한 번에 50%를 인하하도록 제안했던 이전 SIMD-0436을 대체합니다. 대신 SIMD-0437은 6333 → 5080 → 2575 → 1322 → 696으로 이어지는 더욱 세분화된 5단계 인하 일정을 도입합니다.

변경을 여러 단계로 나누면 네트워크가 시간에 따른 상태 증가를 관찰하고 평가할 수 있습니다. 또한 논란이 가장 큰 인하 조치를 별도 단계로 분리해 더욱 명확하게 논의하고 거버넌스를 진행할 수 있습니다.

그 밖의 주목할 만한 Agave 3.1 릴리스 주기 업데이트

데이터 샤드 32개와 코딩 샤드 32개를 엄격하게 적용

현재 Turbine은 FEC 세트당 가변적인 수의 샤드를 허용합니다. 이 동작은 의미 있는 이점 없이 불필요한 복잡성만 더합니다. 수신자가 인덱스 경계를 파악하려면 코딩 샤드가 필요하므로 샤드 인덱스 검증도 더 어려워집니다. 곧 활성화될 SIMD-0317: 데이터 샤드 32개 + 코딩 샤드 32개 적용 기능 게이트는 FEC 세트마다 정확히 32개의 데이터 샤드와 32개의 코딩 샤드를 요구해 이 동작을 표준화합니다. 또한 이 변경은 이중 제안 탐지 기능을 강화하며, 향후 슬래싱 페널티 같은 집행 메커니즘에 활용됩니다.

정적 명령어 한도

현재 최상위 명령어가 64개를 초과하는 트랜잭션은 초기 정제 검사를 통과하지만 런타임에 실패합니다. 실패가 확실한 트랜잭션이 파이프라인에 진입해 스케줄러 리소스를 소비하므로 불필요한 스케줄러 작업이 발생합니다.

곧 활성화될 SIMD-0160: 정적 명령어 한도 기능 게이트는 트랜잭션 정제 단계에서 명령어 64개 한도를 적용해 이 문제를 해결합니다. 이 변경에 따라 최상위 명령어가 64개를 초과하는 트랜잭션(CPI 호출 포함)은 정제에 실패하고 즉시 거부됩니다.

Turbine ChaCha 라운드 축소

SIMD-0332: Turbine의 ChaCha 라운드를 20회에서 8회로 축소는 Turbine의 블록 데이터 전파 성능을 작지만 의미 있게 개선합니다. 현재 Turbine은 블록 전파 트리를 구성할 때 ChaCha20을 사용해 스테이크 가중 검증인의 순서를 결정론적으로 섞습니다. 이러한 무작위 순서는 검열 공격을 방지하는 데 중요하지만 추가적인 연산 오버헤드가 발생합니다.

ChaCha 라운드는 결정론적 스크램블러 역할을 하며, 각 라운드에서 변환을 적용해 출력의 무작위성을 더욱 높입니다. 라운드가 많을수록 암호학적 보안은 강화되지만 컴퓨트 비용도 증가합니다.

Agave가 XDP로 전환하면서 재전송이 거의 즉시 이루어지게 되었고, 이제 가중 셔플 단계가 런타임의 대부분을 차지합니다. 샤드당 약 ~1마이크로초가 걸리는 상황에서 셔플을 ChaCha20에서 ChaCha8로 줄이면 검열 저항성에 충분한 무작위성을 유지하면서도 병목 현상을 방지할 수 있습니다.

새로운 명령어 데이터 포인터

현재 sBPF 프로그램은 명령어 데이터를 찾기 위해 직렬화된 입력 영역의 계정 섹션을 파싱해야 합니다. 직렬화 레이아웃에서 계정이 명령어 데이터보다 앞에 배치되므로, 프로그램은 명령어 데이터 세그먼트에 도달하기 전에 모든 계정 항목을 순회해야 합니다. 이로 인해 주로 또는 전적으로 명령어 데이터를 처리하는 프로그램에 불필요한 작업이 발생합니다.

곧 활성화될 SIMD-0321: VM 레지스터 2 명령어 데이터 포인터 기능 게이트는 프로그램 진입점에서 VM 레지스터 r2에 명령어 데이터를 가리키는 64비트 포인터를 제공해 이 문제를 개선합니다. 이 포인터는 입력 영역의 명령어 데이터 섹션 시작점을 직접 참조합니다. 따라서 프로그램은 계정 섹션을 먼저 파싱하지 않고도 명령어 데이터에 즉시 액세스할 수 있습니다. 파싱 오버헤드를 제거해 컴퓨트 유닛 소비를 줄입니다.

호환성 참고: 이 기능은 현재 진입점에서 r2를 읽지 않는 프로그램에만 하위 호환됩니다. 이전에 진입점의 r2에 있던 초기화되지 않은 값이나 쓰레기 값에 잘못 의존하는 프로그램은 이 기능이 활성화되면 작동하지 않습니다.

RPC 개선

이제 getProgramAccounts RPC 엔드포인트는 잘못된 형식의 필터가 제공될 때 올바른 JSON-RPC 오류를 반환합니다. 이전에는 유효하지 않은 필터를 조용히 무시했기 때문에 RPC 호출이 필터링되지 않은 쿼리로 대체되었습니다. 이로 인해 예기치 않게 비용이 큰 요청이 실행되고 RPC 노드에 불필요한 부하가 발생하는 경우가 많았습니다. 이번 개선으로 잘못된 필터는 명확한 오류를 반환합니다. 실수로 리소스 집약적인 쿼리가 실행되는 것을 방지하고 디버깅도 훨씬 쉬워집니다.

또한 simulateTransaction() 및 **sendTransaction()**의 사전 검사 단계에서 발생하는 서명 검증 실패는 이제 JSON-RPC API 오류(-32003)로 throw되지 않습니다. 대신 시뮬레이션 결과의 err 필드에 TransactionError::SignatureFailure로 반환됩니다.

따라서 이전에 서명 검증 실패를 처리하기 위해 JSON-RPC 예외를 포착하던 애플리케이션은 이제 이러한 오류가 시뮬레이션 응답에 직접 나타날 것으로 예상해야 합니다. 시뮬레이션 결과에서 이미 TransactionError 값을 구체화하고 처리하는 애플리케이션은 이제 해당 검증 지점에서 TransactionError::SignatureFailure를 받을 수 있습니다.

결론

Agave v3.1은 디스크 I/O 감소, 더 빠른 트랜잭션 처리, 향상된 RPC 오류 처리 등 다양한 성능 개선과 최적화를 제공하는 대규모 클라이언트 업그레이드입니다. Agave는 네트워크 강화에서도 눈에 띄는 진전을 이루었으며, 적대적인 환경에서 더욱 강한 복원력을 제공합니다. 또한 이번 릴리스는 상태 보증금을 의미 있게 낮추기 위한 첫 단계입니다.

Anza는 Linux 커널에 패치를 제출하는 작업을 포함해 전체 스택에 걸쳐 개선 사항을 출시하는 업계 유일의 핵심 개발팀으로서 계속 차별화하고 있습니다. Agave 3.1이 곧 네트워크를 구동하게 되면서 Solana는 확장 역량을 계속 입증하고 있습니다.

다음 이정표는 Agave 4.0과 현재 5월 초로 예정된 Alpenglow 테스트넷 출시입니다.

추가 자료

• Agave 3.1 릴리스 일정
• 기능 게이트 추적 일정
• Agave 3.1 변경 로그
• Agave 3.1 풀 리퀘스트