Frequently Asked Questions (FAQ): General Tech Questions

Image by Tim de Groot

Answers to the most common technical questions about æternity.

More FAQ resources:

If you have more questions, please add them in the Forum.

How can I follow what the dev team is doing?

The best way to follow the progress of æternity’s developers is to use the Pivotal Tracker tool.

If you are not a developer, the easiest way to stay updated on dev team progress is to follow this page in the blog.

If you are a developer, you can follow æternity’s GitHub page.

What are the most interesting technological features of æternity?

Some of the most interesting tech features of æternity include the Sophia smart contract language, Bitcoin-NG consensus with Cuckoo Cycle used for Proof of Work, state channels, integrated oracles, and integrated naming system.

The Sophia Smart Contract Language

Sophia is a smart contract language that was designed to write safer code. It is a functional Ocaml-like language which syntax most resembling that of Reason. Aside from several functions for transactions and events, Sophia is a purely functional language. Its functional nature makes it easier to test and verify the code and avoid mistakes. It is strongly typed and has restricted mutable state. Sophia has built-in functions to directly access all features of æternity such as the naming system, state channels and the oracle function.

Bitcoin-NG and Cuckoo Cycle Proof of Work

To date, the Nakamoto consensus is the most tested way to secure the entries in a distributed ledger. However, due to its design — waiting for the next block to be mined — scalability is limited. æternity uses Bitcoin-NG to improve on-chain scalability. Whenever a block is mined, a leader gets elected. That leader is allowed to issue micro-blocks until the next block is mined. This improves on-chain transaction speed compared to Bitcoin to ~6000 transactions per minute without compromising the well tested and proven design of Nakamoto Consensus. æternity uses the efficient Cuckoo Cycle, the first graph-theoretic Proof of Work algorithm, and the most memory bound, with instant verification. Its large memory requirements make single-chip ASICs economically infeasible, which improves mining decentralization.

State Channels

In æternity a channel can be opened between two users. A single user can open as many state channels as they wish. State channels do not only support cryptocurrency transfers (balance updates) between participants, but also the execution of smart contracts. Whenever the state between participants changes, for example after a payment has happened, the participants agree on a new state by signing it. State channels are trustless and have the same security guarantees as the blockchain. If one of the parties tries to act maliciously, any participant can close the channel and submit the last signed state to the blockchain. Whichever participant submits the most recently signed state by all participants is considered right. The submitted state of all channel balances gets settled on-chain and distributed to all participants. As channels transfer user interactions off-chain and only exist in-between participants, they allow for nearly unlimited, nearly instant, lightning-fast transactions. Moreover, if participants in a state channel close it in a mutual agreement, no state needs to be published on-chain. This significantly improves privacy since the participants’ on-chain accounts remain unchanged.


In order to provide data to the blockchain that can be used by smart contracts, æternity makes it possible to register the so-called oracles, or data feeds. These oracles exist on the blockchain in the oracle state tree, stored in a full-node. All registered oracles provide data in a format that has been set up upon their creation and that can be queried by a smart contract. The oracle operator can set and charge a fee in AE for users that query its data. The provided data can then be used to execute smart contracts based on the data received and the rules set within the smart contract. Data can be, for example, sensor data from smart devices, local weather stations, financial institutions, manual input, or prediction markets. The verification of the data happens within the individual smart contract. Smart contract developers can decide if they accept the data from one source right away or if they set multiple conditions, for example, multiple different independent oracles that need to report the same data to the same questions. An example would be a query to multiple oracles with the yes/no question “Did Liechtenstein’s football team qualify for the Fifa World Cup 2018?”. All operations such as registering or querying an oracle are transactions on the æternity blockchain. Oracle operators scan the blockchain for queries or use a subscription mechanism for being notified about queries and respond to them. After a response has been provided, it is immutable on-chain. All responses will remain on-chain and have a TTL (time to live) until they get pruned after a certain number of blocks.

Naming System

æternity features an integrated naming system that could revolutionize the user experience when dealing with wallet addresses, smart contracts or oracles in much the same way as human-readable website addresses revolutionized the internet.

What will be the on-chain and off-chain tx/s speed?

The on-chain speed is difficult to estimate before simulations start running. Implementing Bitcoin-NG, Waves managed to achieve speeds of 6000tx/minute or 100tx/s on-chain. We believe that similar speeds will be achieved on æternity, which is much faster than Ethereum (12 tx/s) and Bitcoin (7tx/s). The off-chain transaction speed is limited only by the bandwidth between peers. It is important to note that most of the load will be pushed off-chain, so the on-chain speed provided by Bitcoin-NG should be more than enough for cheap and instant transactions.

What makes æternity smart contracts special?

A major advantage of æternity smart contracts is the fact that they can be created off-chain. This allows the interaction with other participating parties to happen incredibly fast and has important privacy implications. The users’ interactions stay off-chain and are kept secure. Only in cases of disagreement, a transaction will be submitted on-chain, allowing the æternity blockchain to function as a crypto-court that settles in favor of the most recent state, signed by all participating parties. Furthermore, since æternity smart contracts don’t share state, there is no limit to the volume of smart contracts that can be processed per second. Smart contracts can also be processed in parallel.

In comparison to the ‘legacy’ Ethereum approach to smart contracts, æternity’s contracts switched from being goto-based to being function-based. This makes it much easier to write more secure smart contract code.

You can watch this video by Erik Stenman recorded during the Code BEAM event in San Francisco for more information about smart contracts. You can also read this informative Steemit article.

What are some of the features of æternity virtual machines?

æternity is building state-of-the-art virtual machines for secure and efficient blockchain computations. There will be three types of virtual machines:

  • An improved version of the EVM (Ethereum Virtual Machine) called AEVM, which was rewritten from scratch in Erlang and will allow æternity to run Sophia smart contracts, as well as Solidity contracts.
  • FAEVM — A fast version of the EVM for running Solidity smart contracts (to be confirmed).
  • The high level virtual machine called FTWVM (Functional Typed Warded Virtual Machine) especially designed for the Sophia smart contract language. This VM enables enterprise-grade smart contract security.
  • The HLM (High Level Machine) used by the Varna smart contract language. The HLM is an efficient virtual machine for (near) Turing complete contracts.

Moreover, the FTWVM & HLM support a specialized tool that can ‘merklize’ the smart contract code. This allows the user to only publish the portion of code that actually gets executed, facilitating much larger smart contracts — gigabytes to terabytes in volume, as long as the part that gets executed is relatively small.

For updated information on æternity’s VMs, please visit GitHub.

Who is in charge of technological development at æternity?

Sascha Hanse is æternity’s full-time blockchain lead developer. In addition, one of æternity’s first contractors — Michal Zajda — is leading the core blockchain development. He will be supported by Erik Stenman, former Chief Scientist of Klarna and Ulf Wiger, former Chief Technical Officer at Erlang Solutions. The work on æternity’s core blockchain protocol is also supported by some of the biggest names from the Erlang community. The list of the brightest and most experienced Erlang developers includes Ulf Wiger, Tobias Lindahl, Thomas Arts and Hans Svensson. Find out more about them in this Steemit article.

An AMA session with Sascha Hanse was organized on 01.12.2017. A summary of the AMA can be accessed here. You can also read an interview with him here.

For a full list of developers that work on the æternity blockchain project, visit the main website.

Will there be different types of nodes in æternity?

There will be only one type of node upon Mainnet launch. However, as æternity evolves, more node types will appear. It is likely that the first ones to appear after the standard one are light and archiving nodes. Many different types of nodes could appear in time, serving different functions in the æternity ecosystem. Here are some examples:

  • Nodes that provide liquidity to the state channels’ network. They will have lots of channels with lots of people, so if a user establishes a channel with them, they will be able to participate in state channel contracts with many users. Using a channel contract through such a node will involve a fee in AE.
  • Nodes that run trustless exchanges could also appear. They will also collect transaction fees. Anyone should be able to start a “centralized server” and use the æternity software to create trustless financial tools.

What is the motivation for programming æternity nodes in both Erlang and Elixir?

Developing Erlang and Elixir æternity clients is done with the goal of better security and improved decentralization. Different and even competing codebases improve the resilience of a blockchain and could lead to enhanced damage control in case of bugs in one of the implementations.

A great example here is the error with the Geth Ethereum client which led to all the Geth nodes freezing. If there was only one client, the entire Ethereum network would have stopped functioning. Since Parity nodes were not affected, however, transaction and smart-contract handling did not cease.

For more relevant information, you can read this blog post on the topic of “Building a Truly Decentralized Blockchain”.

How can one run an æternity node? What are the requirements to start a node?

You can find information on how to start running an æternity node here.

You need to have at least 10GB of free disk space to run a node. It is also recommended to have at least 8GB of RAM if you have the intention to use the node for mining. If your RAM is limited, you can reduce memory requirements. If you experience any issues, have a look at this or ask a question in the mining-dedicated category in the Forum.

We are also working on a detailed guide dedicated to mining.

How much tokens are needed to run a masternode?

æternity does not feature master nodes.

How will the Proof of Stake (PoS) system work? What will its design be? Will it be a Delegated PoS (DPoS)?

æternity’s PoS system will be used only for governance, and not for building consensus on blocks (mining). There is no “staking” in æternity. Users will be able to vote on proposals and signal their opinion about modifications of fundamental system variables (such as the amount of the block reward) with their AE balance. Any user that holds AE tokens can participate in the governance on æternity blockchain via delegated voting, weighted by the amount of tokens they hold.

You can ask any question that you may have in this consensus-dedicated topic in the Forum.

Is it already possible to develop smart contracts for æternity testnet?

Release 0.13.0 introduced significant improvements to smart-contracts functionality which allow for the execution Sophia smart-contracts. You can have a look at a Sophia smart contract implementing Dutch auction here. You can also find detailed information about the syntax and features this Sophia tutorial.

If you experience any issues, you can start a topic in the development category in the Forum.

Will it be possible to build dapps on æternity?

æternity is a decentralized applications platform. Applications on æternity are called æpps. The term “dapps” is usually associated with Ethereum’s applications. Since æternity will support pre-compiled Solidity smart-contracts, dapps will be able to run on æternity’s blockchain platform. Nonetheless, we believe that æpps will become the preferred type of applications on æternity, since they will be based on the more reliable Sophia and Varna smart-contracts, developed specifically with security, efficiency and cost-of use in mind.

The best place to start with æternity’s æpps is If you are an app developer, you can go to You can also learn more about æternity’s smart contracts in this dedicated Steemit article. Join the smart contract discussion in the Forum.

What function do oracles have?

Oracles are used to provide information from the real world to blockchain and smart contracts in particular. That information could be used as a trigger for a smart contract to perform an action, for example -> transfer tokens, cryptocurrency or digital property to specific address(es).

æternity’s oracles are integrated into the core protocol (first class objects) and any user can either become an oracle operator (start providing answers to questions) or ask oracle operators questions by initiating corresponding transactions. As such, there is no need to use an additional layer of smart contracts implementing the oracle. Requesters have to pay a fee in AE for oracle requests. Oracle operators receive a reward in AE for every response they provide.

You can find out more about æternity’s oracles in GitHub. You can also ask questions regarding oracles in the dedicated topic in the Forum.

If you have more questions, please add them in the Forum.

Interested in æternity? Get in touch:

GitHub | Forum | Reddit | Telegram | Twitter | Facebook | Mail

Leave a Reply

Your email address will not be published. Required fields are marked *