Adventures in Dystopia

Hi, be careful with remote RPCs.

The use of RPCs is indeed critical for web3 and blockchain developers for state observation and interaction with the blockchain.
Hosting your own node can be costly and time-consuming, so the use of third-party RPC providers becomes a practical solution.
It's essential, though, to ensure data integrity and security when relying on these external services.

For example, GetBlock.io periodically produces testnet blocks instead of mainnet.

1) At first, they respond with a 404 Error to requests

POST /API-KEY/mainnet HTTP/1.1
…
{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":111973596}

HTTP/1.1 404 Not Found
…

2) Later (next request), they send a response with a testnet block instead of mainnet block

POST /API-KEY/mainnet HTTP/1.1
…
{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":111973597}

HTTP/1.1 200 OK
…
{"jsonrpc":"2.0","id":111973597,"result":{…"hash":"0x58a057779ff907d3987c595e801c11bd1067c0fe7485492396176b75eaf7a291",…,"number":"0x2121c19",…}

Where 0x2121c19 and 0x58a057779ff907d3987c595e801c11bd1067c0fe7485492396176b75eaf7a291 is testnet block

It's critical to implement additional validations and checks when observing blocks to ensure the integrity of the data and the correct functioning of your software. You should validate chainId in getBlockByNumber response.

(dump)

👍3🔥2😭1

www.tgoop.com/monolog/384

445 viewsedited  Nov 3, 2023 at 16:17

Hi, be careful with remote RPCs.

The use of RPCs is indeed critical for web3 and blockchain developers for state observation and interaction with the blockchain.
Hosting your own node can be costly and time-consuming, so the use of third-party RPC providers becomes a practical solution.
It's essential, though, to ensure data integrity and security when relying on these external services.

For example, GetBlock.io periodically produces testnet blocks instead of mainnet.

1) At first, they respond with a 404 Error to requests

POST /API-KEY/mainnet HTTP/1.1
…
{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":111973596}

HTTP/1.1 404 Not Found
…

2) Later (next request), they send a response with a testnet block instead of mainnet block

POST /API-KEY/mainnet HTTP/1.1
…
{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":111973597}

HTTP/1.1 200 OK
…
{"jsonrpc":"2.0","id":111973597,"result":{…"hash":"0x58a057779ff907d3987c595e801c11bd1067c0fe7485492396176b75eaf7a291",…,"number":"0x2121c19",…}

Where 0x2121c19 and 0x58a057779ff907d3987c595e801c11bd1067c0fe7485492396176b75eaf7a291 is testnet block

It's critical to implement additional validations and checks when observing blocks to ensure the integrity of the data and the correct functioning of your software. You should validate chainId in getBlockByNumber response.

(dump)

BY Adventures in Dystopia