Alpenglow: Solana의 대대적인 합의 재설계

실행 가능한 인사이트 

• Alpenglow이 Solana에 제공하는 가장 큰 이점은 트랜잭션 최종 확정 시간을 100배 단축한다는 점입니다. 검증인의 지리적 위치에 따라 12.8초에서 100~150ms로 줄어듭니다. 이에 따라 Solana는 더 중앙화된 Web2 인프라와 경쟁하고 실시간 애플리케이션을 지원할 수 있습니다.
• Alpenglow은 Proof of History, Tower BFT, 가십 기반 투표 전파를 비롯한 Solana의 여러 레거시 구성 요소를 제거해 합의를 단순화합니다. Proof of History 대신 400ms의 고정 블록 시간을 도입해 네트워크 전반의 타이밍을 조율합니다. 이는 전역적으로 동기화된 시계를 사용하는 것과는 다릅니다.
• 프로토콜은 두 가지 핵심 구성 요소를 중심으로 설계됩니다. Rotor는 Solana의 기존 Turbine 아키텍처를 확장하고 개선한 블록 전파 프로토콜입니다. Votor는 Tower BFT, Proof of History, 투표 전파를 위한 가십 사용을 대체하는 새로운 투표 메커니즘입니다.
• 모든 합의 활동이 오프체인으로 이동합니다. 투표 인증서는 계속 온체인에 앵커링되지만, 슬롯별 투표 트랜잭션은 경량 BLS 인증서 시스템으로 대체됩니다. 이 변화로 현재와 같은 투표 수수료가 사라집니다. 투표 수수료는 지금까지 검증인의 주요 운영 비용이었으므로 소규모 운영자의 검증인 경제성이 크게 개선됩니다. 정확한 경제 모델은 아직 확정 중입니다.
• Alpenglow은 “20+20” 복원력 모델을 제공합니다. 지분의 최대 20%를 적대적 주체가 통제해도 안전성을 유지하며, 이와 별개로 추가 20%의 지분이 오프라인이거나 응답하지 않아도 활성성을 유지합니다. 따라서 적대적이고 불안정한 네트워크 조건을 모두 견딜 수 있습니다.
• Votor는 합의를 위해 2단계 동시 투표 시스템을 사용합니다. Fast-Finalization 경로에서는 첫 라운드에 블록이 지분 ≥80%의 승인을 받으면 Fast-Finalization Certificate와 함께 즉시 최종 확정됩니다. Slow-Finalization 경로에서는 블록이 지분 ≥60%의 승인을 받는 즉시 두 번째 라운드가 시작됩니다. 이 라운드에서 승인율이 ≥60%에 도달하면 Finalized Certificate와 함께 블록이 최종 확정됩니다.
• 팬아웃 200의 다계층 트리 구조에 의존하는 Turbine과 달리 Rotor는 릴레이 노드가 샤드 배포를 담당하는 싱글 홉 모델을 사용합니다. 각 샤드는 단일 소거 코딩 패킷으로 전송되며, Rotor 설계는 DoubleZero 같은 멀티캐스트 시스템과 기본적으로 호환됩니다. Rotor는 Votor와 별도의 SIMD가 될 가능성이 높습니다.
• 현재 Alpenglow은 내년 초까지 Solana 메인넷에 배포될 것으로 예상됩니다. 프로토콜의 참조 구현은 Github에서 확인할 수 있습니다.

소개

Alpenglow 합의 알고리즘은 지금까지 이루어진 Solana 핵심 프로토콜의 가장 중대한 개편입니다. 최신 블록체인 연구 성과를 바탕으로 네트워크 전체에서 합의를 달성하는 방식을 근본적으로 재설계합니다.

Alpenglow은 세계 최상위 컴퓨터 과학 기관 중 하나인 ETH Zurich의 Roger Wattenhofer 교수가 이끄는 Anza의 새로운 연구 부문이 개발했습니다. 분산 시스템 분야의 권위자인 Wattenhofer 교수는 Solana의 현재 합의 프로토콜에서 발생할 수 있는 활성성 취약점을 밝힌 2024년 논문 Halting the Solana Blockchain with Epsilon Stake를 공동 집필했습니다. 그의 제자였던 Kobi Sliwinski와 Quentin Kniep도 Anza에서 함께하고 있습니다.

팀의 과제는 Turbine 기반 아키텍처를 유지하면서 Solana의 합의 알고리즘을 더 높은 성능과 증명 가능한 정확성을 갖추도록 재설계하는 것이었습니다. Alpenglow은 특히 적대적 네트워크 동작을 처리하는 분야에서 최신 분산 시스템 연구 성과를 다수 반영합니다.

Alpenglow이라는 이름은 “알프스의 빛”을 뜻하는 독일어 Alpenglühen에서 유래했습니다. 일출이나 일몰 때 산봉우리에 비치는 인상적인 빛을 가리키며, 프로토콜의 스위스 기원에 대한 오마주입니다.

Alpenglow의 이점은 무엇인가요?

Alpenglow이 제공할 것으로 예상되는 핵심 이점을 간략히 정리했습니다. 각 항목은 글의 나머지 부분에서 더 자세히 살펴봅니다.

더 빠른 최종 확정

Alpenglow이 Solana에 제공하는 가장 큰 이점은 트랜잭션 최종 확정 시간, 즉 사용자 트랜잭션이 블록체인 네트워크에 루팅되는 시간을 100배 단축한다는 점입니다. 검증인의 지리적 위치에 따라 12.8초에서 100~150ms로 줄어듭니다. 이에 따라 Solana는 더 중앙화된 Web2 인프라와 경쟁하고 실시간 애플리케이션을 지원할 수 있습니다.

• 현재 Solana 최종 확정: 12.8초 
• 현재 Solana 낙관적 확인: 500~600밀리초
• Alpenglow 최종 확정: 150밀리초(중앙값)*
• 경쟁 프로토콜의 가장 빠른 최종 확정: 400밀리초(자체 보고)

*지리적 위치와 클러스터 분포에 따라 달라집니다.

투표 트랜잭션 제거

Alpenglow에서는 모든 합의 활동이 오프체인에서 이루어집니다. 이에 따라 더 이상 투표 트랜잭션을 처리할 필요가 없는 트랜잭션 처리 장치(TPU)와 리플레이의 부하가 줄어듭니다.

Alpenglow은 소규모 검증인의 경제성도 크게 개선합니다. 투표 트랜잭션 수수료는 검증인의 가장 큰 운영 비용입니다. 오프체인 투표로 이 수수료를 없애면 참여 비용이 대폭 줄어듭니다. 소규모 검증인이 더 쉽게 운영할 수 있고 네트워크 보안 기여에 필요한 진입 장벽도 낮아집니다.

투표 트랜잭션이 더 이상 블록 공간을 차지하거나 원장 크기를 늘리지 않으므로 커밋 로직이 단순해지고 원장 증가 속도가 느려지는 추가 이점도 있습니다.

이 변화는 Solana의 초당 트랜잭션(TPS) 지표를 둘러싼 모호함도 없앱니다. 현재 TPS는 투표 트랜잭션을 포함하는 전체 TPS와 비투표 트랜잭션만 집계하는 실제 TPS라는 두 가지 방식으로 보고되곤 합니다.

더 간결해진 프로토콜

Alpenglow은 Proof of History, Tower BFT, 투표 전파를 위한 가십 사용 등 Solana의 여러 레거시 구성 요소를 제거해 합의 도달 과정을 간소화합니다. 최신 블록체인 연구의 첨단 기술을 반영하면서도 불필요한 복잡성을 추가하지 않습니다.

Alpenglow의 Votor와 Rotor는 비동기 실행, 다중 동시 리더(MCL) 같은 향후 업그레이드의 기반을 마련합니다. 이를 통해 Solana는 추가 성능 향상과 프로토콜 발전에 유리한 위치를 확보합니다.

Solana의 현재 합의 메커니즘은 무엇인가요?

Proof of History

Proof of History (PoH)는 합의 알고리즘이 아닙니다. 합의 달성을 돕는 도구입니다. 혼동은 아마도 명칭에서 비롯됩니다. Proof of Work와 Proof of Stake에 익숙한 사람에게 “Proof of X”는 해당 대상이 합의 알고리즘이라는 인상을 줍니다. PoH는 효율적인 트랜잭션 처리로 합의를 간소화하는 “사전 합의” 알고리즘으로 이해하는 편이 더 유용합니다.

개괄적으로 PoH는 적대적 네트워크에서 시간을 증명하는 탈중앙화 시계입니다. 더 엄밀히 말하면, 노드가 서로 통신하지 않고도 이벤트 순서에 합의할 수 있게 하는 암호학적 타임스탬프 함수입니다. 순차적이고 역상 저항성을 갖춘 해시 함수를 사용해 해시 체인을 만듭니다. 리더는 이 해시를 사용해 블록에 타임스탬프를 적용하고 일정 시간이 지났음을 증명합니다. 모든 해시가 연결되므로 PoH는 특정 시점에 데이터가 존재했음을 증명하는 이력 기록을 제공합니다. 

이 방식은 합의 과정에서 블록 순서를 정한 뒤 타임스탬프를 추가하는 다른 체인과 다릅니다. Solana에서는 먼저 암호학적으로 검증 가능한 시계를 만들고, 그 시계에 맞춰 트랜잭션을 스트리밍한 다음, 합의를 통해 미리 정렬된 트랜잭션 로그를 검증합니다. 해시 체인 덕분에 시간 순서에는 논쟁의 여지가 없습니다. 

Tower BFT

Tower BFT는 샤드, 즉 부분 블록이 다른 검증인에게 전파되고 네트워크가 이를 리플레이한 후 해당 블록이 원장의 일부가 될지 결정합니다. 개념적으로 Proof of History의 네트워크 전체 시계를 활용하도록 설계된 pBFT 계열 합의 알고리즘입니다. 각 슬롯마다 동기식 합의 라운드를 진행하는 대신 검증인은 이미 관찰한 Proof of History 시퀀스를 바탕으로 향후 슬롯에 사전 커밋하여 지속적인 블록 생성을 지원합니다.

검증인은 투표 계정으로 서명한 투표 트랜잭션을 슬롯마다 하나씩 제출합니다. 특정 포크에 대한 투표에는 해당 포크의 락아웃, 즉 타임아웃이 적용됩니다. 락아웃은 검증인이 다른 포크에 투표할 수 없는 지정된 슬롯 기간입니다. 검증인이 하나의 포크에 커밋하도록 강제하고 포크를 전환하려 할 때 락아웃을 기하급수적으로 늘리는 것이 목적입니다. 각 투표에는 검증인이 하위 슬롯에 투표할 때마다 두 배가 되는 락아웃 카운터가 포함되어 커밋의 “투표 타워”를 만듭니다. 따라서 검증인이 블록 X에 투표하면 기하급수적으로 늘어나는 향후 슬롯 수(예: 1, 2, 4, 8…) 동안 충돌하는 포크에 투표할 수 없습니다. 락아웃 위반은 증명하고 처벌할 수 있지만 슬래싱은 아직 메인넷에 적용되지 않았습니다.

Solana는 Tower BFT에서 두 단계의 최종 확정성을 달성합니다. 낙관적 확인과 결정론적 최종 확정입니다. 

새 블록이 생성되고 지분의 ≥66%가 투표하면 해당 블록은 선도 포크, 즉 정규 포크의 일부로 인정됩니다. 이를 낙관적 확인이라고 합니다. 압도적 다수가 투표하는 즉시 블록에 “confirmed” 커밋 수준이 표시되기 때문입니다. 낙관적 확인은 공식 최종 확정 전에 블록을 최종 확정된 것으로 취급해 UX를 개선하고자 Solana Labs(현재 Agave) 클라이언트 v1.3에서 도입됐습니다.

Solana의 제네시스 블록 이후 낙관적으로 확인된 블록이 롤백된 적은 한 번도 없습니다. 롤백하려면 66%가 이미 정직하게 투표한 뒤 전체 지분의 최소 3분의 1이 충돌하는 포크를 공개해야 합니다. 같은 의미로 블록의 낙관적 확인 비율이 지분의 ~87%에 도달하면 공격자는 같은 지분 중 ≥20%로 이중 서명해야 하며, 이는 명백히 슬래싱할 수 있는 행위입니다. 엄격한 합의 이론의 관점에서 절대적인 최종 확정은 아니지만 낙관적 확인은 실무에서 강력한 보장을 제공합니다. 거의 모든 사용 사례에서 이 블록을 최종 확정된 것으로 취급할 수 있습니다. 그래서 실용적인 관점에서 Solana의 최종 확정 시간은 일반적으로 500~600밀리초로 알려져 있습니다.

진정한 결정론적 최종 확정을 위해서는 블록이 투표 타워에서 최대 락아웃을 달성해야 하며, 이는 32개의 누적 투표로 확인하는 것과 같습니다. 즉, 블록이 “finalized” 상태가 되거나 네트워크에 루팅되려면 그 위에 블록 32개가 더 구축되어야 합니다. 32개 슬롯 요건과 ~0.4초의 슬롯 시간을 고려하면 결정론적 최종 확정까지 ~12.8초가 걸립니다. 락아웃 투표 깊이가 롤백을 불가능하게 만들면 결정론적 최종 확정이 달성됩니다.

Solana의 현재 합의 메커니즘에는 어떤 한계가 있나요?

Proof of History와 Tower BFT는 Solana가 높은 처리량과 빠른 낙관적 확인을 달성하는 데 기여했습니다. 하지만 이 설계는 비용, 지연 시간, 활성성, 검증인 운영 측면에서 여러 한계가 있습니다.

높은 투표 오버헤드와 비용

모든 검증인은 합의에 기여하기 위해 각 슬롯에 계속 투표해야 합니다. 투표는 투표 프로그램과 상호작용하고 네트워크 리소스를 소비하며 수수료를 지불하는 트랜잭션입니다. 

Solana 트랜잭션 중 약 4분의 3이 투표 트랜잭션입니다. 이는 상당한 네트워크 오버헤드를 차지하고 슬롯마다 검증인에게 실제 비용을 발생시킵니다. 끊임없는 투표에 불필요하게 의존하면 처리되는 슬롯 수와 클러스터의 검증인 수에 비례해 증가하는 높은 오버헤드와 비용이 발생합니다. 

최종 확정 지연 시간

낙관적 확인은 빠르지만 결정론적 최종 확정은 그렇지 않습니다. 최종 확정 시간이 ~500ms인 Sui의 Mysticeti 같은 최신 합의 프로토콜과 비교하면 ~12.8초는 느립니다. 이는 운영에 절대적인 확실성이 필요한 거래소 같은 애플리케이션에 문제를 일으킵니다. 실제로 사용자는 확인된 블록을 신뢰합니다. 하지만 네트워크는 최종 확정 전에 발생할 수 있는 소규모 재구성에 대비해 긴 포크 이력을 계속 유지해야 합니다. 

낙관적 확인과 결정론적 최종 확정 지연 시간의 격차는 트레이드오프입니다. Tower BFT는 최종 확정 속도를 희생하고 짧은 포크 대응 기간을 두어 활성성을 우선합니다. 공격이나 합의 버그가 전혀 없어도 ~12.8초의 최종 확정 시간은 빠른 최종 확정 체인과 기존 Web2 인프라에 비해 크게 뒤처집니다.

활성성과 네트워크 파티션 허용성

Tower BFT에서 새 블록을 확인하고 최종 확정하려면 검증인의 압도적 다수가 온라인 상태로 응답해야 합니다. 지분의 3분의 1 이상이 오프라인이거나 네트워크가 심각하게 분할되면 합의가 멈출 수 있습니다. Solana는 활성성을 우선해 계속 블록을 생성할 수 있지만, 네트워크가 블록의 낙관적 확인에 필요한 투표 임계값에 도달하지 못할 수 있습니다. 최악의 경우 최근 Solana 중단 사태처럼 검증인이 투표를 기다리다 멈추거나 낙관적 포크를 처리하지 못해 네트워크가 중단되고 조율된 재시작이 필요할 수 있습니다.

이는 BFT 합의의 고전적인 한계입니다. Solana에는 대규모 검증인 집단이 일시적으로 응답하지 않는 상황을 허용하는 내장 장치가 없습니다. 따라서 극단적인 조건에서 합의를 위한 압도적 다수 임계값 아래로 떨어지는 상황을 프로토콜이 원활히 처리하지 못해 Solana의 활성성이 저하됐습니다. 온라인 지분이 60% 미만이어도 Tower BFT는 블록을 계속 생성해야 했습니다. 따라서 해당 블록은 낙관적 확인에 도달할 수 없고 롤백될 수 있습니다.

검증인 운영의 복잡성

Tower BFT는 검증인에게 많은 것을 요구합니다. 지속적인 투표 트랜잭션, 견고한 네트워킹, 클라이언트 업그레이드, 미이행 방지, “타워 상태” 유지가 필요합니다. 검증인이 재시작하거나 최신 타워 상태를 잃으면 이전 락아웃 커밋을 위반하는 투표를 제출해 투표 크레딧을 잃을 위험이 있습니다.

프로토콜이 Proof of History의 지속적인 해싱과 투표의 가십 전파에 의존하므로 검증인은 Solana의 ~400ms 슬롯 시간을 따라잡기 위해 많은 작업을 해야 합니다. 시간이 지나며 낮아지고 있지만 Solana의 높은 하드웨어 요구 사항도 만만치 않습니다. 또한 모든 검증인은 지분과 관계없이 보상을 극대화하기 위해 모든 슬롯에 투표해야 합니다. 따라서 소규모 검증인은 대부분의 경우 대규모 검증인과 같은 수수료를 내고 같은 작업량을 처리합니다. 리더 슬롯은 지분에 비례해 할당되므로 지분이 많은 검증인은 더 많은 블록을 생성하고 다른 검증인이 낸 투표 수수료를 더 많이 받습니다. 이에 따라 투표 수수료가 사실상 더 많은 지분을 보유한 검증인에게 자본을 재분배하는 순환적 가치 흐름이 만들어집니다.

또한 Solana의 현재 합의 메커니즘에서는 클라이언트가 같은 슬롯의 여러 후보를 관리해야 하므로 중복 블록 리플레이가 매우 복잡합니다. Votor의 인증서 시스템은 각 슬롯이 단일 해시 또는 명시적 건너뛰기 중 하나를 커밋하도록 보장해 중복 블록 리플레이를 간단하게 만듭니다.

Tower BFT의 설계는 혁신적이지만 검증인 운영을 상당히 복잡하게 만든다는 점이 분명해집니다.

Alpenglow은 어떻게 작동하나요?

Alpenglow은 두 가지 핵심 구성 요소를 중심으로 구축됩니다.

• Rotor: 기존 Turbine 아키텍처를 기반으로 이를 개선한 업그레이드된 블록 전파 프로토콜입니다.
• Votor: 합의 참여를 위해 Tower BFT, 가십 기반 투표 전파, Proof of History를 대체하는 새로운 투표 프로토콜입니다.

다음 섹션에서는 이러한 구성 요소를 자세히 살펴봅니다.

Rotor: 새로운 데이터 배포 계층

Rotor는 Solana의 기존 Turbine 설계를 기반으로 효율성과 단순성을 크게 개선한 블록 전파 프로토콜입니다. 팬아웃 200의 다계층 트리 구조를 사용하는 Turbine과 달리 Rotor는 싱글 홉 모델(2δ)을 사용합니다. 

블록은 슬라이스로 분할되고, 각 슬라이스는 Reed-Solomon 소거 코드를 사용해 여러 샤드로 인코딩됩니다. 샤드의 진위를 보장하기 위해 리더는 샤드 해시로 Merkle 트리를 만들고 루트에 서명합니다. 각 샤드에는 이 트리에서의 경로와 리더의 서명이 포함됩니다.

각 샤드는 릴레이 노드로 직접 전송됩니다. 그런 다음 릴레이는 다음 리더를 우선으로 하여 샤드를 네트워크의 모든 노드에 브로드캐스트합니다. 이 단일 계층 방식은 지연 시간을 줄이고 전파 경로를 단순화합니다. 속도도 놀라울 정도로 빠릅니다.

리더와 샤드 릴레이는 모두 지분 가중 샘플링으로 선택됩니다. 즉, 각 노드는 자신의 지분에 비례해 데이터를 전송합니다. 소거 코딩 덕분에 노드는 일부 샤드만 받아도 원본 블록 슬라이스를 재구성할 수 있습니다.

Turbine과의 중요한 차이점은 Rotor가 각 샤드의 소거 코딩 버전을 하나만 전송한다는 것입니다. Turbine처럼 데이터 샤드와 복구 샤드를 별도로 보낼 필요가 없습니다. 중복성, 즉 데이터 확장 비율은 동일하게 유지되지만 이 설계는 데이터 샤드 전달과 관련된 비정상적인 전략을 없애고 프로토콜 설계를 단순화합니다.

Rotor 아키텍처는 DoubleZero 같은 멀티캐스트 시스템과도 호환되어 블록 전송 방식을 유연하게 선택할 수 있습니다. 블록 전파에는 상당한 대역폭이 사용되므로(현재 대형 검증인의 초당 아웃바운드 패킷은 150,000개에 육박합니다) Rotor는 데이터 배포에 대해 릴레이가 보상받는 모델을 도입합니다. 이를 통해 네트워크 성능 지원에 대한 인센티브를 조정합니다.

Alpenglow 백서는 보상을 계산하거나 배분하는 구체적인 메커니즘을 정의하지 않습니다. 다만 Rotor 보상에는 사용된 대역폭이 반영되어야 하며, 더 많은 데이터를 릴레이한 노드가 더 많은 보상을 받을 것으로 예상된다고 설명합니다.

Blokstor란 무엇인가요?

Blokstor는 노드가 Rotor에서 받은 블록 데이터를 저장하고 관리하는 곳입니다. 더 엄밀히 말하면 Blokstor는 슬라이스 저장을 관리하는 데이터 구조입니다. 샤드를 받으면 다음을 포함한 특정 조건이 충족될 때 해당 콘텐츠가 Blokstor에 추가됩니다.

• Blokstor에 해당 인덱스의 샤드가 아직 없음
• 유효한 리더 서명
• 유효한 Merkle 트리 경로

Blokstor는 slot(b)의 첫 번째 완전한 블록 b를 받으면 "Block(slot(b), hash(b) hash(parent(b)))" 이벤트를 내보냅니다. 또한 복구 절차를 수행해 같은 슬롯의 대체 블록을 수집하고 저장할 수 있습니다. 블록이 최종 확정되면 Blokstor는 해당 슬롯에 그 블록만 저장해야 합니다.

Votor: 새로운 투표 및 최종 확정 엔진

Votor는 블록의 공증과 최종 확정을 위해 Tower BFT를 대체하는 Aplenglow의 새로운 투표 및 최종 확정 엔진입니다. 효율성과 단순성을 높이기 위해 Simplex 연구에서 영감을 얻고 이를 Proof of Stake 맥락에 적용합니다. 

Simplex는 네트워크 지연의 상한이 엄격하게 정해져 있다면 순환 리더 Proof of Stake 환경에서 매우 작은 메시지만으로도 효율적인 비잔틴 합의에 도달할 수 있음을 보여줍니다. Votor는 이러한 인사이트를 바탕으로 한두 번의 라운드 안에 합의를 달성합니다.

개괄적으로 Votor는 모든 슬롯에 대해 슬롯을 건너뛰었음을 나타내는 건너뛰기 인증서 또는 공증된 블록의 정규 체인 위에 구축된 공증 블록이 존재하도록 보장합니다. 블록이 공증되려면 유효한 인증서가 있어야 합니다. 검증인은 투표를 가십에 대량 전파하는 대신 기존 Solana 가십이 아닌 일종의 “직접 전송” 메시 형태로 지분 가중 피어 집합에 경량 투표 메시지를 브로드캐스트합니다. 정족수에 도달하면 어떤 노드든 Boneh–Lynn–Shacham(BLS) 서명 체계를 사용해 이 서명을 인증서로 집계할 수 있습니다. 온체인에 앵커링되는 것은 집계된 인증서 헤더이므로 슬롯별 투표 트랜잭션이 필요하지 않습니다.

Votor의 투표 메커니즘은 어떻게 작동하나요?

Votor는 두 가지 투표 경로로 구분되는 단계별 동시 투표 메커니즘을 사용합니다.

• Fast-Finalization: 제안된 블록이 첫 번째 투표 라운드에서 지분 ≥80%의 승인을 받으면 블록이 즉시 최종 확정되고 Fast-Finalization Certificate가 생성됩니다. 지분의 80%는 압도적 다수 임계값을 크게 웃돌기 때문에 두 번째 투표 라운드 없이도 한 번의 라운드로 최종 확정할 수 있습니다.
• Slow-Finalization: 첫 번째 투표 라운드에서 승인한 지분이 <80%이지만 ≥60%이면 Votor가 즉시 두 번째 투표 라운드를 시작합니다. 두 번째 라운드에서 승인한 지분이 ≥60%에 도달하면 Finalized Certificate가 생성됩니다.

두 경로는 동시에 실행되며 임계값을 먼저 충족한 경로가 블록을 최종 확정합니다. 리더는 부모 블록 수신을 마치는 즉시 투표가 계속 집계되는 동안 다음 블록 전송을 시작할 수 있습니다. 따라서 기존 Solana 합의처럼 ~400ms마다 블록 하나가 생성됩니다. 첫 번째 라운드에서 지분 ≥80%의 승인을 받지 못하면 Votor는 두 번째 투표 라운드로 전환됩니다. 지분이 겹치므로 충돌하는 두 블록이 모두 최종 확정되는 것도 방지합니다.

Votor의 Pool 데이터 구조란 무엇인가요?

Pool은 모든 노드가 유지하는 데이터 구조로, 투표 활동과 인증서 생성의 로컬 원장 역할을 합니다. 각 슬롯과 노드에 대해 받은 투표를 메모이제이션합니다. 충분한 투표를 받으면 해당 인증서가 생성됩니다. 새로 받거나 직접 만든 인증서가 Pool에 추가되면 다른 모든 노드에 브로드캐스트됩니다. 

여러 검증인이 거의 동시에 인증서를 만들 수 있지만 정족수 임계값을 충족하는 모든 인증서는 서명 집합에 어떤 검증인이 포함되었는지와 관계없이 합의에서 기능적으로 동일합니다. 최대 3개의 서로 다른 인증이 전파되어야 할 수 있는 Finalized Certificate만 예외입니다. 특정 슬롯에서 모든 유형을 통틀어 고유한 인증서는 4개를 넘지 않으며, 각 고유 인증서는 한 번만 브로드캐스트됩니다. 이 방식은 투표 스팸을 방지하면서도 Pool에 정족수가 확인되는 즉시 정직한 노드가 인증서를 만들고 공유할 수 있게 합니다.

핵심 요약

투표는 단일 UDP 패킷으로 모든 검증인에게 스트리밍되며, 검증인은 각 슬롯과 노드에 대해 받은 투표를 메모이제이션합니다. Votor에서 특정 블록의 공증과 최종 확정은 다음 세 가지 조건으로 결정됩니다.

• 첫 번째 투표 라운드에서 지분 ≥80%의 승인.
• 첫 번째와 두 번째 투표 라운드에서 지분 ≥60%의 승인.
• 검증인이 다른 검증인으로부터 블록이 최종 확정되었다는 유효한 인증서를 수신.

Proof of History 제거

Rotor는 블록 데이터를 한 번의 홉으로 전파하고 Votor의 목표 지연 시간 상한은 ~150ms이므로(다음 섹션에서 더 자세히 다룹니다) Solana에는 더 이상 탈중앙화 시계가 필요하지 않습니다. 단순한 로컬 시계만으로 충분합니다. Alpenglow은 Proof of History를 로컬 타임아웃 타이머로 대체합니다.

Votor의 타임아웃 메커니즘은 어떻게 작동하나요?

실제로 타임아웃 시스템은 다음과 같이 작동합니다.

• 리더 기간: 리더는 슬롯당 Δblock ≈ 400ms인 4개 슬롯 기간을 담당합니다.
• 데이터 도착 또는 타임아웃: 리더의 부모 블록이 공증되는 순간 각 검증인은 타임아웃을 호출하고 슬롯마다 하나씩 총 4개의 기한을 t = now + Δtimeout + slotIndex * Δblock으로 미리 설정합니다. 여기서 Δblock ≈ 400ms입니다. 이 타이머는 절대 재설정되지 않으며 상한 역할을 합니다. 블록의 샤드가 제시간에 도착하면 NotarVote 메시지로 해당 슬롯에 투표하며 대기 중인 타임아웃은 아무 작업도 하지 않습니다. 반대로 샤드가 도착하기 전에 시간이 만료되면 검증인은 리더가 부정직하거나 의무를 이행하지 않았다고 판단하고 SkipVote를 제출합니다.
• 인증: 앞에서 설명한 것처럼 공증된 블록에는 Fast-Finalization 또는 Finalized Certificate가 생성됩니다. 건너뛴 슬롯에는 Skip Certificate도 생성될 수 있습니다.

Alpenglow은 모든 검증인이 로컬에서 독립적으로 타임아웃을 측정하는 시스템을 도입합니다. 따라서 Solana에는 Proof of History와 같은 단일 해시 기반 시계가 필요하지 않습니다. 메시지가 단일 UDP 패킷이고 Rotor가 싱글 홉이므로 해싱 없이도 400ms 상한을 현실적으로 달성할 수 있습니다. 검증인은 더 이상 해시를 계속 계산할 필요가 없고 락아웃 없이 블록에 반대 투표할 수 있습니다. Firedancer 같은 대체 클라이언트도 Agave 클라이언트의 Proof of History 구현을 복제하지 않아도 됩니다.

슬롯 건너뛰기

검증인은 SkipVote 메시지를 보내 슬롯을 건너뛸 수도 있습니다. 지분 ≥60%가 SkipVote 메시지를 제출하면 Skip Certificate가 생성되고 해당 슬롯을 공식적으로 건너뜁니다. 건너뛰기 투표는 공증 투표와 동일한 보상 가중치를 가지므로 리더가 잘못 행동할 때 검증인이 침묵할 유인이 없습니다. Alpenglow 경제 모델이 확정되면 이 방식은 변경될 수 있습니다.

검증인은 특정 슬롯의 블록을 최종 확정할 수 없다고 판단할 때마다 해당 슬롯에 SkipVote를 보냅니다. 타임아웃 도달, 블록 누락, 유효하지 않거나 잘못된 형식의 블록 생성 등이 원인일 수 있습니다. 리더의 4개 슬롯 기간 중 첫 번째 슬롯에서 이 조건 중 하나라도 발생하면 검증인은 전체 기간을 잘못된 것으로 표시합니다. 그런 다음 기간 내 나머지 슬롯을 순회하며 아직 투표하지 않은 모든 슬롯에 SkipVote를 제출합니다. 따라서 4개 슬롯 기간 전체를 한 번의 건너뛰기 라운드로 처리할 수 있습니다. 각 투표는 여전히 슬롯 하나에 적용되지만 대부분의 검증인이 같은 투표를 한꺼번에 보내므로 대기 중인 세 슬롯 모두 거의 동시에 60% 임계값에 도달합니다. 오프라인 리더의 타임아웃을 기다리며 클러스터가 빈 슬롯 세 개 동안 유휴 상태에 머무는 것을 방지하기 위한 설계입니다.

물론 블록 생성에는 공백이 생깁니다. 하지만 빠른 건너뛰기 인증서 덕분에 슬롯 주기는 중단 없이 계속됩니다. 건너뛰기 인증서가 해당 슬롯의 정규 “널 블록” 역할을 하고 모든 정직한 노드가 건너뛰기를 결과로 채택하므로 포크 선택이 단순해지고 일관성이 향상됩니다. 따라서 경쟁 포크가 없고 건너뛰기로 영구적인 포크가 발생하지 않으며 정상적인 블록 생성 주기를 유지할 수 있습니다.

검증인 보상

Votor의 검증인 보상은 투표와 인증서 생성 참여를 기준으로 합니다. 블록에 찬성(NotarVote)하거나 반대(SkipVote)하는 투표를 제출해 합의에 기여한 노드는 동일한 보상을 받습니다. 이는 정직한 참여를 유도하고 노드가 다수의 선택을 예측하거나 이에 맞추려 하지 않고 자신의 상태를 기준으로 투표하게 합니다.

현재 정확한 보상 구현 방식은 명시되지 않았습니다.

Alpenglow 성능 벤치마크 및 시뮬레이션 결과

Anza의 시뮬레이션에 따르면 Alpenglow는 Fast-Finalization 또는 Fallback(즉, slow-finalization) 경로 중 어느 쪽에서 블록을 공증하는지에 따라 약 100~150ms 안에 블록을 최종 확정합니다. Fast-Finalization 경로의 지연 시간 목표는 ~100ms이며, Slow-Finalization 경로의 목표는 ~150ms입니다.

지연 시간 히스토그램

네트워크 지연 시간은 모든 분산 시스템의 통신에서 근본적인 하한선을 결정합니다. 예를 들어 리더가 뉴욕에 있고 스테이크의 과반수가 유럽에 있다면, 한 노드가 다른 네트워크 노드로 정보를 전송하는 단방향 지연 시간의 중앙값은 약 200밀리초에 이를 수 있습니다. 지리적으로 가까운 노드(예: 같은 데이터 센터나 리전에 있는 노드)는 지연 시간이 더 짧고, 남반구나 그 밖의 먼 지역에 있는 노드는 훨씬 더 깁니다.

• 네트워크: 인터넷을 통해 1비트를 다른 노드로 전송하는 네트워크 지연 시간입니다
• Rotor: 이 하한선과 비교해 Rotor가 얼마나 느린지를 나타냅니다
• 공증: 스테이크 60%로부터 공증된 투표를 받는 데 걸리는 시간입니다(한 차례 더 투표할 수도 있으며, 투표를 받으면 최종 확정을 시작할 수 있음)
• 최종성: 최종 확정 시간입니다

Alpenglow의 전체 최종성은 하한선의 2배입니다. 즉, 합의 오버헤드는 원시 네트워크 하한선에 2배의 배수를 적용합니다. 따라서 리더와 압도적 다수의 스테이크 사이에서 가장 긴 단방향 홉이 ~70ms(즉, ~140ms RTT)라면 빠른 경로의 최종성은 120~150ms 범위에 도달할 것으로 예상됩니다.

Anza의 시뮬레이션에서 나온 지연 시간 히스토그램은 스테이크의 65%가 원시 네트워크 지연 시간으로부터 50ms 이내에 최종 확정된다는 것을 보여줍니다. 이는 대부분의 검증인이 데이터가 도착하자마자 거의 즉시 투표한다는 의미입니다.

Alpenglow를 사용하면 결정론적 커밋 시간이 경쟁 L1보다 훨씬 짧아져 Solana의 온체인 경험이 기존 Web2 서비스에 훨씬 가까워집니다.

Alpenglow 보안 및 내결함성 분석

Alpenglow의 합의는 네트워크 스테이크의 최대 33%를 통제하는 공격자에 대한 복원력을 유지하는 기존 BFT 합의를 개선합니다. 이를 “3f + 1”로 표기합니다. Alpenglow는 Martin과 Alvisi가 Fast Byzantine Consensus에서 제시한 5f + 1 한계를 기반으로 이 기준을 네트워크 스테이크의 20%까지 낮춥니다. 보안을 다음 두 부분으로 나누는 “20+20” 복원력 모델을 사용합니다.

• 비잔틴 장애 ≤ 20%: 전체 스테이크의 20% 미만을 적대적 검증인이 통제하면 안전성이 유지됩니다. 이는 수십억 달러에 달하는 막대한 금액이며, 쉽게 식별하고 처벌할 수 있습니다. 따라서 공격자는 전체 스테이크를 잃을 위험을 감수해야 하므로 이러한 공격은 경제적으로 실현하기 어렵습니다.
• 비악의적 현상 ≤ 20%: 적대적 스테이크와 별개로 전체 스테이크의 최대 20%가 오프라인이거나 충돌했거나 합의에 참여하지 않더라도 활성성이 유지됩니다. 여기에는 네트워크 중단, 잘못된 구성, 소프트웨어 버그가 포함됩니다. 따라서 상당수의 검증인이 응답하지 않더라도 네트워크는 블록을 계속 최종 확정할 수 있습니다.

안전성

전체 적대적 스테이크가 ≤20%이고, 하나의 포크에서 정직한 참여자가 최소 60%에 이르는 것을 막을 수 없다면 안전성이 보장됩니다. 이러한 조건에서는 프로토콜이 최종 상태로 간주하는 모든 투표 임계값(즉, 1라운드의 빠른 경로와 2라운드의 느린 경로)이 충분히 높으므로 다른 포크에서 충돌하는 임계값에 도달할 수 없습니다. 적대적 검증인이 이중 투표(즉, 서로 다른 두 포크에 투표하거나 같은 슬롯에서 서로 다른 두 블록을 생성)를 시도하면 정직한 노드는 결국 충돌하는 서명을 받게 됩니다. 이는 쉽게 식별할 수 있으며, 향후에는 슬래싱과 같은 처벌 대상 행위로 이어지는 것이 이상적입니다. 

또한 리더가 유효하지 않은 블록을 생성하려 해도 정직한 검증인은 단순히 투표를 거부합니다. 투표에 직접 통신을 사용하는 Alpenglow의 모델에서는 악의적 행위자가 정직한 노드를 스테이크에서 고립시키거나 이클립스 공격을 가하기 어렵습니다. 결국 정직한 과반수의 투표로 드러나기 때문입니다. 악의적인 리더가 할 수 있는 최선은 합의를 더 느린 경로로 보내거나 한 슬롯의 지연을 일으키는 정도입니다. 체인을 영구적으로 중단하거나 분기시킬 수는 없습니다.

활성성

장애 임계값이 지켜지는 한 부분 동기화 조건에서 활성성이 보장됩니다. 즉, 일정한 네트워크 지연이 지난 후 정직한 검증인은 통신을 통해 특정 블록에 스테이크의 ≥60%를 모을 수 있습니다. 전체 스테이크의 정확히 20%가 오프라인이어도 나머지 정직한 노드가 모두 투표하면 빠른 경로가 성공할 수도 있습니다. 전체 스테이크의 20%를 조금 넘는 비율이 오프라인이면 네트워크는 두 번째 투표 라운드에서 일관되게 느린 최종 확정 경로를 사용합니다. 속도는 느리지만 최종성은 계속 보장됩니다. 따라서 비악의적 장애는 주로 성능에 영향을 미치며 안전성에는 영향을 주지 않습니다.

높은 충돌 복원력

Alpenglow는 열악한 네트워크 조건에 대응하도록 높은 충돌 복원력을 명시적으로 고려해 설계되었습니다. 즉, 악의적인 스테이크가 20%이고 응답하지 않는 스테이크가 20%인 상황에서도 Alpenglow는 안전하게 계속 작동합니다. 

하지만 예상 가능한 모든 장애를 해결하는 만능책은 아닙니다. Alpenglow는 Solana를 크게 개선하지만, 전제 조건이 위반되면 네트워크 중단이나 장애가 발생할 위험을 완전히 없애지는 못합니다. 새 블록을 생성하려면 스테이크의 ≥60%가 필요하며, 스테이크의 ≥20%가 악의적으로 행동하면 합의를 막거나 장애를 일으킬 수 있습니다. 그럼에도 정의된 한도 내에서 Alpenglow는 한두 차례의 투표로 안전성과 활성성을 보장합니다.

역사 증명을 제거하면 보안이 약해지나요?

역사 증명은 현재 Solana 운영의 핵심이지만, 이를 제거해도 보안이 유의미하게 약해지지는 않습니다. 앞서 언급했듯이 보편적인 400ms 한계가 역사 증명 해시 시계를 대체합니다. 네트워크에 상당한 지연이 발생하더라도 Votor의 스테이크 중첩(즉, 1라운드 ≥80%, 2라운드 ≥60% + ≥60%)으로 인해 정직한 검증인이 서로 다른 두 포크를 승인할 수 없습니다.

다만 활성성은 동기화 메시지에 의존하므로 활성성 보장은 달라집니다. 정직한 메시지가 이 지연 시간 내에 도착하는 한 활성성은 유지됩니다. Rotor의 원홉 데이터 전파와 단일 패킷 투표 덕분에 부하가 높은 상황에서도 지연 시간은 400ms 범위 내에 충분히 머뭅니다.

전반적으로 역사 증명을 제거하면 지속적인 해시 연산에 대한 의존성이 사라져 해시 지연 공격 벡터도 제거됩니다. 위에서 언급했듯이 활성성 보장 방식도 달라집니다. 하지만 역사 증명을 제거해도 보안이 유의미하게 약해지지는 않습니다.

핵심 요약

Alpenglow는 비잔틴 장애 허용 범위를 약간 줄이는 대신 1초 미만의 결정론적 최종성, 대규모 비악의적 중단에 대한 안정적인 대응, 악의적 검증인의 더 쉬운 식별을 제공합니다. 핵심 내용은 다음과 같습니다.

• 스테이크의 ≥20%가 이중 서명하지 않는 한 충돌하는 두 블록을 모두 최종 확정할 수 없습니다. 이중 서명은 쉽게 입증하고 처벌할 수 있는 행위입니다.
• 나머지 스테이크가 오프라인이더라도 스테이크의 ≥60%가 통신할 수 있는 한 Solana는 계속 블록을 최종 확정합니다.
• 최악의 경우 최종성은 목표 지연 시간이 ~150ms인 2라운드 투표로 전환됩니다. 따라서 공격은 안전성을 위협하기 전에 체인 속도를 저하시킵니다.
• 20% 비잔틴 한계를 침해하는 비용은 감당하기 어렵습니다. 더 작은 규모의 부정행위는 감지할 수 있으며, 메인넷에서 슬래싱이 도입되면 사회적·경제적으로 처벌할 수 있습니다.

Alpenglow는 검증인에게 어떤 영향을 미치나요?

투표 비용은 Solana 검증인 운영을 시작하는 데 가장 큰 진입 장벽입니다. 검증인을 운영하는 데 필요한 SOL의 엄격한 최솟값은 없습니다. 하지만 합의에 참여하기 위해 필요한 투표 트랜잭션을 슬롯마다 전송하면 하루에 최대 ~1 SOL의 비용이 발생할 수 있습니다.

Alpenglow는 슬롯별 투표 트랜잭션을 간결한 인증서 시스템으로 대체해 현재의 투표 수수료를 사실상 없애고자 합니다. 각 검증인은 모든 다른 노드에 경량 투표 메시지를 브로드캐스트합니다. 정족수에 도달하면 모든 노드가 BLS 서명 체계를 통해 해당 서명을 인증서로 집계할 수 있습니다. 이제 투표가 BLS로 집계되므로 인증서 헤더만 온체인에 고정됩니다. 실제로는 검증인당 매일 발생하는 ~1 SOL의 비용이 사라집니다. 

앞서 언급했듯이 Alpenglow에서는 모든 블록 제안을 동시에 진행되는 두 투표 경로에서 평가합니다.

• Fast-Finalization(1라운드)
  • 첫 번째 투표 라운드에서 특정 블록의 공증된 투표 집계가 스테이크의 ≥80%에 도달하면 시작됩니다
  • Fast-Finalization 인증서를 생성합니다 
  • 목표 지연 시간은 ~100ms입니다
• Slow-Finalization(2라운드)
  • 첫 번째 투표 라운드에서 특정 블록의 공증된 투표 집계가 스테이크의 ≥60%에 도달하면 시작됩니다
  • 두 번째 라운드의 공증된 투표 집계가 스테이크의 ≥60%에 도달하면 최종 확정 인증서를 생성합니다
  • 목표 지연 시간은 ~150ms입니다

Votor는 두 경로를 동시에 실행합니다. 두 집계가 동일한 첫 번째 라운드 투표 스트림에서 업데이트되며, 먼저 임계값을 넘는 인증서가 블록을 최종 확정합니다. 중첩된 스테이크 집합(즉, ≥60%) 덕분에 충돌하는 두 블록이 모두 최종성에 도달하는 일은 없습니다.

이 새로운 설계가 검증인 운영에 미치는 영향은 긍정적입니다.

운영 비용 절감 

투표 수수료를 없애면 검증인이 되려는 참여자의 진입 장벽이 크게 낮아집니다. 반대로 투표 수수료는 약세장에서 소규모 검증인이 인플레이션 보상에 더 의존하게 했습니다. 논쟁이 많았던 SIMD-228 투표를 고려하면 수수료 제거는 향후 Solana 인플레이션에 관한 논의로 이어질 수 있습니다. 현재 논의 중인 Alpenglow 구현안에서는 Cogent Crypto의 검증인 수익 계산기를 기준으로 이러한 비용 절감을 통해 수익을 내기 위한 최소 SOL이 ~4,850 SOL(~80만 USD)에서 ~450 SOL(~7만 5천 USD)로 줄어듭니다.

간소화된 키 관리 

Solana 검증인은 더 이상 슬롯마다 투표에 서명할 필요가 없습니다. 따라서 성능 위험 없이 검증인 신원 키를 하드웨어 보안 모듈(HSM)에 보관할 수 있어 핫 월렛 위험이 실질적으로 줄어듭니다.

리더 슬롯 네트워크 부하 감소

에포크마다 수천 개의 개별 투표 트랜잭션을 블록당 하나의 집계된 인증서로 대체해 리더 슬롯의 네트워크 부하를 줄입니다. 

Lock-Out 계산 제거

Solana의 Tower 방식 지수형 Lock-Out 테이블이 제거됩니다. 이제 검증인은 메모리에서 최신 인증서 체인만 추적하면 되므로 재시작 시간이 단축됩니다.

Alpenglow는 RPC 제공업체에 어떤 영향을 미치나요?

이 새로운 설계가 RPC 제공업체 운영에 미치는 영향은 대체로 긍정적이지만, 일부는 잠재적인 확장성 문제를 일으킬 수 있습니다.

간소화된 커밋 수준 

이 새로운 최종성 수준은 confirmed(즉, 낙관적)와 finalized(즉, 루트가 설정된) 커밋 수준 사이의 기존 차이를 없앱니다. 예를 들어 두 확인 수준을 기다리는 모든 UX 로직(예: finalized 상태가 될 때까지 스피너 표시)을 단일 인증서 확인으로 줄일 수 있습니다.

원장 크기 감소

현재 Solana의 수요를 고려하면 투표 트랜잭션이 사라져 원장 증가량이 약 4분의 3 감소합니다. 스냅샷과 아카이브의 크기도 줄어듭니다. 하지만 블록 한도 CU 증가에 대한 예상 목표를 고려할 때 실제로 어떤 결과가 나타날지는 아직 확실하지 않습니다.

WebSocket 팬아웃 병목 현상

Alpenglow에서는 최종성이 ~100~150ms 안에 도달하고 단일 인증서로 인코딩되므로 더 이상 트랜잭션을 폴링할 이유가 없습니다. 앱, 브라우저 또는 봇이 실행되는 동안 열린 상태를 유지하며 모든 새 인증서를 구독 중인 모든 클라이언트에 브로드캐스트하는 푸시 채널을 통해 최종성 정보를 받는 편이 더 합리적입니다. 문제 지점은 수백만 건의 작은 HTTP 폴링에서 수십만 개의 실시간 소켓으로 이동합니다.

실시간 캐시 최신성

인증서가 100~150ms 안에 블록을 확정하므로 계정 데이터를 0.25초 넘게 보관하는 캐시는 오래된 데이터를 노출할 수 있습니다. 엣지 캐시, CDN, Layer 7 프록시에는 매우 짧은 TTL이나 인증서를 인식하는 제거 훅이 필요합니다.

Alpenglow의 개발 일정은 어떻게 되나요?

Alpenglow는 5월 말 뉴욕 Accelerate 콘퍼런스에서 공식 공개되었습니다. 다음 단계에서는 공식 Solana 개선 문서(SIMD)를 게시합니다. 이후 GitHub, Solana 거버넌스 포럼, Solana Tech Discord를 통해 커뮤니티의 피드백을 받습니다.

커뮤니티 검토 기간이 끝나면 제안은 검증인 커뮤니티의 온체인 거버넌스 투표로 넘어갑니다. 동시에 새로운 설계의 성능과 보안을 보장하기 위한 광범위한 테스트가 진행됩니다.

모든 단계가 계획대로 진행되면 내년 초까지 Solana 메인넷에 배포될 것으로 예상됩니다.

Alpenglow의 위험 요소와 미해결 과제

새로운 합의 알고리즘

새로운 합의 프로토콜로 전환하는 것은 중대한 작업이지만 의미 있는 선례가 있습니다. Ethereum의 2022년 Merge는 대규모 운영 네트워크가 작업 증명에서 지분 증명으로 핵심 합의 메커니즘을 성공적으로 전환하면서도 운영을 중단하지 않을 수 있음을 보여주었습니다. 여전히 수많은 위험이 있지만 완전히 미지의 영역은 아닙니다.

이러한 전환에는 앱, SDK, 월렛, 봇이 예고 없이 작동을 멈추지 않도록 마이그레이션 가이드도 필요합니다. Alpenglow가 confirmed와 finalized 커밋 수준을 단일 인증서 확인으로 통합하기 때문입니다. 두 커밋 수준을 명시적으로 폴링하거나 기본값으로 confirmed 커밋 수준을 사용하는 모든 코드는 작동을 멈춥니다. Alpenglow가 출시되기 전에 문서, 린트 경고, RPC 메서드, 전반적인 코드 아키텍처에 걸쳐 생태계 차원의 조율된 노력이 필요합니다. 

거버넌스

거버넌스 위험도 고려해야 할 요소입니다. 최근 SIMD-228 투표는 Solana가 진정한 탈중앙화 네트워크로 운영되며, 핵심 개발자와 저명한 커뮤니티 구성원이 지지하는 제안도 통과를 보장할 수 없다는 점을 보여줍니다. 하지만 Alpenglow가 도입할 변화, 특히 투표 비용 절감은 검증인에게 전반적으로 유리하며 소규모 운영자에게 특히 유리합니다. 따라서 거버넌스 차원의 저항 가능성은 비교적 낮다고 판단합니다.

보상

지금까지 공개된 Alpenglow 백서와 관련 자료에는 검증인의 투표 활동에 보상을 지급하거나 대역폭 사용에 대해 Rotor 릴레이를 보상하는 정확한 메커니즘이 명시되어 있지 않습니다. 백서는 이중 투표가 처벌 대상이라고 명확히 밝히지만, 실제로 누가 처벌을 제출하는지, 처벌 규모는 얼마인지, 해당 처벌이 자동으로 이뤄지는지 거버넌스에 의해 결정되는지는 명시하지 않습니다. 이러한 누락으로 인해 검증인 경제의 핵심 요소가 정의되지 않은 상태이며, 생태계 내에서 논쟁의 대상이 될 수 있습니다.

MEV

Alpenglow는 현재 Solana의 MEV 환경도 근본적으로 재편합니다. 일부 수익성 높은 전략은 TPU 트래픽을 미러링하거나 트랜잭션이 낙관적으로 확인되기 전에 특정 순서로 스팸 취소 및 교체를 수행하는 데 의존하므로 지연 시간은 여전히 MEV의 핵심 요인입니다. 이 모든 과정은 현재 ~500~600ms의 시간 범위에서 이뤄지지만, Alpenglow는 이를 ~150ms로 단축하려 합니다. 언뜻 보면 리더, 특히 이미 맞춤형 블록 구축 인프라를 호스팅하는 검증인은 더 많은 MEV를 확보할 수 있습니다. 반면 독립적인 지연 시간 차익거래자는 더욱 빠르고 세분화된 트레이딩 시스템을 계속 개발하지 않는 한 경쟁 우위를 잃을 수 있습니다.

다중 동시 리더

Alpenglow의 설계는 현재 Solana 합의 아키텍처보다 다중 동시 리더(MCL)라는 멀티 리더 프레임워크를 도입하기에 훨씬 유연합니다. Anatoly Yakovenko가 언급했듯이, 초기 MCL 프로토타입은 동일한 Rotor 집합을 공유하고 모든 샤드를 동시에 내보내는 두 Alpenglow 인스턴스를 가동하는 방식이 될 수 있습니다. Rotor는 병렬 스트림을 팬아웃하고 Votor는 각 레인을 공증합니다. 하지만 실행 레이어에 관한 여러 질문이 제기됩니다. 구체적으로는 다음과 같습니다.

• 두 리더의 블록이 같은 계정을 잠그지 않도록 쓰기 집합을 어떻게 분할해야 하나요? 같은 계정을 잠근다면 충돌 해결을 결정론적이고 저렴하게 만드는 방법은 무엇인가요?
• 재실행 비용을 두 배로 늘리지 않고 레인별 인증서를 하나의 표준 상태 루트로 병합하려면 어떻게 해야 하나요?
• 레인이 자산을 두고 경쟁할 때 어떤 수수료 시장 로직을 적용해야 하나요?
• 이를 통해 어떤 종류의 레인 간 MEV 전략이 가능해지나요?
• 레인 한도가 없다면 스테이크가 많은 단일 검증인이 동시 슬롯을 지배할 수 있나요? 

Alpenglow의 설계는 합의 수준의 장애물을 제거해 MCL을 현실적인 로드맵 항목으로 만드는 데 도움이 됩니다. 하지만 이러한 미해결 과제에 답하기 전까지는 여전히 유망한 미래의 과제로 남습니다.

결론

이 보고서에서는 Alpenglow의 핵심 구성 요소를 살펴보고 이들이 Solana의 합의 모델을 어떻게 재구성하는지 검토했습니다. 기술적 개선 사항, 검증인 경제의 변화, 네트워크 수준의 영향과 함께 성능, 단순성, 확장성 측면의 이점도 분석했습니다.

Alpenglow 백서는 프로토콜 설계뿐 아니라 개발 철학에서도 Solana의 전환점이 됩니다. Solana는 처음으로 합의 알고리즘의 공식 정확성 증명을 공개했습니다. 이는 전통적으로 경험과 엔지니어링을 중심으로 하던 접근 방식에서 더욱 엄격하고 연구에 기반한 토대로 전환하고 있음을 보여줍니다. 이러한 발전은 성능을 계속 우선시하면서도 정형 검증의 엄격함을 더해 성숙해지는 생태계를 반영합니다.

역사 증명(PoH)의 지원 중단은 네트워크 정체성에서도 이와 유사한 상징적 전환을 의미합니다. PoH의 실질적 중요성은 자주 과장되었지만, 오랫동안 Solana를 대표하는 혁신으로서 기술 입문 자료에서 비중 있게 다뤄졌으며 브랜드와 동의어가 되었습니다. PoH의 제거는 한 시대의 끝이자 새로운 시대의 시작입니다. Solana가 성숙하고 있습니다.

추가 자료

• Accelerate Alpenglow 발표 슬라이드 - Roger Wattenhofer
• Alpenglow: Solana를 위한 새로운 합의 - Anza 블로그
• Alpenglow 참조 구현 - GitHub
• Alpenglow 백서 - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Solana의 합의 - Helius 블로그
• Accelerate 2025의 Scale or Die: Solana의 새로운 합의 Alpenglow 소개 - YouTube 동영상