150ms finality는 공짜가 아니다: Solana Alpenglow로 보는 합의 지연과 신뢰 가정

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: “빠른 finality”라는 숫자를 볼 때, 그 속도를 가능하게 한 투표 임계값·네트워크 가정·운영 비용을 같이 설명할 수 있는가?
• 핵심 출처:
  • Solana Network Upgrades - 최종 업데이트 2026-02-03, 확인일 2026-06-10
  • SIMD-0326: Alpenglow - 생성일 2025-07-25, 확인일 2026-06-10
  • SIMD-0326: Alpenglow PR #326 - 병합일 2025-09-09, 최종 업데이트 2026-01-12, 확인일 2026-06-10
  • Alpenglow: A New Consensus for Solana - 게시일 2025-05-19, 확인일 2026-06-10
  • SIMD-0326 proposal forum thread - 게시일 2025-08-14, 확인일 2026-06-10

1. 왜 지금 봐야 하나

Solana 공식 네트워크 업그레이드 페이지는 Alpenglow를 Agave 4.1에 예상되는, 아직 개발 중인 합의 업그레이드로 분류한다. 같은 페이지는 Alpenglow가 150ms confirmation time을 목표로 하고, Proof of History와 온체인 vote transaction을 제거하며, Validator Admission Ticket(VAT)이라는 epoch당 1.6 SOL 비용 모델을 도입한다고 정리한다. 즉 이것은 단순한 성능 패치가 아니라 “Solana가 블록에 동의하는 방식” 자체를 바꾸는 작업이다.

개발자가 이 이슈를 봐야 하는 이유는 명확하다. finality는 UX 문구가 아니라 상태를 확정해도 되는 시점이다. 지갑은 언제 “완료”를 보여줄지, 거래소는 몇 confirmation 뒤 입금을 반영할지, 브리지는 언제 반대편 체인에 메시지를 전달할지, 청산 봇은 언제 포지션 상태를 신뢰할지 모두 finality 가정 위에서 움직인다.

하지만 “12.8초에서 150ms로 빨라진다”만 외우면 위험하다. Alpenglow는 빠른 길과 느린 길을 동시에 두고, 80% stake가 빨리 응답하면 한 round로, 60% stake가 응답하면 두 round로 block을 finalize하는 구조를 제안한다. 속도는 합의 임계값, 네트워크 지연, validator 참여율, 메시지 전달 방식, 인센티브 설계가 맞물린 결과다.

2. 핵심 개념

기존 Solana 합의는 Proof of History와 TowerBFT에 기반한다. SIMD-0326은 이 구조가 12.8초 finality와 pre-confirmation을 제공하지만, formal security proof 부재와 통신·계산 오버헤드 문제가 있다고 설명한다. Alpenglow는 그중 Votor라는 투표·finalization 부분을 먼저 바꾸자는 제안이다. Rotor, Smart Sampling, Lazy/Asynchronous Execution은 이 SIMD 범위 밖이며 별도 제안으로 다뤄진다.

Votor의 핵심은 certificate다. validator들이 특정 block을 notarize, skip, finalize했다는 stake-weighted vote를 모으고, 이를 aggregate signature 같은 효율적인 증거로 표현한다. block은 “많은 노드가 봤다”가 아니라 “정해진 stake 비율이 특정 의미의 vote를 했다”는 certificate로 전진한다.

여기서 두 경로가 나온다.

• fast-finalization: 한 round에서 80% stake vote를 관측하면 block을 finalize한다.
• slow-finalization: 두 round에서 60% stake 조건을 만족하면 block을 finalize한다.

Anza 글은 시뮬레이션 기준으로 약 150ms median actual finality, 빠른 경우 약 100ms를 기대한다고 설명한다. 단, 이 수치는 현재 mainnet stake distribution을 사용한 시뮬레이션이며 computation overhead는 별도로 봐야 한다. 네트워크 물리 지연은 사라지지 않는다. Zurich 기준 예시에서도 가까운 stake와 먼 stake의 latency tail이 다르게 나타난다.

3. 최신 이슈와 연결

2026년 현재 중요한 점은 Alpenglow가 이미 아이디어 소개 단계를 지나 Solana 공식 업그레이드 로드맵에 올라와 있다는 것이다. Solana 페이지는 상태를 “under development”, 예상 release를 “Agave 4.1”로 표시한다. 또한 같은 묶음에 100M CU, larger transaction size, CPI nesting limit 증가, block revenue distribution 같은 실행·경제·개발자 경험 변화가 함께 배치되어 있다.

SIMD-0326 PR은 2025년 9월 병합되었고 2026년 1월까지 논의가 정리되었다. PR discussion에서 눈에 띄는 부분은 “finalized가 optimistic confirmation과 무엇이 다르냐”, “20+20 security model이 기존 33% Byzantine tolerance와 어떻게 다른 trade-off냐”, “validator metadata를 어떻게 온체인에 둘 것이냐”, “latency griefing과 vote manipulation을 어떤 reward/slashing 규칙으로 막을 것이냐” 같은 질문이다.

이 논의는 숫자보다 중요하다. 합의 업그레이드는 API 하나가 빨라지는 일이 아니다. 네트워크가 무엇을 장애로 간주하고, 어느 정도 공격 stake를 견디며, 응답하지 않는 stake를 얼마나 허용하고, validator에게 어떤 비용과 보상을 부과할지 다시 쓰는 일이다.

4. 개발자 관점 해석

첫 번째 해석은 finality latency와 confirmation UX를 분리해야 한다는 것이다. 사용자 화면에서는 150ms confirmation이 “거의 즉시 완료”처럼 보일 수 있다. 하지만 백엔드 정산, bridge message, 고가치 출금, 청산, oracle update는 “어떤 commitment level을 읽고 있는지”를 명시해야 한다. 빠른 chain일수록 모호한 confirmed 의존성이 코드에 숨어 있으면 장애 때 찾기 어렵다.

두 번째 해석은 속도는 더 강한 신뢰가 아니라 다른 신뢰 가정이라는 점이다. Alpenglow의 20+20 모델은 최대 20% adversarial stake와 추가 20% non-responsive stake를 견디는 방향으로 설명된다. 이것은 전통적인 1/3 Byzantine tolerance와 같은 문장이 아니다. 개발자는 “더 빠르다”를 “항상 더 안전하다”로 번역하면 안 된다. 내 앱이 걱정하는 실패가 Byzantine double-vote인지, validator outage인지, 네트워크 partition인지, RPC lag인지에 따라 필요한 대기 시간과 방어가 달라진다.

세 번째 해석은 vote transaction 제거가 앱 개발자에게도 간접 영향을 준다는 것이다. Solana 공식 페이지는 온체인 vote transaction 제거가 block compute capacity 증가의 길을 열 수 있다고 설명한다. 그렇다고 모든 dApp이 자동으로 더 많은 throughput을 얻는 것은 아니다. fee market, CU limit, priority fee, validator client 성능, 네트워크 packet 처리 같은 병목도 같이 봐야 한다.

네 번째 해석은 VAT가 보안 예산과 validator 참여 비용의 문제라는 점이다. Forum과 공식 페이지는 Alpenglow의 Validator Admission Ticket을 epoch당 1.6 SOL로 설명한다. 이 비용은 단순 수수료가 아니라 consensus set 참여의 마찰이다. 비용이 너무 낮으면 spam validator 문제가 생길 수 있고, 너무 높으면 작은 validator의 참여성이 줄어들 수 있다. finality 속도는 validator 경제와 분리되지 않는다.

5. 내 프로젝트에 적용할 체크포인트

1. Solana 앱이라면 processed, confirmed, finalized를 어디에서 쓰는지 코드 검색으로 표로 만들어라. UI, webhook, indexer, 정산 job, bridge adapter를 분리해서 봐야 한다.
2. “빠른 완료” UX를 만들 때도 고가치 작업에는 별도 정책을 둬라. 예: 화면 표시는 빠르게, 출금·cross-chain 메시지는 finalized 기준 또는 추가 risk threshold 기준.
3. timeout 값을 하드코딩하지 마라. 500ms 뒤 재조회, 12초 뒤 확정 간주 같은 값은 합의 업그레이드에서 기술 부채가 된다.
4. RPC 응답의 commitment와 slot/root 정보를 로그에 남겨라. 나중에 재조직, 지연, fork-choice 이슈를 분석하려면 “무엇을 믿고 처리했는지”가 남아야 한다.
5. validator·RPC 공급자 의존성을 운영 리스크로 봐라. finality가 빨라져도 특정 RPC가 늦게 root를 반영하면 내 앱의 체감 finality는 느리다.
6. bridge나 oracle을 운영한다면 원천 체인의 finality policy를 설정 파일로 분리하라. 합의 업그레이드마다 코드를 고치지 않고 정책만 바꿀 수 있어야 한다.
7. 성능 홍보 문구를 그대로 제품 보증으로 옮기지 마라. 150ms는 protocol target/시뮬레이션 기반 기대치이며, p95·장애 상황·client rollout 상태를 별도로 확인해야 한다.

6. 오늘 10분 액션

10분 동안 내 코드에서 Solana confirmation 의존성을 찾는다.

1분: 저장소에서 commitment, confirmed, finalized, processed, confirmTransaction 검색
2분: 각 사용처를 UI / backend settlement / indexer / bridge-oracle / test 로 분류
2분: 각 사용처 옆에 “rollback되면 손실이 생기는가?”를 yes/no로 적기
2분: timeout 하드코딩 값과 retry 정책 찾기
2분: RPC 응답 로그에 slot, blockhash, commitment, root가 남는지 확인
1분: 가장 위험한 한 곳에 TODO 작성 — “Alpenglow/합의 변경 후 재검토”

오늘의 목표는 Alpenglow 대응 코드를 미리 쓰는 것이 아니다. finality 가정이 코드 어디에 박혀 있는지 보이게 만드는 것이다.

7. 더 볼 자료

• Solana Network Upgrades: Alpenglow, 100M CU, block revenue distribution이 같은 Agave 4.1 묶음에 어떻게 배치되는지 확인하기 좋다.
• SIMD-0326 원문: Votor 범위, fast/slow finalization, timeout, certificate, VAT 설명을 직접 읽어야 한다.
• SIMD-0326 PR discussion: finality 보장, 20+20 모델, latency griefing 질문처럼 실제 검토자가 걱정한 지점을 볼 수 있다.
• Anza Alpenglow 글: 왜 TowerBFT와 PoH를 대체하려는지, 100~150ms 숫자가 어떤 시뮬레이션 맥락에서 나오는지 확인할 수 있다.
• Solana Developer Forum governance thread: upgrade가 기술 제안에서 validator vote와 incentive 논의로 넘어가는 과정을 볼 수 있다.

중복 회피 메모

최근 blockchain_dev 글은 Ethereum EIP-7928의 block-level access list, PeerDAS와 blob data availability, Arbitrum Nova 오프보딩, Ethereum native account abstraction, Zcash 비상 차단, Gnosis Pay 모듈 권한 검증을 다뤘다. 이번 글은 Solana Alpenglow의 consensus finality, Votor vote threshold, 20+20 resilience, VAT 인센티브, dApp confirmation 정책을 다뤄 기존 Ethereum 실행/DA/브리지/지갑 보안 글과 주제와 결론을 분리했다.