Week #14 - Aeternity Protocol Development Update

In this post the core team highlights the most important and interesting developments that took place over the course of the last two weeks (weeks 13-14).

State Channels

One of the most challenging endeavours in the world of public blockchains is solving the scalability problem. State channels, where transactions are taking place off-chain and, therefore, are not bound by limitations imposed by a consensus protocol, is one of the most promising ways of solving this problem. aeternity blockchain has one of the most (if not the most!) advanced implementations of state channels among public permissionless blockchains . However, the job is still far away from being complete and our team is constantly working on improving and extending our state channels implementation.

During the last two weeks we did following improvements to the exiting implementation:

  • improved the WebSocket API making it easier to use and more stable,
  • improved documentation with custom timeouts for state changes,
  • improved transactions versioning: introducing new versions of transactions to go in Fortuna release, while keeping the backwards compatibility of current transactions. This feature is not really channels specific but yet is required for allowing us to expand state channels functionality in a backwards compatible manner.

Also new functionality is constantly being introduced. So, we are working on providing support for on-chain events notifications that are required for disputing mechanism: if Alice tries cheating Bob using the solo closing sequence, Bob gets notified by a dedicated event and can decide if he wants to initiated dispute it or not. A result of a dispute can be the solo closing sequence that consists of solo close, slash and settling transactions for Alice to sign. Solo closing sequence is also work in progress and requires updates to state channel’s finite state machine or FSM - a state machine that governs operations of state channels.

We are also working on embedding the on-chain environment inside every off-chain update: it will allow us to have much simpler reasoning about off-chain updates that rely on both off-chain and on-chain environments and, therefore, have access to both. It will result in improved stability of State Channels and make all updates - off-chain and on-chain forced progress ones - more deterministic.

Generalized accounts

Our team is working on implementing a very novel concept in the blockchain world: generalized accounts. In a nutshell, a generalized account is an account that is transferred into a contract and for which signing is done by contract calls

The implementation of generalized accounts is going forward, at the moment the two necessary new transactions are implemented, and are feature complete. There are some negative cases, assertions and error handling missing. Generalized accounts impose changes to contracts, call objects, oracle queries and state channel id’s - this is all in place. The latest addition is the ability to use generalized accounts in state channels, with the most changes/additions needed around signing and co-signing off-chain state using generalized accounts .

The last bit has only been tested with one of the two channel participants being a generalized account. Expecting a PR with this status early next week. And then more polish, new crypto in VM and FATE is next.


As you probably know, at aeternity we are religious about testing. Apart from the ordinary testing, we use automatic test case generation to create thousands of meaningful tests that one probably would not think of writing manually. Main focus of the last two weeks has been to extend the test case generators to cover more contracts and state channels, such that we can test the generalized accounts that come up.

We added extra contracts that could be randomly picked and called with a random amount of gas and random fee for a random function in that contract. Funnily, we did find the VM to crash in one specific case that nobody had been thinking of testing. The consequence of this crash was that the miner would have had to run a potentially expensive contract that would crash at the very end and therefore, the miner would have spent effort, but would not get paid. Crashes are typically taken care of in Erlang, so the miner would have put the failed Tx back into the mempool and continue with other things.

However, every next generation, it would read this broken Tx from the mempool and try again, thus spending a little effort a number of times.

The reason for the crash was that the gas was exactly one unit too little for storing the result of the contract computation in memory. Thus, the complete contract had been computed to the end and the only thing that needed to be done is to save the result. For that however, there was too little gas. The details can be found in the fix: PT-164890420 fix out of gas for memory in call by ThomasArts · Pull Request #2272 · aeternity/aeternity · GitHub.

By now having more contracts in place, we could create tests for generalized accounts. First of all we tested that we could create generalized accounts from any account state, no matter whether the account was an active oracle or a contract already. Then we tested that each transaction sequence with normal transaction could also be part of a generalized account transaction… which gave some interesting corner cases to fix.

To be hornest, not all transactions were tested this way, the state channel transactions turned out to be more tricky than we expected. So, most of this week went into improving the state channel test generators… and hopefully next week we can test state channels in generalized accounts and generalized accounts opening state channels and all that.


In response to multiple requests from the community we have decided to provide a reference implementation of stratum protocol for aeternity.

Stratum approaches state close to development completion. We are few changes away from running the full cycle of stratum loop. Such loop consists of observing the chain, delegating the work, validating work and dispatching rewards via spend-to-many contract.

This is not the end of road, tho. We need to polish rough edges like define minimal award or figure out what’s the good solution to key management of stratum operator. Balance of convenience ( = automation) and security is what we deal here.

When all of that is ready, we will escape with tests to real world. First smaller set of hosts then our full testnet and we would like to conclude with run in special stratum test environment that is bigger and will let cover number of edge cases.


Our team is also working on a major update of our virtual machine (VM). The detailed description of the update is a subject for a whole separate post, so here is a brief description of what has been done within the last few weeks.

We started working on connecting the new VM to the chain. Also we were able to execute tests with first contract (identity and remote calls) running on the new VM “on chain”. First gas model in progress. Assembler autgenerated from specification. Work on serialization and deserialization is complete.