챕터 3: 솔라나 (Solana)

개요

솔라나(Solana)는 2020년 메인넷을 출시한 고성능 레이어1 블록체인으로, "세계에서 가장 빠른 블록체인"을 표방하며 설계된 플랫폼입니다. 이더리움이 직면한 확장성 문제, 즉 느린 처리 속도와 높은 수수료 문제를 근본적인 아키텍처 혁신을 통해 해결하고자 했습니다. 솔라나의 접근법은 단순히 기존 기술을 개선하는 것이 아니라, 병렬 실행(Parallel Execution), 히스토리 증명(Proof of History) 등 독자적인 핵심 기술들을 결합하여 초당 수만 건의 트랜잭션 처리를 목표로 삼는다는 점에서 차별화됩니다.

이번 챕터에서는 솔라나를 솔라나답게 만드는 7가지 핵심 개념을 심층적으로 살펴봅니다. 아키텍처 수준의 혁신인 병렬 실행과 히스토리 증명(PoH)을 시작으로, 보안과 개발 편의성을 높이는 프로그램 파생 주소(PDA), 수수료 구조를 혁신한 로컬 수수료 시장, 그리고 네트워크 효율을 높이는 걸프 스트림(Gulf Stream)과 터빈(Turbine)까지 폭넓게 다룹니다. 마지막으로 솔라나의 미래를 결정할 알펜글로우(Alpenglow) 업그레이드까지 포함하여, 솔라나의 현재와 미래를 종합적으로 이해할 수 있도록 구성하였습니다.

솔라나는 뛰어난 성능으로 주목받는 동시에 네트워크 중단, 중앙화 우려 등 현실적인 한계도 지적받아 왔습니다. 이 챕터를 통해 솔라나 기술의 장점과 트레이드오프를 균형 있게 파악하고, 블록체인 확장성 문제에 대한 솔라나만의 해법을 비판적으로 이해하는 것을 목표로 합니다.

---

병렬 실행 (Parallel Execution)

정의

병렬 실행이란 솔라나가 트랜잭션을 처리하는 방식으로, 서로 다른 계정(account)을 건드리는 트랜잭션들을 동시에(simultaneously) 여러 CPU 코어에서 실행하는 메커니즘입니다. 이를 가능하게 하는 핵심 조건은 "트랜잭션이 사전에 자신이 읽거나 쓸 계정 목록을 선언해야 한다"는 규칙입니다. 런타임은 이 선언을 바탕으로 트랜잭션 간의 충돌 여부를 미리 파악하고, 충돌이 없는 트랜잭션들은 병렬로 처리하며, 같은 계정을 건드리는 트랜잭션만 순차적으로 처리합니다. 솔라나는 이 방식을 시코(Sealevel)이라는 병렬 런타임을 통해 구현합니다.

핵심 포인트

• 마트 계산대 vs. 단일 대기열: 이더리움은 전역 상태(global state)에 순차적으로 접근하는 단일 대기열 방식입니다. 솔라나는 마치 대형 마트에서 여러 계산대를 동시에 운영하는 것처럼, 서로 다른 계정을 처리하는 트랜잭션들을 독립적으로 병렬 실행합니다. 장을 보는 손님(트랜잭션)이 서로 다른 상품(계정)을 계산할 때는 같은 줄에 설 필요가 없습니다.

• 사전 선언(Pre-declaration)의 중요성: 모든 솔라나 트랜잭션은 실행 전에 접근할 계정 목록을 반드시 명시해야 합니다. 이 요구사항은 병렬 실행을 가능하게 하는 전제 조건이지만, 동시에 개발자에게 추가적인 설계 부담을 주기도 합니다. 런타임 중에 동적으로 접근 대상이 결정되는 구조는 솔라나에서 구현이 더 복잡합니다.

• 성능 상의 이점: 병렬 실행은 솔라나가 초당 수만 건의 트랜잭션 처리를 주장하는 가장 근본적인 이유입니다. 현대 서버는 수십 개의 CPU 코어를 보유하므로, 이론적으로 코어 수에 비례하는 처리 성능 향상을 얻을 수 있습니다.

• 충돌 시 순차 처리: 동일 계정에 접근하는 트랜잭션들은 여전히 순차적으로 처리됩니다. 인기 있는 DeFi 프로토콜이나 NFT 민팅처럼 수많은 트랜잭션이 동일 계정에 집중되면, 병렬 실행의 이점이 줄어들고 병목이 발생할 수 있습니다.

• 이더리움과의 근본적 차이: 이더리움의 EVM은 글로벌 상태 전환(global state transition)을 기본 모델로 하여 순차 실행에 최적화되어 있습니다. 이더리움이 병렬 실행을 도입하려면 계정 접근 예측이나 낙관적 병렬화 같은 복잡한 추가 설계가 필요한 반면, 솔라나는 처음부터 병렬 실행을 설계 원칙으로 삼았습니다.

관련 개념

병렬 실행은 솔라나의 모든 성능 관련 개념과 밀접하게 연결됩니다. 로컬 수수료 시장은 병렬 실행과 조화를 이루어, 특정 계정에 트랜잭션이 집중될 때 해당 계정의 수수료만 올라가고 나머지 병렬 실행 흐름에는 영향을 주지 않도록 설계되었습니다. 또한 걸프 스트림은 트랜잭션을 사전에 리더에게 전달함으로써 병렬 실행에 필요한 계정 정보를 미리 수집·정렬하는 데 기여합니다. 알펜글로우 업그레이드는 병렬 실행 아키텍처를 유지하면서 합의 레이어를 대폭 개선하여 시너지를 극대화하는 방향으로 설계되었습니다.

---

히스토리 증명 (Proof of History, PoH)

정의

히스토리 증명(Proof of History, PoH)은 솔라나가 고안한 암호학적 시간 기록 메커니즘입니다. 연속적인 SHA-256 해시 시퀀스를 생성하여 특정 이벤트들이 특정 순서로, 특정 시점에 발생했음을 수학적으로 증명합니다. 일반적인 블록체인에서 노드들은 이벤트의 순서와 시간에 합의하기 위해 복잡한 메시지 교환이 필요합니다. PoH는 이 과정을 암호학적 타임스탬프로 대체하여, 합의에 소요되는 오버헤드를 줄이고 처리 속도를 높이는 역할을 했습니다. 다만, PoH는 독립적인 합의 알고리즘이 아니라 솔라나의 지분증명(PoS) 기반 합의 메커니즘인 Tower BFT를 보조하는 시간 기록 레이어입니다.

핵심 포인트

• 연속 해시 시퀀스: PoH는 이전 해시의 출력을 다음 해시의 입력으로 사용하는 연속적 해싱(sequential hashing)으로 구현됩니다. 이 시퀀스는 계산에 시간이 걸리므로, 특정 해시값이 존재한다는 것은 그 이전 해시들이 반드시 먼저 계산되었음을 의미합니다. 즉, 순서를 위조할 수 없습니다.

• 신뢰할 수 있는 글로벌 시계 역할: 전통적인 분산 시스템에서 노드 간 시간 동기화는 어려운 문제입니다. PoH는 블록체인에 내재된 암호학적 시계를 제공하여, 외부 타임스탬프 서버 없이도 이벤트의 상대적 순서를 모든 참여자가 검증할 수 있게 합니다.

• Tower BFT와의 관계: PoH는 합의(consensus)를 직접 달성하지 않습니다. Tower BFT가 실제 합의를 담당하며, PoH는 그 기반이 되는 시간 정보를 제공합니다. PoH가 만들어내는 슬롯(slot)과 에포크(epoch) 구조 위에서 검증자들이 투표를 진행합니다.

• 리더 스케줄과의 연동: 솔라나는 각 슬롯마다 블록을 생성할 리더(leader) 검증자를 사전에 지정합니다. PoH의 시간 흐름은 이 리더 스케줄과 동기화되어, 각 리더가 자신의 슬롯에 정확히 트랜잭션을 처리하고 다음 리더에게 넘겨주는 구조를 만듭니다.

• 알펜글로우에서의 폐지: PoH는 솔라나의 상징적 기술이었지만, 알펜글로우(Alpenglow) 업그레이드에서 완전히 폐지될 예정입니다. 고정 슬롯 스케줄링(fixed slot scheduling)이 PoH를 대체하며, 이를 통해 더 단순하고 빠른 합의가 가능해질 것으로 기대됩니다. PoH가 제공하던 시간 기록 역할을 새로운 방식으로 수행하게 됩니다.

관련 개념

PoH는 솔라나의 합의 구조 전반과 긴밀하게 연결됩니다. 병렬 실행은 PoH가 만드는 시간 구조와 리더 스케줄 위에서 작동합니다. 걸프 스트림은 PoH의 리더 스케줄 정보를 활용하여 트랜잭션을 해당 리더에게 사전 전달합니다. 가장 중요한 관련 개념은 알펜글로우로, PoH를 완전히 대체하는 업그레이드이기 때문에 PoH를 이해하는 것은 곧 알펜글로우가 무엇을 개선하는지를 이해하는 열쇠가 됩니다.

---

프로그램 파생 주소 (Program Derived Address, PDA)

정의

프로그램 파생 주소(Program Derived Address, PDA)는 솔라나에서 프로그램(스마트 컨트랙트)이 수학적으로 생성하는 특수한 주소로, 대응하는 프라이빗 키(private key)가 존재하지 않습니다. 일반적인 솔라나 지갑 주소는 공개키-개인키 쌍으로 이루어져 있어 개인키 소유자가 해당 주소의 자산을 관리합니다. 반면, PDA는 특정 프로그램의 ID와 시드(seed) 값들을 결합하여 타원 곡선(elliptic curve) 밖의 점(off-curve point)으로 수학적으로 유도되기 때문에 어떤 개인키도 존재하지 않으며, 오직 해당 프로그램만이 PDA를 "서명(sign)"하여 제어할 수 있습니다.

핵심 포인트

• 에스크로 커스터디 문제 해결: DeFi에서 에스크로(escrow) 기능은 제3자가 일시적으로 자금을 보관해야 하는 상황을 만듭니다. 전통적인 방식에서는 이 자금을 관리하는 키를 누군가(또는 멀티시그)가 보유해야 하며, 이는 내부자 횡령이나 해킹의 위험을 내포합니다. PDA는 프라이빗 키가 없으므로, 어떤 사람도 PDA에 보관된 자금을 임의로 꺼낼 수 없습니다. 오직 소유 프로그램의 로직이 허용하는 조건에서만 자금이 이동합니다.

• 프로그램만이 PDA에 서명 가능: 솔라나 런타임은 특정 프로그램이 자신의 PDA를 대신하여 서명하는 행위를 허용합니다. 이를 "프로그램 서명(program signing)" 또는 "CPI(Cross-Program Invocation) with signer"라고 부릅니다. 이 메커니즘이 있어야 프로그램이 PDA 계정의 자산을 이동시키거나 데이터를 변경할 수 있습니다.

• 결정론적 주소 생성: PDA는 프로그램 ID와 시드 값이 동일하면 항상 동일한 주소를 생성합니다. 이 결정론적(deterministic) 특성 덕분에 어떤 참여자도 특정 PDA의 주소를 사전에 계산하고 검증할 수 있어, 투명성과 예측 가능성이 보장됩니다.

• 다양한 활용 사례: PDA는 에스크로 외에도 AMM(Automated Market Maker)의 유동성 풀, NFT 메타데이터 저장 계정, 사용자별 상태 저장 계정, 온체인 설정 데이터 등 솔라나 DApp 개발의 핵심 패턴으로 광범위하게 사용됩니다.

• 이더리움과의 비교: 이더리움의 스마트 컨트랙트도 자체 주소를 가지고 자산을 보관할 수 있습니다. 그러나 솔라나의 PDA는 계정 모델과 프로그램 소유 구조의 특수성으로 인해 더 명시적이고 세밀한 방식으로 자산 커스터디를 구현합니다.

관련 개념

PDA는 솔라나의 프로그래밍 모델 전반과 연결됩니다. 병렬 실행과의 관계에서, PDA를 포함하는 트랜잭션도 해당 PDA 계정을 사전 선언해야 하며, 이는 병렬 실행 스케줄링에 포함됩니다. 로컬 수수료 시장과의 관계에서, 많은 사용자가 동일한 PDA(예: 인기 있는 DEX의 유동성 풀)에 접근하면 해당 계정의 수수료가 상승하는 현상이 나타납니다. PDA는 솔라나 DApp 보안 설계의 근간으로, 알펜글로우 업그레이드 이후에도 프로그래밍 모델의 핵심 요소로 유지됩니다.

---

로컬 수수료 시장 (Local Fee Markets)

정의

로컬 수수료 시장(Local Fee Markets)은 솔라나의 수수료 책정 방식으로, 네트워크 전체 혼잡도가 아닌 개별 계정(account) 수준에서 수수료가 결정되는 메커니즘입니다. 이더리움에서는 네트워크 전체 수요에 따라 기본 수수료(base fee)가 결정되므로, 한 DApp에서 혼잡이 발생하면 전혀 관계없는 다른 트랜잭션의 수수료도 올라갑니다. 반면 솔라나의 로컬 수수료 시장에서는 특정 계정에 트랜잭션이 몰릴 때 해당 계정과 관련된 트랜잭션의 우선 수수료(priority fee)만 상승하고, 다른 계정을 다루는 트랜잭션은 영향을 받지 않습니다.

핵심 포인트

• 계정 수준의 수수료 책정: 솔라나의 모든 트랜잭션에는 기본 수수료(base fee)와 선택적인 우선 수수료(priority fee)가 있습니다. 특정 계정에 접근하는 트랜잭션이 많아지면, 해당 계정에 대한 우선 수수료 경쟁이 발생합니다. 인기 있는 NFT 민팅이나 DeFi 청산(liquidation) 이벤트처럼 특정 계정에 수요가 집중될 때 이 효과가 뚜렷하게 나타납니다.

• 이더리움 글로벌 수수료 시장과의 대조: 이더리움에서 인기 있는 NFT 민팅이 발생하면 가스 가격이 네트워크 전체에서 폭등하여, 단순한 토큰 전송 같은 무관한 트랜잭션도 비싸집니다. 솔라나의 로컬 수수료 시장은 이 문제를 원칙적으로 해결하여, 혼잡의 영향이 해당 계정 범위에 국한되도록 합니다.

• 병렬 실행과의 시너지: 로컬 수수료 시장은 병렬 실행과 함께 작동할 때 가장 큰 효과를 발휘합니다. 혼잡한 계정의 트랜잭션들이 비싼 수수료를 지불하며 경쟁하는 동안, 다른 계정을 처리하는 트랜잭션들은 낮은 수수료로 병렬 실행 레인에서 정상적으로 처리됩니다.

• 실제 한계 — 스팸 취약성: 로컬 수수료 시장은 이론적으로 우아한 설계이지만, 실제로는 극심한 스팸 공격이나 봇 트래픽이 발생할 때 불완전하게 작동한다는 비판을 받습니다. 스팸 트랜잭션이 여러 계정에 분산되어 공격하거나, 네트워크 수준의 포화 상태가 발생하면 로컬 수수료 메커니즘만으로 네트워크 품질을 보장하기 어렵습니다. 솔라나가 과거 여러 차례 네트워크 성능 저하를 겪은 원인 중 하나입니다.

• QUIC 업그레이드와의 연계: 솔라나는 스팸 문제를 개선하기 위해 트랜잭션 전송 프로토콜을 UDP에서 QUIC으로 전환하고, 스테이크 가중 서비스 품질(stake-weighted QoS)을 도입하는 등 보완 조치를 시행했습니다. 이는 로컬 수수료 시장만으로는 충분하지 않음을 인정한 현실적인 대응입니다.

관련 개념

로컬 수수료 시장은 병렬 실행의 아키텍처적 전제 위에 설계된 수수료 메커니즘입니다. PDA를 포함한 계정들도 로컬 수수료 시장의 영향을 받으며, 인기 있는 프로그램의 PDA는 수수료 경쟁의 대상이 됩니다. 걸프 스트림은 트랜잭션을 리더에게 사전 전달하면서 우선 수수료 정보도 함께 전달하여, 리더가 수익성 높은 트랜잭션을 우선 처리할 수 있게 합니다. 알펜글로우는 합의 속도를 대폭 향상시켜 수수료 경쟁의 시간적 압박을 줄이는 간접적 효과도 기대됩니다.

---

걸프 스트림 (Gulf Stream)

정의

걸프 스트림(Gulf Stream)은 솔라나의 트랜잭션 전달(transaction forwarding) 프로토콜입니다. 비트코인이나 이더리움 등 대부분의 블록체인에서는 트랜잭션이 공개 멤풀(mempool)에 브로드캐스트되어 모든 노드가 보관하다가 리더(채굴자 또는 검증자)가 선택합니다. 걸프 스트림은 이 방식 대신, 트랜잭션을 현재 리더와 향후 예정된 리더들에게 직접 전달합니다. 솔라나는 PoH 기반의 리더 스케줄을 통해 미래 리더를 사전에 알 수 있기 때문에 이 방식이 가능합니다.

핵심 포인트

• 멤풀 없는 아키텍처: 솔라나는 공개 멤풀을 운영하지 않습니다. 대신 걸프 스트림을 통해 트랜잭션이 네트워크 전체에 브로드캐스트되지 않고, 필요한 리더들에게만 직접 전달됩니다. 이를 통해 브로드캐스트 단계에서 발생하는 네트워크 오버헤드와 지연(latency)을 줄입니다.

• 리더 스케줄 활용: PoH가 만드는 리더 스케줄 덕분에 솔라나의 모든 노드는 앞으로 여러 슬롯 동안 누가 리더인지 미리 알고 있습니다. 걸프 스트림은 이 정보를 활용하여 트랜잭션을 현재 리더뿐 아니라 다음 순서의 리더들에게도 사전에 전달해, 리더가 블록 생성을 시작하기 전에 이미 처리할 트랜잭션을 보유하고 있도록 합니다.

• 지연 감소 효과: 공개 멤풀 방식에서는 트랜잭션이 전체 네트워크에 전파된 후 리더가 선택하므로 전파 지연이 발생합니다. 걸프 스트림은 이 전파 경로를 단축하여, 트랜잭션이 리더에 도달하는 시간을 줄이고 결과적으로 확인(confirmation) 속도를 높입니다.

• MEV(최대 추출 가능 가치) 영향: 공개 멤풀이 없으면 이더리움에서 흔한 형태의 프론트러닝(front-running) MEV가 어렵습니다. 그러나 솔라나에서도 리더가 자신에게 전달된 트랜잭션을 재정렬(reorder)하는 방식의 MEV는 여전히 존재하며, 이에 대한 논의가 활발합니다.

• 중앙화 우려: 트랜잭션이 소수의 예정된 리더들에게 직접 전달되는 구조는, 이론적으로 해당 리더들이 특정 트랜잭션을 검열(censor)하거나 우선순위를 조작할 가능성을 만듭니다. 이는 솔라나 아키텍처의 탈중앙화 관련 비판 중 하나로 제기됩니다.

관련 개념

걸프 스트림은 **히스토리 증명(PoH)**의 리더 스케줄 없이는 작동할 수 없습니다. 알펜글로우 업그레이드에서 PoH가 폐지되면 리더 스케줄 방식도 변경되므로, 걸프 스트림 프로토콜도 이에 맞게 조정될 것으로 예상됩니다. 로컬 수수료 시장과의 관계에서, 걸프 스트림을 통해 전달되는 트랜잭션에는 우선 수수료가 포함되어 리더가 처리 우선순위를 결정하는 기준이 됩니다. 터빈은 걸프 스트림과 상호 보완적으로 작동하며, 걸프 스트림이 트랜잭션을 리더에게 모으는 과정이라면, 터빈은 완성된 블록을 나머지 검증자들에게 배포하는 과정입니다.

---

터빈 (Turbine)

정의

터빈(Turbine)은 솔라나의 블록 전파(block propagation) 프로토콜입니다. 리더가 블록을 생성하면 이를 네트워크의 모든 검증자(validator)에게 전달해야 하는데, 수천 명의 검증자에게 대용량 블록 데이터를 직접 전송하면 엄청난 네트워크 대역폭이 필요합니다. 터빈은 이 문제를 해결하기 위해 블록을 '슈레드(sh