Agave v2.3 업데이트: 알아야 할 모든 것

소개

Agave 검증인 클라이언트의 v2.3 릴리스는 Solana의 또 다른 중요한 진전을 의미합니다. 이전 업데이트와 마찬가지로 이번 새 버전에도 네트워크 성능과 개발자 경험을 모두 향상하기 위한 핵심 개선 사항이 포함됐습니다.

주목할 만한 Agave 2.3 업데이트 

• 새로운 TPU 클라이언트 tpu-client-next
• 디스크 I/O 사용량을 줄이는 AccountsDB 최적화
• 이제 검증인 투표 계정을 키로 사용하는 리더 스케줄
• 슬래싱 가능 이벤트 검증
• 기본으로 활성화되는 그리디 스케줄러
• 스냅샷 개선
• gossip 업그레이드
• 더 빨라진 에포크 전환

이 글의 각 섹션은 독립적으로 구성되어 있어 가장 관련 있는 주제로 바로 이동할 수 있습니다. 검증인 운영자, 개발자, 적극적인 사용자 누구에게나 Agave 2.3의 최신 개선 사항을 최대한 활용하는 데 필요한 핵심 정보를 제공하는 종합 가이드입니다.

Anza는 Agave 릴리스 속도를 높이고 있습니다. 2.2 출시 후 3개월도 지나지 않아 버전 2.3이 이미 가동 중이며, 현재 전체 스테이킹의 13%가 새 클라이언트 버전을 실행하고 있습니다. 향후 몇 주 동안 도입률이 빠르게 증가할 것으로 예상됩니다. 그동안 메인넷 기능 게이트 활성화는 출시 과정에서 일시 중단됐으며, 계획된 활성화 순서에 따라 곧 재개될 예정입니다.

새로운 TPU 클라이언트

Agave 2.3은 기존 ConnectionCache를 대체하는 새로운 Transaction Processing Unit(TPU) 클라이언트 구현을 도입합니다. 이 TPU 클라이언트는 QUIC 프로토콜을 사용해 직렬화된 트랜잭션을 네트워크상의 검증인에게 전송합니다. tpu-client-next라는 새로운 설계는 성능을 크게 개선하고 리소스 사용량을 줄이며 전체 아키텍처를 단순화하기 위해 전면 재설계됐습니다.

TPU 클라이언트는 두 가지 주요 상황에서 사용됩니다. 검증인이 다음 리더에게 트랜잭션을 전달하는 ForwardingStage와 RPC가 리더에게 트랜잭션을 중계할 때 사용하는 SendTransactionService입니다.

이전 구현인 ConnectionCache는 UDP와 QUIC 프로토콜을 모두 지원하도록 설계돼 불필요하게 복잡했습니다. ConnectionCache는 명시적인 채널 대신 내부 비동기 큐에 트랜잭션을 저장했고, 빈 패킷을 전송하는 캐시 워밍업 로직도 포함했습니다. Quinn, 즉 Rust로 구현된 QUIC의 엔드포인트 관리와 관련된 지속적인 문제도 있었습니다.

새로운 tpu-client-next는 간결한 비동기 설계로 이러한 문제를 해결합니다. 내부적으로는 개별 워커 태스크가 각 QUIC 연결을 처리하는 에이전트 기반 모델을 따릅니다. 이 워커들은 비동기 채널을 사용해 중앙화된 ConnectionWorkersScheduler와 통신합니다. 

스케줄러가 트랜잭션 배치를 수신하면 설정된 전략에 따라 적절한 워커 집합으로 브로드캐스트합니다. 이 아키텍처는 멀티스트리밍을 완전히 제거해 트래픽 단편화를 줄입니다. 연결도 미리 설정하므로 전송 시점에 새 스트림을 열 때 발생하는 지연 시간을 없앱니다.

tpu-client-next는 뚜렷한 성능 향상을 보여줍니다. 

• 테스트넷 RPC 실험에서 기존 클라이언트와 새 클라이언트는 부하 상황에서 비슷한 평균 TPS를 기록했지만, tpu-client-next는 지터가 눈에 띄게 낮았습니다. 
• 검증인 사용 사례에서 ForwardingStage는 전달된 트랜잭션 양이 10% 증가했고, 트래픽 패턴은 더 안정적이었으며 CPU 사용량은 30% 감소했습니다.
• Anza의 비공개 소스 스트레스 테스트 도구인 **transaction-bench,**는 최신 클라이언트로 구축됐습니다. 이전 벤치 테스트 도구인 bench-tps보다 초당 두 배 많은 트랜잭션을 생성합니다.

tpu-client-next는 완전한 하위 호환성을 제공하며, 이제 Agave 노드의 기본 구현입니다. 문제가 발생하면 운영자는 --use-connection-cache 플래그로 노드를 실행해 이전 구현으로 되돌릴 수 있습니다.

요약하면 tpu-client-next는 다음을 제공합니다.

• 비동기 친화적인 에이전트 기반 아키텍처
• 지터를 줄인 일관된 트래픽
• CPU 및 메모리 사용량 감소
• 설정 가능한 스케줄링 및 큐 정책
• 간소화된 통합과 깔끔한 API 인터페이스

투표 계정을 키로 사용하는 리더 스케줄

Agave 2.3 릴리스 주기의 일부로 Solana는 SIMD-0180: 리더 스케줄의 키로 투표 계정 주소 사용을 활성화합니다. 이 변경으로 네트워크가 블록 생성 예정 검증인을 결정하는 방식이 달라집니다. 리더 스케줄의 기본 키가 검증인 ID 주소에서 투표 계정 주소로 바뀝니다.

이번 마이그레이션은 블록을 생성한 검증인을 특정 스테이킹과 안정적으로 연결할 수 없다는 Solana 프로토콜의 오랜 모호성을 해결합니다. 현재 설계에서는 검증인 ID 주소가 리더 스케줄의 키입니다. 하지만 여러 투표 계정이 동일한 검증인 ID에 위임될 수 있어 특정 슬롯의 블록 생성을 특정 위임 스테이킹 집합까지 추적하기가 어렵습니다.

리더 스케줄의 키로 투표 계정 주소를 사용하면 위임된 스테이킹과 검증인의 리더 역할이 명확하고 직접적으로 연결됩니다. 사소해 보이는 이 변경으로 몇 가지 중요한 기능을 구현할 수 있습니다.

첫째, 3월 공식 거버넌스 투표를 통과한 SIMD-0123의 명세에 따라 블록 보상을 분배하는 데 필요한 기반을 제공합니다. 검증인은 블록 수수료의 커미션 비율을 설정하고 나머지 수익을 위임자에게 비례 배분할 수 있습니다. 이 시스템은 인플레이션 스테이킹 보상에 이미 사용되는 보상 공유 모델을 반영해 검증인과 스테이커 간의 경제적 인센티브를 더욱 긴밀하게 조정합니다.

둘째, 투표 계정 주소를 리더 스케줄의 키로 사용하는 것은 프로그래밍 방식 슬래싱을 활성화하는 데 필수적입니다. 중복 블록을 제출하거나 여러 포크에 투표해 네트워크 규칙을 위반한 검증인에게 페널티를 부과할 수 있습니다. 이는 자연스럽게 다음 업데이트로 이어집니다.

슬래싱 가능 이벤트 검증

슬래싱은 온체인에서 부정행위를 검증하고 위임된 스테이킹 일부를 소각해 악의적인 검증인에게 페널티를 부과하는 메커니즘입니다. 네트워크의 보안이나 안정성을 위협하는 행동을 억제하는 핵심 수단입니다.

슬래싱에는 두 가지 주요 모델이 있습니다.

소셜 슬래싱(Solana의 현행 시스템)

현재 Solana는 소셜 슬래싱이라고 하는 수동 커뮤니티 주도 합의 방식에 의존합니다. 이 모델에서는 검증인이 네트워크 가용성이나 안전성을 훼손하는 등 악의적으로 행동하면 정직한 참여자들이 오프체인에서 조율해 하드 포크를 시작하고, 네트워크를 재시작한 뒤 위반자의 스테이킹을 슬래싱할 수 있습니다. 이 방식은 사례별로 유연하게 판단할 수 있지만 조율 비용이 크고 본질적으로 사후 대응적입니다.

프로그래밍 방식 슬래싱(프로토콜 내 슬래싱)

반면 프로그래밍 방식 슬래싱은 전적으로 온체인에서 집행됩니다. 검증인이 프로토콜 규칙을 위반하면 해당 위반에 대한 암호학적 증명을 전용 프로그램에 제출할 수 있으며, 프로그램이 자동으로 슬래싱을 실행합니다. 이 모델은 사람 간 조율에 대한 의존도를 낮추고 네트워크 운영을 중단하지 않고도 경미한 위반을 제재할 수 있어 확장 가능하고 탈중앙화된 책임 체계의 기반을 마련합니다.

슬래싱에는 두 가지 핵심 단계가 있습니다.

• 오류 탐지 및 귀속: 부정행위와 책임이 있는 검증인을 식별합니다.
• 페널티 집행: 위반자의 스테이킹을 슬래싱해 경제적으로 처벌하고 책임을 묻습니다.

Agave 2.3 릴리스 주기의 일부로 Solana는 SIMD 문서인 SIMD-0204: 슬래싱 가능 이벤트 검증에 설명된 Slashing Program의 기능 게이트를 활성화할 예정입니다. 이는 오류 탐지와 귀속에 중점을 두고 Solana에서 프로그래밍 방식 슬래싱을 구현하기 위한 첫 단계입니다. 누구나 슬래싱 가능한 행동을 신고하고 기록할 수 있는 온체인 프로그램을 도입해 향후 자동 집행을 위한 기반을 마련합니다.

이 프로그램은 스테이킹이나 보상을 변경하지 않으며 위반 사항을 검증하고 기록하기만 합니다. 즉, 검증인의 부정행위에 대한 온체인 기록으로 기능합니다. 초기 프로그램 프로토타입은 Testnet에 배포됐습니다. 예를 들어 DuplicateBlockProof 샘플 트랜잭션을 확인할 수 있습니다. 

이 프로그램은 먼저 중복 블록 생성을 탐지하고 기록하는 데 집중하며, 향후 이중 투표 같은 추가 위반도 지원할 예정입니다. 중요한 점은 프로그래밍 방식 슬래싱이 명확하게 증명할 수 있는 부정행위로 제한된다는 것입니다. 따라서 의도적으로 블록 생성을 늦추거나 MEV를 추출하는 등 더 주관적이거나 시스템적인 문제는 집행하기가 훨씬 어렵고, 슬래싱 프로그램으로 처리될 가능성도 낮습니다.

제출되는 증명에는 동일한 검증인이 서명한 동일 슬롯의 상충하는 샤드 두 개가 포함됩니다. 슬래싱 프로그램은 샤드가 유효한 중복 블록 증명을 구성하는지 확인해 증명을 검증합니다. 두 샤드가 동일한 슬롯에 속하고 위반 검증인이 올바르게 서명했는지 확인합니다. 이 로직은 Solana의 gossip 프로토콜이 포크 선택 과정에서 중복 블록 증명을 처리하는 방식과 같습니다. 

증명이 성공적으로 검증되면 결과는 나중에 참조할 수 있도록 Program-derived Address(PDA)에 저장됩니다. 슬래싱 프로그램에서 getProgramAccounts를 실행하기만 하면 슬래싱 관련 데이터를 보여주는 대시보드를 쉽게 구축할 수 있습니다. 검증인은 이를 통해 위반 신고 여부를 확인하고 필요에 따라 시정 조치를 취할 수 있습니다.

향후 SIMD에서는 위반 유형별 스테이킹 페널티 같은 매개변수를 포함해 슬래싱의 경제적 집행을 다룰 예정입니다. 이러한 결정은 Solana 검증인 운영의 경제성에 영향을 주므로 제안된 모든 변경 사항은 전체 거버넌스 투표의 승인을 받아야 합니다.

더 빨라진 에포크 전환

Agave 2.3은 에포크 전환 속도를 크게 개선합니다. 이제 에포크 보상 계산이 500밀리초 이내에 완료됩니다. 그 결과 건너뛰는 슬롯이 줄고 에포크 경계 부근에서 트랜잭션이 더 안정적으로 반영됩니다.

또한 새 에포크의 첫 번째 리더 슬롯을 건너뛰더라도 Agave 2.3은 보상을 다시 계산하지 않습니다. 대신 이전에 계산한 결과를 재사용해 중복 계산을 없애고 새 에포크를 더 원활하게 시작합니다.

AccountsDB 최적화

이번 릴리스에서는 스토리지 효율성이 크게 개선됐습니다. 디스크 I/O 사용량은 약 75%, 복구 요청량은 약 85% 감소했습니다. 이러한 최적화를 통해 특히 네트워크 부하가 높은 기간에도 노드 성능이 더 일관되고 안정적으로 유지됩니다.

기본으로 활성화되는 그리디 스케줄러

Agave 2.3에서는 그리디 스케줄러가 기본으로 활성화됩니다. 이전의 중앙 스케줄러는 트랜잭션을 정렬하고 종속성 그래프를 구성하는 데 걸리는 시간 때문에 네트워크 부하가 높을 때 병목이 되는 경우가 많았습니다. 새로운 그리디 방식은 단순화된 로직과 더 작은 배치 크기로 트랜잭션 스케줄링을 크게 가속합니다.

그리디 스케줄러에 관한 자세한 내용은 이전 Helius 블로그 게시물에서 확인할 수 있습니다.

Gossip 샤드 버전

Agave 2.3은 gossip 네트워크에서 샤드 버전 일치를 더 엄격하게 적용합니다. 이제 노드의 샤드 버전이 클러스터와 일치하는 경우에만 인바운드 gossip 연결을 설정할 수 있어 잘못 설정된 노드를 조기에 차단할 수 있습니다.

이전에는 스파이 노드가 클러스터의 샤드 버전과 일치하지 않아도 네트워크에 참여할 수 있었습니다. 이번 변경으로 스파이 모드를 포함한 모든 노드는 클러스터 엔트리포인트에서 가져오거나 명령줄에서 명시적으로 설정해 올바른 샤드 버전을 확보해야 합니다.

이번 업데이트는 최근의 gossip 오버헤드 감소 작업을 기반으로 합니다. 최근 몇 달 동안 세 가지 gossip 메시지 유형이 폐기되고 스테이킹되지 않은 검증인의 에포크 슬롯 광고가 제거되면서 인그레스 gossip 트래픽이 약 61% 감소했습니다.

리소스 사용량을 포함하는 RPC 시뮬레이션

트랜잭션 리소스 사용량을 더 쉽게 파악할 수 있도록 기본 `simulateTransaction` RPC 메서드에 `loadedAccountsDataSize` 필드가 새로 추가됐습니다. 이 필드는 시뮬레이션 중 로드된 계정 데이터의 총 바이트 수를 보고합니다.

이 기능으로 개발자는 트랜잭션 비용을 추정하고 우선순위 수수료를 더 정확하게 조정할 수 있습니다. 계정 데이터를 로드하면 컴퓨트 유닛(CU)이 소모되며, Solana의 힙 페이지 할당 크기를 기준으로 32KB당 8CU가 사용됩니다. 이 지표가 제공되므로 개발자는 트랜잭션을 구축하고 전송할 때 비용 효율성을 더 효과적으로 최적화할 수 있습니다.

스냅샷 개선

스냅샷은 주기적인 저장 지점으로 사용되며 노드가 상태를 복원할 수 있게 합니다. 노드는 이러한 스냅샷을 지속적으로 생성하고 시간이 지나면 이전 버전을 새 버전으로 교체합니다.

이번 릴리스에는 스냅샷 동작의 사용 편의성을 높이는 여러 개선 사항이 포함됐습니다.

• 기본 간격 변경: 전체 스냅샷의 기본 간격이 25,000슬롯에서 50,000슬롯으로 늘어나 스냅샷 생성 빈도가 줄었습니다.
• 스냅샷 비활성화를 위한 새 플래그: 스냅샷 생성을 명시적으로 비활성화하는 새로운 `--no-snapshots` 플래그가 도입됐습니다. 기존의 `--snapshot-interval-slots 0` 사용 방식은 이제 더 이상 권장되지 않습니다.
• Geyser 동작 개선: 스냅샷에서 복원할 때 Geyser를 통해 전송되는 계정 알림의 중복이 더 이상 제거되지 않습니다.

스냅샷 간격을 늘리면 디스크 성능이 더 안정되고 IOPS, 즉 초당 입출력 작업 수의 급증이 줄어드는 추가 이점도 있습니다.

SBPF 툴체인 개선

Agave 2.3은 SBPF 툴체인을 사용하는 개발자를 위해 여러 사용 편의성 개선 사항을 도입합니다.

• 버전 지정: 이제 개발자는 프로그램을 컴파일할 때 특정 BPF VM 버전(v0~v3)을 명시적으로 지정해 제어 수준을 높일 수 있습니다.
• SBPFv3부터 Rust만 지원: SBPFv3부터는 Rust 기반 툴체인만 지원됩니다. 기존 C 툴체인은 향후 버전과 더 이상 호환되지 않습니다.
• 새로운 최적화 플래그: 배포용 프로그램 바이너리 크기를 줄이는 새로운 `--optimize-size` 빌드 플래그가 추가됐습니다. 스토리지 사용량을 줄일 수 있지만 컴퓨트 유닛(CU) 사용량은 소폭 증가할 수 있습니다.

기타 변경 사항

이번 릴리스에는 다음과 같은 추가 업데이트가 포함됐습니다.

• 자동 클러스터 복구: 체인 충돌 시 클러스터 재시작을 자동으로 실행하는 새로운 클러스터 복구 기능 `wen-restart`이 도입됐습니다.
• 로깅 ABI 업데이트: `TimedTracedEvent` 로깅 ABI가 새로운 진단 정보를 포함하도록 업데이트됐습니다. 따라서 검증인은 호환성을 보장하기 위해 이러한 로그를 사용하는 외부 추적 또는 분석 도구를 모두 업데이트해야 합니다. 형식 불일치를 방지하려면 업그레이드 후 기존 추적 데이터를 삭제해야 합니다.
• CLI 개선: 스테이킹되지 않은 모든 lamport를 쉽게 출금할 수 있도록 withdraw-stake AVAILABLE이 추가됐으며, 보안 강화를 위해 solana-test-validator가 기본적으로 RPC 서비스를 localhost(127.0.0.1)에 바인딩하도록 변경됐습니다.
• 더 빠른 시작: 검증인 시작 시간이 크게 단축됐습니다. 이제 노드를 시작하고 원장을 로드하는 데 약 3분, 체인의 최신 지점을 따라잡는 데 약 5분이 걸립니다. 단, 이제 fastboot를 사용하려면 새로운 --wait-for-exit 플래그로 정상 종료해야 합니다. 운영자는 즉시 재시작 명령을 내리는 대신 검증인 프로세스가 자체적으로 완전히 종료될 때까지 기다린 후 재시작해야 합니다.

결론

Agave 2.3은 Solana 프로토콜의 또 다른 중요한 이정표입니다. 주요 내용으로는 새로운 TPU 클라이언트(`tpu-client-next`) 출시, AccountsDB 최적화를 통한 디스크 I/O 대폭 감소, 스냅샷 성능 향상, gossip 네트워크 개선, 더 빨라진 에포크 전환 및 시작 시간이 있습니다. 이러한 업데이트는 네트워크를 더욱 견고하게 만들고 개발자와 검증인 운영자 모두의 경험을 개선합니다.

Solana는 견고한 멀티 클라이언트 네트워크를 향해 꾸준히 발전하고 있습니다. 현재 전체 스테이킹의 8% 이상이 Firedancer를 실행하고 있으며 그 비중은 계속 증가하고 있습니다. 약 1년 반 동안 중단 없이 가동된 기록은 네트워크 핵심 소프트웨어의 성숙도와 안정성이 높아지고 있음을 보여줍니다. 동시에 메이저 및 마이너 릴리스 속도도 빨라지고 있습니다.

다음은 Agave 3.0입니다!

추가 자료

• Agave 2.3 릴리스 일정
• Agave 2.3 변경 로그
• Agave 2.3 풀 리퀘스트
• Agave 2.3 패치 노트 - Anza 블로그 
• tpu-client-next 발표 - Solana Core 커뮤니티 콜, 2025년 6월 20일