Week #16 - Aeternity Protocol Development Update


#1

In this post the core team, as usually, highlights the most important and interesting developments that took place over the course of the last two weeks (weeks 15-16).

Stratum

Stratum development was focused around stability of mining client and communication with chain. We achieved full lifecycle of calls from sending the key block candidate to receiving evidence of solved block. Further work is needed around testing framework and number of small issues listed in updated pivotal tracker tickets.

State Channels

State channels team enhanced internal pub-sub system to provide more detailed information regarding new blocks.

Also both off-chain and forced progress transactions from Fortuna were enchanced with additional optional field for specifying the environment to be used. This is heavily tested especially with regards of backwards compatibility. Improved documentation accordingly. The logic for processing the new fields is still in work in progress.

We also revisited State Channels WebSocket API for reestablishing an existing channel’s connection. Required parameters had been refined so it is even easier from a client’s perspective. Improved documentation accordingly

Finally we continued refactoring State Channels’ FSM for accommodating solo closing and disputing flows. Specifically, we introduced handling of more unexpected corner cases regarding long on-chain forks that invalidate the off-chain state - this still in work in progress.

Generalized accounts and Testing

Testing efforts were mainly focused on generalized accounts, specifically on testing meta transactions using Quick Check.

The new generalized accounts are basically contracts in which the writer of the contract is obliged to provide an authentication function. Each existing transaction can now be wrapped in a meta transaction, meaning that the generalised account’s authentication function replaces the normal signing.

Before we tested meta transaction without looking at signatures, but with the completion of state channel transactions (which need to be signed by two parties) testing was extended to sign inner transactions. This was first done by mocking the signature verification, such that the QuickCheck models did not need to keep track of private keys. As a consequence of this, it was found that (very weird case) any spend transaction, wrapped in a Meta of an unrelated Generalized account could be accepted.

This is weird. It basically would mean that one can Wrap that spend transaction in your generalized account, pay the fee for running this and the spend is performed.

A ticket was created as well as that we realised that this will possibly be never an issue in reality. Because it would mean that the spend was double signed. In order to verify that, the model was extended to really take care of signing. And indeed, the double signing rule saves us for the moment, but when we get delegate calls, etc, this issue may pop-up again and therefore the ticket remains.

Also we were testing using ECDSA with Secp256k1 curve for signing transaction (instead of currently used EdDSA with Curve25519 aka Ed25519). Allowing for the usage of different signing schemes for transactions signing is one of the features that generalised accounts bring.


Week #16 - Product Coordinators Weekly Development Update Call