Solana 수수료의 이론과 실제

소개

Solana의 수수료 구조는 수요와 공급의 불균일한 충격에 대응하면서 네트워크 성능을 유지하도록 설계되었습니다. 모든 블록체인에서 수수료는 스팸을 방지하고 검증인에게 인센티브를 제공하는 역할을 합니다. Solana에서는 이러한 수수료 중 일부를 네트워크 상황에 따라 동적으로 조정하여 특정 시점의 수요를 더 정확하게 반영합니다.

Solana의 수수료는 뜨거운 주제입니다. 특히 “로컬 수수료 시장”은 Solana가 블록 공간과 특정 계정의 가격을 더 정확하게 책정할 수 있도록 어느 정도의 표현력을 제공합니다. 현재 구현은 완벽과 거리가 멀지만, 계정별 순서에 대해서는 느슨한 보장을 제공합니다. Solana는 아직 초기 단계지만 네트워크의 스테이킹 규모와 활동이 증가함에 따라 수수료 모델 변경과 같은 프로토콜 변경이 초래할 1차 및 2차 효과를 더 심도 있게 논의하고 분석해야 합니다.

이 글에서는 수수료의 이론과 온체인에서 실제로 나타나는 양상을 살펴봅니다. 일각에서는 Solana가 중앙화되어 있으며, 스테이킹 가중 QoS 설계와 Turbine이 중앙화를 촉진한다고 비판해 왔습니다. 그러나 수년에 걸친 현실의 양상은 이러한 주장과 뚜렷한 차이를 보였습니다. 마찬가지로 이 글에서는 온체인 동작을 통해 수수료가 실제로 어떻게 나타나는지 종합적으로 분석합니다.

수수료의 이론

Solana의 수수료 시스템은 기본 수수료와 우선순위 수수료, 두 가지 요소로 구성됩니다. 각 수수료 요소는 대체로 다음 역할을 수행하는 것이 이상적입니다.

• 기본 수수료: 네트워크 리소스를 사용할 권리
• 우선순위 수수료: 리더의 트랜잭션 대기열 내 순서 결정

기본 수수료

현재 서명당 0.000005 SOL(5,000 lamports)로 설정된 기본 수수료는 트랜잭션 비용의 기반을 이룹니다. 주소가 네트워크 리소스를 사용할 권리를 얻기 위해 지불하는 수수료입니다. 트랜잭션 실행에 실제로 사용된 리소스의 양이나 트랜잭션의 실행 여부와 관계없이 네트워크에 선불로 일괄 지급합니다. Solana 트랜잭션은 지정된 수의 컴퓨팅 유닛(CU)을 미리 요청하며, 이 수를 초과하면 트랜잭션이 실패합니다. 따라서 현재 개발자에게는 컴퓨팅 유닛 요청을 최소화할 경제적 유인이 거의 또는 전혀 없습니다.

우선순위 수수료

사용자는 블록에 포함될 가능성을 높이고 트랜잭션을 더 빠르게 처리하기 위해 우선순위 수수료를 지불할 수도 있습니다. 이는 비용을 지불한 사용자에게 우선순위를 제공하지만, 확정적으로 보장하지는 않습니다. 트랜잭션의 결정성을 개선하기 위한 작업이 진행 중이며, 1.18에 중요한 스케줄러 변경 사항이 적용될 예정입니다.

참고로 투표 트랜잭션에는 우선순위 수수료가 없으며 일반 트랜잭션과 다르게 처리됩니다.

검증인이 우선순위 수수료가 포함된 트랜잭션을 처리할 유인은 런타임 외부에 존재합니다. 리더는 해당 트랜잭션을 자신의 블록에 포함한 대가로 우선순위 수수료의 50%를 받고, 나머지 50%는 소각됩니다.

현재 대부분의 검증인(80% 이상)은 수정하지 않은 Solana Labs 또는 Jito-Solana 클라이언트를 실행합니다. 즉, 이 검증인들은 “블록 생성”을 기본 스케줄러에 맡깁니다. Solana에서는 “블록 순서 지정”을 “블록 생성”이라고 부르는 경우가 있지만, Ethereum에서 블록 생성은 전혀 다른 의미입니다. 일부 팀은 클라이언트 코드를 수정하고 순서 지정 흐름을 더 세밀하게 제어할 수 있는 복잡한 스케줄러를 구현했습니다. 이를 통해 트랜잭션 순서를 바꾸거나 샌드위치 공격을 수행하여 MEV를 추출하기도 합니다.

우선순위 수수료의 비결정성

현재 스케줄러 구현은 우선순위 수수료가 더 높은 트랜잭션이 특정 블록에 포함된다고 보장하지 않습니다. 대신 우선순위 수수료가 있는 트랜잭션이 특정 블록에 포함될 가능성이 더 높다는 느슨한 보장만 제공합니다. 현재 스케줄러 구현은 4개의 실행 코어를 사용하며, 추가 코어 2개는 투표 트랜잭션용으로 예약됩니다.

각 스레드는 자체 대기열을 운영하며 다른 스레드가 처리 중인 패킷을 알지 못한 채 독립적으로 패킷의 우선순위를 지정합니다. 각 스레드는 시작부터 끝까지 계속 순환하며 트랜잭션의 잠금을 확보하고 실행하려고 시도합니다. 현재 주기를 완료하면 패킷을 더 수집한 뒤 다시 주기를 시작합니다.

따라서 한 스레드의 대기열 맨 앞에서 우선순위가 높은 트랜잭션을 처리하는 동시에, 다른 스레드에서는 같은 계정이 관련된 트랜잭션을 처리하며 자체 대기열을 마무리하고 있을 수 있습니다.

스케줄러의 현재 및 향후 구현에 관한 구체적인 내용은 별도 글에서 살펴보겠습니다. 우선순위 수수료가 스레드 내(자체 레인 내부)에서만 작동하고 스레드 간(레인 사이)에는 작동하지 않는다는 점만 이해해도, 스케줄러가 완벽과 거리가 멀고 “지터”가 발생한다는 사실을 알 수 있습니다.

수수료의 실제

트랜잭션 처리 성공

수수료는 트랜잭션의 처리 성공 여부를 좌우하는 주요 요인이지만 유일한 결정 요인은 아닙니다. 예를 들어 UDP 네트워크 패킷이 손실되어 트랜잭션이 처리되지 않을 수 있습니다. 네트워크 활동이 많은 시기에는 검증인이 처리할 수 있는 양보다 많은 트랜잭션이 몰릴 수 있습니다. 검증인은 tpu_forwards 메커니즘을 통해 초과 트랜잭션을 전달할 수 있지만, 처리 가능한 데이터 양에는 한계가 있으며 각 트랜잭션을 중계할 수 있는 횟수도 블록 해시가 만료될 때까지로 제한됩니다. 스테이킹 가중 서비스 품질은 스테이킹 규모가 큰 주소에 예약 대역폭을 제공하고 트랜잭션 포함 가능성을 높여 이러한 문제를 일부 완화합니다.

트랜잭션이 누락되는 원인으로 잘 언급되지 않는 두 가지가 더 있습니다. 첫 번째는 RPC 풀 내 불일치입니다. RPC 풀의 한 구간이 다른 구간보다 앞서 나가면서 조정 문제가 발생할 수 있습니다. 예를 들어 더 최신 상태인 구간에서 트랜잭션의 recentBlockhash를 가져온 후 더 느린 구간에 제출하면, 후자는 업데이트된 블록 해시를 인식하지 못해 트랜잭션을 폐기할 수 있습니다. 개발자가 sendTransaction 함수에서 프리플라이트 검사를 활성화했다면 제출 시점에 이러한 문제를 발견할 수 있습니다.

임시 네트워크 포크와 관련된 문제도 있습니다. 검증인의 블록 처리가 지연되면 트랜잭션이 정식 체인이 되지 못하는 소수 포크에 포함될 수 있습니다. 클라이언트가 이 소수 포크에만 존재하는 recentBlockhash를 트랜잭션에서 참조하고, 네트워크가 트랜잭션을 처리하기 전에 해당 포크를 폐기하면 블록 해시를 더 이상 찾을 수 없어 트랜잭션이 누락됩니다.

우선순위 수수료

실제로 우선순위 수수료는 완벽과 거리가 멀지만 거시적 규모에서는 작동한다는 증거가 있습니다. 우선순위 수수료가 포함된 트랜잭션은 블록에 포함될 가능성이 더 높으며, 더 높은 우선순위 수수료를 설정한 트랜잭션일수록 포함 가능성도 커집니다.

Helius RPC 데이터에 따르면 우선순위 수수료가 있는 트랜잭션은 처리될 가능성이 더 높으며, 처리에 성공하는 경우 전반적으로 더 빠릅니다.

1월 21일에는 다음 주에 있을 실제 JUP 에어드롭을 준비하기 위한 mockJUP 에어드롭으로 평균 우선순위 수수료가 급등했습니다. 블록 공간 수요는 크게 변했지만 실제 사용자가 체감한 트랜잭션 처리 성공률과 시간에는 비교적 변화가 적었습니다.

이 UX를 주로 지원하는 것은 Solana RPC 메서드인 getRecentPrioritizationFees입니다. 개발자는 이를 사용해 트랜잭션에 추가할 우선순위 수수료를 정확하게 결정할 수 있습니다. 이 엔드포인트는 해당 주소와 입력 매개변수로 하나 이상의 트랜잭션을 성공적으로 처리하는 데 사용된 최근 150개 블록의 우선순위 수수료 목록을 반환합니다. 이를 통해 우선순위 수수료에 설정해야 할 최소값을 파악할 수 있지만 활용도는 비교적 제한적입니다. Helius의 Priority Fee API를 사용하면 추가 계산을 거쳐 더 정확한 우선순위 수수료 추정치를 얻을 수 있습니다.

이론적으로 우선순위 수수료는 어느 정도 의도대로 작동하지만, 1.18에 예정된 스케줄러 개선은 트랜잭션 포함에 더 높은 결정성을 제공할 것입니다. 트랜잭션을 포함하기 위해 체인에 스팸을 보낼 필요가 없어지므로 온체인에 유입되는 스팸의 양도 줄어들 것입니다.

기본 수수료

Solana의 기본 수수료는 분명 지나치게 낮습니다. 블록은 포화되지만 기본 수수료가 동적이지 않아 블록 공간의 시장 청산 가격에 도달하지 못합니다. Ethereum에서는 최근 블록을 살펴보고 50%의 사용률을 목표로 하는 EIP-1559의 제어 메커니즘을 통해 동적 기본 수수료를 구현합니다.

Solana는 서명당 5,000 lamports로 가격을 고정하며, 일반적으로 트랜잭션당 서명은 1개입니다. 기본 수수료가 블록 공간 수요와 검증인 리소스 사용량의 변화를 전혀 반영하지 않으므로 효과적인 수수료가 아닙니다. 이에 따라 우선순위 수수료가 사실상 시장 기반 대안 역할까지 떠안게 됩니다. 검증인은 포함될 가능성이 거의 없는 추가 트랜잭션도 처리하므로 네트워크 혼잡이 심해집니다. 또한 포함 가능성을 높이기 위해 최소한의 우선순위 수수료로 많은 트랜잭션을 제출하는 것이 지배적인 전략입니다. 이는 모든 네트워크 참여자의 UX에 막대한 외부효과를 초래합니다.

인센티브

RPC는 최소 비용으로 트랜잭션 포함률을 극대화하기 위해 정확한 정보를 다운스트림으로 전달할 유인이 있습니다. 상위 스테이킹 검증인과 통합하면 RPC가 네트워크의 현재 상태를 더 정확하게 파악할 수 있습니다. Solana의 여러 메커니즘이 스테이킹 가중 방식으로 작동하기 때문입니다. 상당한 스테이킹을 보유한 검증인과 통합 RPC가 트랜잭션 처리의 효율성과 신뢰성을 높이는 공생 관계가 형성됩니다. 이는 상위 스테이킹 검증인의 입지를 더욱 공고히 하는 피드백 루프를 만들 수 있습니다.

또한 현재 스테이킹이 0인 검증인으로 취급되는 RPC에도 스테이킹 가중치가 적용될 예정입니다. RPC는 검증인과 제휴하지 않고 직접 스테이킹을 유치할 수 있습니다. 애플리케이션이 수직 통합을 강화하기 위해 자체 검증인을 운영하는 경우도 드물지 않습니다. 이를 통해 최종 사용자 경험과 트랜잭션/MEV 공급망을 더 세밀하게 제어할 수 있습니다.

경제적 인센티브는 스테이킹 중앙화 추세를 시사하지만, Solana에서는 스테이킹 가중 이익을 위한 대규모 자본 집중이 나타나지 않았습니다. 여기에는 여러 이유가 있을 수 있습니다.

• 개인은 주로 Solana의 문화와 소셜 레이어에 따라 로컬 탈중앙화를 극대화하는 것이 네트워크의 장기적 이익을 위한 지배적 전략이라고 판단할 수 있습니다.
• Solana 참여자의 대부분은 리테일 사용자와 프로슈머였으며 전문 기업만큼 수익률에 민감하지 않습니다. 활동 수준과 절대 수익이 증가하면 참여자 구성과 수익률 민감도가 달라질 수 있습니다.
• 개인은 차별화된 상품을 마케팅하는 과정에서 원활하게 협력하지 못하고 있습니다.

결론

이 글에서는 Solana 수수료 메커니즘의 상위 수준 이론과 이것이 온체인 네트워크에 미치는 영향을 자세히 설명했습니다. 수수료는 인센티브를 형성하며, 이는 큰 외부효과를 일으키고 Solana의 모든 참여자 행동에 영향을 줍니다.

Solana의 기본 수수료와 우선순위 수수료 같은 메커니즘은 현재 구현 상태로는 완벽하지 않습니다. 기본 수수료는 조정할 수 없으며 현재 수요와 공급의 균형을 반영하지 못합니다. 이로 인해 네트워크 혼잡과 비효율적인 리소스 할당 같은 문제가 발생합니다. 현재 스케줄러 구현으로 인해 우선순위 수수료에도 어느 정도 비결정성이 나타납니다. 예정된 스케줄러 변경과 같은 향후 업데이트는 트랜잭션 처리의 결정성과 효율성을 높여 현재 관찰되는 온체인 동작을 재편할 가능성이 있습니다.

쓰기 잠금 계정에 대한 지수형 수수료처럼 새로운 제안도 등장하고 있습니다. 이 제안은 계정 접근을 임의로 잠그는 트랜잭션의 비용을 더 정확히 책정하는 것을 목표로 합니다. 상태 접근 비용을 더 정확히 책정하는 동적 기본 수수료 메커니즘에 관한 논의도 진행 중입니다.

수수료, 검증인, RPC의 상호작용은 복잡한 인센티브의 그물망입니다. 이론적으로 검증인과 RPC는 통합하고 스테이킹 가중치를 높일 유인이 있으며, 이는 중앙화 우려로 이어질 수 있습니다. 그러나 실제로 Solana는 탈중앙화된 운영자와 스테이킹 구성을 유지해 왔습니다. 이는 커뮤니티 주도의 거버넌스, 기술적 장벽, 경제적 상쇄 인센티브, 그리고 현재의 최적화 함수가 수익률을 최우선으로 삼지 않는다는 점에 기인한 것으로 보입니다.