What Blockchain Should I Build My Dapp On?

2019-03-06 03:57:27 · 15386 views · 5 min read

Decentralized applications, which some people refer to as Web 3.0, are the future of secure design. Rather than storing user information, passwords, money, and other data in centralized storehouses and wrapping layers of firewalls around them, Web 3.0 keeps these things either with the user or in a distributed system that cannot be compromised without going to unreasonably expensive lengths.


Capable platforms for smart contracts and distributed applications (dapps) are at last coming to market, launching mainnets and tools and libraries for developers and enterprise looking to protect user data and funds in this way.


There are so many platforms, in fact, that we can’t consider them all. A number of platforms – NEM, Hashgraph, Komodo, Cardano, and many more – didn’t make the cut for this article for a number of reasons. My focus is on platforms which are already running dapps. The platforms you can use now to deploy a full-featured application quickly, to a relatively broad community, with relatively available developer tools.


Disclosure: I’m an EOS developer and IOST node partner, with an interest in the Everything EOS and Inside IOST podcasts. I also own some of every crypto asset here and run a Bitcoin Lightning node. I have only developed on some of the platforms named here. This space is still inherently risky; do you own due diligence before launching any application on a platform.

Here are seven factors to consider when picking a platform for your distributed application.


Versatility: I need to work with more than just money.

Do you need Turing-complete contracts, with capabilities for decentralized operations on data?


Before you say “yes,” though, you should carefully consider why your application needs decentralization. No matter what your final decision is, it is likely that only a small piece of your application will live on the blockchain. Your only core need may be avoiding financial censorship for your users.


If you’re just looking to incorporate censor-free money under simple contracts, Bitcoin is a good choice, or even BTC’s Lightning, if you need speed and are OK with its limitations. Despite rumors to the contrary, Bitcoin can do smart contracts, as demonstrated by Particl.io’s use of it for “Mutually Assured Destruction” escrow. Bitcoin cannot do loops, by design.


If you need a little more flexibility for your application, but not quite Turing-complete capabilities, Stellar is a platform you might consider. Stellar is often a choice for various financial applications.


Bitcoin is unparalleled in terms of secure, censorship-resistant money.


However, if you decide you do need decentralized data manipulation and storage, the other four platforms are the ones to investigate. All promise Turing-complete solutions, which basically means they can perform any general computing task in a decentralized fashion.


Verdict: if you need to perform decentralized operations on data, look at Ethereum, EOS, Tron, or IOST.


Speed: I need to handle lots of transactions or have them confirm quickly.

The loser in the speed category is still Ethereum, despite massive effort to bring scaling to the ecosystem. Unlike each of the other blockchains, Ethereum is still Proof of Work and has made no moves to limiting the number of validating nodes and thus improving the speed of the network.


EOS limits producing nodes to 21, Tron limits them to 27, and IOST, while it doesn’t specify a limit, includes only producing nodes which meet certain hardware requirements and have at least 2.1 million IOST staked and voted for them. Stellar also limits validating nodes.


While these restrictions raise the barrier to entry for running a producing node on these blockchains, they also secure a much higher transaction per second (TPS) count, so these blockchains offer much superior speed.


Bitcoin’s Lightning Network and its lapps (Lightning apps) are fast, too, if it fits your application’s requirements – but onboarding users to Lightning is not yet a smooth process.


Verdict: if you need speed, consider EOS, Stellar, Tron, or IOST. Bitcoin’s Lightning is also an option, but it has some tradeoffs.


Platform Confidence: I want to make sure the platform I build on stays around.

It’s difficult to build on a platform you’re not sure is going to exist in 2 years, let alone 5, 10, or 50.


Bitcoin is the king of confidence in the crypto space. Very few projects even aspire to de-throne Bitcoin, and the volume of public and financial interest in Bitcoin is miles beyond the interest in other crypto assets. However, it’s unsuitable for some applications.


Ethereum has a large community, but like all of the cutting-edge smart contract platforms, it could potentially suffer a major bug that dramatically reduces its power or usability. Cryptocurrency is still early. Nevertheless, confidence in Ethereum is growing.


EOS, Tron, and IOST all have varying degrees of governance mechanisms in place to recover should a network failure occur, but they don’t yet have the massive developer and financial backing that Ethereum has.


Verdict: For confidence that the platform will last for decades, choose Bitcoin if you can. If you need better speed or versatility, the other platforms are relatively close in confidence, with Ethereum possibly in the lead and IOST lagging behind since it is a newer contender.


Community Bootstrap: I want to build something that will have a user base right away.

People use lapps because they’re into Bitcoin. People use Peepeth and MakerDAO because they’re into Ethereum. And people use pixEOS and EOS Knights because they’re into EOS. All of these platform communities have fans ready to jump onto new dapps simply because they’re a part of their favorite ecosystem.


Just like some apps were bought on the early App Store merely because they existed, build a decent application on one of these young platforms and you’ll have an instant fan base. Try hard not to disappoint them, or they might just turn on you:)


Verdict: All of the communities, except perhaps Stellar, already have active communities using widely available tools that will eagerly try good dapps simply because they’re available on their favorite platform.


Ease of Development: I want my developers to experience the minimum learning curve.

Smart contract development is a new space, and Ethereum built a new programming language for it, Solidity. Adding Solidity to your toolkit is not too hard a task for a developer if they’ve worked with a similar language in the past – say JavaScript, Java, C++, or C# – but it’s still a new language, and thus doesn’t have a very large set of tools available for it.


Other platforms have decided to start with different languages for their smart contracts. EOS’s VM runs on WASM, and EOS has a compiler from C++ that can be used to create WASM contracts. IOST uses JavaScript. Tron uses Solidity currently and boasts compatibility with Ethereum VM, so it might be a good choice for projects moving from Ethereum with limited resources to make a significant change, or those looking for cross-compatibility.


Verdict: Develop on EOS or IOST to use C++ or JavaScript, respectively. Stellar is an option if your decentralized application is limited to financial use cases. Bitcoin and Ethereum have higher learning curves. All platforms have teams working to add more languages such as JavaScript, Rust, and Go, but their timelines are not set in stone.


Safety: I want to minimize risk to my users’ funds.

There is still no safe smart contract platform, only safer applications.


Safe coding practices don’t just involve hunting down and eliminating bugs. They also involve minimizing the damage that can be done in worst-case scenarios.


On Ethereum, code is law. The DAO hack in 2016 was an exception, but that’s generally recognized as an event that will not be repeated. If your code freezes funds, they might remain frozen.


On EOS, the idea is that “intent of code” is law. Block producers are able to remedy an issue resulting from a bug when the intent of the code was to produce an expressly different outcome from what actually happens. For this reason, EOS smart contracts are published with Ricardian contracts declaring their intent. However, there is absolutely no guarantee that the current block producers will mitigate your issue, especially if it is relatively minor. The same applies to Tron.


Note that IOST is a newer platform still subject to design changes, so extra caution may be required. We haven’t yet seen how the platform’s governance will function in response to bugs. Every platform experiences growing pains upon launch, and things should become clearer over the coming months.


Verdict: To minimize risk to user’s data funds, use safe coding practices that minimize potential damage, engage a reputable review team, and use formal verification if possible. The communities of Bitcoin and Ethereum will not reverse bad transactions with effects that are narrower than network-wide. EOS is designed to reverse destructive events in the spirit of “Intent of Code Is Law.” Do not select a newer platform if safety is your priority.


Developer Support: I want help during the development process.

Ethereum has been building for years and is the clear winner when it comes to tools for developing and debugging smart contracts. However, standard libraries are not as readily available as they are on other platforms due to Ethereum’s philosophical decision to not build in generalized features.


So whereas decentralized storage is (or will be) integrated on other smart contract platforms, on Ethereum you’ll have to write your own code for this, or reuse someone else’s.


Getting direct support from an experienced Ethereum developer on an issue is still difficult, as many are overbooked. You may need to engage a paid professional.


EOS, Tron, and IOST have fewer tools and less documentation, but you’re more likely to get personal help, especially on IOST, which has a focus on coming “alongside dapp developers” to build with them.


If you’re developing on Lightning, you might expect less support this early in the game. I don’t yet have any experience developing for Stellar, but it seems simple enough via APIs – again, for the use cases Stellar is intended for.


Verdict: Ethereum is currently the winner for support tools, and IOST is the winner for direct personal support. Other platforms fall somewhere in between on both spectrums. If you’re looking for paid support, the Ethereum community has the most smart contract programmers at this time.


(P.S.) Privacy: I want smart contract actions to be private.

You can’t really do this on a public blockchain yet.


There are solutions in the works. Bitcoin’s Taproot is going to make contract actions look indistinguishable from regular transactions. Enigma is working on a privacy layer for smart contracts that hides input data from the nodes executing smart contract code (which is amazing).


But for now, if you need privacy for a data point, encrypt it or keep it off the blockchain. Or, consider permissioned or private blockchain solutions.


Good luck building!

Comments Write Comment
Currently there are no comments for this article. Would you like to be the first to write one?
Related Products
Main Network
An unstoppable and decentralized Twitter
EOS Knights
Main Network
The first mobile blockchain game.
Work in Progress
pixEOS.io the first Art Gamification on the EOSn.
Recommanded Articles
Welcome to the IOST Dapp Rankings v1.3!
Jun 24 · 5453 Views
School's Out, Ready For Some New Games?
Jun 26 · 7185 Views
Dice, Dice, Trust Dice!
Jun 30 · 5259 Views
Obstacles to Mass Adoption
Jul 1 · 6880 Views