Pull Requests

• Squash your commits to ensure each resulting commit is stable and can be tested.

• Include issue numbers in the PR title, e.g. "GH-128. Resolves issue #123".

• Follow the indentation, e.g. provided by .

• Add unit tests for self-contained modules.

• Add integration tests as needed.

• Document new code.

• End all files with a newline

Git Commit Messages

• Use the present tense ("Add feature" not "Added feature")

• Use the imperative mood ("Move cursor to..." not "Moves cursor to...")

• Limit the first line to 72 characters or less

• Reference issues and pull requests liberally after the first line

Learn more about .

Conduct

Contact: or any member you trust.

• We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

Aeternity node

A new blockchain for æpps.

Optimized for scalability via smart contracts inside state-channels.

Has a built-in oracle for integration with real-world data.

Comes with a naming system, for developerability.

Written in Erlang.

To install and run the Aeternity node, see the instructions

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Aeternity node API is documented in the protocol repository.

Swagger API documentation is available online at Aeternity node API documentation

This document describes how to update an Aeternity node using a release binary:

• Manual update;

Manual update

Ubuntu 18.04

Be sure to have a backup of your files, don't remove your node database.

Download the latest version of the æternity node

Once done, stop your node by:

Decompress your new node version overwriting the old version:

And start your node again:

Now check that your node is up and running by :

Expected Behavior

...

Actual Behavior

...

Fourth Lima release candidate.

Changelog:

• Fix Map.to_list crash for large maps in FATE VM.

The node is able to start from a database produced by v4.* releases. For the rest, this release is not backward compatible with v4.* releases.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

is a maintenance Lima release:

• Fixes a bug in FATE VM where bytes(N) as the return type of a remote call would cause the VM to crash.

• Fixes a bug in FATE where the stack could be modified by a remote contract.

• Fixes a bug in FATE where hashing a map could cause the VM to crash.

is a maintenance Lima release.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

is a maintenance Lima release.

• The metric which evaluates contract sizes has been disabled due to excessive computational impact.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

is a maintenance Lima release.

It:

• Provides a finalized height of the blockchain. This further improves fork resistance. The old approach had a flaw that a node was susceptible to following a wrong fork when starting from an existing DB. This change fixes it with following the desired fork instead.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

is an emergency Lima release.

There had been a 51% attack on the network. This release is an expression of the ecosystem's desire to move from the attacker's fork to the community one. If you prefer staying on the former, please use release 5.6.0

This release requires the node to be running without the GC being enabled. If your node has it enabled - the DB is not suitable and your node will likely crash on start. In this case please either sync from the genesis block or download a . Once on the community fork - you can enable the GC.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

Hardware requirements may vary based in what mode the node is running, the network and it is supposed to run full sync or restore from database snapshot. Running a full node to do a full sync being the most resource intensive. Requirements would also vary based on the node configuration, API requests and eventually on future consensus protocol and features.

This recommendations are for nodes part of the Aeternity Mainnet

Last update: October 1, 2024

Summary

Running a full node with full sync now and then (i.e. once per month):

• Intel(R) CPU 2 cores @ 3.0Ghz

• 8GB of RAM

• 500GB SSD storage

• 500GB bandwidth

Processor

A recent generation of Intel(R) 2 CPU logical cores @ 2.5Ghz should cover normal operations. However, during initial full sync the process is also CPU bound, so more cores and higher frequency is recommended, for example 2 CPU cores @ 3.0GHz.

Memory

It is recommended to use at least 8GB RAM. However 4GB of RAM should be also good enough for modest cases.

Storage

During initial full sync the node is very disk I/O intensive. A disk with good I/O throughput is recommended in this case, that's usually a SSDs. However, after the initial sync the node can run perfectly fine on a commodity HDDs.

Full Node

Database size as of the moment of this writing is 270GB and grows with 13.5GB per month. So a reasonable disk space allocation for 1 year horizon would be 450GB.

Lightweight Node

Database size as of the moment of this writing is 60GB and grows with 3GB per month. So a reasonable disk space allocation for 1 year horizon would be 100GB.

Bandwidth

During the normal operations the node needs up to 30KB/s inbound and up to 30KB/s outbound traffic. That's about 78GB/mo per direction or 156GB/mo total.

Notice that, fully utilized chain might go up to 300-500KB/s for gossip traffic.

However during initial full sync this requirement goes as high as 1MB/s but 400KB/s on average inbound traffic.

This is a maintenance Lima release.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to Aeternity node documentation.

This is an emergency Lima release.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to Aeternity node documentation.

This is a maintenance Lima release.

It:

• An API method has been added for state channels that allows the client to tell the fsm to assume that minimum depth has been achieved for a certain tx hash. If used by both clients, it can make a state channel immediately available after creation (and after deposits/withdrawals). The minimum_depth confirmation message is reported as it arrives later.

• Improves the gossiping of orphaned transactions. Now, as soon a transaction ends up on a micro fork, the node broadcasts it to one's peers, even if some of them are still syncing.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

It:

• Fixes an issue where some nodes are stuck and could not sync beyond a certain point.

• Exports a function (aec_chain_state:grant_fees/5) in order to be used in the MDW while doing dry runs.

• Improves the transaction pool to not allow in paying_for transactions that are incorrectly authenticated.

• Improves node performance: use a dirty read when possible while checking a signed transaction

• Introduces some refactoring that is a prerequisite in order to accommodate contract clone primitives.

• Transaction lifecycle is: the transaction is being prepared and posted to a node, then if it is valid it lands in the mempool, it is gossiped to all peers in the network, it is picked by a miner and then included in a block. If a transaction stays in the pool for too long time (2 weeks) and is not included in a block, there might be an issue with it (ex. origin doesn't have enough tokens to spend) and it is garbage collected. There used to be a check ensuring GCed transactions do not end up in the mempool ever again. This PR disables this check.

• An optional setting for transaction garbage collect TTL is available for the node operator to set. It is mempool.tx_ttl and its default value is 2 weeks.

• The transaction pool is being protected by DDos attacks via a caching layer so only new transactions ever reach the pool. There is a new setting for the node operator to define the cache size in amount of transactions to keep. It is mempool.cache_size with a default value of 200.

• Introduced key-header index and fast implementation offind_key_headers_and_hash_at_height using it. This greatly improves performance of BLOCKHASH opcode for both AEVM and FATE.

• Fixes a bug when using HTTP API to fetch contract call data at an already GCed height.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

• Allow all TX types (except ga_meta_tx, paying_for_tx and offchain_tx) in dry-run

• Added new metrics to ae.epoch.aemon namespace

  • block.propagation_time.key : Time until key-blocks reached this node in milliseconds

  • block.propagation_time.micro : Time until micro-blocks reached this node in milliseconds

  • block.time_since_prev.key : Time between key-blocks in milliseconds

  • block.time_since_prev.micro : Time between micro-blocks in milliseconds

  • chain.top.difficulty : Difficulty of the top block

  • forks.micro.count : Count of observed micro-forks

  • forks.micro.height : Height difference of observed micro-forks

• Increased histogram timespan to 1 hour for some aemon metrics

• Changed the default configuration handling of peers to always include the seed nodes (unless explicitly blocked). The idea is to make it harder to exclude the seed nodes by mistake.

• Makes some peer pool parameters configurable:

  • gossiped_peers_count

  • select_verified_peer_probability

  • max_update_lapse

• Sets default select_verified_peer_probability to 1.0 to make sure a peer is selected from the verified pool first.

• Sets default max_update_lapse to 2592000000 (30 days).

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release focused on stability:

• Adds support for community hard-forks. Miners will be able to signal if they support the new protocol version. Depending on the signalling result, the network will switch to a new protocol version or will stay with the current one.

• Adds protocol activated by miner signalling to HTTP /status endpoint

• Improving chain sync - avoid creating duplicate sync tasks.

• Optimize sync, by being more aggressive and drop gossiped blocks that are far in the future. This also reduces the amount of noise in the console.

• State Channels off-chain update requests can now all include meta information objects. This affects methods update, new_contract, contract_call, deposit and withdraw.

• State Channel FSM: allows optionally setting the fee of all on-chain transactions.

• State Channels: Changed calculation of block confirmation times in to be dynamic. Previously the confirmation times would be static for all relevant transactions in a channel. This has been changed to calculate the block confirmation time based on the chosen strategy. For more information check the protocol documentation.

• Adds a functionality to reject updates in State Channel environment.

• Improves stability of channel_force_progress_tx series before a solo closing sequence.

• Improves stability of channel_slash_tx after a channel_close_solo_tx with a payload that had been preceded by a channel_force_progress_tx

• Load regulation for state channel set up was corrected so that requests release the job scheduler sooner, thereby allowing for more channels than regulators:sc_ws_handler:counter. A config value,channels:max_count (default: 1000) is introduced, to limit the total number of active channels on a node.

• Fixes rare crash in FATE VM when updating nested maps in the store.

• Fixes internal API bug which manifests itself during sync on low io throughput devices

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

• Fix docker database compatibility issue by bundling LZ4 and Snappy into RocksDB build

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is the second Iris release candidate.

It:

• Fixed a HTTP API issue: in /v2/ when fetching oracle queries, the client can specify if they want currently open, already closed or simply all queries for that oracle. If no parameter was provided, the endpoint crashed. Now if nothing is specified, all queries are returned as this is the default behaviour for /v3/.

• Fixed a HTTP API issue: in /v3/ when fetching a transaction by hash, if the transaction is ga_attach_tx, the API crashed.

• Fixed a HTTP API issue: in /v3/ when fetching a channel_create_tx, the API crashed.

Please test the iris protocol by activating it in the configuration file as below:

You can also join testnet, the hard fork kicked in there at .

Please let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

• Adds support in the State Channel FSM to detect and properly act upon unexpected channel_force_progress_tx on-chain

• Fix check of contracts which prevented new nodes from syncing from scratch

• When a State Channel responder acceptor times out (accept_timeout), it checks to see whether it should give up or keep trying. This logic was faulty and has now been fixed.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release:

• Cache calls to Contract.creator in FATE engine state.

• Disable unused FATE operation INT_TO_ADDR.

• Improves the checks and tests for close solo and force progress transactions.

The node is able to start from a database produced by v4.* releases, otherwise this release is not backwards compatible.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Iris release.

It:

• Fixes an issue in FATE storage functionality: updating big maps is now even more optimized.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

It:

• Fixes broken swagger version. The version reported breaks semver.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This document describes how to install an Aeternity node using a release binary either by:

• ;

• .

The documentation describes how to install, configure and operate an aeternity node. One can install it from a package, run a docker image or build it themselves. There is also additional documentation on mining with CUDA and build and/or join a Stratum pool.

Index

The Aeternity consensus and sync protocols resolve forks according to the specification in . This means that 51% attacks are still possible, just as with other Proof-of-Work chains.

The Aeternity node implementation offers a few ways to withstand 51% attacks.

Fork resistance via gossip

The configuration variable

limits the height difference allowed for incoming blocks via gossip. This variable has a hard-coded default of 5, but can be changed via the aeternity_config.[yaml|json]

Getting Started

is a maintenance Lima release.

It:

• Bugfix: Exposes the State Channel force progress transaction call result to HTTP API

• Bugfix: Under specific circumstances the store of a contract could be damaged by updating values in the wrong place. A transaction experiencing this would not be valid for peers which are not affected by this bug. The fix ensures the store update is correct.

  This bug affects nodes running v5.4.x and v5.5.x, therefore we advise to upgrade these nodes to prevent any issues from occurring.

is a maintenance Lima release.

It:

• Add helper function aeu_log:set_console_log_level/1. Use it to set the level to warning to remove info logs from the system's console.

• The event and message history kept by the State Channel FSM can now be fetched using the WebSocket API method channels.history.fetch

Second Lima release candidate.

Changelog:

• Remove the rename_db migration command used to migrate Roma databases.

• Remove the custom docker entrypoint. To run the docker image with extra arguments the default command should be used as well, e.g.:docker run aeternity/aeternity bin/aeternity console -noinput -network_id ae_uat see the corresponding docs for details. cat: docs/release-notes/next-lima/PT-168132312-new-name-hash: No such file or directory

is a maintenance Lima release.

• Remove HTTP API endpoint v2/contracts/{hash}/store due to excessive computational impact.

• State Channel FSM: fixes fee computation according to transaction size. Until now close mutual transactions were expecting a fee to be provided by the initiating party, or a default value of 20 000 gas would be used instead.

• State Channel FSM: adds support for an optional gas_price

Fifth Lima release candidate.

Changelog:

• Fix bug in FATE gas computation for Bits operations.

• Change top level namespace from .aet to .chain

The node is able to start from a database produced by v4.* releases. For the rest, this release is not backward compatible with v4.* releases.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

is a maintenance Lima release focused on stability:

• SC clients will now receive a token which will be required for reestablishing a channel or reconnecting to an existing FSM, the token must be persisted and kept secret by the client.

• Removes the user provided password from the state channel API

• Removes the special channel reconnect transaction - reestablishing a channel may now result in reconnecting to an existing FSM

is a maintenance Lima release.

It:

• Upgrades the swagger definition to OAS3.

• Introduces a new query param in relevant HTTP APIs. It is calledint-to-str and specifies that all integers in the response shall be represented as strings instead. This will allow SDKs to pick their preference for the data representation and will help them solve precision issues. This applies only for v3 API that supports oas3 and is not supported by the swagger v2 API

Sixth Lima release candidate.

Changelog:

• Fixes a bug in FATE VM - Call.caller was incorrectly set when returning from a remote contract call.

The node is able to start from a database produced by v4.* releases. For the rest, this release is not backward compatible with v4.* releases.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

is the third Iris release candidate.

It:

• Introduced a new HTTP endpoint: /dry-run. It is part of the external interface and should be preferred over the existing debug endpoint. It comes with some protections for the node: all transactions/calls provided are limited to a total amount of gas that they can consume. There is a new setting in the config where the node operator can change this according to their needs, the default value is 6 000 000 gas. The new endpoint is disabled by default and can be enabled via the new API group dry-run.

This release fixes an issue in v5.5.x which prevented nodes from validating blocks which include transactions which have performed failed remote contract calls. All nodes running v5.5.x should upgrade to this release.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

is the fourth Iris release candidate.

It:

• Fixed the default value of the gas limit for the external dry-run endpoint. It used to have a default of 1 000 000 gas per call and now it is 6 000 000 per call.

• Set height for iris hard fork to happen on block 441444, on 10 June 2021, around 9:11am UTC

You can join testnet

Third Lima release candidate.

Changelog:

• Added infrastructure for deploying contracts (with fresh tokens) during hard forks from Lima release. This will be used to finalize the token migration.

• Added the migrated tokens in the Phase 3 of the token migration.

• Adds one (1) percent of the total initial (ERC20) token supply to an account according to Pool D in https://hackmd.aepps.com/s/H1qF1w1j7#

This release is the fourth release candidate. It:

• Enables signing of micro blocks when using configuration autostart: false

• Makes the number of nodes to gossip to configurable

This release does not introduce backward incompatible changes in the chain format.

Please join the testnet by following the instructions below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

The instructions below describe:

• ;

• ;

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The user configuration is documented in the . For specifying configuration using the Docker image, please refer to .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-0.1.0/priv/swagger.json.

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://18.130.148.7:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

This is a maintenance Lima release candidate focused on stability:

• Adds support for community hard-forks. Miners will be able to signal if they support the new protocol version. Depending on the signalling result, the network will switch to a new protocol version or will stay with the current one.

• Adds protocol activated by miner signalling to HTTP /status endpoint

• Improving chain sync - avoid creating duplicate sync tasks.

• Optimize sync, by being more aggressive and drop gossiped blocks that are far in the future. This also reduces the amount of noise in the console.

• State Channels off-chain update requests can now all include meta information objects. This affects methods update, new_contract, contract_call, deposit and withdraw.

• State Channel FSM: allows optionally setting the fee of all on-chain transactions.

• State Channels: Changed calculation of block confirmation times in to be dynamic. Previously the confirmation times would be static for all relevant transactions in a channel. This has been changed to calculate the block confirmation time based on the chosen strategy. For more information check the protocol documentation.

• Adds a functionality to reject updates in State Channel environment.

• Improves stability of channel_force_progress_tx series before a solo closing sequence.

• Improves stability of channel_slash_tx after a channel_close_solo_tx with a payload that had been preceded by a channel_force_progress_tx

• Load regulation for state channel set up was corrected so that requests release the job scheduler sooner, thereby allowing for more channels than regulators:sc_ws_handler:counter. A config value,channels:max_count (default: 1000) is introduced, to limit the total number of active channels on a node.

• Fixes rare crash in FATE VM when updating nested maps in the store.

• Fixes internal API bug which manifests itself during sync on low io throughput devices

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a Iris test release.

It:

• Fix buggy serialization of contract information - this means compiler version is actually stored on chain, and isn't replaced by "unknown".

• Added AENS.update to FATE VM

• Added AENS.lookup and Oracle.expiry lookup functions to FATE VM

• Fixed bug regarding TTL of preclaims in FATE VM - it was incorrectly always set to 0, from VM_FATE_SOPHIA_2 it has the correct value.

• Fixed bug in AENS.resolve in FATE VM - for invalid names VM_FATE_SOPHIA_1 will crash. From VM_FATE_SOPHIA_2 it will not crash, rather return None.

• Changed Chain.block_hash - in VM_FATE_SOPHIA_2 it will returnSome(<blockhash>) for Chain.block_height (i.e. current generation) previously it returned None. With Bitcoin-NG we do have the block hash of the current generation, so no reason not to allow this.

• Extend AENS name max expiration time from 50000 generations (~100 days) to 180000 generations (~375 days).

• Changes how a meta transaction TTL's is being validated: so far it used to be the outermost transaction's ttl that was taken into account, now it is the innermost one instead. Meta transactions no longer have TTL.

• Fixes a protocol issue: a valid force progress call with invalid CallData or failing call will result in on-chain transaction but tokens from the caller would still be moved to the forced contract. This is fixed and failed calls in successful force progress transactions result in rollback of the off-chain balances.

• Improves the functionality of State Channel delegates: now they can providechannel_solo_snapshot_tx as well. This is really handy in cases one party is missing and the other is doing malicious force progress on-chain while the channel is still open.

• Revisits the State Channel delegates: so far they were a shared list for both participants. From Iris on, delegates are per peer: there is a list of delegates for the initiator and another one for the responder. Old channel objects can still be used but users are strongly recommended to reset their delegates list if they had any. Note that the HTTP representations are changed accordingly.

• Allows delegates to force progress on behalf of the user that authorized them to do so.

• Improved garbage collector for all Fate contracts form Iris

• Fate contracts of different versions can call each other (Fate1 can call Fate2 and vice-versa)

• Opcode availability and behaviour depends on VM version of the contract (Fate2 opcodes are available both when Fate2 contract is called directly and when called by another (possibly Fate1) contract)

Please test the iris protocol by activating it in the configuration file as below:

Please let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

It:

• Enchances the p2p noise protocol with an optional setting to ask a peer for the version of their node. A node operator can set one's node to not respond to this message if one considers this a private information. This is to be used for monitoring the network's health.

• Enhances FSM behaviour: when the initiator is offline, allows the responder to stay online waiting for it even if the timeout timer is reached.

• Configuration values can now be set using OS environment variables, where the environment variable name is on the form AE__k1__k2, e.g. AE__CHAIN__PERSIST=true. Note that two underscores are used to separate each level. Structured values must be JSON-encoded. The prefix AE can not be customized. The environment variables are applied after reading an available config file, and all values are checked against the schema. See docs/configuration.md.

• Introduces persistence of the peer pool: if the node flag for disc persistence is set, after a node restart old peers are loaded from the DB. Trusted peers are provided to the node from the config file so they are already persisted. Since the time being off is unknown, all peers are loaded asunverified, even if they had been verified before the node stop.

• Changes the default value and significantly speeds up the TCP probes. Those used to be done roughly once every 2 minutes while now they are executed every second. Note that this is done only if there are peers to be checked: if a peer is missing, there is a grace period in which we mark it as 'suspended', waiting for its return. If all peers are checked, we wait longer - until either a new peer is added or there is a not-suspended peer. Basically the probes come on demand. Even despite the probes are fast, there is a maximum size of currently ongoing probes.

• Fixes the process of probing verified peers. Until now we were probing only unverified peers. If a peer responds to the probe - we consider it verified. We downgrade a verified peer only after we fail connecting to it. This resulted in amounting peers that used to be verified at one point of time. This is fixed now as we probe verified peers as well. What is more is, that this PR plays really well with PR #3365. This means that if a peer goes down, we will find it significantly sooner and will downgrade it as an unverified one. This is important as a nodes shares to other nodes only peers one considers to be verified.

• Added support for reporting chain events during contract evaluation. These events are published internally as 'tx_events' (available e.g. for plugins), and can also be fetched via the HTTP 'dry-run' method. The events are presented as 'dummy' transactions, unsigned, reflecting the details of the respective events.

• Fixes a bug: there are special trusted peers that are never deleted nor downgraded. Those are quite unique as the node considered them to be available. One can pick their own set of trusted peers but this was not really effective: the default peers were always included as a bonus. This PR fixes it: if the new config flag is set to false - the defaults are omitted. The flag is called include_default_peers and by default it is true.

• There used to be multiple copies of the same peers in peers pool. This resulted in propagation of same peers with different Peer IDs through the network. Now duplicates are cleaned up.

• Some further peers fine tuning: we used to treat peers that refuse connecting to us as they were malicious. This was the case no matter if peers were active and part of the network and only simply refusing to open aenoise connection to our node (most likely because their inbound pool is staturated already). This is now changed and if the node is responding but refusing to open an enoise connection - we consider it still a valid and verified participant of the network.

• Improves sync's peer propagation: peers are split into verified and unverified. We had allowed a grace period for peers to be down while the node still considers them as verified and broadcasts them as such. Once a verified peer is being detected as down, it enters a standby state that allows them to stay verified. This PR tightens the process - once a peer is being detected to be unreachable - it is being downgraded from verified to unverified immediately. The processing of unverified being deleted is left unchanged - they still enter the standby mode for a few times before being removed.

• Fixes inconsistency of the /status endpoint

• Provides some fine tuning to the supervision tree of the conductor. This will prevent the node making too many recovery attempts after a crash.

• Enhances FSM behaviour: when the initiator is offline, allows the responder to stay online waiting for it even if the timeout timer is reached.

• Adds an explicit settings for local_lima_testnet. So far those were implicit as Lima is the currently running release. The MDW though uses a macro to parse those and if there is no explicit function head - it fails. This aims at providing the MDW with capabilities to work with a local Lima test environment.

• Due to MacOS High Sierra reaching EOL status we no longer build and provide release binaries for MacOS High Sierra. MacOS Mojave and above is supported.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

It:

• Upgrades the swagger definition to OAS3.

• Introduces a new query param in relevant HTTP APIs. It is calledint-to-str and specifies that all integers in the response shall be represented as strings instead. This will allow SDKs to pick their preference for the data representation and will help them solve precision issues. This applies only for v3 API that supports oas3 and is not supported by the swagger v2 API

• Allows passing strings instead of integers in post requests for debug APIs that are convenience for testing and developing SDKs.

• Introduces a second HTTP specification. This is to provide the new OAS3 API under /v3/ while we keep the Swagger v2 API unchanged under /v2/. This aims to provide a smooth transition from old specification to the new one. The new API is to be finalized with iris hardfork, please do not depend on it yet.

• Expands the /api endpoint with an option: while simply calling /api keeps the old behaviour, calling /api?oas3 will provide the new OAS3 spec instead.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release candidate.

It:

• Enchances the p2p noise protocol with an optional setting to ask a peer for the version of their node. A node operator can set one's node to not respond to this message if one considers this a private information. This is to be used for monitoring the network's health.

• Enhances FSM behaviour: when the initiator is offline, allows the responder to stay online waiting for it even if the timeout timer is reached.

• Configuration values can now be set using OS environment variables, where the environment variable name is on the form AE__k1__k2, e.g. AE__CHAIN__PERSIST=true. Note that two underscores are used to separate each level. Structured values must be JSON-encoded. The prefix AE can not be customized. The environment variables are applied after reading an available config file, and all values are checked against the schema. See docs/configuration.md.

• Introduces persistence of the peer pool: if the node flag for disc persistence is set, after a node restart old peers are loaded from the DB. Trusted peers are provided to the node from the config file so they are already persisted. Since the time being off is unknown, all peers are loaded asunverified, even if they had been verified before the node stop.

• Changes the default value and significantly speeds up the TCP probes. Those used to be done roughly once every 2 minutes while now they are executed every second. Note that this is done only if there are peers to be checked: if a peer is missing, there is a grace period in which we mark it as 'suspended', waiting for its return. If all peers are checked, we wait longer - until either a new peer is added or there is a not-suspended peer. Basically the probes come on demand. Even despite the probes are fast, there is a maximum size of currently ongoing probes.

• Fixes the process of probing verified peers. Until now we were probing only unverified peers. If a peer responds to the probe - we consider it verified. We downgrade a verified peer only after we fail connecting to it. This resulted in amounting peers that used to be verified at one point of time. This is fixed now as we probe verified peers as well. What is more is, that this PR plays really well with PR #3365. This means that if a peer goes down, we will find it significantly sooner and will downgrade it as an unverified one. This is important as a nodes shares to other nodes only peers one considers to be verified.

• Added support for reporting chain events during contract evaluation. These events are published internally as 'tx_events' (available e.g. for plugins), and can also be fetched via the HTTP 'dry-run' method. The events are presented as 'dummy' transactions, unsigned, reflecting the details of the respective events.

• Fixes a bug: there are special trusted peers that are never deleted nor downgraded. Those are quite unique as the node considers them to be available. One can pick their own set of trusted peers but this was not really effective: the default peers were always included as a bonus. This PR fixes it: if the new config flag is set to false - the defaults are omitted. The flag is called include_default_peers and by default it is true.

• There used to be multiple copies of the same peers in peers pool. This resulted in propagation of same peers with different Peer IDs through the network. Now duplicates are cleaned up.

• Some further peers fine tuning: we used to treat peers that refuse connecting to us as they were malicious. This was the case no matter if peers were active and part of the network and only simply refusing to open aenoise connection to our node (most likely because their inbound pool is staturated already). This is now changed and if the node is responding but refusing to open an enoise connection - we consider it still a valid and verified participant of the network.

• Improves sync's peer propagation: peers are split into verified and unverified. We had allowed a grace period for peers to be down while the node still considers them as verified and broadcasts them as such. Once a verified peer is being detected as down, it enters a standby state that allows them to stay verified. This PR tightens the process - once a peer is being detected to be unreachable - it is being downgraded from verified to unverified immediately. The processing of unverified being deleted is left unchanged - they still enter the standby mode for a few times before being removed.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

• Refactor fetching of (forward) generations. This avoids a slow check for chain inclusion and will speedup v2/generations/height/<height> andv2/generations/hash/<kh_...>

• Added new metrics covering extended block information

  • ae.epoch.aemon.block.tx.total.micro : Number of transactions in a microblock

  • ae.epoch.aemon.block.gas.total.micro : Gas used per microblock

  • ae.epoch.aemon.block.gas.per_tx.micro : Gas used per transaction in a microblock

  • ae.epoch.aemon.block.size.per_tx.micro : Size of transactions in a microblock in bytes

  • ae.epoch.aecore.blocks.micro.txs_execution_time.success : Execution time of all transaction in a microblock in microseconds

  • ae.epoch.aecore.blocks.micro.txs_execution_time.error : Execution time of all transaction in a microblock in microseconds, when an error was encountered

  • ae.epoch.aecore.blocks.micro.insert_execution_time.success : Execution time of insertion of a microblock in microseconds

  • ae.epoch.aecore.blocks.micro.insert_execution_time.error : Execution time of failed insertion of a microblock in microseconds

  • ae.epoch.aecore.blocks.key.insert_execution_time.success : Execution time of insertion of a keyblock in microseconds

  • ae.epoch.aecore.blocks.key.insert_execution_time.error : Execution time of failed insertion of a keyblock in microseconds

• Added new metrics covering contract call information The following names act as templates for multiple specific metrics. The placeholders in these names are (in order) for ABI version, VM version, return type and actual info type. The return type may be ok, return or revert. The info type may be gas_used, execution_time in microseconds,state_size or call_data_size, both in bytes.

• Improve the algorithm in agree_on_height. It now starts looking near the top, and it keeps the right top hash during the whole algorithm.

• The default configuration for the Erlang runtime system has been adapted to use less CPU cores and threads. This should improve CPU contention on systems with fewer cores and improve responsiveness. For systems with 4+ CPU cores the settings can be increased if the node is experiencing any form of CPU limitations.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

First Lima release candidate.

Changelog:

• We now have FATE. (The initial version of FATE is released as VM version 0x05).

• The channel_close_mutual transaction can now be performed while the channel is not active on-chain (The channel solo closing sequence had been initiated and the channel is not yet closed), this is a consensus breaking change available after the Lima fork.

• The state channel FSM after the Lima fork accepts a shutdown message while the channel is being closed unilaterally.

• Introduces AEVM version 0x06, available from Lima consensus. This is a fine-tuned version of the AEVM version 0x04 introduced in the Fortuna consensus.

• Extends transaction signing - also allow signatures of the transaction hash. The transaction serialization is potentially long, so signing the transaction hash means less cryptographic work.

• Obsoletes the old State Channel off-chain transaction type which contained the list of updates that produced the latest state_hash. The new transaction type is available since Fortuna hard fork and the FSM is producing such transactions ever since. This detaches the off-chain protocol from the on-chain one and allows development of unique off-chain protocols that don't need their updates to be serializable on-chain.

• For existing state channels where the latest co-authenticated state is an off-chain transaction based on the old version, it is suggested to make a new co-authenticated transaction which is using the new serialization. For currently existing state channels which latest co-authenticated state is an old version off-chain transaction is suggested to make a new co-authenticated transaction that is using the new serialization. If the other party refuses to authenticate a new round or is simply missing, one can use the solo closing sequence instead.

• Metadata objects (of type binary) can now be added to an offchain update transfer request. These objects serve as comments and are not part of the signed transaction, nor do they affect the offchain state trees. This is an incompatible change in the serialization of offchain updates, but old offchain updates can still be deserialized. When creating a channel with a party running an older node version, add version_offchain_update=1 to the channel params.

The node is able to start from a database produced by v4.* releases. For the rest, this release is not backward compatible with v4.* releases.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This is a maintenance Lima release.

It:

• Introduces an external HTTP endpoint(/v2/status/chain-ends) which reports keyhashes for which no successor is present in the database. Useful for retrieving orphan blocks and tracking chain reorganizations.

• Introduces configurable fork resistance (sync:sync_allowed_height_from_top), which lets a node reject long forks injected via the sync protocol. Documented in docs/fork-resistance.md

• HTTP endpoint names/<name> now also returns a field owner containing the account owning the name.

Please join the mainnet by following the instructions in the documentation below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This document describes:

• ;

• ;

• ;

Rebar3 is the standard Erlang build tool

Common commands are:

• rebar3 help

• rebar3 get-deps

• rebar3 compile

is the first release candidate. It:

• Adds response TTL to Oracle query response TX - a required parameter. This affects consensus.

• Adds JSON-RPC support in the state channel WebSocket API. The previous API remains supported for now. Support for JSON-RPC request batches implemented but not yet tested.

• Forbids certain prim-ops to be run in off-chain contracts

is the seventh release candidate. It:

• Updates genesis accounts

• Sets target for the genesis block

• Increases the amount of nodes that new information is gossiped to

is a maintenance release. It:

• Fine tunes the severity of the log message in case of invalid request on the user HTTP API - from warning to info.

• Details the Sophia compiler error reason, returned in the HTTP response body of path /debug/contracts/code/compile. This is a backward compatible enhancement of the user HTTP API.

• Fine tunes the validation of user API requests. The request body must be smaller than approx. 5 MB (was 8 MB) and must be received within 10 s (was 15 s).

This document describes how to build an Aeternity node from source on:

• Ubuntu 20.04 LTS

• MacOS (latest)

• Archlinux 20210404

is the sixth release candidate. It:

• New error handling for smart contracts. This affects consensus.

• Increase gossiping of created blocks.

This release introduces backward incompatible changes in the chain format:

• After upgrading your node, you will not have your previous balance (even if you keep your key pair);

This release is the third release candidate. It:

• Include the Network ID in the P2P Handshake to avoid that differently configured nodes talk to each other by mistake. This affects P2P communication and this version is not able to talk to earlier versions.

This release introduces backward incompatible changes in the chain format:

• After upgrading your node, you will not have your previous balance (even if you keep your key pair);

• Please ensure that you do not reuse a persisted blockchain produced by the previous releases "v1.0.0-rc2".

Please join the testnet by following the instructions below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

The instructions below describe:

• ;

• ;

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The user configuration is documented in the . For specifying configuration using the Docker image, please refer to .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-0.1.0/priv/swagger.json.

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://18.130.148.7:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

Introduction

Please note that this application is in alpha state.

By setting the configuration value stratum > enabled to true, the node starts Aestratum app. Aestratum app is an implementation of server side part of the stratum protocol suited for Aeternity network [https://github.com/aeternity/protocol/blob/master/STRATUM.md]. The purpose of the protocol is to formalize the coordination of information exchange between pool server and pool clients.

Aestratum app is part of the Aeternity node, but in the future we may move this functionality to a separate executable. Enabling stratum server causes that the node doesn't mine the solutions for proof of work locally, but allows user to form mining pools and act as a pool operator. For providing the pool to individual miners, a pool operator can specifying the percentage of the reward they withhold from mined block rewards.

An Aestratum client [https://github.com/aeternity/aestratum_client] connects to operator pool node (Stratum server), and solves cryptographic puzzles. The server sends jobs to clients, they try to solve them and send their results (called shares) back. The server keeps targets for each client in line with its computational power and distributes rewards accordingly. When miner finds the result artefacts of the Cuckoo Cycle algorithm - nonce and proof of work, the miner is awarded a share in a mining epoch happening between two subsequent key blocks of the chain. A share can be understood as a smallest unit of eligible right to be paid out if the share was created in the mining epoch to be rewarded. If the difficulty of the solution matches the difficulty of the main network, we can combine the block candidate with the computed nonce and proof of work, construct a next block and publish it.

If the network accepts our new block, the node which constructed that next block will receive a mining reward. This reward will be used for paying out the participants which submitted shares during mining epochs. When stratum app notices that the latest keyblock has changed, stratum looks back 180 (BENEFICIARY_REWARD_DELAY) epochs behind the top keyblock and locates two (configurable) subsequent mining epochs. Miners who contributed their shares to these mining epochs will be paid out proportionally to their contribution, with miner difficulty also taken into account. The rewarding scheme is called PPLNS - Pay Per Last N Shares [https://virtopia.ca/what-is-pplns/].

The payout of the rewards to pool operators and miners is executed by payout contract deployed to the main net at [https://explorer.aepps.com/#/tx/th_2raHdPQ8xtbE6oKh3z1pFmUpyFC5H7ZTBkNB8TuVydJjwedduL]. Submitting of contract call transaction to the operator node invokes the contract functionality and changes the balances of the rewarded participants. The contract's source code can be seen here: [https://github.com/aeternity/aeternity/blob/master/apps/aestratum/priv/Payout.aes]

The frequency of payments depends on how often the clients of the pool find a share with the same difficulty as the main net. Ideally, miners with CUDA hardware are mining for the pool, as that significantly increases a chance to find a solution with acceptable difficulty.

Several improvements are planned for Aestratum, also depending on the feedback from community:

• proxy for miners (for a miner with multiple mining devices)

• separation of Aestratum from Aeternity Node

• simple web based gui for better insight

Configuration

Example configuration section in your aeternity.yaml configuration file could look as follows:

The mining > autostart must be set to true.

Since mining locally and enabled stratum are mutually exclusive, the mining > beneficiary is not used when stratum is enabled. Instead, the stratum > reward > beneficiaries will receive the rewards from operating of the pool.

When stratum is started for the first time and no keypair is found in the configured location (stratum > reward > keys > dir), the keypair is automatically generated and placed in the configured location for next time.

It is advised to backup this keypair, as it may hold some tokens received in the last 180 keyblocks.

Do not forget to put your accounts in stratum > reward > beneficiaries.

Connection

host - (optional) - used only for identification of the pool (default "localhost")

port - (optional) - denotes what port should clients connect to (default 9999)

max_connections - (optional) - max number of connected mining clients (default 1024)

num_acceptors - (optional) - max number of active acceptor processes handling clients requests (default 100)

transport - (optional) - what mode of transport for data to use (default "tcp", to be tested: "ssl")

Session

extra_nonce_bytes - (optional) - nonce (a number) has 8 bytes, and is composed of two parts - extra nonce and miner nonce. Extra nonce is a randomly chosen (unique) number by the stratum server. When a client connects to stratum, it receives an extra nonce and tries to find a miner nonce. There is an interdependence among max_connections and extra_nonce_bytes: max_connections must be at most (2^(extra_nonce_bytes * 8)) / 2. For example - if you set extra_nonce_bytes to 1, max_connections shouldn't exceed 128. (1 byte can represent 256 numbers, and since we need to choose from them, we divide that range by 2). (default 4)

skip_num_blocks - (optional) - a new keyblock candidate is generated roughly every 3 seconds. skip_num_blocks determines how many of these candidates are skipped before a new job is sent to miner. (default 10)

initial_share_target - when a miner connects, we cannot immediately determine his mining power. For this reason, we give this new miner a job with the lowest difficulty (highest target).

max_share_target - maximal target (or, minimal difficulty) of the shares a pool accepts. If you lower the target, you raise the minimal difficulty which puts a strain on miners with weaker hardware.

desired_solve_time - (optional) - is the amount of time (in seconds) the server expects a miner to send a mined share. If this time is too short for a miner to produce a result, the server adjusts difficulty of the next job sent to the miner. (default 30)

max_solve_time - (optional) - specifies a time limit (in seconds) stratum app understands as time needed for producing a share, even when miner didn't submit a share at all. (default 60)

share_target_diff_threshold - (optional) - stratum app measures how long it took a miner to produce a share, or, uses max_solve_time in case no share was submitted. For the succeeding jobs being sent to the miner, a recalculation of the difficulty is in order. If the difference between the new difficulty and previous difficulty is larger than share_target_diff_threshold (in percentages), the new difficulty is used for succeeding jobs sent to miner. This is done by sending set_target notification to the miner. If the difference is smaller than the threshold, the previous difficulty is used for the following jobs. (default 5.0)

edge_bits - (optional) - a proof of work algorithm we use, called Cuckoo Cycle, looks for a cycle in randomly generated graph. edge_bits determines how long this cycle should be. You should only change this value if you plan to deploy your own network, because in order for this change to work, you will need to distribute a new mining client. (default 29)

max_jobs - (optional) - max number of jobs kept in queue for each client. Lower number of max_jobs results in more frequent changes via set_target notification. (default 20)

max_workers - (optional) - max number of workers for one connection. This is not fully implemented yet, will be required for a proxy implementation. (default 20)

msg_timeout - (optional) - timeout (in milliseconds) guards transitions between miner states (connected, configured, subscribed). If a transition doesn't happen within a specified time, the client session is closed. (default 15)

Reward

reward_last_rounds - (optional) - denoted how many epochs between keyblocks are rewarded out of the received mining reward. Higher number of epochs would cause that the mining reward will be distributed to more shares, but each partial reward will be smaller. Higher number incentivizes loyalty among miners, by raising a chance of rewarding miners who contributed shares for a longer period of time. (default 2)

beneficiaries - is a list in format "account_address:percent_share" - denotes the pool operator addresses with their respective shares. The sum of shares must be less than or equal to 100. The sum of shares equal to 100 effectively means that all rewards coming from mining are distributed to pool operators, while miners don't receive any reward.

keys > dir - points to a location where to a stratum account keypair is stored. Since we want to send tokens to miners from this account, we need to have access to its private key. The stratum account holds reward(s) from mining which are scheduled to be paid out via a payment contract. While it may sound tempting, stratum account should never have any significant accumulated wealth since it only serves as a temporary place for holding rewards received, before they are distributed to the miners. This is happening regularly and funds are not accumulated in this account for longer periods of time. If dir represents a relative path, the directory will be in priv directory of estratum app. Providing an absolute path allows storing a keypair outside the aestratum app.

This is the stable Minerva release. It contains:

• The finalization of the Minerva consensus protocol version - in mainnet.

• Feature refinements.

Please refer to the notes below for details and backward compatibility.

Regarding the Minerva consensus protocol upgrade on mainnet, this release:

• Sets the Minerva mainnet hard fork height to block 47800 (approximately 6th Mar 2019 1pm CET).

• Adds all tokens migrated in phase 1 of the token migration. This takes effect at the Minerva mainnet hardfork height.

Regarding feature refinements:

• More consistent handling of defaults for state channel on-chain transactions

• If a fee is specified for an on-chain state channel tx, but is too low, an error will be raised. If no fee is specified, a default fee 10% above the minimum is chosen.

• If a channel shutdown is requested, but the balances are insufficient to cover the transaction fee, the shutdown request will be rejected right away.

• Introduce a configuration parameter for miners - the minimum gas price that they are willing to accept.

This release is backward compatible with v2.0.0-rc.1.

Please join the mainnet by following the instructions below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

The instructions below describe:

• ;

• ;

• .

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The instructions for configuring the node using the Docker image are in .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-*/priv/swagger.json (you will need to amend the wildcard * placeholder in the path with the version).

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join the mainnet

Mainnet seed nodes

The release package comes preconfigured with seed nodes. Here is example subset of the seed nodes:

• aenode://pp_2L8A5vSjnkLtfFNpJNgP9HbmGLD7ZAGFxoof47N8L4yyLAyyMi@18.136.37.63:3015

• aenode://pp_2gPZjuPnJnTVEbrB9Qgv7f4MdhM4Jh6PD22mB2iBA1g7FRvHTk@52.220.198.72:3015

• aenode://[email protected]:3015

• aenode://pp_2mwr9ikcyUDUWTeTQqdu8WJeQs845nYPPqjafjcGcRWUx4p85P@3.17.30.101:3015

Inspect the mainnet

Here are example nodes that can be used to inspect current top block and see information about e.g. height or target:

• http://18.136.37.63:3013/v2/blocks/top

• http://52.220.198.72:3013/v2/blocks/top

• http://13.53.114.199:3013/v2/blocks/top

• http://13.53.149.181:3013/v2/blocks/top

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Testnet seed nodes

In order to join testnet reconfigure seed nodes in the release package:

• aenode://pp_QU9CvhAQH56a2kA15tCnWPRJ2srMJW8ZmfbbFTAy7eG4o16Bf@52.10.46.160:3015

• aenode://pp_27xmgQ4N1E3QwHyoutLtZsHW5DSW4zneQJ3CxT5JbUejxtFuAu@13.250.162.250:3015

• aenode://pp_DMLqy7Zuhoxe2FzpydyQTgwCJ52wouzxtHWsPGo51XDcxc5c8@13.53.161.215:3015

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://13.53.161.215:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

This is a maintenance release. It contains stability improvements so all users are encouraged to upgrade.

It:

• Makes the cleanup of the UPnP/NAT-PMP port mapping when the operator stops the node more robust.

• Enhances the stability of the Noise-based connections used for syncing and gossiping blocks.

• Enhances the stability of state channels.

This release is backward compatible with v1.3.*, v1.2.*, v1.1.* and v1.0.*.

Please join the Roma network by following the instructions below, and let us know if you have any problems by . Troubleshooting of common issues is documented .

The instructions below describe:

• ;

• ;

• .

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The instructions for configuring the node using the Docker image are in .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-*/priv/swagger.json (you will need to amend the wildcard * placeholder in the path with the version).

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join Roma network

Roma network seed nodes

The release package comes preconfigured with seed nodes. Here is example subset of the seed nodes:

• aenode://pp_5mmzrsoPh9owYMfKhZSkUihufDTB6TuayD173Ng464ukVm9xU@35.178.61.73:3015

• aenode://pp_2KWhoNRdythXAmgCbM6QxFo95WM4XXGq2pjcbKitXFpUHnPQc3@35.177.192.219:3015

• aenode://pp_2L8A5vSjnkLtfFNpJNgP9HbmGLD7ZAGFxoof47N8L4yyLAyyMi@18.136.37.63:3015

• aenode://pp_2gPZjuPnJnTVEbrB9Qgv7f4MdhM4Jh6PD22mB2iBA1g7FRvHTk@52.220.198.72:3015

Inspect Roma network

Here are example nodes that can be used to inspect current top block and see information about e.g. height or target:

• http://35.178.61.73:3013/v2/blocks/top

• http://35.177.192.219:3013/v2/blocks/top

• http://18.136.37.63:3013/v2/blocks/top

• http://52.220.198.72:3013/v2/blocks/top

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Testnet seed nodes

In order to join testnet reconfigure seed nodes in the release package:

• aenode://pp_QU9CvhAQH56a2kA15tCnWPRJ2srMJW8ZmfbbFTAy7eG4o16Bf@52.10.46.160:3015

• aenode://pp_27xmgQ4N1E3QwHyoutLtZsHW5DSW4zneQJ3CxT5JbUejxtFuAu@13.250.162.250:3015

• aenode://pp_nt5N7fwae3DW8Mqk4kxkGAnbykRDpEZq9dzzianiMMPo4fJV7@18.130.148.7:3015

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://18.130.148.7:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

This is a maintenance release. It:

• Reduces the parameters required when reestablishing a state channel from the WebSocket user API. The node retrieves the rest of the parameters from the on-chain channel indicated by the specified channel identifier parameter. Please refer to the documentation of the intended usage of the user API for details.

This release is backward compatible with previous v2.3.* and v2.2.* releases.

Please join the mainnet by following the instructions below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

The instructions below describe:

• ;

• ;

• .

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The instructions for configuring the node using the Docker image are in .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-*/priv/swagger.json (you will need to amend the wildcard * placeholder in the path with the version).

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join the mainnet

Mainnet seed nodes

The release package comes preconfigured with seed nodes. Here is example subset of the seed nodes:

• aenode://pp_2L8A5vSjnkLtfFNpJNgP9HbmGLD7ZAGFxoof47N8L4yyLAyyMi@18.136.37.63:3015

• aenode://pp_2gPZjuPnJnTVEbrB9Qgv7f4MdhM4Jh6PD22mB2iBA1g7FRvHTk@52.220.198.72:3015

• aenode://[email protected]:3015

• aenode://pp_2mwr9ikcyUDUWTeTQqdu8WJeQs845nYPPqjafjcGcRWUx4p85P@3.17.30.101:3015

Inspect the mainnet

Here are example nodes that can be used to inspect current top block and see information about e.g. height or target:

• http://18.136.37.63:3013/v2/blocks/top

• http://52.220.198.72:3013/v2/blocks/top

• http://13.53.114.199:3013/v2/blocks/top

• http://13.53.149.181:3013/v2/blocks/top

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Testnet seed nodes

In order to join testnet reconfigure seed nodes in the release package:

• aenode://pp_QU9CvhAQH56a2kA15tCnWPRJ2srMJW8ZmfbbFTAy7eG4o16Bf@52.10.46.160:3015

• aenode://pp_27xmgQ4N1E3QwHyoutLtZsHW5DSW4zneQJ3CxT5JbUejxtFuAu@13.250.162.250:3015

• aenode://pp_DMLqy7Zuhoxe2FzpydyQTgwCJ52wouzxtHWsPGo51XDcxc5c8@13.53.161.215:3015

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://13.53.161.215:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

This is a backwards-compatible bug fix release for the Fortuna release 3.0.0. It:

• Solves an issue with loading old serialization ofchannel_force_progress_tx from the database and updating it to the new serialization format.

Please join the mainnet by following the instructions below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

The instructions below describe:

• How to retrieve the released software for running a node;

• ;

• .

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The instructions for configuring the node using the Docker image are in .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-*/priv/swagger.json (you will need to amend the wildcard * placeholder in the path with the version).

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join the mainnet

Mainnet seed nodes

The release package comes preconfigured with seed nodes. Here is example subset of the seed nodes:

• aenode://pp_2L8A5vSjnkLtfFNpJNgP9HbmGLD7ZAGFxoof47N8L4yyLAyyMi@18.136.37.63:3015

• aenode://pp_2gPZjuPnJnTVEbrB9Qgv7f4MdhM4Jh6PD22mB2iBA1g7FRvHTk@52.220.198.72:3015

• aenode://[email protected]:3015

• aenode://pp_2mwr9ikcyUDUWTeTQqdu8WJeQs845nYPPqjafjcGcRWUx4p85P@3.17.30.101:3015

Inspect the mainnet

Here are example nodes that can be used to inspect current top block and see information about e.g. height or target:

• http://18.136.37.63:3013/v2/blocks/top

• http://52.220.198.72:3013/v2/blocks/top

• http://13.53.114.199:3013/v2/blocks/top

• http://13.53.149.181:3013/v2/blocks/top

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Testnet seed nodes

In order to join testnet reconfigure seed nodes in the release package:

• aenode://pp_QU9CvhAQH56a2kA15tCnWPRJ2srMJW8ZmfbbFTAy7eG4o16Bf@52.10.46.160:3015

• aenode://pp_27xmgQ4N1E3QwHyoutLtZsHW5DSW4zneQJ3CxT5JbUejxtFuAu@13.250.162.250:3015

• aenode://pp_DMLqy7Zuhoxe2FzpydyQTgwCJ52wouzxtHWsPGo51XDcxc5c8@13.53.161.215:3015

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://13.53.161.215:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

This document describes how to configure network monitoring within the node provided by aemon application.

Configuration

By default monitoring is disabled. To turn it on monitoring.publisher.pubkey and monitoring.active = true need to be setup. To start posting transaction setup monitoring.publisher.autostart to true.

To post transactions account's public and private key is needed. For online processing only public key needs to be configured. Offline post-processing can be done by filtering transaction by publisher public key.

Metrics configuration

Monitoring uses statsd backend provided by apps/aecore/src/aec_metrics.erl. See metrics metrics.* configuration keys in apps/aeutils/priv/aeternity_config_schema.json

Metrics

Each metric uses ae.epoch.aemon. prefix.

How to read metrics

confirmation.delay

represents network latency. A high number might imply a busy network or unfair leaders.

forks.micro & gen_stats.microblocks.total

forks.micro represents the length of microfork. It shows a minimum number observed by monitoring, not an exact one. Based on behaviour observed in mainnet in the first half of 2019, roughly 33% of microblocks transactions are rewritten to the next generation. Use gen_stats.microblocks.total as a reference.

gen_stats.microblocks.total and gen_stats.tx.{monitoring,total}

Statistic metrics can be used to measure network saturation

publisher.post_tx.*

Metrics can be used to monitor mempool's transaction propagation. When publisher.post_tx.nonce_too_high is preset you might want to check mempool.nonce_offset configuration/

publisher.queue.*

For further network transaction propagation investigation. All transactions accepted by mempool are tracked by *.size. Over time it should correlate with gen_stats.tx.monitoring.

*.ttl_expired might imply low transaction fee or busy network.

This release is the fifth release candidate. It:

• Fixes the content of the /key-blocks/pending API in case autostart: false.

This release does not introduce backward incompatible changes in the chain format.

Please join the testnet by following the instructions below, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.

The instructions below describe:

• ;

• ;

• .

Retrieve the software for running a node

You can run a node by either:

• Installing the published corresponding to your platform; or

• Running the published ; or

• .

The user configuration is documented in the . For specifying configuration using the Docker image, please refer to .

The node user API is documented:

• HTTP API endpoints are specified ;

  • A JSON version of the same specification is located in the node at path lib/aehttp-0.1.0/priv/swagger.json.

  • The JSON version can be obtained from a running node using the endpoint /api.

Install node

The instructions for installing a node using a release binary are in .

For installation of a node using the Docker image, please refer to .

Join the testnet

This section describes how to run a node as part of the testnet - the public test network of nodes - by using the release binary.

For running a node as part of the testnet by using the Docker image, please consult in addition to this section.

Inspect the testnet

The core nodes of the public test network are accessible from the Internet.

Information, e.g. height, of the top block of the longest chain as seen by these core nodes of the testnet can be obtained by opening in the browser any of the following URLs:

• http://52.10.46.160:3013/v2/blocks/top

• http://13.250.162.250:3013/v2/blocks/top

• http://18.130.148.7:3013/v2/blocks/top

Setup your node

Setting up your node consists of:

• Configuring your node - see instructions in ;

• Starting your node and verifying it works as expected - see instructions in .

This is the first Iris release candidate.

It:

• Fixed buggy serialization of contract information - this means the compiler version is actually stored on chain, and isn't replaced by "unknown".

• Added AENS.update to FATE VM

• Added AENS.lookup and Oracle.expiry lookup functions to FATE VM

• Fixed bug regarding TTL of preclaims in FATE VM - it was incorrectly always set to 0, from VM_FATE_SOPHIA_2 it has the correct value.

• Fixed a bug in AENS.resolve in FATE VM - for invalid names VM_FATE_SOPHIA_1 will crash. From VM_FATE_SOPHIA_2 it will not crash, rather return None.

• Changed Chain.block_hash - in VM_FATE_SOPHIA_2 it will returnSome(<blockhash>) for Chain.block_height (i.e. current generation) previously it returned None. With Bitcoin-NG we do have the block hash of the current generation, so no reason not to allow this.

• Extended AENS name max expiration time from 50000 generations (~100 days) to 180000 generations (~375 days).

• Changed how a meta transaction TTL's is being validated: so far it used to be the outermost transaction's ttl that was taken into account, now it is the innermost one instead. Meta transactions no longer have TTL.

• Fixed a protocol issue: a valid force progress call with invalid CallData or failing call would result in on-chain transaction but tokens from the caller would still be moved to the forced contract. This is fixed and failed calls in successful force progress transactions result in rollback of the off-chain balances.

• Improved the functionality of State Channel delegates: now they can providechannel_solo_snapshot_tx as well. This is really handy in cases one party is missing and the other is doing malicious force progress on-chain while the channel is still open.

• Revisited the State Channel delegates: so far they were a shared list for both participants. From Iris on, delegates are per peer: there is a list of delegates for the initiator and another one for the responder. Old channel objects can still be used but users are strongly recommended to reset their delegates list if they had any. Note that the HTTP representations are changed accordingly.

• Allowed delegates to force progress on behalf of the user that authorized them to do so.

• Improved garbage collector for all Fate contracts form Iris

• Fate contracts of different versions can now call each other (Fate1 can call Fate2 and vice-versa)

• Opcode availability and behaviour now depends on VM version of the contract (Fate2 opcodes are available both when Fate2 contract is called directly and when called by another (possibly Fate1) contract)

• Generalized accounts, allow access to the signed transaction within the authentication context:

This enables more use-cases, for example in combination with PayingForTx.

• Added more crypto primitives (mainly pairing operations) for BLS12-381. This enables for example Zero-knowledge proofs and more multi-signature schemes.

• Added functions related to strings. It introduces to_list and from_list primitives that enables flexible string manipulation. Strings.aes standard library functions include many useful string functions.

• Added the possibility to query a an oracle by name hash. A name pointer can map oracle_pubkey

Please test the iris protocol by activating it in the configuration file as below:

You can also join testnet, the hard fork will happen there at .

Please let us know if you have any problems by . Troubleshooting of common issues is documented .

Documentation

For an overview of the installation process for different platforms, building the package from source, configuration and operation of the Aeternity node please refer to .

This document describes how to start your Aeternity node installed using a release binary, verify that it mines and verify that it joined the configured public network of nodes (e.g. testnet).

The instructions below assume that:

• The node is deployed in directory ~/aeternity/node;

• beneficiary account is set under mining > beneficiary in the config (see configuration documentation);

• No custom peers are specified under the peers: key in the config. If the peers: key is undefined, the testnet or mainnet seed peers (built-in in the package source) are used.

• The external HTTP endpoint of the user API of the node can be contacted at 127.0.0.1 port 3013.

• The location of the keys is set under keys > dir in the config (see ).