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:
https://gist.github.com/kristjank/9b4b9c46b3b97dc856584139f26aae7f#file-transaction-payload-type-transfer-json
Translated to a serialized version of this payload:
https://gist.github.com/kristjank/d8e1daa30776289cf92bacc577769a11#file-transaction-payload-serialised-json
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:
https://gist.github.com/kristjank/2235e565789698495f75f6a1ead047a6#file-network-json
Dynamic fee is calculated according to the formula implementation, as can be
seen here:
https://gist.github.com/kristjank/dac8707d0ead35407e8f43ec942c78a8#file-dynamic-fee-js
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).
https://gist.github.com/kristjank/cbbcda1eb4250e4de8e8206929cff883#file-dynamic-fee-matcher-js
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-node/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
\
--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:
- ./bin/tester transfer - Send multiple transactions
- ./bin/tester second-signature - Create wallets with second signature
- ./bin/tester delegate-registration - Create multiple delegates
- ./bin/tester vote - Create multiple votes for a delegate
- ./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-node/packages/core-tester-cli/test-wallets file. You can open the
file simply by opening it with your editor. For example:
nano ~/ark-node/packages/core-tester-cli/test-wallets
You can also read the commands and their respected values here:
https://github.com/ArkEcosystem/core/tree/develop/packages/core-tester-cli/bin/tester#L23
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
\
--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:
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
\
--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.
- ./bin/tester transfer with parameter --transfer-fee
- ./bin/tester **second-signature **with parameter --signature-fee
- ./bin/tester delegate-registration with parameter --delegate-fee
- ./bin/tester vote with parameter --vote-fee
- ./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.
“dynamicFees”: {
“feeMultiplier”: 1000,
“minAcceptableFee”: 30000
}
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.
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
ARK.io | Github | Facebook | Twitter | Forum | Blog | Explorer | Shop | Discord | YouTube