- Thay vì query nhiều RPC rồi lấy đa số, Ethereum cho phép mỗi node đính kèm một Merkle proof cryptographic.
- Dù RPC bị hack, bạn vẫn an toàn — vì proof giả mạo là bất khả thi.
TL;DR
Anh @0xngmi (DefiLlama) vừa nhắc lại một fact mà đa số dev Web3 quên mất: Ethereum đã có sẵn cơ chế chống RPC giả mạo từ 2018. Mỗi block header chứa stateRoot — gốc của một Merkle-Patricia Trie phủ toàn bộ state. Một RPC có thể trả kèm Merkle proof cho response của nó, client verify cục bộ với stateRoot đã ký bởi validator. Dù RPC bị hack, nó không thể lừa bạn — chỉ có thể từ chối trả lời. Đây là phương án mạnh hơn hẳn pattern "query nhiều RPC rồi high-quorum".
What's new
Trong post gây bàn luận trên X, @0xngmi viết:
Ethereum has a very simple solution to faulty rpcs, rpc nodes maintain state tries to the block header. RPCs can use that to craft a cryptographic proof that its response is correct. That way even if rpc provider is hacked you're safe, a much better solution than high quorum.
Điểm này không mới về mặt kỹ thuật — EIP-1186 chuẩn hoá eth_getProof từ tháng 6/2018, Geth và Parity ship từ đầu 2019. Nhưng bối cảnh 2026 làm nó nóng trở lại: Vitalik đang đẩy roadmap "don't trust, verify", ví Kohaku do Ethereum Foundation hậu thuẫn sẽ tích hợp Helios — light client của a16z chuyên biến RPC untrusted thành trustless bằng proof.
Why it matters
99% ví và dApp hiện tại tin mù vào Infura / Alchemy / QuickNode. Nếu endpoint đó bị hack, DNS hijack, hoặc insider rogue, nó có thể trả về balanceOf() sai, giá oracle sai, hoặc quote swap bẩn. Pattern "defensive" phổ biến là query 3–5 RPC và lấy majority — nhưng nhiều provider cùng chạy trên Cloudflare/AWS, và majority vẫn thua nếu có collusion. Merkle proof phá bỏ vấn đề đó về nguyên tắc: không cần tin ai ngoài math và block header đã được consensus đồng ý.
Technical facts
State Ethereum lưu dưới dạng Modified Merkle-Patricia Trie. Mỗi block header có 3 root hash: stateRoot, transactionsRoot, receiptsRoot.
eth_getProof(address, storageKeys[], blockTag) trả về:
balance,nonce,codeHash,storageHashcủa accountaccountProof: mảng RLP-serialized trie nodes từstateRootxuống leaf của accountstorageProof: mảng trie nodes từstorageHashxuống leaf của từng slot yêu cầu
Quy trình verify:
- Lấy
stateRoottừ block header (đã được validator ký, tin được). - Hash leaf node, đi ngược lên theo proof.
- So sánh root kết quả với
stateRoot. Trùng → data đúng. Sai → RPC nói dối.
Chi phí: payload ~KB, verify vài ms trên CPU phổ thông. Keccak256 bị break là tiền đề duy nhất cho proof giả — và nếu keccak256 vỡ thì cả Ethereum đã sập trước đó.
Comparison
| Approach | Trust model | Fails when | Overhead |
|---|---|---|---|
| Single RPC | Tin provider | Provider bị hack / rogue | Không |
| High quorum (N RPC) | Tin đa số | Majority collude, hoặc chung infra (Cloudflare/AWS) | N× latency + cost |
Merkle proof (eth_getProof) | Chỉ tin block header | Keccak256 vỡ | ~KB payload + vài ms |
| Full node | Tin math + phần cứng mình | Disk chết | 1–2 TB state, sync nhiều ngày |
Proof cho security ngang full node với chi phí ngang light client. Quorum là heuristic; proof là guarantee.
Use cases
- Ví & dApp: MetaMask + Helios chạy cục bộ ở
localhost:8545— app vẫn gọi Infura, nhưng mọi response đều verify. Chainstack đã có guide đầy đủ. - Mobile / IoT: thiết bị không gánh được full node, nhưng verify proof thì được — EIP-1186 motivate đúng kịch bản này.
- Bridges & L2: chứng minh state Ethereum sang chain khác mà không cần multisig committee.
- DeFi frontend: verify minimum output của swap trước khi sign, chặn RPC sandwich.
- Indexer & audit: kiểm tra historical state mà không phụ thuộc archive provider.
Limitations & pricing
- RPC vẫn có thể censor: trả "not found" hoặc timeout. Proof chặn việc nói dối, không chặn việc im lặng. Fallback sang RPC khác là bắt buộc.
- Không phải method nào cũng có proof path sẵn.
eth_callphụ thuộc execution EVM — Helios instrument lại execution để verify từng slot được touch, overhead cao hơn. eth_getProofcho block cũ cần archive node. Free tier của public RPC thường disable hoặc rate-limit mạnh method này.- EIP-1186 formally marked Stagnant, nhưng implementation đã universal (Geth, Erigon, Nethermind, Besu).
- Payload ~KB/call — fine cho ví, nặng cho indexer QPS cao.
What's next
Bước tiếp theo là ZK execution proofs: thay vì chỉ prove state reads, prove luôn cả state transitions bằng SNARK. Khi đó eth_call cũng trustlessly verify được trong thời gian gần như hằng số, bất kể block phức tạp đến đâu. Đây là hướng Vitalik đặt cho 2026+ — và là lý do CryptoSlate gọi 2026 là năm Ethereum "kill trust-me wallets".
Takeaway cho dev Web3: nếu bạn đang ship ví, bridge, hoặc DeFi frontend và vẫn chạy pattern "query 5 RPC lấy majority" — đổi sang Helios-style proof verify đi. Code đã có, chuẩn đã xong 8 năm, chỉ còn việc dùng.
Nguồn: @0xngmi tweet, EIP-1186, a16z — Building Helios, Chainstack deep dive.
