왜 고성능 RPC가 중요한가
사용자를 위한 블록체인 진입 관문
RPC(Remote Procedure Call) 인터페이스는 사용자가 블록체인과 상호작용하는 주요 방법입니다:- 지갑은 트랜잭션을 브로드캐스트하기 위해 RPC를 사용합니다.
- DApp은 UI 렌더링을 위한 온체인 데이터 조회뿐 아니라, 트랜잭션 준비 및 시뮬레이션, 로그 및 이벤트 수집 등을 위해 RPC를 사용합니다.
- 익스플로러, 인덱서, 봇 등도 모두 실시간 데이터를 위해 RPC에 의존합니다.
기존 RPC 아키텍처의 문제점
모놀리식 설계와 리소스 충돌
- 체인 동기화와 RPC 요청 처리가 동일한 인스턴스에서 수행됩니다.
- RPC를 확장하려면 풀노드를 새로 셋업해야 하며, 이로 인해 상태 동기화(state sync)나 합의 셋업과 같은 리소스 집약적인 작업이 필요합니다.
- 합의, 실행, RPC가 모두 동일한 CPU, 메모리, 디스크를 공유합니다. 예를 들어 트랜잭션 부하가 높을 때 한 컴포넌트가 자원을 독점하면, 나머지 컴포넌트가 충분한 리소스를 얻지 못해 RPC 성능이 저하됩니다.
eth_getBalance와 같은 읽기 쿼리는 쓰기 트랜잭션보다 훨씬 빈도 수가 많지만, 처리 방식에는 차이가 없습니다. 이러한 구조는 본질적으로 비효율적이며 확장성이 떨어집니다.
Stable의 RPC 아키텍처
Stable은 읽기와 쓰기를 분리하고 각 경로를 독립적으로 최적화하는 split-path RPC 아키텍처를 도입합니다.
핵심 원칙
- RPC를 기능에 따라 효율적이고 경량화된 RPC 노드로 분리
- 경량 RPC를 엣지 노드(edge nodes)로 배포하여 확장성 강화
- 각 기능별 RPC의 데이터 경로를 최적화하여 지연을 줄이고 더 직접적이고 효율적인 데이터 구조로 처리
성능 향상
새로운 읽기 전용 RPC 경로에 대한 내부 벤치마크 결과는 다음과 같습니다.- 동일한 환경에서 10,000 RPS 이상의 처리량, 100ms 미만의 엔드투엔드 레이턴시
- 전체 상태 동기화나 합의 부담 없이 선형 확장 가능한 엣지 노드
향후 계획
EVM View 호출 최적화
현재 진행 중인 리서치 중 하나는 EVM view 연산 (eth_call)에 대한 전용 지원입니다:
- 이 연산은 트랜잭션 커밋이나 상태 업데이트를 필요로 하지 않습니다.
- 현재의 상태에 대한 스냅샷만을 사용하는 경량화된 무상태(stateless) 환경에서 실행이 가능합니다.
- 이러한 작업을 위한 특화된 RPC 노드를 설계하면, 응답 시간을 더욱 단축시키고 주요 전체 노드의 부하를 줄일 수 있습니다.
인덱서와 노드의 결합
인덱서를 노드에 직접 통합하면 dApp에 최대한 빠른 데이터 제공이 가능해집니다.- 기존 아키텍처: 노드 → RPC → 인덱서 (예: The Graph) → 스토리지 → dApp
- 제안된 아키텍처: 인덱서 + 노드 → DB → dApp
- 이 아키텍처는 인덱서가 노드에 네이티브로 통합되어 있기 때문에, 네트워크 통신 단계를 제거하고 데이터 전달 속도를 획기적으로 향상시킵니다.