---
status: DIRECT_RPC_RELAY_CANARY_PARTIAL_NAT_BLOCKED_ATTESTATION_PROTOCOL_STAGED
production_rpc_enabled: false
validator_changed: false
external_transaction_enabled: false
main_server_outage_continuity_proven: false
---

# PC read-only RPC와 NAT canary

## 실제 canary 결과

고정 hostname 없이 fresh heartbeat, canonical runtime sync, gateway와 reliability 조건으로 PC 세 대를 선택했다. candidate client `1.4.66-permissionless-read-only-rpc-relay-default-off-single-install-locked`를 device allowlist와 30분 만료 정책으로만 배포했다.

- 세 PC 모두 기존 local canonical RPC가 ready이고 gap 0~2 조건을 만족했다.
- 세 PC 모두 gateway read-only relay를 활성화하고 서버에 등록했다.
- `eth_sendRawTransaction`을 포함한 쓰기/비허용 메서드는 relay 코드에서 구조적으로 거부했다.
- validator role, key, process, set은 변경하지 않았다.
- 두 번째 동적 선택에서 관찰 failure domain 2개를 확보했다.

그러나 메인 위치에서 세 gateway를 직접 조회했을 때 한 endpoint만 도달 가능했고 두 endpoint는 7초 timeout이었다. 두 PC가 광고한 LAN/NAT 주소에는 외부 inbound 경로가 없기 때문이다. 따라서 **직접 endpoint 2-of-3 live quorum은 통과하지 못했다.**

실패 후 runtime feature policy를 false로 갱신해 relay 등록 수가 0이 된 것을 확인했고 임시 rollout policy를 삭제했다. production `.env`에는 relay 활성화 flag가 없다.

## NAT-safe 보정

모든 PC RPC port를 인터넷에 개방하지 않는다. 각 full node가 안정된 canonical checkpoint의 block number/hash/parent hash를 별도 node Ed25519 key로 서명하고, outbound 연결로 도달 가능한 임의 gateway에 전달한다. 클라이언트는 한 gateway에서 certificate를 받아도 다음을 검증한다.

1. 서로 다른 admitted node key의 서명인지
2. chain ID와 block number/hash가 일치하는지
3. attestation이 만료되지 않았는지
4. 최소 2개 또는 정책상 3개 서명이 있는지

`services/rpcBlockAttestationProtocol.js`와 self-test를 추가했다. 세 node signature quorum은 통과했고 payload 변조, 비회원 key와 단일 node 응답은 거부됐다. operator signature와 transaction submission은 사용하지 않았다.

아직 실제 PC가 attestation을 만들고 peer gateway로 outbound push하는 연결은 남아 있다. 따라서 이 문서는 부분 성공과 발견된 NAT failure-domain을 기록하며 전체 RPC 생존 완료를 선언하지 않는다.

