Gulf Stream은 다음 리더를 미리 알 수 있는 Solana의 리더 스케줄을 이용해 클라이언트와 검증자가 미처리 거래를 예정 리더 쪽으로 전달하는 설계입니다. 전 네트워크가 하나의 공개 대기열을 오래 공유하는 전통적 멤풀 모델의 부담을 줄이려는 구조지만, 거래가 어디에도 잠시 저장되지 않는다는 뜻은 아닙니다. RPC·검증자·리더의 수신 큐와 forwarding 단계가 있으며, 거래는 recent blockhash 유효성, 서명, 계정 잠금, compute budget, 블록 자원 검사를 통과해야 포함됩니다. 전달 성공은 실행 또는 확정 성공의 증거가 아닙니다.
Gulf Stream은 2019년 아키텍처 설명에서 나온 이름이다
Solana Foundation의 2019년 공식 설명은 Gulf Stream을 ‘mempool-less transaction forwarding protocol’로 소개합니다. 모든 검증자가 다가올 리더 순서를 알기 때문에 클라이언트와 검증자가 거래를 현재 또는 예정 리더에게 미리 보낼 수 있고, 미확인 거래 풀의 메모리 부담과 리더 교체 지연을 줄인다는 구상입니다.
다만 이 문서는 초기 아키텍처 설명입니다. 현재 운영 동작을 확인할 때 Gulf Stream이라는 이름만으로 패킷 프로토콜이나 큐 구현을 단정하면 안 됩니다. 공식 Transaction Pipeline 문서는 오늘의 검증자가 거래를 UDP·QUIC로 받고, 서명 검증·sanitize·budget·age·account loading·execution·commit 단계를 거친다고 설명합니다. 역사적 설계 목표와 현재 파이프라인을 연결하되 같은 버전의 세부 사양처럼 취급하지 않는 것이 안전합니다.
‘멤풀 없음’은 대기 상태가 없다는 말이 아니라 전역 멤풀을 중심으로 거래를 전파하지 않는다는 구조 설명이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- Gulf Stream은 2019년 아키텍처 설명에서 나온 이름이다
Solana Foundation의 2019년 공식 설명은 Gulf Stream을 ‘mempool-less transaction forwarding protocol’로 소개합니다.
- 예정 리더를 알면 패킷의 다음 목적지를 좁힐 수 있다
리더 스케줄이 예측 가능하면 송신자는 무작위 피어 사이에서 거래가 돌기를 기다리는 대신 생산 차례가 가까운 리더 방향으로 전달할 수 있습니다.
- recent blockhash가 거래의 대기 수명을 제한한다
일반 Solana 거래 메시지는 recent blockhash를 포함합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
예정 리더를 알면 패킷의 다음 목적지를 좁힐 수 있다
리더 스케줄이 예측 가능하면 송신자는 무작위 피어 사이에서 거래가 돌기를 기다리는 대신 생산 차례가 가까운 리더 방향으로 전달할 수 있습니다. 리더 교체 전에 다음 리더가 거래를 확보하면 새 slot에서 다시 대규모 대기열을 동기화하는 시간을 줄일 수 있습니다. 이것이 Gulf Stream 설명의 핵심 이점입니다.
하지만 예정 리더에게 보냈다는 사실은 그 리더가 패킷을 수신·검증했다는 영수증이 아닙니다. QUIC 연결, 신뢰된 RPC forwarding 설정, stake-weighted QoS, 네트워크 혼잡에 따라 도달 경로가 달라질 수 있습니다. 공개 RPC의 sendTransaction 성공 응답도 보통 서명을 반환하거나 요청 접수를 뜻할 뿐, 블록 포함을 보증하지 않습니다.
| 관측 | 확인 가능한 사실 | 아직 확인되지 않은 사실 |
|---|---|---|
| RPC가 signature 반환 | 요청 형식이 접수되고 서명이 식별자로 정해짐 | 리더 수신·블록 포함 |
| 리더 TPU 연결 성공 | 패킷 전송 경로가 열림 | sanitize·age 검사 통과 |
| processed 상태 | 검증자가 거래를 실행한 블록을 관측 | 충분한 투표와 최종성 |
| finalized 상태 | RPC commitment 기준으로 root된 이력 | 거래소·수탁사의 별도 입금 반영 |
recent blockhash가 거래의 대기 수명을 제한한다
일반 Solana 거래 메시지는 recent blockhash를 포함합니다. 공식 Transaction Pipeline 문서에 따르면 검증자는 BlockhashQueue에서 해시를 찾고 최대 처리 나이 안인지 검사하며, 문서는 MAX_PROCESSING_AGE를 150 slots로 설명합니다. 범위를 벗어나면 durable nonce 여부를 별도로 검사합니다. 즉 서명된 거래는 무기한 대기열에 남아 언젠가 실행되는 요청이 아닙니다.
가정으로 slot이 평균 400ms라고 놓으면 150 slots는 약 60초입니다. 150×0.4=60이라는 단순 계산이며 실제 만료 벽시계는 slot 진행과 큐 규칙, 클러스터 상태에 따라 달라집니다. 사용자는 초 단위 고정 만료로 의존하지 말고 lastValidBlockHeight 같은 응답과 status를 추적해야 합니다. 동일 메시지를 새 blockhash로 다시 만들면 서명이 바뀌므로 앞선 요청과 새 요청을 함께 관리해야 중복 실행 위험을 줄일 수 있습니다.
- 전송 전에 cluster와 RPC endpoint가 의도한 네트워크인지 확인한다
- signature, recent blockhash, lastValidBlockHeight를 요청 기록에 함께 저장한다
- RPC 반환을 블록 포함으로 기록하지 말고 signature status를 추적한다
- 만료 전 재전송은 동일 서명 재브로드캐스트인지 새 blockhash 재서명인지 구분한다
- 새 거래가 성공하면 이전 서명의 뒤늦은 처리 가능성도 상태에서 재확인한다
리더가 받은 뒤에도 여러 검사가 남아 있다
현재 공식 파이프라인은 수신 뒤 패킷 역직렬화와 크기 검사, sigverify, transaction sanitize, compute budget·blockhash age·status cache, fee payer, account loading, instruction execution, commit의 순서를 제시합니다. 어느 단계에서 탈락했느냐에 따라 같은 ‘미체결’처럼 보여도 원인이 다릅니다.
예를 들어 signature가 유효해도 blockhash가 오래되면 실행 전에 거절됩니다. blockhash가 살아 있어도 같은 message hash가 이미 처리됐다면 AlreadyProcessed가 될 수 있습니다. 계정 데이터가 없거나 writable account가 경합하거나 block resource limit을 넘으면 다른 오류 또는 다음 기회 대기가 생깁니다. forwarding은 이 검사들 앞에 있는 운송 단계입니다.
공개 전역 멤풀과 리더의 로컬 큐를 구분한다
전통적 공개 멤풀에서는 여러 노드가 미확인 거래 집합을 광범위하게 공유하고 블록 생산자가 그중 거래를 선택합니다. Gulf Stream 설명은 예정 리더 중심 forwarding으로 이 공유 부담을 낮춥니다. 그렇더라도 RPC는 재시도와 forwarding을 위해 거래를 잠시 보유할 수 있고, 리더는 scheduler가 고를 후보를 버퍼에 둡니다. 구현 큐가 존재한다는 사실은 Gulf Stream의 ‘mempool-less’ 표현과 모순되지 않습니다.
이 차이는 관측 가능성에도 영향을 줍니다. 비트코인식 전역 멤풀 크기처럼 네트워크 전체 대기 거래 수를 한 숫자로 읽기 어렵습니다. 한 RPC의 queue나 특정 리더의 수신 상태를 전체 클러스터 상태로 일반화하면 안 됩니다. 거래 도달률을 측정하려면 여러 endpoint의 status, block inclusion과 만료 비율을 같은 시간 창에서 비교해야 합니다.
지연 진단은 마지막으로 확인된 단계에서 시작한다
signature도 반환되지 않았다면 RPC 요청·직렬화·연결부터 확인합니다. signature는 있지만 status가 계속 null이면 잘못된 cluster, forwarding 실패, 만료를 조사합니다. processed 뒤 error가 있으면 프로그램 로그와 계정 상태를 봅니다. processed 뒤 confirmation이 진행되지 않으면 해당 slot과 분기 상태를 확인합니다. 단계별 증거를 남기면 ‘네트워크가 느리다’는 하나의 원인으로 뭉개지 않습니다.
운영 기록에는 endpoint, 전송 시각, blockhash, last valid 높이, signature, 최초 status 관측 시각, 포함 slot, error를 저장하는 것이 유용합니다. 이 기록은 투자 전략을 만들기 위한 것이 아니라 전송 품질과 애플리케이션 재시도 안전성을 검증하는 자료입니다. 특히 새 blockhash로 재서명하는 자동화는 앞선 서명의 상태를 다시 확인한 뒤 실행하도록 설계해야 합니다.
자주 묻는 질문
솔라나는 멤풀이 정말 전혀 없나요?
전 네트워크가 하나의 공개 미확인 거래 풀을 중심으로 동작하지 않는다는 뜻에 가깝습니다. RPC와 리더 내부에는 수신·forwarding·스케줄링을 위한 일시적 큐와 캐시가 존재할 수 있습니다.
sendTransaction이 signature를 반환하면 성공인가요?
요청 접수와 거래 식별자를 얻었다는 증거입니다. signature status, 실행 error, 포함 slot과 commitment를 별도로 확인해야 합니다.
만료된 거래는 같은 서명으로 다시 보낼 수 있나요?
오래된 recent blockhash를 가진 같은 거래는 age 검사를 통과하지 못합니다. 새 blockhash로 메시지를 만들고 다시 서명하면 새 signature가 되므로 이전 거래와 함께 중복 상태를 관리해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
