Development

Aeternity GitHub metrics

Developer activity (from Aeternity Coinlib.io)

Jelly Swap protocol — first ever cross-chain atomic swap between Aeternity and Ethereum blockchains. Watch the swap ETH for AE and vice versa in a few minutes. The real use case of cross-chain atomic swaps and innovative solution for the blockchain interoperability problem. ETH/AE atomic swaps will become available on the aeternity Mainnet at the end of January 2020.

The latest Base aepp update allows you to transact with a name instead of an address.

Watch the video and register your [.chain] name now.

{Protocol hardening through property-based testing}

As described in previous reports the testing of the State Channels protocol was extended by using Quickcheck models for the on-chain transactions as well as the FSM itself. This work is in progress. Nevertheless, they see great results with every addition to the model which is encouraging. They plan to continue this effort in 2020 by improving the model even further. This work is tricky though, as the FSM is a moving target which is subject to constant change, while the model needs to catch up slowly. Thus, achieving full coverage will take a lot of work down the road and be a constant work item going forward.

{UAT suite}

In mid-2019 an effort was started by @Aleksandar to create a stand-alone test suite that implements an SC client outside of the usual set of test tools that are used during SC development. One of the UAT’s goals is to be a prototyping tool for potential SC users as well, by providing an API to create use-case scenarios easily. The goal for 2020 is to make the UAT more accessible by cleaning up the API, creating good documentation and keeping it up-to-date with the latest changes in the State Channels.

{Wallet integration}

A first stab at building an application on top of State Channels was done in preparation for AE One 2019. The application was meant to provide fast payments for on-conference drinks. It is currently being completed, [more info here][payment_app].

To make these kinds of use-cases easier a short-term focus will be on integrating State Channels into the AE Wallet. This integration will provide a useful user-flow and proper API integration to help developers to leverage State Channels without having to implement the entire flow from scratch.

{Virtual State Channels}

The design has been outlined in the State Channels Yellow Paper. Since then the SC team is implementing the required protocol support piece-by-piece. The plan is to have a first working version of Virtual State Channels ready in 2020. The progress is exciting, updates will be floated here in the forum as well to get the community involved as well once something usable is ready. Until then everyone should feel free to comment on the Yellow Paper

{Description}

What they have focused on and working on lately was gathering all of the developer tools into one to form one powerful bundle, called the Development Suite or just Dev-Suite. Dev-suite aims to bring the ultimate experience for developers (having all of the tools and services in one place).

They believe that:

It should not be difficult to build a blockchain application (aepps) on aeternity

{AEproject}

Updated the version of node and compiler to the latest so developers would be able to test their work with the most up to date ones. Carry on with integrating another tools in Aeproject. They decided to concatenate the aepp-middleware in order to have a one comprised tool which could set up the entire network locally with all you need. Were active on the forum as well, helping other members and provide updates.

{Token migration}

Added a web app manifest file.

{Playground}

The playground has been deprecated.

{Changelog}

Aeproject updated node and compiler aepp-middleware integration on the way Playground no longer available

{p2p simulations}

Using p2p simulator they’ve been trying to come up with different sets of parameters that would improve the situation with propagation of the dead peers. The results show that changing some parameters such as the number of gossiped peers and decreasing the max number of connection rejections would have positive impact.

{Peer pool configuration parameters}

Related PRs: PR #3074, PR #3076

Based on the p2p simulations, they’ve made some peer pool parameters configurable. Also, they decided to change probability of selecting a peer from a verified pool to 1.0 (100%) mainly because if a connection to a peer specified in the config is lost they want to reconnect to this peer as soon as possible.

{Ping message check}

Related PR: PR #3090

The max number of gossiped peers in ping message is 32, but this number hasn’t been enforced by the node.

{Dead peers removal}

Related PR: PR #3117

Changed the way how a filtering function is called in order to filter dead peers in pool buckets — it called more often now resulting in more aggressive removal of outdated peers. This is still work in progress.