Embarrassingly, I wasn’t aware of the Infura Addiction that plagues blockchain ecosystems until recently. My tech background is in hard core embedded systems and centralized server applications, primarily in the Internet of Things space. I just assumed that blockchains, such as Ethereum, could support an ecosystem of application developers (e.g. wallets, blockchain browsers, credential management, inventory apps, etc…) that were developed and interacted with “the decentralized” blockchain. This assumption was incorrect. Every application built to interact with decentralized public blockchains does so through a centralized server (blockchain node) — often an Infura server — the “Infura Addiction.”
When we started building the Diode technologies (diode.io) around blockchain concepts, we were solving (and did solve) the problem of time and didn’t pay too much attention to this dichotomy. However, as we pushed into the technology in order to establish a proof of concept for our solution to time, we found that there were no practical methods for connecting embedded devices and terminal-level clients to decentralized blockchain networks. The reasons for why everyone was using Infura (or spinning up their own full node) were two fold:
- Lack of Incentive: It is expensive to run a node. No-one wants to run a full-node and leave the RPC ports open. Some of the calls are expensive to service, and there is a risk of attack. So, the status quo is to run a node that is locked down and only available to the app/apps you want to run — a centralized server.
- Trust Required: Clients/apps must trust a public blockchain node — the blockchain node could be spoofing the state of the blockchain in order to capture tokens from transactions from the application. However, if you host your own full node, you can trust it.
These reasons made sense, but we weren’t satisfied. Our devices had to speak freely! We had to find a way to unleash the power of the ecosystem of traditional web and device developers into the decentralized economy!
But, the “right” solution was non-trivial — we had to solve the incentive problem to ensure nodes would _want_ to keep their RPC ports open, and we had to solve the trust problem so that clients could connect to a public node in a trustless way. Fortunately, the fundamental IP we had created from solving the problem of time directly lent itself to solving the trust problem. And, our background with the way that IoT business incentives work created a clear roadmap for solving the incentive problem.
There were, and are, many other implementation and technical challenges (which will be solved as a matter of due course), but the team at Diode.io crossed a big bridge today (April 27, 2020) by releasing pre-built downloads for Linux (including one for RaspberryPi), MacOS, and Windows (source at https://github.com/diodechain/diode_go_client).
For the first time, applications on desktops, embedded devices, browsers, etc., can be created that interact DIRECTLY with the blockchain in a truly decentralized way: the Nodes are incentivized, and the application/network interaction is trustless. Through publishing the pre-built binaries, a key barrier to Web3 application onboarding is removed. Now, by running the client on the system hosting the application, every web application in the world can become part of the decentralized Web3 revolution!
For details on how to get started, see my write-up on using the Diode Chain client to enable a web-browser to directly view Web3 content (no centralized middle-man!).
Stay tuned for an additional write-up on using the Diode Chain client to publish a website directly to Web3 (no DNS or static IP required!).
Finally, checkout https://diode.io/testnet/#/dns to browse a list of human-readable content available on Web3 (HINT: any web-browser can view the Web3 content by using the “diode.link” suffix — the <web3address>.diode.link URL invokes a Web2 gateway that proxies the Web3 content for all of who don’t want to download and run the Diode Chain client!).