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

Agave 2.0 요약

Agave 검증인 클라이언트 v2.0 출시는 Solana가 더욱 견고한 멀티 클라이언트 생태계로 나아가는 여정에서 중요한 이정표입니다. 이번 업데이트에서는 네트워크 성능, 안정성, 효율성을 높이는 몇 가지 핵심 개선 사항을 도입합니다. 주요 변경 사항은 다음과 같습니다.

• 광범위한 코드베이스 리팩터링 및 최적화
• 분할된 에포크 보상
• 검증인에게 우선순위 수수료 전액 지급
• 새로운 중앙 스케줄러가 이제 기본으로 활성화됨
• ZK ElGamal Proof 프로그램
• Get-Sysvar Syscall
• GetEpochStake Syscall
• MoveStake 및 MoveLamports
• 지원 중단된 RPC 메서드 제거
• 크레이트 이름 변경

검증인을 운영하거나 플랫폼에서 개발하거나 Solana를 활발히 사용한다면, 이 Agave 2.0 업데이트 종합 개요를 통해 최신 혁신을 이해하고 활용하는 데 필요한 정보를 얻을 수 있습니다.

Agave 2.0이 메이저 버전 업데이트인 이유는 무엇인가요?

이제 단일 ‘Solana 검증인’은 존재하지 않습니다. Agave 2.0은 Solana의 새로운 멀티 클라이언트 환경을 수용하며 기존 Solana Labs GitHub 저장소와 완전히 결별합니다. Solana Labs 저장소는 보관 처리되며 새로운 풀 리퀘스트나 이슈를 더 이상 받지 않습니다. 이전에는 이 저장소가 Agave 저장소의 활동을 미러링했습니다. 아직 이전하지 않았다면 개발자는 모든 활동을 Anza Agave GitHub 저장소로 옮겨야 합니다. Solana Labs에서 Agave로의 마이그레이션 절차는 3월 1일에 시작되었으며 GitHub에서 공개적으로 추적되고 있습니다.

생태계가 발전함에 따라 운영자는 하나 이상의 클라이언트를 운영하는 환경에 적응해야 합니다. 이러한 변화에 맞춰 여러 크레이트의 이름을 변경해 독립 개발팀이 관리하는 Firedancer를 비롯한 여러 클라이언트를 지원할 수 있도록 네임스페이스를 정리합니다. 이제 Anza가 유지 관리하는 크레이트에는 "agave" 접두사가 붙어 멀티 클라이언트 환경에서 Anza 전용 종속성임을 쉽게 식별할 수 있습니다.

‍영향을 받는 크레이트는 다음과 같습니다. 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

이전 전환 가이드에서 자세히 설명했듯이 2.0 업데이트에는 여러 주요 변경 사항이 포함됩니다. 특히 오래되고 지원 중단된 여러 엔드포인트가 제거됩니다. 모든 Solana 개발자가 이미 알고 있어야 할 핵심 변경 사항입니다. RPC 변경 사항의 전체 내용은 이 글 마지막에 정리했습니다.

기능 출시

이 글을 작성하는 시점에는 검증인의 ~20.7%가 버전 2.0.14를 실행하고 있습니다. v2.0 도입 시기를 테스트넷 및 데브넷의 활성화 일정과 더 가깝게 맞추기 위해 메인넷의 기능 게이트 활성화는 일시 중단되었습니다. 메인넷 클러스터에서 v2.0이 널리 도입되면 예정된 활성화 순서에 따라 기능 게이트 활성화가 재개될 예정입니다. 

다음 섹션에서 설명하는 새로운 전체 기능은 현재 활성화되지 않았으며, 기능 게이트 시스템을 통해 2.0 수명 주기에 걸쳐 점진적으로 출시됩니다. 기능은 상대적 우선순위와 테스트넷 및 데브넷 클러스터에서 활성화된 순서에 따라 특정 에포크에 활성화됩니다.

검증인에게 우선순위 수수료 전액 지급

많은 기대와 치열한 논의를 모은 경제 모델 업데이트가 5월 검증인 거버넌스 투표를 거친 제안 SIMD-0096에 따라 구현되고 있습니다. 투표는 에포크 620 종료 시점에 마감되었으며, 스테이크의 51.17%가 참여하고 77.77%가 찬성했습니다. 기능 게이트가 적용된 이번 업데이트는 네트워크의 우선순위 수수료 처리 방식을 근본적으로 바꿉니다. 수수료의 50%를 소각하고 나머지 50%를 검증인에게 지급하는 현재 모델 대신, 새로운 모델에서는 우선순위 수수료의 100%를 검증인에게 직접 지급합니다.

우선순위 수수료는 기술적으로 선택 사항이지만 Solana의 경제 활동이 증가하면서 표준 관행으로 자리 잡았습니다. 이 수수료는 다음 공식에 따라 컴퓨트 유닛당 마이크로 램포트(램포트의 100만분의 1)로 계산됩니다.

‍우선순위 수수료 = 컴퓨트 유닛 가격(마이크로 램포트) x 컴퓨트 유닛 한도

앞으로 모든 우선순위 수수료는 블록 생성자에게 지급됩니다. 이를 통해 인센티브가 더 긴밀하게 조정되고, 과거 문제가 되었던 트랜잭션 포함을 위한 검증인의 프로토콜 외부 합의 가능성이 줄어듭니다.

수수료 소각을 없애면 SOL의 순 인플레이션율이 소폭 상승하지만, 스테이킹 보상에 따른 신규 토큰 발행의 영향이 훨씬 큽니다. 자세한 분석은 이전 Helius 블로그 글인 Solana의 발행 및 인플레이션 일정을 참고하세요.

분할된 에포크 보상

분할된 에포크 보상은 스테이크 보상을 여러 블록에 걸쳐 분배해 각 새 에포크의 첫 번째 블록에 보상 분배가 집중되면서 발생하는 성능 문제를 완화합니다. 이 과정의 주된 병목은 네트워크에서 계속 늘어나는 활성 스테이크 계정에 업데이트를 다시 기록해야 한다는 점입니다. 현재 그 수는 약 140만 개에 달합니다.

새로운 방식에서는 에포크 경계의 스테이크 보상 계산 및 분배를 다음 두 단계로 나눕니다.

• 보상 계산 단계: 모든 활성 스테이크 계정의 에포크 보상을 계산하고, 분배분을 예정된 청크로 나눕니다.
• 보상 분배 단계: 활성 스테이크 계정에 미리 계산된 에포크 보상을 분배합니다.

이 과정을 지원하고 모니터링하기 위해 Sysvar 계정인 EpochRewards가 분배 단계 전반의 보상 분배를 추적하고 검증합니다. EpochRewards Sysvar는 보상 분배 단계의 진행 여부와 스냅샷에서 시작할 때 분배를 재개하는 데 필요한 정보를 기록합니다. 

보상 계산

보상은 에포크의 첫 번째 블록에서 계산됩니다. 계산이 끝나면 보상을 bank에 저장되는 분배 청크로 분할하고, 보상 분배 단계에서 이를 분배합니다.

보상 분배 단계에서 블록 처리 시간에 미치는 영향을 최소화하고 각 블록이 보상의 일부를 결정론적으로 분배하도록 블록당 4,096개의 스테이크 보상을 분배하는 것을 목표로 합니다. 스테이크 계정 수의 급격한 증가에 대비해 블록 수는 에포크 전체 슬롯의 10%로 제한됩니다. 이 블록 상한에 도달한 경우에만 파티션당 계정 수가 목표치인 4,096개를 초과할 수 있습니다.

보상 분배

보상 분배는 보상 계산 단계 직후인 에포크의 두 번째 블록부터 시작됩니다. 보상은 일반 트랜잭션 처리 전, 블록 최상단에서 분배됩니다.

이에 따라 사용자는 이전보다 몇 블록 늦게 스테이크 계정에 보상이 적립되는 것을 확인할 수 있습니다. 하지만 이전에도 에포크 경계의 첫 번째 블록 처리 시간이 길어 사용자의 스테이크 계정 접근이 지연되었으므로 전반적인 경험은 비슷합니다. 또한 이전에는 보상 분배 중 차단되었던 비스테이킹 트랜잭션도 이제 원활하게 계속 처리할 수 있습니다.‍

투표 계정 수는 약 1,500개로 비교적 적으므로 에포크 경계의 첫 번째 블록에서 투표 보상을 분배하는 기존 메커니즘은 그대로 유지됩니다. 여러 블록에 걸쳐 분배되는 것은 스테이크 보상뿐입니다.

중앙 스케줄러가 이제 기본으로 활성화됩니다

v1.18 업데이트에서 기능 릴리스로 처음 도입된 중앙 스케줄러는 이전에 “스케줄러”로 불렸습니다. 기본으로 활성화되지 않아 운영자가 검증인을 시작할 때 --block-production-method central-scheduler 플래그를 사용해 직접 활성화해야 했습니다. 이제 기본으로 켜집니다. 이전 스케줄러 구현에는 성능에 부정적인 영향을 줄 수 있는 여러 문제가 있었습니다. 트랜잭션 처리의 병목은 트랜잭션 순서와 우선순위 지정에 지터나 불일치를 일으키는 경우가 많았습니다.

새 구현은 각각 트랜잭션 우선순위 지정과 처리를 독립적으로 관리하던 4개의 뱅킹 스레드 모델을 대체합니다. 새로운 구조에서는 중앙 스케줄러만 TPU의 SigVerify 단계에서 트랜잭션을 받습니다. 중앙 스케줄러는 우선순위 큐를 만들고 prio-graph라는 종속성 그래프를 배포해 충돌하는 트랜잭션의 처리와 우선순위 지정을 더 효과적으로 관리합니다. 새로운 스케줄러 설계는 확장성과 유연성을 높이며, 잠금 충돌 증가에 대한 기존 우려 없이 스레드 수를 늘릴 수 있게 합니다. 중앙 스케줄러의 초기 출시는 더 많은 보상을 창출하는 것으로 나타났으며, 여러 운영자의 수익이 향상되었습니다. 이전 Solana v1.18 업데이트 관련 Helius 글에서 중앙 스케줄러의 작동 방식을 자세히 다뤘습니다.

ZK ElGamal Proof 프로그램

원래 1.17 릴리스에 포함될 예정이었던 ZK Token Proof 프로그램은 이제 지원 중단되며, 더 범용적이고 애플리케이션에 독립적인 ZK ElGamal Proof 프로그램으로 대체됩니다. 새로운 ZK ElGamal Proof 프로그램은 공개 키의 유효성 검증이나 ElGamal 암호문에 암호화된 값의 범위 확인처럼 여러 애플리케이션에 폭넓게 적용되는 ZK Token Proof 프로그램의 기능을 유지합니다. 다만 SPL Token 전송 명령에 필요한 영지식 증명 검증과 같은 애플리케이션별 요소는 제외합니다. 새로운 ZK ElGamal Proof 프로그램은 ZkE1Gama1Proof11111111111111111111111111111 주소의 내장 프로그램 목록에 포함됩니다.

ZK Token Proof 프로그램에 대해 자세히 알아보려면 Helius 블로그의 기존 글을 읽어보세요.

Get-Sysvar Syscall

Syscalls, 즉 시스템 호출은 운영 체제 커널에 서비스를 요청합니다. Solana에서 Syscall은 Solana Virtual Machine(SVM) 내에서 실행되는 프로그램이 외부 리소스 및 서비스와 상호작용할 수 있게 합니다. 

Sysvars는 최근 블록 해시와 에포크 보상 같은 클러스터 상태 정보를 노출합니다. 이 계정들은 알려진 주소에 데이터가 채워집니다. 프로그램은 Sysvar 계정을 통해 Sysvar에 접근하거나 Syscall로 조회할 수 있습니다. 온체인 프로그램은 다양한 사용 사례에서 여러 Sysvar를 사용하며, 일부 Sysvar는 네트워크 운영에 필수적입니다.

Anza 엔지니어 Joe Caulfield가 SIMD-127에서 처음 제안한 Get-Sysvar Syscall은 Sysvar 데이터에 접근하기 위한 통합 Syscall 인터페이스를 도입합니다. 이번 업그레이드를 통해 SlotHashes와 StakeHistory를 포함해 이전에는 접근할 수 없었던 Sysvar 데이터를 가져올 수 있습니다. 새로운 인터페이스를 사용하면 개발자는 전체 데이터 구조를 복제하지 않고도 SlotHashes::get_slot(slot) 및 StakeHistory::get_entry(epoch) 호출처럼 Sysvar 데이터의 특정 부분에 접근할 수 있습니다.

이번 업데이트는 Sysvar 데이터 레이아웃을 변경하거나 새 Sysvar를 추가할 때 발생하는 오버헤드도 최소화합니다. 이전에는 새 Sysvar마다 해당 Syscall을 추가해야 했습니다. 이처럼 긴밀한 결합 관계로 인해 시간이 지날수록 Syscall 인터페이스가 비대해지고 유지 관리가 복잡해졌습니다. 이제 단일 sol_get_Sysvar Syscall이 모든 Sysvar 인터페이스를 지원해 어떤 Sysvar에서든 일관되고 효율적으로 데이터를 가져올 수 있습니다.

새로운 Syscall 도입으로 Sysvar를 수정하고 추가하는 절차가 간소화됩니다. Syscall 인터페이스의 복잡성과 유지 관리 요구 사항도 크게 줄어듭니다. 또한 이번 업데이트는 BPF 프로그램의 Sysvar 데이터 접근 범위를 넓힐 기반을 마련해 온체인 프로그램이 트랜잭션 크기에 영향을 주지 않고 더 많은 Sysvar 정보를 읽을 수 있게 합니다.

GetEpochStake Syscall

새로운 GetEpochStake Syscall은 현재 에포크에서 투표 계정에 위임된 스테이크를 가져오는 기능을 제공합니다. 요청이 많았던 기능으로, 온체인에서 이 정보를 더 효율적이고 직접적으로 조회할 수 있습니다.

현재 프로그램은 특정 투표 계정에 현재 에포크 동안 위임된 스테이크의 실시간 데이터에 접근할 수 없습니다. 이는 검증인 거버넌스와 보조 합의 메커니즘 같은 사용 사례에 걸림돌이 됩니다. 이 데이터를 온체인에서 조회할 수 있게 되면 이러한 애플리케이션과 향후 사용 사례가 가능해집니다.

GetEpochStake를 사용할 때 개발자가 32바이트 투표 계정 주소를 제공하면, syscall은 현재 해당 투표 계정에 위임된 총 활성 스테이크를 나타내는 u64 정수를 반환합니다. 제공된 주소가 유효한 투표 계정에 해당하지 않거나 존재하지 않으면 Syscall은 0을 반환합니다.

MoveStake 및 MoveLamports

스테이크 계정 간 가치 이전을 지원하기 위해 두 가지 새로운 스테이크 프로그램 명령인 MoveStake와 MoveLamports가 도입됩니다. SIMD-0148에서 처음 제안된 이 명령을 사용하면 출금 권한의 제어 없이도 동일한 권한을 가진 계정 간에 자금을 이동할 수 있어 개발자의 작업이 간편해집니다.

이전에는 사용자 스테이크를 관리하는 프로토콜이 스테이크를 여러 검증인에 분할하고 정기적으로 재위임할 때 어려움을 겪었습니다. 프로토콜이 비활성화를 위해 사용자의 스테이크를 분할하면 새 계정의 임대료 면제에 필요한 램포트를 제공해야 합니다. 이후 분할된 계정을 병합해도 프로토콜은 임대료 면제 램포트를 회수할 수 없습니다.

MoveStake

MoveStake: 이 명령은 활성 스테이크를 계정 간에 이동할 수 있게 합니다. 한 활성 계정에서 다른 활성 계정으로, 또는 활성 계정에서 비활성 계정으로 이전해 해당 계정을 다시 활성화할 수 있습니다. 소스 계정의 위임 전체를 이동하면 소스 계정은 비활성 상태가 됩니다. 모든 경우에 임대료 면제 잔액은 그대로 유지되며 활성 계정의 최소 위임 규칙도 유지됩니다.

MoveLamports

MoveLamports: 한 활성 또는 비활성 계정에서 다른 활성 또는 비활성 계정으로 초과 램포트를 이동합니다. 여기서 "초과 램포트"는 위임된 스테이크가 아니며 임대료 면제에도 필요하지 않은 램포트를 의미합니다. MoveLamports를 사용하면 병합된 계정에서 램포트를 회수하고 사용하지 않는 자금을 통합하는 등의 정리 작업을 수행할 수 있습니다.

구현을 간소화하기 위해 이러한 변경 사항은 계정 활성화 또는 비활성화를 지원하지 않으며, 부분적으로 활성화된 스테이크 계정에도 영향을 주지 않습니다. 새로운 프로그램 명령은 기존 기능을 변경하지 않습니다.

보너스: Solana-SVM 크레이트

Agave 2.0 출시와 함께 새로운 solana-svm 크레이트가 제공됩니다. 개발자는 전체 검증인 프레임워크에서 독립된 간결한 API를 통해 핵심 SVM 구성 요소에 직접 접근할 수 있습니다. 이를 통해 오프체인 서비스, 경량 클라이언트, 상태 채널, 롤업 등 검증인 외부의 애플리케이션에서도 Solana의 고성능 트랜잭션 처리를 활용할 수 있습니다.

API를 나머지 런타임에서 분리한 이 크레이트는 Bank 인스턴스 같은 구성 요소가 필요하지 않아 운영 오버헤드를 줄입니다. 이제 개발자는 Solana mainnet-beta를 지원하는 것과 동일한 견고한 구성 요소를 활용해 경량 클라이언트, 상태 채널, 롤업, 오프체인 서비스 같은 맞춤형 SVM 프로젝트를 구축할 수 있습니다. 이 API의 핵심은 TransactionBatchProcessor 구조체입니다. 애플리케이션은 이를 통해 BPF Loader, eBPF, 가상 머신을 포함한 전체 다운스트림 Agave 구성 요소 세트로 정제된 Solana 트랜잭션 배치를 처리할 수 있습니다.

이 흥미로운 개발의 전체 내용은 Anza의 새로운 SVM API 심층 분석에서 확인하세요.

제거된 RPC 엔드포인트 

오래되고 지원 중단된 여러 v1 Agave RPC 엔드포인트가 제거되었습니다. Helius Devrel 팀은 이 엔드포인트를 사용하는 모든 고객에게 연락했습니다. 내부 분석을 통해 제거 예정인 다음 엔드포인트를 실제로 사용하는 소수의 고객을 이미 확인했습니다.

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

참고: 이미지에 표시된 getAccountInfo의 대체 방식은 여기에서 확인할 수 있습니다.

SDK의 주요 변경 사항은 다음과 같습니다.

• Borsh v0.9 지원이 제거되었습니다. v1 또는 v0.10을 사용하세요(#1440)
• Rent와 EpochSchedule에서 Copy trait이 더 이상 파생되지 않습니다. clone()을 사용하도록 전환하세요.
• solana-sdk: 지원 중단된 심볼)이 제거되었습니다. 
• solana-program: 지원 중단된 심볼이 제거되었습니다.

검증인 운영자의 경우 Agave v2.0 출시와 함께 지원 중단된 여러 검증인 인수가 제거됩니다. 전체 목록은 여기에서 확인할 수 있습니다.‍

결론

Agave 2.0 업데이트는 다양한 기능 구현과 런타임 최적화를 포함하며 Solana를 크게 발전시킵니다. 이번 릴리스는 강력한 새 Syscall과 확장된 기능을 제공하고, 크레이트 이름 변경, 지원 중단된 RPC 메서드 제거, 검증인 인수 간소화 등 전반적인 정리 작업을 통해 한계를 계속 확장합니다. Agave 2.0은 Solana의 역량을 확대하고 성능과 사용성을 개선합니다. 개발자, 검증인, 활성 사용자 모두에게 Agave 2.0 업데이트는 Solana 생태계의 새로운 가능성을 열어줍니다.

추가 자료

• Agave v2.0 릴리스 일정
• Agave v2.0 변경 로그
• Agave 릴리스 버전