Solana Alpenglow: Solana 역사상 가장 큰 합의 알고리즘 개편

현재 Solana 트랜잭션이 완결되기까지는 12.8초가 걸린다. 2026년 10월 21일부터는 메인넷 전체에서 이 시간이 150밀리초로 줄어든다.

이 변화가 Alpenglow다. Solana가 출시된 이후 가장 큰 합의 업그레이드다. Alpenglow는 네트워크가 합의에 도달하는 방식을 처음부터 규정해 온 두 시스템, Proof of History와 Tower BFT를 제거하고, 더 단순하고 훨씬 빠른 설계로 대체한다. 거버넌스에서는 98.27%의 찬성으로 통과되었으며, 10월 21일 13:20 UTC경 시작되는 epoch 1064에서 메인넷에 활성화될 예정이며, Votor는 약 18분 뒤인 슬롯 459,653,000에서 인계받는다.

전환이 일어날 때 무엇을 예상해야 하는지, Alchemy가 어떻게 준비하고 있는지, 그리고 내부에서 실제로 무엇이 달라지는지를 살펴본다. 프로토콜 수준의 원문은 Solana Foundation의 Alpenglow 업그레이드 페이지와 이를 명세한 거버넌스 제안인 SIMD-0326을 참고하길 바란다.

메인넷 전환 시 무엇을 예상해야 하는가

10월 21일 13:20 UTC경에 새로운 epoch(Solana의 약 이틀 단위 스케줄링 구간)가 시작된다. epoch는 항상 길이가 같기 때문에 전환이 일어나는 정확한 슬롯을 이미 알고 있다. 459,653,000이다. 다만 epoch가 시작되는 순간 네트워크가 바로 바뀌는 것은 아니다. 처음 약 18분 동안은 기존 합의 방식인 Tower BFT를 계속 사용하다가, 바로 그 슬롯에서 Alpenglow의 대체 시스템인 Votor로 전환한다. 이는 네트워크가 트랜잭션에 대해 내부적으로 합의하는 방식만 바꿀 뿐, 네트워크와 통신하는 방식은 바꾸지 않는다. 따라서 RPC, WebSocket, gRPC 엔드포인트는 그 전 과정에서 정상적으로 계속 작동할 것으로 예상된다.

전환 자체는 네트워크의 충분한 부분이 준비 완료를 확인하는 동안 약 2개 블록, 대략 400밀리초가 걸릴 것으로 예상된다. 이 짧은 구간 동안 새 블록에는 검증자의 투표만 포함되고 사용자 트랜잭션은 포함되지 않는다. 거부되는 것은 없어야 한다. 그 시점에 전송한 트랜잭션은 전환이 끝난 직후에 반영될 것이다.

팀에 미리 알려 둘 만한 부수 효과가 하나 있다. 활성화 직후에는 공개 대시보드의 트랜잭션 수와 TPS가 낮게 보일 것이다. 이는 사용량이 줄어서가 아니라 검증자 투표가 더 이상 트랜잭션으로 집계되지 않기 때문이다. Alpenglow가 블록 공간의 75%를 확보하는 이유도 같다. 투표가 예전에는 대부분을 차지했지만, 이제는 그렇지 않다.

활성화가 일어난 뒤에는 getAgGenesisCert를 호출해 특정 네트워크가 이미 전환되었는지 확인할 수 있다. 전환 전에는 아무것도 반환하지 않고, 전환 후에는 (정확한 슬롯 같은 세부 정보를 포함한) 결과를 반환한다.

Alchemy는 Alpenglow를 어떻게 준비했는가

Alchemy의 모든 Solana RPC 노드는 활성화에 앞서 이미 Alpenglow 대응 클라이언트를 실행하고 있다. 따라서 RPC, WebSocket, Yellowstone gRPC 엔드포인트에서 고객 측 변경은 필요하지 않다. 또한 당사의 트랜잭션 라우팅은 검증자가 새로운 완결 타이밍에 잠시 뒤처질 때 다른 백엔드로 재시도하는 기능을 이미 갖추고 있다. 오늘날 일반적인 지연 서버를 처리하는 것과 같은 보호 장치다.

Phantom, Solflare, Cielo Finance 등 Solana의 선도적인 팀들이 사용하는 최고 수준의 Solana RPC, 아카이브 데이터, gRPC 스트리밍을 Alchemy로 활용해 보자.

• 평균 읽기 지연시간 9.21ms. 2026년 9월 29일까지의 24시간 동안 측정한 결과 차순위 제공업체보다 약 26% 빠름
• 아카이브 쿼리는 최대 20배, getProgramAccounts 같은 무거운 호출은 10배 빠르며, 대규모 과거 데이터 쿼리에서도 200ms 미만의 응답 시간 (Solflare가 프로덕션에서 검증)
• 99.99% 가동률 SLA와 이전 세대 스택 대비 2배 높은 처리량
• 평균 5-15ms 전달 속도와 48시간 블록 리플레이를 갖춘 Yellowstone 호환 gRPC. 대안 대비 약 5배 저렴

Solana 데이터를 직접 스트리밍하고 있다면, Yellowstone gRPC 클라이언트 버전을 확인하고 마이그레이션 구간 동안 confirmed 데이터만 커밋하고 있는지 점검하기에 좋은 시점이기도 하다. 또한 confirmed와 finalized가 이제 같은 시점에 확정되므로, 입금 크레딧처럼 기존에 finalized를 기다리던 플로우는 더 빠르게 처리할 수 있을 것이다.

무료 Solana RPC 엔드포인트로 시작하기 →

Alpenglow의 모든 것

Votor와 Rotor가 Tower BFT와 Turbine을 대체하는 방식

Alpenglow는 두 가지 새로운 프로토콜로 동작한다. 투표와 완결을 담당하는 Votor와 블록 전파를 담당하는 Rotor다. 이 연구는 ETH 취리히 Wattenhofer 교수의 분산 시스템 연구실에서 나왔으며, Anza가 구현을 주도하고 Jump Crypto의 Firedancer 팀이 멀티 클라이언트 호환성을 작업하고 있다.

완결이 85배 빨라지는 방식

Tower BFT는 32번의 단계적 확인이 필요하며, 각 확인마다 락아웃 기간이 추가된다. Votor는 이를 한두 번의 투표 라운드로 압축한다.

• 빠른 경로(~100ms): 첫 번째 라운드에서 검증자의 80% 이상이 승인하면 완료.
• 느린 경로(~150ms): 첫 번째 라운드에서 60-80%가 승인하면, 두 번째 라운드에서 60% 이상의 임계값으로 확정.

두 경로는 동시에 실행되며, 먼저 끝나는 쪽이 채택된다. 시뮬레이션에서는 스테이크의 65%가 원시 네트워크 지연시간 기준 50ms 이내에 완결된다.

검증자는 투표를 네트워크상의 트랜잭션이 아니라 작은 메시지로 서로에게 직접 전송한다. 그러면 Votor는 BLS 집계라는 서명 결합 기법을 사용해 수천 개의 투표를 약 1,000바이트의 단일 증명으로 압축한다. 기록되는 것은 이 작은 증명 하나뿐이며, 현재 블록마다 기록되는 약 500KB의 투표 데이터를 대체한다.

해당 상태를 직접 인덱싱하거나 쿼리한다면, getProgramAccounts 같은 무거운 호출은 Alpenglow의 타이밍 개선과 무관하게 이미 Alchemy의 Solana API에서 최대 10배 빠르게 실행된다.

Alpenglow가 블록 공간의 75%를 확보하는 방식

현재 Solana 전체 트랜잭션의 약 75%는 검증자 투표다. Alpenglow는 투표를 완전히 오프체인으로 옮기므로, 그 공간이 실제 사용자에게 돌아간다. 사소한 조정이 아니다. 네트워크 용량의 4분의 3이 실제 사용에 환원되어, 수수료는 낮아지고 혼잡한 시기의 정체는 줄어든다.

Alpenglow가 Proof of History를 폐기하는 방식

Alpenglow는 Solana의 원래 암호학적 시계도 버린다. 연속적인 해시 체인 대신, 검증자는 블록이 걸려야 하는 시간에 연동된 단순한 타이머를 사용한다. 블록이 제시간에 도착하면 승인하고, 아무것도 없이 타이머가 만료되면 건너뛴다. 시계 편차는 비례적으로 처리되며, 5% 편차에는 5% 더 긴 타임아웃만 있으면 된다.

각 블록을 생성하는 데 걸리는 시간은 완결과는 별개의 수치이며, 이 역시 바뀌었다. 네 단계에 걸친 단축으로 400ms에서 200ms가 되었으며, Alpenglow 활성화에 앞서 이번 10월에 완료되었다.

완결이 세 단계에서 한 단계로 줄어드는 방식

개발자가 가장 크게 체감할 변화일 것이다. Solana는 현재 트랜잭션이 처리되었는지 확인하는 방법을 세 가지 제공한다. processed(가장 빠르지만 확실성은 가장 낮음), confirmed(~500ms, 되돌려질 가능성이 작게 남아 있음), finalized(~12.8초, 영구성 보장)다. 거래소 입금, 브릿지 확인, 청산처럼 작은 롤백 가능성조차 용납할 수 없는 작업은 finalized를 기다려야 한다. 그 외 모든 것은 confirmed로 만족하며 그 작은 위험을 감수한다.

Alpenglow는 confirmed와 finalized를 하나로 압축한다. 100-150ms이며, 모든 트랜잭션은 확인되는 순간 영구적이 된다. processed는 여전히 가장 이른 단계의 관찰이며 확실성이 가장 낮으므로 확정된 것으로 취급해서는 안 된다. 더 이상 확실성을 위해 속도를 맞바꿀 필요가 없다.

이는 이전에는 작동하지 않던 패턴을 가능하게 한다. 마켓 메이커가 호가가 150ms 안에 확정된다는 것을 알기 때문에 더 좁은 스프레드를 제공하는 오더북. 퍼페추얼 거래소의 더 저렴한 JIT 경매. Solana 측 완결 병목이 없는 크로스체인 브릿지. 13초 대기에서 즉시 처리로 바뀌는 거래소 입금. 그리고 은행과 핀테크에게는 스테이블코인 정산과 국경 간 송금에서 전통적인 결제 레일과 경쟁할 만큼 빠르게 정산되는 트랜잭션이다.

빠르고 결정적인 완결은 가스리스 트랜잭션을 Solana에서 더 깔끔한 경험으로 구축할 수 있게 하기도 한다. 스폰서와 최종 사용자 모두 확인 구간을 기다리는 대신 한 단계에서 최종 답을 얻기 때문이다.

Alpenglow가 검증자 경제성을 바꾸는 방식

검증자당 하루 약 1 SOL이던 투표 수수료는 사라진다. 그 대신 하루 약 0.8 SOL의 Validator Admission Ticket이 도입되며 전액 소각된다. 네트워크는 최대 2,000개의 검증자로 제한되며, 스테이크가 높은 순으로 선정된다. 최소 수익성 스테이크는 약 4,850 SOL에서 약 450 SOL로 낮아져 검증자를 운영하기 위한 진입 장벽이 약 90% 낮아지고, 전체 운영 비용은 20-50% 감소한다. 아이덴티티 키도 더 이상 투표에 계속 서명하지 않으므로 하드웨어 보안 모듈로 옮길 수 있다.

Alpenglow가 속도를 위해 보안을 맞바꾸는 방식

Alpenglow는 "20+20" 보안 모델을 사용한다. 단독으로는 명백히 악의적인 검증자에 대한 내성이 이전보다 낮아, 네트워크의 33%가 아니라 20%다. 하지만 오프라인이거나 응답하지 않는 검증자와 결합하면, 어떤 형태로든 실패하는 네트워크의 최대 40%까지 견딜 수 있다. 기존 33% 한계보다 높다. 현실의 장애는 대개 악의적인 검증자와 단순히 오프라인인 검증자가 섞여 있으므로, 이 결합 수치가 더 현실적인 척도다.

두 승인 임계값(80%와 60%)의 합이 네트워크의 100%를 넘기 때문에, 서로 충돌하는 두 개의 역사가 모두 승인될 수 없다는 수학적 보장은 그대로 유지된다.

Alpenglow 롤아웃이 여기까지 온 과정

Alpenglow는 2025년 5월 Solana Accelerate에서 공개되었고, 그해 9월 거버넌스를 통과했으며(SIMD-0326), 프라이빗 클러스터 테스트와 Agave 4.1 릴리즈를 거쳐 2026년 9월 devnet에 도달했고, 올해 10월 21일 epoch 1064에서 메인넷에 활성화될 예정이다. 원래 백서의 일부 요소인 스마트 샘플링, 비동기 실행, Rotor의 추가 개선은 향후 제안으로 남겨져 있다.

최종 결과는 운영 중인 네트워크에서의 합의 전면 교체, 200ms 이내에 영구적이 되는 트랜잭션, 블록 공간 75%의 확보, 그리고 검증자 운영 진입 장벽의 90% 하락이다.

FAQ

Alpenglow는 Solana 메인넷에서 언제 활성화되는가?

epoch 1064, 2026년 10월 21일 13:20 UTC경이다. Votor는 epoch 시작 약 18분 후인 슬롯 459,653,000에서 인계받을 예정이다.

Alpenglow로 인해 다운타임이 발생하는가?

다운타임은 예상되지 않는다. RPC, WebSocket, gRPC 트래픽은 전 과정에서 정상적으로 작동해야 한다. 전환 순간에 새로운 사용자 트랜잭션이 약 400ms 동안 잠시 멈출 것으로 예상되지만, 그때 전송된 것은 유실되지 않고 전환이 끝나면 반영될 것이다.

Alpenglow 이후에도 confirmed는 별도의 확정 수준으로 남는가?

아니다. confirmed와 finalized는 이제 모두 약 150ms의 같은 시점에 확정되며, 기존의 3단계 모델을 대체한다.

네트워크가 Alpenglow로 전환되었는지 어떻게 확인하는가?

getAgGenesisCert(Agave v4.3+)를 호출한다. 네트워크가 아직 Tower BFT라면 아무것도 반환하지 않고, Alpenglow로 동작 중이면 결과를 반환한다.

Alpenglow를 위해 Alchemy Solana 연동을 변경해야 하는가?

아니다. RPC, WebSocket, Yellowstone gRPC 엔드포인트에는 어떤 변경도 필요하지 않다. Alchemy의 Solana 노드는 이미 Alpenglow 대응 클라이언트를 실행하고 있다.