Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

고성능 RPC

고성능 블록체인을 추구하는 데 있어서 합의 또는 블록 생성만 최적화하는 것으로는 충분하지 않습니다. RPC 계층은 블록체인과 사용자 간의 인터페이스이므로 종단 간 사용자 경험의 중요한 구성 요소입니다. Stable은 기존 RPC 설계의 한계를 극복하기 위해 새로운 RPC 전용 아키텍처를 제안합니다.

고성능 RPC가 중요한 이유

블록체인으로 향하는 사용자의 관문

원격 프로시저 호출(RPC) 인터페이스는 사용자가 블록체인과 상호 작용하는 주요 방법입니다.

  • 지갑은 RPC를 사용하여 트랜잭션을 브로드캐스트합니다.
  • dApp은 RPC를 통해 상태를 쿼리하여 온체인 데이터로 UI를 렌더링하고, 트랜잭션을 준비 및 시뮬레이션하고, 로그 및 이벤트를 가져오는 등의 작업을 수행합니다.
  • 익스플로러, 인덱서 및 봇은 모두 실시간 데이터를 위해 RPC에 의존합니다.

블록체인이 번개 같은 속도로 트랜잭션을 처리하고 블록을 빠르게 생성할 수 있더라도, 느린 RPC로 인해 사용자가 지연 시간을 경험한다면 아무 소용이 없습니다. 실제로 RPC는 종종 전반적인 사용자 경험에서 병목 현상이 될 수 있습니다.

Stable의 고성능 체인을 향한 로드맵에는 RPC 최적화가 최우선 과제로 명시적으로 포함되어 있습니다.

기존 RPC 아키텍처의 문제점

모놀리스 설계 및 리소스 경합

기존 RPC 아키텍처

전통적으로 RPC 노드는 추가 RPC 엔드포인트가 노출된 용도 변경된 풀 노드에 불과합니다. 이는 다음을 의미합니다.

  • 체인 동기화 및 RPC 요청 서비스가 동일한 인스턴스에서 발생합니다.
  • RPC를 확장하려면 팀은 전체 새 풀 노드를 가동해야 하며, 이는 상태 동기화 및 합의 설정과 같이 리소스가 많이 소모되는 작업을 트리거합니다.
  • 합의, 실행 및 RPC는 모두 동일한 CPU, 메모리 및 디스크를 공유합니다. 높은 트랜잭션 부하 기간 동안 바쁜 구성 요소는 다른 구성 요소를 굶겨 RPC 성능을 저하시킵니다.

또한 기존 RPC 아키텍처는 읽기 위주 작업과 쓰기 위주 작업을 동일하게 처리합니다. 읽기 쿼리(예: eth_getBalance)가 쓰기 트랜잭션보다 훨씬 많음에도 불구하고 처리 방식에 차이가 없습니다. 이 설계는 본질적으로 비효율적이고 확장 불가능합니다.

Stable RPC 아키텍처

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

Stable RPC 아키텍처

핵심 원칙

  • 기능에 따라 RPC를 효율적인 경량 RPC 노드로 분리합니다.
  • 확장성을 향상시키기 위해 경량 RPC를 에지 노드로 사용합니다.
  • 기능별 RPC의 데이터 경로를 최적화하여 대기 시간을 줄이고, 보다 효율적인 데이터 구조를 통해 보다 직접적인 액세스 또는 관리를 제공합니다.

성능 향상

새로운 읽기 RPC 경로에 대한 내부 벤치마크는 다음을 보여줍니다.

  • 동일 환경에서 종단 간 대기 시간 100ms 미만으로 10,000 RPS 이상의 처리량을 지원합니다.
  • 완전한 상태 동기화 또는 합의 오버헤드 없이 에지 노드의 선형적 확장성.

Stable의 새로운 RPC 아키텍처는 트래픽이 많을 때에도 훨씬 더 원활하고 빠른 사용자 경험을 제공합니다.

향후 작업

EVM 뷰 호출 최적화

진행 중인 연구의 흥미로운 영역 중 하나는 EVM 뷰 작업(eth_call)에 대한 전용 지원입니다.

  • 이들은 트랜잭션 커밋 또는 상태 업데이트를 필요로 하지 않습니다.
  • 실행은 현재 상태 스냅샷만 사용하는 경량 무상태 환경에서 발생할 수 있습니다.
  • 이러한 작업을 위해 특별히 설계된 특수 RPC 노드를 통해 응답 시간을 더욱 단축하고 기본 풀 노드의 부하를 줄일 수 있습니다.

인덱서를 노드에 직접 통합

인덱서를 노드에 직접 통합하면 dApp에 가능한 가장 빠른 데이터를 제공할 수 있습니다.

  • 일반적인 아키텍처: Node → RPC → Indexer (예: The Graph) → Storage → dApp
  • 제안하는 아키텍처: Node with Indexer → DB → dApp
  • 이 아키텍처는 인덱서가 노드에 내장되어 네트워크 통신 단계를 제거하므로 훨씬 빠른 데이터 전송이 가능합니다.

다음 권장 사항

  • JSON-RPC API: Stable이 노출하는 eth_* 메서드를 사용하여 계약 읽기, 트랜잭션 제출 및 로그 필터링을 수행합니다.
  • 실행: 실행이 어떻게 상태를 RPC 계층에 공급하는지 확인합니다.
  • 스토리지(StableDB): RPC 읽기 쿼리가 사용하는 스토리지 계층을 검토합니다.