Harvesting

The process of creating new blocks is called harvesting.

In this process, the account that harvests a block is called the harvester and is rewarded with any transaction fees produced and any inflation tokens generated.

Each produced block stores in its header the public key of the harvester account and the block’s signature that it created.

Eligibility criteria

The importance score determines the probability that an account is chosen to harvest the next block among all the accounts which have harvesting enabled.

Symbol’s public network defines that an account needs to hold at least 10,000 harvesting mosaics to have an importance score greater than zero. Eligible accounts can use their importance score to create new blocks either by running a node or delegating harvesting to another node.

Regardless of the method chosen, any account willing to activate harvesting must first announce a valid VrfKeyTransaction. The VRF transaction links the harvester account with a second key pair to randomize block production and leader selection.

Harvesting mosaic

The Symbol platform supports defining any mosaic for harvesting purposes to fit different business needs.

For example, consortium networks can distribute harvesting mosaics between the companies that are running the infrastructure, while other participants need to pay fees in the form of currency mosaic to consume services.

By contrast, public networks might use the same mosaic for paying transaction fees and running the network. Symbol’s public network uses symbol.xym as the harvesting mosaic, enabling any eligible participant to harvest new blocks.

Rewards

Network operators can define a network fee sink account that will receive a percentage of the harvesting rewards (block fees and inflation). In the case of the public network, this fee could be used to create supernode programs, reward accounts that participate in the finalization process or advance the network development. By default, the public test network sets this percentage to 5%.

Additionally, each node can set a beneficiary account to share a percentage (up to 25%) of the harvesting rewards. The node operators can use this feature to create incentive structures for their node supporters.

The sharing ratios for the beneficiary and network sink accounts are configurable per network.

../_images/network-sink-beneficiary.png

Rewards division when the network’s sharing ratio for network sink is 20% and for beneficiary is 10%.

Note

The calculation of the beneficiary percentage will occur after the network sink calculation. When the node operator does not define a beneficiary or a Network Fee Sink, all the rewards go to the block signer.

Local harvesting

Any eligible account can harvest new blocks by running a node. To harvest locally, a node must provide the following properties in the config-harvesting.properties file:

Harvesting configuration settings.
From resources/config-harvesting.properties v0.10.0.3
PropertyTypeDefault value
PRIVATE
Default value
TESTNET
harvesting
harvesterSigningPrivateKeystring
Harvester signing private key. Used only when harvesting is enabled.
harvesterVrfPrivateKeystring
Harvester VRF private key. Used only when harvesting is enabled.
enableAutoHarvestingboolfalsetrue
Enables harvesting using configured harvester keys when true.
maxUnlockedAccountsuint32_t55
Maximum number of unlocked accounts, i.e., the maximum number of delegated harvesting accounts.
delegatePrioritizationPolicyharvesting::DelegatePrioritizationPolicyImportanceImportance
Prioritization policy used to keep accounts once the maximum number of delegated harvesting accounts is reached. Possible values are Age and Importance.
beneficiaryAddressAddress
Address of the account receiving part of the harvested fee.

As it can be seen, the harvester account’s private key must be stored in the node configuration, since it will be used to sign off created blocks. This is a security concern since this account contains funds (at the very least, the collected harvesting fees), and funded accounts’ private keys should always be stored offline.

To avoid storing private keys on a node which is available online and therefore susceptible to attack, use delegated harvesting.

Delegated harvesting

Delegated harvesting allows using the importance score of an account to create new blocks and receive rewards without exposing the account’s private key on a node.

An eligible account can delegate its importance score to a remote account which acts as a proxy. The remote account signs off created blocks, sharing its private key with the a node, but harvesting fees are sent to the original account.

With delegated harvesting, an account without a node can still collect harvesting fees, and a node with a low importance score can still be selected as a harvester, thanks to the delegated importance from the first account. It is a beneficial agreement to both parties.

Due to its inherently higher security, node owners may prefer using delegated harvesting over local harvesting and this is indeed the recommended setup.

Security-wise, sharing a proxy private key involves minimal risk since:

  • The remote account has no funds.
  • The remote account can’t transfer the delegated importance score to a third account.

Keep in mind that remote harvesters may not receive the entire reward if:

Note

See the Activating Delegated Harvesting guide for step-by-step instructions on how to activate this feature.

Comparison

  Local harvesting Delegated harvesting
Setup Install a catapult-server node. Activate remote harvesting.
Cost Node maintenance (electricity, VPN, …) + VrfKeyLinkTransaction announcement fees. Announcement fees for 4 transactions.
Security The node stores the main account’s private key. The node stores a proxy account’s private key.
Reward Total reward. The node owner can share part of it with a beneficiary account. Total reward minus any beneficiary share set on the node.

Guides

Continue: Inflation.