Insights

News

Is Decentralized DLT Necessary for your Business?

By Russell Harvey

We often see companies run into DLT development problems due to a mismatch between business needs and a desire to create a fully decentralized application (“dapp”). Enthusiasts often champion a decentralized approach to integrating DLT because the vision of a world without intermediaries and middlemen is exciting, and popular platforms, such as Ethereum, tout this vision. As a result, tech teams internalize this thinking as an assumed industry standard, and begin designing accordingly.

Today, we’ll discuss the thought process that a CEO, CTO, and development team walk through when creating an example decentralized system, and then present an alternative approach.

CEO View: The business

There’s a gap between video content that is freely distributed and attempts to monetize by showing ads, and funded content which is paid for up-front based on projected value. We can create a marketplace which will allow consumers to pay a la carte for ad-free content, and have the creators get paid on a per-view basis. Everything will be controlled by smart contracts, we’ll drive the whole system with a utility token, and we’ll take a piece of every sale. Our logic will be out in the open for everyone to see, so our customers will have confidence that the system is behaving correctly.

A compelling concept. Rather than build a monolithic, old-fashioned system where the company runs and is responsible for the entire platform, let’s let the free market do a little work through the efficiencies of blockchain! The token makes for a nice fund-raising mechanism, too.

Development Team View: The proposed system design

A completely decentralized application.

Creators push content to a peer-to-peer distributed file store and set a price for consumption.

The business owns a large stock of utility tokens at the outset, with the intent to sell them directly to consumers and/or on exchanges.

Standards will be created to allow third-party contributors to develop new tools that fit into the ecosystem.

Sounds reasonable. Somebody creates a video, somebody else pays to see it, with a small fee to the company that made it all possible. Everyone can transact anonymously, nothing can be censored, and nobody can shut it down as long as there’s at least one exchange to provide an entrance and exit point. The future is now!

To bring the imagined system to life, the team picks their DLT platform of choice, gets to work, and builds the perfect decentralized pipeline. Integration tests successfully demonstrate that content can be pushed and notarized, tokens can be paid to access the content, and a percentage of those tokens automatically gets shunted to an account the business controls. All is well.

Well, there is one little problem. We’re going to need some initial content on the system, so we’ll need to incentivize creation early on. We could try paying our initial creators directly in utility tokens, in hopes that they will see them as something that will be valuable later on, but they’ll probably want some cash.

We’re going to have to go through some rigor to identify who we’re paying, what regulations apply, and who we have to declare to. That’ll have to be stored somewhere. Putting personally identifiable information on a public ledger is certainly not appropriate, so we’ll need to maintain a database and set something in front of it so our smart contracts can interact with it. We’re not really compromising on our vision of a fully decentralized application, because we can do away with it once the system is self-sustaining and there’s no more need to directly incentivize creation.

Problems solved: initial content creation

Resulting additional development demands:

Payment transactions for content creation

Identification database

Connection between identification database and smart contracts

2. Client Tools: How will users interact with the system?

We’ve built our system to be easy to develop against, but we’re going to need to provide that initial set of client tools — something to invisibly handle the ledger interactions and make it easy to create and consume content. Releasing a bunch of native user clients to several different platforms doesn’t sound like fun, so let’s do it all on the web. Let’s hope whatever DLT platform we chose has a nice way of handling the wallet integration, because we’re sunk without that.

Hmm, we’re going to need a way to search content and build in mechanisms for the system to perform some automatic curation. Let’s allow users to tag and rate things; we’ll add this metadata to new blocks on the ledger as the votes and tags come in. Hang on, pulling all this is going to get pretty slow as the history grows. We’ll need a cache of some kind for search to be even remotely performant. We can build that into the backend for our initial client tool, and we’ll have to architect that to be horizontally scalable for when we get popular.

Creators using the client should be able to make profiles for themselves so they can advertise what their content is about, and we’ll have to keep that all off-ledger so that we don’t fall afoul of GDPR and right to erasure. Say, this is beginning to sound like a traditional application, but we’ll have to live with that. It’s only the web client; we haven’t compromised our vision of a decentralized platform.

Problems solved: client interfaces, searchable content, user profiles

Resulting additional development demands:

Web-based client tools

Wallet integration

Tags and ratings as metadata on new blocks

Cache for search

Profile database

Connection between profile database and ledger

3. Access: How do we maintain control without centralization?

The economy only works if we can prevent people from accessing content without paying for it. We can’t just provide an address to a file on the P2P file store, because then that address can be easily shared. Encrypting it at upload time isn’t much better, since the decryption key will have to be distributed. Maybe we could keep control of the decryption key and decrypt and stream the results. Problem is, now we need this central controlling piece in the middle, which goes against our vision. Let’s table this problem for now, because a copyright owner has just come knocking, claiming an unauthorized copy of their work has appeared on the network.

Well, this is problematic. We don’t have any means of taking down the content, nor should we have to care. Why are they coming to us? We just build the roads; we don’t control what people choose to drive on them. Seems their lawyers don’t see it that way, and now we’re going to have to mount a defense. Yikes, even if we ultimately win, we can’t sustain these legal bills. The platform may live on, but the company is doomed.

Problems solved: none

Resulting additional development demands:

Unaddressed need to selectively grant access without a central authority

Assessing the Actual Business Needs

Why was full decentralization seen as necessary and justified? It felt like an elegant way of doing things, initially seemed that it would save on hosting costs, but mainly it was done to establish user confidence that the system was behaving exactly as promised.

Reframing the Problem: A trustworthy system

The new business wants creators to be confident that their work will be faithfully represented to consumers, and that consumption will be unbreakably tied to payment. So the real problem is making sure that the system is trustworthy, and is seen as such by its users. Is there a way to solve this other than full decentralization?

A New Solution: Targeted DLT use

A publicly auditable record of system transactions should go a long way toward establishing trust. Here’s a practical approach that limits DLT usage and forgoes the need for smart contract development:

Content uploaded by creators is sent to a distributed file system with access controlled by the company.

At upload time, characteristics about the content are notarized on a public ledger.

Content metadata (user tags, ratings, etc.) is stored in a database, where it can be easily updated and queried.

Content purchasing is done via public transfer of utility tokens. The user client handles the split of sending the appropriate amount to the creator’s address and to the fee-collecting address.

A listener operated by the company monitors the ledger. When it notes a valid purchase, it generates a unique access key for the content on the DFS it resides on. It then writes the key and any other necessary access details as an encrypted message on the ledger, which only the purchaser is able to decrypt. The key can have a timed duration, if appropriate.

The user client reads the ledger for access information, and purchased content can be accessed securely.

Here, content creators have a clear, publicly auditable log of the number of times their content was accessed, and all the associated payments. Sure, you could have secretly distributed their content for some kind of off-ledger payment and failed to log it, but that’s a pretty elaborate ruse to maintain. The secret payment system would have to be sufficiently well-known that consumers can find out about this alternative and use it, while all the creators remain in the dark. So you’d have to be both extremely clever and thoroughly nefarious to pull it off.

Some other benefits of this approach:

You have completely avoided the expense and risk of engaging in the nascent art of large-scale smart contract development.

Keeping control of the system the content resides on allows the company to retain control of who can access it. Specific access keys or entire pieces of content can be disabled at will, whether because the consumer has been deemed to be a bad actor, or because a copyright claim has been issued and an investigation has to be conducted.

Your data cache and search service can now be treated as official first-party offerings, and advertised as appealing capabilities to anyone wanting to build additional tools within your system.

Creating a Practical System

Let the business requirements drive the technology. Don’t let pursuit of a theoretically elegant solution take precedence over your actual needs.

Make as much of your system as traditional as possible. Instead of asking “How can I address this problem with DLT?” ask, “Why should I use DLT for this problem?” Use it only where the benefits are clear and necessary.

When smart contracts are the most appropriate solution, keep them simple. Start with smart contracts that are small and straightforward to reduce overall risk and raise your likelihood of success.

Know that DLT is a great tool for accounting and auditable record keeping. Your needs can often be met with an entirely private ledger, exposed only to the applications and people that have a need to view them.

The lure of a fully decentralized application is a strong one. The idea of building a platform and community that can be self-sustaining feels great, can (in theory) be trusted, and certainly can generate some good PR. But before going down that route, take a hard look at whether you’re choosing it because the needs of the business truly demand it. As we saw in the scenario above, upholding a fully decentralized application’s altruistic intentions can result in a growing list of development demands that may ultimately contradict each other.