Background
Blockchain is here to stay and anybody who knows the potential, just do not want to be left out, but want to be an early adopter as well. So there are so many individuals and corporations who tries to build solutions based on Blockchain, but more often these solutions does not comply true values of Blockchain (or Decentralised Ledgers). This article tries to explain, a possible design pattern, which could be used when designing blockchain based solutions for common business problems. In decentralised terminology, design pattern to build truly trust-less solutions. Further this suggest a possible revenue model for trust-less solutions on decentralised ledgers.
Sample business problem
Let’s consider a simple business application so we could apply this design pattern. Consider a simple online market place similar to eBay (simplest possible version of eBay). This system would ideally have 3 actors, namely Sellers, Buyers & Admins (Who manage the market place). Let’s define what each actor would do in this minimalistic version of marketplace.
Sellers: Create a store & put up items to sell
Buyers: Create a profile and buy items offered by seller’s
Admins: Manage the site by authorising sellers, buyers and resolve any disputes and collect commission from transactions
Design with centralised & trust-based mindset
If you ask a general software developer (here I’m referring to a developer who does not use decentralised technologies nor aware of such concepts) to build this solution, following would be classic implementation of this solution.
- Sellers could register with this market place, but admins would have to approve/accept the seller to trade using the platform. Irrespective to approval/acceptance process, admins could kick a seller out of system if they want
- Same as above applies to buyers, admins would have the ultimate control over specific buyer’s existence in the marketplace
- Admins would have access to all sellers and buyers within the system from backend and would be able alter profile attributes if necessary (reset passwords, etc)
- Only way to access list of buyers and sellers (and their items) would be through the market place platform (or APIs provided by the platform)
- Whoever register with this platform (both buyers and sellers) ultimately have to trust the platform admins or the organization behind the platform
So all characteristics above constitutes a controlled, closed system governed by the owners of the platform. And everything rely on how trustworthy the owners of the platform are. So solution is trust based and centralised.
Important fact to remember here is, even using decentralised technologies (such as Smart Contracts and Distributed Ledgers) it is quite possible to implement solutions which needs to trust the owner of the platform and owner could control most aspect of the platform. Unfortunately, most blockchain based business solutions we find have these attributes even though those are implemented on top of decentralised technologies.
Design with decentralised, trust-less mindset
Let’s see how we could make the above solution truly trust-less. In other words, platform owner should not have any control over any of the aspects of the platform. This is where things start to sound weird, but if you closely look at how Bitcoin works, conceptually that’s what we proposing here. Possible way to achieve trust-less design,
- Platform owner should provide a Smart Contract which is a Contract Factory (a smart contract that could create sub contracts) for each actor and entity in the system. Important point here is, platform owner should not have any control over these factory contracts once those are deployed to the network. No backdoors.
- So in our example platform above, there will be two Factory Contracts for Sellers and Buyers each. So, anyone in the network could use these Factory Contracts to create either a seller contract or a buyer contract.
- Once a seller or buyer contract is created, such contract is owned by the creator of the contract not by the platform. So the individual sellers and buyers would own their respective contracts and would have full control over those. Platform owner has nothing to do with these contracts.
- For the selling and buying to be possible, there should be a third contract which define how the buy, sell transactions would work. Again it is important to make this transaction controlling contract (call it TxnController) is self governed. In other words, no one should own TxnController or should not have any control over it [In a trust based world, this would be the heart of the business, but in our trust-less world, platform creator does not own or control it].
In summary, we have built set of smart contracts, which are owned and controlled by relevant actor and another contract which owned and controlled by no one other than the logic written in the contract. This constitute a truly trust-less system. Only elements we trust here are the contract logic and the Virtual Machines (EVM in Ethereum world) which executes it. These are unbiased and autonomous, so can be trusted to do what they have programmed to do.
Important fact to remember here is the openness of the solution we have built. As the platform creator, you might be the first to build a DApp for the platform, but that does not prevent any third party also build a similar or better DApp. This is possible at all levels as each smart contract is available to third parties as much as those are available for the creator.
Possible business model
So we have a feasible way of implementing a decentralised solution in completely trust-less manner. That being true, you might have the question in your mind, why anyone should build this type of a system, if you do not own anything at the end. Usually (in trust based centralised world), the ownership, the ability to control is what you could turn into business model (revenue stream) where you could sustain your business and finally make profits out of it.
While there could be many different ways to make profits even from a trust-less system similar to what we explained above (for instance, in the marketplace example, you could charge a percentage of every transaction in TxController contract and transfer that to your ether account), there is a possible model that could use to make revenue from almost any trust-less system.
Smart contracts begin the core of decentralisation and trust-less design, we could leverage on the Decentralised App (DApp) to make revenue. Even though the smart contracts are completely independent from each other, a DApp you create could provide a single point of entry to deal with all these independent and self governed smart contracts. That would provide the convenience for users to access these self governing smart contracts via a single DApp and as the platform developer you could assure the data integrity (linking and referencing of data stored in smart contracts in a meaningful manner) to its end users. Just reemphasise, at the core, contract logics and stored data do not under anyone’s control and can be accessed by any arbitrary user, but the DApp which wraps these contracts provide a nexus point to deal with these contracts as a single solution platform.
If you are as a reader is still skeptical about the viability of this model, I would like to relate this with a popular revenue model in open source ecosystem.
If you think of Open-Core based solutions which runs profitable businesses, it might shade some lights to prove the viability of this model. There are many solutions have an open source core, which could be used by anyone to build any type of solution on top of it. But at the same time, there are organisations, provide convenience for its users by providing value additions on top of the open-core (Many Apache foundation solutions are supported by commercial ventures which make profits out of that service. ex: ThoughtWorks & Hadoop).
Overview of Smart Contracts
As you could see in above diagram, Factory Contracts (SellerFactory & BuyerFactory) and TxController are self governed (No owner or no one has control over those). DApp provides means to interact with these self governing contracts and optionally could own Registry Smart Contract which could use to store relationships between data stored in independent contracts. As indicated under DApp, there will be functionality to interact with smart contracts in a more integrated manner (similar to any general business application).
Conclusion
If anyone build solutions based on Blockchain (or decentralised ledger technology) it is important to have core concepts of Blockchain being persevered in the implementation. Making core actors and entities related smart contracts self governed is a must to provide true trust-less implementation, but additional application layer (DApp + Smart contracts which are controlled by a authorised party) on top of these independent smart contracts could be a possible way to monetise a true trust-less platform.
This design pattern is more of a thought experiment and PoC level implementation, meaning this is not tested against commercial implementations. I hope there would be many different ideas on how this can be improved and/or other possible approaches to achieve the same goals. Please share your thoughts in comments to explore further about this topic.