Bank innovation manager talks about several major issues of decentralized applications (dapps)

Alex Batlin is a senior innovation manager at the UBS FinTech Innovation Lab and head of crypto 2.0 blockchain technology research at the Swiss financial firm.

In the article, Batlin points out that decentralized applications are more at risk of centralization than hardwired protocols like Bitcoin.

Over the past few months, I’ve been struggling to understand the dynamics between Ethereum’s smart contract-based distributed application (dapp) model and hardwired protocols like Bitcoin or Ripple.

This week, that feeling has crystallized into a semi-coherent train of thought.

Hardwired protocols do not separate the protocol from the business logic; the same protocol designers, software developers, and miners control how the Distributed Autonomous Organization (DAO) functions.

It is different for dapps. There is a clear dividing line between the protocol and business logic encapsulated in the smart contract.

The evolutionary dynamics of dapp-based protocols can be similar to Bitcoin, but it is very different from the dapp itself. They can have a clear owner, such as who uploaded it, or the person or organization that collects its usage fees.

Concentration Risk

This introduces an unexpected, at least to me, risk of centralization.

Of course, the protocol can be distributed, and therefore the operation of the dapp can be distributed, but if many other dapps use a shared smart contract that is controlled by one party, then you are back to a centralized model, at least on the logical layer, which in some cases may be exactly what you want to avoid.

If managed properly, this isn't necessarily a problem.

Highly shared smart contracts can be considered key infrastructure components that can be formally owned and managed by some form of open software foundation (OSF), such as the Ethereum Foundation or some other organization. The key here is that there should be no confusion about who owns the smart contracts and what obligations they have.

Alternatively, you can write “mirror” smart contracts to mitigate the risks of centralization.

For example, suppose two parties need to track a bilateral contract. Each party will deploy its own smart contract instance, and each instance will also track the contract's outgoing and incoming transactions.

Technically, double tracking data would be inefficient, but it does provide a simple ownership model.

That said, as long as they provide unique value and users are fully aware of the associated risks, there is no reason why smart contracts cannot be private, even if they are highly shared.

Welcome to the Dapp Store

Once you start charging for your dapp, you have to figure out what you are charging for. Are you charging for deploying your own smart contract and dapp wallet, kind of like buying an app from the app store? Or is it a service provided by the deployed smart contract?

It can be said that it is difficult to charge service fees for smart contracts unless the dapp has a lot of value-added off-chain services.

Based on this assessment, we may end the “DAPP store” model, where people need to purchase a license to deploy a well-written, standards-compliant DAPP instance on the blockchain.

However, this means that dapp creators don’t need to provide guarantees of business, so who would do that?

There are similar examples today, for example, iOS developers rely on Apple to provide devices, OS operating system and App Store. And they all rely on bandwidth and connections provided by mobile Internet Service Providers (ISPs). However, none of them guarantee the entire service from beginning to end for app users.

New Entity Requirements

Therefore, the conclusion is that we need a new type of entity: a Blockchain Service Provider (BSP). Essentially, it is not a Bitcoin or Ethereum miner, or validator equivalent, as it is today, but rather it is a provider of a guarantee, maintaining a full node for use by lightweight end-user wallets.

This blockchain service provider is likely to run on a blockchain-as-a-service (BaaS) cloud computing platform, such as Microsoft's Azure platform, which already supports multiple blockchains.

This structure requires clear legal responsibilities for the entire supply chain. End users must formally accept the restrictive regulations of dapp wallets, dapp smart contracts, and blockchain service providers.

Multiple interconnected blockchain service providers will be required to provide a sufficient level of trust that exceeds that provided by centralized service providers, as no single party will be able to unilaterally change any part of the system.

In other words, blockchain business is a trustworthy business, and then you need to decide whether you will enhance trust for the specific application you use.

Original article: http://www.coindesk.com/crypto-2-0-musings-dapp-centralisation/
By Alex Batlin
Compilation: Overnight porridge
Source (translation): 8btc Information (http://www.8btc.com/dapp-centralisation‎)