So you are starting a blockchain project...

So you are starting a blockchain project...

You've just been asked by your business to start a blockchain project, how do you begin? Let me tell you how I think about blockchain projects.

Table of Contents

You’ve just been asked to manage a blockchain project. Now what do you do?

This post will also be valuable to developers that need to ramp up quickly on this tech. I will show you how to speak the lingo and focus on what is REALLY important and how blockchain dev is different from any other development you have likely done. Companies are looking for blockchain developers with experience, but it is hard to find those people. But anyone, frankly, can learn it. You just need to understand the principles and engineering decisions around blockchain. And you need to throw out some old habits that will not work with distributed applications.

How I Describe Blockchain to Clients

Blockchain is just a different way to maintain “state”.

In the nascent days of the Internet, web pages were static. If I visited a page at the same time as you we both saw the exact same page. This made it difficult to conduct commerce since “shopping carts” require your “state” to be maintained. Marc Andreesen solved this by creating the first “cookie” which was merely the state of your visit to a site that you stored in your browser cache and passed along with each page request to the site. Soon companies realized that state was better managed in a database on a server they maintained. While this enabled e-commerce, the “centralized database” had far bigger ramifications. Centralized state management spawned entire communities (think Facebook) that were built around storing the “state” of what you like and who you interact with.

Over the years “centralized state management” using platforms like Twitter, Facebook, or even GitHub has taken on some negative connotations. People are hesitant to put even more of their personal lives on these platforms. I don’t use Facebook because I don’t like what they do with some of their user data. Similarly, I avoid putting my personal projects on GitHub, and instead use my personal gitlab server to showcase my work.

I know users are getting annoyed with how Facebook is monetizing their private data…I read their complaints on Facebook everyday.

–Dave Wentzel

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.

Up to table of contents

Blockchain Architectural Tradeoffs

Nobody uses blockchain anymore, it’s too popular.

–Dave Wentzel (heavily influenced by Yogi Berra)

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.

Up to table of contents

Blockchain Conversations

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
    • implementation issues
    • 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.

Up to table of contents

What is the minimum you REALLY need to know about blockchain?

If the following list is complete gibberish to you, then you have some learning to do before you undertake a blockchain project.

Functional Knowledge

  • Really understand what blockchain is.
    • Be able to speak about it from a technical AND business perspective
    • Be able to speak about good use cases and poor use cases.
  • Understand Smart Contracts
    • A smart contract is a set of rules implemented in programming constructs that are capable of automatically enforcing themselves when predefined conditions are met.
    • Be able to give some examples
    • Understand how to write and test smart contracts. More importantly, be able to explain this to a non-technical project sponsor.
  • Understand blockchain’s “problems”
    • Does blockchain have a legal leg to stand on if it is challenged in the courts?
    • Underlying all contracts is the concept of “ownership”. Crypto has no “ownership” as such. There is no “database” ownership claim. It is not a “security” and legally there is nothing underpinning it.
    • This should give any commercial blockchain implementation some pause.

Up to table of contents

Technical Knowledge

  • Foundational understanding of Ethereum
    • As of this writing most businesses that are undertaking blockchain projects are using ethereum.
    • Know it.
    • But be on the constaint lookout for companies and developers shifting to the next implementation.
    • ethereum is VERY difficult to code against.
  • a cursory understanding of Solidity. This is the language backing Ethereum. It is javascript-like, but the programming constructs are still difficult to learn and implement correctly.
  • Smart Contracts
    • development
    • and testing using something like web3.js on testnet vs mainnet
  • understand how to communicate with geth
  • JSON-RPC: internally all communication in Ethereum is JSON-RPC. Every blockchain implementation will have a foundational communication protocol you will need to learn.
  • understand gas and what “requires a lot of gas”. Gas is the “fee” imposed to store data in the blockchain.
    • For instance, storing files in the blockchain requires a lot of gas. Don’t do it unless you need to. If you just need to prove ownership of a file there are better ways to do that.
  • Oraclize familiarity. This is a service that enables a Smart Contract to access data from extra-blockchain sources. Oraclize handles the trust and proof-of-authenticity for you.

Up to table of contents

Good Blockchain Use Cases

Reputational Risk Use Case

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.

Up to table of contents

“Certification” tracking

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.

Up to table of contents

Resume verification service

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).

These are just a few very simplistic use cases.

Up to table of contents

How I run blockchain projects

  • 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)

Up to table of contents

Definitey do NOT do THIS

  • 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.

Up to table of contents

Blockchain-as-a-Service (Leverage the Cloud)

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.

Up to table of contents

Thanks for reading. If you found this interesting please subscribe to my blog.

CONTENT
architecture azure cloud case study

Archive