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.

Where it lands in Jayverse

Devnet: treat every read as unverified by definition. A single-node hosted Anvil fork has no second independent view, so any finality-confidence logic must actually be tested against Sepolia, or later the OP-Stack L2, where a second provider exists.
Bridge: gate mint or release on a confidence tag, not "latest." Lock-and-mint should require a finalized (or explicit safe) block hash from at least two independent providers before releasing funds; failing to reach that tag should pause release, not retry against a fresh latest.
Verex: define per-action risk explicitly. Cheap, reversible reads can use failover; market resolution and payout should require agreement-by-hash across independent RPC providers before being treated as final.

Key expressions

Words and phrases from this page worth keeping, with the Korean meaning and the sentence they come from.

Expression	뜻 · 쓰이는 자리
stale	오래되어 더는 최신이 아닌, 신뢰하기 힘든 · "It may be unavailable, stale, following a temporary fork"
amplify	증폭시키다, 문제를 더 키우다 · "can amplify disagreement unless responses are compared"
failure independence	장애가 서로 독립적으로 발생하는 성질 · "The goal is failure independence, not endpoint count"
tail latency	드물게 발생하는 아주 느린 응답(꼬리 지연) · "Ask B when A is slow"
hedge (a request)	위험 분산을 위해 예비로 같이 요청하다 · "Ask B when A is slow"
degrade	성능·신뢰도가 한 단계 낮은 수준으로 떨어지다 · "Allow low-risk reads to degrade with a stale warning"
irreversible action	되돌릴 수 없는 행동 · "Pause collateral release, expensive fulfillment, or other irreversible actions"
confidence tag	신뢰도를 나타내는 표식 · "compared by block hash and confidence tag"

← All Knowledge 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.

Jayverse에서의 위치

Devnet: 모든 읽기를 정의상 미검증으로 취급한다. 호스팅된 단일 노드 Anvil 포크에는 독립된 두 번째 시야가 없으므로, 파이널리티 신뢰도 로직은 실제로 두 번째 프로바이더가 존재하는 Sepolia나 이후의 OP-Stack L2에서 검증해야 한다.
Bridge: "latest"가 아니라 신뢰도 태그로 민팅/방출을 통제한다. lock-and-mint은 자금을 방출하기 전 최소 두 독립 프로바이더로부터 finalized(또는 명시적 safe) 블록 해시를 요구해야 한다. 그 태그에 도달하지 못하면 새 latest로 재시도하지 말고 방출을 멈춘다.
Verex: 액션별 위험도를 명시적으로 정의한다. 저렴하고 가역적인 읽기는 페일오버를 써도 되지만, 마켓 정산과 정산금 지급은 독립 RPC 프로바이더 간 해시 일치를 확인한 뒤에야 확정으로 취급한다.

핵심 표현

이 페이지의 영어 본문에서 배울 만한 단어와 표현, 뜻과 나온 자리.

Expression	뜻 · 쓰이는 자리
stale	오래되어 더는 최신이 아닌, 신뢰하기 힘든 · "It may be unavailable, stale, following a temporary fork"
amplify	증폭시키다, 문제를 더 키우다 · "can amplify disagreement unless responses are compared"
failure independence	장애가 서로 독립적으로 발생하는 성질 · "The goal is failure independence, not endpoint count"
tail latency	드물게 발생하는 아주 느린 응답(꼬리 지연) · "Ask B when A is slow"
hedge (a request)	위험 분산을 위해 예비로 같이 요청하다 · "Ask B when A is slow"
degrade	성능·신뢰도가 한 단계 낮은 수준으로 떨어지다 · "Allow low-risk reads to degrade with a stale warning"
irreversible action	되돌릴 수 없는 행동 · "Pause collateral release, expensive fulfillment, or other irreversible actions"
confidence tag	신뢰도를 나타내는 표식 · "compared by block hash and confidence tag"

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