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.
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 enabling delegated harvesting.
Regardless of the method chosen, any account willing to activate harvesting must first announce a valid VrfKeyLinkTransaction. This key is required by Symbol to randomize harvester selection.
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.
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 main network, this fee is set to 5% and is used to support the different Reward Programs.
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.
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.
There are different kinds of harvesting available, depending on whether or not the harvester account owns the node and the amount of desired security: Local, Remote and Delegated.
This is the simplest to set up, and the most insecure method. It requires changing a node’s configuration, so it is only available to node owners. It is enabled by filling-in the appropriate harvesting properties in the node configuration file.
As it can be seen, the harvester account’s private key is stored in the harvesterSigningPrivateKey property, since it is needed to sign off created blocks. This is a security concern since this account contains funds and the configuration file might be accessed by uninvited actors if the node is compromised. Funded accounts’ private keys should always be stored offline.
Therefore, this method is strongly discouraged. Remote or delegated harvesting are recommended instead.
Node owners can use a remote account to act as proxy and sign off the newly created blocks, while harvesting fees are still collected by their main account. The remote account has no funds, so the fact that its private key is exposed in a configuration file on the node is not a concern. The importance score is still based on the main account.
In this setup the main account is still called the Harvester, for simplicity, whereas the remote account is called a Proxy.
Remote harvesting is enabled just like local harvesting but using the remote account’s private key in the harvesterSigningPrivateKey property and announcing an AccountKeyLinkTransaction that links the remote and main accounts.
This is the recommended method for node owners. See the Harvesting guides for step-by-step instructions on how to activate remote harvesting.
Eligible accounts not owning a node can still benefit from harvesting by requesting a node to harvest for them. The account’s importance score is used and any collected fees are divided among the account and the node’s beneficiary (as explained in the Rewards section). It is a advantageous agreement to both the account and the node.
It is then said that the account delegates harvesting to the node, but the account is still considered the harvester.
Delegated harvesting is enabled similarly to remote harvesting but, since the account has no access to the node’s configuration, it announces a PersistentDelegationRequest transaction instead (This can be done effortlessly from the Wallet). Upon receiving the request, the node may or may not grant it, depending on its configuration and the rest of requests received.
As with remote harvesting a proxy remote account is used so the main account’s private key is never put at risk.
See the Harvesting guides for step-by-step instructions on how to activate delegated harvesting and check if the delegation request has been granted.
This is actually a TransferTransaction sent to the node owner’s account with a special 132-byte message, formatted as a 264-characters hexadecimal string:
Bytes |
Hex digits |
Description |
|---|---|---|
8 |
16 |
Header: |
32 |
64 |
Ephemeral keypair public key. |
Below is encoded with the ephemeral key: |
||
16 |
32 |
AES GCM tag. |
12 |
24 |
AES GCM initialization vector. |
32 |
64 |
remoteLinkedPrivateKey |
32 |
64 |
vrfPrivateKey |
