Figure 2: Forger requesting transactions from the node

For example a basic transfer transaction with payload looks like this:

Translated to a serialized version of this payload:

The length of the serialized transaction is 160 bytes. This length is taken into the calculation formula outlined in the AIP-16 proposal.

The size of a transaction varies and is related to vendorField size. The transaction type is included in the dynamic fee calculations, since a vote or delegate registration transaction requires more processing power. This is where the dynamicOffset plays a role. Offsets are defined in the network settings (network.json). Default values look like this:

Dynamic fee is calculated according to the formula implementation, as can be seen here:

And finally, the process of retrieving a transaction from the pool is seen in the following code snippet. This code is executed according to each transaction before returning to the forger (Figure 2 — Forger requesting transactions from the node), method checkIfDynamicFeeMatch(transactions).

Help Us Test

New features and core functionalities were tested by our team internally. However, public testing is essential to review all of the usage scenarios and edges cases from a fresh perspective (developers aren’t always the best testers). Wallets incorporating dynamic fees will be available prior to v2 MainNet release, currently only CLI tools will be available for testing on DevNet.

Everyone is invited to our DevNet to perform proper testing (join our Slack, channel #devnet) — from dynamic fees to multsig transactions and anything else you can think of. The more we test the better the foundation is for our new Core v2.

If you find a bug, please provide in-depth and detailed information on our GitHub Core repository (click), where all the instructions are already waiting for you.

Delegates

All delegates running nodes will have an option to customize fees in the config file according to the network they are running their node for (eg. DevNet Dynamic Fee configuration file).

Intro to Core Tester CLI

ARK Core v2 comes equipped with a built in testing suite. Presuming ARK Commander was used to install Core we can move into the Tester directory:

cd ~/ark-core/packages/core-tester-cli

From here you can run commands for sending test transactions across the network. They all have built in validation/tests to make sure the transactions are processed correctly.

To send one or more transactions, you simply run the commands and adjust the parameters. As you can see, the first command starts the tester and tells it which transaction it will run. The “\” at the end means end line and more parameters (commands) will follow. Each parameter starts with “--” and ends with “\” specifying that there are more parameters coming. When you reach the last parameter there is no “\” at the end. For example to generate 2 transactions you would run the following command:



-n 2 \

--base-url

--passphrase "your 12 word passphrase" ./bin/tester transfer \-n 2 \--base-url http://167.114.29.34 --passphrase "your 12 word passphrase"

In the example above, n represents the number of transactions you wish to send, base-url is node IP being broadcasted to (replace that with your Node’s IP) and passphrase is the wallet you wish to send transactions from.

By executing the command you get the following output in your terminal: