Overview of aeternity reference implementation (design decisions, considerations)

Here will be placed series of posts which is tagged by “guide” intended to help the all interested parties to dive deeper into aeternity reference implementation’s concepts and the key design considerations. This topic is opened with the general UML package schema of reference Erlang implementation:

aeternity.drawio (4.0 KB)

Also see links to the inspirational core members talks from the latest Aeternity Universe meetup:

Aeternity Universe 2019, dev track, day 1:

Michal Zajda 's talk for consesus and Stratum https://youtu.be/Oa2zIa0B0q0

Hans Svensson 's talk for Sophia (smart contract language) https://youtu.be/rY9t09bZYeE

Erik Stenman 's talk for FATE (virtual machine engine) https://youtu.be/a77DGGzMyN8

Dincho Todorov 's talk for setup https://youtu.be/I40yr6B1KZ0

Aeternity Universe 2019, dev track, day 2:

Hans Svensson 's talk about Generalized Accounts (AEGA or GA) https://youtu.be/2aPaoCC8I0A

Ulf Wiger 's talk for State Channels (SC or AESC) https://youtu.be/Q8QEcQ47vyY

Dimitar Ivanov 's talk for State Channels (SC or AESC) https://youtu.be/WJj3Z12-W9g

Michal Zajda 's talk about naming system (AENS) https://youtu.be/VbbgxehnIFk


It’s worth to mention that Aeternity node represents messaging system internally (Erlang as such) and thus provides the key benefits of messaging architecture style (see Enterprise integration patterns).
One of the most notable problems is “Variable timing” of distributed systems (especially important for decentralized systems which have no intermediary between).
To solve this problem the concept of “jobs regulation” has provided via our core member solution (see Jobs). So at the core of aeternity node resides design decision which allows to manage load capacity and to be sure that our network has controlled from predefined throughput perspective.

This is EIP schema which describes the load scheduling within aeternity node application (also please note that it doesn’t contain stratum application as it uses it’s own scheduling algorithm):

aeternityEIP.drawio (2.8 KB)

Our current plan for the onboarding covers the following topics:


Those represent basic knowledge for the system that is crucial in order to dive deeper:

  • tools and networks - what is testnet, what is mainnet, what wallets are out there, why we need them, middleware web page and etc.
  • system architecture and startup - AE node is a multi-application software and follows the OTP approach but still it has its own solutions regarding how different applications are setup and started
  • blocks and headers - BitcoinNG, block structure, header structure and etc. Initial accounts in genesis block also are discussed
  • serialization - aeserialization lib - IDs, RLP, structures serializations (with a strong focus on fork awareness), Base58c vs Base 64 encodings
  • mining - cuckoo cycle, tx pool, micro block generation, transaction fees, miner rewards, BRI
  • stratum - how it works (optional)
  • MPtrees - Mtrees, MPTrees, DB, GC
  • http - internal and external endpoints, swagger, validation of requests


Describing how nodes sync from the network, how they gossip new transactions, how they share peer lists and so on

  • coordinator - aec_chain & coordinator processes, how blocks are validated, executed and consumed
  • p2p protocols - sync protocol, peers lists, gossip


Discussions around different transaction types, strong focus on why certain decisions were made

  • foundamentals - signed and unsigned transactions, spend transaction, account’s tree
  • oracles - mechanics, transactions and trees
  • names - mechanics, transactions and trees
  • contracts & calls - mechanics, transactions and trees
  • channels - mechanics, transactions and trees
  • generalized accounts - mechanics and transactions

State channels

A deeper dive in AESC reference implementation of the off-chain protocol

  • FSM - FSM, chain watcher and noise sessions; if this can be broken into a couple of smaller discussions - that would be great
  • WebSocket API - client facing interface, discussion around how it is intended to work; log examples

Smart contracts

A deeper dive into AE’s smart contract system

  • Sophia language - a language overview with a focus on why certain decisions were made
  • Sophia compiler - implementation details
  • VMs - AEVM & FATE, primops

After the foundamentals’ section is done, the rest can be done in a parallel.


There is a transaction processing activity diagram which is intended to cover business flow from the point of acceptance HTTP request until ordered placement in transaction pool.

aeternityActivity.drawio (2.8 KB)

Since this thread is a bit messed up, I am creating a new one with the plan on the top

The new topic to be followed is

Note that the transactions’ foundamentals had been moved in the foundation section because they happen to be a prerequisite for anything else. Who would expect :slight_smile:

@erlmachinedev1.chain please move your materials there.

1 Like