Where are all the dapps?

This post is based on the presentation made by Tim Galebach at the NAC3 Conference on December 9th, 2017, where Tim spoke about the Credit Protocol, Lndr and his approach to solving the problems faced during the development of decentralized applications on Ethereum.

*The content was edited for clarity.

What happens after an ICO?

A dapp — short for ‘decentralized application’ — is an application running on Ethereum. Today, there are many ICO (Initial Coin Offering) companies that are talking about the dapps they develop. But most of us haven’t used dapps, with the exception of “Cryptokitties” or “Etherdelta.” So the question coming up a lot lately is, “Where are all the dapps?” There are programs that can run on Ethereum, and Ethereum has been out for about three years, so why aren’t there more dapps? There are reasons for that, which we came across ourselves once we started developing the proof of concept for our app Lndr.

In order to build dapps that are usable in a familiar and accessible way, we need an entire world of underlying technology in Ethereum. The problem is, no one wants to build the underlying mechanics until there are dapps that are going to use it. It really comes down to a chicken and egg problem. For example, Cryptokitties only exist on a browser, not on mobile. This is because, before them, there wasn’t a big incentive for anyone to build mobile libraries and the technology that you need to make it work on mobile. Thus, programmers don’t want to create dapps until there’s a useable foundation already in place. But, no one wants to create the usable foundation until there are dapps already in place to run on it.

The journey starts with real steps

Since this summer, we’ve talked about a lot of ICOs, and there’s one important fact that relates to many of them. Many whitepapers, and I mean ours included, talk about big ideas and about the ways these ICOs are going to build massive platforms and change the world. But the journey can’t start just with big ideas; it has to start with actual real steps. I’ll demo those real steps in the dapp in a few minutes.

It is worth mentioning that while it is great to have a functional dapp, it can feel like a step backward. This is because when you start building that first version of the dapp from the bottom up, the dapp won’t live up to the platform it will develop into later. And, it definitely won’t live up to the imaginary application everyone seems to talk about in a whitepaper. However, this first version of an application is an essential step towards building the dapp that you originally dreamt about.

About Blockmason and The Credit Protocol

Let me give a quick overview of how we started Blockmason. I’ve been a technology developer for a while, and earlier this year we, along with some friends, started Blockmason for developing a project to build the protocol for recording debts and credits on the Blockchain. This protocol was called the Credit Protocol.

We saw this protocol as a fundamental base for all accounting. This is especially true when you add a functionality for guaranteeing that the debt and credit recorded on the Blockchain is cryptographically signed and agreed to by both parties. This functionality can’t be replicated when people are just keeping tracks of IOUs (“I Owe You”) on an Excel spreadsheet or handwritten notes, which cannot guarantee the legitimacy of the obligation.

The Credit Protocol is a base-level protocol, and the first thing you want to do with a base-level protocol is to prove the concept and show people how it can be useful. So how did we turn this protocol into an actual application?

Lndr: the first dapp built on top of the Credit Protocol

We launched the Credit Protocol on testnet in August, had an ICO by early October, and launched the Credit Protocol on the mainnet in mid-October. But even by launching it on the mainnet — a significant step further than most other ICOs have gotten to — we still didn’t make it easy for users or developers to interact with it.

We sometimes think of developers as magicians, but they are people just like you and I, who Google things they don’t know when they’re building an application. However, besides some very basic information, there are not a lot of resources available about Ethereum. This means developers run into a brick wall when they try to teach themselves more about Ethereum and dapps. And if developers run into that problem, then certainly the average user would as well.

So I’m going to demo the first proof of concept that we’ve made. Lndr lets you track debts and credits between friends. When we started building it, our assumption was that, since the protocol is developed and released on the mainnet, building the dapp would be easy. And what we found out is that every piece that would have been an easy development for a regular none-decentralized app turned out to be complex and work-intensive.

I now will walk through the current state of Lndr. We are doing a lot of redesigning right now, but I think it’s good to show people where we are in the process and explain what challenges we’ve faced so far. This way, we can talk about what work there still is to do, so that more people can develop decentralized apps in user-friendly formats such as mobile.

Lndr Demo

[Launches the demo of Lndr]

Hopefully this works. Demos are usually the worst idea ever.

I’m running Lndr right now on my phone with my ID of Tim, and we also have the dapp running on a simulator, to simulate another user. I am firing up Lndr, and I am going to imagine that this other user is a company and that I’m sending the company IOUs for some work that I did.

[Creates an account for the imaginary company]

All right, so we’ve created an account. And here we see these words, called mnemonic recovery phrases, that users have to write down. This is based on the idea of a key management, and if anyone has used Metamask, hardware wallets, etc., then you’re already familiar with this. I’m not happy with this system, but with what we have available today, this was the first compromise we had to make so that users can restore their accounts if they need to.

Now we are going into the actual application. Here I can see my total balance, the number of counterparties, and an option to add a new debt.

The first thing I want to do is add a friend. I’m adding Tim as my friend, and now I can see the total balance between us, which is currently zero. On my home screen, I’m going to add that I owe Tim $1,000 for the software development work he performed for the company, and then I submit it. We are currently using the term “friend” to describe parties, but we might change that to something more neutral.

Now we see a pending transaction that needs to be confirmed by Tim. Notice that this happened instantly. Anyone who’s very familiar with Ethereum is immediately going to ask, “How did you do that?”, because such immediate transactions are not possible in a decentralized architecture. Many of us know that when you buy Bitcoin or Ethereum, it takes some time for transactions to go through. With Cryptokitties it takes many hours. So I’ll talk later about how we did this and the trade-offs that we’ve made while keeping the decentralization for the most part.

At this point, I go on my iPhone as Tim and confirm the request. Now again, this confirmation was instant, which means that this couldn’t happen directly on the Blockchain. However, we still want to guarantee that these debts and credits are stored on the Blockchain and guarantee that both parties confirmed the obligation. At this point, we have completed the demo.

Next, I am going to talk about what we have done to enable these functionalities, while providing a rapid user experience. As I mentioned earlier, each seemingly easy step in the development turned out to be very hard and this demonstrates some of the challenges the tech community will need to address going forward.

Analysis: the lack of resources and platforms

The first thing we needed to address were those keys — mnemonic recovery phrases or mnemonic seeds — a list of words that store the information needed to recover an account. And for us, it wasn’t even a question of getting rid of them to ensure an easy and smooth user experience. What we were trying to find was already developed programs that handle those keys. And it turned out there wasn’t much out there, so we had to develop most of this functionality from scratch.

Then when we got to the part where I sent out a debt from the company to Tim and said, “I owe you this much,” my phone had to actually sign that, to confirm the request came from my phone and not from somewhere else. This functionality also took a fair amount of time to develop, because there were no platforms already developed to handle this functionality.

Now, I know that some people get bored with the development talk. But keep in mind that this process is something that every ICO/ blockchain company has to go through. As users, we may only be interested in seeing the final product, but there is a lot of work that goes on behind the scenes. And because this process of developing a product on the Blockchain is difficult and frustrating, it incites companies to give in and not pursue their previous app ideas, and instead write another whitepaper about another great product they will build in the future. This means that companies are constantly jumping from one hypothetical to the next, without making any of those hypotheticals into reality.

In addition, when we speak about mobile versus desktop, we have to note that there are many tools already written for interacting with decentralized apps on desktops. For example, platforms such as MyEtherWallet and Metamask have functionalities that enable the interactions with dapps. But not many platforms of this type exist for mobile.

Opportunities and Outputs

Despite the difficulties we mentioned, we’ve also generated many opportunities. For example, we now have the internal capability to quickly develop mobile dapps. We also want to share libraries, documentation, and tutorials with the broader community, even though that is not a part of our protocol and ICO. This sharing is essential, because it is the only way other developers are going to start using Ethereum and similar technology, and be able to develop platforms on top of the Credit Protocol. Therefore, this information needs to be available.

Rapid user experience

How does Lndr provide instant user feedback, when currently on the Blockchain we have to wait for block confirmations before transactions can be validated?

This is an important point that we had to address, because most general users aren’t going to accept long waiting periods just to use decentralized apps.

So, waiting is not an option, but we still need to keep the decentralized aspect. We could have our server sitting in the middle of the two parties and make it appear to users as if the transaction was confirmed, while it’s actually still waiting. But it isn’t that easy. I don’t want to get too technical, but most Ethereum programs do not care about who sends the transaction information. Thus, we had to redo the normal Ethereum approach and our entire design to make it operate so that the Ethereum application only receives information about the transaction itself, and not about who is sending it.

Our main programmer came up with a great way to make the protocol handle the transaction so that it could take the debt from a third party (our server), but still have the two involved parties sign and agree to the transaction. This allowed us to designate our server as the one that sends information to the Blockchain and then waits till the transaction cost goes down. This makes it a short-term source of truth for the period of time when the transaction goes into the Blockchain. And in the long run, you can audit everything by looking in the Blockchain and seeing those debts going in and being signed. This approach guarantees the recording of information on the Blockchain, and allows our server to be the one who pays for the transaction, while giving a lot of options in terms of how we monetize the program and how users pay for those transactions, and enabling users to do things such as in-app purchases.

This takes us to the next point: how do we create a fluid user experience on a dapp? Today, when someone uses a dapp such as Etherdelta or Cryptokitties, the user has to perform a lot of steps such as choosing the gas price and hitting confirm button. It’s a great system for sophisticated users, because you get a lot of control, you know exactly what is going on, and it can be fun. But, it doesn’t generalize to the common user, as those steps are not something a user should have to think about.

Such complex process makes dapps incredibly bad for adoption and because of that, that is not an option for this community going forward.

So as I said, our protocol design lets us have the server submit the transaction details, and that creates an instant user feedback and a smooth user experience.

Cryptokitties

Let’s talk about the big elephant in the room, something that I thought was about six months away, until things started getting developed faster in Ethereum. Currently, the development community faces some scaling issues on Ethereum, especially when we see that one app — Cryptokitties — can break the network and make Ethereum almost unusable, especially for small transactions.

What this means for us is that we didn’t think our company would be in this business, but we’re going to have to start putting research and effort into developing sidechain options and having Lndr run on its own network, so applications such as Cryptokitties can’t bring it down. Thus, the recording of tokens and the license to use our app could live on Ethereum, and I think this model will be used a lot going forward. But we have to have these alternate ways of storing data for each dapp, otherwsie dapps won’t be feasible or sustainable, and so they won’t be developed.

And it is possible that in the future we will all have to use sidechains developed per application, so that each big application will have its own network of computers — perhaps secured by their own token as the incentive for the users to run it, and possibly secured by proof-of-stake.

What’s next?

Given all this, and what we have developed already, we have some interesting options moving forward.

Because we have the server that can hold transactions and have them pending while moving them to the Blockchain, the next feature we’re going to add — starting this week — is a settlement of debts with cryptocurrency. From Lndr’s functionality perspective, this means that if I want to settle my debt with ETH, the server will hold my signed transaction and will send the ETH to my friend only if my friend accepts that payment. Once my friend confirms it, our debt gets cleared and my friend gets paid with cryptocurrency. This is a great way to get people onboard with cryptocurrency.

One of the most important aspects of future development is publishing the documentation that will help the general dapp community — not only those who develop applications on on top of the Credit Protocol— to develop dapps more quickly. This documentation from what we’ve done will provide resources and working libraries that developers can plug into developing programs in Ethereum. As a result, the increase in dapp development will also make all of us start dealing with the Ethereum scaling issues sooner than later. And thus, because of what we and other people are doing in the field, we will all start seeing a lot more mobile, decentralized applications using Ethereum.

Our current developments have also helped us better understand the Credit Protocol possibilities. At first, we thought we had mostly an IOU system, but it turned out to be a generalized system for handling accounting. Next, we’re going to be working on a partnership to create a banking project as a proof of concept. We’ll also be working on a proof of concept for a program to handle short-term small business loans, especially between companies.

Thanks for having me!

• The content was adapted from a presentation and edited for clarity.

To watch the video of the presentation, click here.

// Blockmason Team