The rise of blockchain dApps

In order to encourage developers to create dApps, it’s essential to have a platform that they can quickly adapt to and enjoy working on. As former mobile app developers ourselves, my co-founders and I have an advantage, as we know what developers are looking for here. We are focusing on building the Orbs public blockchain with developers in mind. So we know what apps need, but in blockchain, those needs will revolve around the still scarcely-explored frontier of decentralization.

Why are we moving toward decentralization?

The philosophy of decentralized apps – dApps – represents a counterbalance to pervasive entities like Facebook or Google that are proprietary rather than governed by the people who use them as utilities every day. The need stems from an incongruence between product vendors and their users in centralized corporations. For users, Google is an indispensable search tool. For Google, it’s an advertising monetization platform.

DApps built on blockchain infrastructure are designed to turn this situation on its head, handing control of data back to the users. However, it’s important for developers to remember that blockchain has some additional pain points that must be considered. Whether dealing with issues like governance, flexibility, and scalability, or avoiding lock-ins, it’s essential that developers make sure that the infrastructure networks they choose to build with tackle these problems in their inherent design.

Flexible governance

Developers know how to build a centralized governance protocol, but a decentralized one – whether for a blockchain protocol or a dApp over blockchain – is a whole new ball game. DApps are governed by decentralized autonomous organizations (DAOs), which embody elements displayed by both states and corporations. We have a strong notion of what works for corporate or state governance, but this is not yet the case for DAOs.

Nearly every cryptocurrency project is currently trialing its own approach to this problem, looking to apply varying proofs-of-concept. However, the fact of the matter is that most of these strategies are not battle-tested, much less proven to be resilient.

We are still far from establishing best practices. That’s okay, although this does mean that developers need to plan accordingly. This said, it is important to choose a foundation that will enable the dApp to evolve as it grows, and its governance model to adapt emerging best practices or external constraints such as regulations. This means blockchains must be malleable and highlights why when building Orbs, flexibility and agility have served as core design and architecture principles.

Most dApp developers want to independently decide how their network should be governed, most have different security requirements, and all understand that their current requirements would change in 2-3 years. Therefore the blockchains they build on should provide this, by design.

SEE ALSO: dApps 101: Tips and tricks to get you started

Scalability

Ethereum and other base-layer protocols have yet to scale to accommodate mass user onboarding. Several second-layer solutions like Casper and Plasma are in the works, but with different tradeoffs: operational costs, security, governance delegation, production timelines, and so on.

There are many innovative transaction-scaling solutions by a number of great infrastructure projects. Specifically, on the Orbs blockchain, our approach is to have each dApp live on its own ‘virtual chain,’ protecting it from traffic stresses on other parts of the network. This form of intelligent sharding, together with our Randomized Proof-of-Stake (RPoS) consensus algorithm, achieves speed while maintaining the dApp’s own security and governance preferences, without compromising on decentralization.

What gets lost in the scalability discussion, though, is that scalability is about more than transactions per second. Speed is important, but fee scalability is even more crucial. Fee structures should avoid diseconomies of scale and provide low, predictable pricing models. Unpredictable fees make budgeting impossible – a no-go for real businesses. Additionally, fee structures where the end-user pays the cost hammers usability. I find that dApps look for established software standards developers recognize, such as subscriptions, for example. Like dedicated web hosting, dApps can subscribe to computing and storage resources with a monthly bill that produces a predictable fee schedule and also allows them to subsidize infrastructure costs to encourage user adoption.

Avoiding lock-ins

Just like choosing a cloud provider, developers should avoid choosing a blockchain platform that locks them in “for life.” Versatility is critical. This way, developers can move to another platform if need be. This further incentivizes platforms to become more competitive in their internal flexibility, ensuring relevance by developing updated tools, incorporating features for the benefit of dApps, and meeting customer (i.e., developer) demand.

There are many tradeoffs developers need to balance when building a dApp. Some are well-known, but most others won’t be obvious until blockchain businesses have time to progress, pivot, change, and hopefully grow. As pioneers, the best advice I have is to make sure your foundations are relatively adaptable and enjoy the thought-provoking challenge of preparing for the unknown.

The post The rise of blockchain dApps appeared first on JAXenter.