In this lesson, we want to get you thinking about the kinds of business problems that are best solved with blockchain. For all the hype around blockchain technology, it can't do everything and it shouldn't. But for the things it does well, it's unprecedented. Twenty-five years ago, the idea that you could have a functioning cache system operating on a peer-to-peer network without any central authority or government backing, and created entirely electronically and without real-world assets would seem the stuff of futurist fiction. Yet, this is where we are now. Here is a decision tree that includes the kinds of questions you should ask when trying to determine whether you should be using a blockchain at all. If you should, what kind of blockchain you should be using, whether that's public, shared or consortium, or private. If you finish this course with a clear understanding of this decision tree, then this course has been a success. Let's say, you're an executive and you're trying to determine if a blockchain is the right solution for a project that you have. The first question to ask about your project is, do you need a database? If you don't need a database at all, you don't need a blockchain. BitTorrent, for example, is a peer-to-peer file sharing system that doesn't have a database, so it wouldn't need a blockchain. Next ask, do you require shared right access? The role of blockchain is to spread the authority to write amongst a group without any one group controlling access. If you don't need to share this access with multiple people or groups, you don't need a blockchain. For example, if your organization wants to collect traffic information and sell it, you don't have to have multiple groups that write to the database, so you don't need a blockchain. At this point so far, you have separate parties and you want to write to a database. So ask, "Are any of the parties unknown or untrusted? Or if they're trusted, is it possible for them to have conflicting interests?" On the Bitcoin blockchain, people have conflicting interests because they stand to gain from an invalid transaction that works in their favor. So, if you know and trust all the parties and you know that everyone's interests are unified, then you don't need a blockchain. For example, suppose three water companies want to maintain a shared database of pollution levels across various sources. They all trust each other and all their interests are unified, they probably don't need a blockchain. But if all parties aren't known or trusted, or they are but have potentially conflicting interests, consider if you could rely on a third party to control the database, or audit it. If that's possible, you don't need a blockchain. For example, three competing furniture resellers agree to a shared database of suppliers. However, they are all able to trust a third party to manage the database. This third party is an intermediary but they all trust it, so they don't need a blockchain. But if you can't trust an intermediary, after all of that, you're finally ready to start talking blockchains. To recap, we have a business problem or project that needs a database, requires shared access amongst parties that may not be known or trusted or may have competing interests, and it's not practical or possible for a third party to be trusted to manage the database. Great. Now, there are a few more questions to ask. Do you want to control access and functionality and will just one party verify information without consensus internally in a high trust environment? If so, a private permission blockchain will work. That's a blockchain operated by you and your organization. This is really just a distributed ledger and it's not very blockchainy. If you want to control functionality but consensus must be reached by multiple parties, that is other entities will be verifying, writing, and auditing data on the blockchain along with you, then a shared or consortium, or shared permission blockchain is what you want to use. In this case, a group of possibly competing entities share access and use of a blockchain database. If you don't want transactions to be publicly viewable, you'll need a non-private blockchain of some kind, whether that's private or consortium. Last but not least, the public blockchain. In this one, you don't control functionality, and all transactions are public. Anyone can join it and use it. However, it's ready-made. So, if you wanted to, say, build an app that needs a blockchain, public blockchains are waiting for you. You could also create your own public blockchain to fulfill a specific need. But being public, you're dealing with unknown and untrusted entities writing to the block chain, so great care must be taken to ensure a robust set of consensus mechanisms are in place to keep the blockchain secure. By thinking about problems in this way and thinking about the decisions here, you can start to get a feel for whether or not a blockchain makes sense as the solution to a business problem. Feel free to refer back to this lesson when you consider case studies, problems, or business models that may or may not best benefit from a blockchain.
