Status: Approved on the 26.06.2020
Last updated: 25.06.2020
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
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
- Aeternity core node
- Sophia and Sophia compiler
- HTTP compiler
- Aeternity middleware
- Ae channel service
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.
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.
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
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
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.