dApp Developers Must Focus Effort On What Makes Them Unique
Developers of any type, but especially in the Web3 industry, face the same challenge as any hero on a streaming platform. This probably needs a little explanation.
If you’ve seen any series on a streaming platform, especially the type of series with a very simple story, you’ve probably witnessed this effect. For an entire season, the hero has to travel to a destination to deliver something, to retrieve something, or to do something. Why is the story spread across an entire season instead of a single episode? Two words: Side Quests.
The hero begins the series with a seemingly simple mission. They understand what needs to be done, they have a plan, they have what they need, and they get started to accomplish it. But then, there is a wrinkle. Before they can accomplish their goal, they have to go fetch something, talk to someone, build something, destroy something… the list goes on.
The curse of the side quest begins. In the next episode they complete the side quest, but by the time they finish, there is another side quest, and another, and another. Sometimes there are side quests within a side quest. The point is, they don’t actually get to finish their primary goal until the season finale (unless the series is especially cruel and stretches the original goal across seasons), guaranteeing a full season of adventure even though the only real value-added goal should have been straightforward.
For a series—at least when done well—this can be very entertaining. For a developer who is prevented from finishing something they have dreamed of creating, this is a nightmare. Developer side quests are a seemingly unavoidable piece of building software, especially with something as complex as a Web3 dApp. This is a surprisingly involved piece of infrastructure with many different moving pieces, countless considerations, and tradeoffs the team will have to seriously consider.
While the goal might be to build a dApp that can perform a handful of key processes, the side quests necessary to make that happen can be overwhelming. Let’s look through this process and see the different paths available to developer teams looking to build up a dApp or even a dApp ecosystem. Each path has pros and cons to consider, but it is important to ensure that you are eliminating as many side quests as possible. We will consider some of the traditional choices for dApp development, such as L2/L3s and AppChains, and will look at newer options, such as the Supra Container.
Level Up, Level Down, Level In-Between
One of the biggest considerations for dApp development is the level at which to build. The primary chain is at Level 1, and in some ways building here offers the most direct connection to various infrastructure and services. However, it can also put the dApp at the mercy of unfavorable effects of the chain itself, being unprotected from congestion, gas price surges, the ability to determine governance and token policies, and more.
Because of this, building on a generic Level 1 is not ideal, especially when that chain has a wide variety of other platforms on it. However, there is a form of this that allows for some key Level 1 benefits. The AppChain is a specialized blockchain that is built around your needs.
It can be tailored to the needs of a single dApp, or to a group of dApps that share similar characteristics. It has a number of big advantages in that you are able to completely develop the governance, consensus model, tokenomics, and security that is optimal for the dApp environment you need. This is excellent of course, so what’s the downside? Well, simply put, this is a laundry list of side quests. Before you can even begin to build up your dApp, the piece of software that is value-added and that will provide something unique, creative, or revenue generating, you must first build up the infrastructure yourself.
Customization is very attractive except that you have to either pay an expert, or do it yourself. And most dApp development teams do not possess the strong infrastructure experience needed to do this well, and these elements have to be right for the dApp to be efficient, secure, and reliable.
The other common approach is to take the dApp down a level or two, to a L2/L3 platform that can host it. There are certainly benefits of doing this in that some of the L1 infrastructure elements can be used by the dApp. Moreover, having the dApp at an L2 can nearly always provide a significant boost in speed and reduction in cost, rolling up to the L1 at specific times.
However, there are also significant challenges, notably fragmented liquidity, broken composability, and potential security issues. These can be devastating for a dApp needing to pool liquidity or to have a solid composability structure, and security issues of any kind are one breach away from devastating the most successful dApp.
As mentioned above, there continue to be new approaches developed for dApps and dApp ecosystems since neither of these options is especially superior. Supra’s Container model is one example, and has made progress in taking a Goldilocks approach by examining the limitations and actually building new infrastructure to prevent them.
The model is called a “container” because it acts very much like a self-contained ecosystem within the Layer 1. It does this for three key reasons. First, so that it can stay isolated enough to manage the value-added elements such as governance, tokenomics, and compute/execution space. Second, so it can connect enough to take advantage of the Layer 1 infrastructure: Security, composability, atomic transactions, oracle price feeds, onchain verifiable randomness, cross-chain communication, and automation. Third, so it can stay at a high enough level to maintain connection with the liquidity across the L1 network, which is critical for any liquidity-driven dApp.
Verdict
It does seem clear that the Supra Container model has a lot to offer. It’s important to take this in context, however. For one, this is a natural evolution as newer models learn from older improvements, and the L2/L3 and AppChain models have given plenty of lessons learned for the newer generation of dApp scaling tools. It’s also important to realize that different development teams may still want to choose a DappChain if they have the need and resources for full-up customization, or an L2/L3 rollup if they want to perform specialized off chain processes with the periodic rollup. For many dApp development teams however, the Supra Container model offers the best chance of minimizing side quests and being able to focus on the value-added development driving the team forward.
***
DISCLAIMER
The views, the opinions and the positions expressed in this article are those of the author alone and do not necessarily represent those of https://www.cryptowisser.com/ or any company or individual affiliated with https://www.cryptowisser.com/. We do not guarantee the accuracy, completeness or validity of any statements made within this article. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author. Any liability with regards to infringement of intellectual property rights also remains with them.