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

주목할 만한 Agave 2.1 릴리스 주기 업데이트 

• 대대적인 성능 최적화
• 블록 한도 상향
• 그리디 스케줄러 도입(실험적)
• Secp256r1 서명 검증 네이티브 지원(업데이트: Agave 2.2로 연기)
• 임대료 징수 및 임대 관련 재기록 비활성화
• 트랜잭션 로딩 실패 제약 완화
• Config 및 Address Lookup Table 프로그램을 Core BPF로 마이그레이션

이 글의 각 섹션은 독립적으로 이해할 수 있도록 구성했습니다. 독자는 자유롭게 이동하며 가장 관심 있는 주제에 집중할 수 있습니다. 검증인 운영자, 개발자, 활발한 사용자 모두 Agave 2.1의 심층 개요를 통해 이러한 발전을 효과적으로 활용하는 데 필요한 인사이트를 얻을 수 있습니다.

기능 출시

이 글을 작성하는 시점에는 전체 스테이킹 지분의 88%가 Agave 버전 2.1.11을 실행하고 있습니다. v2.1이 더 널리 도입될 수 있도록 메인넷의 기능 게이트 활성화가 일시 중단되었으며, 예정된 활성화 순서에 따라 곧 재개될 것으로 예상됩니다. 

뒤에서 다룰 새로운 전체 기능 대부분은 현재 활성화되지 않았으며, 기능 게이트 시스템을 통해 2.1 릴리스 주기 동안 출시될 예정입니다. 기능은 상대적 우선순위와 테스트넷 및 데브넷 클러스터에서 활성화된 순서에 따라 특정 에포크에 활성화됩니다.

성능 개선

검증인과 RPC 운영자들은 Agave 2.1에서 안정성과 성능이 눈에 띄게 향상되었다고 보고했습니다. 지난 1년 동안 Anza는 병목 현상 제거, 리소스 효율성 최적화, 전반적인 성능 개선을 우선해 왔습니다. 새로운 클라이언트 릴리스는 새 기능 도입만큼이나 대역폭을 늘리고 지연 시간을 줄이는 핵심 기반 개선에도 중점을 둡니다. 2.1 업데이트의 세부 내용을 살펴보기 전에, 최근 이어진 클라이언트 업데이트에서 달성한 중요한 성능 향상을 수치로 확인해 보겠습니다.

블록 시간

Solana의 블록 시간이 빨라지면서 평균 슬롯 시간은 400ms 아래로 내려갔습니다. 최근 에포크는 이틀이 채 되지 않아 완료되는 추세로, 네트워크 역사상 가장 빠릅니다. 두 클라이언트 모두 더 짧은 블록 시간을 지원할 준비가 되어 있습니다. 이러한 가속은 단순히 트랜잭션 처리량을 높이는 데 그치지 않습니다. 스테이킹 보상은 역년이 아닌 "에포크 연도"를 기준으로 계산되는 인플레이션 발행량과 연동되므로 검증인과 스테이커에게 이점이 있습니다. 에포크 연도는 표준 에포크 길이인 이틀을 기준으로 연간 182.5개 에포크를 가정합니다. 에포크가 짧아지면 같은 기간에 더 많은 에포크가 포함되어 스테이킹 보상 분배 속도가 실질적으로 빨라집니다.

가동 시간

Solana는 2024년과 2025년 초에 걸쳐 거의 완벽한 안정성을 보여 주었으며, 1년 넘게 100% 가동 시간을 유지했습니다. 마지막으로 기록된 중단은 2024년 2월 6일에 발생했습니다. 당시 알려진 버그로 인해 Mainnet의 블록 최종 확정이 일시적으로 중단되었습니다. 문제는 빠르게 파악되어 패치되었습니다. 이후 Solana는 최근 Trump 일가의 토큰 출시로 인한 활동 급증처럼 네트워크 활동이 폭증한 시기에도 중단 없이 블록을 생성하며 높은 부하에서도 탄력성을 입증했습니다.

슬롯 건너뛰기 비율

슬롯 건너뛰기 비율은 특정 슬롯의 리더로 지정된 검증인이 할당된 시간 안에 블록을 생성하지 못하는 빈도를 나타냅니다. 2024년 11월의 에포크 700 전후부터 슬롯 건너뛰기 비율은 크게 감소했습니다. 수년 동안 2~5% 사이에서 변동하던 이 비율은 이제 최적화가 잘된 대부분의 검증인에서 0에 가까워졌습니다.  

이러한 개선에 기여한 요인 중 하나는 에포크 707에서 메인넷에 분할 에포크 보상이 도입된 것입니다. 스테이킹 보상을 여러 블록에 분산함으로써 새 에포크의 첫 번째 블록에 보상 분배가 집중되어 발생하던 성능 병목 현상을 완화하고, 네트워크가 더 원활하게 운영되도록 합니다.

또한 2024년 11월에 도입된 Timely Vote Credits(TVC)는 검증인의 신속한 투표를 장려하고 지연 투표를 억제합니다. TVC는 의도적으로 투표를 보류하는 검증인 수를 줄여 클러스터 수렴을 개선하고, 확인과 최종 확정 속도를 높입니다. 이 메커니즘은 포크를 최소화하고 포크 지속 시간을 단축하는 데 도움이 됩니다. 이제 TVC 점수가 스테이킹 풀 순위에 영향을 주기 때문에 운영자들은 하드웨어를 업그레이드하고 검증인 구성을 최적화해 성능을 개선하고 있습니다.

초당 트랜잭션 수(TPS)

초당 트랜잭션 수(TPS)가 높을수록 체인의 처리량이 높다는 뜻입니다. Solana의 비투표 TPS, 즉 ‘실질 TPS’는 2023년 말부터 꾸준히 상승하고 있습니다. 2025년 2월 첫째 주 최신 데이터에 따르면 네트워크의 50번째 백분위 평균은 1,228 TPS였으며, 99번째 백분위의 최고 성능은 2,520 TPS에 달했습니다.  

역대 최고 TPS는 2024년 12월 23일에 끝난 PENGU 토큰 에어드롭 주간에 관측되었습니다. 50번째 백분위 평균은 1,260 TPS였고, 99번째 백분위는 최고 3,252 TPS를 기록했습니다. 이러한 지속적인 성장은 Solana의 확장성과 트랜잭션 처리 효율성이 계속 향상되고 있음을 보여 줍니다.

우선순위 수수료

마지막으로 2025년 1월 27일부터 2월 4일까지 Agave 2.1과 이전 버전인 2.0의 우선순위 수수료 징수를 비교한 결과, Agave 2.1이 일관되게 조금 더 높은 우선순위 수수료를 징수했습니다.

블록 한도 상향

SIMD-0207: 블록 한도를 50M으로 상향에서 제안된 블록 한도 상향은 Solana의 2.1 릴리스 주기에 적용될 예정입니다. 현재 프로토콜은 블록당 총 컴퓨팅 리소스를 4,800만 Compute Units(CU)로 제한합니다. 블록 한도는 리더가 블록에 담을 수 있는 작업량을 제한하여 노드가 네트워크를 따라갈 수 있도록 합니다. 창립 팀은 검증인이 합리적으로 처리하여 400밀리초의 블록 시간을 달성할 수 있는 작업량을 기준으로 현재 한도를 경험적으로 정했습니다. 

하지만 현재 메인넷 활동은 실행 시간의 제약을 받지 않으므로 400ms 목표를 초과하지 않고도 블록에 더 많은 트랜잭션을 담을 수 있습니다. 이번 업데이트는 네트워크 용량을 점진적으로 확장하기 위해 블록당 컴퓨팅 한도를 48M에서 50M CU로 높이는 4%의 완만한 상향을 도입합니다. 한도를 두 배로 늘리는 등 더 큰 폭의 상향도 가능하지만, 첫 변경으로는 위험이 너무 크다고 판단했습니다. 블록 한도 확대는 검증인뿐 아니라 RPC 노드, 인덱서, 아카이브 서비스 같은 핵심 인프라에도 영향을 미치므로 이들 역시 그에 맞게 확장해야 합니다.

다른 프로토콜 한도는 그대로 유지됩니다.

• 블록당 계정별 컴퓨팅 한도는 12M CU로 유지됩니다.
• 트랜잭션당 최대 컴퓨팅 한도는 1.4M CU로 유지됩니다.

블록 한도는 앞으로 더 높아질 것으로 예상되며, 정식 SIMD 절차를 통해 진행될 예정입니다.

그리디 스케줄러

배경: 중앙 스케줄러

마지막 주요 스케줄러 업데이트인 중앙 스케줄러는 지난해 5월 Agave 1.18에 도입되었습니다. 이 스케줄러는 우선순위가 가장 높은 N개의 트랜잭션으로 종속성 그래프를 구성하며, 현재 N은 256으로 설정되어 있습니다. 그런 다음 충돌하지 않는 트랜잭션이 먼저 처리되도록 우선순위에 따라 트랜잭션 스케줄링을 시도합니다. 스케줄링된 트랜잭션은 그래프에서 제거되므로 이전에 충돌했던 트랜잭션에 우선순위를 부여할 수 있습니다. 이후 스케줄러는 N개의 트랜잭션 대기열을 유지하도록 그래프를 다시 채웁니다.

이 접근 방식은 주로 대규모 배치 처리를 최적화하여 전반적인 트랜잭션 처리량을 개선하도록 설계되었습니다. 하지만 종속성 그래프를 구성하고 트랜잭션을 정렬하는 데 상당한 시간이 걸려 병목 현상이 발생한다는 큰 단점이 있습니다. 

Agave 1.18과 중앙 스케줄러 구현에 관한 자세한 개요는 이전 Helius 블로그 게시물을 참고하세요.

새로운 그리디 스케줄러

중앙 스케줄러와 달리 그리디 스케줄러는 종속성 그래프를 구성하지 않습니다. 대신 더 간단한 접근 방식을 따릅니다.

• 먼저 우선순위가 가장 높은 트랜잭션을 선택합니다.
• 트랜잭션이 진행 중인 배치와 충돌하지 않으면 네 개의 작업자 스레드 대기열 중 하나에 추가합니다.
• 충돌이 발생하면 현재 배치를 확정하여 전송하고, 트랜잭션을 새 배치에 추가합니다.

이 방식은 트랜잭션 스케줄링 속도를 크게 높이지만 배치 크기가 작아져 트랜잭션당 오버헤드가 증가합니다. 하지만 실제 메인넷 환경에서는 실행 시간이 배치 처리보다 BPF 처리에 더 크게 좌우되므로 이러한 절충은 가치가 있습니다.

중앙 스케줄러는 트랜잭션을 정렬하고 종속성 그래프를 구축하는 데 시간이 필요하기 때문에 네트워크 부하가 높을 때 어려움을 겪습니다. 그리디 스케줄러는 이러한 오버헤드를 제거해 배치 효율성이 낮아지는 대신 응답성을 개선합니다.

트랜잭션이 A, B, C라는 세 충돌 그룹으로 나뉘는 상황을 생각해 보겠습니다. 한 트랜잭션이 쓰려는 계정을 다른 트랜잭션이 읽거나 쓰려 할 때 트랜잭션이 충돌합니다. A의 트랜잭션은 B 또는 C의 트랜잭션보다 우선순위 수수료가 높습니다.

• 중앙 스케줄러는 충돌하지 않는 트랜잭션 A1, B1, C1을 [A1, B1, C1]이라는 하나의 배치로 함께 스케줄링합니다.
• 그리디 스케줄러는 수수료가 가장 높은 트랜잭션을 우선하여 A1을 별도 배치로 스케줄링한 다음, 다음 배치에서 A2로 넘어갑니다.

이러한 우선순위 지정은 더 빠른 스케줄링을 보장하지만 중앙 스케줄러보다 배치가 작아질 수 있습니다.

Secp256r1 서명 검증용 네이티브 프로그램

Solana는 secp256r1 타원 곡선 서명을 검증하는 새로운 네이티브 프로그램을 도입합니다. 이를 통해 Passkeys의 온체인 지원, WebAuthn 표준, 2단계 인증(2FA)을 포함한 새로운 계정 추상화 모델을 사용할 수 있습니다. 이번 개선으로 Web2에서 이미 널리 사용되는 비밀번호 없는 인증을 온체인 보안의 두 번째 인증 수단으로 활용할 수 있게 됩니다.

secp256r1 타원 곡선은 NIST가 표준화한 암호화 곡선으로, 다음을 포함한 최신 기기에서 폭넓게 지원됩니다.

• WebAuthn: 모든 주요 웹 브라우저에서 지원되는 공개 키 암호화 기반 인증을 위한 W3C 표준입니다.
• Apple의 Secure Enclave: 메시지에 서명하며 생체 인증을 통해서만 접근할 수 있는 하드웨어 기반 Trusted Execution Environment(TEE)입니다.
• Android Keystore: 기기의 TEE를 활용해 키를 안전하게 저장하고 개인 키와 서명 방식을 관리하는 API입니다.
• Passkeys: 비밀번호를 암호화 키 쌍으로 대체하며 타원 곡선 암호화와 호환되는 FIDO Alliance 및 W3C 표준입니다.

Ethereum(EIP-7212)을 포함한 여러 다른 네트워크에서도 secp256r1 곡선 지원 통합을 검토했습니다.

Secp256r1 프로그램 세부 정보

새 프로그램은 다음 ID로 배포됩니다: Secp256r1SigVerify1111111111111111111111111

명령 구조:

• u8 카운터는 검증할 서명 수를 지정합니다.
• 그 뒤에 단일 바이트 패딩이 이어집니다.
• 각 서명에는 다음과 같은 직렬화된 구조체가 사용됩니다.

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

이번 업데이트는 Bunkr 팀이 제안한 SIMD-0048: Secp256r1 Sigverify용 네이티브 프로그램에서 시작되었습니다. Secp256r1 SigVerify Precompile Program은 Solana의 기존 secp256k1 지원 및 ed25519 서명과 유사하게 작동합니다.

임대료 징수 비활성화 및 임대 관련 재기록 건너뛰기

SIMD-0084: 임대료 징수 비활성화와 SIMD-0183: 임대 관련 재기록 건너뛰기에서 제안된 두 가지 관련 업데이트는 임대료 납부 계정과 관련된 기존 오버헤드 대부분을 제거합니다.

임대료 징수는 Bank 내부의 복잡한 구성 요소입니다. 이를 비활성화하면 검증인 클라이언트 코드베이스가 단순해지고, 더 이상 임대료 징수 로직을 복제할 필요가 없어 모든 검증인 클라이언트 구현 개발이 간소화됩니다. 계정에서 임대료가 더 이상 차감되지 않으며, 징수된 임대료도 검증인에게 분배되지 않습니다. 새로운 임대료 납부 계정은 이미 생성할 수 없으며, 생성하려 하면 트랜잭션 오류가 발생합니다.

현재 임대료 징수는 에포크마다 모든 계정을 최소 한 번 확인하며, 변경되지 않은 계정도 로드하고 저장합니다. 모든 Solana 계정이 이미 임대료 면제 대상이므로 이 프로세스를 유지하는 것은 불필요한 컴퓨팅 작업입니다.

임대료 관련 계정 재기록이 제거되어 슬롯당 저장되는 계정 수가 줄어듭니다. 그 결과 계정 델타 해시와 증분 계정 해시 계산에 포함되는 계정이 감소하므로 검증인의 성능이 향상됩니다. 이 변경은 증분 스냅샷의 크기도 줄여 리소스 소비를 더욱 낮춥니다.

트랜잭션 제약 완화: 로딩 실패

현재 Solana 트랜잭션에는 블록에 포함되기 전에 실패하게 만들 수 있는 엄격한 제약이 적용됩니다. 이러한 블록 포함 전 실패는 트랜잭션 수수료를 받지 못한 채 리소스를 사용하므로 검증인의 컴퓨팅 자원을 낭비합니다. 사실상 보상 없이 작업을 수행하는 셈입니다.

유효하지 않은 프로그램을 호출하거나 로드된 계정 데이터의 최대 한도인 64 MiB(~67.11 MB)를 초과하는 트랜잭션을 필터링해야 하므로 블록 생성은 더욱 복잡해집니다. 이러한 제한은 블록 조립의 복잡성을 높이고 블록의 유효성을 판단하기 어렵게 만듭니다. 이러한 제약을 완화하면 프로그램 데이터를 미리 로드하고 검증하지 않아도 트랜잭션을 블록에 포함하고 수수료를 부과할 수 있습니다. 이러한 전환은 블록 검증에서 계정 상태에 대한 의존성을 없애는 것을 목표로 합니다.

SIMD-0191에서 제안된 이러한 변경은 모든 트랜잭션이 실행을 시도한다고 가정하는 블록체인 탐색기 같은 도구에 영향을 줄 수 있습니다. 또한 사용자는 불필요한 수수료 지출을 피하기 위해 자신의 트랜잭션이 실행 가능한지 확인해야 합니다.

Config 및 Address Lookup Table 프로그램을 Core BPF로 마이그레이션

네이티브 내장 프로그램에서 Berkeley Packet Filter(BPF) 프로그램으로 진행 중인 전환의 일환으로 Config 및 Address Lookup Table 프로그램이 Core BPF 프로그램으로 마이그레이션됩니다. 이 전환은 이러한 핵심 프로그램을 검증인 런타임에서 분리하여 더 유연한 업데이트와 쉬운 유지보수를 지원합니다.

BPF 프로그램은 네이티브 프로그램보다 복잡성이 낮아 서로 다른 검증인 클라이언트의 개발과 유지보수가 간소화됩니다. 이번 변경으로 Firedancer 및 Anza 팀은 더 이상 각자의 런타임에서 프로그램 변경 사항을 별도로 추적하고 구현할 필요가 없습니다. 대신 업데이트가 모든 클라이언트에 공통으로 적용됩니다. 

다시 구현된 프로그램은 네이티브 버전과 동일한 ABI를 유지하여 완전한 호환성을 보장하며, 컴퓨팅 사용량만 달라집니다.

결론

Agave 2.1 업데이트는 주요 기능 개선과 런타임 최적화를 도입하며 Solana의 중대한 발전을 이룹니다. 이번 릴리스는 기능을 확장하고 성능을 개선하며 Solana가 달성할 수 있는 한계를 넓혀 네트워크를 강화합니다. Secp256r1 서명 검증 네이티브 지원, 블록 한도 상향, 대대적인 성능 개선, 향후 도입될 그리디 스케줄러를 통해 Agave 2.1은 효율성과 확장성을 모두 높입니다. 개발자, 검증인, 활발한 사용자 모두에게 이번 업데이트는 새로운 가능성을 열어 주며 Solana를 그 어느 때보다 빠르고 유연하며 강력하게 만듭니다.

추가 자료

• Agave 클라이언트 저장소
• Agave v2.1 릴리스 일정
• Agave v2.1 태그가 지정된 Pull Request