Harvesting
The process of creating new blocks is called harvesting.
In this process, the account that harvests a block—called the harvester—is rewarded with the transaction fees added in the block and the inflation tokens generated.
Once an account harvests a block, the block recorded stores in its header the public key and signature generated by the harvesting account.
Eligibility criteria
The importance score determines the probability of an account to harvest the next block in case the account has harvesting turned on and all other accounts are harvesting too.
Symbol’s public network defines that an account needs to hold at least 10,000 harvesting mosaics units to have importance score greater than zero.
Eligible accounts can use their importance scores to create new blocks either by running a node or delegating it to a remote 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
Symbol software supports defining any mosaic for harvesting purposes to fit the 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.
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
An eligible account can harvest new blocks by running a node.
To harvest locally, the account should provide the next properties in config-harvesting.properties file:
| Property |
Type |
Description |
Default |
|---|
| harvesterSigningPrivateKey |
string |
The harvester account private key. This account needs to hold at least 10,000 harvesting mosaics units to have importance score greater than zero in the public network. |
|
| harvesterVrfPrivateKey |
string |
The VRF private key linked with the account. |
|
| enableAutoHarvesting |
bool |
Set to true if delegated harvesting is enabled. |
false |
| maxUnlockedAccounts |
uint32_t |
Maximum number of delegated harvesting accounts. |
5 |
| delegatePrioritizationPolicy |
harvesting::DelegatePrioritizationPolicy |
Delegate harvester prioritization policy used to keep accounts once the node stores maxUnlockedAccounts. Possible values are “Importance” or “Age”. |
Importance |
| beneficiaryAddress |
Address |
Address of the account that will receive a percentage of the block fees defined by the harvestBeneficiaryPercentage. |
0000000000000000000000000000000000000000000000000000000000000000 |
Local harvesting is secure as long as no one accesses your node instance, which is storing the private key.
Delegated harvesting
Delegated harvesting allows using the importance score of an account to create new blocks and receive rewards without having to run a node locally.
An eligible account can delegate its importance score to a brand new proxy account
The private key of the proxy account can be shared securely with any node that is running local harvesting that delegated harvesting connections.
To enable delegated harvesting, the account owner has to link its importance score to the proxy account by announcing an AccountKeyLinkTransaction.
In order for the remote account to be accepted for delegated harvesting, the remote account should not have sent nor received any transaction or be linked to another account previously.
Note
The remote account cannot be involved in any transaction while it is a delegated account.
Then, the account needs to send a special encrypted message to the node via a TransferTransaction.
The message must contain the remote’s account proxy private key encrypted using AES, making the transaction readable only by the recipient.
The node receives an encrypted message using WebSockets.
Once the node decrypts the private key of the potential delegated harvester, the node owner can add the remote account as a delegated harvester if the candidate meets the requirements.
As the remote private key is saved on disk, even if the node disconnects temporarily, the persistent delegated harvesters will be reestablished once the node reconnects to the network.
Additionally, the use of encrypted message creates a backup of the information for the nodes.
If the disk containing the delegated keys becomes corrupted or destroyed, the node owner can retrieve the data by querying the blockchain.
Security-wise, sharing a proxy private key does not compromise the original account since:
- The remote account has zero balance.
- The remote account by itself can’t transfer the importance to another account.
- The original account receives the resulting fees.
Remote harvesters may not receive the entire reward if the following conditions are met:
- The network harvesting sharing rate is greater than 0.
- The node selected has defined a beneficiary account.
Comparison between local and delegated harvesting
| |
Local harvesting |
Delegated harvesting |
|---|
| Configuration |
Setup a catapult-server node. |
Activate remote harvesting. |
| Cost |
The node maintenance (electricity, cost VPN) + VrfKeyLinkTransaction announcement fees. |
VrfKeyLinkTransaction + AccountKeyLinkTransaction + TransferTransaction announcement fees. |
| Security |
The node stores the private key. |
A proxy private key is shared with a node. |
| Reward |
Total reward. The node owner can share part of the reward with a beneficiary account. |
Total reward - node’s beneficiary share. |
