Solana의 Gulf Stream: 멤풀 많으면 문제도 많다

핵심 인사이트

• "Gulf Stream"은 노드가 네트워크에서 트랜잭션을 포착한 순간부터 현재 슬롯의 리더에게 도달해 TPU(Transaction Processing Unit)의 Fetch Stage에서 수신될 때까지 진행되는 과정으로 넓게 정의할 수 있습니다.
• Solana는 처음부터 멤풀 없이 작동하도록 설계되었다는 점에서 차별화됩니다. 가십 프로토콜을 사용해 트랜잭션을 네트워크 전체에 광범위하게 전파하는 기존 블록체인과 달리, Solana는 각 슬롯의 모든 트랜잭션을 리더라고 하는 사전 지정된 주 검증인에게 전달합니다. 리더는 4슬롯마다 교체되며, 모든 활성 네트워크 노드는 리더 스케줄을 미리 알고 있어 트랜잭션을 효율적으로 전달할 수 있습니다.
• 기본적으로 Solana 트랜잭션에는 최근 블록해시가 포함되어야 하며, 개발자는 간단한 API 호출로 이를 쉽게 요청할 수 있습니다. 최근 블록해시는 최대 150슬롯, 약 1분 동안 유효합니다. 이 시간이 지나면 오래된 상태가 되며, 이를 참조하는 트랜잭션은 네트워크에서 폐기됩니다. 따라서 처리되지 않은 트랜잭션이 계속 남아 있을 수 없습니다. 최근 블록해시는 트랜잭션 중복 제거에도 도움이 됩니다. 개발자가 내구성 있는 논스를 추가하는 방법도 있습니다.
• Gulf Stream의 트랜잭션은 인코딩된 후 QUIC 스트림을 통해 리더에게 전송됩니다. 2022년 말 QUIC 도입은 이전에 사용하던 UDP 연결을 대체한 중요한 네트워크 업그레이드였습니다. 변경의 주된 목적은 네트워크의 스팸 필터링 역량을 높이는 것이었습니다. 하지만 Solana의 활동량이 2024년 내내 전례 없는 수준에 이르면서 QUIC 전환을 둘러싼 논쟁도 이어졌습니다.
• 2024년 초 스테이크 가중 서비스 품질(SWQoS)이 도입되면서 트랜잭션이 Gulf Stream을 통해 리더에게 도달하는 방식이 크게 바뀌었습니다. 이제 리더는 스테이킹된 다른 검증인을 경유한 트랜잭션 메시지를 우선 처리합니다. 구체적으로 리더 용량의 80%(연결 2,000개)는 스테이킹된 피어에 할당되고, 나머지 20%(연결 500개)는 스테이킹되지 않은 노드의 트랜잭션 메시지에 할당됩니다.
• 현재 Solana 스테이크의 80% 이상은 기존 Agave 클라이언트 대신 Jito-Solana 클라이언트를 실행하는 검증인에 예치되어 있습니다. Jito는 프로토콜 외부 블록 공간 경매를 도입해 트랜잭션이 리더에게 도달하는 과정을 더 복잡하게 만듭니다. 특히 Jito 릴레이어는 유입되는 트랜잭션 메시지의 흐름을 늦추는 200밀리초의 “과속 방지턱”을 추가해 검색자가 번들을 제출할 충분한 시간을 확보합니다.

소개

"Gulf Stream"이라는 용어는 Solana 창립 팀이 2019년에 작성한 일련의 입문용 블로그 게시물에서 유래했습니다. 이들은 Solana의 여러 혁신적 메커니즘에 항공을 주제로 한 이름을 붙였습니다. 해당 게시물에서 Gulf Stream은 Solana의 “멤풀 없는 트랜잭션 전달 프로토콜”로 정의되었습니다. 하지만 현재 Solana 코드베이스에서 “Gulf Stream”을 검색하면 중요하지 않은 언급 하나만 나옵니다.

Solana 트랜잭션 수명 주기라는 더 넓은 맥락에서 “Gulf Stream”은 트랜잭션이 네트워크 노드, 일반적으로 RPC에 포착된 순간부터 현재 슬롯의 리더에게 도달할 때까지 진행되는 전체 과정으로 이해할 수 있습니다. 즉, TPU의 “Fetch Stage”에서 포착될 때까지입니다. Gulf Stream은 Solana의 블록 전파 메커니즘인 Turbine의 반대 모습으로도 볼 수 있습니다. Gulf Stream은 트랜잭션이 리더에게 도달하는 방식이고, Turbine은 처리된 트랜잭션이 리더를 떠나는 방식이기 때문입니다.

먼저 Solana 맥락에서 RPC(Remote Procedure Call) 노드를 정의하면 유용합니다. 이 노드는 네트워크와 상호작용하고 데이터를 읽는 게이트웨이로 볼 수 있습니다. 사용자와 Solana 검증인 사이에서 중개자 역할을 합니다. RPC는 전체 검증인과 동일한 소프트웨어를 실행하지만 설정이 다릅니다. 따라서 트랜잭션을 정확히 시뮬레이션하고 현재 상태, 즉 뱅크에 대한 최신 뷰를 유지할 수 있습니다. 하지만 RPC 노드는 스테이킹되지 않으므로 합의에 참여하지 않습니다. 스테이크가 없기 때문에 투표하거나 블록을 생성할 수 없습니다. 이는 일반적으로 검증인과 RPC 노드가 동일한 다른 여러 블록체인과 차이가 있습니다. Gulf Stream에서 RPC의 역할은 HTTP로 트랜잭션을 수신하고, 트랜잭션을 QUIC으로 변환하며, 리더 스케줄을 사용해 현재 리더의 주소와 포트 정보를 조회한 뒤, 트랜잭션을 현재 리더와 다음 리더에게 전달하는 것으로 요약할 수 있습니다. QUIC은 뒤에서 더 자세히 설명합니다.

네트워크가 시작된 후 Gulf Stream은 QUIC과 스테이크 가중 QoS라는 두 차례 이상의 주요 업그레이드를 거쳤습니다. 이 글의 뒤에서 자세히 살펴보겠습니다. 또한 Gulf Stream은 최근 몇 년간 Solana의 전례 없는 네트워크 트래픽으로 인해 코어 프로토콜에서 가장 큰 부담을 받은 부분이라고 할 수 있습니다. 상황을 설명하자면 검증인이 리더가 될 때 전체 네트워크가 패킷을 해당 검증인에게 보내므로 유입 트래픽이 급증해 초당 1기가바이트를 넘을 수 있습니다. 이처럼 방대한 데이터 유입량을 처리하는 일은 매우 어려운 엔지니어링 과제입니다.

멤풀 많으면 문제도 많다

창립 팀이 처음 정의한 Gulf Stream은 멤풀이 없다는 점을 강조합니다. 멤풀은 문자 그대로 “메모리 풀”이며, 사용자가 제출한 후 네트워크에서 처리되기를 기다리는 트랜잭션의 집합으로 정의할 수 있습니다. 이러한 트랜잭션은 공개된 상태로 대기할 때 일반적으로 암호화되거나 보호되지 않습니다. 가십 프로토콜을 통해 네트워크 전체에 전파됩니다. 네트워크에 따라 서명된 트랜잭션은 실행 조건이 충족될 때까지 멤풀에 무기한 남아 있을 수 있습니다. 특히 트랜잭션 수수료, 즉 컴퓨팅 단위당 가격을 일반적인 시장 가격 범위보다 훨씬 낮게 설정한 경우가 그렇습니다. 극단적인 경우 네트워크 상황상 블록에 포함되기 어렵다면 이러한 트랜잭션이 실행되는 데 며칠 또는 몇 주가 걸릴 수 있습니다.

Solana에서는 이런 상황이 발생할 수 없습니다. 멤풀이라는 기본 개념이 없을 뿐만 아니라 모든 트랜잭션 메시지에 최근 블록해시를 포함해야 하기 때문입니다. 개발자는 getLatestBlockhash 메서드에 JSON RPC API 호출을 보내 최근 블록해시를 쉽게 요청할 수 있습니다. 이 블록해시는 트랜잭션 메시지에 삽입되며, 최대 150슬롯 동안 유효합니다. 각 슬롯의 목표 시간이 400밀리초라는 점을 고려하면 약 1분입니다. 150슬롯이 지나면 블록해시는 오래된 상태가 되고, 이를 참조하는 트랜잭션은 네트워크에서 폐기됩니다. 기본적으로 RPC는 2초마다 트랜잭션 전달을 시도하지만, 최근 블록해시가 만료되면 트랜잭션이 폐기되므로 온체인에서 절대 실행되지 않습니다.

최근 블록해시는 중복 트랜잭션을 감지하고 제거하는 수단이기도 합니다. 다른 네트워크에서는 논스, 즉 한 번만 사용하는 숫자를 반드시 포함하도록 해 이를 구현합니다. 개발자가 특정한 일부 상황에서 Solana 트랜잭션에 내구성 있는 논스를 추가하는 방법도 있지만, 표준 Solana 트랜잭션에는 논스를 포함하지 않아도 됩니다.

Solana의 Gulf Stream 시스템이 가능한 이유는 모든 활성 노드가 리더 스케줄을 항상 미리 알고 있기 때문입니다. 노드는 슬롯 높이가 에포크 경계를 지날 때마다, 대략 이틀마다 리더 스케줄을 업데이트합니다. 한 에포크의 리더 스케줄은 이전 에포크가 시작될 때의 원장 상태를 기반으로 계산됩니다. 리더 스케줄을 생성하는 알고리즘 과정은 다음과 같습니다.

• 역사 증명(PoH) 틱 높이, 즉 단조 증가 카운터를 주기적으로 사용해 안정적인 의사 난수 알고리즘의 시드를 설정합니다.
• 해당 높이에서 클러스터에 설정된 틱 수 이내에 투표한 리더 ID를 가진 모든 스테이킹 계정을 뱅크에서 샘플링합니다. 이 표본을 활성 집합이라고 합니다.
• 활성 집합을 스테이크 가중치에 따라 정렬합니다.
• 난수 시드를 사용해 스테이크에 따른 가중치로 노드를 선택하고 스테이크 가중 순서를 만듭니다.
• 이 순서는 클러스터에 설정된 틱 수가 지나면 유효해집니다.

출처: Solana 공식 문서

스테이크 가중치를 적용하면 스테이크가 더 많은 신뢰할 수 있는 노드가 리더로 더 자주 선택될 가능성이 커집니다. 반면 스테이크가 적은 노드는 덜 자주 선택되거나 전혀 선택되지 않습니다. 

‍스테이크 가중치에 따른 리소스 할당은 투표 보상, Turbine 트리, 리더 스케줄, 가십 네트워크* 등 Solana 코어 프로토콜 전반에서 반복되는 주제입니다. 이 글의 뒤에서 설명하겠지만 Gulf Stream도 스테이크 가중치를 사용합니다.

QUIC 참고 사항

Gulf Stream의 첫 번째 주요 업데이트는 2022년 말에 이루어졌습니다. 리더에게 트랜잭션 메시지를 전송하기 위해 QUIC 네트워킹 프로토콜을 도입했습니다. 이 업그레이드는 NFT 민팅 중 체인에 몰린 DDoS 공격과 스팸 트랜잭션으로 발생한 네트워크 장애에 대응하기 위한 것이었습니다. 릴리스 1.13.4에서 QUIC이 Mainnet-Beta에 완전히 통합된 후 네트워크 안정성이 향상되었습니다.

이전에는 Solana가 RPC 노드에서 현재 리더로 트랜잭션을 전송할 때 UDP(User Datagram Protocol) 네트워킹 프로토콜을 사용했습니다. UDP는 빠르고 효율적이지만 연결이 필요 없으며 흐름 제어와 수신 확인 기능이 모두 없습니다. 따라서 악의적 행위를 억제하거나 완화할 실질적인 방법이 없습니다. 네트워크 트래픽을 제어하기 위해 검증인의 트랜잭션 수집 프로토콜, 즉 TPU의 Fetch Stage가 QUIC으로 다시 구현되었습니다.

QUIC은 2012년 Google이 처음 개발했으며 TCP와 UDP의 장점을 모두 제공하려 합니다. UDP처럼 빠른 비동기 통신을 지원하면서도 TCP의 보안 세션과 고급 흐름 제어 전략을 제공합니다. 따라서 개별 트래픽 소스에 제한을 적용해 네트워크가 실제 트랜잭션 처리에 집중할 수 있습니다. 또한 별도의 스트림이라는 개념이 있어 트랜잭션 하나가 폐기되어도 나머지 트랜잭션을 차단하지 않습니다. Google은 Web2 전반의 QUIC 도입을 주도했습니다. Google 서버 연결에는 QUIC이 사용되므로 Hangouts, Gmail, YouTube 등 Google 산하의 많은 앱이 QUIC을 기반으로 합니다. 참고로 QUIC은 약어가 아니라 프로토콜의 실제 이름입니다. 

다만 Solana의 QUIC 구현이 효과적인지는 논쟁의 여지가 있습니다. 네트워크 트래픽이 급증하면 검증인이 QUIC 핸드셰이크를 감당하지 못할 수 있습니다. 네트워크 수준의 혼잡 문제를 해결하리라는 일부의 초기 기대와 달리 만능 해결책은 아니었다고 평가할 수 있습니다. Solana의 구현을 제외하면 블록체인 업계에서 QUIC 도입률은 낮다는 점도 고려해야 합니다. Solana 검증인 커뮤니티의 일부 구성원은 QUIC 도입이 잘못된 선택이었다고 공개적으로 비판해 왔습니다.

스테이크 가중 서비스 품질(SWQoS)

2024년 초 스팸을 방지하고 시빌 저항성을 강화하기 위한 메커니즘으로 스테이크 가중 서비스 품질(SWQoS)이 도입되었습니다. 이 시스템을 통해 리더는 스테이킹된 검증인을 거쳐 라우팅되는 트랜잭션 메시지를 우선 처리할 수 있습니다. 스테이크가 더 많은 검증인은 트랜잭션 메시지 패킷을 리더에게 전송할 수 있는 용량을 비례해서 더 많이 받습니다. 따라서 네트워크 전반에서 스테이킹되지 않았거나 스테이크가 적은 노드의 시빌 공격을 효과적으로 완화합니다. QUIC을 통해 IP 주소를 확인할 수 있으므로 이러한 분리가 가능합니다. 검증인은 특정 연결의 트래픽에 우선순위를 지정하고 제한할 수 있습니다. 

SWQoS를 사용하는 검증인은 스테이크 가중 용량을 RPC 노드에 임대할 수 있습니다. 그 대가로 RPC 노드는 더 많은 대역폭을 확보해 블록에 트랜잭션이 포함되는 비율을 높일 수 있습니다. 특히 리더 용량의 80%(연결 2,000개)는 스테이크 가중 QoS에 할당되고, 나머지 20%(연결 500개)는 다른 노드의 트랜잭션 메시지에 할당됩니다. 이 할당 전략은 운전자가 정체를 피하려고 통행료를 내는 고속도로의 우선 차로 시스템과 비슷합니다.

현재 스테이킹된 피어 자격을 얻기 위한 최소 스테이크는 전체 스테이크의 0.04%입니다. 이 글을 쓰는 시점의 전체 스테이크는 3억 8,400만 SOL이므로 최소 요건은 15,360 SOL입니다.‍

SWQoS는 트랜잭션을 리더에게 전달하기 위한 요건을 높이고 스팸 공격의 효과를 줄여 Solana 생태계에 큰 영향을 미쳤습니다. 이러한 변화는 트래픽이 많은 애플리케이션이 운영을 수직 통합하도록 유도했습니다. 애플리케이션은 자체 검증인 노드를 실행해 리더에 대한 우선 접근을 확보하고 트랜잭션 처리 역량을 높일 수 있습니다. Helius는 스테이크 기준 네트워크 상위 검증인 중 하나를 운영하며 더 높은 트랜잭션 포함률을 확보하고 있습니다. Helius를 통한 스테이킹에 관한 자세한 내용은 스테이킹 가이드에서 확인하세요.

Jito 과속 방지턱

이 글을 쓰는 시점에 네트워크 스테이크의 80% 이상이 Jito 검증인 클라이언트를 사용한다는 점에서 Jito를 빼놓을 수 없습니다. 이 클라이언트는 일반적으로 트랜잭션이 리더에게 도달하는 과정을 더 복잡하게 만듭니다. Jito-Solana 검증인 클라이언트(Github)는 원래 Solana Labs 클라이언트였던 Agave 클라이언트(Github)의 포크입니다. 프로토콜 외부 블록 공간 경매를 도입하고 검증인이 팁 형태로 추가 경제적 인센티브를 받을 수 있게 합니다.

Jito 클라이언트를 종합적으로 살펴보는 것은 이 글의 범위를 벗어납니다. 따라서 Jito 클라이언트가 Gulf Stream을 통한 일반 트랜잭션 흐름에 미치는 영향만 분석하겠습니다. 트랜잭션에는 두 가지 경로가 있습니다. RPC에서 페어링된 검증인을 거쳐 현재 리더로 흐르거나(스테이크 가중 경로), 리더에게 직접 전달됩니다(개방형 연결 경로). 어느 경우든 리더가 Jito-Solana 클라이언트를 실행하고 있다면 트랜잭션은 먼저 트랜잭션 프록시 라우터 역할을 하는 오픈 소스 소프트웨어 Jito-Relayer(Github)로 전송됩니다. 

다른 네트워크 노드는 Jito-Relayer의 존재를 알지 못합니다. 리더가 가십 네트워크를 통해 자신의 ingress_socket로 브로드캐스트하기로 선택한 주소와 포트 구성으로 트랜잭션을 보낼 뿐입니다. 릴레이어는 트랜잭션을 리더에게 전달하기 전에 200밀리초 동안 지연시킵니다. 이 “과속 방지턱” 메커니즘은 유입되는 트랜잭션 메시지의 흐름을 늦추고 효율적인 이산 시간 경매를 지원합니다. 200밀리초가 지나면 릴레이어는 경매 결과와 관계없이 트랜잭션을 낙관적으로 내보냅니다.

Jito는 이전에 표준 프로토콜 외부 멤풀 서비스를 운영했지만 현재는 지원이 중단되었습니다. Jito-Solana 검증인이 리더일 때 검색자는 차익 거래 트랜잭션이나 청산처럼 멤풀에 의존하지 않는 다른 유형의 MEV 트랜잭션을 위해 번들이라고 하는 원자적으로 실행되는 트랜잭션 그룹을 계속 제출할 수 있습니다.

자세한 내용은 Solana MEV를 소개하는 Helius 블로그 게시물을 참고하세요.

결론

이 글에서는 QUIC 네트워킹 프로토콜, 스테이크 가중 QoS, Jito 검증인 구성 등 Solana Gulf Stream의 여러 측면을 살펴봤습니다. Gulf Stream을 더 전통적인 멤풀 아키텍처와 비교하고, 효율성 향상과 지연 시간 단축이라는 측면에서 Solana 방식의 이점을 설명했습니다. 

Gulf Stream은 앞으로도 계속 발전할 것입니다. Solana 프로토콜과 더 넓은 생태계는 빠르게 발전하고 있으며 중요한 업그레이드가 예정되어 있습니다. 한 가지 예로 Solana 공동 창립자 Anatoly Yakovenko는 여러 동시 리더의 구현을 강력히 지지해 왔습니다. 여러 동시 리더를 사용하면 전 세계의 여러 노드가 사용자 트랜잭션의 순서를 동시에 지정할 수 있습니다. 이에 따라 지연 시간이 줄어들고, 트랜잭션을 블록체인에 추가하기 전에 최악의 경우 전 세계를 완전히 왕복해야 하는 상황을 없앨 수 있습니다.

Solana는 멈추지 않을 것이며 Gulf Stream을 포함한 전체 프로토콜에는 흥미로운 미래가 기다리고 있습니다. 따라서 개발자는 앞으로도 많은 업데이트와 최적화가 이루어질 것으로 예상해야 합니다.

여기까지 읽어주셔서 감사합니다! Discord 커뮤니티에 참여하거나 X를 팔로우하거나 아래에서 메일링 리스트를 구독해 보세요.‍

이 글의 이전 버전을 검토해 주신 Jacob Creech와 0xIchigo에게 깊이 감사드립니다.‍

추가 자료

• Gulf Stream: Solana의 멤풀 없는 트랜잭션 전달 프로토콜
• QUIC: UDP 기반 다중화 전송
• HTTP/3 및 QUIC 종합 가이드
• SWQoS 링크 모음
• Solana 스테이크 가중 서비스 품질 가이드
• Solana 검증인 교육 - 스테이크 가중 QoS
• Jito Relayer 문서
• 비동기 실행, 최종 단계 아키텍처

‍