There is an overwhelming amount of information and hype about blockchain, which gets outdated really fast as the ecosystem moves at breakneck speed. In this article I detail on my ongoing journey towards becoming a blockchain architect, to the benefit of any others that might want to follow this path.
I’m not afraid of storms, for I’m learning how to sail my ship. — Louisa May Alcott
Who is this article intended for?
This article is intended for people that want to get into blockchain in the heady summer of 2018. With a special emphasis on those that want to get into architecture roles and therefore need an understanding of all moving parts including theory, but that don’t really need a deep knowledge of anything in particular. As an architect you should know how to get the right knowledge from experts when you need it.
For reference I took 84 hours to execute the steps in this article, which is about the required commitment for an AWS Solutions Architect Associate Certification. You can take this as an starting point for your own training, and then go deeper in the topics that your own role demands.
Who is writing this?
My background is that of a specialist in high performance computing for financial companies. Recently I moved countries and found myself with a highly specialized knowledge of a technology stack with zero local demand. The easiest way out was to double down on soft skills working in purely managerial or pre-sales roles. Some guys, however, offered me to abandon my pretensions of having a safe and boring life, and called me aboard the blockchain train.
My initial task would be to train myself in blockchain technologies so that I could later advise developers and business stakeholders — as I did for high performance computing. The expectation was to get there in a couple of months which is quite reasonable nowadays if you are committed.
Needless to say, I got aboard. I got great direction from my new colleagues at TechHQ, and now I’m paying it forward.
Ok, so what should I study then?
Blockchain articles go stale in three months or so, given how fast the field develops, however I still recommend Haseeb Qureshi’s Authoritative Guide to Blockchain Development as a starting point. This article is a true tour de force and was pointed to me by Sergio Pereira as the best way to get started. You could ignore the rest of my article, and just jump on to Haseeb’s, and you would be fine.
If you go on reading (thank you!) I’ll give the 10 steps I followed and an estimation of the time that each one took me.
- Implement a python blockchain: 20 hours. It was a fun exercise and I would say that it is essential to know how a blockchain works at a data structure level if later on you are supposed to understand and apply what makes blockchains different from databases. I just did the data structure and a Proof-of-Work mining process to create blocks. Adding application data to the blockchain was trivial and implementing a consensus algorithm was not needed at this stage.
- Cryptozombies.io: 8 hours. Great intro into Solidity coding and best practices. Very similar to JavaScript, and you might start to have some doubts on whether you would want to code mission critical software with Solidity right now.
- Remix / remixd / git: 4 hours. Remix is a great starting IDE, especially if you plan to stay more in the back end and can’t be bothered with learning javascript. I found it relatively easy to connect remix with a local folder in my laptop so that I could use git.
- Ethereum crowdfund tutorial: 4 hours. At this point I felt I could code unaided in Solidity, even knowing that it wouldn’t be great quality. You will need to read the docs.
- Read ICO whitepapers: 8 hours. As a bit of a diversion I read a bunch of whitepapers of blockchain-based applications to understand the use cases and what is going on in the community. I got a feeling that some people want to solve real world problems, some people want a mountain of cash and some people want to crush capitalism and bring on the revolution. I definitely saw some real use cases in between. Some recommended reading would be Polymath, Compound, Salt, SelfKey and Civic.
- Solidity Best Practices: 4 hours. At this point I was already aware that smart contracts are immutable and public, so I made a point of learning best practices to save myself future embarrassment and not lose millions from my customers. The cryptozombies.iotutorial has a lot of good advice, the OpenZeppelin audit is very readable and the best practices document from consensys is an authoritative classic. Please read and use the Solidity style guide.
- Atom / Truffle / Ganache: 4 hours. Because remix is cool but I wanted a proper IDE in order to make good code.
- Unit tests for crowdfund: 12 hours. Truffle allows for unit tests, and I took to these with gusto. I did really learn a lot of Solidity by creating them, enough to ease on my development training and move on to study which blockchain implementations exist and how do they compare to each other.
- Create parity test environment: 12 hours. Ethereum is the leading blockchain platform today and I was directed to Parity as an option to create consortium networks, which we plan to use extensively at TechHQ. Installing Parity made me understand the Ethereum ecosystem much better, and that you are not to expect user friendliness, even if nowadays you get Docker images for everything. It felt like installing Linux around the turn of the millennium.
- Read articles about blockchain implementations: 8 hours. At this point I clearly understood the difference between the blockchain implementations (Bitcoin, Ethereum, EOS.IO, Hyperledger, Corda, etc…), which run at a lower layer than all the other applications that you’ll see in ICO whitepapers. This comparison of blockchain platforms made me understand the different use cases for public and consortium implementations, how to ensure privacy, what is finality, how performance depends on the consensus algorithm chosen and the maturity of the different options you can use to build your solution.
If you got here, congratulations! Now you know enough about blockchain to know that you know almost nothing. Which is still more than most of the people out there, so don’t feel bad.
Some final thoughts
- The blockchain technology field is still very immature and the learning curve is very short. A few months of consistent effort are enough to get to the top, although once there you will have to continue learning at a fast pace while the technology settles down.
- You should focus on learning what makes a blockchain data structure special, how to code smart contracts and the impact of the consensus algorithm on your blockchain network in order to provide valuable advice for your clients.
- A well-architected solution using blockchain will have 90% of the code done with a normal technology stack, and the smart contracts will be minimal in complexity. The current version of Solidity is very immature and it is not clear which language will be used to code smart contracts two years from now. I would ask to be able to do them in python, if I could.
- There is a fierce fight for dominance between blockchain implementations. None is really mature enough today but that is something that you will need to gamble on if you plan to have first mover advantage.
- I’m immensely happy that I took this path, it is really exciting to be part of such a dynamic environment and to be able to work on fundamental problems.
We all get by with a little help from our friends, thanks to Sergio Pereira, Antonio Ferreira, Carlos Manzanedo and Adam Vile for their career and technology advice.
Thanks for reading this much, if you want to know more please feel free to contact us at TechHQ, we love helping people out. Or if you are the one that would like to help us, now is the time, we are hiring!
This article was originally published on July 2018 on the TechHQ blog, stay tuned for a “six months later” update!