지분 가중 서비스 품질: 알아야 할 모든 것
소개
Solana는 높은 처리량과 짧은 지연 시간을 갖춘 네트워크로서 블록체인 기술을 선도하며, 탈중앙화 네트워크가 달성할 수 있는 한계를 넓히고 있습니다. 하지만 여기에는 중대한 과제도 따릅니다. Solana 발전 과정의 중요한 전환점은 2022년 4월 30일 발생한 중단이었습니다. 이 사건은 많은 트랜잭션을 처리하고 높은 부하에서도 네트워크 성능을 유지하려면 더 강력한 메커니즘이 필요하다는 점을 보여주었습니다.
지분 가중 서비스 품질(Stake-Weighted Quality of Service, SWQoS)은 이 사건에 대응하기 위해 만들어졌습니다. 이 메커니즘은 검증인이 보유한 스테이크를 기준으로 네트워크 트래픽의 우선순위를 정해, 스테이크가 많은 검증인이 트랜잭션을 더 높은 우선순위로 전송할 수 있게 합니다. SWQoS는 스테이크가 적은 검증인이 네트워크에 과도한 부하를 주는 것을 방지하고 Solana의 복원력과 효율성을 높이도록 설계되었습니다.
이 글에서는 SWQoS와 Solana의 트랜잭션 처리 모델, 그리고 SWQoS가 이 모델에 미치는 영향을 살펴봅니다. 스테이킹된 연결과 설정 방법, SWQoS와 우선순위 수수료의 차이도 다룹니다. 또한 검증인과 유동성 스테이킹 토큰(LST)의 중요성 증가, 진입 장벽, 이 시스템에 내재된 신뢰 가정 등 향후 영향을 논의합니다.
이 글은 독자가 Solana의 프로그래밍 모델과 QUIC을 알고 있다고 가정합니다. 해당 주제가 익숙하지 않다면 이 글을 읽기 전에 다음 글을 먼저 살펴보시기를 권합니다.
다만 필요한 부분에서는 관련 맥락을 설명합니다.
지분 가중 서비스 품질이란?
지분 가중 서비스 품질(SWQoS)은 검증인이 보유한 스테이크를 기준으로 네트워크 트래픽의 우선순위를 정하는 메커니즘입니다. 스테이크가 많은 검증인이 트랜잭션을 더 효과적으로 전송하게 하여 서비스 품질을 높입니다.
Solana가 지분 증명 네트워크라는 점을 고려하면, 트랜잭션 성능에도 스테이크 가중치를 적용하는 것은 자연스럽습니다. 간단히 말해 Solana는 스테이크, 즉 네트워크 보안을 위해 검증인에 잠근 자금을 사용해 해당 검증인의 신뢰도를 나타냅니다. 검증인이 보유한 스테이크가 많을수록 네트워크의 보안과 안정성에 더 큰 이해관계를 갖습니다. 또한 서비스 품질은 특정 패킷에 우선순위를 부여해 네트워크에서 더 안정적인 성능을 제공하는 네트워킹 개념입니다. 따라서 Solana는 스테이킹된 검증인의 트랜잭션을 우선 연결로 라우팅해 더 안정적인 전송 성능을 제공합니다.
SWQoS의 주된 목적은 스테이크가 적은 검증인이 대량의 트랜잭션을 보내 품질이 높거나 스테이크가 많은 검증인이 전송한 트랜잭션을 밀어내는 일을 방지하는 것입니다. 예를 들어 검증인이 전체 스테이크의 5%를 보유하면 리더에게 전체 패킷의 5%를 보낼 수 있습니다. SWQoS는 악의적인 행위자가 “품질이 낮은” 트랜잭션으로 네트워크를 범람시키기 어렵게 만드는 시빌 저항 메커니즘으로 볼 수 있습니다.
한정된 수의 티켓만 판매하는 인기 콘서트나 놀이공원에 갔다고 생각해 보세요. 누구나 티켓을 구매하려고 줄을 설 수 있는 일반 대기열이 있지만, 줄이 길어지고 처리 속도가 느려질 수 있습니다. 반면 더 많은 비용을 지불한 고객을 위한 VIP 대기열도 있습니다. 특정 멤버십 보유와 같은 기준을 충족한 사람만 이용할 수 있고 한 번에 일정 인원의 입장이 보장되므로 훨씬 짧고 빠릅니다. Solana에서 SWQoS는 검증인이 보유한 스테이크의 양에 따라 이용 권한이 정해지는 VIP 대기열과 같습니다. 스테이크가 많을수록 더 많은 VIP 접근 권한, 즉 우선 연결을 확보하여 티켓(트랜잭션)을 더 빠르고 안정적으로 처리할 수 있습니다.
그렇다면 실제로는 어떻게 작동할까요? 먼저 Solana가 트랜잭션을 처리하는 방식을 이해해야 합니다.
Solana의 트랜잭션 처리 방식
Solana의 트랜잭션 처리 장치(Transaction Processing Unit, TPU)는 트랜잭션을 효율적으로 처리하고 실행합니다. 트랜잭션의 검증, 실행, 네트워크 전파를 보장하기 위해 여러 단계로 나누어 처리합니다. Fetch Stage, SigVerify Stage, Banking Stage, 역사 증명(Proof of History, PoH) Service, Broadcast Stage가 이에 해당합니다.
Fetch Stage
Fetch Stage는 네트워크를 통해 클라이언트에서 들어오는 트랜잭션을 수신합니다. UDP 소켓의 입력을 배치로 묶고 다음 세 가지 주요 소켓으로 분류합니다.
tpu: 토큰 전송, NFT 민팅, 프로그램 상호작용과 같은 일반 트랜잭션용tpu_vote: 투표 트랜잭션용tpu_forwards: 현재 리더가 모든 트랜잭션을 처리할 수 없을 때 처리되지 않은 패킷을 다음 리더에게 전달합니다.
이 소켓들은 Gossip에서 생성되어 ContactInfo 구조체에 저장되며, 해당 소켓에 따라 태그가 지정됩니다.
Fetch Stage는 동시에 수신된 패킷을 병합하는 메커니즘을 사용합니다. 개별 패킷 처리 작업 수를 줄이는 동시에 처리량을 높입니다. 전달된 패킷을 수신하면 이후 단계에서 이를 올바르게 인식하도록 FORWARDED 플래그로 표시합니다. 노드가 현재 리더가 아니면 불필요한 처리를 방지하기 위해 전달된 패킷을 폐기합니다. 반면 노드가 리더라면 해당 패킷을 수용하고 적절히 처리합니다.
Fetch Stage는 제한 없는 채널(예: packet_sender, packet_receiver)을 생성해 트랜잭션을 다음 단계인 SigVerify Stage로 전달합니다. 이 채널은 TPU의 각 단계를 분리하여 서로에게 차단되지 않고 동시에 작동할 수 있게 합니다. unbounded 함수는 채널 오버플로로 패킷이 삭제되지 않도록 용량 제한이 없는 채널을 생성합니다.
트랜잭션은 128개 패킷 단위의 배치로 묶인 후 SigVerify Stage로 전달됩니다. 이 배치 처리는 트랜잭션 처리 효율을 높이고 개별 패킷 처리에 드는 오버헤드를 줄입니다.
Fetch Stage는 높은 처리량을 지원하기 위해 여러 스레드에서 작동합니다. 각 스레드는 패킷 수신, 배치 처리, 트랜잭션 전달과 같은 특정 작업을 담당합니다. streamer::receiver 함수를 사용해 각 소켓 유형(즉, tpu, tpu_vote, tpu_forwards)별 스레드를 생성합니다. 각 스레드는 할당된 소켓을 수신 대기하고 들어오는 패킷을 처리한 후 적절한 채널로 전송합니다.
Fetch Stage는 트랜잭션의 유입과 분류를 효율적으로 관리하여 Solana TPU의 이후 모든 처리 단계에 기반을 제공합니다.
SigVerify Stage
SigVerify Stage는 Solana 트랜잭션 처리 파이프라인의 두 번째 단계입니다. 트랜잭션의 무결성과 진위를 보장하는 데 매우 중요합니다.
이 단계에서 TPU는 제한 없는 채널을 통해 Fetch Stage에서 배치 처리된 트랜잭션을 받습니다. 주요 작업은 Ed25519 서명 체계를 사용해 트랜잭션 서명을 검증하는 것입니다. 이 암호학적 검증을 통해 관련 계정의 올바른 소유자가 트랜잭션에 서명했는지 확인합니다.
SigVerify Stage는 최신 CPU와 GPU의 병렬 처리 기능을 활용해 서명을 검증하도록 고성능으로 설계되었습니다. 기본적으로 CPU가 모든 처리를 수행합니다. 하지만 병렬화 특성 덕분에 성능 라이브러리를 사용할 수 있을 때 GPU로 작업을 오프로딩하면 처리 속도가 크게 향상됩니다.
프로세스는 SigVerify Stage를 초기화하고 Fetch Stage에서 패킷을 받을 수신 채널을 설정하는 new 함수로 시작합니다. verifier 함수는 브래킷을 수신하고 서명을 검증합니다. 중복 제거를 처리하고, 과도한 패킷을 폐기하며, 남은 패킷을 검증합니다. 이 함수는 서명 검증의 ed25519_verify 메서드를 사용합니다. 트랜잭션이 많은 기간에는 부하 차단이 발생합니다. SigVerify Stage가 과도한 패킷을 폐기하는 과정입니다. 패킷을 소스 IP 주소별로 그룹화하고 주소마다 처리할 최대 패킷 수를 할당하는 방식으로 수행합니다.
서명이 유효하지 않은 트랜잭션은 표시 후 폐기됩니다. 이 과정을 통해 유효한 트랜잭션만 다음 단계로 넘어가며, 사기성 또는 잘못된 트랜잭션의 진행을 막습니다.
서명 검증 후 유효한 트랜잭션은 또 다른 제한 없는 채널 집합을 통해 다음 단계인 Banking Stage로 전달됩니다. 이를 통해 각 단계는 계속 분리된 상태로 동시에 작동할 수 있습니다. 이 단계도 여러 스레드에서 작동합니다. 각 스레드는 트랜잭션의 일부를 처리하고 서명을 검증하며 중복 제거와 부하 차단을 수행합니다.
Banking Stage
Banking Stage는 Solana 트랜잭션 처리 파이프라인의 세 번째 단계입니다. 트랜잭션이 실행되어 원장의 현재 상태에 적용되는 중요한 단계입니다. Banking Stage는 Solana의 고유한 Sealevel 런타임을 활용해 처리량이 높은 병렬 트랜잭션 처리를 지원합니다.
Banking Stage에는 6개의 스레드가 있습니다. 2개는 TPU 또는 Gossip에서 들어오는 투표 트랜잭션 처리 전용이며, 4개는 비투표 트랜잭션 전용입니다. 각 스레드는 독립적으로 작동하며, SigVerify가 패킷을 배치 단위로 보내는 공유 채널에서 패킷을 수신합니다. 이 구조는 1.18 이후 변경될 예정입니다. 각 스레드는 이 공유 채널에서 트랜잭션을 가져와 로컬 버퍼에 저장합니다. 로컬 버퍼는 우선순위 큐 역할을 하며, 트랜잭션 상태와 네트워크 수요의 실시간 변화를 반영하도록 동적으로 업데이트됩니다.
트랜잭션 처리 방식은 검증인이 리더 일정에 포함되어 있는지에 따라 달라집니다. 검증인이 곧 리더가 될 예정이 아니라면 패킷을 다음 리더에게 전달한 후 삭제합니다. 리더 차례가 가까워지면(약 20슬롯 전) 계속 패킷을 전달하되, 다음 리더가 처리하지 못할 경우에 대비해 이를 보관합니다. 리더가 되기 두 슬롯 전부터는 리더가 되었을 때 처리할 수 있도록 패킷을 유지합니다.
각 스레드는 블록 생성 중 로컬 큐의 최상위 트랜잭션 128개를 가져와 처리합니다. 잠금, 확인, 로드, 실행, 기록, 커밋, 잠금 해제 등의 단계를 거칩니다.
Banking Stage는 멀티 이터레이터 방식을 사용해 트랜잭션을 배치로 묶습니다. 이 방식은 데이터 세트를 동시에 순회하면서 트랜잭션을 충돌하지 않는 배치로 그룹화합니다. 먼저 트랜잭션을 우선순위 기반 벡터로 직렬화합니다. 그런 다음 멀티 이터레이터가 트랜잭션이 충돌하지 않는 지점에 이터레이터를 배치해 128개 트랜잭션으로 구성된 배치를 만듭니다. 충돌하는 트랜잭션은 건너뛰고, 충돌이 해소되면 이후 배치에 포함합니다. 배치가 만들어지면 트랜잭션을 실행합니다. 성공한 트랜잭션은 역사 증명 Service에 기록되고 Turbine을 통해 네트워크로 브로드캐스트됩니다.
역사 증명(PoH) Service
역사 증명(PoH) Service는 Solana 트랜잭션 처리 파이프라인의 핵심 구성 요소입니다. 네트워크 내 시간과 이벤트 순서를 검증 가능하게 추적하여 트랜잭션을 효율적이고 안전하게 배열합니다. 해시 체이닝을 통해 트랜잭션의 타임스탬프 역할을 하는 암호학적 시퀀스를 생성합니다. 이 연속적인 해시 체인은 이벤트 사이에 시간이 흘렀음을 증명하는 기록을 만듭니다.
PoH Service를 통해 모든 네트워크 참여자는 중앙 시간 관리자 없이도 트랜잭션 순서에 합의할 수 있습니다. 네트워크 전반의 검증인을 동기화하는 데도 도움이 됩니다. 또한 검증인이 언제 리더가 되어 다음 블록을 생성해야 하는지 판단할 신뢰할 수 있는 타임스탬프를 제공하여 Solana의 리더 선출 프로세스를 지원합니다.
PoH Service는 해시 시퀀스를 생성하는 시드 값을 초기화하면서 시작합니다. 트랜잭션을 수신하면 현재 PoH 시퀀스의 해시로 태그하여 고유한 타임스탬프를 부여합니다. 이후 검증인은 해시 시퀀스를 검증해 트랜잭션의 순서와 시점을 확인합니다.
역사 증명에 대해 자세히 알아보려면 역사 증명, 지분 증명, 작업 증명 — 해설을 읽어보세요. 암호학이 낯설게 느껴진다면 암호학 도구 입문 — 해시 함수와 머클 트리 해설도 권합니다.
Broadcast Stage
Broadcast Stage는 Solana 트랜잭션 처리 파이프라인의 마지막 단계입니다. 검증 및 확인된 트랜잭션을 네트워크의 나머지 부분에 배포합니다.
Banking Stage에서 트랜잭션이 처리되고 커밋되면 엔트리로 구성됩니다. 이 엔트리는 샤드라는 데이터 구조로 패키징됩니다. Broadcast Stage는 샤드를 직렬화하고 서명한 후 데이터 무결성과 복구 능력을 높이기 위한 소거 코드를 생성합니다. 샤드는 Turbine이라는 구조화된 트리 형태의 전파 프로세스를 통해 피어에게 전송됩니다. 이는 효율적이고 중복성을 갖춘 배포 프로세스이며, 소거 코딩을 통해 검증인은 누락되거나 손상된 데이터를 재구성할 수 있습니다.
Turbine을 더 자세히 알아보려면 Turbine: Solana의 블록 전파를 읽어보세요.
SWQoS가 적용된 트랜잭션의 수명 주기
다른 블록체인과 달리 Solana에는 트랜잭션이 처리 전에 대기하는 멤풀이 없습니다. 대신 트랜잭션은 현재 리더에게 직접 라우팅되고 리더의 TPU에서 처리됩니다. 사용자는 지갑이나 애플리케이션을 통해 직접 또는 간접적으로 트랜잭션을 생성하고, JSON RPC API를 통해 RPC 노드에 제출합니다. 이 노드들은 사용자와 Solana 검증인 사이의 중개자 역할을 합니다. 중요한 점은 네트워크에 어떠한 스테이크도 보유해서는 안 된다는 것입니다. 즉, RPC 노드는 스테이킹되지 않고 투표하지 않으며 합의에도 참여하지 않습니다.
이제 리더와의 연결은 QUIC을 통해 이루어집니다. Solana TPU에서 UDP를 대체하기 위해 사용자 트랜잭션을 수신하는 포트에 QUIC이 추가되었습니다. QUIC은 핸드셰이크가 필요하므로 행위자의 트래픽에 제한을 적용할 수 있습니다. 이를 통해 네트워크는 스팸을 걸러내면서 실제 트랜잭션 처리에 집중할 수 있습니다. 물론 이것이 QUIC을 구현한 목적이며, 현재의 효과에 대해서는 이 글에서 논하지 않습니다. 핵심은 리더와의 연결이 QUIC을 통해 이루어진다는 점입니다.
연결에는 두 가지 유형이 있습니다.
- 모든 RPC 노드가 이용할 수 있는 500개의 개방형 연결
- 스테이킹된 검증인만 이용할 수 있는 2,000개의 지분 가중 연결. 검증인은 자신의 스테이크에 비례해 연결을 할당받습니다
RPC가 트랜잭션을 효과적으로 중계하려면 스테이킹된 검증인과 피어링해야 합니다. RPC는 네트워크에 스테이크가 없으므로 검증인이 자신의 스테이크를 가상으로 확장해야 합니다. 검증인은 --staked-nodes-overrides 플래그를 사용해 스테이킹된 연결의 일부를 특정 RPC 노드에 할당할 수 있습니다.
검증인은 지분 가중 연결을 구성하기 위해 --staked-nodes-overrides flag를 사용해 YAML 파일 경로를 지정해야 합니다. YAML 파일에는 다음 형식의 매핑이 포함됩니다.
staked_map_id:
<pubkey_of_RPC>: 80000000000000000지정된 RPC ID의 모든 공개 키에는 lamports 단위의 값이 필요합니다. 이 값은 RPC ID에 부여할 스테이크 가중치를 지정합니다. 예를 들어 100만 SOL을 지정하면 전체 활성 스테이크 중 100만 SOL이 차지하는 비율만큼 할당합니다. 본질적으로 해당 RPC 노드를 네트워크에서 그만큼의 스테이크를 보유한 검증인처럼 취급해 스테이킹된 연결을 제공하는 것입니다. 즉 “내 로컬 관점에서는 이 RPC ID가 내 검증인과 통신할 때 x만큼의 스테이크를 보유한 것으로 취급하라”고 지정하는 셈입니다. 이 설정에는 검증인 재시작이 필요하지 않습니다. 파일을 변경하고 즉시 다시 로드할 수 있습니다.
또한 Jito 릴레이어는 스테이킹된 노드 재정의 플래그를 지원합니다. 성능을 최적화하려면 릴레이어를 스테이킹된 노드와 동일한 머신에서 실행하는 것이 좋습니다.
이 스테이킹된 연결을 사용하려면 RPC 운영자는 --rpc-send-transaction-tpu-peer 플래그를 사용해야 합니다. 이 플래그에는 스테이킹된 검증인의 TPU IP와 포트가 필요합니다. Gossip에서 확인되는 TPU 포트는 일반적으로 동적 포트 범위에 3을 더한 값으로 시작합니다. Jito의 경우 공개 Jito 릴레이어를 사용할 수 없으므로 트래픽은 운영자가 실행하는 릴레이어로 전송됩니다. RPC 운영자는 연결을 확인하기 위해 로그에서 solana_quic_client 및 warm와 같은 항목을 확인해야 합니다. 이 설정에 필요한 플래그를 지원하려면 RPC 노드에서 v1.17.28 이상의 Agave 클라이언트를 실행해야 합니다.
전반적으로 SWQoS가 적용된 트랜잭션의 수명 주기는 일반 트랜잭션과 거의 같습니다. 사용자가 RPC 노드를 통해 트랜잭션을 생성하고 제출하면 리더에게 전송됩니다. 다만 RPC 노드가 스테이킹된 검증인과 피어링되어 있고 --rpc-send-transaction-tpu-peer 플래그를 사용하면 트랜잭션이 스테이킹된 연결을 통해 전송됩니다. 요약하면 다음과 같습니다.
- 트랜잭션 생성: 사용자가 지갑이나 애플리케이션을 사용하거나 프로그래밍 방식으로 트랜잭션을 생성합니다
- RPC 노드에 제출: JSON RPC API를 통해 트랜잭션을 RPC 노드에 제출합니다
- QUIC 연결: RPC 노드는 구성에 따라 개방형 또는 지분 가중 연결을 활용해 리더와 QUIC 연결을 설정합니다
- 지분 가중 QoS: RPC 노드가 스테이킹된 검증인과 피어링되어 있다면 검증인의 스테이킹된 연결을 사용해 트랜잭션 성능을 높입니다
- 리더에게 전달: 트랜잭션은 스테이킹된 연결을 통해 리더에게 전송되며, 지연되거나 삭제될 가능성이 낮아집니다
- 트랜잭션 처리: 앞서 설명한 대로 트랜잭션이 TPU를 거쳐 리더에 의해 처리됩니다
SWQoS는 스테이킹된 검증인과 피어링된 RPC 노드가 리더에게 더 원활히 접근할 수 있게 해 트랜잭션 수명 주기를 개선하고, 네트워크 혼잡으로 인한 지연 가능성을 줄입니다. 이 메커니즘은 우선순위 수수료와 함께 작동해 트랜잭션 성능을 향상합니다.
SWQoS와 우선순위 수수료: 명확한 차이
네트워크가 혼잡할 때 SWQoS는 스테이크가 많은 검증인의 트랜잭션이 지연되거나 삭제될 가능성을 낮춥니다. 이 시스템은 흔히 스테이크가 많은 검증인이 고속도로의 추가 차선처럼 덜 혼잡한 경로를 이용하는 유료 도로에 비유됩니다. 위 사진을 예로 들어보겠습니다. 콜로라도의 운전자는 정체 속에서 기다리거나 몇 달러를 더 내고 유료 차로를 이용할 수 있습니다. Express Lanes는 콜로라도의 프리미엄 차로망으로, 원활한 교통 흐름을 유지할 수 있도록 가격을 계속 조정합니다. 따라서 Solana의 스테이킹된 연결은 프리미엄 사용자의 혼잡을 줄이기 위한 우선 경로라는 점에서 콜로라도의 Express Lanes와 비슷합니다.
하지만 일반적으로 사용되는 유료 도로 비유는 두 개념의 차이를 흐릴 수 있으므로 SWQoS와 우선순위 수수료를 명확히 구분해야 합니다.
- 우선순위 수수료는 Banking Stage에서 리더가 지불된 수수료에 따라 트랜잭션의 우선순위를 정할 때 적용됩니다. 더 높은 수수료를 지불한 트랜잭션을 먼저 처리하여 추가 비용을 지불하려는 사용자가 더 빠르게 실행할 수 있게 하는 방식입니다.
- SWQoS는 연결 접근성을 개선하며 리더의 트랜잭션 큐 안에서 트랜잭션 우선순위를 바꾸지 않습니다. 스테이킹된 검증인이 네트워크에 더 원활히 접근하도록 하여 네트워크 혼잡으로 트랜잭션이 지연되거나 삭제될 가능성을 줄입니다
우선순위 수수료는 리더의 큐에 들어온 트랜잭션의 순서와 처리 방식에 영향을 줍니다. 반면 SWQoS는 스테이킹된 검증인이 보낸 트랜잭션이 리더에게 도달하는 우선 경로를 확보합니다. 두 메커니즘 모두 네트워크 성능 개선을 목표로 하지만 트랜잭션 수명 주기의 서로 다른 단계에서 작동합니다.
SWQoS 전쟁
앞으로 SWQoS는 Solana 네트워크 인프라의 핵심 요소가 될 것입니다. 트랜잭션 처리를 최적화하고 스테이킹된 검증인에서 리더로 향하는 연결에 우선순위를 부여함으로써 생태계에 큰 영향을 미칠 것입니다. 아무리 강조해도 지나치지 않습니다.
네트워크가 혼잡하지 않고 트랜잭션에 시간 민감성이 없을 때는 스테이크가 많은 검증인을 사용하는 이점이 줄어든다고 볼 수 있습니다. 네트워크에 트랜잭션을 빠르게 처리할 충분한 용량이 있어 그 배후의 스테이크 가중치가 중요하지 않기 때문입니다. 하지만 대중화와 함께 Solana 수요가 증가하면 네트워크가 항상 모든 트랜잭션을 지연이나 간헐적인 삭제 없이 처리할 충분한 용량을 갖추지는 못할 수 있습니다. 이는 Solana가 확장할 수 없다는 뜻이 아닙니다. Solana는 확장 가능한 블록체인을 실현할 가장 유력한 후보 중 하나이며, 어쩌면 최고의 후보일 수 있습니다. 핵심은 수요가 늘수록 탁월한 UX를 제공하는 데 SWQoS가 계속 중요하다는 점입니다.
이에 따라 검증인의 역할은 더욱 중요해지고, 최상의 서비스를 제공하기 위한 경쟁과 혁신도 활발해질 것입니다. 그렇다면 자연스럽게 모두가 자체 검증인을 운영하려 하지 않을까요?
검증인과 유동성 스테이킹 토큰(LST)
추세는 분명합니다. 모든 진지한 Solana 프로토콜은 검증인을 운영하게 될 것입니다. 자체 애플리케이션을 지원하는 데 필요하기 때문입니다. 자체 검증인 운영에 관심이 있다면 Helius 블로그의 시작 가이드를 확인해 보세요.
Solana에서 LST가 폭발적으로 증가하는 거대한 캄브리아기 대폭발을 앞두고 있으며, SWQoS는 이를 더욱 가속하고 있습니다. 이번 달에만 총 스테이크(즉, 네이티브 + LST)가 약 320만 증가했습니다. LST만의 시장 가치는 이번 달 현재 60억~90억 달러 수준입니다. Sanctum과 같은 프로토콜은 검증인과 앱이 자체 LST를 만들 수 있는 플랫폼을 제공하므로 주요 주자로 자리 잡을 가능성이 큽니다. 또한 Picasso Network는 Solana에서 리스테이킹을 지원하고, LST가 더 큰 유용성과 수익률을 확보할 수 있는 허브 역할을 합니다. 추가 유용성을 갖춘 LST를 만드는 기능은 이미 본격적으로 활용되고 있습니다.
하지만 몇 가지 잠재적인 진입 장벽을 고려해야 합니다.
진입 장벽
SWQoS는 잠재적 이점에도 불구하고 여러 진입 장벽을 만듭니다. 특히 스테이크가 적은 검증인을 스테이킹되지 않은 피어로 취급하기 위한 최소 스테이크 요건이 Agave 클라이언트 v1.17.31에 도입되었습니다. 스테이크가 적은 노드가 불균형하게 많은 대역폭을 받아 스테이킹된 연결을 악용할 수 있었기 때문입니다. 이제 스테이크 비율이 다음 공식보다 낮은 노드는 스테이킹되지 않은 것으로 취급됩니다.
stake / total_stake < 1 / (max packet per 100ms)즉, 스테이킹된 SOL이 약 15,000개 미만인 클라이언트는 이제 스테이킹되지 않은 검증인으로 분류됩니다. 이 요건은 이미 재정적·기술적 부담이 큰 Solana 검증인 운영의 문턱을 더 높여 소규모 참여자와 독립 검증인의 네트워크 참여를 막을 수 있습니다. 약 300만 달러에 해당하므로 언뜻 보면 큰 금액입니다.
하지만 Austin Federa가 지적했듯이, 이 기준은 전체 스테이크의 25,000분의 1에 불과하므로 낮다고 볼 수 있습니다. 또한 스테이크를 두고 경쟁하는 검증인 대부분이 최상의 서비스를 제공하고 자체 수익을 극대화하기 위해 지속적으로 성능을 개선한다면 네트워크 전체에 도움이 됩니다. 이것이 바로 Toly가 설명한 SWQoS의 전반적인 목표입니다.
Helius는 Helius 권장 수수료로 트랜잭션을 전송하는 모든 유료 플랜의 진입 장벽을 낮추고 있습니다. 즉, 유료 공유 플랜을 통해 트랜잭션을 전송하는 모든 사용자는 Priority Fee API가 제공하는 권장값 이상의 수수료를 설정하면 Helius의 스테이킹된 연결로 라우팅됩니다. 또한 Node.js 및 Rust SDK에 추가된 새로운 Smart Transactions 기능으로 이 프로세스를 간소화했습니다. 기본적으로 어떤 SDK를 사용하든 사용자는 키페어와 실행할 명령만 제공하면 나머지는 Helius가 처리합니다. 이제 사용자는 월 50달러의 Developer 플랜만으로 공유 스테이킹 연결을 이용할 수 있습니다. 스테이킹 연결 대역폭을 보장하는 전용 스테이킹 연결도 제공하며, 엔터프라이즈, 퀀트, 트레이딩 기업에 권장합니다. 전용 스테이킹 연결에 관심이 있다면 영업팀에 문의하세요.
스테이크는 0% 수수료를 부과할 수 있는 대형 프로토콜과 RPC 제공업체가 운영하는 검증인에 집중되기 시작할 가능성이 큽니다. Helius를 예로 들면, 다른 사업에서 수익을 창출해 검증인 운영 비용을 일부 충당할 수 있습니다. Solana 네이티브 팀이 상위 검증인을 운영하여 네트워크의 탈중앙화를 개선하는 동시에, 스테이킹된 연결에 더 폭넓게 접근해 사용자 경험을 개선하기 위해서입니다.
신뢰 가정
스테이크가 대형 프로토콜과 RPC 제공업체가 운영하는 검증인에 집중될 가능성이 크다면, Solana의 최선의 이익을 고려하는 검증인에게 스테이킹하는 것이 중요합니다. SWQoS에는 여러 신뢰 가정이 따릅니다.
주요 신뢰 가정 중 하나는 검증인과 RPC 노드 사이에 높은 수준의 신뢰가 필요하다는 점입니다. 앞서 설명했듯이 SWQoS를 사용하면 리더가 스테이킹된 검증인의 트랜잭션을 식별하고 우선 처리할 수 있습니다. RPC 노드는 스테이킹되지 않고 투표하지 않으며 합의에도 참여하지 않으므로 스테이킹된 검증인과 같은 방식으로 우선 트랜잭션의 혜택을 직접 받을 수 없습니다. 따라서 SWQoS의 이점을 활용하려면 검증인과 RPC 노드 사이에 신뢰 관계가 형성되어야 합니다.
SWQoS를 활성화하려면 민감한 네트워크 구성을 공유해야 하고 RPC 노드가 트랜잭션 우선순위에 영향을 줄 수 있으므로 이 신뢰 관계는 매우 중요합니다. 검증인은 피어링하는 RPC 노드가 네트워크에 가장 유리하게 행동하고 확장된 스테이크를 악의적인 목적으로 남용하지 않을 것인지 확인해야 합니다. 검증인과 RPC 노드는 스테이킹된 연결을 어떻게 사용할지 사전에 합의하고 서로 이해해야 합니다. 이상적으로는 오랜 파트너나 같은 조직처럼 신뢰도가 높은 주체 사이에서 설정해야 합니다.
현재 이러한 관계는 드러나지 않는 경우가 많습니다. 앞으로 RPC 운영자가 스테이킹 재정의를 위해 검증인과 협상하지 않는 미래는 상상하기 어렵습니다. 일반 사용자가 자신이 지원하는 RPC와 검증인을 알 수 있도록 투명성을 높여야 합니다. 이에 대한 요구는 시간이 갈수록 커질 것입니다.
결론
SWQoS는 Solana의 네트워크 인프라를 혁신할 준비를 마쳤습니다. 트랜잭션 성능 향상과 시빌 저항성 개선을 비롯해 많은 이점을 제공하지만, 신중하게 해결해야 할 새로운 과제와 신뢰 가정도 만듭니다. SWQoS는 스테이킹된 검증인이 보낸 트랜잭션에 우선순위를 부여하도록 설계되었지만, 현재 이 우선순위를 강제하는 장치는 없습니다. 진지한 검증인은 기본 설정을 덮어쓰는 경우가 많고 특정 행위자를 차단할 수도 있습니다. 이는 SWQoS를 공정하고 효과적으로 사용하려면 검증인과 RPC 노드 간 관계에서 신뢰와 투명성이 필요하다는 점을 보여줍니다. 그럼에도 SWQoS 도입은 Solana가 효율적이고 복원력 있는 네트워크로 발전하는 데 중요한 진전입니다.
이 글에서는 SWQoS와 이것이 트랜잭션 처리에 미치는 영향을 살펴봤습니다. SWQoS와 우선순위 수수료의 차이처럼 중요한 구분도 다뤘습니다. 또한 검증인과 LST의 부상, 잠재적 진입 장벽, 관련된 신뢰 가정을 논의하여 향후 논의를 위한 중요한 출발점을 제시했습니다. 이 모든 요소를 이해하는 것은 SWQoS를 효과적으로 활용하고 Solana 전체를 개선하는 데 매우 중요합니다.
여기까지 읽어주셔서 감사합니다, 익명의 독자 여러분! 아래에 이메일 주소를 입력해 Solana의 새로운 소식을 놓치지 마세요. 더 깊이 알아볼 준비가 되셨나요? 지금 Helius 블로그의 최신 글을 살펴보고 Solana 여정을 이어가세요.
추가 자료
Helius 구독하기
최신 Solana 개발 소식을 확인하고 새 게시물 알림을 받아보세요