As far as I know, there are roughly two kinds of contract calls on Ethereum. One kind is intended to change the global state of blockchain (i.e. change some storage values or transfer money). The other one is just to get data from blockchain without any modification.

The transaction of the first kind will be broadcast on the Ethereum network, but the second one only goes to the node that you have RPC connection with.

My question is: although the first kind of contract call can be secured thanks to blockchain consensus algorithm, how about the second kind? What if the node you are connected is cheating and gives dApps wrong data? Is there any ways to prevent such cases of cheating nodes from happening?

  • This question generally holds in every system which bares a communication channel (for example, when you speak to someone on the phone). How would you know that the other side isn't cheating you? The general answer is that you gotta trust that other side. Commented Jan 5, 2020 at 9:51

2 Answers 2


This is not exactly about trusting a random node. This is about trusting the node you use to communicate with the blockchain - you most likely issue both types of transactions to the same node. If you don't trust that node then you can't trust anything really - you can't even know whether the node is even really connected to the blockchain or whether it just gives you random results.

This is why typically bigger projects run their own nodes. There are node providers out there (such as Infura) but due to the nature of trustless communication in the blockchain it makes no sense to add extra trust requirements (external service provider) to the project. Basically the only reason why people tend to use such service providers is that they are easy to use and you don't need to maintain your own node.

My advice is to use external node providers only for testing and other similar stuff but especially if you have a serious project you should consider running your own node.


Just to amplify Lauri's answer, the question could be rephrased,

What if I don't trust my own equipment?

That is possibly a concern, but it isn't limited to the Ethereum node. It goes all the way to the metal. Exactly what you want to do about that will depend on the value you attach to the asset you want to protect. No one is stopping you from, for example, setting up your own off-chain cluster of nodes inspecting the blockchain with different stacks and confirming unanimous agreement about any inquiry. They should always agree 100% - otherwise, something is malfunctioning. Sound the alarm!

Yeah, but we/our users/someone uses Infura.

That is outsourcing the "your node" role to a service, not unlike outsourcing the "your hardware" role to a cloud provider. The trust model of ethereum isn't changed - it is still understood that you trust your own equipment but you have delegated responsibility. You and your users are burdened with asking yourself if you trust Infura enough or if you would trust your own node more.

Information leaks

A non-obvious concern with a node service is the unveiling of read-only operations. Many contracts are written with the understanding that a view or pure call is between the user and their node and not broadcast to the network. By extension, it may be assumed that confidential inputs are not knowable by anyone other than the user, but that assumption breaks down when an outsourced node service can observe the inputs.

For example, consider a contract that exposes a hash function, perhaps to ensure that any client in any language will always be able to mimic the exact hash algo the contract uses:

function hashHelper(uint nonce, bytes32 salt) public pure returns(bytes32) {
  return keccak256(abi.encodePacked(address(this), msg.sender, none, salt));

That contrived example takes some inputs and returns a hash. It should be impractical to guess the nonce if that hash appears on the blockchain. However, if a node-as-a-service assisted with the hash generation, then they saw the inputs and they also saw the hash. If they are dishonest, they can watch for known hashes to appear on the chain and they can possibly gain something by knowing the magic number before anyone else (other than the sender who called the read-only function).

It is arguably a good practice to include such a function to ensure future clients always have a way to compute such things, but it is also a good idea to favor computing such a thing client-side even if the contract offers a convenient short-cut.

Local node or light client? Why not both?

In practice, you'll usually want to present a web UI and offer users the choice, so light clients/mobile can use Infura (or similar) and others can run their own node. There is EIP-1102 to think about. It improves the user experience considerably and legacy methods of connecting are slated for sunsetting.

All these considerations make initializing a client somewhat of a web of concerns. Have a look at this tutorial that shows how to implement EIP-1102 if the browser supports it, fallback to injected Web3 if possible and further fallback to the user's own node if they are running one.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.