Agave 4.3 업데이트: 알아야 할 모든 것
소개
Agave 4.3과 함께 Solana는 역대 최대 규모라 할 수 있는 프로토콜 업그레이드를 준비하고 있습니다. 4.3 릴리스 주기에는 많은 기대를 받아 온 Solana의 새로운 합의 메커니즘 Alpenglow이 도입됩니다. 최종 단계는 TowerBFT에서 메인넷을 일제히 전환하는 "Alpenswitch"입니다.
출시 이후 Solana의 합의 아키텍처는 Proof of History와 TowerBFT를 중심으로 구축되었습니다. 검증인은 일반 사용자 트랜잭션과 함께 처리되고 블록에 포함되는 트랜잭션을 제출해 투표합니다. 이후 이러한 투표가 32개 슬롯에 걸쳐 쌓이면서 최종성이 확보됩니다. 슬롯 시간이 400밀리초라고 가정하면 Solana의 최종성 도달 시간은 약 12.8초입니다.
Proof of History(PoH)는 이벤트 순서를 정하고 시간을 조율하는 독창적인 접근 방식으로, 출시 당시 Solana를 대표한 핵심 아키텍처 혁신 중 하나였습니다. 이제 이 기술이 단계적으로 종료되면서 한 시대가 막을 내립니다. 동시에 Solana를 처음 차별화했던 기술에서 프로토콜이 얼마나 발전했는지도 보여줍니다.
Alpenglow은 'PoH + TowerBFT'를 Votor로 대체합니다. Votor에서는 검증인이 핵심 트랜잭션 파이프라인 외부에서 투표를 교환하고, 이를 암호학적 인증서로 집계합니다. 목표 최종성 도달 시간은 약 150밀리초입니다.
트랜잭션을 제출하고 계정 상태를 읽는 사용자와 애플리케이션은 마이그레이션할 사항이 거의 또는 전혀 없습니다. 트랜잭션과 수수료 구조도 그대로 유지됩니다. 가장 큰 조정이 필요한 대상은 블록, 투표, 스트림 또는 커밋 데이터를 사용하는 검증인과 인프라입니다.
블록에서 투표 트랜잭션이 사라지고, confirmed와 finalized가 사실상 하나로 합쳐집니다. 스트리밍 인프라에는 같은 슬롯 내에서 경합하는 뱅크를 구분할 수 있는 새로운 정보가 추가됩니다.
이 글에서는 Votor가 블록 생성과 최종성을 어떻게 바꾸는지 등 Alpenglow의 작동 방식을 살펴봅니다. Agave 4.3 릴리스 주기에 도입되는 다른 주요 변경 사항도 다룹니다.
단계적 출시: Votor 우선, Rotor는 이후
Alpenglow은 두 가지 주요 구성 요소를 중심으로 설계되었습니다. Votor는 Solana의 투표 및 최종성 메커니즘을 대체하고, Rotor는 네트워크에서 블록이 전파되는 방식을 재설계합니다. 두 메커니즘은 단계적으로 출시되며 Votor가 먼저 도입됩니다.
Agave 4.3은 기존 블록 전파 프로토콜인 Turbine을 유지하면서 Votor를 도입합니다. Rotor는 Alpenglow의 초기 활성화를 규정하는 제안인 SIMD-0326에서 명시적으로 제외되었습니다. 배포하려면 별도의 SIMD가 필요합니다. 초기 출시는 검증인이 합의에 도달하는 방식을 바꾸지만, 네트워크에서 블록 데이터가 이동하는 방식까지 바꾸지는 않습니다.
Votor
Votor는 TowerBFT의 투표 트랜잭션과 잠금 시스템을 더 직접적인 검증인 간 프로토콜로 대체합니다. TowerBFT에서는 검증인이 블록에 포함되는 트랜잭션을 제출해 투표하며, 충분한 잠금 깊이가 누적되면 블록이 최종 확정됩니다. Votor에서는 검증인이 서명된 투표 메시지를 직접 교환하고, 프로토콜이 해당 서명을 압축된 인증서로 집계합니다.
Votor는 투표가 32개 슬롯에 걸쳐 누적되기를 기다리는 대신, 한두 라운드의 투표 후 블록을 최종 확정할 수 있습니다. 목표 최종성 도달 시간은 약 150밀리초로, TowerBFT의 약 12.8초보다 훨씬 짧습니다.
Votor에는 동시에 작동하는 두 가지 최종성 경로가 있습니다.
첫 번째 라운드에서 스테이킹 지분의 80% 이상이 블록을 공증하면 해당 투표를 Fast-Finalization Certificate로 집계할 수 있으며, 블록은 즉시 최종 확정됩니다. 이는 프로토콜의 빠른 경로로, 한 라운드의 투표만 필요합니다.
80% 임계값에 도달하지 못해도 스테이킹 지분의 60%를 초과하는 지분이 블록 공증에 투표했다면 계속 진행할 수 있습니다. 이때 Notarization Certificate가 생성되어 두 번째 투표 라운드를 진행할 수 있습니다. 2라운드 경로를 통해 스테이킹 지분의 60%를 초과하는 지분이 최종화 투표를 하면 Finalization Certificate가 형성되고 블록이 최종 확정됩니다.
따라서 전체 프로토콜에는 Notarization, Notarization Fallback, Skip, Skip Fallback, Final의 다섯 가지 투표 유형이 있습니다. 이러한 투표의 조합에 따라 공증, 폴백, 건너뛰기 또는 최종화 인증서가 생성됩니다. 이 인증서는 슬롯의 결과에 충분한 스테이킹 지분이 동의했다는 압축된 암호학적 증거로 사용됩니다.
Votor는 응답하는 정직한 스테이킹 지분이 60%에 불과해도 계속 진행할 수 있도록 설계되었습니다. 스테이킹 지분의 최대 20%가 적대적으로 행동하고 다른 20%가 오프라인이거나 응답하지 않아도 됩니다. 이는 의도적인 절충입니다. Alpenglow은 기존 BFT 설계의 3분의 1 비잔틴 임계값 대신, 중단되거나 사용할 수 없는 검증인에 대한 허용 범위를 넓힌 20+20 복원력 모델을 채택합니다.
Votor는 합의 시계로 사용되던 Proof of History도 제거합니다. 대신 검증인은 로컬 타임아웃 타이머를 사용합니다. 허용 가능한 블록을 받지 못한 채 충분한 시간이 지나면 검증인은 건너뛰기 투표를 보내 합의가 계속 진행되도록 할 수 있습니다. 이를 통해 TowerBFT보다 시간 측정과 합의의 관계가 단순해집니다.
Rotor
Rotor는 Agave 4.3에 포함되지 않으며, 현재 공개된 활성화 일정도 없습니다. 따라서 Votor가 활성화된 후에도 Turbine이 계속 블록 데이터를 전달합니다. Rotor와 릴레이 선택에 사용되는 스마트 샘플링 메커니즘은 향후 별도의 제안과 출시 절차를 거칩니다.
중요한 점은 Solana가 1초 미만의 최종성을 달성하기 위해 Rotor를 기다릴 필요가 없다는 것입니다. 현재 Alpenglow 출시는 Turbine을 유지한 상태에서 Agave 4.3의 Votor로 약 150밀리초의 최종성을 달성하는 것을 목표로 합니다. Rotor는 블록 전파를 더욱 개선하고 전반적인 Alpenglow 아키텍처의 효율을 높이기 위한 것이지만, Votor의 새로운 최종성 모델에 필수적인 요소는 아닙니다.
투표 트랜잭션 종료
Alpenglow 도입으로 나타나는 가장 눈에 띄는 변화 중 하나는 Solana 블록에서 투표 트랜잭션이 사라진다는 점입니다. 검증인은 이러한 투표에 트랜잭션 수수료를 지불하며, 네트워크는 이를 처리하고 저장하는 데 대역폭, 컴퓨팅 자원, 원장 공간을 사용합니다.
과거에는 투표 트랜잭션이 온체인에 기록된 전체 트랜잭션의 약 4분의 3을 차지했습니다. 블록 용량이 늘면서 이 비율은 낮아졌습니다. 투표 트랜잭션은 저렴하고(5,000 lamports) 전체 컴퓨팅 자원의 일부(약 5%)만 사용하지만, 네트워크의 원시 트랜잭션 수와 원장 크기를 부풀립니다.
Alpenglow에서는 검증인이 대신 BLS로 서명된 투표 메시지를 서로 직접 교환합니다. Agave의 ConsensusPool는 관찰한 투표를 추적하고 충분한 스테이킹 지분을 인증서로 집계합니다. Votor는 이 인증서를 사용해 합의를 진행하거나 최종 확정합니다.
그렇다고 검증인의 참여 증거가 원장에서 사라지는 것은 아닙니다. Alpenglow 블록에는 합의 정보가 담긴 새로운 블록 푸터가 추가됩니다. 현재 Agave 구현에서 BlockFooterV1는 최신 최종화 인증서와 notar_reward_cert 및 skip_reward_cert를 포함할 수 있습니다. 보상 인증서에는 집계된 BLS 서명과 투표한 검증인을 식별하는 비트맵이 포함됩니다.
현재 Vote Program 트랜잭션을 인덱싱해 검증인의 투표 여부를 확인하는 시스템은 Alpenglow의 인증서와 투표 관련 데이터로 전환해야 합니다. 단순히 투표 트랜잭션을 필터링하는 기존 트랜잭션 파이프라인은 대체로 계속 작동할 수 있습니다. Alpenswitch 이후에는 필터링할 대상이 사라질 뿐입니다.
이 전환은 익숙한 Solana TPS 통계에도 단절을 만듭니다. Alpenglow이 활성화되면 사용자 활동이 전혀 변하지 않아도 투표 트랜잭션을 포함한 원시 TPS 측정치는 급격히 하락합니다. 따라서 Alpenswitch 전후의 활동을 비교할 때는 비투표 TPS가 의미 있는 지표입니다. 투표 트랜잭션을 제거하면 Solana의 실제 처리량을 둘러싼 오랜 혼란이 사라지고 다른 네트워크와도 더 쉽게 비교할 수 있습니다.
투표 트랜잭션을 제거하면 일부 용량을 사용자에게 돌려줄 수 있습니다. 다만 투표가 네트워크 컴퓨팅 부하에서 차지하는 비중은 비교적 작으므로 그 효과를 과장해서는 안 됩니다.
커밋 수준
Alpenglow은 Solana에 오랫동안 존재해 온 또 하나의 구분, 즉 confirmed와 finalized 커밋 사이의 격차도 없앱니다.
현재 애플리케이션은 세 가지 커밋 수준 중 하나를 선택합니다. processed는 가장 최신 상태를 제공하지만 클러스터 전체의 보장은 없습니다. confirmed는 스테이킹 지분의 압도적 다수가 블록에 투표했음을 의미하며, 일반적으로 한두 슬롯 내에 도달합니다. finalized는 결정론적 최종성을 제공합니다. 하지만 TowerBFT에서는 블록이 최대 투표 잠금에 도달해야 하므로 확인과 최종 확정 사이에 약 32개 슬롯의 격차가 생깁니다. 일반적으로 지연 시간에 민감한 RPC 요청에는 confirmed가 권장되고, 더 강력한 보장이 필요할 때는 finalized가 권장됩니다.
실제로 confirmed는 매우 안정적이었습니다. 낙관적으로 확인된 Solana 블록이 이후 최종 확정에 실패한 사례는 없습니다. 하지만 프로토콜 보장은 여전히 더 약합니다. 확인된 블록은 아직 결정론적으로 최종 확정된 상태가 아닙니다. 따라서 이러한 잔여 꼬리 위험을 허용할 수 없는 브리지, 거래소, 결제 시스템 등의 애플리케이션은 지금까지 finalized를 기다려야 했습니다.
Alpenglow은 이러한 절충을 없앱니다. Votor가 빠른 최종화 인증서 또는 최종화 인증서를 생성하면 블록은 최종 확정됩니다. Votor가 최종 확정된 뱅크를 루트로 선택하면 검증인은 가장 높은 확인 슬롯, 루트, 가장 높은 압도적 다수 루트를 동시에 업데이트합니다.
개발자 관점에서 Alpenswitch 이후 confirmed와 finalized는 사실상 동일한 합의 상태를 가리킵니다. 기존 애플리케이션은 활성화 당일 커밋 설정을 변경할 필요가 없습니다. RPC 인터페이스는 계속 processed, confirmed, finalized를 허용하지만, 마지막 두 수준 사이의 지연 시간 차이는 사라집니다.
일반 RPC 사용자는 Votor의 두 최종화 경로를 구분할 수 없습니다. 블록이 한 라운드에서 80%의 빠른 최종화 임계값에 도달하든, 60% 임계값의 2라운드 경로를 통해 최종 확정되든 외부에 표시되는 결과는 같습니다.
여러 후보 블록
Alpenglow의 또 다른 중요한 변화는 검증인 데이터를 사용하는 RPC 제공업체, 인덱서 및 기타 인프라를 대상으로 합니다. 이제 슬롯을 고유한 블록 식별자로 취급할 수 없습니다.
Solana 슬롯은 리더가 블록을 생성할 수 있는 시간 구간입니다. 반면 bank는 특정 후보 블록을 실행해 생성된 상태를 검증인이 로컬에서 표현한 것입니다. 두 개념은 항상 달랐고 경합하는 뱅크도 새로운 현상은 아닙니다. 하지만 많은 프로덕션 인프라는 슬롯과 블록을 같은 의미로 취급해 왔습니다.
Alpenglow에서는 이러한 가정이 갈수록 위험해집니다.
Agave 4.3은 계정, 트랜잭션, 엔트리, 블록 업데이트를 스트리밍하는 검증인 인터페이스인 Geyser에 새로운 식별자 bank_id를 추가합니다. update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank, notify_block_metadata_for_bank를 포함한 새로운 뱅크 인식 콜백은 이벤트를 생성한 특정 뱅크와 해당 이벤트를 연결합니다. 뱅크 범위 상태 알림에도 마찬가지로 bank_id가 포함됩니다. 이전 콜백은 4.3에서 호환성을 위해 유지되지만 더 이상 권장되지 않으며, 다음 Agave 메이저 릴리스에서 제거될 예정입니다.
중요한 점은 bank_id가 전역적으로 합의된 블록이 아니라 로컬 뱅크 인스턴스를 식별한다는 것입니다. Agave는 검증인 런타임이 유지하는 로컬 원자적 카운터에서 뱅크 ID를 생성합니다. 따라서 같은 블록을 재실행하는 두 검증인이 동일한 bank_id를 할당할 것으로 기대해서는 안 됩니다. 인프라는 단일 검증인에서 들어오는 경합 스트림을 분리할 때 (slot, bank_id)를 사용해야 합니다. 서로 다른 검증인이나 연결의 데이터를 조정할 때는 블록 ID 또는 블록해시를 사용해야 합니다.
Alpenglow의 향후 단계에서는 같은 슬롯에 여러 뱅크가 존재하는 것이 검증인 운영의 일반적인 형태가 됩니다.
가장 명확한 예는 초기 Votor 활성화 이후 출시되는 Alpenglow 구성 요소 중 하나인 빠른 리더 핸드오버입니다. 리더는 합의가 수락할 것으로 예상되는 부모를 기반으로 낙관적으로 블록 생성을 시작할 수 있습니다. Votor가 해당 부모를 건너뛰기로 결정하면 리더는 부모를 전환하고 남은 리더 시간 동안 블록을 다시 생성할 수 있습니다. 내부적으로는 같은 슬롯의 뱅크 하나를 다른 뱅크로 교체하는 것입니다. Agave에는 이미 이 전환을 표현하는 데 필요한 UpdateParent 메커니즘이 포함되어 있습니다. 빠른 리더 핸드오버는 Agave 4.3의 초기 Alpenglow 활성화에 포함되지 않으며 4.4에서 출시될 예정입니다.
리더 이중 서명도 대체로 같은 결과를 만들 수 있습니다. 리더가 같은 슬롯에 대해 서로 다른 두 블록에 서명해 배포하면 검증인은 일시적으로 두 후보를 모두 보관하고 평가해야 할 수 있습니다. Votor는 비동기식이며 검증인은 블록, 투표, 인증서, 로컬 타임아웃이 도착하는 대로 처리하므로 네트워크의 각 부분이 후보를 서로 다른 순서로 볼 수 있습니다.
최근 변경 사항에서는 MAX_ALTERNATE_BLOCKS_PER_SLOT가 11에서 6으로 축소되었습니다. 따라서 검증인은 슬롯당 최대 7개의 후보 블록만 보관하면 됩니다. 합의는 최종적으로 이러한 후보를 하나의 기록으로 확정합니다. Votor에서 공증하려면 스테이킹 지분의 60%를 초과하는 지분이 필요합니다. 상당한 지분이 두 블록 모두에 투표하지 않는 한, 충돌하는 두 블록이 모두 유효한 공증 인증서를 얻을 수는 없습니다. 비잔틴 방식으로 행동하는 지분이 20% 미만이라는 Alpenglow의 가정하에서는 프로토콜의 안전성 가정을 위반하지 않고 충돌하는 공증 인증서가 생성될 수 없습니다.
Geyser 사용자가 얻어야 할 실질적인 교훈은 명확합니다. 일시적 상태의 키로 슬롯만 사용해서는 안 됩니다. 합의가 살아남을 뱅크를 식별할 때까지 계정 변경, 트랜잭션, 엔트리, 블록 메타데이터를 (slot, bank_id)별로 추적해야 합니다. 같은 슬롯에 다른 뱅크가 나타나면 해당 이벤트는 별도의 후보 상태에 속하므로 첫 번째 뱅크의 이벤트를 조용히 덮어써서는 안 됩니다.
검증인 승인 티켓
현재 Solana 검증인 운영에서 가장 큰 비용은 투표 트랜잭션입니다. TowerBFT에서는 검증인이 투표를 제출할 때마다 표준 트랜잭션 수수료를 지불하며, 에포크당 약 2 SOL이 듭니다. Alpenglow은 트랜잭션 수수료를 활성 합의 집합에 승인된 검증인에게 에포크당 한 번 부과하는 Validator Admission Ticket(VAT) 수수료로 대체합니다.
이 전환을 위한 기반은 이미 운영 중입니다. SIMD-0387에 명시된 BLS 공개 키 등록이 7월 메인넷에서 활성화되었고, 곧이어 VAT 기능 게이트인 SIMD-0357이 활성화되었습니다. Votor는 여러 검증인의 서명을 하나의 압축된 인증서로 집계할 수 있도록 BLS 서명을 사용합니다. 각 검증인은 Alpenglow에 참여하기 전에 투표 계정에 BLS 공개 키를 등록해야 합니다. VAT 게이트가 활성화된 이후 BLS 공개 키가 없는 검증인은 이미 투표 집합에서 제외되고 있습니다.
Alpenglow 도입 전까지 검증인은 계속 일반 투표 트랜잭션을 제출하고 관련 수수료를 지불합니다. 이 단계에서 VAT는 주로 승인 필터로 작동합니다. 자격을 갖추려면 BLS 키를 보유하고 스테이킹 지분 기준 상위 2,000개 검증인에 포함되어야 합니다. Alpenglow이 활성화되면 VAT가 시작되고 투표 트랜잭션은 사라집니다.
Alpenglow이 활성화되면 에포크 경계를 기준으로 승인 여부가 다시 계산됩니다. 검증인의 투표 계정에는 등록된 BLS 키와 티켓 및 임대료 면제를 충당할 충분한 SOL이 있어야 합니다. 자격을 갖춘 계정이 2,000개를 넘으면 시스템은 스테이킹 지분을 기준으로 순위를 매겨 지분이 가장 많은 검증인을 승인합니다. 그런 다음 각 승인된 검증인의 투표 계정에서 티켓 비용을 직접 차감해 Solana의 소각 계정으로 보냅니다. 따라서 검증인은 투표 계정에 충분한 자금을 유지해야 합니다. 기존 시스템에서는 투표 트랜잭션 수수료가 검증인의 신원 계정에서 차감되었습니다.
원래 Alpenglow 및 VAT 제안에서는 에포크당 티켓 가격을 1.6 SOL로 정했습니다. 이는 검증인이 기존에 투표 트랜잭션에 지출하던 약 2 SOL의 80% 수준입니다. 이 수치는 Solana의 기존 목표 슬롯 시간인 400밀리초를 가정한 것입니다. 대신 SIMD-0525는 슬롯 시간에 따라 VAT를 조정합니다. 슬롯 시간이 200밀리초일 때 승인 비용은 0.8 SOL입니다.
VAT는 이 비용의 도착지도 바꿉니다. 현재 투표 트랜잭션이 지불하는 5,000-lamport 기본 수수료는 절반으로 나뉩니다. 50%는 소각되고 50%는 블록 리더에게 돌아갑니다. 반면 VAT는 전액 소각 계정으로 전송됩니다. 하지만 VAT의 더 큰 목적은 SOL을 실질적으로 더 디플레이션화하는 것이 아닙니다. 투표 트랜잭션 수수료가 사라진 후에도 합의 집합에 참여하는 데 경제적 비용이 들도록 유지하는 것입니다.
안전성과 준비
운영 중인 네트워크의 합의 프로토콜을 교체하는 작업은 이례적으로 위험합니다. 따라서 Alpenglow은 일반적인 Agave 기능 활성화보다 훨씬 광범위한 테스트와 마이그레이션 절차를 거칩니다. 전용 커뮤니티 테스트 클러스터와 버그 바운티도 포함됩니다.
5월부터 검증인 운영자들은 전용 Alpenglow Community Cluster를 운영해 왔으며, 현재 100개가 넘는 노드로 성장했습니다. 운영자는 실제 검증인 하드웨어와 네트워크 환경을 사용합니다. 이를 통해 통제된 환경에서 재현하기 어려운 지리적 분산, 지연 시간 변동, 소프트웨어 구성, 재시작, 운영 실수 등의 조건에서 Alpenglow을 테스트할 수 있습니다.
이 클러스터의 가장 중요한 목적 중 하나는 Alpenswitch 자체를 테스트하는 것이었습니다. 운영자들은 클러스터에서 이미 Alpenglow이 실행된 후 Votor가 작동하는지만 확인하지 않고, TowerBFT에서 새로운 합의 시스템으로 전환하는 과정을 반복해서 검증했습니다.
Alpenglow은 전용 적대적 검토도 거쳤습니다. 8월에 Anza는 최대 50,000 SOL 규모의 상금 풀을 제공하는 2주간의 Alpenglow Bug Bounty Competition을 열었습니다. 상시 운영되는 Agave 바운티와 달리 이 대회는 Votor, BLS 서명 및 인증서 검증, 검증인 승인, TowerBFT에서 Alpenglow으로의 마이그레이션 경로 등 새로운 합의 스택만을 대상으로 했습니다. 참여 규모도 상당했습니다. Anza는 300건이 넘는 제출을 받았으며 25,000 SOL 이상의 바운티를 지급할 예정이라고 밝혔습니다.
Alpenglow 도입과 함께 Frankendancer 지원이 종료됩니다. Frankendancer는 Firedancer의 네트워킹 및 블록 생성 구성 요소와 실행 및 합의를 담당하는 Agave 구성 요소를 결합한 전환용 클라이언트로 설계되었습니다. 이러한 하이브리드 아키텍처에서 새로운 합의 시스템까지 지원하면 유지보수 및 보안 부담이 크게 늘어납니다. 따라서 Firedancer 팀은 완전한 Firedancer 클라이언트 개발에 집중합니다.
검증인에게 공유된 지침에 따르면 Frankendancer와 완전한 Firedancer 모두 TowerBFT에서 Alpenglow으로 전환하는 짧은 마이그레이션 구간 자체는 지원하지 않습니다. 따라서 Firedancer 운영자는 Alpenswitch 전에 Agave 검증인으로 장애 조치하고, 전환이 끝날 때까지 Agave를 유지한 뒤, 클러스터가 Alpenglow에서 정상적으로 작동하면 Firedancer로 다시 이동해야 합니다.
Alpenswitch의 실제 진행 방식
Alpenglow은 임의의 실제 시각에 모든 곳에서 동시에 켜지지 않습니다. 기능이 활성화되면 프로토콜은 5,000개 슬롯 뒤에 마이그레이션 경계를 설정합니다. 검증인이 이 경계를 넘어 충분히 강하게 확인된 블록을 찾는 동안 TowerBFT는 계속 작동합니다. 이후 검증인은 선택된 Alpenglow 제네시스 블록에 BLS 서명하고 해당 제네시스 투표를 서로 직접 배포합니다.
스테이킹 지분의 82% 이상이 동일한 제네시스 블록에 서명해 Alpenglow 제네시스 인증서가 생성되면 전환이 이뤄집니다. 해당 인증서를 수신하고 검증한 검증인은 제네시스 블록 이후 TowerBFT를 비활성화하고 합의된 상태에서 Votor를 초기화합니다. 이후 인증서가 검증인 집합 전체로 전파되면서 나머지 노드도 경계를 넘습니다.
이 인증서를 사용하면 인프라 운영자는 클러스터가 Alpenswitch의 어느 단계에 있는지 편리하게 확인할 수 있습니다.
Agave 4.3에는 새로운 RPC 메서드 getAgGenesisCert가 도입됩니다. 마이그레이션 전 Agave 4.3 노드는 null을 반환합니다. 클러스터 전환 후에는 제네시스 블록과 집계된 BLS 서명을 포함한 Alpenglow 제네시스 인증서를 반환합니다. 이 메서드를 지원하지 않는 이전 노드는 대신 Method not found을 반환합니다. CLI에서는 solana alpenglow-genesis-info를 통해 같은 정보를 확인할 수 있습니다.
따라서 마이그레이션에 대응해야 하는 검증인, RPC 제공업체 및 기타 인프라는 특정 타임스탬프에 Alpenglow이 활성화되었다고 가정하기보다 제네시스 인증서의 존재 여부를 확인하는 편이 좋습니다.
새로운 암호학적 시스템 호출
Agave 4.3은 sBPF에서 직접 수행하기에는 비용이 지나치게 큰 연산을 위한 새로운 런타임 프리미티브를 추가해 SVM의 암호학 도구를 확장합니다.
주요 추가 기능은 SHA-512 해싱과 큰 정수 모듈러 지수 연산입니다. 둘 다 기존 기능에 추가되는 형태이며 기능 게이트가 적용됩니다. 기존 프로그램에는 영향이 없습니다. 이를 사용하기로 선택한 프로그램은 계산 비용이 큰 암호화 작업을 검증인 런타임 내부의 최적화된 네이티브 구현에 위임할 수 있습니다.
큰 정수 모듈러 지수 연산
SIMD-0529: Big Integer ModExp Syscall은 다음을 계산하는 시스템 호출 sol_big_mod_exp를 도입합니다.
result = (base ^ exponent) mod modulus모듈러 지수 연산은 RSA 서명 검증, 암호학적 누산기, 일부 검증 가능한 지연 함수 및 기타 수론 기반 프로토콜의 핵심 연산입니다. SVM 프로그램 내부에서 임의 정밀도 정수 연산으로 직접 구현하면 컴퓨팅 자원이 매우 많이 듭니다. 특히 2048, 3072, 4096비트와 같은 일반적인 RSA 키 크기에서는 더욱 그렇습니다.
새로운 시스템 호출은 비용이 큰 산술 연산을 검증인 런타임으로 옮깁니다. 프로그램은 밑, 지수, 모듈러스를 리틀 엔디언 부호 없는 정수로 제공하고 호출자가 제공한 메모리에서 결과를 받습니다. 각 피연산자는 처음에 512바이트로 제한되며, 최대 4096비트 정수를 지원하기에 충분합니다.
가장 명확한 사용 사례는 RSA 검증입니다. 예를 들어 일반적인 RSA 서명을 검증하는 프로그램은 큰 정수 지수 연산을 직접 구현하는 대신, 흔히 사용되는 공개 지수 65537를 사용해 sol_big_mod_exp를 호출할 수 있습니다. 이 시스템 호출은 의도적으로 산술 프리미티브까지만 제공합니다. 해싱, PKCS#1 v1.5 또는 PSS와 같은 RSA 패딩, 키 검증, 프로토콜별 도메인 분리는 프로그램이 직접 처리해야 합니다.
효율적인 큰 정수 모듈러 축소도 수행할 수 있습니다. 지수로 1를 전달하면 연산은 다음과 같이 축소됩니다.
base mod modulus이를 통해 프로그램은 범용 큰 정수 구현 비용을 지불하지 않고도 SVM의 내장 머신 워드 크기보다 큰 정수를 축소할 수 있는 네이티브 프리미티브를 사용할 수 있습니다.
이 설계는 EIP-198에서 도입된 Ethereum의 ModExp 프리컴파일과 개념적으로 유사하며, 컴퓨팅 측정 모델은 EIP-198의 연산 복잡도 공식을 따릅니다. 하지만 Ethereum과 바이트 단위로 호환되지는 않습니다. Solana는 네이티브 시스템 호출 ABI를 통해 이 기능을 제공하고 리틀 엔디언 입력을 사용합니다. 또한 모듈러스는 1보다 큰 홀수여야 하며 짝수 모듈러스는 거부됩니다.
따라서 Solana가 EVM 프리컴파일 인터페이스 자체를 채택하지 않고도 상호 운용성에 이 시스템 호출을 유용하게 사용할 수 있습니다. Ethereum 방식의 암호학적 가정을 기반으로 구축된 증명, 서명 또는 증명을 검증하는 프로그램은 호출 방식을 조정하면서 동일한 기본 산술 연산을 재사용할 수 있습니다.
SHA-512
두 번째 추가 기능은 훨씬 단순하지만 즉시 유용합니다.
SIMD-0512: Sha512 Syscall은 sol_sha512를 추가해 온체인 프로그램이 검증인 런타임을 통해 SHA-512 해시 함수에 직접 접근할 수 있도록 합니다. 인터페이스는 Solana의 기존 sol_sha256, sol_keccak256, sol_blake3 시스템 호출과 같은 형태이며, 표준 64바이트 SHA-512 다이제스트를 반환합니다.
SHA-512는 특히 Solana 자체에서 광범위하게 사용하는 서명 체계인 Ed25519의 핵심 프리미티브 중 하나입니다. Agave와 Firedancer 모두 내부적으로 이미 SHA-512를 사용하지만, 이 변경 전에는 SVM 프로그램이 해당 최적화 구현에 직접 접근할 수 없었습니다. SHA-512가 필요한 프로그램은 알고리즘을 소프트웨어로 직접 구현해야 했습니다.
컴퓨팅 관점에서 이 차이는 큽니다. SIMD 추정에 따르면 sBPF 구현으로 짧은 입력을 해싱하면 수천 CU가 들지만, 시스템 호출로 같은 연산을 수행하면 100 CU 미만이 듭니다. sol_sha512는 Solana의 기존 SHA-256 시스템 호출과 동일한 일반 컴퓨팅 비용 모델을 사용합니다.
두 시스템 호출은 SVM의 더 큰 흐름을 이어갑니다. 일반적으로 사용되지만 계산 비용이 큰 암호학적 프리미티브를 개별 프로그램에서 표준화되고 측정 가능한 런타임 연산으로 옮기는 것입니다. 프로그램은 여전히 상위 수준의 암호학 프로토콜을 정의하지만, 검증인은 sBPF 구현보다 비용이 큰 기본 요소를 훨씬 효율적으로 실행할 수 있습니다.
결론
Agave 4.3의 핵심 변경 사항은 Alpenglow입니다. TowerBFT를 Votor로 대체하고, 블록에서 투표 트랜잭션을 제거하며, 최종성 도달 시간을 초 단위에서 밀리초 단위로 줄입니다. 또한 검증인 및 인프라가 합의와 상호작용하는 방식을 재편합니다.
대부분의 사용자와 애플리케이션 개발자에게는 이러한 전환의 상당 부분이 보이지 않게 진행됩니다. 하지만 검증인, RPC 제공업체, 인덱서, 인프라 팀에게 Agave 4.3은 Solana가 합의에 도달하는 방식이 크게 바뀌기 시작하는 지점입니다.
추가 자료
- Alpenglow 백서 v1.2(2026년 7월)
- Agave 4.3 릴리스 일정
- 기능 게이트 추적 일정
- Agave 4.3 변경 로그
- Agave 4.3 풀 리퀘스트
- Alpenglow 업그레이드 - Solana Foundation
Helius 구독하기
최신 Solana 개발 소식을 확인하고 새 게시물 알림을 받아보세요