A Middle Way Forward for Blockchain

[Leonardo]

Here in Stockholm, we’ve entered the long months of winter. In the next few weeks, the sun won’t rise until 9:00 a.m. and it will set just four hours later. Perhaps it’s some combination of our location and temperate climate which makes Swedes both innovative and practical.

We have a track record here on commercializing technologies (Stockholm is second only to Silicon Valley when it comes to the number of “unicorns” that it produces per capita). Companies like Spotify and Skype have combined cutting-edge technology with a practical approach to addressing consumer and business needs.

This in mind, there’s a Swedish concept called “Lagom,” which roughly translates into “Not too little. Not too much. Just right.”

Viewing blockchain through this Swedish lens, I see a useful design logic for how this technology can evolve to address many of the well-documented limitations of existing platforms and open up new (currently hard to predict) paths to solve pressing business and social challenges.

The internet ushered in a new era of businesses made possible only through networked technology. The leading companies in the world today, Google, Facebook, and Amazon, would not be possible without internet-based information exchange. The blockchain, some refer to it as Web 3.0, introduces a new layer that enables internet-based value exchange.

But, this leap forward is not a conversion exercise where enterprises simply re-write their code and move to an internet of value exchange. It’s more complicated than that, and success will require us to determine the best technology and business trade-offs to facilitate adoption and scalability without compromising security and trust.

As we are about to cross over into 2019, I offer these lagom-inspired approaches to resolving some of the thorniest problems facing greater blockchain adoption.

1. Function Versus Form
Dapps, applications that run on distributed blockchain data networks, have a number of problems currently.

User interfaces are quite crude and not easily navigable. Performance lags, no doubt due to the time it takes to validate transactions on the blockchain (a prospective passenger waiting in the rain on a New York street corner might have to wait at least 10 minutes for the transaction to be initiated on a bitcoin-based ride sharing dapp).

In addition, cryptographic keys will have to be managed by users who will likely view this as an unnecessary burden.

One impulse is to “wrap’ the dapp in a slick user interfaces thus hiding all of the decentralized, unique and value-adding aspects of blockchain. A better approach would be to introduce much improved design elements, but preserve features which make the blockchain most powerful. For example, instead of a pure custody model (See: Coinbase) for maintaining keys, utilize a multi-signature approach.

Instead of centralizing all of the client application operations (e.g., the algorithm which generates unique CryptoKitties), allow application logic to run on the blockchain. These are just a few, of the many, ideas to achieve better design balance for dapps.

2. Data Loaned Versus Data Owned
When I log onto LinkedIn, I am providing data that the company (actually Microsoft) now owns in exchange for my use of the application. Dapps offer a radically different data ownership model. The dapp user controls data access (through cryptographic signing), not the dapp developer.

This presents certain challenges and advantages for all parties. Developers have the complication of having to architect applications that utilize data validated by nodes operated by independent service providers.

Users will have to adjust to thinking of data as an asset they own and decide to “lend” to app developers. On the other hand, dapp developers can charge for use of the application and users are benefiting by paying for value-added features and functions and not to have their data sold to vendors.

3. Zero-Sum Versus Shared Benefits
The rage in the app economy is software-as-a-service pricing. Whether one is using a CRM tool like Salesforce or renting time on Amazon Web Services (AWS), it’s generally a zero-sum game for users. Unless I own shares (which have a separate set of costs) of AWS, the total economic benefit for usage flows to the application owner.

Blockchain can moderate that imbalance.

Dapps utilize native tokens which allow users to purchase services and – if the service is popular – benefit from the increasing value of the token. In a public blockchain, tokens can be used to purchases a variety of services (e.g., storing data, playing a game, etc.). Token holders will be able to buy more services as the value of their purchased token go up.

Tokens also can be fungible and can be used across dapps in exchange for other types of services.

4. Proprietary Networks Versus Blockchain Open Source
Open-source technology projects have resulted in enormous improvements by providing bug-free software, raising tech performance, facilitating interoperability and reducing the total ownership cost of technology development.

Leading companies might have Apache servers running on a Linux operating system and utilizing databases that use PostgreSQL (which our relational blockchain platform, Postchain, utilizes). At the same time, few businesses have truly thrived on 100 percent open-source platforms. But, blockchain presents developers a potentially lower cost, resilient, highly-available platform more likely to achieve success.

Blockchain isn’t enterprise software by a different name. The technical architecture, data ownership model, and economics are fundamentally different.

Similar to emergence of the internet economy, the transition to an internet of value will not be a straight line. Success will come for those not reliant on some perfect ideal of the blockchain, but those who are able to design into systems the right sets of trade-offs which balance the needs of users, developers, and service providers.

Source: https://www.coindesk.com/a-middle-way-forward-for-blockchain