For tomorrow’s leading dapps to utilize blockchain within their development stack, developers need the tools and information-access that they are used to having when developing for the web. dfuse is speaking with experienced blockchain developers to help share their journey, the tools they use, and the knowledge sources they turn to. This week we spoke with Christoph Michel, author of Learn EOS.

Could you introduce yourself? 

I’m Christoph Michel, a software engineer from Germany. You can usually find me online under the username cmichel. My fascination for programming started early in my teens as a gamer. Back then, anti-cheat systems were quite easy to circumvent and unfortunately, we had to deal with cheaters a lot. At some point, I started visiting game hacking forums with the intention of defeating other cheaters by learning how to create better hacks myself. Oddly enough, I quickly discovered that it brought me more joy writing and improving the hacks than actually playing the games in the first place. This was the beginning of my programming career and then I transitioned into web development, and eventually went to university to study maths and computer science.

This is also where I had my first point of contact with blockchain technology during my Master studies in Cryptography. I was immediately fascinated by how the cryptographic protocols I learned can be used to build completely decentralized systems when combined with economic incentives. Privacy-preserving coins like Monero or Zcash are super interesting to me from a technical perspective.

However, as a developer, I really enjoy building apps, so I started looking more into blockchain projects that were able to run code. While I was evaluating different smart contract platforms, EOS was announced by Dan Larimer and I agreed with many of the trade-offs he made in its design. I started to get involved in EOS with a pre-release version in early 2018 and then launched one of the first games on EOS upon its Mainnet release, King of EOS. I stuck to EOS since then and recently released Learn EOS, a book that teaches developers how to build dapps on EOS.

What were you hoping to achieve by writing Learn EOS?

I started developing on EOS before its Mainnet release and the documentation consisted mostly of how to set up your development environment by manually compiling the EOS source code.

Naturally, to figure out how to write smart contracts you almost always ended up reading the EOS source code or other open source smart contracts as there was no other option available.

I had high hopes for’s “Elemental Battles”, a gamified tutorial on how to develop your first EOS smart contract. Sadly, it was out-dated upon release as a new EOS version with many breaking changes (EOSIO.CDT v1.3) was introduced shortly before. (Fun fact: The same happened to my book. Literally one day before release, a new EOS Contract Development Toolkit was released.)

I, along with many other developers from the community, was frustrated by the lack of up-to-date learning resources for EOS development. Having already built dapps on EOS at that time, I decided it was a good idea to write everything down that I learned through that process and from reading the EOS source code.

In my opinion, developer education is an important part of the whole ecosystem where I saw a big void that I could fill with my knowledge. In the end, adoption comes with users, and users come with apps which are built by developers. 

I set out to create a complete guide that is self-contained and includes up-to-date information on building dapps on EOS from start to finish. From setting up the development environment, to learning the EOS features, smart contract programming, interacting with them through a frontend and integrating wallets, to deploying the frontend in a decentralized way to IPFS.

While you can find this information scattered around the web in the EOS.IO Stack Exchange forums, in GitHub issues, or in the source code, it is often out-dated or tells only part of the story.

For example, you can find information about how to communicate with other smart contracts using inline transactions on the EOS Developer Portal. But what about transactions that you want to schedule to run at some point in the future instead of right now? What’s the maximum amount of time an action is allowed to run or to be scheduled in advance? What guarantees do you get from a deferred transaction? What happens when they fail and how do you work around that unreliability and these limitations in your contract such that it remains secure?

The above are all questions that one does not think about when writing documentation which makes this information hard to find. But you will ask yourself these questions when sitting down to code actual contracts.

So I packed all this information into over 260 pages, such that all levels of experience can benefit from it – from beginners to experts. The only prerequisite is that one should already be familiar with general programming concepts in any language. An introduction to programming was not what EOS needed, and was never my intention for the book. There are already many other great books on learning how to program, so I didn’t want to reinvent the wheel in this regard. Instead, I focused solely on the blockchain part of development.

What were the main challenges you faced when writing Learn EOS?

The biggest challenge for me, in the beginning, was that smart contracts on EOS are written in C++.

While I programmed in C and C++ almost a decade ago, the language saw a tremendous change since then. Having done mostly web development recently, I first had to become familiar with modern C++ again (iterators, functional programming, lambda functions) and its more low-level features like memory-management and references. However, it was mostly getting used to the syntax and I was happy to see that you don’t need to master complex C++ features when programming smart contracts.

Another issue when coming from a JavaScript web development background was the developer tooling. Being used to hot-reloading and a nice package management system, it felt quite archaic when I had to run commands to compile and deploy my contract every time I made a code change. This led me to quickly develop my own automated build process.

The most tedious part was having to update all code examples whenever EOS released a new version with breaking changes. This happened twice so far, once last year in October and another time the day before the book release. I’m certain it won’t be the last time, but I promised to keep the book up-to-date. I think everyone working with EOS for a long enough time made the frustrating experience of trying to compile out-dated smart contract code. This is especially harmful to new developers that are just getting started, so I try to at least remove this frustration by keeping the book up-to-date.

As a blockchain developer, you need to get used to the fast pace with which updates occur and all the development that is happening. This is true for all tech fields, but in my opinion more so for blockchain. In traditional software development, you own your isolated server and you can just decide to not update. In our space, everything is much more intertwined and the choice is made for you. Your code is executed on lots of different nodes’ hardware in a decentralized infrastructure where consensus decides what versions to run and which new proposals are included as a new part of the system. 

What are you hoping to see come to the blockchain ecosystem?

I’d like to answer this question from two different points of view. First, on a global ecosystem level encompassing all platforms, and then what I’d like to see specifically coming to EOS.

On a global level, I’d like to see more collaboration between the projects whenever it makes sense. To me, it seems like most projects are only concerned about themselves and are afraid to collaborate out of a “winner-takes-all” scarcity mindset. When in reality, in my opinion, it will be quite different. More adoption and more real use cases will advance the market as a whole.

Especially with inter-blockchain communication becoming a reality, or even just through being able to trade any token on Ethereum with any EOS token through, for example, the Bancor Network, projects can co-exist. Almost everything in computer science is just a matter of different trade-offs being made, and the projects can then choose what project with what level of decentralization, privacy, or performance is best for their needs.

Another thing I’d like to see is the exploration of use cases different from gaming, gambling or finance. I think decentralized trustless insurance companies are a good candidate that is worth exploring. Basically, anything that can be confirmed through a public API call can be implemented in a trustless, more transparent and efficient way through oracles.

Lastly, more clarity on the legal side about starting blockchain companies is something I’d like to see. It’s not often talked about but many teams decide to remain anonymous just because the existing legal frameworks cannot be applied to blockchain yet. Just to give an example, when selling digital products to customers in the EU you must pay VAT in the customer’s country of residence. It’s impossible to get that information when your products can be purchased through a smart contract. There are many other such legal uncertainties.

Zooming in on EOS specifically, I’d like to see more dice games.

I think there are still permutations of “EOS”, “BET”, “DICE” and “PLAY” left that could be turned into a company offering these games. On a more serious note, many dapps are still closed-source and even if they are open-source it’s hard to verify that they are indeed running the code they claim as we’re missing contract verification tools in our block explorers. I know EOSPark and the SlowMist team worked on this in the past, but I found them a bit unstable to use.

As a developer, my personal biggest wish would be to have more tools that make parsing the blockchain easier – similar to what dfuse is already working on. Having reliable webhooks that hit your API endpoint whenever an action on your smart contract is executed would be immensely valuable. Right now, the only reliable way to achieve this is by running an EOS Mainnet node yourself which comes with a lot of financial and setup time costs.

What advice would you like to share with a developer who wants to get started developing on EOSIO?

I take a contrarian view on blockchain development. It is not that different from traditional programming after all. Certain things can be even easier, such as not needing to think about data backups, setting up infrastructure or doing dev-ops and maintenance related tasks to keep your app running. That’s all done by the network. (That is as long as all your backend logic is done by a smart contract and doesn’t need a server.) So what I’m saying is that you don’t need to be afraid to learn blockchain development.

The EOS Developer portal is still a great resource to start, and if you’re interested in blockchain there’s no better time to start than now.

A few tips: 

  • Automate your whole setup. From launching the local network to compiling and deploying contracts. This time adds up. Especially if it’s just a side-project that you only invest in a couple of hours per day into, going through the whole process manually can be enough of a mental burden to not even get started. That’s why I wrote my own EOS boilerplate generator.
  • As your smart contract is not a long-running process, but processes each action on an individual basis, you need to carefully consider the different states your application can end up in. I found it really helpful to think of it in terms of a finite-state-machine and draw a diagram for visualization as I did with my Cryptoship contract. This helps to catch unforeseen issues early in the architecture phase, saving you from a lot of refactoring later.
  • Don’t rely on deferred transactions. They are not guaranteed to be executed and you should always provide the user with a way to manually retry the action.
  • Many of the concepts that you’ll learn while developing for one smart contract platform will also be relevant and applicable to other smart contract platforms. Don’t feel like you’re locking yourself in. Don’t become emotionally invested in your platform. 

When you’re serious about EOS development and you want to dive deep and save yourselves hours of googling for solutions, I would shamelessly recommend my own Learn EOS book. Another more bare-bones one is the “eosiolib” source code of the Contract Development Toolkit. This smart contract security checklist by SlowMist also deserves a mention.

If you encounter any problems, feel free to reach out to the community either on Stack Exchange or Telegram. The EOS community is one of the most helpful communities I’ve ever been in! It seems like all the FUD towards EOS has just brought everyone in it closer together.

If you are a developer and want to share your experience to build on the blockchain, please feel free to contact us. We would be happy to integrate your interview to our series “In the Eyes of a Blockchain Developer”.