지분 가중 서비스 품질(Stake-weighted QoS)은 솔라나 리더가 들어오는 거래 처리 장치(TPU) 패킷 연결을 지분 비중에 맞춰 나눠 주는 선택 기능입니다. 덕분에 지분 없는 노드가 대량으로 쏟아붓는 패킷이 지분 검증자의 통로를 밀어내기 어려워집니다. 공식 가이드의 예처럼 지분 0.5%인 검증자는 리더 패킷 용량의 최대 약 0.5%에 해당하는 통로를 얻을 수 있습니다. 이 기능이 다루는 것은 패킷이 리더 입구에 닿을 기회일 뿐, 우선순위 수수료 순위나 계정 잠금, 프로그램 실행, 최종 확정까지 보장하지는 않습니다. 믿을 수 있는 RPC에 설정으로 가상 지분(virtual stake)을 줄 수는 있지만, 그렇다고 RPC가 합의에 참여하는 검증자가 되는 것은 아닙니다.
QoS가 풀려는 문제는 리더 입구에 몰리는 패킷 홍수입니다
슬롯을 맡은 리더에게 많은 노드가 한꺼번에 패킷을 보내면 네트워크 연결과 수신 대기열부터 가득 찰 수 있습니다. 출처를 따지지 않고 똑같이 나눠 주면, 공격자가 지분 없는 신원을 여럿 만들어 정상 거래의 연결을 밀어내는 시빌(Sybil) 공격이 싸게 먹힙니다. 지분 가중 QoS는 합의에 걸어 둔 지분을 수신 용량을 나누는 신호로 다시 씁니다.
공식 가이드는 지분 0.5%인 검증자가 리더에게 보낼 수 있는 패킷 용량도 최대 약 0.5%가 된다는 예를 듭니다. 초당 정확히 몇 건을 보장한다는 뜻은 아닙니다. 전체 TPU 용량, 리더 설정, 패킷 크기, 지분을 가진 다른 피어의 트래픽에 따라 실제 건수는 달라집니다.
지분 가중 QoS는 어떤 거래가 옳은지를 지분으로 고르는 장치가 아닙니다. 리더 입구의 좁은 전송 통로를 나눠 주는 장치입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- QoS가 풀려는 문제는 리더 입구에 몰리는 패킷 홍수입니다
슬롯을 맡은 리더에게 많은 노드가 한꺼번에 패킷을 보내면 네트워크 연결과 수신 대기열부터 가득 찰 수 있습니다.
- 지분 비중과 패킷 몫을 가정으로 계산해 봅니다
리더 TPU가 어떤 관측 구간에 100만 패킷을 안정적으로 받을 수 있고, 그중 80%를 지분 연결에 배정한다고 가정해 봅니다.
- 믿을 수 있는 RPC의 가상 지분은 합의 지분이 아닙니다
공식 가이드는 검증자 쪽 staked-nodes-overrides와 RPC 쪽 rpc-send-transaction-tpu-peer를 함께 설정해 신뢰 관계를 맺는다고 설명합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
지분 비중과 패킷 몫을 가정으로 계산해 봅니다
리더 TPU가 어떤 관측 구간에 100만 패킷을 안정적으로 받을 수 있고, 그중 80%를 지분 연결에 배정한다고 가정해 봅니다. 검증자 A가 전체 유효 지분의 2%라면 단순 비례 몫은 1,000,000×0.8×0.02=16,000패킷입니다. 어디까지나 설명을 위한 가정일 뿐, 실제 처리량이나 지금의 기본 설정을 뜻하지 않습니다.
거래 하나가 패킷 하나라는 보장도 없습니다. 거래 형식과 크기에 따라 전송 단위가 달라질 수 있고, 패킷이 도착해도 형식 정리·블록해시 유효 기간·수수료 납부 계정·계정 불러오기 검사에서 떨어질 수 있습니다. QoS 지표를 초당 거래 수나 성공률로 곧장 옮기면 단위가 뒤섞입니다.
| 단계 | 주요 입력 | 확인하는 결과 |
|---|---|---|
| TPU 연결 QoS | 피어 신원과 지분·수동 지정값 | 리더 수신 용량 몫 |
| 거래 스케줄러 | 수수료 보상·요청 연산량·쓰기 잠금 비용 | 실행 후보의 우선순위와 배치 |
| 런타임 실행 | 서명·계정·명령 | 상태 변경 성공 또는 오류 |
| 합의 | 검증자 투표와 루트 | 분기 채택과 최종성 |
| 서비스 반영 | 거래소 자체 확인 정책 | 입금·출금 화면 처리 |
믿을 수 있는 RPC의 가상 지분은 합의 지분이 아닙니다
공식 가이드는 검증자 쪽 staked-nodes-overrides와 RPC 쪽 rpc-send-transaction-tpu-peer를 함께 설정해 신뢰 관계를 맺는다고 설명합니다. RPC는 원래 투표도 합의도 하지 않는 노드입니다. 그래서 검증자가 그 연결에 가상 지분을 짝지어 주면, 해당 리더는 RPC에서 들어오는 TPU 트래픽을 지분 연결처럼 대할 수 있습니다.
이 가상 지분은 온체인 위임이나 투표권, 스테이킹 보상으로 바뀌지 않습니다. 검증자와 RPC 운영자가 서로 합의해 정한 네트워크 설정일 뿐입니다. 엉뚱한 상대를 신뢰 피어로 올리면 스팸 통로를 넓혀 주는 꼴이 되므로, 공식 문서도 믿을 수 없는 RPC와는 설정하지 말라고 권합니다.
- 검증자와 RPC의 신원 공개키를 정확히 맞춰 봅니다
- 양쪽 피어 주소와 QUIC TPU 포트를 같은 환경에서 확인합니다
- 수동 지정한 램포트 값이 의도한 가상 비중인지 다시 계산합니다
- 설정 뒤 연결 수립·패킷 누락·블록 포함 거래를 따로따로 잽니다
- 설정을 되돌리는 절차와 원래 구성 파일 해시를 함께 보관합니다
우선순위 수수료와 QoS는 서로 다른 우선순위입니다
지분 가중 QoS는 누가 리더에게 패킷을 보낼 통로를 얻느냐를 다룹니다. 우선순위 수수료(priority fee)는 이미 받은 거래 가운데 스케줄러가 경제적 우선순위를 매길 때 쓰는 보상입니다. 수수료가 높은 거래라도 리더에게 닿지 못하면 후보에 오르지 못하고, QoS 통로로 도착한 거래도 낮은 수수료·지나친 연산량 요청·계정 경합 때문에 밀릴 수 있습니다.
공식 수수료 구조 문서는 우선순위를 reward×1,000,000÷(estimated cost+1)로 설명합니다. 여기서 예상 비용에는 쓰기 잠금과 요청 연산량이 들어갑니다. 그러니 ‘지분 큰 RPC를 쓰면 수수료가 필요 없다’거나 ‘수수료를 올리면 QoS 제한을 건너뛴다’는 결론은 두 단계를 잘못 한데 묶은 것입니다.
효과를 잴 때는 수신과 포함을 나눠야 합니다
도입 전후 성공률만 비교하면 시장 혼잡, 수수료 설정, 블록해시 만료 같은 변화가 뒤섞입니다. 같은 거래 유형과 같은 수수료 구간에서 RPC 전송 시각, 리더 연결 성공, 처음 처리된 시점, 포함된 슬롯, 오류를 적어 둬야 QoS가 전달 단계에 준 영향을 좁혀 볼 수 있습니다.
A/B 비교를 할 때 같은 슬롯을 동시에 써서 중복 거래를 만들지 마세요. 일정한 시간 구간별 합계를 비교하고 거래 서명은 중복을 걸러 냅니다. 포함 비율이 올랐더라도 QoS 덕분이라는 인과 판단은 피어 경로 말고 다른 조건을 통제했을 때만 조심스럽게 내놓습니다.
설정 문서의 버전과 실제 활성 여부를 확인합니다
공식 가이드는 이 기능이 v1.14에서 도입돼 지금의 Agave로 이어졌다고 설명합니다. 하지만 명령줄 옵션과 기본 용량 비율은 클라이언트 릴리스마다 바뀔 수 있습니다. 옛 문서의 80% 수치를 바뀌지 않는 프로토콜 상수처럼 쓰지 말고, 실행 중인 Agave 버전의 도움말과 릴리스 노트를 확인해야 합니다.
운영 보고에는 ‘설정 파일에 값이 있다’, ‘QUIC 피어 연결이 맺어졌다’, ‘패킷 누락이 줄었다’, ‘거래 포함률이 바뀌었다’를 각각 따로 된 증거로 남기세요. 설정이 있다는 것만으로 성능이 나아졌다거나 서버 반영이 끝났다고 주장하지 않습니다.
자주 묻는 질문
지분이 크면 거래가 무조건 먼저 실행되나요?
아닙니다. 지분 가중 QoS는 리더의 수신 통로를 나눌 뿐입니다. 실행 순서는 수수료, 요청 연산량, 계정 잠금, 블록 자원 같은 스케줄러 조건에 따라 따로 정해집니다.
RPC에 가상 지분을 주면 투표 보상도 받나요?
받지 않습니다. 가상 지분은 믿을 수 있는 RPC의 TPU 트래픽을 검증자가 어떻게 대할지 정하는 로컬 네트워크 설정이고, 온체인 위임이나 합의 투표권과는 무관합니다.
공식 문서의 80% 용량 비율은 항상 같나요?
문서가 쓰인 구현 시점의 값입니다. 지금 값은 실행 중인 클라이언트 버전과 설정에서 확인해야 하고, 고정된 프로토콜 상수로 여기면 안 됩니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
