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.
