솔라나 Gulf Stream 거래 전달: 멤풀 없이 다음 리더로 가는 경로

걸프 스트림(Gulf Stream)은 다음 리더를 미리 알 수 있는 솔라나의 리더 스케줄을 활용해, 클라이언트와 검증자가 처리되지 않은 거래를 차례가 다가온 리더 쪽으로 넘기는 설계입니다. 네트워크 전체가 공개 대기열 하나를 오래 함께 쓰는 전통적 멤풀 방식의 부담을 덜려는 구조지만, 거래가 어디에도 잠시 머물지 않는다는 뜻은 아닙니다. RPC·검증자·리더에는 수신 대기열과 전달(forwarding) 단계가 있고, 거래는 최근 블록해시(recent blockhash) 유효성, 서명, 계정 잠금, 연산 예산(compute budget), 블록 자원 검사를 통과해야 블록에 들어갑니다. 전달 성공은 실행 또는 확정 성공의 증거가 아닙니다.

걸프 스트림은 2019년 아키텍처 설명에서 나온 이름입니다

솔라나 재단(Solana Foundation)의 2019년 공식 설명은 걸프 스트림을 ‘멤풀 없는 거래 전달 프로토콜’로 소개합니다. 모든 검증자가 앞으로의 리더 순서를 알고 있으니 클라이언트와 검증자가 거래를 현재 리더나 다음 리더에게 미리 보낼 수 있고, 그만큼 미확인 거래 풀의 메모리 부담과 리더 교체 지연을 줄인다는 구상입니다.

다만 이 문서는 초기 아키텍처 설명입니다. 지금의 운영 동작을 확인할 때 걸프 스트림이라는 이름만 보고 패킷 프로토콜이나 대기열 구현을 단정하면 안 됩니다. 공식 거래 파이프라인(Transaction Pipeline) 문서는 오늘날 검증자가 거래를 UDP·QUIC로 받은 뒤 서명 검증, 형식 정리, 예산 확인, 나이 확인, 계정 불러오기, 실행, 커밋 단계를 거친다고 설명합니다. 역사적 설계 목표와 현재 파이프라인을 연결하되 같은 버전의 세부 사양처럼 취급하지 않는 것이 안전합니다.

‘멤풀 없음’은 대기 상태가 없다는 말이 아니라, 전역 멤풀을 중심으로 거래를 퍼뜨리지 않는다는 구조 설명입니다.

JOBCOIN 해설

그림으로 보기거래 요청부터 블록 확인까지

1. 01
   걸프 스트림은 2019년 아키텍처 설명에서 나온 이름입니다

   솔라나 재단(Solana Foundation)의 2019년 공식 설명은 걸프 스트림을 ‘멤풀 없는 거래 전달 프로토콜’로 소개합니다.

2. 02
   다음 리더를 알면 패킷의 목적지를 좁힐 수 있습니다

   리더 스케줄을 예측할 수 있으면 보내는 쪽은 무작위 피어 사이를 거래가 떠돌기를 기다리는 대신, 블록 생산 차례가 가까운 리더 쪽으로 거래를 넘길 수 있습니다.

3. 03
   최근 블록해시가 거래의 대기 수명을 정합니다

   일반적인 솔라나 거래 메시지에는 최근 블록해시가 들어갑니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

다음 리더를 알면 패킷의 목적지를 좁힐 수 있습니다

리더 스케줄을 예측할 수 있으면 보내는 쪽은 무작위 피어 사이를 거래가 떠돌기를 기다리는 대신, 블록 생산 차례가 가까운 리더 쪽으로 거래를 넘길 수 있습니다. 리더가 바뀌기 전에 다음 리더가 거래를 확보해 두면 새 슬롯에서 큰 대기열을 다시 맞추는 시간을 줄일 수 있습니다. 이것이 걸프 스트림 설명의 핵심 이점입니다.

하지만 다음 리더에게 보냈다는 사실이 그 리더가 패킷을 받아 검증했다는 영수증은 아닙니다. QUIC 연결, 신뢰된 RPC 전달 설정, 지분 비례 서비스 품질 정책, 네트워크 혼잡에 따라 도달 경로가 달라질 수 있습니다. 공개 RPC의 sendTransaction 성공 응답도 보통 서명을 돌려주거나 요청을 받았다는 뜻일 뿐, 블록 포함을 보증하지 않습니다.

최근 블록해시가 거래의 대기 수명을 정합니다

일반적인 솔라나 거래 메시지에는 최근 블록해시가 들어갑니다. 공식 거래 파이프라인 문서에 따르면 검증자는 BlockhashQueue에서 해시를 찾아 최대 처리 나이 안에 있는지 검사하며, 문서는 MAX_PROCESSING_AGE를 150 슬롯으로 설명합니다. 범위를 벗어나면 지속 논스(durable nonce)를 쓰는지 따로 검사합니다. 곧 서명된 거래는 무기한 대기열에 남아 언젠가 실행되는 요청이 아닙니다.

슬롯 하나가 평균 400ms라고 가정하면 150 슬롯은 약 60초입니다. 150×0.4=60이라는 단순 계산일 뿐이고, 실제로 몇 초 뒤 만료되는지는 슬롯 진행과 대기열 규칙, 클러스터 상태에 따라 달라집니다. 사용자는 초 단위 고정 만료에 기대지 말고 lastValidBlockHeight 같은 응답과 상태를 추적해야 합니다. 같은 메시지를 새 블록해시로 다시 만들면 서명이 바뀌므로, 앞선 요청과 새 요청을 함께 관리해야 중복 실행 위험을 줄일 수 있습니다.

• 보내기 전에 클러스터와 RPC 엔드포인트가 의도한 네트워크인지 확인합니다
• 서명, 최근 블록해시, lastValidBlockHeight를 요청 기록에 함께 저장합니다
• RPC 응답을 블록 포함으로 기록하지 말고 서명 상태를 추적합니다
• 만료 전 재전송이 같은 서명을 다시 퍼뜨리는 것인지, 새 블록해시로 다시 서명한 것인지 구분합니다
• 새 거래가 성공하면 이전 서명이 뒤늦게 처리될 가능성도 상태 조회로 다시 확인합니다

리더가 받은 뒤에도 여러 검사가 남아 있습니다

현재 공식 파이프라인은 수신 뒤 패킷 역직렬화와 크기 검사, 서명 검증, 거래 형식 정리, 연산 예산·블록해시 나이·상태 캐시 확인, 수수료 지불 계정 확인, 계정 불러오기, 명령 실행, 커밋 순서를 제시합니다. 어느 단계에서 떨어졌느냐에 따라 똑같이 ‘미체결’로 보여도 원인이 다릅니다.

예를 들어 서명이 유효해도 블록해시가 오래됐다면 실행 전에 거절됩니다. 블록해시가 살아 있어도 같은 메시지 해시가 이미 처리됐다면 AlreadyProcessed가 될 수 있습니다. 계정 데이터가 없거나 쓰기 계정을 두고 경합하거나 블록 자원 한도를 넘으면 다른 오류가 나거나 다음 기회를 기다리게 됩니다. 전달은 이 검사들 앞에 놓인 운송 단계입니다.

공개 전역 멤풀과 리더의 로컬 대기열을 구분합니다

전통적인 공개 멤풀에서는 여러 노드가 미확인 거래 집합을 널리 공유하고, 블록 생산자가 그 가운데 거래를 고릅니다. 걸프 스트림 설명은 다음 리더 중심의 전달로 이 공유 부담을 낮춥니다. 그렇더라도 RPC는 재시도와 전달을 위해 거래를 잠시 들고 있을 수 있고, 리더는 스케줄러가 고를 후보를 버퍼에 둡니다. 구현상 대기열이 있다는 사실이 걸프 스트림의 ‘멤풀 없음’ 표현과 모순되지는 않습니다.

이 차이는 관측 방식에도 영향을 줍니다. 비트코인처럼 전역 멤풀 크기 하나로 네트워크 전체의 대기 거래 수를 읽기는 어렵습니다. RPC 한 곳의 대기열이나 특정 리더의 수신 상태를 클러스터 전체 상태로 일반화하면 안 됩니다. 거래 도달률을 재려면 여러 엔드포인트의 상태, 블록 포함 여부, 만료 비율을 같은 시간 창에서 비교해야 합니다.

지연 진단은 마지막으로 확인된 단계에서 시작합니다

서명조차 돌아오지 않았다면 RPC 요청·직렬화·연결부터 확인합니다. 서명은 있는데 상태가 계속 null이라면 잘못된 클러스터, 전달 실패, 만료를 조사합니다. processed 뒤에 오류가 있으면 프로그램 로그와 계정 상태를 봅니다. processed 뒤로 확인이 진행되지 않으면 해당 슬롯과 분기 상태를 확인합니다. 단계별 증거를 남겨 두면 모든 원인을 ‘네트워크가 느리다’ 한마디로 뭉개지 않게 됩니다.

운영 기록에는 엔드포인트, 전송 시각, 블록해시, 마지막 유효 높이, 서명, 처음 상태를 관측한 시각, 포함 슬롯, 오류를 저장해 두면 쓸모가 있습니다. 이 기록은 투자 전략을 세우려는 것이 아니라 전송 품질과 애플리케이션 재시도의 안전성을 검증하는 자료입니다. 특히 새 블록해시로 다시 서명하는 자동화는 앞선 서명의 상태를 다시 확인한 뒤 실행하도록 설계해야 합니다.

자주 묻는 질문