Dapps Need Dapp Services

2019-05-09 05:05:00 · 1991 views · 5 min read

dApps promise immunity to censorship and manipulation, but they’re only as strong as their weakest link.

 

We are at last beginning to see uncensorable applications begin to catch on.

 

  • Decentralized finance (#DeFi) applications on Ethereum are generating loans that have not been approved by any third party, cannot be revoked – and can be automatically collected on if the borrower goes into default.

  • Uncensorable social media apps are beginning to emerge, to the relief of users unjustly suspended by fickle company committees managing centralized platforms.

  • Verifiably fair, low-margin gambling dApps have arrived, too, and might just prove to be the first dApps to revolutionize a whole industry.

  • Games of improving quality are launching where players can own (and sometimes create and sell) in-game items and trade them freely amongst themselves.

 

Yes, this “Code is Law” smart contract movement has had frequent troubles and occasional catastrophes, but it’s beginning to bear some fruit. Yes, most of these dApps are clearly in the early days, the awkward days: the 21st century equivalents of GeoCities websites and season 1 of The Next Generation. But they are improving.

 

These distributed applications are run by code that is, to varying degrees, resistant to meddling and manipulation. But any entity managing or hosting these applications is still subject to legal action, sabotage, or disaster.

 

Servers can perish in earthquakes.

 

Domains can be seized.

 

Teams with contract account keys or repository passwords can be legally stopped, suspending development forever. And even if they’re not stopped, they can be compromised.

 

For these reasons, numerous projects are building the dApp services that distributed applications need in order to run more than just their smart contract in a decentralized (uncensorable, uncompromisable) fashion:

  • Hosting that cannot be shut down.

  • Domains that cannot be seized or otherwise stolen.

  • DNS services that cannot be manipulated in order to trick end users.

  • Frontend and backend code deployment solutions that protect code from being modified by a bad actor.

 

On Ethereum, the “Web3 Stack” is made up of far more than just Ethereum itself.

All but the most simple dApps require an array of services to function.

 

For example, a single Ethereum-based application might hope to use:

 

  1. Raiden or Celer to perform actions quickly and cheaply.

  2. Infura and IPFS, Storj, Sia, or SWARM to store data (including project code) without taking up a prohibitively expensive amount of storage on Ethereum, but still with on-chain proofs of integrity.

  3. The Graph to get and analyze blockchain data.

  4. Livepeer to handle video content.

  5. 0x, Bancor, or Kyber to allow the exchanging of assets.

  6. Provable (formerly Oraclize) to retrieve information from 3rd-party sources.

  7. Ethereum Name Service to manage human-readable names.

  8. Civic to manage identity.

 

Note: Some of these projects may not yet be ready for full production use.

 

After all, if a government, competitor, or maverick wants to take down an application and can’t actually hit the core logic – the smart contract, in this case – it would make sense to try to disrupt some service the application relies on. Hosting or storage, financial connections, identity management, external data sources.

 

As core protocols and scaling solutions mature, and as dApp developers need more services for their applications, more and more services will have solutions that are sufficiently decentralized to protect the applications they service from indirect attack.

 

Many people argue that all that matters is decentralized program logic and storage. After all, if a frontend or some other service is compromised, a replacement can be selected or developed. This is similar to a torrent tracker website being shut down – or a music sharing website, which adult readers will remember – and a dozen more replacement websites springing up in the place of the one that was shut down.

 

But this potentially drastic move is an inconvenience at best – and an application killer at worst.

 

By using decentralized dApp services, applications will grow more and more resilient, more difficult to attack, more difficult to shut down.

 

One day, I hope, we will end up with what are, in practice, unassailable applications. In some instances, the company that built your favorite application can go out of business or move on to other projects, and yet the application will live on – perhaps powered and governed solely by its users.

 

Immortal dApps” is my favorite phrase, one introduced to me by Tal Muskal of LiquidApps. The LiquidApps project provides code for the DAPP Network – a distributed network of service providers who can offer, on a free-market basis, a range of decentralized services for dApps like the list I mentioned above: hosting, database and file storage, easy access to information from the blockchain, information from 3rd-party APIs, and more.

 

I found the importance of decentralized dApp services so compelling, in fact, that I was delighted to join the LiquidApps project full-time earlier this year so that I can help explore, build, and explain dApp services.

 

After all, in order to build resilient applications, we must build resilient services for their foundation.

It will take a lot of development work, full of tests and disappointments and triumphs along the way. In the end, though, dApp service developers hope to build a world where these fully uncensorable applications can be built and used with speed and ease.

 

dApp services of all kinds may even begin to bridge across protocols, as well, becoming blockchain agnostic, and this will ease dApp development even further.

 

Perhaps you’ve seen Mainframe’s great video:

dApps are clumsy today, but all inventions and innovations are when they are first born. Solid dApp services will allow dApps to be developed more quickly and more reliably. Developers of each service will be skilled in that service and focused on maximizing efficiency and performance. As these services improve, so will all of the dApps using them.

 

Solid dApp services mean better dApps.

 

Many people are understandably quick to criticize dApps, calling them inefficient, unnecessary, and uninteresting. Some of the criticisms are locally valid – “come on, do you really need a token for that?” – in general, these criticisms miss the forest for the trees. We developers are all on a journey. We’re building. We’re taking one step at a time, learning and fixing and breaking and tweaking along the way.

 

If people realize that a token is a dubious idea for a given dApp, someone will probably try the idea without a native token. If platforms prove to be too slow or unwieldy, they will continue to be improved, or additional layers will be added, or the platforms will be discarded for faster platforms. This is how the greatest things in the world come to be: one iteration after another.

 

Why go through all the trouble to build a new, decentralized infrastructure? Well, we have to.

Bitcoin is a powerful development that limits any entity’s ability to obtain massive, destructive power. In fact, its freeing of money is arguably the most important move of all.

 

But even with free money, corporations or governments may gain total power over data, power over the press, power over travel, power over people’s social lives. All of these outcomes, and more, grow increasingly realistic with the news of each passing week. Unless we build a way for our applications to run on something other than monolithic infrastructure and centralized service providers. Unless we find ways to prevent our applications from being shut down or taken over by humans hungry for power.

 

This is why these services are important. Building new decentralized applications and all of the services needed to enable them is a hard road, but it’s the only road many of us see to a free, fair, peaceful world.

 

We need dApps which cannot die. For that, we need dApp services which cannot die.

I believe Layer 2 will continue to blossom, and that it is a space with tremendous opportunity for developers, creators, and entrepreneurs of all kinds to build great things for the future of software.

 

Be sure to keep an eye on it.

infrastructure
Comments Write Comment
Currently there are no comments for this article. Would you like to be the first to write one?