The first of a series of blog posts about æternity’s technology. By Michał Zajda.

I would like to start the series of blog posts describing engineering and technological approach to æternity blockchain implementation.

Our tech stack happens to be pretty unified and is mainly implemented in Erlang/OTP language. This is where we begin.

It is always debatable if certain technology is the best for a project. Pros and Cons should be covered in dedicated post on its own (and surely followed by heated discussion in the comments! 😉 )

Erlang/OTP

According to my experience with both Erlang and blockchain projects, I can say that the evolution of Erlang projects matches closely the evolution of blockchain ones. Its about the journey from one man’s desktop to operations on a global scale.

Erlang/OTP is excellent at the beginning, when we operate on bunch of scripts. It lets us leverage multicore CPU benefits right away and gives simple tools allowing for the creation of a distributed system.

The next step is to standardize, make it portable and reliable during the release process. One of he main tools in the Erlang/OTP ecosystem that can be instrumental for the achieving of this goal is Rebar v3. It is a set of tools developed by both — the community and OTP (think: standard lib for Erlang).

Advantages

So, what advantages do we get?

1. It is a clear and robust way of organizing code, libraries and dependencies. The development of the code is separated from dependencies and everything is optimized to create a compilation quickly.

2. It is a great way of deploying code. The OTP release creates an artifact which is self-containing. It includes runtime Erlang VM, code, dependencies, and configuration. It is one step away for providing one-click deployment of a blockchain peer on any OS. We need to compile the VM just once on dedicated build machine, sign and publish!

3. Its optimal way of interacting Erlang VM with an OS. The release (when done the OTP way) comes with set of scripts to start, stop, attach etc. The system runs as a daemon out of the box, usually started in the context of dedicated OS user. It is not attached to any bash console. We don’t need a screen. Using a simple attach script takes us straight to the interactive Erlang VM, where we can play, inspect, and diagnose the running system.

4. The standard layout makes it easier to use out-of-the-box testing frameworks, debuggers, static code analyzers.

5. Its easy and robust way to manage configs: for production, test, development, etc.

In our case: we use 3 node deployments for testing .

Before Rebar: we had to copy the project to three different locations and make sure it is the latest compilation and that it is reset, with no blocks and data files. It is very bug-prone process.

Finally, we had to start each of the deployments with a dedicated configuration defined in a bash script.

After Rebar: we call “make dev-release”. It creates three releases in isolated build directory and they are all fresh.

Then we call: “make dev-release-start”. All three nodes start with dedicated configs maintained in subdirectories of the config dir. They are easy to use as templates for ansible or puppet.

6. Finally, when everything is compliant with the newest Rebar, we are part of the Erlang ecosystem and it is easy to include dependency projects or be included in something new!

I hope that the list above shows what our goals are and where we want to take the project.

Do not hesitate do deep dive and contribute code!

About the author

Michał Zajda is a hands-on engineer with a track record in the hottest projects of the last few years. He has been responsible for the architecture, scalability and performance in systems behind RTB markets, Mobile Chat apps, and IoT systems that serve hundreds of millions of customers. He will support æternity’s incorporation of Erlang technology in order to deliver a state-of-the-art blockchain.

---

Interested in æternity? Get in touch:

GitHub | Reddit | Telegram | Twitter | Facebook | Mail