LFM(로컬 수수료 시장)을 통해 솔라나는 경쟁 수준에 따라 개별 주에 대한 세분화된 수수료를 설정할 수 있습니다. 트랜잭션은 특정 주에 따라 수수료를 지불하므로, 지역화된 핫스팟이 블록체인 전체에 걸쳐 수수료를 인상하는 것을 방지할 수 있습니다.
LFM은 모든 앱이 원활하게 공존하는 확장 가능하고 통합된 베이스 레이어라는 솔라나의 비전을 실현하는 데 매우 중요합니다. LFM이 없으면 체인의 한 부분에서 수수료가 급등하면 모든 거래의 수수료가 상승하게 되며, 이는 블록 공간 가격을 글로벌 수수료 시장에만 의존하는 다른 네트워크에서 흔히 발생하는 문제입니다.
2023년 말 솔라나의 경제 활동이 가속화됨에 따라, LFM의 원래 구현에서 몇 가지 주요 결함이 드러났습니다. 가장 눈에 띄는 것은 비결정적 스케줄러 우선순위입니다. 트랜잭션은 주로 블록 빌더에 도착하는 시간을 기준으로 정렬되며, 우선 순위 비용은 부차적인 고려 사항일 뿐입니다.
2024년 5월 Agave 클라이언트 v1.18 업데이트에서는 새로운 트랜잭션 스케줄러와 개선된 트랜잭션 우선순위 공식이 도입되었습니다. 스케줄러는 종속성 그래프를 작성하여 스레드 간에 충돌하는 트랜잭션의 처리와 우선순위를 더 잘 관리합니다. 이 주요 업데이트는 결정론적 방식으로 트랜잭션을 주문하는 프로토콜의 기능을 크게 향상시켰습니다.
효율적으로 실행되는 LFM을 평가하는 데 유용한 지표 중 하나는 트랜잭션 우선순위 비용의 중앙값과 평균값을 비교하는 것입니다. 분쟁이 없는 상태(백분위수 중앙값 50%)와 관련된 비용은 낮은 수준을 유지할 것으로 예상됩니다. 분쟁 중인 상태에 대한 비용은 수요가 증가함에 따라 급증하여 평균 비용이 상승할 것입니다. 최근 데이터는 이러한 패턴을 확인시켜 줍니다. 2024년 11월, 투표권이 없는 거래의 평균 수수료는 0.0003 SOL 이상으로 사상 최고치를 기록했습니다. 그러나 중간 수수료는 0.00000861 SOL로 약 35배 낮은 수준을 유지했습니다.
현재 솔라나의 LFM은 기능적이지만 여전히 개선의 여지가 많습니다. 안자 엔지니어들이 은행 단계 스레딩 워크로드를 분석한 결과 스케줄러 버그가 검증자 클라이언트의 기능을 최대한 활용하지 못하도록 방해하고 있는 것으로 나타났습니다. 그 결과 아가베 클라이언트는 잠재력의 극히 일부만 실행됩니다. 또한 트랜잭션의 순서를 어떻게 지정해야 하는지에 대한 공식적인 사양이 없습니다.
현재 우선순위 수수료 API는 결정론적 결과를 제공하는 데 필요한 정교함이 부족합니다. 각 주요 RPC 제공업체는 자체적인 맞춤형 우선순위 수수료 API를 제공하고 있으며, 이로 인해 특정 벤더에 종속될 수 있습니다. 핵심 오픈 소스 RPC API 구현은 Jito와 같은 주요 네트워크 역학의 영향을 고려하지 않아 비용 추정이 부정확할 수 있습니다.
우선순위 수수료를 계산하는 결정론적 방법이 없는 경우, 개발자는 거래 처리를 위해 과다 지불하는 신중한 접근 방식을 취하는 경우가 많습니다. 또는 블록의 상단을 확보할 필요가 없는 트랜잭션의 경우에도 지토 팁 수수료를 대체 메커니즘으로 사용하여 초과 지불할 수 있습니다.
솔라나의 수수료 구조를 더욱 개선하기 위해 다양한 전략이 제안되었습니다. 여기에는 기하급수적 쓰기 잠금 수수료와 동적 기본 수수료가 포함됩니다. 네트워크는 아직 스팸을 억제하기 위해 경제적 압박을 가하는 동시에 실제 사용자의 수수료를 낮게 유지할 수 있는 방법을 찾지 못했습니다.
소개
수수료 시장은 거래 수수료를 동적으로 조정하여 희소한 블록 공간을 가장 가치가 높은 거래에 효율적으로 할당하도록 설계된 경제 메커니즘입니다. 트랜잭션이 지불하고자 하는 수수료는 트랜잭션의 가치에 대한 대리인이며, LFM은 상태 경쟁의 정도에 따라 개별 상태에 대한 세분화된 수수료를 설정함으로써 이 일반적인 개념을 구체화합니다. 두 트랜잭션이 동일한 상태(두 개의 쓰기 작업 또는 동일한 계정에 대한 읽기/쓰기 작업)에 액세스하면 경쟁하는 것으로 간주됩니다.
LFM을 사용하면 트랜잭션이 쓰는 특정 상태에 따라 수수료를 지불하므로, 특정 핫스팟이 블록체인 전체에서 수수료를 인상하는 것을 방지할 수 있습니다. 수요가 많거나 경합이 심한 상태에 액세스하는 트랜잭션은 더 높은 수수료를 지불하고, 수요가 적은 상태와 상호작용하는 트랜잭션은 더 낮은 수수료를 지불합니다. 이는 솔라나가 병렬 실행을 지원하기 때문에 경쟁이 없는 트랜잭션을 처리할 때 더 나은 성능을 발휘하기 때문에 중요합니다.
그림
반면, 글로벌 수수료 시장은 네트워크 상태에 접근하는 데 보편적인 비용을 부과하며, 이는 모든 거래가 상호작용하는 계정과 관계없이 블록에 포함되기 위해 동등하게 경쟁한다는 것을 의미합니다. EIP-1559에서 구현된 이더리움의 수수료 모델은 글로벌 수수료 시장의 적절한 예입니다. EIP-1559는 네트워크 수요에 따라 동적 기본 수수료를 조정하여 최적의 블록당 계산(가스) 사용량을 유지하기 위해 동적 기본 수수료를 조정합니다. 블록 용량이 가득 차면 모든 거래에 대한 수수료가 증가합니다. 지갑은 현재 기본 수수료와 거래의 가스 한도를 기준으로 수수료를 계산합니다. 이 방식은 프로토콜에서 시행되며 예측 가능한 수수료 계산을 제공하지만, 수요가 많은 핫스팟을 더 넓은 네트워크에서 분리하는 데는 실패합니다. 수수료가 급증하면 모든 트랜잭션의 수수료가 급증합니다.
주별 높은 수요 문제는 블록체인에만 국한된 문제가 아닙니다. 이 문제는 웹2.0 소셜 애플리케이션에서 흔히 '유명인 문제'라고 불리는 핫키 문제와 유사합니다.
이 백서에서는 솔라나 LFM에 대한 접근 가능한 분석을 제공하는 것을 목표로 합니다. 이 작업은 다음 섹션으로 나뉩니다.
솔라나 수수료 기초: 독자의 현재 트랜잭션 처리에 대한 기본적인 이해를 구축합니다.
현지 수수료 시장의 초기 이슈: LFM 초기 구현의 초기 문제와 그 함정을 살펴봅니다.
중앙 스케줄러 v.1.18 업데이트: LFM의 기능을 크게 개선하는 2024년 주요 업데이트에 대해 설명합니다.
로컬 수수료 시장의 효율성 측정: Solana에서 실행 중인 LFM의 상태를 이해하는 데 관련된 데이터를 제공합니다.
지속되는 문제 및 개선 분야: 이 섹션에서는 LFM이 잠재력을 최대한 발휘하기 위해 해결되지 않은 문제와 주의가 필요한 분야에 대해 설명합니다.
제안된 솔루션: LFM을 개선하고 보다 세분화된 블록 공간 가격에 대한 더 나은 경제적 인센티브를 도입하기 위해 제안된 솔루션에 대한 검토입니다.
솔라나의 거래 수수료 구조에 이미 익숙한 독자는 수수료 기본 사항에 대한 다음 섹션을 건너뛰셔도 됩니다.
솔라나 수수료 기본 사항
솔라나 거래는 기본 수수료와 우선순위 수수료의 두 가지 수수료로 구성됩니다. 기본 수수료는 현재 서명당 5,000램포트로 고정되어 있으며, 대부분의 솔라나 거래에는 서명이 하나만 있습니다. 우선순위 수수료는 마이크로 램프포트(즉, 램포트의 100만 분의 1)로 계산되며 요청된 CU(계산 단위)로 계산됩니다. 수수료는 수수료 납부자(서명자)의 계정에서 차감됩니다. 결제자의 램포트가 거래 수수료를 충당하기에 부족하면 거래가 취소됩니다. 트랜잭션을 블록에 포함시키기 위한 인센티브로 기본 수수료와 우선순위 수수료의 50%는 블록 생성자가 보유합니다. 나머지 50%는 소멸됩니다. 지난 5월 성공적인 거버넌스 투표에 따라, 제안 SIMD-096은 우선순위 수수료의 100%로 변경됩니다. 블록 빌더가 보유하는 수수료로 변경됩니다. 예를 들어:
서명이 있는 트랜잭션에 500,000개의 CU를 요청하고 발신자는 요청된 CU당 50,000 마이크로램프의 우선 수수료를 설정합니다. 트랜잭션의 총 비용은 R5,000 + (요청된 CU 500,000개 * 요청된 CU당 50,000 마이크로랜드봇) = R25,000, 즉 0.000025 SOL입니다.
검증자의 연산 자원은 유한하며 프로토콜은 블록당 총 연산 자원을 4800만 CU로 제한합니다. 4,800만 CU로 제한됨. 이 수치는 검증자가 400ms의 블록 시간을 달성하기 위해 합리적으로 처리할 수 있는 양을 기준으로 경험적으로 선택되었습니다. 계정당 블록당 최대 CU는 1,200만 개로 제한되며, 거래당 최대 계산 한도는 140만 CU로 설정됩니다. 거래 메시지는 헤더를 제외한 IPv6의 최소 전송 단위인 1,280바이트에서 최대 1,232바이트의 크기로 제한됩니다.
컴퓨팅 리소스의 오용을 방지하기 위해 Solana는 각 트랜잭션에 대해 컴퓨팅 예산을 할당합니다. 기본적으로 네트워크는 명령어당 최대 200,000 CU(컴퓨팅 단위)로 제한을 설정합니다. 그러나 트랜잭션은 보다 효율적인 리소스 할당을 위해 SetComputeUnitLimit 지시어를 포함하여 사용자 지정 컴퓨팅 단위 제한을 지정할 수 있습니다. 아가베 클라이언트 코드베이스에는 다양한 작업에 대한 CU 비용이 나열되어 있습니다.
솔라나는 모든 트랜잭션이 트랜잭션 중에 읽거나 쓸 계정 주소의 전체 목록을 지정하도록 요구합니다. 이 목록의 최대 크기는 35개 주소이며 체인 주소 조회 테이블을 통해 액세스할 수 있습니다. 주소 목록을 구축하면 개발자에게 추가적인 오버헤드가 발생하지만, 병렬 트랜잭션 실행과 현지화된 비용 시장 등 솔라나의 많은 최적화를 실현하기 위한 핵심 요소입니다.
솔라나의 현지화된 비용 시장의 초기 문제점
"현지화된 비용 시장은 거짓말입니다." Ben Coverston, Temporal 공동 창립자
2023년 말 솔라나에서 경제 활동이 가속화되면서 원래의 LFM 구현에 몇 가지 주요 결함이 드러났습니다. 이 시점에서 Ellipsis Labs의 유진 첸은 엄브라 리서치 기사에서 이러한 문제에 대한 종합적인 분석을 제공합니다. 솔라나 수수료, 1부. 아래는 첸의 핵심 내용을 요약한 것입니다.
정확하게 CU를 요청할 인센티브 부족
솔라나의 수수료 구조는 사용되거나 요청된 계산 단위(CU)에 관계없이 서명을 기준으로 기본 수수료를 부과합니다. 동시에 우선 순위 수수료는 혼잡한 기간 동안 CU 사용을 줄이기 위한 제한적인 인센티브만 제공합니다. 이러한 설계는 트랜잭션 발신자에게 컴퓨팅 사용량을 최적화하거나 CU 요청을 실제 수요에 맞추려는 인센티브를 거의 제공하지 않습니다. 그 결과, 트랜잭션은 종종 CU를 과도하게 요청하여 네트워크 스케줄링 프로세스의 비효율을 초래합니다.
프로토콜 외 우선순위 메커니즘 사용 장려
50% 우선순위 수수료는 트랜잭션 전송자가 블록 빌더와 공모하고 우선 액세스 권한을 얻기 위해 오프체인 지불을 주선함으로써 프로토콜을 우회하도록 인센티브를 부여합니다. 이러한 행동은 점점 늘어나는 지토 경매에서 분명하게 드러납니다. 지토-아가베 클라이언트를 운영하는 검증자는 더 높은 수수료 수익으로 이익을 얻고, 지토 메브 수수료 보상을 통해 위임받은 위임자에게 이러한 수익을 효과적으로 분배할 수 있습니다. 지토 아가베 클라이언트의 채택이 증가함에 따라 지토 제품군은 많은 시나리오에서 우수한 트랜잭션 전송 서비스임이 입증되고 있습니다.
비결정적 스케줄러 우선순위
솔라나의 합의나 스케줄러 모두 우선순위에 따라 트랜잭션의 순서를 엄격하게 적용하지 않습니다. 트랜잭션은 주로 블록 빌더에 도달하는 시간을 기준으로 정렬되며, 우선순위 수수료는 부차적인 고려 사항으로만 사용됩니다. 우선순위 비용이 높을수록 분쟁 상태에 포함될 가능성이 높아지지만, 정렬 프로세스는 여전히 비결정적입니다. 트랜잭션 처리 장치(TPU)에 도달하기 전의 네트워크 지터와 스케줄러 내의 지터는 예측 불가능성을 더욱 가중시킵니다.
이러한 결정성의 결여는 트랜잭션 실행의 예측 가능성과 신뢰성을 떨어뜨리고, 사용자들은 더 빨리 포함될 가능성을 높이기 위해 네트워크에 트랜잭션 스팸을 쏟아붓게 됩니다. 그러나 특정 임계값 이후 높은 우선순위 수수료의 수익이 감소하면 더 나은 거래를 배치하는 메커니즘으로서의 효율성이 떨어지고, 결국 솔라나의 공유 블록 공간은 고전적인 '공유지의 비극'의 희생양이 되고 맙니다. 각자의 이기심에 이끌린 개별 행위자들이 이 공공 자원의 남용과 비효율성을 초래한 것입니다.
중앙 스케줄러 v1.18 업데이트
아가베의 클라이언트 측 스케줄러의 초기 구현은 우선 순위가 높은 트랜잭션이 특정 블록에 포함될 확률이 더 높다는 느슨한 보장만을 제공했습니다. 리더의 트랜잭션 처리 장치(TPU)는 6개의 병렬 스레드(비투표 트랜잭션 처리용 4개와 투표 트랜잭션용으로 예약된 2개)를 사용해 실행됩니다. 각 비투표 트랜잭션 스레드는 자체 대기열을 유지하며, 대기 중인 트랜잭션이 실행을 위해 그룹화되기를 기다립니다. 이전에는 트랜잭션이 이러한 스레드에 무작위로 할당되었고, 대기열은 다른 스레드가 처리하는 패킷과 관계없이 독립적으로 패킷의 우선순위를 지정했습니다.
그림
이 시스템에서 각 스레드는 트랜잭션을 잠그고 실행하기 위해 큐를 반복합니다. 스레드가 현재 루프를 완료하면 추가 패킷을 수집하고 프로세스를 다시 시작합니다. 이러한 구조는 우선순위 비용을 효율적으로 사용하는 데 어려움이 있습니다. 예를 들어 우선순위가 높은 트랜잭션이 한 스레드의 대기열 맨 위에 있는 동안 다른 스레드는 대기열 끝에 있는 동일한 계정과 관련된 우선순위가 낮은 수수료 트랜잭션을 동시에 처리하고 있을 수 있습니다. 우선순위 수수료는 단일 스레드(스레드 내)에서만 트랜잭션 주문에 영향을 미치며 모든 스레드(스레드 간)에는 영향을 미치지 않습니다. 따라서 각 대기열은 선입 선출(FIFO) 처리와 우선순위 비용 고려 사항을 결합한 하이브리드 정렬 메커니즘을 적용합니다. 그러나 스레드 간에는 전역 정렬이 적용되지 않습니다.
스레드가 트랜잭션을 실행할 준비가 되면 먼저 필요한 계정 잠금을 획득해야 합니다. 필요한 쓰기 잠금을 사용할 수 없는 경우 트랜잭션이 다시 대기열에 추가됩니다. 멀티스레드 스케줄링 시스템에서는 동일한 트랜잭션 유형이 서로 다른 위치에 있을 수 있으므로 스레드에 트랜잭션이 무작위로 할당되면 문제가 더욱 악화됩니다. 이러한 스케줄러의 무작위성은 지터를 발생시켜 트랜잭션이 블록에 배치되는 위치에 변동성을 유발합니다.
2024년 5월 Agave 클라이언트 v1.18 업데이트에서 새로운 트랜잭션 스케줄러인 중앙 스케줄러가 도입되었습니다. 이 개정된 구조에서 중앙 스케줄러는 우선순위 그래프라고 하는 종속성 그래프를 구축하여 모든 스레드에서 충돌하는 트랜잭션의 처리와 우선순위를 더 잘 관리합니다. 이 주요 업데이트는 트랜잭션의 우선순위를 결정하는 솔라나의 기능을 크게 개선하여 우선순위가 높은 트랜잭션이 블록에 포함될 가능성을 높였습니다.
그림
우선순위 그래프는 새로운 거래가 추가되면 동적으로 업데이트되는 방향성 비순환 그래프(DAG)입니다. 그래프에서 트랜잭션은 시간 우선순위에 따라 처리되는 실행 체인으로 구성됩니다. 충돌하는 트랜잭션의 경우 우선순위 비용에 따라 삽입 순서가 결정됩니다. 이 접근 방식은 잠금 경합을 최소화하여 트랜잭션 배치를 원활하게 실행하고 리소스 충돌로 인한 지연을 줄입니다. 트랜잭션 사전 컴파일 유효성 검사가 워커 스레드로 오프로드되어 성능이 향상되고 보다 효율적인 처리가 가능해졌습니다.
그림
업데이트된 스케줄러 설계는 확장성과 유연성을 크게 향상시켜 잠금 충돌의 위험 없이 스레드 수를 잠재적으로 늘릴 수 있도록 합니다. 또한 중앙 집중식 스케줄링 방식은 보상 창출을 개선하여 많은 검증인 운영자의 수익을 증가시킵니다.
중앙 집중식 스케줄러에 대한 자세한 내용은 이전 Helius 블로그 게시물에서 Agave 1.18. 업데이트 를 참조하세요.
보다 효율적인 우선순위 계산
스케줄러 업데이트와 함께 트랜잭션 우선순위 공식이 개선되어 계산 요구 사항이 낮은 트랜잭션에 유리하도록 하여 개발자와 리소스 사용량이 가장 적은 사용자 모두에게 혜택을 제공합니다.
위: Base58로 인코딩된 직렬화된 트랜잭션을 사용한 getPriorityFeeEstimate의 로드 예시.
우선순위 수수료를 계산하는 결정적인 방법이 없기 때문에 개발자는 종종 트랜잭션 처리를 위해 초과 지불을 하는 신중한 접근 방식을 취합니다. 또는 블록의 상단을 확보할 필요가 없는 트랜잭션에서도 지토 팁으로 초과 지불할 수 있습니다. 이러한 팁은 종종 우선순위 수수료를 대신하는 용도로 사용됩니다. 2024년에 관찰된 대부분의 팁은 차익거래나 피닝과 같은 전통적인 MEV 활동과 관련이 없으며, 오히려 트랜잭션의 빠른 포함을 위해 설계되었다는 점에 주목할 필요가 있습니다. 검증자는 더 높은 블록 보상과 MEV 수수료를 부과함으로써 이러한 비효율성을 통해 이득을 얻습니다.
또 다른 문제는 개발자가 변동하는 온체인 조건에 따라 우선순위 수수료를 동적으로 조정하는 로직을 구현하지 못했을 때 발생합니다. 주요 이벤트(예: 시장 변동성이 큰 경우)가 발생하면 특정 스테이트 계정에 액세스하는 데 드는 수수료가 급격히 증가할 수 있습니다. 동적 수수료 메커니즘이 없는 애플리케이션은 정적 수수료 설정으로 적시에 실행을 보장하기에 충분하지 않기 때문에 이러한 상황에서 어려움을 겪을 수 있습니다.
제안된 솔루션
솔라나의 수수료 구조를 더욱 개선하기 위한 다양한 전략이 제안되었습니다. 이러한 제안은 네트워크 리소스 할당을 최적화하고 스팸 인센티브를 완화하는 것을 목표로 합니다.
기하급수적 쓰기-잠금 수수료
SIMD-0110은 2023년 1월에 Tao Zhu(Anza)와 Anatoly Yakavenko가 분쟁 계정에 동적 수수료를 부과하여 정체를 관리하기 위한 새로운 메커니즘을 제안합니다. 이 메커니즘은 쓰기 잠금 계정의 컴퓨팅 유닛(CU) 사용률의 지수이동평균(EMA)을 추적하여 사용률이 지속적으로 높은 쓰기 잠금 계정의 수수료를 인상하는 방식입니다.
이러한 시스템을 구현하기 위해 Solana 런타임은 분쟁 계정에 대한 공개 키의 LRU(최소 최근 사용) 캐시 및 해당 CUP(컴퓨팅 단위 가격)를 유지하며, CUP는 계정의 EMA CU 사용률을 모니터링하고 쿼리 시점에 업데이트된 수수료율을 제공합니다.
이 메커니즘은 쓰기 잠금 수수료를 동적으로 조정합니다. 계정의 EMA CU 사용률이 목표 임계값을 초과하면 쓰기 잠금 비용 비율이 증가합니다. 반대로 사용률이 목표보다 낮으면 비용 비율이 감소합니다. 초기 매개변수에는 다음이 포함됩니다.
목표 사용률은 계정 최대 CU 한도의 25%입니다.
초기 쓰기 잠금 비용 비율은 CU당 1,000 마이크로 라포트입니다.
비용 조정률은 블록당 1%입니다.
계정 쓰기 잠금 수수료는 해당 수수료율에 거래 요청의 CU를 곱하여 계산됩니다. 이 시스템에서 총 거래 수수료는 기본 서명 수수료, 우선순위 수수료, 쓰기 잠금 수수료의 세 가지 요소를 합한 값입니다. 쓰기 잠금 수수료는 100% 소멸됩니다.
공개 당시 SIMD-0110은 커뮤니티 내에서 많은 논의를 불러일으켰습니다. 그러나 이 제안은 현재 비활성 상태이며 마감된 것으로 표시되어 있습니다.
동적 기본 수수료
솔라나의 LFM을 개선하기 위한 또 다른 장기적인 해결책은 전 세계 및 계정별로 동적 기본 수수료(DBF)를 도입하는 것입니다. 엘립시스 랩의 제리 샤오와 유진 첸은 이 접근법의 지지자로 잘 알려져 있습니다. 이 접근 방식의 지지자들.
우선 순위 수수료는 선택 사항이지만 기본 수수료는 필수입니다. 현재 솔라나의 기본 수수료는 서명당 5,000라봇으로 고정되어 있습니다. 간단한 토큰 전송을 제출하는 사용자는 복잡한 멀티플레이스 교환을 수행하거나 복잡한 MEV 차익거래를 시도하는 검색자와 동일한 기본 수수료를 지불합니다. 기본 수수료는 거래의 계산된 사용량을 정확하게 반영하지 않습니다.
동적 기본 수수료를 사용하면 기본 수수료가 부적절한 차익거래는 무효로 처리되어 디스패처에 도달하기 전에 폐기될 수 있습니다. 기본 수수료를 인상하면 스패머가 더 적은 수의 거래를 보내도록 유도할 수 있습니다.
기본 수수료는 결국 균형에 도달하고 블록 공간 시장의 가치에 따라 거래 가격이 책정될 것입니다. 기본 수수료가 상승하면 결국 한계 비용에 도달하게 되며, 이 시점에서는 트랜잭션을 전송하는 것이 더 이상 거래의 기회 비용에 비해 가치가 없습니다. 수수료가 너무 높아서는 안 됩니다. 그렇지 않으면 사용자 활동이 위축될 것입니다. 로봇에게는 너무 높지만 사용자에게는 일반적으로 허용되는 최대값이 이상적입니다. 이러한 시스템을 사용하면 포함을 위해 거래를 전송하는 계정은 SOL을 모두 소진하게 됩니다.
솔라나의 빠른 블록 시간 덕분에 공격적인 알고리즘으로 기본 수수료를 설정할 수 있습니다. 수요가 많은 기간에는 네트워크 혼잡을 반영하여 블록당 수수료를 빠르게 조정할 수 있습니다(잠재적으로 두 배까지). 반대로 수요가 감소하면 수수료를 점진적으로 낮출 수 있습니다. 솔라나는 블록 시간이 짧기 때문에 수수료가 상대적으로 빠르게 인하되어 네트워크가 변화하는 상황에 빠르게 적응할 수 있습니다.
유사한 경제적 카운터 스트레스의 예로는 Metaplex Candy Machine 프로그램이 있으며, 이 프로그램은 2022년에 스팸 방지 메커니즘으로 봇세를 도입했습니다. 봇세는 유효하지 않은 거래에 대해 선택적으로 부과되는 세금입니다. 일반적으로는 진심 어린 실수를 한 진짜 사용자에게 영향을 미치지 않도록 비교적 적은 금액이 부과됩니다. 이 세금의 효과는 입증되어 캐스팅 스나이퍼가 빠르게 고갈되고 스팸이 중단되었습니다.
결론
솔라나의 LFM은 기능적이지만 아직 개선의 여지가 많습니다:
우선순위 수수료 메커니즘 개선:우선순위 수수료 RPC 호출은 개선이 필요합니다. 이상적으로는 개발자가 다음 몇 블록 내에 트랜잭션이 포함되도록 간단하고 결정적인 방법으로 수수료를 설정할 수 있어야 합니다.
스팸에 대한 경제적 불이익: 네트워크는 경제 활동이 활발한 기간 동안 봇에 경제적 압박을 가하는 동시에 실제 인간 사용자에게는 수수료를 낮게 유지할 수 있는 방법을 찾아야 합니다.
개발자 교육: 개발자는 정적인 앱 거래 수수료 설정을 중단하고 일반 거래를 위해 Jito와 같은 프로토콜 외 메커니즘에 대한 의존도를 줄여야 합니다.
스케줄러 최적화: 트랜잭션 스케줄러를 더욱 최적화하여 수요가 많은 기간 동안 모든 워커 스레드가 활용될 수 있도록 해야 합니다.
솔라나의 공동 창립자인 아나톨리 야코벤코가 지적한 것처럼, 이러한 문제는 주로 '엔지니어링 문제'로서 적절한 기술적 관심을 기울이면 해결할 수 있습니다. -적절한 기술적 관심을 기울이면 해결할 수 있습니다.
기타 리소스
솔라나 수수료, 파트 1 - Umbra Research
다차원 솔라나 수수료 - Umbra Research
로컬 수수료 이더리움 확장을 위한 시장 필요성 - Eclipse Labs
솔라나의 로컬 수수료 시장은 진짜가 아니다 | 유진 첸 - Lightspeed 팟캐스트
솔라나 뱅킹 스테이지 및 스케줄러 - A.Fitzgerald
Preview
유익한 보고서를 통해 암호화 산업에 대한 더 넓은 이해를 얻고 비슷한 생각을 가진 다른 저자 및 독자와 심도 있는 토론에 참여하십시오. 성장하는 Coinlive 커뮤니티에 참여하실 수 있습니다.https://t.me/CoinliveSG