솔라나는 단순히 더 빠른 블록체인이 아니라, 실제 금융 시장을 대체할 수 있는 온체인 자본시장 인프라를 구축하려 한다. 이 과정에서 탈중앙화 이념보다는 거래 체결 속도, 지연(latency), 안정성과 같은 시장 친화적인 요소에 더 높은 우선순위를 둔다. Firedancer, Alpenglow, DoubleZero와 같은 인프라 업그레이드는 모두 이러한 방향성 위에서 설계되고 있다.
솔라나는 이미 높은 처리량과 낮은 지연을 확보했지만, 네트워크의 발전을 제약하는 핵심 병목은 따로 존재한다. 바로 트랜잭션의 순서와 포함 여부를 결정하는 MEV 중심 구조다. 특히 Jito 기반 독점적인 블록 생성 구조는 MEV를 효율화하는 동시에, 트랜잭션 지연과 체결 불확실성, 인프라 의존성을 만들어내고 있다. 이는 단순한 성능 문제가 아니라, 시장의 마이크로스트럭처 문제다.
솔라나의 장기 로드맵은 성능 개선을 넘어, 거래 순서와 실행 방식 자체를 재정의하는 데 초점이 맞춰져 있다. BAM, ACE, MCL, APE와 같은 구조는 서로 다른 레이어에서 트랜잭션 정렬과 실행을 재설계하려는 시도다. 이러한 접근은 MEV를 제거하기보다는 그 영향력을 분산시키고, 시장 구조를 보다 공정하고 예측 가능하게 만드는 방향에 가깝다. 결국 인프라의 방향성과 경제적 인센티브를 얼마나 정렬할 수 있는지가 핵심 과제가 된다.
우선 컴퓨팅 블록체인의 두 대표주자인 이더리움과 솔라나라는 더 이상 추구하는 방향이 같지 않다는 것을 인지하고 시작해야한다.
이더리움은 탈신뢰(trustlessness), 검열 저항(censorship resistance), 사이퍼펑크(cypherpunk) 정신과 같은 이념적 가치를 핵심 설계 원칙으로 삼는다. 국가나 기업의 간섭 없이 누구나 접근할 수 있는 중립적 인프라, 그것이 이더리움이 추구하는 것이고 성능이나 사용성보다 이런 원칙들이 언제나 우선시된다.
하지만 솔라나는 명시적으로 다른 길을 선택하고 있다. 지난해 솔라나 핵심 개발사 Anza는 Anatoly Yakovenko(솔라나 공동창업자), Jito Labs의 Lucas Bruder, Multicoin Capital의 Kyle Samani등이 공동 서명한 비전 선언문 "The Internet Capital Markets Roadmap"을 발표했다. 이 선언문에 적힌 다음 문구들이 솔라나가 지향하는 바를 명확히 보여준다.
"솔라나의 최초 미션은 인터넷 자본시장의 탈중앙화된 백본을 구축하는 것이었다."
"솔라나에 광신도는 없다. 세계에서 가장 유동성 높은 금융 시장을 지원할 수 있는 플랫폼을 만들고자 하는 실용주의 엔지니어들만 있을 뿐이다."
솔라나는 이념이 아닌 성능, 탈중앙화만을 위한 네트워크가 아닌 시장 인프라로서의 역할을 지향한다. 솔라나의 목표는 전 세계 사용자가 실제로 쓸 수 있는 온체인 자본시장의 백본이 되는 것이다. 검열 저항성, 탈중앙화 같은 가치보다 더 빠른 트랜잭션, 더 낮은 지연, 더 안정적인 거래 체결이 솔라나의 모든 인프라 업데이트 방향이다. 이 글에서 다룰 파이어댄서(Firedancer), 알팬그로우(Alpenglow), 더블제로(DoubleZero), BAM 등의 모든 인프라 혁신이 이를 향해 있다.
그런데 그 방향성에 병목이 되고 있는 것이 있다면, 솔라나의 MEV 구조다.
솔라나의 평균 슬롯 타임은 400ms다. 그런데 대부분의 솔라나 트랜잭션이 거쳐가는 지토(Jito)의 릴레이어(Relayer)는 MEV 번들 경매 기회를 만들기 위해 들어오는 트랜잭션을 최대 200ms 동안 홀드했다. "온체인 나스닥"의 트랜잭션은 슬롯 타임의 절반 동안 MEV 경매가 끝나길 기다리고 있던 것이다. 이 사실을 아는 사람은 많지 않다.
트랜잭션 속도에 대한 문제만이 아니다. 솔라나의 고성능 밸리데이터 클라이언트 파이어댄서는 MEV 추출에 불리하다는 이유로 메인넷 배포를 시작하고도 거의 채택을 받지 못했고, Jito가 공식 통합 가이드를 배포하고 나서야 채택이 늘었다. 그럼에도 2026년 3월 현재 파이어댄서 클라이언트의 스테이크 비율은 약 13.7%에 불과하며, 아직도 솔라나 스테이크의 대부분은 Jito-Agave 클라이언트가 점유하고 있다.
MEV 자체가 나쁘기만 한 것은 아니다. MEV가 프로토콜의 경제적 건전성에 기여하는 측면도 있다. 문제는 그 MEV가 만들어낸 구조가 솔라나의 인프라 발전을 틀어막고, 사용자에게 숨겨진 세금을 부과하며, 생태계의 인센티브를 뒤틀어왔다는 데 있다. 2025년 한 해 솔라나에서 추출된 MEV 수익은 rpcfast.com 집계 기준 7억 2,010만 달러에 달했다. MEV 팁은 솔라나 네트워크 실질 경제가치(REV)의 절반 안팎을 지속적으로 차지하며 Priority Fee를 크게 앞질렀다. MEV는 솔라나라는 온체인 자본시장의 백본의 사용자들, 지금 이 순간에도 스왑 버튼을 누르는 누군가의 주머니에서 나온다.
이 글은 솔라나가 인터넷 자본시장의 백본이 되기 위한 비전을 실현하기 위해 진행 중인 인프라 혁신들을 기술적으로 살펴보고, 솔라나의 MEV 구조가 그 혁신을 어떻게 방해해왔는지, 그리고 생태계가 이 문제를 어떻게 풀어가려 하는지를 다룬다.
솔라나의 성능은 여러 기술 설계의 조합에서 나온다. 이 개념들을 이해하는 것이 이후 인프라 혁신들의 의미를 파악하는 전제가 되기에 간단히 설명한다.
대부분의 블록체인은 트랜잭션이 퍼블릭 멤풀에 대기하다가 블록에 포함된다. 하지만 솔라나에는 트랜잭션의 대기 장소인 퍼블릭 멤플이 없다. 솔라나의 걸프 스트림은 트랜잭션을 퍼블릭 대기열 없이, QUIC 프로토콜을 통해 예정된 다음 리더(leader) 밸리데이터에게 직접 포워딩한다. 솔라나는 매 슬롯마다 다음 수백 개 슬롯의 리더 스케줄을 미리 알 수 있어서, 클라이언트가 트랜잭션을 미래 리더에게 선제적으로 전달할 수 있다.
이러한 방식은 멤풀 혼잡이 없고, 리더가 블록을 즉시 구성할 수 있으며, 메모리 오버헤드가 줄어든다. 단점은 퍼블릭 멤풀이 없기 때문에 일반적인 방식으로는 MEV가 불가능하다는 점이다.
여기에 SWQoS(Stake-Weighted Quality of Service)가 더해진다. 멤풀 없이 트랜잭션을 리더 밸리데이터에 바로 전달하기 때문에, 리더가 된 밸리데이터와 QUIC로 연결되어 있는게 매우 중요하다. 하지만 리더 밸리데이터가 동시에 처리할 수 있는 QUIC 연결 수에는 물리적 한계가 있다. 네트워크 혼잡 시 수많은 노드가 동시에 연결을 시도하면 이 슬롯이 부족해지는데, SWQoS는 제한된 슬롯을 지분 비중에 따라 우선 배분하는 구조다. 더 많은 지분을 보유한 밸리데이터에서 포워딩된 트랜잭션이 우선권을 받고, 지분이 낮은 일반 노드에서 제출한 트랜잭션은 혼잡 시 밀려날 수 있다.
이 메커니즘 자체는 스팸을 억제하고 네트워크 자원을 합리적으로 배분하기 위한 설계다. 하지만 2026년 3월 현재 솔라나 전체 스테이킹의 33%가 18개의 밸리데이터에 집중되어 있다는 점이 중요하다. SWQoS 우선순위는 이 스테이크 집중을 그대로 반영하기 때문에, 사용자나 MEV 서처(Searcher) 입장에서는 트랜잭션을 안정적으로 전달하려면 스테이크가 높은 대형 밸리데이터를 경유해 포워딩하는 것이 유리한 구조가 된다.
Source: solanabeach
이더리움은 트랜잭션을 순차적으로 실행한다. 솔라나의 Sealevel은 서로 다른 계정 상태를 읽고 쓰는 트랜잭션들을 병렬로 실행한다. 트랜잭션이 제출될 때 어떤 계정을 읽고(read), 어떤 계정을 쓰는지(write)를 명시하기 때문에, 런타임이 겹치지 않는 트랜잭션들을 동시에 처리할 수 있다. Sealevel의 병렬 실행은 솔라나가 높은 TPS를 달성하는 핵심 메커니즘이라고 할 수 있다.
블록을 완성한 뒤 전체를 브로드캐스트하면 대역폭 문제가 발생한다. 터빈(**Turbine)**은 블록을 슈레드(**shred)**라는 ~1,200바이트 단위로 쪼개 트리 구조로 전파한다. 리더가 슈레드를 생성하면서 동시에 네트워크에 전파하기 때문에, 블록이 완성되기 전부터 다른 밸리데이터들이 조각을 받아 재조립하기 시작한다. 이 구조가 솔라나의 연속적 블록 생산(streaming block production)을 가능하게 한다. Reed-Solomon 코드를 활용해 전체 슈레드 중 일부가 손실돼도 블록을 복구할 수 있다. 뒤에 소개할 Alpenglow 업그레이드의 Rotor는 이 터빈을 대체하는 새로운 브로드캐스트 레이어다.
솔라나의 현재 합의는 두 레이어로 구성된다.
일반적으로 솔라나의 합의 알고리즘으로 알고 있는 Proof-of-History(PoH) 는 합의 알고리즘이 아니라 암호학적 시계다. SHA-256 해시를 연속적으로 계산해 시간의 흐름을 증명하는 것이다. 이를 통해 밸리데이터들이 글로벌 시계에 대한 합의를 건너 뛰고도 트랜잭션의 순서를 검증할 수 있게 해준다. 이것이 솔라나가 빠른 블록 타임을 가능하게 하는 핵심 설계다.
Tower BFT는 PoH를 활용한 BFT(Byzantine Fault Tolerance) 합의다. 밸리데이터들이 매 슬롯마다 온체인 투표 트랜잭션을 보내야 한다. 이 투표들이 누적되어 블록 최종성(finality)을 결정한다. 문제는 이 밸리데이터들의 온체인 투표가 평시 솔라나 전체 트랜잭션의 약 75%를 차지한다는 것이다. 사용자 트랜잭션이 들어갈 수 있는 블록스페이스의 상당 부분이 합의 유지를 위한 내부 트래픽에 소비된다. 현재 솔라나의 최종성 시간은 약 12.8초다.
파이어댄서(Firedancer)는 Jump Crypto가 2022년부터 3년에 걸쳐 개발한 솔라나의 두 번째 완전 독립 밸리데이터 클라이언트다. 기존 Agave가 Rust로 작성된 것과 달리, 파이어댄서는 C/C++ 로 처음부터 재작성됐다.
핵심 아키텍처는 타일(tile) 기반 모듈화 파이프라인이다. 네트워킹, 서명 검증(sig verify), 블록 생산(pack), 실행 등 각 기능이 독립적인 타일로 분리되어 전용 CPU 코어에 핀닝되고, 공유 메모리 큐(shared-memory queue)를 통해 통신한다. 타일 간 데이터 전달에 시스템 콜이 필요 없어 컨텍스트 스위칭 오버헤드가 거의 없게끔 설계되었다. 또한 각 타일이 샌드박스로 격리되어 하나가 크래시 되더라도 전체 프로세스가 다운되지 않는 모듈화된 고가용성을 갖는다.
파이어댄서를 사용했을 때 솔라나 네트워크의 성능은 큰 수준으로 향상된다. 단일 코어 fd_quic 벤치마크에서 140만 TPS, 제어 환경 클러스터에서 100만 TPS 이상을 기록했다. 현재 솔라나 메인넷 처리량을 수십 배 상회하는 수치다.
클라이언트 다양성이라는 측면에서 파이어댄서의 의미는 더 크다. 솔라나는 5년간 7번의 네트워크 장애를 겪었고, 그 중 5번이 클라이언트 버그에서 비롯됐다. 2022년 6월 장애는 durable-nonce 트랜잭션 버그 하나가 4.5시간 네트워크 중단을 초래했다. Jito-Agave 클라이언트가 스테이크의 대부분을 독점하는 상황에서, Agave 버그 하나가 네트워크 전체를 멈출 수 있다. 파이어댄서는 C/C++ 기반 독립 코드베이스로, Agave의 버그가 전파되지 않는 완전히 다른 장애 도메인을 형성한다.
파이어댄서의 현황을 살펴보자. 2024년 9월 Frankendancer(파이어댄서 네트워킹 + Agave 합의 하이브리드)가 메인넷에 출시됐고, 2025년 12월 Agave 의존성을 완전히 제거한 완전한 파이어댄서가 메인넷 배포를 시작했다. 2026년 3월 현재 파이어댄서 클라이언트를 사용하는 밸리데이터들의 스테이크 비율은 약 12.7%이며, 이들은 모두 지토를 함께 실행한다. 아직까지도 83.8%의 솔라나 스테이크는 파이어댄서를 채택하지 않고 Agave에 의존하고 있다.
Source: reports.firedancer.io
알팬그로우(SIMD-0326) 는 솔라나 역사상 가장 큰 프로토콜 업그레이드다. 2025년 9월 커뮤니티 거버넌스 투표에서 98.27%의 찬성(스테이크 52% 참여)으로 통과됐다. Anza의 리드 이코노미스트 Max Resnick은 이를 "솔라나 역사상 가장 중요한 프로토콜 재작성"이라고 표현했다.
2.2.1 Votor
솔라나의 새로운 블록 최종성 엔진이다. 기존 Tower BFT에서는 밸리데이터들이 매 슬롯마다 온체인 투표 트랜잭션을 발행한다. 앞서 이야기한 것처럼 솔라나 평시 트랜잭션의 약 75%가 이 내부 투표다. Votor는 이 투표를 오프체인으로 이동시킨다.
밸리데이터들은 BLS12-381 서명으로 오프체인에서 직접 투표를 교환한다. 리더가 충분한 표를 수집하면 수백, 수천 개의 서명을 하나의 압축된 집계 서명(aggregate signature)으로 묶어 "최종성 인증서(finality certificate)"를 생성하고, 이것만 온체인에 게시한다. 수백 개의 개별 투표 트랜잭션이 오프체인에서 모아져 인증서 하나로 압축되는 구조다.
최종성 달성 조건은 두 가지다. 스테이크의 80% 이상이 참여하면 단일 라운드(fast-finalization), 60% 이상이면 두 라운드(slow-finalization)만에 블록이 최종 확정된다. 목표 최종성 시간은 100~150ms로, 현재 ~12.8초 대비 약 100배 단축된다. 보안 수준은 SHA256 해싱과 BLS12-381 서명 집계를 조합해 128비트 보안을 달성한다.
내결함성도 강화된다. Votor는 "20+20" 모델을 채택한다. 악의적 노드 20%와 비응답 노드 20%가 동시에 존재해도 네트워크가 계속 작동할 수 있는 설계다. 현재 Tower BFT보다 훨씬 강한 내결함성이다.
경제 모델도 바뀐다. 오프체인 투표로 전환되면 기존 투표 수수료가 사라지는데, 이를 대체하기 위해 VAT(Validator Admission Ticket) 이 도입된다. 밸리데이터는 에포크 시작 전 1.6 SOL을 선납하고 이는 전액 소각된다. 현재 투표 비용(하루 최대 1.1 SOL)의 약 80% 수준이다.
2.2.2 Rotor
Rotor는 솔라나 블록 전파 레이어의 재설계로, 기존 터빈을 대체한다. 핵심 설계 인사이트는 "블록 전파의 병목은 대역폭이 아니라 네트워크 레이턴시"라는 것이다. 이 인사이트를 바탕으로 터빈의 다층 트리 구조를 단일 홉(single-hop) 릴레이 모델로 전환한다.
솔라나의 기존 블록 전파 구조인 터빈은 fanout 200의 다층 트리 구조로 슈레드를 전파한다. 블록이 리더 → 1차 노드들 → 2차 노드들로 여러 홉을 거치며 전달된다. Rotor는 이를 단순화한다. 리더가 블록을 erasure-coded 슈레드로 분할한 뒤, 각 슈레드를 스테이크 가중 릴레이 노드에 직접 전송한다. 릴레이 노드는 받은 슈레드를 전체 네트워크에 브로드캐스트한다. 대부분의 밸리데이터가 릴레이로부터 단 한 번의 네트워크 홉으로 필요한 블록 데이터를 수신한다.
터빈과의 또 다른 차이점이 있다. 터빈은 데이터 슈레드와 복구 슈레드를 별도로 전송하는 반면, Rotor는 단일 erasure-coded 버전만 전송한다. 데이터 중복을 줄이면서도 동일한 수준의 복구 가능성을 유지한다. 각 슈레드의 무결성은 리더가 슈레드 해시의 머클(Merkle) 트리를 생성하고 루트에 서명하는 방식으로 보장된다. 각 슈레드에는 자신의 머클 경로가 포함되어 있어 수신 노드가 즉시 진위를 검증할 수 있다.
Rotor를 통한 블록 전파의 경우 1Gb/s 대역폭 기준으로 1,500개 슈레드 전송에 약 18ms, 전체 스테이크의 80%에 도달하는 데 약 2ms가 소요된다. 이 수준에서는 프로토콜 오버헤드가 아닌 빛의 속도, 즉 물리적 거리에 의한 네트워크 레이턴시 자체가 병목이 된다. 또한 Rotor는 더블제로의 멀티캐스트 시스템과 네이티브 호환되도록 설계됐다.
다만 우려도 있다. 릴레이 노드를 스테이크 가중으로 결정적으로 선택하는 구조는 대형 밸리데이터에게 지속적으로 대역폭 효율적인 역할을 부여해 장기적으로 경제적 우위를 강화할 수 있다는 지적이 있다. MIT 교수 Muriel Médard는 Rotor가 활용하는 Reed-Solomon 코드가 "1950~60년대에 다른 목적으로 설계된 것"으로 Web2 네트워크의 비결정적 지연에 취약할 수 있다고도 지적했다.
원래 Rotor도 알팬그로우에 포함될 예정이었으나 제외된 것으로 확인된다. 공식 문서에 "Initially we stay with Turbine as the data dissemination protocol. Rotor will be introduced later and will get its own SIMD"라고 명시되어 있다. 즉 알팬그로우 v1에서는 Votor만 도입되고, 데이터 전파는 당분간 기존 터빈을 유지한다. Rotor는 별도 SIMD를 통해 추후 제안될 예정이다.
밸리데이터들은 일반적으로 공공 인터넷 위에서 통신한다. 공공 인터넷은 범용으로 설계되어 있어 패킷 손실, 지터(jitter), 예측 불가능한 지연이 발생한다. 솔라나의 합의처럼 수천 개의 노드가 수백 밀리세컨드 단위로 동기화해야 하는 워크로드에는 근본적으로 맞지 않는 인프라다.
더블제로는 이 문제에 대한 해결책이다. Solana Foundation 전략 책임자 출신 Austin Federa가 공동창업한 이 프로젝트는, Jump Crypto, Galaxy, RockawayX 등 기관들이 보유한 미사용 전용 광섬유 대역폭을 모아 블록체인 전용 사설망을 구축한다. 밸리데이터들은 공공 인터넷 대신 더블제로의 직접 연결 경로를 통해 슈레드와 합의 메시지를 주고받는다.
ICM 로드맵도 더블제로를 명시적으로 중기 과제로 포함시켰다. 로드맵이 강조하는 "라우팅 레이턴시 최대 100ms 감소, 대역폭 10배 확장"이 더블제로의 공식 목표치다.
더블제로는 2025년 10월 2일 메인넷 베타를 출시했다. 코인데스크(CoinDesk) 보도에 따르면 출시 시점 솔라나 스테이크의 약 22%, 300개 이상 밸리데이터가 연결됐으며, 70개 이상의 고성능 광섬유 링크를 통해 25개 글로벌 거점을 연결했다.
주목할 점은 더블제로가 지리적 탈중앙화를 명시적 목표로 내걸었다는 것이다. 솔라나의 목표가 전 세계 어떤 지역에서도 지연 없이 인터넷 자본시장을 사용할수 있게끔 하는 것이기에, 다른건 몰라도 지리적 탈중앙화만큼은 솔라나에게도 중요하다. 2026년 3월 9일부터 "Phase II 위임 프로그램"을 시작하며 상파울루, 싱가포르, 홍콩, 도쿄 등 소외 지역 밸리데이터들에게 총 240만 SOL을 추가 위임한다.
BAM(Block Assembly Marketplace) 는 2025년 7월 공개되고 9월 early 메인넷이 시작된 지토의 차세대 블록 조립 시스템으로, ICM 로드맵이 "단기 솔루션"으로 명시했다.
BAM은 솔라나 MEV에서 샌드위치 공격 문제를 구조적으로 해결하려는 시도다. 기존 지토 Block Engine은 지토가 중앙에서 운영하는 오프체인 경매 시스템으로, 트랜잭션 내용이 외부에 노출될 수 있는 구조였다. BAM은 이를 TEE(Trusted Execution Environment) 하드웨어를 실행하는 분산 노드 네트워크로 대체한다. 각 BAM 노드는 TEE 안에서 트랜잭션을 암호화된 상태로 시퀀싱하기 때문에, 리더 밸리데이터조차 실행 전까지 트랜잭션 내용을 볼 수 없다. BAM 노드는 모든 시퀀싱 결정에 암호학적 증명(cryptographic attestation)을 생성하므로, 밸리데이터가 순서를 임의로 변경하면 네트워크 전체가 즉시 감지할 수 있다. 사용자 트랜잭션에 피해를 주는 공격성 MEV를 기존보다 훨씬 어렵게 만드는 것이다.
BAM의 또 다른 혁신은 ACE(Application-Controlled Execution) 플러그인이다. 앱 개발자가 자신의 프로토콜 내 트랜잭션 정렬 규칙을 직접 정의할 수 있다. 오라클 업데이트가 트레이드보다 먼저 실행되도록 하거나, 청산이 마켓 오더보다 우선하거나, LP에게 배치 내 우선 접근권을 주는 등의 로직을 플러그인으로 구현할 수 있다. Drift, Pyth, Dflow 등이 이미 플러그인을 개발 중이다. ACE는 온체인 CLOB이 중앙화 거래소와 경쟁할 수 있는 실행 환경의 기반이 될 것이다.
2026년 3월 기준 약 28.7%의 스테이크가 JitoBAM을 실행 중이다. 다만 BAM은 여전히 지토가 핵심 인프라를 운영하는 중앙화된 시스템이다. 후술하겠지만 솔라나 인프라에서 지토에 대한 의존도가 과하게 증가하는 것은 그리 바람직하지 못하다.
이더리움에서 MEV는 직관적이다. 트랜잭션이 퍼블릭 멤풀에 브로드캐스트되고, 봇들이 이 정보를 보고 앞뒤에 끼워 넣거나 순서를 바꿔 이익을 취한다. 그러나 솔라나에는 인프로토콜 멤풀(in-protocol mempool)이 존재하지 않는다. 트랜잭션은 공개 대기열에 쌓이는 대신, QUIC 프로토콜을 통해 현재 리더 밸리데이터에게 직접 전달된다. 이 구조만 보면 MEV가 사실상 불가능할 것 같지만, 솔라나에서 MEV는 매우 활발하게 이루어지고 있다.
멤풀이 없어도 트랜잭션 정렬에 대한 경쟁은 치열했다. 멤풀이 존재하지 않기에 솔라나의 실행 순서는 리더가 트랜잭션을 받는 순서가 결정적인 영향을 끼친다. MEV 봇들은 이를 이용해 동일한 차익거래 트랜잭션을 수백, 수천 번 반복 전송하는 레이턴시 전쟁(latency war)을 벌였다.
지토 랩스의 연구에 따르면 지토 도입 이전, 솔라나의 블록 컴퓨트 유닛의 60% 이상이 차익거래 봇 트랜잭션에 소비되었으며, 심지어 그 차익거래 시도의 98%는 실패했다. 즉, 스팸 트랜잭션이 네트워크를 지배하고 있던 것이다. 정상 유저의 트랜잭션은 밀리고, 거래 체결은 매우 불안정했다. 이는 솔라나가 지향하는 빠르고 신뢰할 수 있는 온체인 자본시장과는 거리가 먼 현실이었다.
지토는 이 문제를 해결하기 위해 2022년 Jito-Solana 클라이언트를 출시했다. 솔라나 재단의 기존 Agave 클라이언트를 포크해, MEV 경매 시스템을 오프프로토콜로 탑재한 버전이다.
번들(Bundle)은 최대 5개의 트랜잭션을 묶은 원자적(atomic) 실행 단위다. 이는 All-or-nothing이다. 번들 중 하나라도 실패하면 전체가 롤백된다. 서처는 번들에 팁(최소 1,000 lamports, 인프로토콜 수수료와 별개)을 첨부해 블록 엔진에 제출하고, 블록 엔진은 경매를 통해 최고 팁 번들을 리더에게 전달한다.
지토로 인해 98% 실패율의 스팸이 단일 경매로 정리되면서, 네트워크에 낭비되던 컴퓨팅 자원이 대폭 감소했다. 하지만 지토로 인해 새로운 문제가 등장했다. MEV 추출을 위해서 트랜잭션이 실행되기 전에 지토의 오프체인 인프라를 반드시 경유해야 하는 구조가 만들어진 것이다.
성능을 위해 멤풀이 존재하지 않던 솔라나에 지토로 인해 프라이빗 멤풀이 생기고, 트랜잭션이 블록에 포함되지 않을 가능성이 증가한다. 서처가 트랜잭션을 포함한 번들을 제출하더라도 경매에서 더 높은 Tip 번들에 밀리면 탈락하고, 다수에 승인받지 못한 uncled block이 발생하면 번들의 원자성이 깨진 채 개별 트랜잭션이 재브로드캐스트 되기도 한다. 이는 솔라나를 써본 사람이라면 한 번쯤 경험했을 분명히 보냈는데 트랜잭션이 누락되는 현상의 구조적 배경이다.
앞서 이야기한 것과 같이 솔라나의 평균 슬롯 타임은 400ms다. 그런데 Jito-Solana 클라이언트의 릴레이어는 들어오는 트랜잭션을 리더로 선정된 밸리데이터에게 바로 전달하지 않는다. 지토 릴레이어는 블록엔진 옥션타임으로 트랜잭션을 최대 50ms 홀드한다. (2025년 6월까지 이 값은 200ms였다.) MEV 번들 경매 기회를 만들기 위해서다.
Jito-Solana 클라이언트를 사용하는 밸리데이터에 도달하는 모든 트랜잭션이 이 릴레이어를 통과한다. 즉, 솔라나가 자랑하는 400ms 슬롯 타임의 절반이 구조적으로 MEV 경매 윈도우로 쓰이고 있었던 셈이다.
Jito-Solana 클라이언트가 한때 지분의 약 87%를 점유했던 시기(2025년 중반)를 기준으로 하면, 사실상 솔라나 블록의 대부분이 이 지연 구조 위에서 생산된 것이다. "0.4초 블록체인"의 실제 사용자의 체감 레이턴시는 이 200ms 오버헤드를 포함하고 있었다. 네트워크의 추가 수익을 위해 사용자 트랜잭션을 대기시킨다는 것 자체가 솔라나가 목표로 하는 바와 방향부터 맞지 않다.
솔라나의 밸리데이터들이 지토를를 선택하는 이유는 단순하다. 지토의 서처들로부터 받는 MEV 팁이 의미 있는 추가 수익을 제공하기 때문이다. Blockworks Research에 따르면 2025년 1월 기준 밸리데이터 수익에서 지토 팁의 비중은 무려 30%였다. 지토를 쓰지 않으면 경쟁자보다 낮은 APY를 제공하게 되고, 위임 경쟁에서 불리하게 작용하는 것이다. 개별 밸리데이터 입장에서는 합리적 선택이라고 할수 있지만, 생태계 전체로 보면 단일 인프라에 대한 경제적 종속이라고 할 수 있다.
지토의 블록 엔진은 사실상 솔라나 트랜잭션 처리의 핵심 경로가 됐다. 이 시스템이 장애를 일으키면, MEV 흐름이 마비된다.
지토는 2026년 3월 현재 글로벌 8개 블록 엔진 노드를 운영 중이다. 유럽에 4개(암스테르담, 더블린, 프랑크푸르트, 런던), 북미에 2개(뉴욕, 솔트레이크시티), 아시아에 2개(싱가포르 도쿄) 노드로 남미, 아프리카, 오세아니아 지역은 존재하지 않는다.
Source: JITO docs
MEV를 최대화하려는 밸리데이터는 블록 엔진과의 레이턴시를 줄이기 위해 유럽/북미에 코로케이션할 인센티브를 갖는다. 남미, 아프리카, 오세아니아 지역은 아예 블록 엔진 노드 자체가 없다. 해당 지역의 서처는 번들 경매에서 구조적으로 불리하고, 밸리데이터는 고가 번들 수신이 지연되어 MEV 팁 수익이 줄어들며, 일반 사용자도 트랜잭션 체결 속도와 안정성이 낮아진다. "전 세계 자본시장의 백본"을 표방하는 체인치고는 지리적 격차가 크다.
ICM 로드맵 자체는 지리적 탈중앙화를 핵심 가치로 명시한다. 도쿄에서 발생한 시장 정보를 뉴욕보다 빠르게 체인에 반영하려면 전세계 분산 밸리데이터가 필요하다고 설명한다. 솔라나의 MEV 인센티브 구조는 지토의 블록엔진 노드의 위치에 지나치게 의존적이다. 지토에 대한 의존도를 프로토콜 차원에서 줄이거나 지토 블록 엔진의 지리적 분산을 강화하는 등의 해결이 필요하다.
MEV가 솔라나 인프라 발전을 직접 방해한 가장 구체적인 사례가 파이어댄서다.
2024년 9월 프랭큰댄서가 메인넷에 출시됐을 때, 겨우 12개 밸리데이터만 프랭큰댄서를 사용했다. 전체 스테이크 392M SOL 중 5.4M SOL에 불과한 수치다. Temporal의 엔지니어링 파트너 Ben Coverston은 그 이유에 대해 "프랭큰댄서가 MEV를 효율적으로 캡처하지 못하기 때문이다." 라고 설명했다.
프랭큰댄서는 지토 블록 엔진과의 통합이 구현되지 않은 상태로 출시됐다. 밸리데이터 입장에서 전환한다는 것은 네트워크 성능과 탈중앙화를 위해 수익을 희생하는 것이었다. 이후 지토에서 공식 파이어댄서 통합 가이드를 배포하면서 채택은 급격히 늘었다. 솔라나의 트랜잭션이 지토로 인해 대기하는 것을 넘어, 인프라를 개선하는 것에 있어서도 지토의 영향 아래에 놓여있는 것이다.
지토의 솔라나 블록 스페이스 독점은 2025년 말부터 하모닉(Harmonic)이 등장하며 조금씩 깨지고 있다. 하모닉은 지토로 중앙화된 블록 엔진에 대한 대안으로 등장한 솔라나의 오픈 블록 빌딩 마켓플레이스다. 2025년 11월 패러다임(Paradigm) 리드로 $6M 시드 펀딩을 받고 런칭했으며, 여러 독립 빌더들이 경쟁적으로 블록 후보를 제출하고 밸리데이터가 가장 수익성 높은 블록을 선택하는 구조다. 이더리움의 PBS구조와도 유사하다.
"블록 빌딩은 블랙박스가 되어서는 안 된다"는 것이 하모닉의 핵심 메시지다. 2026년 3월 현재 하모닉을 사용하는 클라이언트는 이미 스테이크의 16.9%까지 차지하고 있다. 재밌는 점은 하모닉의 공동창업자는 Ben Coverston로, 솔라나에서 파이어댄서 채택이 저조했던 이유에 대해 "MEV를 효율적으로 캡처하지 못하기 때문"이라고 설명했던 바로 그 인물이다.
라쿠라이(Rakurai) 역시 주목할 만한 대안이다. Agave 포크 기반의 고성능 밸리데이터 클라이언트로, 트랜잭션 스케줄링 최적화를 통해 블록을 더 효율적으로 채워 밸리데이터 수익을 높이는 것이 핵심이다. 하모닉이 "블록 빌딩의 경쟁 시장 도입"이라면, 라쿠라이는 "더 빠르고 효율적인 블록 빌더"다. 2026년 3월 피그먼트(Figment)가 주요 밸리데이터를 라쿠라이로 마이그레이션한 후 지토 MEV 팁 캡처가 5배 증가했다는 데이터를 발표하기도 했다.
지토가 독점하고 있던 솔라나의 블록 스페이스 시장에 의미 있는 대안들이 등장하고 있는 것이다.
ICM 로드맵이 가장 야심차게 제시하는 것은 MCL(Multiple Concurrent Leaders) 과 프로토콜 레벨 ACE다.
현재 솔라나는 단일 리더(single leader) 모델이다. 해당 슬롯에 리더가 된 밸리데이터가 트랜잭션 포함 여부와 순서를 독점한다. MEV는 본질적으로 이 권한을 남용하는 것이다.
MCL은 하나의 슬롯에 여러 리더가 동시에 블록을 생산하게 하는 설계다. 한 리더가 특정 트랜잭션을 검열하거나 순서를 조작하려 해도, 다른 리더가 이를 포함시킬 수 있다. MEV의 구조적 근거를 프로토콜 레벨에서 제거하는 접근이다. ICM 로드맵은 MCL이 단순히 MEV를 줄이는 것 이상의 의미를 갖는다고 강조한다. 전세계 여러 리더가 동시에 정보를 받는 구조는 지리적 분산 목표와도 정확히 일치한다.
솔라나의 ICM이 지향하는 바는, 전세계 어디에서도 빠른 거래가 가능한 네트워크를 만드는 것이다. 지역별로 리더가 존재한다면 도쿄의 시장 이벤트가 뉴욕의 리더보다 도쿄의 리더에게 먼저 도달해 블록에 포함될 수 있는 것이다. 지역적 요인에 따른 불평등을 해소할 수 있는 로드맵이다.
프로토콜 레벨 ACE는 앱이 온체인에서 자신의 트랜잭션 순서를 직접 제어할 수 있게 하는 설계다. BAM의 ACE가 오프체인 TEE 기반인 것과 달리, 프로토콜 레벨 ACE는 밸리데이터 협력에 의존하지 않고 프로토콜 자체가 앱의 순서 규칙을 강제한다.
프로토콜 레벨의 ACE가 왜 중요한지는 2025년 5월 로빈후드(Robinhood)의 선택이 잘 보여준다. 당시 로빈후드는 EU 토크나이즈드 주식 거래 플랫폼의 베이스 레이어로 솔라나와 아비트럼(Arbitrum) Orbit을 기반으로 이더리움 L2를 만드는 것을 고민했다. 최종 선택은 아비트럼 기반의 자체 커스텀 L2였다. 그 이유 중 하나가 트랜잭션 시퀀싱에 대한 세밀한 제어와 인프라 수준의 커스터마이징이었는데, 프로토콜 레벨 ACE가 아직 준비되지 않은 솔라나는 이 요구사항을 충족할 수 없었던 것이다. 결국 로빈후드는 프로토콜 레벨에서 시퀀싱을 커스터마이징할 수 있는 L2를 선택한 것이다.
ACE는 단순한 성능 업그레이드가 아니라, 솔라나가 기관급 금융 애플리케이션을 수용하기 위한 필수 업그레이드라고 할 수 있다.
APE(Asynchronous Program Execution) 는 솔라나의 구조적 병목을 가장 근본적인 수준에서 해결하려는 설계다. APE 관련 SIMD들이 제출되어 있고(SIMDs 192, 290, 297, 298, 301), 알팬그로우 이후 구현 복잡도가 낮아질 것이라는 기대가 있다.
현재 솔라나에서 트랜잭션이 블록에 포함되려면 실행(execution)이 완료되어야 한다. 합의와 실행이 같은 크리티컬 패스 위에 있다는 뜻이다. APE는 이 둘을 분리한다.
핵심 개념은 실행 도메인 의 분리다. APE는 솔라나의 프로그램 실행을 두 개의 독립적인 도메인으로 나눈다. VED(Vote Execution Domain)는 합의 투표와 관련된 프로그램만 처리하고, UED(User Execution Domain)는 일반 사용자 트랜잭션을 처리한다. 두 도메인은 서로의 계정 상태를 읽거나 쓸 수 없다.
이 분리가 가능해지면 밸리데이터는 사용자 프로그램 실행이 완료되기 전에 투표를 먼저 진행할 수 있다. 트랜잭션 포함 레이턴시가 줄어들고, 합의가 실행 병목에 묶이지 않는다. 알팬그로우의 150ms 최종성과 결합하면 실질적인 체감 속도는 더 크게 개선된다.
솔라나의 인프라 발전 관정을 보면 하나의 공통적인 패턴을 확인할 수 있다. 기술적으로 올바른 방향이 있어도, 그 방향으로 가는 것을 틀어막는 경제적 인센티브가 있다는 것이다. 그중 대표적인 것이 MEV다. 솔라나 ICM 로드맵은 결국 온체인 자본시장의 핵심 문제가 단순 TPS가 아니라, 주문이 어떤 순서와 규칙으로 체결되는지에 관한 시장의 마이크로스트럭처라는 점을 인정하고 있다.
솔라나는 블록체인의 이념적 가치보다는 기술 그 자체를 활용해 비(非) 블록체인 시스템보다도 더 나은 인프라를 만들고자 한다. 단순히 가장 빠른 블록체인이 아니라 자본 시장을 위한 가장 빠른 거래 네트워크를 만드는 것이다. 이를 위해 솔라나가 준비하는 로드맵과 기술적 해법의 방향은 적절하다. 하지만 이 로드맵의 도입 과정에서 생태계의 인센티브를 재정렬하지 못한다면 문제는 다른 형태로 등장할 것이다.
솔라나는 지난 밈코인 열풍을 주도했다. 나는 이 밈코인 열풍이 우연히 얻어걸린 내러티브가 아닐 것이라 생각한다. 솔라나는 이를 통해 엄청난 거래 트래픽을 감당할 수 있는 네트워크임을 숫자로서 검증해냈다.
하지만 솔라나가 진정한 온체인 나스닥이 되려면, 나스닥이 수십 년에 걸쳐 구축한 것을 프로토콜 레벨에서 해결해야 한다. “솔라나에 광신도는 없다. 실용주의 엔지니어들만 있을 뿐”이라는 것은 강점이자 동시에 약점이다. 이념 없는 실용주의는 빠른 실행을 가능하게 하지만, 단기 수익 인센티브 앞에 장기적인 설계 원칙은 쉽게 타협되기 때문이다. 인센티브를 추구하는 것이 나쁘다는 것이 아니다. 인프라가 나아가는 방향과 인센티브의 방향을 일치시켜야 한다는 것이다.
Solana
Ethereum
