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

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

• 광범위한 성능 최적화
• 블록 한도를 50M CU에서 60M CU로 20% 상향
• Accounts Lattice Hash (ALH) 도입
• Secp256r1 서명 검증(Agave 2.1 릴리스 주기에서 연기됨)
• SBPFv1, v2, v3 프로그램 배포 및 실행
• CPI 호출자 제한 해제
• Loader-v4

이 글의 각 섹션은 독립적으로 구성되어 있어 가장 관련성 높은 주제를 쉽게 살펴볼 수 있습니다. 검증인 운영자, 개발자, 적극적인 사용자 모두 Agave 2.2의 최신 개선 사항을 최대한 활용하는 데 필요한 핵심 정보를 이 종합 가이드에서 확인할 수 있습니다.

기능 출시

이 글을 작성하는 현재 전체 스테이킹 지분의 19.8%가 Agave v2.2에서 운영되고 있으며,* 네트워크 전반의 도입에 대한 강력한 지지를 보여줍니다. 업그레이드 기간에는 메인넷 기능 게이트 활성화가 일시 중단되었으며, 예정된 활성화 순서에 따라 곧 재개될 전망입니다.

Agave 2.2에 도입된 주요 기능 대부분은 현재 게이트로 제한되어 있으며 아직 메인넷에서 활성화되지 않았습니다. 이러한 기능은 Solana의 기능 게이트 시스템을 통해 2.2 릴리스 주기 동안 점진적으로 활성화됩니다. 활성화 시점은 기능 우선순위와 테스트넷 및 데브넷 클러스터의 출시 순서에 따라 결정됩니다. 최신 업데이트는 Agave 기능 게이트 추적기를 참조하세요.

블록 한도를 60M CU로 상향

Anza는 2025년을 위한 야심 찬 목표를 세웠습니다. 바로 Solana에서 사용 가능한 블록 공간을 두 배로 늘리는 것입니다. 이 노력의 일환으로 SIMD-0256: 블록 한도를 60M으로 상향이 예정된 Solana 2.2 릴리스에 포함될 예정이며, 현재 블록 한도보다 20% 증가합니다.

이는 블록 한도를 4,800만 컴퓨트 유닛(CU)에서 5,000만으로 높인 이전 업그레이드에 이은 조치입니다. 이후 블록 시간은 400ms 목표 아래로 꾸준히 유지되었습니다. 최근 데이터에 따르면 블록이 50M CU 상한에 반복적으로 도달하고 있어 추가 확장을 위한 준비가 되었음을 보여줍니다.

참고: Firedancer 대시보드의 보고 로직에 하드코딩된 상수로 인해 일부 블록은 104%가 찬 것으로 표시됩니다.

이번 업데이트에서도 다른 프로토콜 한도는 그대로 유지됩니다.

• 블록당 계정별 컴퓨트 예산은 1,200만 CU로 유지됩니다.
• 트랜잭션당 최대 컴퓨트는 140만 CU로 제한됩니다.
• 블록당 투표 트랜잭션의 총 컴퓨트 한도는 3,600만 CU로 유지됩니다.
• 블록당 신규 계정 데이터의 최대 할당량은 100MB로 제한됩니다.

블록 한도 상향은 사용자 경험에 직접적인 영향을 줍니다. 네트워크 처리량이 높아지면 트랜잭션 수수료 중앙값이 낮아지고, 혼잡한 시기에도 트랜잭션이 성공적으로 포함될 가능성이 커집니다.

블록 한도 상향의 과제

처리량을 높일 때는 두 가지 핵심 과제를 해결해야 하므로 블록 한도를 신중하고 점진적으로 올리는 것이 좋습니다.

1. 인프라 준비 상태

광범위한 생태계 인프라는 코어 클라이언트 최적화 속도에 맞춰 발전해야 합니다. 특히 쓰기 계층이 읽기 계층(예: RPC 노드, 인덱서, 아카이브 서비스)보다 빠르게 확장되면 사용자 경험이 저하될 수 있습니다.

2. 적시 블록 전파

또 다른 병목은 리더 노드에서 나머지 클러스터로 블록을 전달하는 과정에 있습니다. 블록이 크게 늘어나면 특히 부하가 높은 상황에서 블록 배포 시간이 400ms 목표를 초과할 수 있습니다.

시급한 과제는 샤드가 클러스터 전체에 배포되는 Transaction Validation Unit (TVU)의 재전송 단계입니다. Turbine의 공격적인 팬아웃 계수 200으로 인해 대형 검증인은 초당 송신 패킷(PPS)이 150,000개에 육박합니다. 즉, 각 노드는 다른 200개 노드로 샤드를 중계해야 합니다. 이 과정이 비효율적으로 처리되면 샤드 적체, 불규칙한 리더 전환, 네트워크 전반의 일관되지 않은 상태 뷰가 발생할 수 있습니다.

이를 해결하기 위해 Anza 엔지니어들은 현재 블록 배포 파이프라인을 전면 개편하고 있습니다. 팀은 패킷 처리를 사용자 공간에 직접 노출해 커널을 우회할 수 있는 XDP(eXpress Data Path)로 전환하고 있습니다. 이 방식은 비용이 큰 중간 복사를 제거하여 검증인 소프트웨어가 네트워크 인터페이스 카드(NIC)와 직접 통신할 수 있게 합니다.

Accounts Lattice Hash (ALH)

Solana가 수십억 개의 계정을 지원하려면 전체 계정 상태를 해싱하는 더 확장성 높은 방식이 필요합니다. 새로 도입된 **Accounts Lattice Hash (ALH)**는 기존 Merkle 기반 계정 해시를 동형 해싱 기반의 더 효율적이고 확장 가능한 대안으로 교체합니다. 동형 해싱을 사용하면 처음부터 다시 계산하지 않고도 기존 해시에서 새 해시를 만들 수 있습니다.

현재 Solana는 두 가지 계정 상태 해시를 유지합니다.

• Epoch Accounts Hash (EAH): 전체 계정 상태의 Merkle 루트로, 에포크마다 한 번 계산됩니다.
• Accounts Delta Hash (ADH): 단일 블록 내에서 변경된 계정의 Merkle 루트로, 블록마다 다시 계산됩니다.

두 방식 모두 공개 키를 기준으로 계정을 정렬하고 Merkle 트리를 구성합니다. 이로 인해 특히 계정 집합이 커질수록 성능과 확장성 문제가 발생합니다. 이중 해시 모델은 절충안으로 등장했습니다. EAH는 모든 계정 상태를 포함해 정확하지만 생성 빈도가 낮고, ADH는 자주 생성되지만 변경된 계정만 포함해 부분적입니다. 이상적으로는 Merkle 트리를 다시 계산하는 오버헤드 없이 모든 블록에 전체 계정 상태의 완전한 최신 해시가 포함되어야 합니다.

Accounts Lattice Hash의 작동 방식

ALH는 증분 업데이트가 가능한 동형 해시 함수를 사용해 이 목표를 달성합니다. 매번 Merkle 트리를 재구축하는 대신 계정에 쓰기가 발생할 때 개별 계정 해시(LtHashes)를 더하거나 뺍니다. 최종 결과는 모든 계정 상태를 요약하는 단일 2048바이트 해시입니다. 무엇보다 처음부터 다시 계산하지 않고 블록 단위로 업데이트할 수 있습니다.

이 방식은 O(n) 복잡도를 제공하며, Merkle 트리의 O(n log n) 복잡도보다 크게 개선되었습니다. 비용이 큰 재계산 없이 모든 블록에 전체 계정 상태의 해시를 포함할 수 있습니다.

통합 및 폐기되는 해시

이번 출시는 세 개의 개별 SIMD로 구성되며, Agave 2.2 릴리스 주기 동안 각각 독립적인 기능 게이트를 통해 활성화됩니다.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: 스냅샷에서 Accounts Lattice Hash 사용
• SIMD-0223: Accounts Delta Hash 제거

이러한 변경으로 Accounts Lattice Hash가 ADH와 EAH를 모두 대체합니다. ALH는 각 블록의 뱅크 해시에 통합되어 에포크 단위가 아닌 블록 단위로 전체 상태를 해싱할 수 있게 됩니다.

성능과 상충 관계

ALH로 전환하면 블록마다 수행하던 Merkle 기반 해싱이 제거되어 검증인 성능이 크게 향상됩니다. 합의와 스냅샷 생성 과정도 간소화됩니다. 예를 들어 검증인은 블록 확정이나 스냅샷 생성 중에 더 이상 계정을 정렬하거나 트리를 재구축할 필요가 없습니다. ALH 업데이트는 단순한 덧셈 연산입니다.

그러나 이 방식은 Merkle 또는 Verkle 트리와 달리 포함 증명이나 제외 증명을 지원하지 않습니다. 이는 라이트 클라이언트와 단순 결제 검증(SPV) 같은 일부 암호학적 검증 사용 사례에 영향을 주지만, 효율성이 크게 향상된다는 점에서 감수할 만한 상충 관계로 평가됩니다. 포함 증명을 위한 대체 방식에 관한 논의는 여기에서 확인할 수 있습니다.

스냅샷 통합

초기 Accounts Lattice Hash 계산에는 많은 비용이 들기 때문에 이제 ALH 값은 검증인 스냅샷에 유지되며, 사용 가능한 경우 시작할 때 복원됩니다. 스냅샷에는 Merkle 기반 Snapshot Hashes 대신 업데이트된 ALH 형식이 반영되어 Solana의 저장 및 해싱 모델이 새로운 설계를 중심으로 더욱 일관되게 정렬됩니다.

네이티브 Secp256r1 서명 검증

Solana는 secp256r1 타원 곡선 서명 검증을 네이티브로 지원합니다. 이는 Passkeys, WebAuthn 표준, 2단계 인증(2FA)을 포함한 고급 계정 추상화 모델과의 온체인 호환성을 지원하는 핵심 업그레이드입니다. 이번 업데이트는 Web2에서 이미 널리 쓰이는 비밀번호 없는 인증을 Web3 영역에 도입해 온체인 애플리케이션의 보안과 사용성을 높입니다.

원래 Agave 2.1 릴리스에 포함될 예정이었지만 2.2로 연기되었습니다. 자세한 내용은 Agave 2.1 업데이트의 Secp256r1 서명 검증 상세 분석을 확인하세요.

프리컴파일 정렬 버그

Agave 2.2의 초기 출시 직후 Secp256r1 및 Ed25519 프리컴파일 프로그램 구현에서 심각한 버그가 발견되었습니다. 이 버그는 정렬을 보장하지 않고 원시 트랜잭션 레이아웃을 노출하는 새로운 `--transaction-structure` 뷰 플래그에서 발생했습니다. 프리컴파일이 명령어 데이터에 2바이트 정렬을 잘못 가정해 블록 생성자와 검증인 사이에 실행 결과가 달라졌습니다. 이로 인해 뱅크 해시 불일치가 발생하고 리더가 작업을 중단하면서 가용성이 저하되었습니다. 이 문제는 4월 9일 처음 보고되었으며 4월 11일까지 신속하게 패치되었습니다. 사용자 자금에는 영향이 없었습니다. 자세한 내용은 직후 공개된 근본 원인 분석에서 확인할 수 있습니다.

SBPFv1, v2, v3 프로그램 배포 및 실행

Solana Berkeley Packet Filter (SBPF)는 Solana 프로그램을 효율적이고 안전하게 실행하도록 설계된 맞춤형 가상 머신입니다. 원래 Linux용으로 구축된 확장 Berkeley Packet Filter(eBPF)를 Rust 기반으로 포크한 것입니다. 

Solana의 Berkeley Packet Filter (SBPF) 업그레이드는 성능 향상, 보안 강화, 애플리케이션 개발자를 위한 새로운 기능 제공에 필수적입니다. Agave 2.2는 SIMD-0161에서 처음 제안한 SBPF 가상 머신용 정식 버전 관리 시스템을 도입해 장기적인 유지보수성과 성능 업그레이드의 기반을 마련합니다. 이 변경으로 SBPFv1(SIMD-0166), SBPFv2(SIMD-0173, SIMD-0174), SBPFv3(SIMD-0178, SIMD-0179, SIMD-0189) 프로그램을 배포하고 실행할 수 있습니다. 네트워크 전체를 다시 배포하지 않고도 프로그램 실행 환경을 단계적으로 발전시킬 수 있는 지속 가능한 프레임워크가 구축됩니다.

지금까지 모든 SBPF 업그레이드는 전역 기능 게이트를 통해 도입해야 했기 때문에 런타임 발전이 번거롭고 배포 조율이 거의 불가능했습니다. 버전 관리는 프로그램 동작을 전역 런타임에서 분리하고, 대신 실행 및 링크 가능 형식(ELF) 파일 헤더의 e_flags 필드에 인코딩된 프로그램별 버전 태그에 연결해 이 문제를 해결합니다. 이 방식은 다음을 지원합니다.

명시적인 런타임 동작

각 프로그램은 예상하는 명령어 집합 아키텍처, 즉 SBPF 버전을 나타냅니다. 프로그램 런타임은 이 버전에 따라 동작을 변경합니다.

통제된 출시

기능 게이트는 새 SBPF 버전의 배포와 실행을 독립적으로 활성화하고, 시간이 지나면서 이전 버전을 점진적으로 폐지합니다. 전체 변경 사항이 서로 다른 SBPF 버전으로 묶이므로 업그레이드가 더 깔끔하고 관리하기 쉬워집니다.

단계적 지원 종료

이전 SBPF 버전이 폐기되면 향후 지원을 중단해 가상 머신 로직을 단순화할 수 있습니다. 지원 종료는 천천히 진행되어 개발자가 프로그램을 마이그레이션하거나 다시 배포하고 새 버전에 적응할 충분한 시간을 제공합니다.

버전 식별자

현재 프로토콜은 0x0020 이외의 모든 e_flags 값을 SBPF v0으로 처리하며, 이는 기존 시스템에서 유효합니다. 하지만 이 방식은 여러 SBPF 버전을 지원하도록 확장할 수 없으므로 업데이트해야 합니다.

새 SBPF 버전을 지원하는 첫 번째 기능 게이트가 활성화되면 프로토콜이 e_flags를 해석하는 방식이 변경되며, 해당 값을 대응하는 SBPF 버전 번호에 직접 매핑합니다. 이 시스템에서 0x0000은 SBPF v0, 0x0001은 SBPF v1을 나타내는 식입니다.

CPI 호출자 제한 해제

Agave 2.2 릴리스 주기에는 오랫동안 기다려 온 개선 사항이 포함됩니다. Cross-Program Invocations (CPI)에 적용되던 기존 제약이 제거됩니다. 현재 CPI를 통해 호출되는 모든 프로그램은 호출자가 명령어 계정으로 명시적으로 전달해야 합니다. 특히 CPI가 깊게 중첩된 경우 트랜잭션 구성이 복잡해지고 컴퓨트 오버헤드가 크게 증가합니다. 그러나 이 제한은 역사적인 이유로 남아 있을 뿐 현재 프로토콜에는 필요하지 않습니다.

SIMD-0163은 CPI 명령어가 호출의 모든 단계에서 프로그램 계정을 재귀적으로 전달하도록 요구하는 대신, 트랜잭션의 최상위 계정 목록에서 직접 참조할 수 있도록 해 이 제한을 해제합니다. 이 변경은 다음과 같은 이점을 제공합니다.

• 프로그램 계정의 중복 직렬화와 역직렬화를 방지해 CU 사용량을 크게 줄입니다. 단, 실행 파일을 별도 계정에 저장하는 loader-v3 프로그램은 제외됩니다. 프로그램 계정은 크기가 크기 때문에(~10MB 바이너리) 이 작업의 비용이 특히 높습니다.
• 피호출 프로그램 계정을 명령어 스택 전체에 전달할 필요가 없어 트랜잭션 구성이 단순해집니다.
• 조합성이 향상되어 모듈식으로 깊게 중첩된 프로그램 아키텍처를 더 쉽게 구축할 수 있습니다.

하위 호환성

기존 프로그램은 이 변경을 활용하려는 경우가 아니라면 영향을 받지 않습니다. 활용하려면 다음 중 하나를 선택할 수 있습니다.

피호출자를 정적으로 하드코딩하고 런타임이 부과하는 제약을 충족하기 위해 임의의 명령어 계정으로만 필요한 프로그램은 다른 명령어 계정의 인덱스가 바뀌지 않도록 NativeLoader1111111111111111111111111111111 같은 플레이스홀더를 전달할 수 있습니다.

특정 명령어 계정에 전달된 대상을 동적으로 호출하는 다른 모든 기존 프로그램은 제한 해제의 이점을 얻으려면 업데이트하고 다시 배포해야 합니다.

이 최적화는 안전성을 저해하지 않습니다. "가시성 지연" 기능은 동일한 트랜잭션 내에서 추가, 수정 또는 제거된 다른 프로그램을 호출하지 못하도록 합니다.

Loader-v4

Agave 2.2는 Loader-v3를 대체하도록 설계된 간소하고 유연한 프로그램 배포 메커니즘인 Loader-v4를 지원합니다. SIMD-0167을 통해 활성화되는 Loader-v4는 프로그램 계정 관리를 단순화하고 업그레이드 워크플로를 개선하며, 특히 DeFi처럼 중요한 환경에서 운영되는 라이브 프로그램에 필수적인 안전 기능을 도입합니다.

Loader-v4의 주요 기능:

단일 계정 모델: Loader-v4는 프록시 계정과 별도의 프로그램 데이터 버퍼가 필요하지 않습니다. 이제 단일 계정이 각 프로그램을 나타냅니다.

유지보수 모드

이제 프로그램을 영구적으로 종료하거나 다시 배포하지 않고도 실행 불가능한 "유지보수 모드"로 전환할 수 있습니다. 기존 프로그램 주소가 유지되므로 개발자는 주소를 포기하지 않고도 실행을 일시 중지할 수 있습니다. 예를 들어 익스플로잇이 발생했을 때 유용합니다.

자유로운 크기 조정

Loader-v4는 배포 후 프로그램 바이너리의 확장과 축소를 모두 지원합니다. 리소스를 더 유연하게 할당하고 잠긴 자금을 회수할 수 있습니다.

선택적 버퍼 사용

재배포 시 항상 외부 버퍼 계정이 필요했던 Loader-v3와 달리 Loader-v4에서는 버퍼가 선택 사항입니다. 이제 프로그램을 기본 프로그램 계정에 직접 다시 배포할 수 있어 업로드 중 잠가야 하는 자금이 절반으로 줄어듭니다.

부분 재배포

Loader-v3에서는 업그레이드할 때마다 전체 프로그램 바이너리를 다시 업로드해야 했습니다. 반면 Loader-v4는 부분 업로드를 지원하므로 개발자가 프로그램의 특정 섹션만 패치할 수 있습니다. 특히 소규모 업데이트에 유용합니다.

Loader-v3에서 원활하게 마이그레이션

Loader-v3로 배포된 프로그램은 프로그램 주소를 변경하지 않고 Loader-v4로 마이그레이션할 수 있습니다. 이는 Loader-v3의 새로운 Migrate 명령어를 통해 지원됩니다. 이 작업은 가시성을 지연시키므로 현재 슬롯의 남은 시간 동안 프로그램을 사용할 수 없습니다.

Loader-v4가 활성화되면 별도의 기능 게이트가 작동해 Loader-v3로의 신규 배포를 비활성화합니다. 기존 Loader-v3 프로그램은 계속 작동하지만, 앞으로 모든 배포는 Loader-v4를 사용할 것으로 예상됩니다.

loader-v4 프로그램을 확정할 때 다음 버전 주소를 지정해 연결 리스트를 구성할 수 있습니다. 이는 프로그램 재배포의 대안을 제공하며, 사용자 인터페이스에서 사용자가 선택할 수 있는 확정된 프로그램 버전 목록을 제공할 수 있게 합니다.

권한 관리와 계정 종료 메커니즘은 Loader-v4에서도 동일하게 유지됩니다. 이 모든 기능은 새로운 program-v4 CLI 하위 명령을 통해 사용할 수 있습니다.

결론

Agave 2.2는 Solana 프로토콜의 중요한 이정표입니다. 핵심 런타임 개선과 새로운 기능을 제공해 네트워크의 기술적 영역을 확장합니다. 이번 릴리스에는 여러 핵심 변경 사항이 포함됩니다. 블록 용량이 20% 증가하고, 확장 가능한 상태 해싱을 위한 Accounts Lattice Hash (ALH)가 통합되며, 여러 프로그램 개발 기능이 개선됩니다. 또한 대중적인 암호화 기술 통합에 필수적인 Secp256r1 서명 검증도 지원합니다. 이러한 개선 사항은 처리량과 개발자 경험을 향상하고, 네트워크가 더 다양한 애플리케이션을 지원할 수 있도록 합니다.

프로그램을 구축하거나 검증인을 운영하거나 네트워크와 상호작용하는 모든 사용자에게 Agave 2.2는 더 높은 성능과 유연성, 탄력성을 제공합니다.

추가 자료

• Agave 클라이언트 저장소
• Agave v2.2 릴리스 일정
• Agave v2.2 변경 로그
• Agave v2.2 태그가 지정된 풀 리퀘스트