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

목적: 멀티 프로바이더 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](https://ethereum.org/developers/docs/apis/json-rpc/).