ERPC, Solana 트랜잭션 제출에서 SWQoS를 최대한 활용하기 위한 Durable Nonce Fanout 운영 가이드 공개

ERPC, ELSOUL LABO B.V. (본사: 네덜란드 암스테르담, 대표이사 CEO: Fumitake Kawasaki)가 운영하고 Validators DAO가 함께하는 Solana 트랜잭션 제출에서 SWQoS(Stake weighted Quality of Service)를 최대한 활용하여 높은 성공률과 낮은 지연 시간을 달성하는 방법을 설명한 새로운 실무 운영 가이드를 공개했습니다.

이 가이드는 ERPC의 SWQoS 엔드포인트를 중심으로 한 트랜잭션 제출 아키텍처를 다루며, 동일한 트랜잭션을 여러 고성능 RPC 엔드포인트로 안전하게 팬아웃하는 방법을 설명합니다. web3.js를 사용한 구체적인 구현 예제도 제공하므로 개발자는 실제 환경에 이 접근 방식을 직접 적용할 수 있습니다.

가이드는 다음 URL에서 확인할 수 있습니다: https://erpc.global/ko/doc/rpc/durable-nonce-send-transaction/

Solana 트랜잭션 제출의 구조적 특성

Solana에서 트랜잭션 제출은 슬롯 진행, 리더 스케줄링, 네트워크 라우팅, 노드 수준의 부하 상태처럼 지속적으로 변하는 요인의 영향을 받습니다. 따라서 어떤 제출 경로가 리더에 가장 빠르게 도달할지 미리 결정할 수 없습니다.

이러한 동작은 특정 RPC 제공업체나 제출 서비스의 품질 때문이 아니라 Solana 실행 모델 자체에서 비롯된 구조적 특성입니다. 결과적으로 하나의 RPC 엔드포인트에 의존하는 설계는 트랜잭션 성공률과 지연 시간 모두에서 본질적인 한계에 부딪히는 경향이 있습니다.

SWQoS 엔드포인트의 역할과 실무적 위치

ERPC가 제공하는 SWQoS 엔드포인트는 Stake weighted Quality of Service에 따라 리더에 할당된 우선순위 레인으로 트랜잭션을 제출할 수 있게 합니다. 이러한 우선순위 레인은 비우선순위 레인의 약 20%에 비해 훨씬 큰 약 80%의 대역폭을 할당받으며, Priority fee 평가보다 앞선 단계에서 적용됩니다.

이 때문에 SWQoS 엔드포인트는 고가치 트랜잭션을 제출할 때 중요한 선택지입니다. 그러나 실제 운영에서는 SWQoS를 사용하더라도 하나의 제출 경로가 항상 가장 빠른 것은 아닙니다. 동일한 슬롯 안에서도 일시적인 라우팅 차이와 고르지 않은 부하 분산으로 인해 다른 고성능 엔드포인트가 먼저 트랜잭션을 처리할 수 있습니다.

단일 경로 설계의 한계와 팬아웃의 필요성

이러한 조건에서는 하나의 최속 경로를 미리 예측하는 것이 효과적인 설계 방식이 아님이 분명합니다. 대신 팬아웃 전략은 동일한 트랜잭션을 여러 고성능 제출 경로에 동시에 보내고 먼저 처리된 경로를 채택하는 합리적이고 견고한 해결책입니다.

SWQoS를 중심에 두고 다른 빠른 RPC 엔드포인트를 함께 사용하면 시스템은 슬롯마다 달라지는 라우팅과 부하 변동에 더욱 강해질 수 있습니다.

팬아웃 운영의 근본적인 과제

동시에 동일한 트랜잭션을 여러 제출 경로로 보내면 중요한 과제가 생깁니다. 적절한 제어가 없으면 트랜잭션이 한 번만 실행된다는 보장이 사라집니다. 통제되지 않은 팬아웃은 의도하지 않은 이중 실행이나 재시도 및 재전송 로직의 붕괴를 일으킬 수 있습니다.

이러한 문제를 애플리케이션 수준의 로직만으로 방지하기는 어렵기 때문에 프로토콜 수준의 메커니즘이 필요합니다.

해결책으로서의 Durable Nonce

Solana는 이 문제를 해결하기 위한 공식 메커니즘으로 Durable Nonce를 제공합니다. 최근 블록해시 대신 nonce 값을 사용하면 동일한 서명 트랜잭션을 여러 제출 경로로 보낼 수 있으며, 네트워크에서 하나의 실행만 유효하도록 보장할 수 있습니다.

따라서 Durable Nonce는 팬아웃 기반 트랜잭션 제출을 안전하게 구현하기 위한 기반 기술 요소입니다.

이 가이드의 위치

새로 공개된 가이드는 순수한 이론이 아니라 구현 중심의 관점에서 Durable Nonce를 사용한 트랜잭션 제출을 설명합니다. SWQoS 엔드포인트의 효과를 극대화하는 제출 설계를 포괄적으로 다루며, 초기 설정부터 일상적인 운영 워크플로까지 설명합니다.

가이드에서 다루는 주요 주제

가이드는 다음과 같은 운영상 중요한 내용을 구성하여 설명합니다.

nonce 권한과 nonce 계정 설계
nonceAdvance를 포함한 올바른 명령어 순서
원시 트랜잭션을 재사용할 수 없는 운영상의 제약
여러 RPC 엔드포인트로의 병렬 제출
Durable Nonce 사용을 전제로 한 확인 설계
후속 트랜잭션 제출을 위한 안전한 전환 패턴

이러한 주제는 개념 증명 단계뿐 아니라 안정적인 프로덕션 배포를 위해서도 중요합니다.

ERPC의 실용적인 제출 아키텍처

ERPC의 트랜잭션 제출 아키텍처는 SWQoS를 핵심으로 설계하고, 서로 다른 리전과 경로에 있는 여러 고성능 RPC 엔드포인트를 결합합니다. 하나의 리전이나 제출 경로에 의존하지 않는 것은 현실적인 Solana 운영에서 중요한 요소입니다.

이 가이드는 ERPC의 멀티 리전 환경에서 실용적인 아키텍처 결정을 내릴 때 직접 적용할 수 있습니다.

대상 독자

이 가이드는 다음 개발자와 팀을 대상으로 합니다.

고빈도 또는 고가치 트랜잭션을 처리하는 개발자
기존 RPC 제출 구성에서 성공률이나 지연 시간 문제를 겪는 팀
이미 SWQoS 엔드포인트를 사용하거나 도입을 고려하는 사용자

향후 계획

ERPC는 SWQoS를 포함한 트랜잭션 제출 인프라를 계속 개선하고, 실제 배포에서 얻은 운영 지식을 가이드와 코드 예제의 형태로 점진적으로 공개할 예정입니다.

ERPC는 빠를 뿐 아니라 정확하고 운영상 안정적인 트랜잭션 제출 플랫폼으로 개발자를 지원하기 위해 계속 노력하겠습니다.

사용 방법 및 상담

최적의 제출 아키텍처, 리전 선택 또는 기존 설계에서의 마이그레이션에 관한 상담은 Validators DAO 공식 Discord를 통해 개별적으로 지원받을 수 있습니다.

Validators DAO 공식 Discord: https://discord.gg/C7ZQSrCkYR
ERPC 공식 웹 사이트: https://erpc.global/ko