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:
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):
Our current plan for the onboarding covers the following topics:
Foundamentals
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
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.
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
