Workspace IndexDev Notes › An RPC response is a view, not consensus

#25PoC

An RPC response is a view, not consensus

A hosted RPC reports what one node currently believes. Availability, correctness, canonicality, and finality are separate properties, yet applications often compress them into "the chain says."

Run two operationally independent providers side by side (different vendors on different client implementations), poll latest / safe / finalized block number plus hash from each, and put a small proxy in front of one endpoint to inject the four failure cases: timeout, lag, equal-height/different-hash, and a shared stale answer.

Why

Multi-provider failover fixes downtime but can amplify disagreement unless responses are compared by block hash and confidence tag. The PoC turns RPC trust into an observable policy.

An RPC provider exposes one node's present view. It may be unavailable, stale, following a temporary fork, or simply wrong. A second endpoint improves availability, but two URLs are not automatically two independent observations: they may share an operator, cloud, client implementation, or upstream node. The goal is failure independence, not endpoint count.

How it works

Query two independent providers for latest, safe, and finalized block number plus hash; inject a stale or disagreeing response; and define when the application degrades, retries, or refuses an irreversible action.

What two providers actually buy

The useful pattern is not "always send every request twice." It is to match the RPC policy to the business risk.

Pattern Behavior Problem solved
Failover Use B when A fails Availability
Hedged request Ask B when A is slow Tail latency
Agreement check Compare A and B by block hash Disagreement detection

With two providers, agreement increases confidence and disagreement tells the application to stop or retry. Two providers cannot decide which answer is correct when they disagree.

Confidence tags

Tag Meaning Typical use
latest The node's current proposed head; it can change UI and reversible reads
safe A head with substantially stronger reorg resistance Higher-confidence processing
finalized The latest finalized block reported by the node Irreversible, high-value fulfillment

The tags are still reported through RPC. They strengthen the requested chain state; they do not make the provider itself a consensus oracle.

PoC

Inject timeout, lag, equal-height/different-hash, and shared-stale-answer cases, and record four separate signals:

Signal Question
Availability Did an endpoint answer?
Freshness How far behind is its reported head?
Agreement Do independent nodes report the same block hash?
Confidence Is the block latest, safe, or finalized?

Allow low-risk reads to degrade with a stale warning. Pause collateral release, expensive fulfillment, or other irreversible actions when the required confidence or agreement cannot be established. A practical default is primary-plus-fallback for ordinary UI reads and explicit finalized-hash agreement for selected high-value actions.

Reference: Ethereum JSON-RPC API.

← All Dev Notes · Workspace Index · Top ↑

RPC 응답은 합의가 아니라 하나의 관점이다

호스팅 RPC 는 노드 하나가 지금 믿는 것을 보고합니다. 가용성·정확성·정규성·최종성은 서로 다른 속성인데, 애플리케이션은 이를 곧잘 "체인이 말한다" 한마디로 압축합니다.

운영상 독립적인 프로바이더 둘을 나란히 둡니다(클라이언트 구현이 다른 서로 다른 벤더). 각각에서 latest / safe / finalized 블록 번호와 해시를 폴링하고, 한쪽 엔드포인트 앞에 작은 프록시를 두어 네 가지 실패 — 타임아웃, 지연, 같은 높이·다른 해시, 둘 다 오래된 답 — 를 주입합니다.

멀티 프로바이더 failover 는 다운타임은 고치지만, 응답을 블록 해시와 신뢰도 태그로 비교하지 않으면 불일치를 오히려 증폭시킬 수 있습니다. 이 PoC 는 RPC 신뢰를 관찰 가능한 정책으로 바꿉니다.

RPC 제공자는 한 노드의 현재 관점을 노출합니다. 응답하지 않거나, 뒤처지거나, 일시적 포크를 따라가거나, 그냥 틀릴 수 있습니다. 두 번째 엔드포인트는 가용성을 높이지만, URL 두 개가 자동으로 독립 관점 둘이 되는 것은 아닙니다 — 같은 운영사·클라우드·클라이언트 구현·업스트림 노드를 공유할 수 있기 때문입니다. 목표는 엔드포인트 개수가 아니라 장애 독립성입니다.

동작 방식

운영상 독립적인 두 제공자에게 latest·safe·finalized 블록 번호와 해시를 요청하고, 오래되거나 불일치하는 응답을 주입한 뒤, 애플리케이션이 언제 성능을 낮추고, 재시도하고, 비가역 작업을 거부하는지 정의합니다.

프로바이더 두 개가 실제로 사 주는 것

좋은 패턴은 "모든 요청을 언제나 두 번 보낸다"가 아니라 비즈니스 위험도에 RPC 정책을 맞추는 것입니다.

패턴 동작 해결하는 문제
Failover A 가 실패하면 B 사용 가용성
Hedged request A 가 느리면 B 에도 요청 긴 꼬리 지연
Agreement check A 와 B 의 블록 해시 비교 불일치 감지

둘이 동의하면 확신이 커지고, 불일치하면 애플리케이션이 멈추거나 재시도할 근거가 생깁니다. 하지만 둘이 다를 때 어느 쪽이 맞는지는 두 개만으로 결정할 수 없습니다.

신뢰도 태그

태그 대표 용도
latest 노드가 현재 보는 최신 제안 블록이며 바뀔 수 있음 UI 와 되돌릴 수 있는 읽기
safe reorg 저항이 훨씬 강한 head 더 높은 확신이 필요한 처리
finalized 노드가 보고하는 최신 최종 확정 블록 비가역적이고 고가치인 이행

이 태그들도 RPC 를 통해 전달됩니다. 요청하는 체인 상태의 강도를 높일 뿐, 제공자 자체를 합의 오라클로 만들지는 않습니다.

PoC

타임아웃, 지연, 같은 높이의 다른 해시, 두 곳이 함께 오래된 답을 주는 상황을 주입하고 네 신호를 따로 기록합니다.

신호 질문
가용성 엔드포인트가 응답했는가?
신선도 보고한 head 가 얼마나 뒤처졌는가?
일치 독립 노드가 같은 블록 해시를 보고하는가?
신뢰도 그 블록은 latest, safe, finalized 중 무엇인가?

저위험 읽기는 오래된 데이터 경고와 함께 계속할 수 있습니다. 담보 해제, 고가 상품 제공 등 비가역 작업은 필요한 신뢰도나 일치를 확인할 수 없으면 중단합니다. 현실적인 기본값은 일반 UI 읽기에 primary + fallback, 선택된 고가치 작업에만 finalized 해시 일치를 명시적으로 확인하는 것입니다.

참고: Ethereum JSON-RPC API.

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑