[ROADMAP] aeternity roadmap & release schedule Q2-2021

[lydia]

The Aeternity Foundation (AF) supports the aeternity protocol and ecosystem.

The AF is giving funding grants for application on the promotion of the success and growth of the aeternity ecosystem as well as the ae blockchain maintenance. Weekly detail reports on the progress of the developers can be found in the Active Grant Applications under the forum’s AF Grant Category.

Our goal remains the same: to make the aenode faster, better and lighter and the ae ecosystem more attractive for the users. The hyperchain network using the aenodes has been designed to attract the Aeternity enterprise customers and their users. On top of the faster aeternity network and hyperchain network the decentralized applications (dapps) can be run with higher performance and in a private context. Therefore the whole aeternity ecosystem will perform with higher availability, scalability, security and performance.

During April 2021 the aeternity core team had focused on Iris:

• a voting on Iris Hard Fork was made

• Iris release candidate for testing was produced

• a final stable and secure Iris release had been prepared

Simultaneously the private HyperChains (HC) were intensively tested. As a result the HC protocol and HC whitepaper were further improved. The HC Roadmap for April 2021 was published on HC Roadmap.

The continues maintenance process resulted in a new release release 5.11 in April 2021 with fine tuned features, bug fixing and polishing.

The remaining part of the quarter Q2 2021 has the focus on the User Experience (UX) und User Interfaces (UI). The following features are planned:

• DB refactoring is resulting in stability and performance improvements.
  There is currently a large Scale DB refactoring going on and it will result in a better node stability. This DB refactoring might provide some performance boost. It will also allow us improvements the node in some new ways.

• Introduction of a maintenance mode for the node and improved the cyber attacks prevention.
  The maintenance mode will allow the node operator to disable whole sections of the application in order to perform some actions on the node. This mode will help the node stability. It will also provide the foundation for running different scripts on the node in a maintenance mode. Such scripts would be the ones that produce whitelisted block headers or even rolling the DB back to a certain point of time. These scripts and tools are in development and will considerably improve the maintenance flexibility. They also are useful for the prevention of the 51% attacks.

• AeCanary to be released in May 2021.
  The monitoring tool AeCanary link is already in development and will be released soon. It provides the tracking of the tainted tokens. Also it delivers to the exchanges an exposure at a given point of time.

• Sophia New Data Types and Fate Improvements are actively under development

• Beam sync - a radical optimization of fast sync

• Rosetta implementation

• Continuous extensive testing as part of the maintenance of the blockchain:
  During all this time we had been doing some extensive testing. There are some tests to be improved and a new ones to be written. It is important to note that from an user’s perspective a node has all the infrastructure for doing local tests of aepps. We plan on exposing those in an HTTP API so a client can be built on top of it. That would mean that the node will be producing transactions, mining on demand, not mining and so on. This will be useful for all aepp developers, in hackathons and etc.

• Continuous improvement of the documentation as part of the maintenance of the blockchain:
  Regarding developers onboarding, we have plans to considerably improve the documentation of State Channel WebSocket API: currently the integration tests produce a lot of logs that expose the actual communication from the client to the server and back. The tests need to be improved and produce actual examples for the flow. We want as result to achieve a fast and smooth development experiencing for the State Channels.

A new public bounty program for bug finding, tutorials and videos as well as a new award program will be launched soon.

The updates on the aeroadmap and the aerelease schedule will follow dynamically in this topic. The previous roadmap can be found on the AETERNITY ROADMAP Q4 2020 / Q1 2021.

You are welcome to contact us under the Email: [email protected]

We are excited to announce the following aeternity release schedule from April 2021 until June 2021 which will be regularly extended and updated:

Release 5.11

Release Date: 14.04.2021
Type: Maintenance
Release 5.11 can be found on v5.11.0 with the release note

Release 6.0 (Iris Hard Fork)

Release Date: 01.06.2021
Type: Hard Fork
Release 6.0 can be found on Iris 6.0.1
Release Candidate 4 on 28.05.2021, see Iris RC4
Release Candidate 3 on 18.05.2021, see Iris RC3
Release Candidate 2 on 13.05.2021, see Iris RC2
Release Candidate 1 on 30.04.2021, see Iris RC1
Release Test Candidate on 15.04.2021, see Iris RTC
Voting starting on the 15.03.2021
Planned Release Date: 25.02.2021
Important Condition: A positive result on community Iris Hard Fork Voting was achieved prior to the Release 6.0

Release 6.1.0

Release Date: 16.06.2021
Type: Maintenance
Release 6.1.0 can be found on v6.1.0 with the release note

[Winfield]

Congratulations,Great job.

[Richard_Libra]

Can AE release more projects that Public attention to attract popularity?

[simo]

When does the iris 6.0 Come Online?

[erik.chain]

Hi @simo, you can find the latest contributions to the Iris Hard Fork Release candidate here:

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

Hi all, A lot of stuff is happening! We’re in the last phases of preparations for the iris release. There had been a lot of testing and improvements, but most importantly Hans and Ulf Norell are back! Here are our reports: Week 12 (22 March - 28 March) Ulf Wiger (@uwiger) Ulf has been working interchangeably on maintenance mode support, database plugin refactoring and inactivity timers for State Channels. While working on the maintenance mode support, he identified a group of bugs in the OTP …

Further, you can find a description of the procedure after testing the Iris release candidate here:

Iris Hard Fork supported by the æcommunity

[image] After the first three planned hard forks, namely Minerva (March 2019), Fortuna (June 2019) and Lima (October 2019) now comes the Iris hard fork (April 2021). The Iris release is the first one that was not planned in the initial roadmap and implies changes in the consensus rules, so it was subject to a community vote which ran from March 15th to Apr 14th at 01:36:39 AM CET, when the vote ending block 414020 was solved. Please note that blockchains do not know about dates and hours but …

[tianyahaijiao]

There are two crucial factors that make a project sustainable. First, the value of the project, and second, the availability of money behind it. Can you tell me why the official exchanges have not opened yet? Any official moves? After the completion of the upgrade will be the first time to restore the refit is the official first responsibility! Why isn’t there any movement?

[gokulalex]

Dear Dr. @lydia, what are the cryptographic signatures supported by the latest release 5.11? Does it support ring signature or signature aggregation features ?

[hanssv.chain]

At the protocol level (transaction signatures) it is: EDDSA (curve 25519), signature is 64 bytes. as described here

In contracts you can also do “bitcoin” crypto - i.e. secp256k1 signature checking, etc. Since generalized accounts are protected by contract code it can be used there.

After the protocol upgrade (v6.0 - a.k.a. Iris) the FATE VM (and thus contracts) also support more fancy cryptographic operations by the addition of BLS12_381 crypto operations.

[gokulalex]

Thank you so much @hanssv.chain for the detailed answer.

Would there be any security issues in the long term when we use EDDSA ( curve 25519 ) as there has been some early observations on Ed25519 leaking private key for scenrios when the signature length is long with Ed25519ph. In these scenarios, curve doubling time for computing a signature could be significant and can produce considerable footprint. It seems these kind of attacks are classified as fault attacks. May be my interpretations are misplaced. Request your review.

Please find a related discussion thread from libsodium repo included here.

[tianyahaijiao]

On the AE exchange to raise questions, the project side is not going to ignore it? Is that a central question?