Share your account’s importance securely with a node and get rewarded.
Delegated harvesting enables accounts to receive rewards from creating new blocks without running a node. At the same time, it allows nodes to benefit from an account’s (possibly higher) importance score.
Node owners have access to the node’s configuration so it’s more convenient for them to use Remote harvesting instead.
Please note that it is entirely up to the node to comply with the request. Some nodes can be asked for their current list of delegated harvesters but this information is not always available (see Verifying activation below).
Before you can activate delegated harvesting, you need the following items:
symbol.xymto be eligible and then some more to pay for transaction fees. This is the account that will receive the harvesting fees. Keep its private key secret at all times.
symbol.xymto pay for transaction fees. By announcing the final harvesting delegation request through this account instead of M, even the fact that M is involved in delegated harvesting is hidden from the network. Use this account for added privacy.
Refer to the Creating an account guide to know how to create new accounts if you need to.
The following bash code snippets make use of symbol-cli and assume that the main account (M) is set as the default profile. Use the
‑‑profile parameter if this is not the case.
Create an AccountKeyLinkTransaction to delegate M’s importance to R. Sign the transaction with M and announce it to the network.
const accountLinkTransaction = AccountKeyLinkTransaction.create( Deadline.create(epochAdjustment), remoteAccount.publicKey, LinkAction.Link, networkType, UInt64.fromUint(2000000), );
symbol-cli transaction accountkeylink --linked-public-key <REMOTE_PUBLIC_KEY> --action Link --sync
Create a VrfKeyLinkTransaction to link M to a VRF key. Sign the transaction with M and announce it to the network.
const vrfLinkTransaction = VrfKeyLinkTransaction.create( Deadline.create(epochAdjustment), vrfAccount.publicKey, LinkAction.Link, networkType, UInt64.fromUint(2000000), ); // Absolute number
symbol-cli transaction vrfkeylink --linked-public-key <VRF_PUBLIC_KEY> --action Link --sync
Create a NodeKeyLinkTransaction to link M to a node’s TLS key. Sign the NodeKeyLinkTransaction with M and announce it to the network.
The node’s public TLS key is typically provided by the node owner. However, Dual nodes (being both Peer and API nodes) running a version of the REST Gateway higher than 2.2.0 offer this information through the
nodePublicKey field of the
node/info REST endpoint.
Just point your browser to
const nodeLinkTransaction = NodeKeyLinkTransaction.create( Deadline.create(epochAdjustment), nodeAccount.publicKey, LinkAction.Link, networkType, UInt64.fromUint(2000000), ); // Absolute number
symbol-cli transaction nodekeylink --linked-public-key <NODE_PUBLIC_TLS_KEY> --action Link --sync
Once the transactions are confirmed, the next step is to share R’s private key with the node. This can be done in one of two ways depending on whether you are the node owner and have access to the node’s configuration or not.
If you are the node owner, you simply need to set the remote account’s private signing key in the
harvesterSigningPrivateKey field in the Harvesting Configuration.
Otherwise, a PersistentDelegationRequestTransaction must be used. As the private key will be shared in an encrypted message, only the node will be able to see it. Moreover, R does not own any mosaic.
The harvesting fees will be sent to M as it has established a link with the node through the NodeKeyLinkTransaction.
Sign the PersistentDelegationRequestTransaction with M (or A for added privacy, as stated in the Prerequisites) and announce it to the network.
const persistentDelegationRequestTransaction = PersistentDelegationRequestTransaction.createPersistentDelegationRequestTransaction( Deadline.create(epochAdjustment), remoteAccount.privateKey, vrfAccount.privateKey, nodeAccount.publicKey, networkType, UInt64.fromUint(2000000), );
# Optionally use --profile announcer symbol-cli transaction persistentharvestdelegation --remote-private-key <REMOTE_PRIVATE_KEY> --recipient-public-key <NODE_PUBLIC_TLS_KEY> --vrf-private-key <VRF_PRIVATE_KEY> --sync
All the above transactions can be announced together in a single Aggregate Transaction.
If everything is successful, the node will receive the encrypted message through WebSockets. Once the node decrypts the private key of the potential delegated harvester, the node owner may add R as a delegated harvester if the following requirements are met:
As the remote private key is saved on disk by the node, even if the node disconnects temporarily the persistent delegated harvesters will be reestablished once the node reconnects to the network.
Additionally, the use of an 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 still retrieve the data by querying the blockchain.
When requesting delegation through a PersistentDelegationRequestTransaction instead of directly configuring the node, whether the node enables delegated harvesting depends entirely on the node and not on the network. It is entirely up to the node to comply with the request or even to lie about its state.
Therefore, there is no reliable way to know if your account has become a harvester or not (besides waiting to see if any blocks appear on the blockchain signed by your remote account and your main account starts collecting harvesting fees).
That said, nodes configured to act as Dual nodes (being both Peer and API nodes) can be queried for their current list of delegated harvesters. To reiterate, this information comes from the node and is not backed up by the blockchain, so take it with a grain of salt.
You can retrieve this list using the
getUnlockedAccount API endpoint (point your browser to
http://<NODE_URL>:3000/node/unlockedaccount) or the Typescript SDK for example). It contains the public keys of all registered delegated harvesters in the node, so your remote account (R) public key should appear here.
By default a node can have up to 5 delegated harvesters (harvesting slots) and excess requests can be priorized as the node sees fit. This can be configured on the node through the
delegatePrioritizationPolicy Harvesting Configuration.
importanceGroupingproperty in the Configuring network properties guide.
Did you find what you were looking for? Give us your feedback.