Why do we need to run our own Ethereum node?

Question

I have been reading a lot about Dapp development, and the gist of it seems to be that you need an ethereum node to connect to with web3.js in the frontend to read/write to the blockchain.

1) You have a choice for a public node or running your own, and the fundamental reasons seems to be a philosophical one which is if you trust your transactions going to the public node; if not then run your own.

2) I read here (What are best practices for serving a DApp over HTTPS, connecting to an Ethereum node using JSON RPC / web3.js, which by default uses HTTP?) that if you want to run your own Ethereum node, that you can't have it run over https, so you have to run it through a proxy. I am basically just fronting the node with an API, what are some other reasons for this?

3) I also understood that your Ethereum node has its own private and public key. You wouldn't have to worry about this if you leave the node locked, but when would I want to unlock and sign a transaction to write to the blockchain? If I do this, I am assuming that I would want to run a separate Ethereum node from the one mentioned in 2) and ensure that only my servers have access to it, is that correct?

4) How is the flow supposed to work here? The user signs a transaction with their private key on the client side, then uses my node from 2) to relay that transaction? Why can't I just do this with a public Ethereum node?

Please correct me if my assumptions are incorrect.

Answer 1

1. The major reason that you would want to run a local node is that it guarantees you a consistent view of the current network state. When you fetch data from a public, untrusted node then that node can lie to you about the current state of the network; i.e. whether your transactions have been confirmed, whether you have recieved a transaction, your current balance, etc.

2. If you are connecting to a node locally, then HTTPS is unnecessary. If you are connecting over a network, not using HTTPS leads to the standard issues with unauthenticated web traffic (MITM, forgery, etc.)

3. It is not necessary for a node to have keys, although they can. Transactions can be signed offline withought a node, but nodes offer the ability to sign using local keys for convenience. You should never store keys on a publically acessible node.

4. Yes, most DApps follow this flow. You can use a public node for this, see part 1.