Toward a Decentralized Future
Once upon a time, the inviting convenience of a public phone booth and a thick, yellow directory were used to call a taxi. A bit later, many began to realize that “there’s an app for that”. Then, with the decline of landline phone use, we saw service delivery shift almost entirely to mobile devices that are always within reach.
As mobile apps proliferated into the common sphere of awareness, the “new normal” of this interconnectedness revealed a dark secret. These convenient, easy-to-install and free applications came at a high personal cost to our privacy. We became the products, as our patterns of behavior and data were transformed into commodities, and through an increasingly unfair exchange, this value is given (your digital identity) is controlled and sold for massive profits.
Everyday users are now questioning the ethical implications of their information being harvested and traded in an extraordinary complex digital marketplace. Meanwhile, another much smaller group has been hard at work deriving a solution by paving the way for an alternative by way of decentralized applications (DApps). Even at a cursory level, many can see the need for a change. DApps are a clear contender to replace their centralized predecessors.
So, where are the DApps? As we will explore below, there are a number of highly specific and challenging obstacles to overcome before they become viable and easy to use. While it may sound defeatist to simply say that DApps are hard, the trials they present are not insurmountable.
Choosing the Platform
The initial step in the development of a DApp should not to be taken lightly. Ethereum is currently the most frequently selected, but others such as Aion, Cardano, EOS, NEO, TEZOs and Tron are among the growing number of viable options as well. Even the relatively straightforward first choice requires a hefty dose of research, however.
While obviously the selection of which platform to build on should be based on strengths (speed, reliability, etc), developers simultaneously become wedded to its drawbacks. The choice signals “no turning back” and is laden with risks of the most dangerous kind: unknown unknowns.
There are numerous considerations you need to be mindful of when choosing a blockchain to develop on. Reliability, performance, scalability, consensus mechanisms, and available talent/tooling must be evaluated. Here are a few resources to help guide your assessment of the available platforms:
So, What About the Nodes?
Once decided, the work cannot begin until connectivity is in place. Should the team deploy and maintain its own nodes? Running a node is a job in and of itself, and difficulties troubleshooting uptime are compounded into the waste of otherwise useful energy that could be spent developing the DApp itself.
Maybe a light client would be a better choice — will that suffice? Perhaps a service can provide connectivity, are there any issues there? It quickly becomes clear that any of these paths present their own specific issues.
Let us say a given team has chosen to offload the duties to a specialty provider:
In the case of Ethereum, there is the heavily utilized Infura, of which 5-10% of total connections are dependent on. While Infura does genuinely assist in streamlining efficiency, it brings fundamental issues to the fore.
Infura relies on cloud servers hosted by Amazon and the high degree of centralization from using this provider easily invalidates every unique selling proposition. DApps are no longer unstoppable, can become subject to censorship (akin to sanctions), are not trustless (the data is taken at face value), and party to a single point of failure (passing along bugs or loses availability status).
We don’t mean to single out any one provider, it is merely an example. In the case of Infura, what they have done for the Ethereum community is a gift very hard to repay. The ease in which you can connect to Infura and no longer worry about infrastructure scaling gave rise to rapid development in the space.
Here are the options that you have for connecting to infrastructure.
- You can set up and maintain your own node infrastructure, which gives you complete control but may also cost you time and money that you may feel is better spent elsewhere.
- You can connect through a service provider or DApp interface (such as MetaMask or Portis), these services take away most of the burden for you and have their own unique specialties. You will still want to weigh the service against your vision and objectives to make sure that you are aligned.
- You can connect through a decentralized relay network, such as Pocket, which then coordinates your requests across a diverse set of nodes from individuals and service providers in order to maintain performance and decentralization.
Running Out of Gas?
Whatever way the connection is established, we still have the network mechanics to consider.
Returning to Ethereum as an example, developers also grapple with the issue of gas fees to complete transactions. Currently, the burden is on the user to know what gas is, how it works and have the ability to manage it during their DApp experience.
Without anything put in place by the DApp team, users are likely to see their transactions fail due to an inadequate gas limit. When there is no feedback about why this has occurred, users are left frustrated and in the dark.
Among the solutions to this problem are projects such as the Ethereum Improvement Protocol (EIP-1613) which introduces the proposed gas station network. Portis have already taken steps to decentralize meta-transactions through use of Tabookey’s “toll-free” transactions in a way that circumvents end users need for having gas or even understanding what happens under the hood during their use of a DApp.
Debugging the Layers
Assuming the DApp team makes it this far, we still have the DApp itself to implement and deploy. Despite the open-source nature of the landscape they are working in, the technology stack is still remarkably new and presents sticking points. Dependencies on both the client side and of the smart contract platform create an immense debugging challenge.
Wrestling with unfamiliar but dependent codebase frequently becomes a time-intensive and costly factor that many smaller projects may not be able to sustain for sufficient time to get the DApp to MVP status. Solutions to bugs may not be easily discovered.
Taken in sum, the enormity of these factors are not only demotivating but potentially even delimiting to the pursuit of DApp development. Factor in an unexpected change in any of the previously mentioned challenges with Infura or addressing the issue with gas and progress suffers the deathblow.
A massive gap exists between the general population and users of cryptoeconomic assets and decentralized applications. Despite widespread familiarity with mobile applications, the necessary leap to DApps is both philosophical and technological and remains to be seen. A rudimentary understanding of the existence, purpose and effective interaction with blockchains rarely occurs spontaneously or over casual conversation.
Even with sufficient interest, users need to master several tasks before using a DApp. They must secure cryptocurrency via an exchange (which requires a KYC process) and then install a wallet such as MetaMask. Even the most enthusiastic early adopters will run across several friction points and decide to “try it later” or outright give up trying to use the DApp.
A Painful Experience
Poor UX negates any and all success made during prior developmental processes. For the user, frustrations which were kept at bay up to this point may finally succumb to the user’s existentially despair: “why do I need this?” To knock over the first domino toward mass adoption., single-step onboarding is a must.
Developers have an enormous challenge in delivering this last crucial aspect. Fortunately there are several comprehensive resources which provide step-by-step guidance:
Striking a Balance
Looming over this discussion is the broader issue of the blockchain trilemma: how to adequately balance decentralization, scalability and security. This delicate triangle has yet to find optimal equilibrium where the strength of any given attribute does not take from the others. Should any particular aspect take precedence in a given application or context? The answer to this question will likely serve as the “bridge” to allow developers to cross the chasm and bring a pleasant, useful and valuable DApp into the mainstream.
Also, should the first steps begin in the ideal, where decentralization is complete and advances toward practical application? Perhaps the opposite direction is the better choice: where a pragmatic level of centralization is used as a stepping stone toward the ideal and totally decentralized system.
We have seen both approaches taken in the space today. For example, Blocknet is a blockchain interoperability protocol built on the conviction that a multi-chain universe lies ahead and takes the ground-up approach of totally decentralized components as they are designed and implemented. Taking the other tack, Pocket is building its structure for functionality first and foremost and will gradually increase the level of decentralization once features become operationally stable.
While the debate on the approach is always passionate or even heated, the fact remains that no one can say for certain which will be the winner. The practical, valuable and fully decentralized web3 application has not yet seen the light of day. Many agree that efforts are inching continually toward it, however.
Next Best Steps
All things considered, the advent of “the app” is still quite new. Even the monolithic success stories of the traditional market (Uber and Airbnb) are only now reaching the initial public offering phase of their lifecycle. It has taken this long to get to this point, and will take longer still to bring decentralization into the picture.
So how far along are decentralized apps, and what sort of work in their development should be worked on?
New support ventures in the DApp universe are already working to facilitate the transition from web 2 to web 3. Examples such Portis and Pocket are have made their assessments and focusing their efforts on the supportive elements and gradual decentralization approach. While the chicken-versus-egg debate continues to unfold, both agree that the underlying support infrastructure must be improved concurrently with the development of DApps themselves.
Bringing additional services into the arena adds necessary competition as well, and is likely to drive superior options to the surface. Even in a scenario where coexisting entities provide similar services (such as Portis and MetaMask), distributing the load (in combination with unique approaches to specific segments of the market) can diversify the options available to DApp projects, thus mitigating the risk with single points of failure.
Filling One Gap at a Time
Despite the extremely complex problems (and even the legitimate risk of loss of funds), the evolution of the decentralized application is quietly in full swing. The rest of the world continues going about its business, unaware of the potential cryptoeconomic networks shaping up. However, under the surface of our increasingly online world are the undeterred, early inhabitants of this promising space. They are driven, connected and identifying ways to begin filling the voids between the real and the ideal.
In summary, as a developer looking to build a DApp for either completely humanitarian reasons, completely profit-driven, or a happy hybrid, you’ll need to consider these important factors.
- Choosing the right platform fit, and de-risking your long-term dependency on that platform if it does not pan out as planned.
- Ensuring that your infrastructure has minimal reliance and what could ultimately become a single point of failure.
- How to deal with crypto-economics implications for the end-user, such as “gas fees”
- Debugging and other quality assurances in rapidly changing codebases.
- Elegant interfacing through mindful UX considerations.
- Motivations of the end user, do they actually care about the same things we do? How do we get them to care?
- Constant orientation and reorientation of the key technical value propositions with the users ideal experience.
A Special thanks to Tom from portis.io for contributing to this post!