고성능 블록체인을 구현하기 위해서는 합의나 블록 생성만을 최적화해서는 충분하지 않습니다. RPC 계층은 블록체인과 사용자를 연결하는 인터페이스로, 사용자 경험에 있어 핵심적인 구성 요소입니다. Stable은 기존 RPC 설계의 한계를 극복하기 위해 새로운 RPC 전용 아키텍처를 제안합니다.

​
왜 고성능 RPC가 중요한가

​
사용자를 위한 블록체인 진입 관문

RPC(Remote Procedure Call) 인터페이스는 사용자가 블록체인과 상호작용하는 주요 방법입니다:
  • 지갑은 트랜잭션을 브로드캐스트하기 위해 RPC를 사용합니다.
  • DApp은 UI 렌더링을 위한 온체인 데이터 조회뿐 아니라, 트랜잭션 준비 및 시뮬레이션, 로그 및 이벤트 수집 등을 위해 RPC를 사용합니다.
  • 익스플로러, 인덱서, 봇 등도 모두 실시간 데이터를 위해 RPC에 의존합니다.
아무리 블록체인이 트랜잭션을 빠르게 처리하고 블록을 신속하게 생성할 수 있어도, 사용자가 RPC 단의 지연 때문에 느리다고 느낀다면 아무 소용이 없습니다. 실제로는 RPC가 전체 사용자 경험에서 병목 지점이 되는 경우가 많습니다. Stable은 고성능 체인을 위한 로드맵에서 RPC 최적화를 최우선 과제로 명시하고 있습니다.

​
기존 RPC 아키텍처의 문제점

​
모놀리식 설계와 리소스 충돌

Traditional RPC Architecture 기존의 RPC 노드는 단순히 기존 풀노드를 재활용하여 RPC 엔드포인트를 추가로 노출시킨 형태입니다. 이는 다음과 같은 단점이 존재한다는 것을 의미합니다:
  • 체인 동기화와 RPC 요청 처리가 동일한 인스턴스에서 수행됩니다.
  • RPC를 확장하려면 풀노드를 새로 셋업해야 하며, 이로 인해 상태 동기화(state sync)나 합의 셋업과 같은 리소스 집약적인 작업이 필요합니다.
  • 합의, 실행, RPC가 모두 동일한 CPU, 메모리, 디스크를 공유합니다. 예를 들어 트랜잭션 부하가 높을 때 한 컴포넌트가 자원을 독점하면, 나머지 컴포넌트가 충분한 리소스를 얻지 못해 RPC 성능이 저하됩니다.
또한 기존 아키텍처는 읽기 위주와 쓰기 위주의 연산을 구분하지 않고 동일한 방식으로 처리합니다. 예를 들어 eth_getBalance와 같은 읽기 쿼리는 쓰기 트랜잭션보다 훨씬 빈도 수가 많지만, 처리 방식에는 차이가 없습니다. 이러한 구조는 본질적으로 비효율적이며 확장성이 떨어집니다.

​
Stable의 RPC 아키텍처

Stable은 읽기와 쓰기를 분리하고 각 경로를 독립적으로 최적화하는 split-path RPC 아키텍처를 도입합니다. Stable RPC Architecture

​
핵심 원칙

  • RPC를 기능에 따라 효율적이고 경량화된 RPC 노드로 분리
  • 경량 RPC를 엣지 노드(edge nodes)로 배포하여 확장성 강화
  • 각 기능별 RPC의 데이터 경로를 최적화하여 지연을 줄이고 더 직접적이고 효율적인 데이터 구조로 처리

​
성능 향상

새로운 읽기 전용 RPC 경로에 대한 내부 벤치마크 결과는 다음과 같습니다.
  • 동일한 환경에서 10,000 RPS 이상의 처리량, 100ms 미만의 엔드투엔드 레이턴시
  • 전체 상태 동기화나 합의 부담 없이 선형 확장 가능한 엣지 노드
Stable의 새로운 RPC 아키텍처는 높은 트래픽에서도 훨씬 더 부드럽고 빠른 사용자 경험을 제공합니다.

​
향후 계획

​
EVM View 호출 최적화

현재 진행 중인 리서치 중 하나는 EVM view 연산 (eth_call)에 대한 전용 지원입니다:
  • 이 연산은 트랜잭션 커밋이나 상태 업데이트를 필요로 하지 않습니다.
  • 현재의 상태에 대한 스냅샷만을 사용하는 경량화된 무상태(stateless) 환경에서 실행이 가능합니다.
  • 이러한 작업을 위한 특화된 RPC 노드를 설계하면, 응답 시간을 더욱 단축시키고 주요 전체 노드의 부하를 줄일 수 있습니다.

​
인덱서와 노드의 결합

인덱서를 노드에 직접 통합하면 dApp에 최대한 빠른 데이터 제공이 가능해집니다.
  • 기존 아키텍처: 노드 → RPC → 인덱서 (예: The Graph) → 스토리지 → dApp
  • 제안된 아키텍처: 인덱서 + 노드 → DB → dApp
  • 이 아키텍처는 인덱서가 노드에 네이티브로 통합되어 있기 때문에, 네트워크 통신 단계를 제거하고 데이터 전달 속도를 획기적으로 향상시킵니다.