0

I have a fundamental question about eth/blockchain infrastructure. I see several posts talking about the need for backend node infrastructure when launching a dapp/ smart contract. This infrastructure could be infura, trongrid, ethscan, etc. or running your own node.

What I don't understand is:

(1) Why do you need this infrastructure? I thought when I launch a smart contract I just use some web3 api to place it on the eth blockchain and we're good to go. Is there some performance reason?

(2) People cite issues when running your own full node such as higher latency, usability, and manageability versus hosted services like infura. What makes these hosted services faster/easier to use than running your own node or just using eth's API to interact with the blockchain.

Thank You

0

First let's get the fundamentals sorted.

You connect to a blockchain through a node which implements the blockchain. So a node is a client program which runs code that makes up the blockchain - the blockchain consists of nodes. There is no way to connect to the blockchain without a node (be it yours or somebody else's).

So a dapp uses some web3 library (for convenience) to connect to some node which in turns is a part of the blockchain and can therefore interact with it.

One of the main aspects of blockchains is decentralization. So nobody controls it and everyone can run a node and connect to it.

Now for actual answers:

1) Using a centralized entity (for example Infura or whatever "web3 API" as you say) is, well, centralized. You are dependent on the service/API provider. If they go down you lose your access and you either have to switch provider or start running your own node. Or they may get compromised and whatever. Furthermore, we need this infrastructure because there is no other way to connect with the blockchain.

2) Running your own node can be rather cumbersome. There are certain hardware requirements and you need to keep the node client code up to date (for example upon a hard fork you have to have the latest client version to be able to mine the new chain). But if you run your own node you are not dependent on anyone else - and you can't blame anyone else but yourself for any downtime. I don't think there are big performance variations between any of the solutions and it wouldn't make much difference anyway as most of the time is spent waiting for mining. So using ready providers is much easier and faster to set up but you may lose a part of your soul in the process.

|improve this answer|||||
0

You can build a DApp to inspect the environment and:

  1. use a local node if one is present
  2. fall back to use one or more node-as-a-service pools.

The latter offers the convenience of an install-and-go user experience. Many new users will be unfamiliar with the deeper design issues of decentralization such as removing a single point of failure or the possibility of censorship. And, many devices such as mobiles cannot reasonably be expected to maintain full nodes, at this time.

Support for a local node means the possibility of improving the decentralization exists. In other words, users are not wholly dependent on the node pool and they can run their own ethereum nodes, if they want to.

The possibility of comparing node pools to actual nodes and exiting the pools in favor of full nodes is a strong incentive on node pools to be honest. In my opinion, DApps should always support full nodes even if most users will opt for the convenient approach.

Hope it helps.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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