[ROADMAP] aeternity roadmap & release schedule Q1-2022

lydia · January 27, 2022, 5:18pm

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.

Q4 2021 Recap

Short review of the worked tasks in Roadmap Q4 2021:

AeCanary received a refactoring and some new services have been added. Devmode was polished with some bugfixing. It proved to be a sufficiently useful for the development and the testing. The node operator interface was implemented. Both a CLI and a complementary group of HTTP endpoints can be used presently by the developers. The node GUI launcher is almost done and is to be release publicly soon. There have been quite a few challenges in order to get the graphics right. The node already compiles under M1 CPU. The M1 architecture docker image will be deliver soon. The aeternity code now supports OTP24. Some DB refactoring was done by forking and fixing the dependent external library by the core team. Some good progress has been made on the the Rosetta API but most of the work is yet to be finished. The current GC Names process needs a refactoring. It is working for accounts cleanup. However, by adding names and contracts to it, it can be overloaded. This process depends on the DB refactoring.

The following Ceres improvements
• bitwise operations (OR, AND, XOR, NOT)
• ZK/SNARK friendly hash function(s) - Poseidon hash (+ possibly more?)
• a dedicated MULMOD instruction
were done. Additionally, some work on multisig, a pygments lexer and an improvement of the production on microblocks was done. It was introduced a new test suite implementing a prototype State Channel Market structure (using hash-locked cross-channel transfers).

The work on Hyperchains was ongoing. The Hyperchains Alpha will be release next month for test. Please note that some of the previous tasks were needed also for hyperchains.

Q1 2022 Roadmap

The node will be continuously improving and the focus will be put on further HyperChains research, design and development.

Ongoing Important Tasks

AeCanary and all basic features/tools as dev mode, node modes, etc. in general will be continuously supported and improved. A support for Hyperchains need to be provided in AeCanary. Rosetta API Implementation is ongoing. A native node GUI launcher to compile the node and provide some means of inspection of the live system will be released soon. The RocksDB refactoring is needed for a stricter control over transactions. The GC Names process improvement relies on this refactoring.

HyperChains

Hyperchains Alpha will provide a staking smart contract. A user friendly GUI will make a staking just an easy task. It will give users the control on assets and rewards behaviour. The research and design on Hyperchains will continue.

Advanced State Channels

A showcase on a state channel market is to be made.

Sync Improvements

The sync is suboptimal and needs to be speed up. An RnD project on beam sync will be started.

MultiSig

Aeternity mainnet already supports multisigs but the process requires a good knowledge about cryptography and Erlang. This process needs to be simplify and to be made an easily accessible.

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 2021.

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

Release 6.4.0

Release Date: January 18, 2022
Type: Maintenance, see post, release info.

Release 0.0.0-hc5

Release Date: February 27, 2022
Type: HyperChains Test, see HyperchainsAlpha.

charles · January 28, 2022, 2:42am

hope hyperchain come soon！ @marco.chain The middleware team Q1 plan can be published here？

marco.chain · January 28, 2022, 9:52am

mdw development is not part of the foundation. @philipp.chain recently published an update with a future outlook here: Middleware Team Development Update

we will also publish an update for the current mdw-frontend (explorer) soon

_dog · February 3, 2022, 2:02am

Advanced State Channels

A showcase on a state channel market is to be made.

Any details available on what this showcase will be?

uwiger · February 3, 2022, 7:41am

Sure. In the aeternity repos, there is so far a test suite, validating a rough first draft of a State Channel network:

github.com

aeternity/aeternity/blob/master/apps/aechannel/test/aesc_htlc_SUITE.erl

%%%=============================================================================
%%% @copyright (C) 2018, Aeternity Anstalt
%%% @doc
%%%    Test utils for State Channel markets, using HTLC contracts
%%% @end
%%%=============================================================================
-module(aesc_htlc_SUITE).

-export([
          all/0
        , groups/0
        , suite/0
        , init_per_suite/1
        , end_per_suite/1
        , init_per_group/2
        , end_per_group/2
        , init_per_testcase/2
        , end_per_testcase/2
        ]).

This file has been truncated. show original

It uses a Hash Time Locked Contract (HTLC) to enable safe transfers across two state channels via an intermediary. In this simple form, you could imagine a “market hub”, to which users open a channel. The hub puts up some collateral, making it possible to make transfers to other users on the hub.

In the scenario running in the test suite (all processes local to one machine), such a transfer takes ca 15-20 ms, including signing and signature verification. In a real-life scenario, you’d add network transfer and perhaps human signing delays, of course, but with bounded automatic signing, it seems possible to transact without noticeable delays even as a button click.

In my talk at the Aeternity Universe One conference (Prague 2019), I discussed some use cases where State Channel networks might unlock new levels of scalability. One of the use cases was “paying for coffee”, but this was mainly because it’s a ubiquitous case; while it could be addressed with new exotic technologies, it’s pretty much a ‘solved problem’ already.

But another case was “pay to read”, where you could imagine a micro-paywall where you get to read the intro to an article and then pay incrementally to read the whole thing, one page at a time. This is something I would personally appreciate.

In the talk, I mainly discuss Virtual State Channels. Those are still pretty far away, since we’ve prioritized other things, but the HTLC scenario is much easier to implement, and so far doesn’t require any updates to the existing State Channels implementation.

The implementation in the test suite is a bit crude, though. I’d like to improve the negotiation, with a bit more structure. Later on, an instructive demo would be needed. The demo should make use of the Channel Service for the hub - this is basically what the Channel Service was originally designed for.