Stake-weighted QoS는 Solana 리더가 들어오는 TPU 패킷 연결을 지분 비중에 따라 배분해 무지분 노드의 대량 전송이 지분 검증자의 통로를 밀어내기 어렵게 만드는 선택 기능입니다. 공식 가이드 예시처럼 지분 0.5%인 검증자는 리더 패킷 용량의 최대 약 0.5%에 해당하는 통로를 확보할 수 있습니다. 이는 패킷이 리더 입구에 도달할 기회를 다루며, 거래의 priority fee 순위·계정 잠금·프로그램 실행·최종 확정을 보장하지 않습니다. trusted RPC에는 설정으로 virtual stake를 부여할 수 있지만 RPC 자체를 consensus validator처럼 바꾸는 것은 아닙니다.
QoS가 해결하려는 문제는 리더 입구의 패킷 홍수다
거래를 처리할 slot 리더에게 많은 노드가 동시에 패킷을 보내면 네트워크 연결과 수신 큐가 먼저 포화될 수 있습니다. 출처에 상관없이 같은 몫을 주면 공격자가 여러 무지분 신원을 만들어 정상 거래의 연결을 밀어내는 Sybil 공격 비용이 낮아집니다. Stake-weighted QoS는 consensus에 걸어 둔 지분을 수신 용량 배분 신호로 재사용합니다.
공식 가이드는 지분 0.5%인 검증자가 리더에게 보낼 수 있는 패킷 용량도 최대 약 0.5%가 되는 예를 듭니다. 이는 초당 정확히 몇 건을 보장하는 숫자가 아닙니다. 전체 TPU 용량, leader 설정, packet 크기와 다른 staked peer의 트래픽에 따라 실제 건수는 변합니다.
Stake-weighted QoS는 거래의 정답을 지분으로 고르는 장치가 아니라 리더 입구의 희소한 전송 통로를 배분하는 장치다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- QoS가 해결하려는 문제는 리더 입구의 패킷 홍수다
거래를 처리할 slot 리더에게 많은 노드가 동시에 패킷을 보내면 네트워크 연결과 수신 큐가 먼저 포화될 수 있습니다.
- 지분 비중과 패킷 몫의 가정 계산
가정으로 leader TPU가 한 관측 구간에 100만 packet을 안정적으로 받을 수 있고, 그중 80%를 staked 연결에 배분한다고 하겠습니다.
- trusted RPC의 virtual stake는 합의 지분이 아니다
공식 가이드는 validator의 staked-nodes-overrides와 RPC의 rpc-send-transaction-tpu-peer를 양쪽에 설정해 신뢰 관계를 만든다고 설명합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
지분 비중과 패킷 몫의 가정 계산
가정으로 leader TPU가 한 관측 구간에 100만 packet을 안정적으로 받을 수 있고, 그중 80%를 staked 연결에 배분한다고 하겠습니다. 검증자 A가 전체 유효 지분의 2%라면 단순 비례 몫은 1,000,000×0.8×0.02=16,000 packets입니다. 이는 설명용 가정이며 실제 처리량이나 현재 기본 설정을 뜻하지 않습니다.
거래 하나가 packet 하나라는 보장도 없습니다. 거래 형식과 크기에 따라 전송 프레임이 달라질 수 있고, 패킷이 도착해도 sanitize·blockhash age·fee payer·account loading 검사에서 탈락할 수 있습니다. QoS 지표를 TPS나 성공률로 바로 바꾸면 단위가 섞입니다.
| 단계 | 주요 입력 | 확인하는 결과 |
|---|---|---|
| TPU 연결 QoS | peer identity와 stake/override | 리더 수신 용량 몫 |
| 거래 scheduler | fee reward·요청 CU·write lock cost | 실행 후보의 우선순위와 배치 |
| runtime 실행 | 서명·계정·instruction | 상태 변경 성공 또는 오류 |
| consensus | 검증자 투표와 root | 분기 채택과 finality |
| 서비스 반영 | 거래소 자체 확인 정책 | 입금·출금 화면 처리 |
trusted RPC의 virtual stake는 합의 지분이 아니다
공식 가이드는 validator의 staked-nodes-overrides와 RPC의 rpc-send-transaction-tpu-peer를 양쪽에 설정해 신뢰 관계를 만든다고 설명합니다. RPC는 원래 non-voting·non-consensus 노드이므로 validator가 그 연결에 virtual stake를 매핑하면 해당 리더가 inbound TPU traffic을 지분 연결처럼 취급할 수 있습니다.
이 virtual stake는 온체인 위임, 투표권, 스테이킹 보상으로 바뀌지 않습니다. validator와 RPC 운영자가 직접 합의한 네트워크 설정입니다. 잘못된 상대를 trusted peer로 등록하면 스팸 통로를 키울 수 있어 공식 문서도 신뢰되지 않은 RPC와 설정하지 말 것을 권합니다.
- validator와 RPC의 identity public key를 정확히 대조한다
- 양쪽 peer 주소와 QUIC TPU port를 같은 환경에서 확인한다
- override의 lamport 값이 의도한 virtual 비중인지 검산한다
- 설정 후 연결 수립·패킷 drop·landed transaction을 각각 측정한다
- 설정 해제 절차와 원래 구성 파일 hash를 함께 보관한다
priority fee와 QoS는 같은 우선순위가 아니다
Stake-weighted QoS는 누가 리더에게 패킷을 보낼 통로를 갖는지 다룹니다. priority fee는 이미 받은 거래 중 scheduler가 경제적 우선순위를 계산할 때 쓰는 reward입니다. 높은 fee 거래도 리더에게 전달되지 않으면 후보가 되지 않고, QoS 통로로 도착한 거래도 낮은 fee·과도한 CU·계정 경합 때문에 늦을 수 있습니다.
공식 Fee Structure는 priority를 reward×1,000,000÷(estimated cost+1)로 설명합니다. estimated cost에는 write lock과 요청 compute가 들어갑니다. 따라서 ‘지분 높은 RPC를 쓰면 수수료가 필요 없다’거나 ‘fee를 높이면 QoS 제한을 무시한다’는 결론은 두 단계를 잘못 합친 것입니다.
효과 측정은 수신과 포함을 나눠야 한다
도입 전후 성공률만 비교하면 시장 혼잡, fee 설정, blockhash 만료 변화가 섞입니다. 같은 거래 유형과 fee bucket에서 RPC 전송 시각, leader 연결 성공, 최초 processed, landed slot, error를 기록해야 QoS가 전달 단계에 준 영향을 좁힐 수 있습니다.
A/B 비교에서는 같은 slot을 동시에 재사용해 중복 거래를 만들지 않습니다. 일정 시간창별 aggregate를 비교하고 transaction signature를 중복 제거합니다. landed 비율이 올라도 QoS 때문이라는 인과 결론은 peer routing 외 조건을 통제했을 때만 제한적으로 제시합니다.
설정 문서의 버전과 활성 상태를 확인한다
공식 가이드는 이 기능이 v1.14에 도입됐고 현재 Agave로 이어졌다고 설명합니다. 그러나 command-line flag와 기본 용량 비율은 클라이언트 릴리스에서 바뀔 수 있습니다. 과거 문서의 80% 수치를 영구 프로토콜 상수로 쓰지 말고 실행 중인 Agave 버전 도움말과 release note를 확인해야 합니다.
운영 보고에는 ‘설정 파일에 값이 있다’, ‘QUIC peer 연결이 성립했다’, ‘packet drop이 줄었다’, ‘거래 포함률이 변했다’를 각각 별도 증거로 남깁니다. 설정 존재만으로 성능 개선이나 server acceptance를 완료로 주장하지 않습니다.
자주 묻는 질문
지분이 크면 거래가 무조건 먼저 실행되나요?
아닙니다. Stake-weighted QoS는 리더 수신 통로를 배분합니다. 실행 순서는 fee, 요청 CU, account lock과 블록 자원 등 scheduler 조건을 별도로 받습니다.
RPC에 virtual stake를 주면 투표 보상도 받나요?
받지 않습니다. virtual stake는 trusted RPC의 TPU traffic을 validator가 어떻게 취급할지 정하는 로컬 네트워크 설정이며 온체인 위임이나 합의 투표권이 아닙니다.
공식 문서의 80% 용량 비율은 항상 같나요?
문서가 설명한 구현 시점의 값입니다. 실행 클라이언트 버전과 설정에서 현재 값을 확인해야 하며 고정 프로토콜 상수로 가정하면 안 됩니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
