The grant which I’ve received by the Aeternity Crypto Foundation has concluded.
Therefore, I’d like to take the chance to summarize the work I did.
But first I’d like to thank @emin.chain for the constructive relationship with the Foundation
during the grant period. The approval process was fast and straight forward, the
reporting during the grant didn’t get in the way of getting work done.
My main objectives were (1) to help the Core team to stabilize the code
post-mainnet-launch, (2) keep Windows support up-to-date and (3) join the state
channels team to improve velocity there.
While I was continuously involved in the state channels work, the focus of my
time was distributed between that and other Core features and improvements as
there was plenty of demand for that too. Nevertheless, updates in regards to the
state channels were posted in separate bi-weekly reports which I
won’t duplicate here.
In Q3 2019 there was a focused effort to provide an easy way to recover tokens
after the final migration phase. That process is now called Token Migration
Phase 4. One part of that solution is the use of
from parity via a new helper library. I specifically
helped with that integration, an FFI to Rust, in collaboration with @jsnewby
and added new operations to FATE using that functionality in collaboration with
@hanssv. This was an interesting piece of work as it touched quite a few parts
in the stack and required additional work to be usable on all supported
Regarding platform support, supporting Windows as a first-class platform for the
Aeternity node is itself a constant chunk of work because this requires all external
libraries to be usable on Windows as well. An example of this was the
integration of new crypto operations for use in
On the surface such a change might look like a simple integration, which it mostly
is for Unix-based platforms such as Ubuntu and macOS. However, the basis for this
was a new library emcl which required the integration of another small C/ASM-based
library which then adds to the complexity since building and running such changes
on Windows can become challenging. Thankfully, we ended up making it work
despite encountering various cryptic problems. It goes to show that
supporting a platform like Windows requires constant effort.
The Aeternity node is based on Erlang/OTP. Erlang/OTP has a very stable major
release cycle. Such releases usually ship with plenty of improvements which
shouldn’t be ignored. However, a project like the Aeternity node requires some
effort to make it with new major versions due to its size and complexity. Thus,
I added support for OTP 21 which includes roughly 1.5 years of
In Q4 2019 I contributed all over the place, updating core dependencies, fixing
and improving test coverage, making the build tool-chain more maintainable. I
also started looking into improving the resilience of the Core’s database layer.
A notable change has been retry support for internal operation
failures. There’s plenty of opportunity for improvement in the future. However,
changes in that part of Core need to be carefully vetted by multiple team
members as there impact on node operations can be severe if not done right.
All things considered I feel like I was able to make valuable contributions to
the Aeternity node as part of the grant. The Core team is very welcoming to
contributions and constructive in gettings things through the process.