Validating
The process of creating new blocks is called validating.
The validating account - called the validator - gets the fees for the transactions in the block and inflation. This reward gives the validator an incentive to add as many transactions to the block as possible.
Validating mosaic
Sirius Chain software allows the definition of any mosaic for validating purposes to fit the business needs. The Sirius Chain test network names this mosaic xpx.
For example, consortium networks can distribute validating 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 decide to use the same mosaic for paying transaction fees and running the network.
Local validating
During the installation of a node, you will be asked to set up an account that will be used to validate. The block header includes the public key and signature generated by the validating account.
Besides, each node can set a beneficiary public key to share a percentage of the validating rewards (fees and inflation), where the sharing ratio is configurable for each network. When the node does not define a beneficiary, all the rewards go to the block signer.
Local validating is secure as long as no one accesses your node instance, which is storing the private key.
Delegated validating
Delegated validating enables an account to use a proxy private key that can be shared with a node securely. In other words, you can use the importance score of your account to create new blocks without running a node.
After an account activates delegated validating, its importance score is transferred to a remote account. The remote account inherits the importance of the original account.
Security-wise, sharing a proxy private key with a remote node 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 validators may not receive the entire reward if the following conditions are met:
The network validating sharing rate is greater than 0. The node selected has defined a beneficiary account.
| Local validating | Delegated validating | |
|---|---|---|
| Configuration | Setup node. | Activate remote validating. |
| Cost | The node maintenance (electricity, cost VPN). | The activation transaction fee. |
| 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 - beneficiary share. |
Schemas
AccountLinkTransaction
Announce an AccountLinkTransaction to delegate the account to a proxy account. By doing so, you can enable delegated validating.
In order for the proxy account to be accepted as the remoteAccountKey for delegated validating, it needs to meet the following conditions:
- It cannot own any mosaics.
- It cannot be a cosignatory of any other account.
- It cannot be a multisig account.
- It cannot already be a delegated account for another account.
- It cannot have its own delegated account.
Furthermore, for the duration that the account is used as a delegated account, it is restricted from:
- initiating any transactions.
- involvement with any type of transactions.
Version: 0x02
Entity type: 0x414C
Inlines:
| Property | Type | Description |
|---|---|---|
| remoteAccountKey | 32 bytes (binary) | The public key of the remote account. |
| linkAction | LinkAction | The account link action. |
LinkAction
Enumeration: uint8
| Id | Description |
|---|---|
| 0 | Link. |
| 1 | Unlink. |