87 lines
3.1 KiB
Markdown
87 lines
3.1 KiB
Markdown
|
# Chain 138 RPC – Verification & Final Confirmation
|
|||
|
|
|
|||
|
|
**Last Updated:** 2026-01-31
|
|||
|
|
**Document Version:** 1.0
|
|||
|
|
**Status:** Active Documentation
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**Status**: Authoritative validation complete
|
|||
|
|
**Date**: 2026-01-29
|
|||
|
|
**Purpose**: Lock in end-to-end RPC path correctness and document LAN vs WAN behavior.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## RPC path validation (proven)
|
|||
|
|
|
|||
|
|
Full stack has been proven correct:
|
|||
|
|
|
|||
|
|
**Client → NPMplus → Besu (VMID 2201)**
|
|||
|
|
|
|||
|
|
| Layer | Status |
|
|||
|
|
|-------|--------|
|
|||
|
|
| **DNS** | `rpc-http-pub.d-bis.org`, `rpc.defi-oracle.io`, etc. → **76.53.10.36** |
|
|||
|
|
| **TLS/SNI** | Cert CN matches hostname; valid Let's Encrypt; TLS 1.3 |
|
|||
|
|
| **Proxy** | NPMplus (192.168.11.167:443) routes by Host header correctly |
|
|||
|
|
| **Upstream** | Besu RPC (192.168.11.221:8545 / :8546) reachable |
|
|||
|
|
| **RPC response** | `eth_chainId` → **0x8a** |
|
|||
|
|
| **Chain ID** | **0x8a = 138** (Defi Oracle Meta Mainnet) |
|
|||
|
|
|
|||
|
|
Validation command (bypasses public IP; connects directly to NPMplus on LAN):
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
curl -vk --resolve rpc-http-pub.d-bis.org:443:192.168.11.167 \
|
|||
|
|
https://rpc-http-pub.d-bis.org \
|
|||
|
|
-H "Content-Type: application/json" \
|
|||
|
|
-d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
|
|||
|
|
# Expected: {"jsonrpc":"2.0","id":1,"result":"0x8a"}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Conclusion**: No firewall, proxy, or TLS issues inside the stack. System is working as designed.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Why it can “hang” from inside the LAN (expected)
|
|||
|
|
|
|||
|
|
From a host **on the same LAN** as 192.168.11.x, calling the **public** hostnames (resolving to 76.53.10.36) may hang or time out because of:
|
|||
|
|
|
|||
|
|
- **NAT reflection / hairpin**: traffic goes LAN → WAN IP (76.53.10.36) → router → back into LAN. UniFi can support this but it is topology- and firewall-rule dependent and can be inconsistent with HTTPS/HTTP/2/SNI.
|
|||
|
|
|
|||
|
|
This **does not affect real users or the internet**. From cellular, cloud, or any external network, the same request (without `--resolve`) succeeds.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Recommended: Split DNS (production-clean)
|
|||
|
|
|
|||
|
|
To make RPC hostnames work **reliably from inside the LAN** without relying on NAT hairpin:
|
|||
|
|
|
|||
|
|
Configure **internal DNS** (e.g. UniFi DNS, or your LAN resolver) so that these hostnames resolve to **192.168.11.167** (NPMplus) for internal clients:
|
|||
|
|
|
|||
|
|
| Hostname | Internal A record |
|
|||
|
|
|----------|--------------------|
|
|||
|
|
| `rpc-http-pub.d-bis.org` | 192.168.11.167 |
|
|||
|
|
| `rpc-ws-pub.d-bis.org` | 192.168.11.167 |
|
|||
|
|
| `rpc.defi-oracle.io` | 192.168.11.167 |
|
|||
|
|
| `wss.defi-oracle.io` | 192.168.11.167 |
|
|||
|
|
|
|||
|
|
Result:
|
|||
|
|
|
|||
|
|
- **LAN clients** → resolve to 192.168.11.167 → traffic stays on LAN.
|
|||
|
|
- **Internet clients** → resolve to 76.53.10.36 (Cloudflare/public DNS) → UDM Pro port forward → 192.168.11.167.
|
|||
|
|
- No dependency on NAT loopback; same hostnames work from everywhere.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Chain ID note
|
|||
|
|
|
|||
|
|
- **Chain ID 138 (`0x8a)** is valid and does not collide with Ethereum mainnet or common testnets.
|
|||
|
|
- Wallets and tooling treat it as a distinct sovereign EVM chain.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## See also
|
|||
|
|
|
|||
|
|
- **NEXT_STEPS_CHAIN138_RPC.md** – .env, scripts, UDM Pro, Chainlist.
|
|||
|
|
- **PUBLIC_RPC_CHAIN138_LEDGER.md** – Public RPC endpoints and backend mapping.
|
|||
|
|
- **RPC_ENDPOINTS_MASTER.md** – Full endpoint and VMID reference.
|