ARK Core v2 Testing: Dynamic Fees

Recently, the basic elements of ARK dynamic fees were outlined in the October 2nd blog post. Now, we present a guide for enabling and testing the new fee structure as we delve into the technical side of dynamic fees in the upcoming release of ARK Core v2.

Dynamic fees allow delegates to set their own minimum acceptable fees for transactions and let users specify the maximum fees they are willing to pay for a transaction. The resultant “marketplace” allows for competition among delegates in setting fees, lets users choose the fee needed for the speed of their transaction, and ultimately keeps fees low for the end user.

This post goes deeper into the technical aspects of dynamic fees and take a look at dynamic fee files with regard to their setup and testing using the Tester CLI to send custom transactions via shell. Dynamic fee testing can be done right now on DevNet and with this blog post we are officially starting our first targeted testing.

If you have any questions please join our Slack (#devnet) channel, you will then be able to question ARK developers and request additional guidance if needed.

#Technical Breakdown

A more detailed technical breakdown is described in the AIP proposal for Dynamic Fees .

Looking at the inclusion scenario from the node process, the steps are:

#1. Send and process transaction payload from the client/sender

Figure 1: Sending and processing of transactions on the node

#2. Forger requests transaction from the pool

When the Forger pulls the transactions from the pool, the transactions are checked to see if they match. Methods are called according to the sequence diagram below.

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:

./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:

If we check the transactions in the dexplorer.ark.io we can see that two transactions where confirmed and forged:

The core-tester-cli package comes with the following commands:

1. ./bin/tester transfer - Send multiple transactions
2. ./bin/tester second-signature - Create wallets with second signature
3. ./bin/tester delegate-registration - Create multiple delegates
4. ./bin/tester vote - Create multiple votes for a delegate
5. ./bin/tester multi-signature - Create multiple multi-signature wallets

The tester-CLI suite stores the address and passphrase of every wallet created in the ~/ark-core/packages/core-tester-cli/test-wallets file. You can open the file simply by opening it with your editor. For example:

nano ~/ark-core/packages/core-tester-cli/test-wallets

Our core-tester-cli has some basic help and parameter included. If you write:

./bin/tester -h

You get basic help and if you write:

./bin/tester COMMAND NAME -h

You’ll get more detailed information about parameters and command.

You can also read the commands and their respected values here:

#Setting the dynamic fee parameters in generated transactions

Each of the commands has a list of parameters (see the link above). One of the parameters allows specification of a custom fee that the user is willing to pay for the processing of the transaction.

The transfer command contains the option --**transfer-fee** where the exact fee can be specified arktoshi.

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

You can also specify random limits for --transfer-fee parameters. For example you can specify a transfer-fee range as follows:

--transfer-fee 1000–5000

This will randomly select different values for the fees in the provided range between 1000 and 5000 arktoshi.

If you are looking at your logs output you will see the following messages:

*(in this case transaction are not forged as they are bellow delegate specified minimum fee).*Let’s run the following command generating 10 transfer transactions with random fees between 29000 and 50000 arktoshi.

./bin/tester transfer \
-n 10 \
--base-url http://127.0.0.1 \
--transfer-fee 29000–50000 \
--passphrase "your 12 word passphrase"

In the above example fees will be randomly generated for each of the 10 transactions ranging from 29000–50000 arktoshis. This is great for testing limits and min accepted fees.

If you are running custom ports for API and P2P you have 2 flags available for that (they are defaulted to 4002 and 4003 as we are running this on devnet):

--api-port 4003 \
--p2p-port 4002 \

#How do I set fees for other transaction types in Core Tester CLI?

Each transaction has its own parameter in the core-tester-cli package. Look at the tester command file where all the parameters are visible. In general, we have the following options for dynamic-fee setup related to different transaction types.

1. ./bin/tester transfer with parameter –transfer-fee
2. ./bin/tester second-signature with parameter –signature-fee
3. ./bin/tester delegate-registration with parameter –delegate-fee
4. ./bin/tester vote with parameter –vote-fee
5. ./bin/tester multi-signature with parameter –multisig-fee

#How do I configure my node to accept dynamic fees?

Last but not least, you need to enable your node (your delegate) to accept dynamic fees. A detailed approach is written in the AIP-16 proposal.

There are two main steps to configure and enable dynamic fees.

1. Setting your fee parameters as a delegate

A delegate can define his formula parameters for feeMultiplier and limit incoming transactions with the minAcceptableFee value. All settings are in ARKTOSHI per byte. Delegate settings can be found in delegates.json .

Assuming core-commander was used to install core, your network config file can be opened with the following command:

nano ~/.ark/config/delegates.json

And there you have options to change feeMultipler or minAcceptableFee.

“dynamicFees”: {
 “feeMultiplier”: 1000,
 “minAcceptableFee”: 30000
 }

If you change it don’t forget to restart your Core process to load updated settings.

2. Turning on dynamic fees

Turn on dynamic fees in your network configuration file. Assuming core-commander was used to install core, your network config file can be opened with the following command:

nano ~/.ark/config/network.json

By setting the value of dynamic to true and defining a new milestone and the block height from which the settings should go into effect, we can enable or disable the dynamic fees on the node level.

For example the settings below will enable the dynamic fee acceptance from block height 10 onwards:

"height": 10,
"fees": {
 "dynamic": true

The example below will disable dynamic fee processing from block 20 onwards:

"height": 20,
"fees":{
 "dynamic": false

All fees will be calculated according to static fees defined in network.json .

If you change it don’t forget to restart your Core process to load updated settings.

This covers basic usage and testing of dynamic fees. See you in #devnet channel on Slack!

Remember we are also running GitHub bounty program for all pull requests that get merged : https://blog.ark.io/ark-github-development-bounty-113806ae9ffe