How to Build Real-Time DApps?

Just as user-friendly software was necessary before computers became adopted for mainstream use, dApps (more specifically, real-time dApps) are the software that run on the blockchain and will help launch it into mainstream use. Remember, there were computers being used before Windows and a a graphical user interface were around, but it was far more difficult and the number of folks using those computers were far lower. The blockchain and distributed ledger technologies (DLT) are currently in their infancy and they don’t have super user-friendly software yet to help the general public interact with them. But taking into account that a reported 84% of companies are looking into the blockchain, if you’re a programmer then real-time dApps are probably where your career is heading. Consider this article as the crash course about your potential future.

https://www.cnbc.com/2017/12/21/long-island-iced-tea-micro-cap-adds-blockchain-to-name-and-stock-soars.html

Real-time dApp technical requirements

For those of you who already know about dApps, this will be a bit of a refresher. To Those of you, on the other hand, who are reading this article with little to no knowledge about the topic, this section is for you. But before we go any further, we need to discuss the basics of dApps in order to understand how (and why) real-time dApps are different. According to David Johnston and associates, the qualifications of a dApp are as follows:

• The application’s data and records of operation must be cryptographically stored in a public, decentralized blockchain in order to avoid any central point of failure.
• The application must be completely open source, it must operate autonomously, and with no entity controlling the majority of its tokens.
• The application must use a cryptographic token (Bitcoin or a token native to its system), which is necessary for access to the application and any contribution of value from (miners / farmers) should be rewarded in the application’s tokens.
• The application must generate tokens according to a standard cryptographic algorithm acting as a proof of the value nodes that are contributing to the application.

https://www.stateofthedapps.com/stats

As we explained earlier, a dApp runs on top of a blockchain or other DLT in order to make a more accessible and higher functioning application. But that is only half of the equation, as most modern dApps are far from running in real time.

In order for something to run in real time it has to, as the name suggests, send, receive, and verify information in as little as time as possible, preferably less than one second. When discussing “real-time” applications, there is typically a keyword that is brought up: server push. These server pushes are used often in the real world; tracking your Lyft/Uber’s location on your phone, sending a message to your friend on iMessage, playing a multiplayer game online. A server push is, basically, anytime data is transacted through a central server.

Real-time dApps combine dApps with server push technology into one decentralized process. Instead of relying on a central server through which everything is bounced, real-time dApps instead rely on a blockchain or other DLT to handle smart contracts that process all of the data in real time. When you look at the capabilities of the current major blockchains’ average transaction speeds (Bitcoin — 78 minutes, Ethereum — 6 minutes, Ripple — 4 seconds, Bitcoin Cash — 60 minutes, EOS — 1.5 seconds) it is obvious how far these are from “real-time” capabilities. To put these numbers into perspective, here are some common uses of real-time technology and their server loads (without taking actual data size into consideration):

• WhatsApp — 637,000 Tx/s
• Telegram — 174,000 Tx/s
• Fortnite (assuming average 50ms ping per player) — 166,000,000 Tx/s

https://blog.whatsapp.com/10000631/Connecting-One-Billion-Users-Every-Day

Needless to say, the current mainstream decentralized technology cannot handle the load that real-time technology demands, which is why the industry is being forced to create new technology and alternative chains.

DApp Structure and the Need for New Chains

Most dApps are built using a specific formula formula, which we’ll break down for you here using Brendan Lee’s “What we learned building our first Ethereum Dapp” medium article as an example, where he explains the technology stack they used. You may or may not know what those technologies are, so we’ll break them down for you here:

1. Solidity is the primary programming language for Ethereum, and smart contracts create the “server” for a dApp on the Ethereum chain.
2. IPFS, or InterPlanetary File System, is a decentralized storage option that allows users to spread their storage needs across a series of nodes.
3. Truffle and Ganache, as Lee points out, are testing frameworks. Imagine this to be the Microsoft Visual Studio C++ testing equivalent for Ethereum.
4. All of these are front-end development languages that vary depending on the programmer’s needs, much like JS, Ruby, C++, etc.
5. MetaMask is a wallet used for Ethereum, as a wallet is necessary to fund the nodes that are running the dApp (and the IPFS nodes that are storing data). It is also necessary to hold funds accepted by the users of the dApp.

The current structure mentioned above is for traditional dApps, and although real-time dApps are similar there is one key difference: the chain they interact with has to be far, far faster than Ethereum.

What blockchains meet the real-time dApp requirements?

There are currently a few alternatives on the market that are up to the task of running real-time dApps, each providing the service in their own unique way. Let’s take a look at each of them.

Loom Network

Loom relies on Ethereum as a base while building side chains off of it. This means that Ethereum is the backbone, and Loom creates side chains that check in with Ethereum to borrow its security protocols, while simultaneously allowing for immense scaling and greater Tx/s. Loom is a layer 2 blockchain on top of Ethereum, running what they call “DAppChains” that use alternative consensus rulesets (like delegated proof of stake).

Chain Speed: Less than 1 second approval times, Tx/s 1,000,000+

Summary: The Loom Network coexists with Ethereum, checking in with Ethereum when it needs to settle a dispute but otherwise remaining independent. This allows for sub second transaction approval times, extremely low gas prices, and the ability for real-time dApps to function on Loom side chains.

#MetaHash

#MetaHash provides a complete alternative to Ethereum in terms of dApp support. This is achieved by focusing on four components: #TraceChain (based on a self-learning algorithm that will grow as higher bandwidth nodes are added to the network), #MetaApps (their version of dApps and real-time dApps), #MetaGate (the inclusion of open source code to allow developers to create dApps and #TraceChain features), and #MetaHashCoin (the network’s digital payment currency used for consensus protocols).

Chain Speed: Approval in under 3 seconds, Tx/s 50,000–1,000,000+

Summary: #MetaHash is a solid alternative when considering the speed of their #TraceChain and their transaction approval times; however, the fact that they operate completely independently from Ethereum could pose a problem in the future.

Zilliqa

Zilliqa is a scalable, miner supporting, data-flow and sharding-friendly blockchain alternative for smart contracts and dApps. Zilliqa’s Tx/s is based on the frequency of sharding, essentially meaning that the amount of possible transactions increases with network and node size. Although Zilliqa is much faster than Ethereum, Bitcoin, and the likes, it would struggle to keep up with the high intensity of real-time dApps unless the sharded nodes were extremely reliant. It currently uses ERC20 protocols and runs on Ethereum, but they aim to have their own blockchain in the future.

Chain Speed: 2 minute approval time, ~10,000 at best Tx/s

Summary: Zilliqa will certainly have its uses (advertising), but in the the greater scheme of real-time dApps it will struggle to keep up with its slower block approval time.

Where do we go now?

If you’re a founder looking where to base your next dApp project, then the answer is a bit more ambiguous. It depends on your needs: do you need millions of transactions per second and do you mind dealing with Ethereum network? If so, look to work with Loom. But if you want to branch out and adopt a completely rewritten solution that doesn’t carry past problems with it, then #MetaHash is your ideal project.

At the end of the day, the most important thing is to look past the flashy marketing campaigns and into the technical details to ensure that the projects are built on solid code. As we said earlier, the technology is still young, so expect to see changes in the blockchain/DLT landscape as time goes on.

About the author:

Kirill Shilov — Founder of Geekforge.io and Howtotoken.com. Interviewing the top 10,000 worldwide experts who reveal the biggest issues on the way to technological singularity. Join my #10kqachallenge: GeekForge Formula.