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

소개

Agave v3.0 메이저 릴리스는 Solana의 또 다른 중요한 이정표입니다. 네트워크 성능, 검증인 운영, 개발자 경험을 개선하기 위한 다양한 업그레이드를 도입합니다.

주목할 만한 Agave 3.0 업데이트 

• 캐시 전면 개편: 트랜잭션 처리 속도 30~40% 향상
• 단일 계정 연산 한도 상향: 단일 계정 한도를 블록 CU의 40%로 상향
• 새로운 스케줄러 TransactionView 구조체: 스케줄링 효율 개선
• Turbine용 eXpress Data Path(XDP): 1억 CU 블록을 위한 필수 조건
• CPI 중첩 깊이 확대: CPI 중첩 한도를 4에서 8로 상향
• 엔트리 제약 완화: 스케줄링 로직을 단순화하고 비동기 실행을 위한 기반 마련
• 시작 시간 단축: 노드의 온라인 복귀 속도 향상
• 로드된 트랜잭션 데이터 크기 명세: 로드된 트랜잭션 데이터 계산 방식 표준화
• RPC 개선: PubSub WebSockets를 사용하는 dApp에 더 빠르고 안정적인 실시간 업데이트 제공

이 글의 각 섹션은 독립적으로 구성되어 있어 가장 관련 있는 주제에 집중할 수 있습니다. 검증인 운영자, 개발자, 활발한 커뮤니티 구성원 누구에게나 Agave v3.0의 최신 개선 사항을 최대한 활용하는 데 필요한 핵심 업데이트와 인사이트를 제공합니다.

클라이언트 관련 동향

Agave v3.0의 새로운 기능을 자세히 살펴보기 전에 최근 데이터가 보여주는 Solana 네트워크와 Agave 클라이언트의 발전을 확인해 보겠습니다. 더 빨라진 릴리스 주기, 폭넓어진 클라이언트 도입, 높은 부하에서도 견고한 성능이 두드러집니다.

Agave 릴리스 주기

Anza는 올해 릴리스 주기를 눈에 띄게 단축해 Agave 마이너 버전 간격을 3개월 미만으로 줄였습니다. Agave 2.2.* 시리즈가 초다수 버전으로 유지된 기간은 11주에 불과했으며, Agave 2.3도 비슷한 흐름을 보이고 있습니다.

멀티 클라이언트 네트워크

최근 몇 달간 메인넷에서 Firedancer 도입이 크게 진전됐습니다. 현재 전체 스테이크의 21.6%가 Jito-Frankendancer 클라이언트를 실행하고 있습니다. 이 비율은 올해 내내 느리지만 꾸준히 증가했습니다(아래 차트 참조). 전체 Firedancer 클라이언트가 메인넷 배포를 위한 프로덕션 준비를 마칠 때까지 도입률은 약 20% 수준을 유지할 것으로 예상됩니다.

이는 네트워크 안전성, 활성, 복원력을 높이려는 Solana의 오랜 멀티 클라이언트 전략에서 중요한 이정표입니다. 클라이언트 다양성이 커지면 검증인 운영자의 선택지가 늘어나고, 클라이언트 팀 간 건전한 경쟁이 촉진되며, 더 많은 사람이 클라이언트 코드베이스를 검토하게 됩니다. 단일 치명적 버그가 네트워크 전체 중단을 일으킬 위험도 줄어듭니다.

Jito 같은 서드 파티 MEV 수정 사항이 없는 기본 Agave 클라이언트를 실행하는 스테이크가 연초 약 6%에서 현재 약 2%로 감소한 점도 주목할 만합니다. 반면 Paladin-Agave 도입률은 최근 몇 달간 상승해 현재 전체 스테이크의 약 6%를 차지합니다.

네트워크 스트레스 테스트

10월 10일, 암호화폐 시장에서 사상 최대 규모의 청산 사태가 발생해 모든 주요 블록체인에서 극심한 변동성이 나타났습니다. 네트워크 활동이 기록적으로 급증했지만 Solana 네트워크와 Agave 검증인 클라이언트는 높은 부하에서도 뛰어난 복원력과 안정성을 보여주었습니다.

정점 구간에서 Solana는 평소의 6배에 달하는 트래픽을 처리했습니다. 리더는 초당 약 100,000개의 트랜잭션 패킷을 수신하면서도 6,000만 CU 한도까지 채운 블록을 생성했습니다.

이러한 상황에서도 Solana는 주요 네트워크 가운데 가장 안정적인 수수료 흐름을 보였으며, 처리량은 한 자릿수 이상 높은 수준을 기록했습니다. 활동이 최고조에 달했을 때 실제 TPS(투표 외 트랜잭션)는 3,200을 넘어섰습니다.

약 2시간의 정점 구간 동안 Solana의 트랜잭션 수수료 중앙값(P50)은 1센트 미만인 $0.007까지만 상승했습니다. 평균 수수료는 잠시 $0.10에 도달했고, 상위 1% 트랜잭션(P99)은 $1.00을 약간 넘는 수준에서 정점을 찍었습니다. 이는 로컬 수수료 시장의 효과를 보여줍니다. 높은 수수료는 경합이 심한 핫 계정과 상호작용하는 트랜잭션에만 제한됐으며, 단순 전송(예: 스테이블코인 결제)을 수행하는 일반 사용자는 영향을 받지 않았습니다.

같은 기간 Ethereum 메인넷과 Arbitrum에서는 트랜잭션당 수수료 중앙값이 잠시 $100를 넘어섰습니다. Coinbase가 운영하는 L2 Base에서도 수수료가 급등해 중앙값이 $3를 넘었습니다. 이 네트워크에는 로컬 수수료 시장이 없어 네트워크에 부하가 발생하면 모든 사용자의 비용을 일괄적으로 높이는 전역 수수료 조정이 적용됩니다.

상태 증가

최근 Solana의 온체인 상태는 총 계정 수 10억 개를 돌파하며 중요한 이정표를 세웠습니다. 이 계정 중 약 67%는 Token Program이 소유하며, 그중 89.45%는 연결된 토큰 계정이고 10.55%는 토큰 민트 계정입니다.

이처럼 상태가 꾸준히 증가하면 장기적으로 Solana 클라이언트와 인프라 제공업체에도 영향을 미칩니다. 계정 수가 늘어날수록 스토리지, 스냅샷 크기, 계정 인덱싱에 대한 요구도 커지며, 이는 성능과 하드웨어 요구 사항에 영향을 줄 수 있습니다. ZK Compression 같은 솔루션은 상태 비대화를 줄일 유망한 장기 해법을 제공합니다.

Agave 3.0 릴리스 주기 업데이트

캐시 전면 개편

Agave 3.0은 중복 런타임 작업을 크게 줄였습니다. 프로그램 캐시를 전면 개편해 트랜잭션 배치마다 발생하던 불필요한 계정 조회 수백 건을 제거했습니다. 내부 벤치마크에서는 트랜잭션 처리 속도가 약 30~40% 향상됐습니다.

계정 한도를 블록 CU의 40%로 상향

Solana는 Agave 3.0 릴리스 주기의 일부로 SIMD-0306: 계정 CU 한도 상향을 활성화합니다. 계정별 CU 한도를 고정 상수인 12M에서 블록 CU 한도의 40%로 높입니다. 현재 각 계정은 블록당 최대 1,200만 CU를 사용할 수 있습니다. 아래 Anza 차트에서 볼 수 있듯 경합이 가장 심한 계정은 이 한도에 자주 도달합니다.

이 변경으로 계정별 한도는 먼저 1,200만 CU에서 2,400만 CU로 높아집니다. 이후 SIMD-0286(100M CU 블록)이 활성화되면 최종적으로 4,000만 CU까지 증가합니다. P-token 프로그램 도입 같은 업데이트와 결합하면 블록마다 자주 액세스되는 핫 계정의 처리량이 크게 향상됩니다.

다음을 비롯한 다른 제약은 변경되지 않습니다.

• 최대 투표 유닛: 블록당 투표 트랜잭션의 총 CU 한도인 3,600만 CU
• 최대 블록 계정 데이터 크기 델타: 블록당 전체 계정 데이터 변경 한도인 100메가바이트

계정별 CU 한도를 높이면 핫 상태의 처리량은 향상되지만, 최악의 경우 직렬화된 실행 시간이 늘어날 수 있습니다. 부하가 높은 상황에서는 블록 검증 시간이나 슬롯 지속 시간이 길어질 가능성이 있습니다.

마지막으로 최근 제안된 SIMD-0370: Compute Unit 블록 한도 제거도 주목할 만합니다. CU 기반 블록 한도를 완전히 없애는 방안을 검토하는 제안으로, Alpenglow 업그레이드 이후 다시 논의될 가능성이 큽니다.

Turbine용 eXpress Data Path(XDP)

eXpress Data Path(XDP)는 고성능 네트워킹을 위해 설계된 Linux 커널 기술입니다. 애플리케이션이 커널의 표준 패킷 처리 경로 대부분을 우회할 수 있어 중간 데이터 복사와 사용자 공간 및 커널 공간 간 컨텍스트 전환을 모두 줄입니다. 사용자 공간에서 네트워크 인터페이스 카드(NIC)를 통해 패킷을 직접 처리하므로 XDP는 패킷당 오버헤드를 크게 낮춥니다.

Turbine의 XDP 지원은 Agave v2.3.8에서 처음 도입됐으며 Agave 3.1부터 기본으로 활성화됩니다. 블록 한도가 100M CU로 증가하면 Turbine이 주요 확장성 병목이 됩니다. 리더는 샤드를 200개 피어에 전달하므로 네트워크 부하가 큽니다. 리더 슬롯이 많은 대형 검증인은 현재 조건에서 초당 발신 패킷이 150,000개에 근접할 수 있습니다. XDP는 이 병목을 직접 해결합니다. 패킷 전송 속도를 최대 100배 높여 검증인이 더 큰 블록을 훨씬 효율적으로 전파할 수 있게 합니다. 

Agave의 XDP 구현을 더 자세히 알아보려면 검증인 설정 가이드와 XDP의 Agave 클라이언트 통합을 주도한 Anza 엔지니어 Alessandro Decina와의 이전 인터뷰를 참고하세요.

로드된 트랜잭션 데이터 크기 명세

Solana의 실행 모델을 단순화하고 표준화하기 위한 지속적인 작업의 일환으로 SIMD-0186: 로드된 트랜잭션 데이터 크기 명세가 Agave 3.0 릴리스 주기 중 메인넷에서 활성화될 예정입니다.

이 명세는 각 트랜잭션이 로드한 전체 계정 데이터를 합의에 안전한 방식으로 계산하는 방법을 도입합니다. 모든 검증인 클라이언트가 동일한 트랜잭션 데이터 크기를 계산하도록 해 합의가 분기될 수 있는 미묘한 불일치를 제거하는 것이 목표입니다.

현재 Solana의 트랜잭션 데이터 크기 계산 로직은 지나치게 복잡합니다. 기존 구현은 LoaderV3와 BPF Upgradeable Loader 프로그램을 독특한 방식으로 처리하며, 두 프로그램 모두 로드된 실제 프로그램 데이터 크기를 빈번하게 과소 계산합니다. 이러한 불일치로 인해 독립 클라이언트 팀이 호환 가능한 로직을 구현하기 어려웠습니다.

SIMD-0186에서는 크기 계산 규칙이 명확하고 이해하기 쉬워집니다.

• 로드된 각 계정은 정확히 한 번만 계산
• BPF Upgradeable Loader를 사용하는 프로그램에는 연결된 프로그램 데이터 포함
• 로드된 각 계정의 크기는 트랜잭션 실행 전 데이터의 바이트 길이에 메타데이터용 64바이트를 더한 값으로 정의
• Address Lookup Table(ALT)마다 고정 8,248바이트 추가

이 명세는 모든 클라이언트에서 트랜잭션 크기 계산을 표준화하고 개발자가 트랜잭션 동작을 더 쉽게 예측할 수 있게 합니다.

로드된 데이터 크기 한도는 트랜잭션별 CU 한도와 비슷한 역할을 하며 검증인 노드가 리소스 사용량을 예측 가능하게 계산하도록 합니다. 기본적으로 각 트랜잭션은 최대 64MB의 계정 데이터를 로드할 수 있습니다. 실제 로드된 데이터가 더 적더라도 로드된 32KB당 8개의 compute unit(CU)을 사용하며, 기본 비용은 16,000 CU입니다. 개발자는 setLoadedAccountsDataSizeLimit 명령으로 이 한도를 낮춰 연산 비용을 줄이고 스케줄링 효율을 높일 수 있습니다.

새로운 크기 계산 방식은 트랜잭션 구조에 따라 다른 값을 산출할 수 있으므로 개발자는 compute budget 명령에 지정한 로드된 계정 데이터 크기 한도를 조정해야 할 수 있습니다.

스케줄러 TransactionView 구조체

Agave 3.0에서 스케줄러는 트랜잭션 파싱과 처리 과정을 간소화하도록 설계된 새로운 경량 데이터 구조 TransactionView를 도입합니다. 역직렬화와 여러 번의 메모리 할당이 필요했던 기존 SDK 트랜잭션 유형과 달리 TransactionView는 직렬화된 트랜잭션을 직접 보여줍니다. 실제로 역직렬화하지 않고 트랜잭션 레이아웃의 메타데이터를 파싱하고 캐시합니다.

시작 시간 단축

Agave v3.0 릴리스에서는 클라이언트 시작 성능이 계속 개선돼 검증인과 RPC 운영자의 사용 편의성이 크게 향상됩니다. 장애, 업그레이드, 예정된 유지보수 후 재시작하는 경우에도 노드가 훨씬 빠르게 온라인 상태로 복귀합니다.

스냅샷 아카이브에서 시작하는 데 걸리는 시간이 3분 30초 미만으로 단축됐습니다. Agave v2.2에서 필요했던 시간의 절반도 되지 않습니다(아래 차트 참조). 시작 시간이 빨라지면 노드가 합의에 다시 참여하는 데 걸리는 시간이 줄어듭니다. 따라서 네트워크 복원력과 검증인 가동 시간이 직접 개선되는 중요한 성능 향상입니다.

앞으로 Agave v3.1에서는 백그라운드 계정 검증을 없애 이 과정을 더욱 간소화합니다. 검증인은 리플레이가 시작되는 즉시 투표할 수 있습니다.

CPI 중첩 한도 상향

SIMD-0268: CPI 중첩 한도 상향은 Cross-Program Invocation(CPI) 호출의 최대 깊이를 4에서 8로 늘립니다. 이를 통해 하나의 트랜잭션에서 Solana 프로그램이 다른 프로그램을 호출할 수 있는 횟수가 사실상 두 배로 증가합니다.

CPI는 하나의 Solana 프로그램이 다른 프로그램을 호출하는 메커니즘입니다. 프로그램이 서로의 로직을 기반으로 구축될 수 있게 하는 Solana 런타임의 핵심 기능입니다.

무기한 스왑, 스마트 지갑, 교차 마진 시스템 같은 복잡한 온체인 프로토콜은 포지션, 청산, 위험을 관리하기 위해 여러 계층의 프로그램 상호작용에 의존하는 경우가 많습니다. 기존의 4단계 CPI 한도는 이러한 설계를 제약했으며, 일부 개발자는 로직을 여러 트랜잭션으로 나눠야 했습니다.

기존 애플리케이션은 이전과 동일하게 작동합니다. 단, 트랜잭션 실패 로직이 기존 한도에 의존하는 경우는 예외입니다. 전반적으로 많은 요청을 받아온 이번 변경은 개발자의 설계 가능성을 넓히고 Solana의 결합성을 강화합니다.

엔트리 제약 완화

Agave 3.0에서 활성화될 예정인 SIMD-0083: 엔트리 제약 완화는 블록 엔트리 내 트랜잭션이 서로 충돌해서는 안 된다는 규칙을 제거합니다. 이전에는 충돌하는 트랜잭션, 즉 동일한 계정에 모두 쓰거나 하나가 읽는 동안 다른 하나가 쓰는 트랜잭션이 엔트리에 포함되면 전체 블록이 무효화됐습니다.

이번 업데이트로 이러한 충돌이 허용됩니다. 충돌이 발생하면 트랜잭션은 표시된 순서대로 직렬 실행됩니다. 이 변경은 블록 패킹 규칙을 단순화해 리더가 트랜잭션 순서와 블록 구성에 더 큰 유연성을 갖게 합니다. Solana가 비동기 실행을 구현하는 데도 필요한 변경입니다.

RPC 개선

Agave v3.0은 구독 서버의 응답성을 개선합니다. 이제 구독 요청과 PING 같은 수신 메시지를 발신 알림보다 우선 처리합니다. 이를 통해 PubSub WebSockets를 사용하는 dApp에 더 빠르고 안정적인 실시간 업데이트를 제공합니다.

또한 에포크 보상 오류 데이터에 슬롯 속성이 추가돼 개발자의 디버깅과 관측 가능성이 향상됐습니다.

기타 변경 사항

• Agave v3.0.0부터 Anza는 사전 빌드된 agave-validator 바이너리 배포를 중단했습니다. 이제 검증인 운영자는 제공된 빌드 지침에 따라 소스에서 바이너리를 컴파일해야 합니다.
• Agave v3.0에서는 기본 스냅샷 간격이 100,000슬롯마다로 늘어났습니다. v2.3의 50,000슬롯과 v2.2의 25,000슬롯보다 길어졌습니다. 간격을 늘리면 디스크 성능이 크게 향상되고 스냅샷 생성 중 IOPS(초당 입출력 작업 수) 급증이 줄어듭니다.
• 더 이상 사용되지 않는 여러 기존 CLI 인수와 플래그가 제거됐습니다(전체 목록 보기).
• 현재 트랜잭션의 advance nonce 명령은 트랜잭션에 포함된 모든 계정을 진행할 계정으로 지정할 수 있습니다. SIMD-0242: 정적 Nonce 계정만 허용의 기능 게이트가 활성화되면 advance nonce 명령은 정적으로 포함된 계정만 진행할 수 있도록 제한됩니다.

결론

Agave v3.0은 트랜잭션 처리 속도 향상, 연산 한도 상향, 스케줄러 효율 개선, 다양한 검증인 및 RPC 최적화를 도입하는 대규모 클라이언트 업그레이드입니다. 이러한 업데이트는 네트워크 성능과 개발자 경험을 모두 강화합니다.

최근 데이터도 이러한 발전을 뒷받침합니다. 더 빨라진 릴리스 주기, 확대되는 클라이언트 다양성, 수요가 최고조에 달했을 때의 뛰어난 네트워크 안정성은 모두 Solana의 성숙을 보여줍니다. 이제 Agave 3.0이 네트워크를 구동하면서 Solana는 확장 역량을 계속 입증하고 있습니다.

추가 자료

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