[Active] Aeternity node maintenance - iris hard fork release candidate

Application Status

Status: Approved on the 26.06.2020
Last updated: 25.06.2020

Prepared by
Sergii Maksiuta [email protected]
Project manager of Core Dev team


Approved Budget (in h): 500h/Month for the first 3 months

Used Budget (in h): TBR (to be reported on a monthly basis)

Planned Delivery: 3-12 month depending on resources availability

Specify the funding category

Open Source Development

Application Title

Aeternity node maintenance - iris hard fork release candidate


We are the core team that built the core technology. You can find our names and nicks in the contributors’ sections in the corresponding GitHub repos

Value Application

Aeternity blockchain is a distributed network of peers.
The node is a complex software that needs adjustments, tests and bugfixes.
There are some functionalities currently that are implemented but are not yet usable on aeternity mainchain as they
wait for the iris hard fork.

We propose iris hard fork candidate and let users vote in favour or against it.

Definition of Terms

Aeternity node must be maintained and this is vital to the Aeternity blockchain.
For this to happen, there must be a team of people that constantly tests and improves it.
Those people shall have a deep understanding of the underlying core software and its infrastructure.
Also the more people share that knowledge - the better security the codebase has.
We expect a long term commitment and a planned horizon ahead so we can do our job properly.

The proposed backlog is a result of continuously gathering feedback from the community.

It also contains bugs and points of improvement of the codebase. Those are publicly available as reported issues in GitHub Kanban board:

Issues are sorted to must-have-s, should-have-s and the coulds sections. The issues have their
descriptions and corresponding labels for getting a better overview.

High priority issues consensus breaking included in the iris hard fork candidate:

  • Migrate to latest possible stable OTP #3293 - currently the latest OTP release is 23
    and the OTP supports 2 versions behind. We are still using OTP 20 which is no longer supported. This both imposes a security risk and sends the wrong message to the
    community. This also prevents us from upgrading any code dependencies.

  • Sync: cleanup dead peers #3290
    Sync system keeps quite a few dead peers and this impacts our network connectivity greatly. This most likely is the cause for many longer-than-one microforks. There had been
    attempts for solving this and a further analysis there must be done for the underlying issue.
    Some research had been already done regarding potential drawbacks from different solutions.

  • Deprecate AEVM for Iris #3151
    Currently we have both the old AEVM and the much faster and better handling resources FATE. Implementing any new Sophia features requires adapting both VMs. Deprecating the old one would significantly reduce the maintenance there

  • [AENS: Fix bug in AENS.update signature check #328]
    (https://github.com/aeternity/aeternity/issues/3281) bug in the protocol implementation

  • [Make inner transaction of PayingForTx non-valid #3054]
    (https://github.com/aeternity/aeternity/issues/3054) - bug in the protocol implementation that makes PayingForTx dangerous to use

  • meta_tx’s TTL #3056 -
    protocol bug that is an unexpected consequence of channels and generalized accounts.

Status Quo

Plans for the iris hard fork candidate are to be settled after this proposal will be agreed and the feedback is gathered in an open discussion

Required Work

We will gradually start cleaning technical debt. Please consult the Kanban board

It is expected while cleaning up technical debt to find new bugs. If those are important to fix, esp. protocol level ones or API breaking ones, we will put them in the “musts” section and fix them.
It makes no sense finding bugs that would require yet another hard fork and postponing them.


The backlog is already too big and resources are limited. Core team believes making estimates IS NOT an adequate solution in this particular case. The listed team is already engaged in related AE and other projects and propose maximum time allocation by team member.

  • Sergii Maksiuta 20h/month
  • Ulf Wiger: 80h/month
  • Hans Svensson: 32h/month
  • Ulf Norell: 32h/month
  • Karol Skocik: 80h/month
  • Daniela Ivanova: 80h/month
  • Artur Kratt: 80h/month
  • Dincho Todorov: 80h/month
  • Dimitar Ivanov: 80h/month

Progress presentation and time reports periods to be negotiated with the Foundation

Known Limitations

The core team proposes a hard fork release candidate.
Then the community vote will decide the need from it.

Performing the community vote is not in the scope of this proposal.
Ledger support for the governance app is not part of this proposal
Any additional governance app changes are not part of this proposal.

Examples for tasks depending on community input

  • Deprecating Windows support - we would ask in the forum if we shall continue supporting the Windows builds. We strongly suspect they are not required.

  • Extending the default name period - there must be a community vote for it.

    This had already been discussed that it should be done, some forum threads:


Planned activities address current community pains and needs
Core team aims having Aeternity node green, bug-free and iris functionality enabled.


All of our work on Aeternity node had always been transparent and open source. As long as we are the developers behind it - it will remain so.


This project is already of maintenance type.


I highly appreciate this effort!

for aenalytics.org we plan to provide some incentivisation mechanism in regards to the naming system which will allow users to extend other users names by providing some small reward. in order to be able to provide this we need the hardfork :smiley:


Thank you for the work of the core team, because of you, aeternity will be more powerful. As a fan of aeternity, we support your work. Looking forward to more changes. Thank you.


For all participants of the aeternity network this will be useful, there is no alternative to a well-maintained core node, moving to iris functionality will be a big help for various products, e.g. with the naming system improvements, sophia additions and PayForTx.


For the maintenance of core code, I think it is worth investment


The ACF Foundation is happy to support the core developers to make the Iris major release. @coreTeam Please provide a weekly report on your development.


All sounds fair and reasonable. Keep up the work, always need rounding off the edges :handshake:


Good to hear the news!

1 Like

for the record: I am only supporting a HF after #hyperchains have been build (or for super critical things / emergencies). protocol should be as stable as possible and only be updated when its really worth it.


This post was flagged by the community and is temporarily hidden.