Solana SWQoS Endpoint 문서

SWQoS Endpoint란?

ERPC가 제공하는 SWQoS Endpoint는 stake 연결을 보유한 사용자가 전용 레인을 통해 트랜잭션을 전송할 수 있도록 해 주는 고성능 RPC 서비스입니다.
공유 플랜과 전용 플랜 모두에서 사용할 수 있으며, 더 빠르고 안정적인 트랜잭션 전달을 가능하게 합니다.

이 endpoint는 ERPC 웹 Dashboard에서 보유 중인 elSOL을 등록하여 발급받을 수 있습니다.

ERPC 웹 Dashboard: https://dashboard.erpc.global/ko

SWQoS란?

**SWQoS (Stake weighted Quality of Service)**는 stake 연결을 보유한 validator를 우선시하는 통신 제어 메커니즘입니다.
리더는 전체 대역폭 중 약 80%를 우선 레인에, 20%를 비우선 레인에 할당합니다.

stake 연결을 보유한 트래픽은 우선 레인을 활용할 수 있으면서 동시에 비우선 레인을 통해서도 전송될 수 있습니다. 그 결과, 비우선 레인에만 의존하는 트래픽에 비해 실효 전달 용량이 현저히 커집니다.
이 제어는 Priority fee 처리 이전, 즉 트래픽이 수용되어 리더 방향으로 라우팅되는 단계에서 적용되므로, 트랜잭션이 우선 레인에 도달하는지 여부가 이후 처리 속도에 직접적인 영향을 미칩니다.

Priority Fee와의 관계

Priority fee는 중요한 역할을 하지만, 이는 트랜잭션이 SWQoS 라우팅을 통해 리더에 도달한 이후에 적용됩니다.
트랜잭션이 SWQoS 우선 레인에 진입하지 못하면 Priority fee의 효과는 제한적이 되며, 기본적인 도달성을 개선하기 어렵습니다.
최적의 운용을 위해서는 SWQoS 기반의 도달성과 적절한 Priority fee 설정을 결합하는 것이 가장 효과적입니다.

비용 구조의 전환

기존의 트랜잭션 제출 서비스에서는 사용자가 트랜잭션을 전송할 때 Tips를 첨부해야 했습니다.
ERPC의 SWQoS Endpoint에서는 Tips가 필요하지 않습니다. 대신 elSOL을 보유함으로써 우선 대역폭에 대한 접근 권한이 부여됩니다.

elSOL은 SOL을 staking하여 발행되는 Solana의 **Liquid Staking Token (LST)**입니다.
SOL 대비 교환 비율은 누적된 staking 보상을 반영하며, 1:1 비율로 고정되어 있지 않습니다.

elSOL은 unstaking 과정을 통해 다시 SOL로 변환할 수 있으며, 누적된 staking 보상이 반영되어 정산됩니다.

elSOL을 통해 staking된 SOL은 ERPC에 연결된 validator에게 위임됩니다.
elSOL 보유량이 증가할수록 ERPC 전체에서 사용 가능한 SWQoS 대역폭이 확대됩니다.
사용자는 elSOL을 보유함으로써 네트워크 강화에 직접 기여하고, 그 대가로 전용 전송 레인에 대한 접근 권한을 얻습니다.

elSOL 공식 사이트: https://elsol.app/en

대역폭 할당 (TPS 구조)

공유 SWQoS Endpoint에서는 eligible user가 연결된 wallet에 보유한 4.2 elSOL마다 1 TPS를 받으며, 소수점은 내림 처리됩니다. 예를 들어 10 elSOL을 보유하면 2 TPS가 부여됩니다.

실제로 사용할 수 있는 TPS는 ERPC plan 최대치와 elSOL 기반 할당 중 더 낮은 값으로 결정됩니다.

Developer Plan+ 및 Bundle Plans를 포함한 eligible ERPC shared plan은 dashboard가 elSOL을 보유한 wallet을 확인한 뒤 shared SWQoS 할당을 사용할 수 있습니다.

Dedicated RPC node의 경우 SWQoS는 +€100/month 옵션으로 제공되며, dedicated node에 1,000 SOL staking allocation을 할당합니다.

설정과 확인은 ERPC Dashboard에서 처리됩니다: https://dashboard.erpc.global

연결 워밍 유지 (Keep Alive)

ERPC의 Solana SWQoS endpoint에서는 /ping으로 GET 요청을 전송하여 클라이언트와 ERPC SWQoS endpoint 간의 HTTPS 연결을 유지할 수 있습니다.

트랜잭션을 제출할 때, 첫 번째 요청에서는 HTTPS 및 TLS 세션 수립에 약간의 시간이 소요됩니다.
미리 /ping을 전송하여 이 연결을 활성 상태로 유지하면, 실제 트랜잭션을 전송할 때 초기 연결 지연을 피하고 즉시 트랜잭션 제출 프로세스에 진입할 수 있습니다.

트랜잭션을 연속적으로 전송하지 않더라도, 이 방식은 특정 순간에 트랜잭션을 신속하게 전송해야 하는 구성에서 효과적이며, 초기 제출 동작을 안정화하는 데 도움이 됩니다.

Ping Endpoint

Keep Warming은 SWQoS endpoint의 /ping으로 GET 요청을 전송하여 수행됩니다.
이 요청은 어떠한 트랜잭션도 처리하지 않으며, 오직 클라이언트와 ERPC 간의 연결 상태를 유지하기 위해서만 사용됩니다.

Endpoint 형식 (HTTPS)

text

https://<your-swqos-endpoint-domain>/ping

https://<your-swqos-endpoint-domain>/ping

<your-swqos-endpoint-domain>을 ERPC가 제공하는 SWQoS 전용 도메인으로 교체하세요.

사용 예시

주기적인 Keep Alive 예시 (JavaScript)

typescript

async function keepWarm(endpoint: string) {
  try {
    await fetch(`${endpoint}/ping`, { method: 'GET' })
  } catch {
    // Ignore failures
  }
}

setInterval(() => {
  keepWarm('https://<your-swqos-endpoint-domain>')
}, 30000)

async function keepWarm(endpoint: string) {
  try {
    await fetch(`${endpoint}/ping`, { method: 'GET' })
  } catch {
    // Ignore failures
  }
}

setInterval(() => {
  keepWarm('https://<your-swqos-endpoint-domain>')
}, 30000)

/ping을 일정한 간격으로 전송하면, 필요할 때 즉시 트랜잭션 제출을 시작할 수 있는 상태를 유지할 수 있습니다.

주의사항

・/ping은 TPS를 소비하지 않으며 elSOL 기반 대역폭 계산에 영향을 주지 않습니다 ・트랜잭션 제출을 대체하지 않습니다 ・오직 클라이언트와 ERPC 간의 연결을 유지하기 위해서만 사용되는 보조 요청입니다

SWQoS (stake 기반 라우팅)와 Priority fee의 설계는 변경되지 않습니다. Keep Warming은 트랜잭션 제출이 시작되는 순간의 지연을 줄이는 메커니즘으로 활용하세요.

Leader Slot 정보 API 문서

튼튼한 Nonce 팬-아웃을 위한 SWQoS