Why you shouldn’t be using Infura for your DApp
By Michael Buchanan, Blockchain Developer
The past two years have seen an explosion in interest in blockchain technology and decentralized application (DApp) development, which brought with it a suite of new development tools and services created by the community to make developers’ lives easier.
One of the most popular of these services is Infura, a service that provides plug and play blockchain communication for DApp developers.
Infura is a centralized service operated by ConsenSys that allows DApps to process queries and request information from the Ethereum blockchain without requiring the developer to run a full node themselves.
Infura provides enormous value to the development community by removing the cost and time investment that is necessary to sync and run an Ethereum node that would otherwise put DApp development out of reach for many.
An estimated 63% of the Ethereum community use Infura as their preferred method of interacting with the blockchain.
Infura provides a communication service between DApps and decentralized infrastructure
“Although Infura is an invaluable tool to bootstrap DApp development, the tool is increasingly being used for something it should not be used for: blockchain communication in critical production environments.”
Why is this a problem?
Consider some of the biggest advertised benefits of decentralized applications. DApps should be:
- Unstoppable
- Censorship resistant
- Trustless
- Without a single point of failure
If a DApp relies solely on Infura for processing blockchain queries, then all the benefits of decentralized applications quickly disappear and what is left resembles a costly and inefficient traditional application.
If a DApp relies on Infura to communicate with the blockchain then:
- It is no longer unstoppable as Infura could decide to stop servicing the DApp (or start charging for the service breaking the DApp business model) or Infura’s cloud provider could decide to stop hosting their nodes.
- It is no longer uncensorable as Infura could easily be pressured to censor some Infura users or even the whole service for some reason (e.g. economic pressure from state-level actors).
- It is no longer trustless as the DApp will implicitly trust that data provided by Infura is accurate and the developer will not be able to verify the accuracy of the data.
- It creates a single point of failure as Infura’s service could introduce bugs or become unavailable for whatever reason, crippling the ability for DApps relying on Infura to function at all.
The reasons listed above make it clear that relying on a centralized service layer such as Infura to plug into the Ethereum blockchain is antithetical to the trustless and redundant nature of decentralized applications.
Popular cryptocurrency wallet and Web3 provider MetaMask highlights the dangers of relying on a service with a centralized single point of failure.
MetaMask makes use of Infura for communicating with the Ethereum blockchain to determine a user’s account balances and to submit transactions.
“If Infura’s service was somehow compromised by an attacker, the attacker could send false information to an honest user’s cryptocurrency wallet that could cause them to think they have received a payment when in reality they have received nothing. It’s easy to see how this could lead to real-life consequences including the loss of funds.”
Infura is owned and operated by blockchain behemoth ConsenSys, which has close ties to the Ethereum Foundation, but even that hasn’t stopped influential figures in the Ethereum Foundation from ringing the alarm bells about the over-reliance on Infura.
Marcus Ligi of the Ethereum Foundation has affirmed that “not only [is Infura] a potential security hole — [it’s] also a single point of failure”.
Afri Schodeon, an Ethereum Core developer at the time, has also stated that “If we don’t stop relying on Infura, the vision of ethereum failed.”
So, what other options do DApp developers have?
Running a full node
The obvious answer is to run a full node yourself. Running a full node gives the user the ability to verify the validity of the entire blockchain and all related data themselves.
Geth and Parity are the most popular full node implementations of the Ethereum protocol that can be used for all blockchain communication. Running a full node requires significant disk space (~150 GB) and memory to run smoothly, something which could be prohibitively expensive for many users, especially those in developing countries.
Geth and Parity both have options that can significantly reduce system requirements, such as pruning old blocks and enabling fast or warp sync mode.
Running a light client
A slightly less obvious alternative is to run a light client. A light client is an Ethereum client specifically designed to run in low power and low disk space environments, such as on older computers or embedded devices.
A light client does not sync the full blockchain, only the block headers relevant to the data the user requests. This enables the client to consume very minimal disk space (about 100 MB) while still being able to verify the validity of the data received.
Decentralized Infura replacements
Another potential replacement for Infura comes in the form of decentralized node provider services. One example of this type of service is Incubed by Slock.it. Incubed is an in-development service that is designed to function as a decentralized replacement for Infura that eliminates the single point of failure, trust requirements, and security concerns.
Incubed works by forwarding your blockchain data request to a network of randomly selected nodes (eliminating the single point of failure), which must all stake a security deposit to ensure honest behaviour (reducing the incentive for dishonest behaviour) that is enforced by watcher nodes. The combination of these features gives the user a high degree of confidence in the reliability of the service and the trustworthiness of the data they receive from the node.
Infura is still an invaluable tool
As it stands today, Infura is an invaluable tool and a very convenient way to interact with the blockchain in development and testing environments, but it should never be used in production environments where actual money and real life consequences are at stake.
For a DApp to be properly decentralized, it requires a reliable and trustworthy line of communication with the blockchain, such as that provided by self-hosted full nodes, light clients, or future node providers like Incubed.
The information in this article is general in nature. Any advice it contains is general advice only and has been prepared without taking into account the objectives, financial situation or needs of any particular person. The article content is not intended to be a substitute for professional advice and readers are urged to seek their own appropriate advice before making decisions. Any reference to a particular investment is not a recommendation to buy, sell or hold the investment.
Originally published at https://www.digitalx.com.