Blockchain, in most implementations, helps by decentralizing state management. It’s a database where no single entity is in control of the data. In theory. Once the data is in the blockchain it is immutable. In theory. It can’t be changed even if you wanted to, in theory. In reality certain blockchain implementations have rewritten history, which is quite disturbing).
What They Won’t Tell You About Blockchain
There are plenty of resources on the web regarding what Blockchain is. Instead of me rehashing those, let me tell you what blockchain is NOT. I want to make you take pause before jumping headfirst into the blockchain pool.
Blockchain is a 10 year old (as of 2018) technology that still doesn’t have a killer application that depends on a distributed ledger that anyone uses regularly or has a mission-critical purpose for any business. Is this a solution in search of a problem?
the implementation is often a cryptocurrency touted as a replacement for local currencies (bitcoin). This is viewed by cryptocurrency fanbois as a way to challenge governments and “authorities”. But, if you are a country with a weak currency, where is your impetus to have a competing currency? Will the government accept payment in your cryptocurrency? The point is, many use cases for blockchain that I see are businesses trying to circumvent local regulations or laws. That’s always a losing proposition.
the biggest business in the cryptocurrency space right now is coinbase. If you understand coinbase then you understand that this use case is the antithesis of what Satoshi wanted in his eponymous whitepaper, laying out decentralized ledger architecture. Coinbase is the modern version of a bank. It charges you fees that are astronomically higher than your bank. Does that sound like it is true-to-purpose? Does that sound revolutionary?
Ask yourself why you want to be a “blockchain company”? Is it because you want to revolutionize your industry and solve a nagging business problem? Or do you just want to jump on the speculative bandwagon? I make no value judgments. I’m here to solve problems for you. But, companies need to be honest with themselves before they undertake a leading-edge journey such as blockchain. Said differently…if you look around you’ll see companies RIGHT NOW making obscene amounts of money on blockchain. Have those companies created killer apps and value, or do you think it is more that they are cashing in on the current speculative fervor?
Well, that was depressing. With all THAT out of the way,
Why would a company ever want to embark on a distributed ledger journey?
the distributed ledger has the potential to be a store of value for the right use cases. “Distributed state management” is a really good technology and it will have staying power.
Blockchain is so YUGE that every company SHOULD experiment with the concepts. Even if your company has no KILLER APP for distributed ledger it is arguably valuable to undertake a small project to at least understand the technology and institutionalize its power. It’s conceivable that your business partners will want to transact business with you using blockchain and you will want to have some experience under your belt.
Don’t believe me? Five-ish years ago companies had no desire to use the public cloud. I heard this a lot: “I just built a new data center and I’m beginning a presence in a colo in another hemisphere. I don’t need cloud.” Now I hear: “We need to be a cloud company…NOW”. Why now? I dunno. But that’s what I hear. Companies want to be on the bandwagon I guess. Meanwhile, companies that have embraced the cloud realize they are far more agile and time-to-market has improved radically. The mantra for years was DevOps. Now with the advent of serverless architecture I’m starting to hear the term NoOps more and more. (BTW, I wrote about the NoOps Movement way back in 2014). It behooves you to start a small blockchain project.
blockchain makes you think differently about your development problems. More on this later, but blockchain development…even the management of blockchain projects…is radically different than anything you’ve ever done.
This isn’t a joke. If a crypto currency becomes too successful in the real world it becomes unusable. Blockchain does not scale. During the holiday seasons it is estimated that Visa and Mastercard are doing 10M transactions/sec. Based on architecture decisions at most bitcoin/blockchain can support around 10K transaction per 10 minutes. This means that, as designed, there are built-in scalability constraints that will limit blockchain (specifically bitcoin) from being as ubiquitous as credit card transactions, as of right now.
More importantly you really need to understand what are good use cases for blockchain and what are not good use cases. It is your duty to tell your project sponsor when his blockchain use case is bunk and his system would be better expressed using a simple database or peer-to-peer network. There are architectural limitations to blockchain deployments (see above). It’s a distributed ledger after all, which means that to make it “distributed” the designers needed to make tradeoffs, such as concurrency, latency, and volume. Nothing “distributed” will be able to handle the sheer volumes of data that a relational database can handle. Don’t believe me? Does that sound like it flies in the face of the CAP Theorem? It’s true, see previous paragraph.
You need to understand the fundamental architecture. When your CMO says: “We want to devise our own CRM system and use blockchain as the backing store”…you want to be prepared to NOT laugh in her face and be able to explain why that won’t work.
When a client engages me or my company to help them with their blockchain project I like to have some frank and honest conversations:
Do you understand the business problem you are trying to solve backwards and forewards? I mean REALLY understand it. You need to understand your business problem before you can know if a distributed application will even work.
What makes “blockchain” your implementation choice over some other, established technology? There are some good uses for blockchain that I’ll discuss below.
Let’s be honest: some companies want to be blockchain companies. Have you seen the stock of RIOT when it announced it wasn’t making sugary drinks and was concentrating on blockchain technologies? Or even overstock.com? It’s stock price went to the moon when it decided to focus on blockchain. Or how about Long Blockchain?
There’s nothing wrong with being a “blockchain company”, per se, but you should be honest with yourself. Be ready for:
problems of scale
too many more items to list
If you aren’t too hung up on being “a blockchain company” then you should seriously consider using an established technology to handle transaction persistence. That’s generally
a relational database or some other established datastore (NoSQL, etc)
if you need something truly distributed, think about using a P2P network (think: thepiratebay or bittorrent). These networks aren’t meant solely for pirating movies. They tend to scale very well and provide privacy and decentralization, hence why they are used for nefarious purposes.
be prepared for unforeseen costs. I’ve seen blockchain solutions being touted as cheaper than using a dedicated database or an existing process. If you hear that, ask for proof of that assertion. How much does it cost you today to use the ACH network for transfering money? It’s free right? How much does it cost to transact in bitcoin? A LOT. Blockchain is not cheap. Someone is paying for all of the backing infrastructure.
Until the legal/contractual questions are answered I would steer clear of use cases where participants in the implementation may want to challenge the validity of the “smart contract”. Instead, I like to focus on use cases where the business problem involves “reputational risk”. In other words, a participant will want to “behave” in a system where, if they don’t, there is not necessarily legal recourse, but rather their reputation could be harmed within the group.
Think about artists that want to showcase their previous works but have a hard time proving they actually created the work. For a small “blockchain tax” a smart contract can be created where payment is made after a jpg of the work is uploaded to the blockchain with a comment from the purchaser on the quality of the work. There is nothing contractually-binding but both parties have a vested interest in their reputations. Uber works similarly in that the driver rates the consumer and the consumer rates the driver.
There are so many certifications and licenses in the world. In some cases a certification may not initially have an expiry (think MCSE certs) and then the certification authority may later say there is an expiration date. It would be nice to be able to track all of that in one location. Could a database application work just as well? Possibly. But “Certification-Blockchain-as-a-Service” could be a subscription service for the certification authority and for the certified entity. This could be clearinghouse service beneficial for everyone. This could be embedded directly into ethereum as a form of Smart Contract. Depending on the specifics of how a company would want to solve this, the implementation could vary.
There is nothing truly revolutionary here. There is no “legal” problem being solved. Again, this is a reputational risk solution.
How do you confirm, quickly, if a job candidate’s resume is truthful? When was the last time you actually verified employment dates and positions of a candidate? Could you even do it if you wanted to? Imagine a resume blockchain where employers, dates, and positions could be written by the candidate and confirmed by the employer? Everyone has a vested interest in keeping it accurate, which can be done for a small fee.
LinkedIn has done a lot of solve this. It’s difficult for a job candidate to lie on LinkedIn when it is open to the whole world. Lying ruins reputations. But LinkedIn has, so far, only gone just far enough. For a small fee LinkedIn could certify this information for you. But folks are hesitant to give even more of their personal information to Microsoft (who owns LinkedIn).
Determine the functional MVP (Minimum Viable Product). Ensure the MVP can fit into just a few months’ implementation. You definitely want to fail-fast on blockchain projects. These are the highest-risk IT projects today.
Develop the MVP with frequent, honest feedback to project sponsors. If you are having implementation issues, be honest.
Attend standups and communicate with your developers. If they appear to be blocked on sticky problems it can quickly cost you time and money. Consider getting help quickly.
Allow your developers plenty of time to learn the underlying technology. Even if you hire “experienced” blockchain programmers, they will need extra time to solve issues that could be solved much more easily in a traditional AppDev environment. Developers who learned during the “client server” era struggled for years becoming “web developers”. Trust me that “distributed blockchain computing” is a paradigm shift. Programmers will want to fallback to old, trusted behaviors. They will need time to refactor code later as they learn and fail.
Don’t try to build the infrastructure yourself. Blockchain requires a lot of horsepower, and it needs to be distributed. Consider initially using a Blockchain-as-a-Service provider (see next section). I prefer Azure blockchain. You don’t need to stick with this infrastructure vendor forever, but you don’t want “infrastructure” to be on your critical path. Outsouce it. There is NO BETTER USE CASE for cloud, right now, than burgeoning blockchain implementations. Leverage the cloud.
Consider using Hyperledger or another OSS blockchain implementation to get started. The benefit is better documentation and crowdsourced “best practices” that you can leverage immediately.
If your developers want to use Java or C/C++ or another common language they are familiar with…well…reconsider. It is certainly possibly to implement blockchain in any programming language. You could also write your own version of Microsoft Word in powershell too, right? But is that smart? Ethereum has a great OSS toolset, plenty of community support, and it has its own programming language that you should likely use (Solidity)
I generally preach iterative releases and MVPs. This is very difficult to do in a distributed application.
Bug fixing is very hard when every peer in the network has to update their node software.
This probably seems contradictory to what I said about MVPs in the last section. Those MVPs need to be internal, proof-of-concept, functional releases. Is the application going to meet the functional requirements? But, unlike an Android app, you can’t just release a half-baked blockchain application to the world. As I said, it’s really hard to refactor a distributed application if you need to rewrite the distributed ledger. Internal MVPs can be redeployed and the blockchain can be “genesis’d” without you losing your reputation.
user identify (aka KYC or “Know Your Customer”) is difficult since no central authority is available. This is especially true during testing and development cycles. Don’t roll-your-own solution.
You can’t just implement your base idea and then later add more features and deal with scalability.
You can’t use third party, centralized APIs to offload some of the feature support you need. If you do you’ve essentially broken your distributed application. To practice true “microservices” concepts you need to build your microservices so they are also distributed.
At least initially, consider leveraging the public cloud for your Proof-of-Concept. You don’t want to waste time-to-market provisioning infrastructure and dealing with Operations issues.
I prefer Azure’s blockchain-as-a-service (BCaaS) but it isn’t the only solution. Azure’s implementation can be public, private, or permissioned. Some people think that a blockchain running in Azure (or any public cloud) is anathema to being “decentralized”. Not true.
“Decentralization, in blockchain terms, simply means “politically” decentralized. Any computer network is a “centralized community” by definition in that the members behave and organize as a unit. There is nothing wrong with that. It is desired in fact.
Decentralization does exist in public cloud in that you do have fault tolerance. Azure does support permissioning new nodes from outside its cloud. I always preach “hybrid cloud”, which means having a presence in multiple public clouds to avoid issues of vendor lock-in.
Azure’s offering has new features every week. It offers all of the production-ready features you would expect for enterprise scenarios. But, it’s the little, infrastructure features that I really like. Azure will try to automatically recover a node and join it back to the Ethereum network. It also helps you set up your network topology the right way by asking a series of questions and providing you with solid recommendations. Ethereum has a confusing array of topologies, each suited for different applications.
How Can I Help You?
Blockchain is a bleeding edge technology right now. Every company wants to dip a toe into the distributed ledger water. But this tech is radically different than a C# developer learning python. I can help you navigate the waters and assist with design and implementation.