Dapps Need To Go Beyond Client/Server Models If They Want Higher Adoption Rates

About a year ago I was excited to hear about the growing number of Decentralized Applications (Dapps) appearing on the EOS mainnet. I started to investigate these Dapps and came away disappointed. Most of the, so-called Dapps were traditional client/server web applications that simply utilized a blockchain component, called a smart contract that existed on the blockchain.

Apparently if you built a traditional client/server web application and just packaged some of your logic in a smart contract, you are able call your applicaton a Dapp.

I am optimistic regarding the potential of Decentralized Autonomous Organizatons (DAOs). Envisioning a future where decentralized organizations could exist and operate autonomously (7x24x365) on the network governed by smart contract codified law.

I envision DAOs controlling either a single Dapp, or a portfolio of Dapps, with automated and decentralized business models, which improve upon traditional business organizational structures such as partnerships and corporations.

I found that many (so-called) Dapps issued tokens to facilitate profit sharing (paying dividends) to token holders. Token holders would stake their tokens to a smart contract and then receive passive income in accordance with the rules specified in the business model.

This appeared to be a promising model for receiving passive income. However, in November 2019 the EOS mainnet experienced what was called CPU congestion that had a detrimental effect on the user experience. During that CPU congestion period many of the (so-called) Dapps dissolved leaving token holders holding worthless tokens with no recourse.

It turns out that these token holders had no property rights with regards to these now, worthless tokens. They had no decision rights with regards to terminating the (so-called) Dapp or any sort of recovery plans. So while many considered owning such tokens analogous to holding shares in a corporation, they found out that they had nothing resembling shareholder rights. Their only path forward was to accept the loss and move on. Certainly their must be a better way!

My conclusion was that these (so-called) Dapps were really not decentralized applications. If the web server went offline, the app was no longer accessible. These applications had the same characteristics of centralized client/server applications with a single point of failure susceptible to DDoS attacks, censorship, seizure, etc.

Token based business models involving profit sharing fell way short when compared to traditional models supporting property rights and therefore, in my opinion, were not ready for prime time.

What is a Dapp?

To be classified as a Dapp, the application, as well as it components need to be decentralized. Just having an application component that resides on a blockchain, i.e., smart contract, should not be the only qualification for classification as a Dapp.

If a web application is a traditional client/server pattern with a single server and IP address, it is not decentralized.

I searched for quite some time to find a Dapp that met my criteria and came up empty until just recently. I came upon a gambling game (figures, gambling seems to be the primary use case as of now) that had a smart contract on the Telos blockchain. A post on reddit provided a link to a paper describing the game along with a link to its homepage.

What I found interesting was that the link to the game homepage was actually an IPFS hash available via an IPFS public gateway. Not a domain with a web server.

It is interesting that the homepage is simply a collection of files stored in the decentralized Interplanetary File System (IPFS). However,I thought that I may have found an underlying weakness with that. Since IPFS hashes are immutable, packaging a web homepage on IPFS would basically make the homepage itself immutable and unable to be changed.

Certainly the owner of the homepage content would want to be able to make changes over time and edit the content. So I looked to see if the website utilized IPNS and DNSLink.

If so, there would be a single point of failure from a censorship standpoint. With DNSLink, DNS TXT records map to a domain name and a domain can be shutdown via censorship.

I submitted a number of questions via email, to the email address listed on the homepage and received a response with some answers.

Turns out that the IPFS homepage does not use DNSLink and the homepage is in fact immutable. However it is structured such that the content rendered on the homepage is mutable!

I was very curious as to how that was done. It turns out that the approach was very simple and elegant. The homepage (using javascript) dynamically makes an rpc call on the Telos network to read a content IPFS hash that resides in a smart contract table. The javascript code in the immutable homepage renders the homepage content from the IPFS hash in the smart contract table.

This approach provides an immutable URL that will never need to change, yet at the same time allowing the content presented on that page to be changed (mutable) by simply updating the IPFS hash in the smart contract table that represents the new content.

The link to the Dapp itself, is handled similarly. As can be seen in the screenshot below, the URL for the Dapp is also an IPFS hash and the hash of the Dapp is stored in the same smart contract table, read by the homepage content code. This allows for versioning of the Dapp over time.

The architecture of this Dapp then is decentralized as it is using the global IPFS network to distribute the Dapp. The code doesn’t sit on a single server that could be shutdown.

Furthermore, the Dapp is all client-side javascript code that doesn’t communicate with any server. It is a client-side javascript web application that only interacts with a local wallet (Scatter Desktop) and smart contracts on the Telos blockchain.

Given that the Dapp is entirely client-side javascript, it is open-source and the code can be inspected and reviewed (minimizing js files makes this more difficult but still qualifies as open source). Users of the Dapp authorize transactions with their Scatter wallet and the Dapp has no access to a user’s private key.

I was informed via the email exchange that the Dapp code contains no keys itself and all blockchain transaction authorization that occurs within the scope of the Dapp are user authorized transactions via Scatter. So there is no security risk to the smart contract relative to the Dapp.

Another innovative feature involves a user friendly way to verify software integrity. Allowing users to verify that they are using the authentic software package and not some packaged tampered with by a bad actor. The IPFS homepage link is immutable and will never change. If someone attempted to change the homepage file in anyway, this would result in a different IPFS hash. So to verify that the correct software package is being used, the user simply needs to check that the homepage URL is the same URL present in the pick2lottery contract, dappinfo table, homepage_skeleton column as shown below:

Once confirmed any link present in the content is authentic, guaranteed by the mathematics inherent in the IPFS protocol. From a user experience perspective, verifying the URL is much simpler than having to perform a SHA256 hash on a downloaded file and comparing that hash to a published hash every time an application is versioned. That process is encapsulated from the user and performed automatically by the IPFS protocol and the innovative way the designers of this game packaged their software.

The game does issue its own token for profit sharing purposes and uses another smart contract for that. Staking and unstaking LOTTO tokens can be performed by users using the Dapp.

So this Dapp (TLOS Pick 2 Lottery) fits my criteria for a Dapp and I would be willing to classify it as such. Dapp developers/designers should use this Dapp as a reference model for their own designs. Integrating the smart contract data tables with IPFS content links is an innovative approach to legitimate Dapp design.

Regarding the token profit sharing business model, I see the same risks present regarding property rights and a lack of legal recourse. The Telos platform has arbitration rules in its governance model that provides a level of recourse via arbitration. However, I believe that we really need significant improvements in this space in order to challenge traditional models.

Interestingly, the team behind this particular Dapp say that they are looking to create a DAO to govern their business model and their portfolio of Dapps to provide decision rights to token holders. Specific details are not yet available, but I'm very interested to see what may develop.

So in summary, this Dapp design pattern is an improvement over what is in widespread use today and should be adopted and continuously improved over time. The business models for generating value and sharing them while providing strong digital property rights still has a long way to go before defi can obsolete traditional models.

I will closely monitor developments and will post another story with detailed information once it is made available.

Disclaimer: I was very impressed with the decentralized design of the Pick 2 Lottery Dapp mentioned in this story and as a result, played the game to acquire some LOTTO tokens. As a result, I now have a vested interest in the success of the Dapp business model. I am not a team member and have not participated in any development of the TLOS Pick 2 Dapp.