Solana 로컬 수수료 시장의 진실

실행 가능한 인사이트

• 로컬 수수료 시장(LFM)을 통해 Solana는 경합 수준에 따라 개별 상태에 세분화된 수수료를 설정할 수 있습니다. 트랜잭션은 쓰기 대상인 특정 상태를 기준으로 수수료를 지불하므로, 국소적인 핫스팟 때문에 블록체인 전체의 수수료가 상승하는 일을 방지합니다. 
• LFM은 모든 애플리케이션이 원활하게 공존하는 확장 가능한 통합 베이스 레이어라는 Solana의 비전을 실현하는 데 필수적입니다. LFM이 없으면 체인의 한 부분에서 발생한 수수료 급등이 모든 트랜잭션의 수수료 상승으로 이어집니다. 이는 블록 공간 가격 책정에 글로벌 수수료 시장만 사용하는 다른 네트워크에서 흔히 나타나는 문제입니다.
• 2023년 말 Solana의 경제 활동이 가속하면서 초기 LFM 구현의 몇 가지 중대한 결함이 드러났습니다. 가장 두드러진 문제는 비결정적인 스케줄러 우선순위 지정이었습니다. 트랜잭션은 주로 블록 빌더에 도착한 시간을 기준으로 정렬됐고, 우선순위 수수료는 부차적으로만 고려됐습니다.
• 2024년 5월 Agave 클라이언트 v1.18 업데이트에서 새로운 트랜잭션 스케줄러와 개선된 트랜잭션 우선순위 공식이 도입됐습니다. 스케줄러는 종속성 그래프를 구축해 여러 스레드에서 충돌하는 트랜잭션의 처리와 우선순위 지정을 더 효과적으로 관리합니다. 이 대규모 업데이트로 프로토콜의 결정적 트랜잭션 정렬 능력이 크게 향상됐습니다.
• LFM의 실효성을 평가하는 유용한 지표는 트랜잭션 우선순위 수수료의 중앙값과 평균을 비교하는 것입니다. 경합이 없는 상태의 수수료(50번째 백분위수인 중앙값)는 낮게 유지될 것으로 예상됩니다. 반면 경합 상태의 수수료는 수요가 증가하면 급등해 평균을 끌어올려야 합니다. 최근 데이터는 이 패턴을 확인해 줍니다. 2024년 11월 비투표 트랜잭션의 평균 수수료는 사상 최고치인 0.0003 SOL 이상에 도달했습니다. 그러나 중앙값은 약 35배 낮은 0.00000861 SOL로 안정적으로 유지됐습니다.
• 현재 Solana의 LFM은 작동하지만 개선할 여지가 큽니다. Anza 엔지니어가 수행한 뱅킹 단계 스레드 워크로드 분석에 따르면, 스케줄러 버그 때문에 검증인 클라이언트가 전체 용량을 활용하지 못합니다. 그 결과 Agave 클라이언트는 잠재 성능의 일부만 사용합니다. 또한 트랜잭션 정렬 방식에 관한 공식 사양도 없습니다.
• 현재 우선순위 수수료 API는 개발자에게 결정적인 결과를 제공할 만큼 정교하지 않습니다. 주요 RPC 제공업체마다 자체 우선순위 수수료 API를 제공하므로 느슨한 형태의 공급업체 종속이 발생할 수 있습니다. 핵심 오픈 소스 RPC API 구현은 Jito의 영향과 같은 중요한 네트워크 역학을 고려하지 않아 부정확한 수수료 추정치를 산출합니다.
• 우선순위 수수료를 결정적으로 계산할 방법이 없기 때문에 개발자는 트랜잭션 처리를 보장하고자 수수료를 과도하게 지불하는 보수적인 방식을 택하곤 합니다. 또는 블록 최상단 확보가 필요 없는 트랜잭션에도 대체 메커니즘으로 Jito 팁을 남용할 수 있습니다.
• Solana의 수수료 구조를 한층 개선하기 위해 다양한 전략이 제안됐습니다. 지수형 쓰기 잠금 수수료와 동적 기본 수수료가 대표적입니다. 네트워크는 실제 사용자의 수수료를 낮게 유지하면서 스팸을 억제할 경제적 역압력을 적용하는 방법을 아직 찾지 못했습니다.

소개

수수료 시장은 트랜잭션 수수료를 동적으로 조정해 희소한 블록 공간을 가치가 가장 높은 트랜잭션에 효율적으로 할당하도록 설계된 경제 메커니즘입니다. 트랜잭션이 지불할 의사가 있는 수수료를 해당 트랜잭션 가치의 대리 지표로 사용합니다. LFM은 이 일반적인 개념을 발전시켜 경합 수준에 따라 개별 상태에 세분화된 수수료를 설정합니다. 동일한 상태에 액세스하는 두 트랜잭션은 경합 관계로 간주됩니다. 동일한 계정에 두 번 쓰거나 하나는 읽고 다른 하나는 쓰는 경우가 이에 해당합니다.

LFM에서는 트랜잭션이 쓰기 대상인 특정 상태를 기준으로 수수료를 지불하므로, 국소적인 핫스팟 때문에 블록체인 전체의 수수료가 상승하지 않습니다. 수요가 많거나 경합이 있는 상태에 액세스하는 트랜잭션에는 더 높은 수수료가 부과되고, 수요가 적은 상태와 상호작용하는 트랜잭션은 더 낮은 수수료를 지불합니다. Solana는 병렬 실행 덕분에 경합이 없는 트랜잭션을 더 효과적으로 처리하므로 이는 중요합니다.

반면 글로벌 수수료 시장은 네트워크 상태에 액세스할 때 보편적인 비용을 적용합니다. 즉, 모든 트랜잭션은 상호작용하는 계정과 관계없이 포함되기 위해 동등하게 경쟁합니다. EIP-1559에서 구현된 Ethereum의 수수료 모델은 글로벌 수수료 시장의 적절한 예입니다. EIP-1559는 블록당 최적 컴퓨팅(gas) 사용량을 유지하도록 네트워크 수요에 따라 동적 기본 수수료를 조정합니다. 블록 용량이 차면 모든 트랜잭션의 수수료가 상승합니다. 지갑은 현재 기본 수수료와 트랜잭션의 gas 한도를 기준으로 수수료를 계산합니다. 이 방식은 프로토콜에서 강제되며 예측 가능한 수수료 계산을 제공하지만, 수요가 높은 핫스팟을 더 넓은 네트워크에서 분리하지 못합니다. 수수료가 급등하면 모든 트랜잭션의 수수료가 함께 오릅니다.

특정 상태에 수요가 집중되는 문제는 블록체인에만 국한되지 않습니다. 이 문제는 Web2 소셜 애플리케이션에서 흔히 발생하며 "유명인 문제"라고도 불리는 핫스팟 키 문제와 유사합니다.

이 글에서는 Solana의 LFM을 알기 쉽게 분석합니다. 글은 다음 섹션으로 구성됩니다.

• Solana 수수료 기초: 현재 Solana에서 트랜잭션이 처리되는 방식을 이해하는 데 필요한 기본 지식을 설명합니다.
• 초기 로컬 수수료 시장의 문제: 초기 LFM 구현에서 발생한 문제와 한계를 살펴봅니다.
• 중앙 스케줄러 v1.18 업데이트: LFM의 기능을 크게 개선한 2024년의 핵심 업데이트를 소개합니다.
• 로컬 수수료 시장의 효과 측정: 현재 Solana에서 운영되는 LFM의 상태를 이해하는 데 필요한 데이터를 제공합니다.
• 현재 문제와 개선 영역: LFM이 잠재력을 온전히 발휘하기 위해 해결해야 할 문제와 주의가 필요한 영역을 다룹니다.
• 제안된 해결책: LFM을 개선하고 더 정교한 블록 공간 가격 책정을 위한 경제적 인센티브를 강화하는 해결책을 검토합니다.

Solana의 트랜잭션 수수료 구조를 이미 잘 아는 독자는 다음 수수료 기초 섹션을 건너뛰어도 됩니다.

Solana 수수료 기초

Solana 트랜잭션 수수료는 기본 수수료와 우선순위 수수료로 구성됩니다. 현재 기본 수수료는 서명당 5,000 lamports로 고정돼 있습니다. 대부분의 Solana 트랜잭션에는 서명이 하나 있습니다. 우선순위 수수료는 요청된 컴퓨팅 유닛(CU)당 microlamports, 즉 lamport의 100만분의 1 단위로 표시됩니다. 수수료는 수수료 지불자 계정(서명자)에서 차감됩니다. 지불자에게 트랜잭션 수수료를 낼 lamports가 부족하면 트랜잭션이 폐기됩니다. 이 글을 작성하는 시점에는 기본 수수료와 우선순위 수수료의 50%를 블록 빌더가 트랜잭션을 블록에 포함하는 인센티브로 가져갑니다. 나머지 50%는 소각됩니다. 작년 5월 제안 SIMD-096의 거버넌스 투표가 통과됨에 따라 블록 빌더가 우선순위 수수료의 100%를 가져가도록 변경될 예정입니다. 예를 들면 다음과 같습니다. 

어떤 트랜잭션에 서명 하나가 있고 500,000 CU를 요청한다고 가정해 보겠습니다. 발신자는 요청된 CU당 50,000 microlamports의 우선순위 수수료를 설정합니다. 트랜잭션의 총수수료는 5,000 lamports + (요청된 500,000 CU * 요청된 CU당 50,000 microlamports) = 25,000 lamports, 즉 0.000025 SOL입니다.

검증인의 컴퓨팅 리소스는 한정돼 있으며 프로토콜은 블록당 총 컴퓨팅 리소스를 4,800만 CU로 제한합니다. 이 수치는 검증인이 400밀리초의 블록 시간을 달성하면서 합리적으로 처리할 수 있는 양을 실험적으로 측정해 정했습니다. 계정당 블록별 최대 CU는 1,200만으로 제한되며 트랜잭션당 최대 컴퓨팅은 140만 CU로 설정됩니다. 트랜잭션 메시지 크기도 최대 1,232바이트로 제한됩니다. 이는 IPv6의 최소 전송 단위인 1280바이트에서 헤더를 뺀 크기입니다.

컴퓨팅 리소스의 오용을 방지하기 위해 Solana의 각 트랜잭션에는 컴퓨팅 예산이 할당됩니다. 기본적으로 네트워크는 명령당 최대 200,000 컴퓨팅 유닛(CU)을 설정합니다. 하지만 트랜잭션에 `SetComputeUnitLimit` 명령을 포함하면 사용자 지정 컴퓨팅 유닛 한도를 지정해 리소스를 더 효율적으로 할당할 수 있습니다. Agave 클라이언트 코드베이스에는 다양한 작업의 CU 비용이 나와 있습니다.

Solana의 모든 트랜잭션은 실행 중 읽거나 쓸 계정 주소의 전체 목록을 지정해야 합니다. 이 목록은 최대 35개 주소로 제한되며 온체인 Address Lookup Tables를 통해 확장할 수 있습니다. 주소 목록을 만들면 개발자에게 추가 부담이 생기지만, 병렬 트랜잭션 실행과 로컬 수수료 시장을 비롯한 Solana의 여러 최적화를 활용하는 데 핵심적인 역할을 합니다.

초기 Solana 로컬 수수료 시장의 문제

2023년 말 Solana의 경제 활동이 가속하면서 초기 LFM 구현의 몇 가지 중대한 결함이 드러났습니다. 당시 Ellipsis Labs의 Eugene Chen은 Umbra Research의 Solana Fees, Part 1 글에서 이러한 문제를 종합적으로 분석했습니다. 아래는 Chen이 제시한 핵심 사항을 요약한 내용입니다.

CU를 정확히 요청할 인센티브 부족

Solana의 수수료 구조는 사용하거나 요청한 컴퓨팅 유닛(CU)을 고려하지 않고 서명당 기본 수수료를 부과합니다. 한편 우선순위 수수료는 혼잡한 시기에 CU 사용량을 줄일 인센티브를 제한적으로만 제공합니다. 이 설계에서는 트랜잭션 발신자가 컴퓨팅 사용량을 최적화하거나 CU 요청량을 실제 필요량에 맞출 동기가 거의 없습니다. 그 결과 트랜잭션이 필요 이상의 CU를 요청하는 일이 잦아져 네트워크 스케줄링 과정의 효율성이 저하됩니다.

프로토콜 외부 우선순위 메커니즘을 사용할 인센티브

우선순위 수수료의 50%를 소각하면 트랜잭션 발신자가 블록 빌더와 공모하고 우선 액세스 대가를 오프체인으로 지급해 프로토콜을 우회할 인센티브가 생깁니다. 이러한 행동은 Jito 경매 사용 증가에서 확인할 수 있습니다. Jito-Agave 클라이언트를 실행하는 검증인은 더 많은 수수료 수익을 얻고, Jito MEV 커미션 보상을 통해 위임한 스테이커에게 이 수익을 효율적으로 분배할 수 있습니다. Jito-Agave 클라이언트 도입이 늘면서 Jito 번들은 여러 상황에서 더 우수한 트랜잭션 전송 서비스임을 입증했습니다. 

비결정적인 스케줄러 우선순위 지정

Solana의 합의와 스케줄러 모두 우선순위 수수료에 따른 엄격한 트랜잭션 순서를 강제하지 않습니다. 트랜잭션은 주로 블록 빌더에 도착한 시간을 기준으로 정렬되며, 우선순위 수수료는 부차적으로만 고려됩니다. 우선순위 수수료가 높으면 경합 상태에서 포함될 가능성이 커지지만 정렬 과정은 여전히 비결정적입니다. 트랜잭션 처리 장치(TPU)에 도달하기 전의 네트워크 지터와 스케줄러 내부의 지터가 예측 불가능성을 더욱 높입니다.

이러한 비결정성은 트랜잭션 실행의 예측 가능성과 안정성을 떨어뜨립니다. 그 결과 사용자는 더 빨리 포함될 가능성을 높이고자 네트워크에 트랜잭션 스팸을 쏟아냅니다. 하지만 우선순위 수수료를 높여도 일정 임계점을 넘으면 효과가 감소해, 더 나은 트랜잭션 배치를 위한 메커니즘으로서 효율성이 떨어집니다. 결국 Solana의 공유 블록 공간은 전형적인 "공유지의 비극"에 빠졌습니다. 각 주체가 자신의 이익을 위해 행동하면서 이 공공 리소스의 과도한 사용과 비효율을 초래했습니다.

중앙 스케줄러 v1.18 업데이트

초기 Agave 클라이언트 스케줄러 구현은 우선순위 수수료가 높은 트랜잭션이 특정 블록에 포함될 가능성이 더 크다는 느슨한 보장만 제공했습니다. 리더의 트랜잭션 처리 장치(TPU)는 병렬 스레드 6개로 작동합니다. 4개는 비투표 트랜잭션을 처리하고 2개는 투표 트랜잭션용으로 예약됩니다. 비투표 트랜잭션 스레드 4개는 각각 자체 큐를 유지하며, 수신된 트랜잭션은 실행할 엔트리로 그룹화되기 전까지 이곳에서 대기합니다. 이전에는 트랜잭션이 이러한 스레드에 무작위로 할당됐으며, 각 큐는 다른 스레드가 처리하는 패킷을 인식하지 못한 채 독립적으로 패킷 우선순위를 지정했습니다.

이 시스템에서 각 스레드는 큐를 순회하며 트랜잭션 잠금과 실행을 시도합니다. 현재 순회를 완료한 스레드는 추가 패킷을 수집한 뒤 과정을 다시 시작합니다. 이 구조에서는 우선순위 수수료를 효과적으로 사용하기 어렵습니다. 예를 들어 우선순위가 높은 트랜잭션이 한 스레드의 큐 맨 앞에 있어도, 다른 스레드가 큐 후미에서 동일한 계정과 관련된 우선순위 수수료가 더 낮은 트랜잭션을 동시에 처리할 수 있습니다. 우선순위 수수료는 모든 스레드 간(inter-thread)이 아니라 개별 스레드 내부(intra-thread)의 트랜잭션 순서에만 영향을 미쳤습니다. 따라서 각 큐는 선입선출(FIFO) 처리와 우선순위 수수료를 함께 고려하는 혼합 정렬 메커니즘을 적용했습니다. 하지만 스레드 전체에 적용되는 글로벌 순서는 강제되지 않았습니다.

스레드가 트랜잭션 실행을 준비할 때는 먼저 필요한 계정 잠금을 확보해야 합니다. 필요한 쓰기 잠금을 사용할 수 없으면 트랜잭션이 다시 큐에 들어갑니다. 트랜잭션을 스레드에 무작위로 할당하면 같은 유형의 트랜잭션도 멀티스레드 스케줄링 시스템에서 매번 다른 위치에 놓일 수 있어 문제가 더 심해집니다. 이러한 스케줄러의 확률적 특성은 지터를 유발해 트랜잭션이 블록 내 어디에 배치될지 변동성을 만듭니다.

2024년 5월 Agave 클라이언트 v1.18 업데이트와 함께 중앙 스케줄러라고도 하는 새로운 트랜잭션 스케줄러가 도입됐습니다. 이 개선된 구조에서는 중앙 스케줄러가 prio-graph라는 종속성 그래프를 구축해 모든 스레드에서 충돌하는 트랜잭션의 처리와 우선순위 지정을 더 효과적으로 관리합니다. 이 대규모 업데이트로 Solana의 결정적 트랜잭션 정렬 능력이 크게 향상됐으며, 우선순위 수수료가 높은 트랜잭션이 블록에 포함될 가능성도 커졌습니다.

prio-graph는 새 트랜잭션이 추가될 때 동적으로 업데이트되는 방향성 비순환 그래프(DAG)입니다. 트랜잭션은 시간 우선순위에 따라 처리되는 실행 체인을 형성하도록 그래프 안에 구성됩니다. 충돌하는 트랜잭션의 삽입 순서는 우선순위 수수료로 결정됩니다. 이 방식은 잠금 경합을 최소화해 트랜잭션 배치가 원활하게 실행되도록 하고 리소스 충돌로 인한 지연을 줄입니다. 성능을 높이고 처리 효율성을 개선하기 위해 트랜잭션 사전 컴파일 검증은 워커 스레드로 이전됐습니다. 

업데이트된 스케줄러 설계는 확장성과 유연성을 크게 높여 잠금 충돌이 증가할 위험 없이 스레드 수를 늘릴 가능성을 열었습니다. 또한 중앙 집중식 스케줄링 방식은 보상 창출을 개선해 많은 검증인 운영자의 수익을 높였습니다.

중앙 스케줄러에 관한 더 자세한 분석은 이전 Agave 1.18 업데이트를 다룬 Helius 블로그 글에서 확인할 수 있습니다.

더 효과적인 우선순위 계산

스케줄러 업데이트와 함께 컴퓨팅 요구량이 적은 트랜잭션에 유리하도록 트랜잭션 우선순위 공식도 개선됐습니다. 리소스 사용량이 적은 개발자와 트랜잭션이 혜택을 받습니다. 

개선된 공식은 다음과 같습니다.

우선순위 = (우선순위 수수료 * 요청된 컴퓨팅 유닛) + 기본 수수료 / 

(1 + 요청된 실행 CU + 서명 CU + 쓰기 잠금 CU)

새 계산식은 트랜잭션과 관련된 모든 컴퓨팅 및 운영 비용을 반영해 우선순위 수준이 실제 리소스 소비량을 정확히 나타내도록 합니다. 따라서 추가 우선순위 수수료가 없는 단순 토큰 전송이나 네이티브 SOL 트랜잭션도 큐에서 기본 우선순위 수준을 보장받습니다. 더 복잡한 트랜잭션의 경우 `SetComputeUnitLimit` 명령을 사용해 사용자 지정 CU 한도를 지정하지 않은 개발자는 이를 지정한 개발자보다 트랜잭션 우선순위에서 불리합니다.

로컬 수수료 시장의 효과 측정

이 섹션에서는 Solana LFM과 관련된 데이터를 살펴봅니다. 

트랜잭션 수수료 중앙값과 평균

LFM이 효과적으로 작동한다면 단순 스테이블코인 전송처럼 경합이 없는 상태와 관련된 트랜잭션 수수료는 낮게 유지될 것으로 예상됩니다. 반면 유동성이 낮은 투기성 토큰처럼 경합 상태에 액세스하는 트랜잭션 수수료는 수요와 함께 급등해야 합니다. 이러한 역학을 평가하는 유용한 지표는 트랜잭션 우선순위 수수료의 중앙값과 평균을 비교하는 것입니다. 중앙값 수수료는 50번째 백분위수 사용자가 지불한 수수료로 일반적인 비용을 나타냅니다. 평균 수수료는 모든 수수료를 전체 트랜잭션 수로 나눈 값으로 전반적인 추세를 보여줍니다.

최근 데이터는 이러한 예상 패턴을 확인해 줍니다. 2024년 11월 Solana의 경제 활동은 당시까지 최고 수준을 기록했으며, 비투표 트랜잭션의 평균 수수료는 사상 최고치인 0.0003 SOL 이상에 도달했습니다. 그런데도 중앙값은 약 35배 낮은 0.00000861 SOL로 안정적으로 유지됐습니다. 이는 비슷한 경제 활동 급증으로 평균 수수료가 0.0002 SOL 이상 오르고 중앙값도 약 10배 낮은 0.00001862 SOL까지 함께 상승했던 2024년 4월과 대조적입니다. 이러한 차이는 수수료 격리가 수요가 많은 시기에 일반 사용자를 비용 급등으로부터 보호하고, 투기와 무관한 사용 사례의 사용자 경험을 유지하는 데 효과적임을 보여줍니다.

LFM이 없는 Coinbase 운영 Ethereum L2 Base와 같은 EVM 기반 네트워크의 유사한 데이터를 분석하면 트랜잭션 수수료 중앙값과 평균 사이에 강한 상관관계가 나타납니다. 수요가 증가할 때 글로벌 기본 수수료가 상승하므로 평균과 중앙값이 비교적 함께 움직입니다. 또한 트랜잭션 수수료 중앙값과 평균의 격차도 훨씬 작습니다. 예를 들어 2024년 12월 5일 Base의 평균 트랜잭션 수수료는 $0.1115까지 급등했으며, 중앙값도 약 5배 낮은 $0.0228까지 올랐습니다.

되돌려진 트랜잭션 비율

살펴볼 만한 또 다른 유용한 추세는 되돌려진 트랜잭션의 비율입니다. 경제 활동이 활발했던 2024년 4월과 5월에는 체인이 대량의 스팸으로 압박받으면서 Solana 사용자들이 사용자 경험 저하를 폭넓게 보고했습니다. 비결정성은 트랜잭션 실행의 예측 가능성과 안정성을 떨어뜨렸고, 사용자는 더 빨리 포함될 가능성을 높이고자 네트워크에 트랜잭션 스팸을 쏟아냈습니다. 

서처는 성공 가능성을 고려하지 않고 기회주의적 거래를 위한 트랜잭션을 자주 제출합니다. 우선순위 수수료가 부적절하게 낮은 차익거래 트랜잭션도 여전히 유효합니다. 프로토콜은 우선순위 수수료가 더 높은 다른 트랜잭션 이후에 이를 처리하며, 슬리피지 로직 때문에 되돌려질 가능성이 큽니다. 

되돌려진 트랜잭션 비율은 2024년 4월 정점을 기록해 전체 비투표 트랜잭션의 75.7%를 차지했습니다. Agave 1.18 중앙 스케줄러를 비롯한 주요 업데이트가 출시된 뒤 이 비율은 크게 낮아졌습니다.

지난 7일(2024년 1월 6~13일)을 다룬 Blockworks Research의 코호트 분석을 보면 활동 수준에 따라 되돌림 비율이 다릅니다. 하루에 1~5건의 트랜잭션을 수행하는 주소(대부분 일반 사용자)의 되돌림 비율은 1.4%이며, 하루 6~50건을 수행하면 4.6%로 증가합니다. 특히 하루 10,000건 이상을 수행하는 주소의 되돌림 비율은 66.7%까지 치솟습니다. 또한 하루 100,000건 이상의 트랜잭션을 수행하는 활동량이 많은 주소(봇)는 되돌려진 모든 트랜잭션의 95.2%를 차지합니다. 2024년 12월 전체 비투표 트랜잭션의 총 되돌림 비율은 41.2%였습니다. 이는 실패한 차익거래를 처리하는 데 네트워크 컴퓨팅 리소스의 상당 부분이 소비된다는 의미입니다.

현재 문제와 개선 영역

주목할 만한 발전에도 Agave 검증인 클라이언트 스케줄러에는 여전히 문제가 있습니다. Anza 엔지니어 Alessandro Decina가 수행한 다음 뱅킹 단계 스레드 워크로드 분석은 현재의 비효율성과 개선 영역을 보여줍니다.

스케줄러 스레드: 블록 생성에 가장 중요한 스레드입니다. 스케줄러는 수신되는 모든 트랜잭션을 가져와 정렬하고 실행 일정을 수립합니다. 

투표 트랜잭션 스레드: 전용 스레드 2개가 투표 트랜잭션을 처리해 사용자 트랜잭션과 별도로 처리되도록 합니다.

비투표 트랜잭션 스레드: 스케줄러가 예약한 트랜잭션을 받아 사용자 트랜잭션을 처리하는 스레드 4개입니다.

QUIC 수신 스레드: 검증인이 리더일 때 Tokio 스레드가 QUIC 프로토콜을 통한 트랜잭션 수신을 관리합니다. 2024년 초 혼잡 기간에는 이 스레드가 상당한 병목 지점이었습니다.

위 시각화를 보면 리더의 첫 번째 블록이 시작될 때는 모든 워커 스레드가 트랜잭션을 병렬로 실행하지만, 이러한 병렬성이 빠르게 순차 실행으로 저하됩니다. 구체적으로 비투표 트랜잭션 스레드 하나(세 번째 스레드)만 트랜잭션 처리를 계속하고 나머지 스레드는 유휴 상태가 됩니다.

이 동작은 스케줄러 버그 때문에 검증인 클라이언트가 전체 용량을 활용하지 못한다는 점을 시사합니다. 그 결과 시스템은 잠재 성능의 일부만 사용합니다. 이 문제를 해결하면 검증인이 현재 부하의 최대 4배까지 처리할 수 있음을 의미합니다.

관측 가능성

예측 가능한 트랜잭션 랜딩을 추정하는 현재 수수료 API는 결정적인 결과를 제공할 만큼 정교하지 않습니다. 주요 RPC 제공업체마다 자체 우선순위 수수료 API를 제공하는 반면, 핵심 오픈 소스 RPC API 구현은 여전히 최적화되지 않았습니다. Jito의 영향과 같은 중요한 네트워크 역학을 고려하지 않아 수수료 추정의 정확도가 떨어집니다. 

Helius는 `getPriorityFeeEstimate` RPC 메서드를 제공합니다. 이 메서드는 글로벌 수수료 시장과 LFM의 과거 데이터를 바탕으로 수수료를 추천합니다. 개발자는 직렬화되고 서명된 트랜잭션이나 트랜잭션과 관련된 계정 키 목록을 입력할 수 있습니다. 이 메서드는 min, low, medium, high, very high, unsafe max라는 6개 백분위수로 분류된 사용자 지정 우선순위 수수료 수준을 지원합니다. medium(50번째 백분위수)이 기본 추천값입니다. 수수료는 가장 최근 슬롯 50개의 데이터를 사용해 계산됩니다.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

위 내용: base58로 인코딩된 직렬화 트랜잭션을 사용하는 getPriorityFeeEstimate의 페이로드 예시입니다.

우선순위 수수료를 결정적으로 계산할 방법이 없기 때문에 개발자는 트랜잭션 처리를 보장하고자 수수료를 과도하게 지불하는 보수적인 방식을 택하곤 합니다. 또는 블록 최상단 확보가 필요 없는 트랜잭션에도 Jito 팁을 남용할 수 있습니다. 이러한 팁은 우선순위 수수료를 대신해 자주 사용됩니다. 특히 2024년에 관찰된 팁 대부분은 차익거래나 샌드위칭 같은 전통적인 MEV 활동과 관련이 없으며, 트랜잭션을 더 빨리 포함하는 데 목적이 있습니다. 검증인은 더 높은 블록 보상과 MEV 커미션을 받아 이러한 비효율성의 이익을 얻습니다.

개발자가 온체인 조건의 변동에 따라 우선순위 수수료를 동적으로 조정하는 로직을 구현하지 않을 때도 문제가 발생합니다. 시장이 크게 움직이는 주요 이벤트가 발생하면 특정 상태 계정에 액세스하는 수수료가 급격히 오를 수 있습니다. 정적인 수수료 설정으로는 적시에 실행하기 어려우므로 동적 수수료 메커니즘이 없는 애플리케이션은 이러한 상황에서 어려움을 겪습니다.

제안된 해결책

Solana의 수수료 구조를 한층 개선하기 위해 다양한 전략이 제안됐습니다. 이러한 제안은 네트워크 리소스 할당을 최적화하고 스팸을 유발하는 인센티브를 완화하는 것을 목표로 합니다.

지수형 쓰기 잠금 수수료

2023년 1월 Tao Zhu(Anza)와 Anatoly Yakavenko가 제안한 SIMD-0110은 경합 계정에 동적 수수료를 부과해 혼잡을 관리하는 새로운 메커니즘을 제시합니다. 이 메커니즘은 쓰기 잠금 계정의 컴퓨팅 유닛(CU) 사용량에 대한 지수 이동 평균(EMA)을 추적하고, 높은 사용량을 지속적으로 보이는 계정의 쓰기 잠금 비용을 높입니다.

이러한 시스템을 구현하기 위해 Solana 런타임은 경합 계정의 공개 키와 해당 Compute Unit Pricer(CUP)를 LRU(Least Recently Used) 캐시에 유지합니다. CUP는 계정의 EMA CU 사용량을 모니터링하고 쿼리 시 업데이트된 비용 요율을 제공합니다.

이 메커니즘은 쓰기 잠금 수수료를 동적으로 조정합니다. 계정의 EMA CU 사용량이 목표 임계값을 초과하면 쓰기 잠금 비용 요율이 올라갑니다. 반대로 사용량이 목표보다 낮으면 비용 요율이 내려갑니다. 초기 매개변수는 다음과 같습니다.

• 계정 최대 CU 한도의 25%를 목표 사용량으로 설정합니다.
• 초기 쓰기 잠금 비용 요율은 CU당 1,000 micro-lamports입니다.
• 비용 조정률은 블록당 1%입니다.

계정의 쓰기 잠금 수수료는 비용 요율에 트랜잭션이 요청한 CU를 곱해 계산합니다. 이 시스템에서 총 트랜잭션 수수료는 기본 서명 수수료, 우선순위 수수료, 쓰기 잠금 수수료라는 세 요소의 합입니다. 쓰기 잠금 수수료는 100% 소각됩니다.

SIMD-0110은 공개 당시 커뮤니티에서 활발한 논쟁을 불러일으켰습니다. 하지만 이 제안은 현재 비활성 상태이며 이후 종료로 표시됐습니다.

동적 기본 수수료

Solana LFM을 개선하기 위한 또 다른 장기적 해결책은 글로벌 및 계정별 동적 기본 수수료(DBF)를 도입하는 것입니다. Ellipsis Labs의 Jarry Xiao와 Eugene Chen은 이 방식의 대표적인 지지자입니다.

우선순위 수수료는 선택 사항이지만 기본 수수료는 필수입니다. 현재 Solana의 기본 수수료는 서명당 5000 lamports로 고정돼 있습니다. 단순한 토큰 전송을 제출하는 사용자도 복잡한 다중 거래소 스왑을 실행하는 사용자나 복잡한 MEV 차익거래를 시도하는 서처와 같은 기본 수수료를 지불합니다. 기본 수수료는 트랜잭션의 컴퓨팅 사용량을 정확히 반영하지 않습니다.

동적 기본 수수료를 사용하면 기본 수수료가 부적절한 차익거래 트랜잭션을 유효하지 않은 것으로 간주해 스케줄러에 도달하기 전에 폐기할 수 있습니다. 기본 수수료를 높이면 스패머가 보내는 트랜잭션 수를 줄일 수 있습니다.

기본 수수료는 결국 균형점에 도달하고 트랜잭션 가격은 블록 공간 시장의 가치에 따라 결정됩니다. 기본 수수료가 상승하므로 결국 트랜잭션을 보내는 행위가 거래의 기회비용을 감수할 가치가 없는 한계비용에 도달합니다. 수수료가 지나치게 높아지면 사용자 활동에 영향을 미칩니다. 봇에는 너무 높지만 일반 사용자는 대체로 수용할 수 있는 최댓값이 이상적입니다. 이러한 시스템에서는 포함을 위해 트랜잭션 스팸을 보내는 계정이 보유한 SOL을 모두 소각하게 됩니다.

Solana의 빠른 블록 시간 덕분에 공격적인 알고리즘으로 기본 수수료를 설정할 수 있습니다. 수요가 많은 시기에는 네트워크 혼잡을 반영하도록 수수료를 빠르게 조정할 수 있으며 블록마다 두 배로 올릴 수도 있습니다. 반대로 수요가 줄어들면 수수료를 더 점진적으로 낮출 수 있습니다. Solana의 짧은 블록 시간 덕분에 수수료 인하도 비교적 빠르게 진행되므로 네트워크가 변화하는 조건에 신속히 적응할 수 있습니다.

유사한 형태의 경제적 역압력 사례로 Metaplex Candy Machine 프로그램을 들 수 있습니다. 이 프로그램은 2022년에 스팸 방지 메커니즘으로 봇 세금을 도입했습니다. 봇 세금은 유효하지 않은 트랜잭션에 적용되는 선택적 요금입니다. 일반적으로 실제 사용자의 단순 실수에 영향을 주지 않도록 합리적으로 적은 금액을 부과합니다. 이 세금은 효과가 있었습니다. 민팅 스나이퍼의 자금이 빠르게 고갈됐고 스팸이 중단됐습니다.

결론

Solana의 LFM은 작동하지만 개선할 여지가 큽니다.

• 우선순위 수수료 메커니즘 개선: 우선순위 수수료 RPC 호출을 개선해야 합니다. 이상적으로 개발자는 이후 몇 개 블록 안에 트랜잭션이 포함되도록 보장하는 수수료를 간단하고 결정적인 방식으로 설정할 수 있어야 합니다.
• 경제적으로 스팸 억제: 네트워크는 실제 사용자의 수수료를 낮게 유지하면서 경제 활동이 많은 시기에 봇에 경제적 역압력을 가할 방법을 찾아야 합니다.
• 개발자 교육: 개발자는 애플리케이션의 트랜잭션 수수료를 정적으로 설정하지 말아야 하며, 일반 트랜잭션에서 Jito 같은 프로토콜 외부 메커니즘에 덜 의존해야 합니다.
• 추가 스케줄러 최적화: 수요가 많은 시기에 모든 워커 스레드를 활용할 수 있도록 트랜잭션 스케줄러를 더 최적화해야 합니다.

Solana 공동 창업자 Anatoly Yakovenko가 지적했듯이 이러한 과제는 대부분 "그저 엔지니어링 문제"이며, 적절한 기술적 집중을 통해 해결할 수 있습니다.

추가 자료

• Solana 수수료, 1부 - Umbra Research
• 다차원 Solana 수수료를 향하여 - Umbra Research
• Ethereum 확장에 로컬 수수료 시장이 필요한 이유 - Eclipse Labs
• Solana의 로컬 수수료 시장은 실재하지 않습니다 | Eugene Chen - Lightspeed Podcast
• Solana 뱅킹 단계와 스케줄러 - A.Fitzgerald