Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” colleagues in mind. The ramp-up recommendations are based on my free-flow learning path, chronicled in the second part of this article. Use this as a guide to get started now, or bookmark and explore additional topics as blockchain conversations emerge with our clients.

Like many of you in the enterprise software development and integration business I filed away the concept of blockchain as either an R&D topic or associated it with dark web. An occasional curiosity was satisfied with a feed from headlines about the Silk Road and Mt.Gox Exchange.

I don’t remember the specific catalyst that got me hooked. Perhaps it was the trip to New York to see my friend’s initial buildout of the data science and cryptocurrency mining operation. Or perhaps it was the Microsoft Day at Booz Allen in May where they affirmed Microsoft ♥ Linux and demoed a 7 minute blockchain setup in Azure. As I learned, I shifted my focus on the Ethereum blockchain ecosystem and started viewing our world through a blockchain lens with the “what if?” and “why not?” questions. If you’re not convinced that this is the new Internet, read chapter 3 in The Industries of the Future.

The blockchain hype is in a bubble. The only profitable blockchain business, so far, are the cryptocurrency exchanges. But the paradigm is here to stay. The blockchain technology represents a form of scientific breakthrough that addresses the problem of trust between two parties without involving a middle man. I see two immediate impacts for enterprise software. For the brownfield development, it’s the integration of Web 2.0 and legacy systems with blockchain distributed ledgers and applications (dApps). For the greenfield development, it’s a shift to a new architectural paradigm to achieve security and privacy requirements through decentralized data storage and transaction handling.

Cryptocurrencies are just the initial use case for the blockchain paradigm. The real power is in the smart contracts that facilitate trusted and binding transactions between two or more parties without an intermediary. Imagine going through this house purchase settlement process without third parties.

Your Learning Path

If you are starting from zero, consider relating the blockchain paradigm to concepts you understand. In essence, a blockchain is a decentralized database. Start with this Forbes “Unchained” episode hosted by Laura Shin. The episode’s guests, Amanda Gutterman (ConsenSys) and Jamie Smith (Bitfury), are professional communicators and explain key concepts in simple terms. Examples: think of a blockchain as a railroad track between two points. A blockchain token is a rail car carrying whatever goods you put on it. Another: think of blockchain security as storing fragments of your valuables in thousands of houses in your community. For a thief to steal your assets he would need to break into all the houses to collect all the pieces.

The Tim Ferris’ podcast with Nick Szabo, who, by the way, coined the term “Smart Contract”, does an excellent job neatly compartmentalizing and relating key blockchain concepts. The episode targets non-technical, but intellectually curious audience, and covers a lot of ground including Bitcoin, cryptocurrencies, Ethereum and how it’s different from the Bitcoin, Initial Coin Offerings (ICOs), etc. This is a “must listen” for everyone.

I highly recommend “Digital Gold” by Nathaniel Popper — the New York Times technology reporter. The book is riveting. Nathaniel tells a compelling story of the Bitcoin birth driven by a small group of cypherpunks. The transitions are smooth, and you get just the right level of detail to feel the sense of hope, danger, excitement, adventure, and technological breakthrough. I hear a newer book, “The Internet of Money”, by Andreas Antonopoulos, may be a good follow-up.

As a compliment to “Digital Gold” consider Netflix’s documentary “Banking on Bitcoin” (trailer). The story feels a bit choppy, almost as if the film was put together in haste, therefore I don’t recommend this as a starting point. The movie does a good job portraying the emotions of the Bitcoin pioneers and the agony of the early adopters.

The Bitcoin and Ethereum ecosystems, out of the box, offer limited value to the enterprise customers: the transactions on public blockchains are visible to all, plus the performance characteristics are not suitable. Enterprise customers need the ability to run private or hybrid blockchain solutions by establishing computational nodes within some trusted consortium shielded from public. I briefly examined Hyperledger Fabric (trailer) and sunk my teeth into the Quorum (trailer) open source enterprise blockchain solutions. For Quorum I recommend this deck as an overview and reading through the project Wiki. The exciting development in the Quorum implementation is the integration of a Zero Knowledge Security Layer (ZSL) initially used at scale by Zcash. The ZSL allows for a trusted transaction to take place, without a third party, while removing information (not just encrypting) about the sender, receiver, and the transaction amount. This reads like science fiction, and it’s eloquently explained here. I highly recommend this podcast with the CTO of Zcash, Nathan Wilcox, to understand how transactions can be verified without publicizing information using a zero-knowledge proof zk-SNARK.

This concludes the non-technical part of this post. If you have a technical thread in you, please read on. This is where it gets interesting. If you’re taking off, thanks for reading, high-five, and follow me on Twitter (iFirebrand) for updates.

A Bit More Technical

To really understand the guts of the blockchain protocols you need to read and understand the Bitcoin white paper and Ethereum white / yellow papers. This is not for everyone. Preethi Kasireddy digested the Ethereum white and yellow papers, along with some code, and wrote an outstanding piece on how Ethereum works. Read it, use it, then read it again.

Knowing is not enough; we must apply. Willing is not enough; we must do. — Johann Wolfgang von Goethe

To understand blockchains you must tinker and put theory to practice. This means setting up your own private blockchains using various clients that implement the Ethereum protocol (e.g., Parity, geth), playing around with various development environments (e.g., Ethereum Studio, Remix), exploring tools (e.g., Metamask, TestRPC), wallets, and frameworks (e.g., Truffle, web3.js), creating and publishing your own smart contracts (e.g., in Solidity), and exploring the distributed applications (dApps) ecosystem (e.g., distributed DNS: ENS, distributed storage: Swarm).

To start learning with training wheels I recommend the Ethereum Blockchain Developer course on Udemy. I took it and learned enough to gain solid footing for further solo exploration. You can power through at 1.5x speed for hands-on exercises and 2x speed for lectures. At first I gave the course 2.5 stars due to some rough edges, but after seeing two other courses I reverted my rating to 4.5 stars. The course is already dated (e.g., the Truffle framework now has a debugger, integrated TestRPC, the Mist client is now called Ethereum Wallet, etc.). However, the fundamentals are still intact and will prepare you well for the tutorials.

Smart contracts facilitate transactions between parties. A classic analogy is a vending machine. Your money deposit is verified against a selection, a change is returned, and a product is dispensed. Sending a Bitcoin from person A to B is an example of a very simple smart contract. The official Ethereum tutorials are a good place to feel more complex code and tinker with smart contracts. I recommend these once you review the The Hitchhiker’s Guide to Smart Contracts in Ethereum by Manuel Araoz and learn how to interact with a test (e.g,. Ropsten network) or a private blockchain. In the first two tutorials you will create your own cryptocurrency and a contract for crowdfunding. When you’re ready to integrate smart contracts with web apps consider this “building your first dApp” tutorial. This is enough to get you started. Use this guide to help you along the way. Next, is the narrative of how I drank from a firehose.

My Learning Path

The initial flow of knowledge came from podcasts, newsletters, Flipboard blockchain keywords, some Reddit, Twitter (handles below), Hacker News, StackExchange boards, Quartz obsession, Meetup Groups, Booz Allen internal events, and 1:1 conversations with folks in the field. For about a week I got into cryptocurrency mining. Mining is the process for securing a blockchain by computing and “sealing” blocks containing the transactions. Without specialized hardware (ASICs) there was no chance for me to earn any rewards (i.e., Bitcoin, Ether) for my mining contribution (unlike these guys). In the process I downloaded and ran a full Bitcoin node, played with various mining software and contributed to mining pools for various currencies. Try this if you want to see how much heat your computer can generate when running at max capacity. These guys in Siberia warm their cottage with heat from their mining operation. As a side note, most major blockchains currently use a proof-of-work method to seal the blocks of transactions. Running proof-of-work is computationally intensive and generates lots of heat. The industry is shifting to energy efficient consensus methods for verifying transactions (e.g., proof-of-stake or proof-of-trust).

I plowed through a number of YouTube videos. There are many explanations of blockchains, lots of pitches of get rich, but I found interviews with Vitalik Buterin helpful — especially on the more advanced topics such as Zero Knowledge Proofs.

The Udemy course I mentioned earlier helped me learn the basics of blockchain operations and deploying smart contracts on Ethereum. I started writing simple smart contracts using Solidity programming language. Solidity is somewhat based on JavaScript with many key differences (e.g., Solidity is statically typed) to enable it run on the Ethereum Virtual Machine. Last time I used JavaScript proficiently was between 1997 and 2000. This JavaScript Course helped me get up to speed quickly and understand the difference between Solidity and JavaScript. I also picked-up important language nuances, such as using promises to neatly handle failures in asynchronous operations. Along the way I stumbled upon a few great software engineering posts, such as Practical Functional Programming by Steven Heidel.

I initially used Remix IDE to write and experiment with contracts. Remix provides a Javascript Virtual Machine in browser or you can attach to an existing blockchain process via an Ethereum JavaScript API provider (web3.js). I deployed and tested smart contracts using a local geth (Ethereum) node and deployed via Mist (Ethereum Wallet). Using a client with a UI to deploy and call contract methods helped me visualize the flow. I incorporated command line deployments and executions later. For some tasks I started using TestRPC that simulates running a blockchain node without actually mining the blocks. Then I moved on to integrate the smart contract actions and responses into web pages using web3.js library with the Metamask add-on for Chrome. Metamask intercepts Ethereum “traffic” and enables you to interact with a blockchain (local or external) without actually running an Ethereum node. Along the way I discovered the Truffle Framework: a self-described “ethereum swiss-army knife”. The development framework contains an abstraction layer to facilitate interaction with a blockchain. It now has a (text based) transaction debugger, and the team just released a pretty sweet personal blockchain framework: Ganache. The Truffle framework has a set of “boxes”, when unpacked upon project initiation, they create a project structure with properly positioned development components (e.g., Webpack, React, Angular, etc.). This enables you to focus on writing blockchain related code. As an FYI, unpacking boxes overwrites all files in the target directory, so git commit often.

As you deepen your understanding of the blockchains you will inevitably start looking at the various implementations of the blockchain protocols. Protocol specifications are often documented in white and yellow papers and have a healthy doze of math. To get through some of these I had to pull out my books from grad school and refresh my knowledge on set theory, set operations, formal specification and formal logic, proofs, and the Turing machine (e.g., Ethereum is a distributed Turing-complete Machine). Thank you MSE/MSIT-SE at Carnegie Mellon for this core knowledge. As I was diving deep into the zk-SNARKs for Ethereum and for Quorum I had to rely on math to get the gist of this, this, and this.

Upon a recommendation from a friend I dove into researching the J.P. Morgan’s permissioned implementation of Ethereum. This is a good example of a blockchain implementation suitable for enterprise customers that need transaction and contract privacy. The diagram is from this page on the Quorum wiki. The essence of the architecture is a separation of private contracts and public ledger visible to all consortium participants. The contracts are only visible to the parties participating in a transaction. The Quorum nodes contain blocks with transactions visible to all consortium particiapnts, but the contract’s state is encrypted with Enclave security mechanism and stored as a hash on the blockchain. Only parties privy to a transaction can decrypt the hash and take action on a transaction state. There is a proof of concept implementation underway to incorporate zk-SNARKs to completely shield transactions and address the double spend problem, which is currently mitigated at the application level instead of the protocol level.

If you get into this space I recommend building something to accelerate your learning process. In my case I’m building a dApp to faciliate peer-to-peer borrowing. This applies to any item that can be digitalized, but let’s imagine I have a set of children's books in Ukrainian that I’m willing to loan to other parents. A book owner establishes a smart contract with a borrower using an app. The borrower puts up a collateral and a fee for borrowing a book for a set period of time. The borrower can then return the book and get the collateral back, or transfer the responsibility for the book to another parent. When this transaction takes place, the original borrower gets their collateral back, plus gets paid a finder’s fee. The new borrower assumes the responsibility for the book by putting up the collateral and paying two fees: the borrower’s fee to the book owner and the finder’s fee. The cycle continues until the book is returned to the owner (and collateral is paid back to the last borrower) or there is an exception in the contract and the collateral is paid to the book owner. I recommend initial solo solutions with this level of complexity to get comfortable with writing and debugging Solidity contracts. The diagram above represents the state machine of the solution.

As a solutions architect in the distributed systems space the blockchain design patterns interest me. This page for dApp design lists considerations and different design approaches. Here is a deck on some of the patterns and the associated talk (from DevCon One).

I also recommend buying some cryptocurrency just to experience the process. Figuring out how to use wallets and how to conduct transactions will be a lifeskill you will have to teach the younger generation. Or wait couple of years and they will teach you. It can be Bitcoin or anything else. I used Gemini.

Along my learning journey I was plummeted by ads for various Initial Coin Offerings (ICOs). That bubble is going to burst and lots of people will lose money. Sound investment advice: if you don’t understand it, don’t invest. Otherwise you’ll end up HODLING something that has zero value.

Where to go next?

This is a rapidly evolving field. The blockchains are frequently splitting (i.e., forking) into sometimes incompatible branches to accommodate anticipated growing pains (e.g., to process transactions faster) or unanticipated forks (e.g., when a major cryptocurrency heist or a hack occurs). The development tools evolve quickly and and even the terminology changes. For example, in a more recent Ethereum release the built-in function to remove a contract from the blockchain was renamed from suicide to self-destruct.

This post has a good source of additional links to follow and explore. I will modify the post to add additional sources. For now, I recommend the following Twitter accounts:

@NickSzabo4 | @bchaininsider | @lopp | @twobitidiot | @iam_preethi | @ethereumJoseph | @iFirebrand

If you enjoyed reading, I would appreciate a set of “high fives” 👏🏼 to help others find this article. Thanks for your time.