Transactions
In Lisk, the state of accounts is updated by transactions included in a block. Every account can issue a transaction, with the corresponding signature and data. Similar transactions are grouped together into one module. Apart from the module-specific account properties, a module defines the validation and execution logic for every transaction contained within that module. The Lisk protocol contains four default modules, Token, Sequence, Keys, and DPoS, which contain the six transactions shown in the table below.
Transaction | Module | Purpose |
---|---|---|
token transfer |
Token |
Transmit funds to another Lisk account |
delegate registration |
DPoS |
Register a delegate for the account |
delegate vote |
DPoS |
Submit or remove vote(s) for delegates |
token unlock |
DPoS |
Unlock locked tokens |
multisignature group registration |
Keys |
Register a multisignature group for the account |
delegate misbehavior report |
DPoS |
Report a misbehavior of a delegate |
Transaction properties
Every transaction object in the Lisk protocol has a common set of properties. These properties are shown in the subsection below.
nonce
An integer that accounts for the number of transactions from the sender account.
For a transaction to be valid, this integer has to be equal to the nonce
stored in the sender account.
If due to network congestion, a transaction was not included in a block because its fee was too low, a user can broadcast a new transaction using the same nonce
value but with a higher fee.
Once one of the two transactions is included in the blockchain, the other one becomes invalid as the nonce
has already been used.
fee
The fee to be spent by the transaction. This fee has to be equal or greater than a minimum value for the transaction to be valid. The minimum value is calculated as the size of the transaction object multiplied by a constant, minFeePerByte
, given by the protocol. The value of minFeePerByte
is 1000 (10-5 LSK/byte in Lisk Mainnet). Note that for delegate registration transactions there is an extra summand of 109 (10 LSK in Lisk Mainnet) added to the minimum fee to account for the name space used by this transaction.
For example, in Lisk Mainnet, for a token transfer transaction with a size of 133 bytes, the minimum fee is 10-5 LSK/byte × 133 bytes = 0.00133 LSK. In the case of delegate registration transaction with a size of 124 bytes, the minimum fee of the transaction is 10 LSK + 10-5 LSK/byte × 124 bytes = 10.00124 LSK.
This required minimum fee paid by every transaction is burned, in other words, it is not assigned to any account balance. The remaining fee on top of this is assigned to the delegate forging the block in which the transaction is included. This implies that under normal circumstances delegates give priority to transactions with higher remaining fees.
senderPublicKey
The public key of the account issuing the transaction.
Note that this public key does not necessarily sign the transaction.
For simplicity, the account issuing the transaction is called the sender account in this document.
The senderPublicKey
is used to compute the address under which the sender account information is stored.
asset
This property contains the data specific to the type of the transaction.
Every pair of values (moduleID
,assetID
) must uniquely correspond to one asset schema defined in the respective module, which defines how to deserialize the bytes provided in the transaction asset.
The section Transactions below contains the asset schemas and a description of the general execution logic for the default transactions listed above.
signatures
An array with the signatures of the transaction.
If the account associated to senderPublicKey
does not have the keys
property, the object containing the six properties, moduleID
, assetID
, nonce
, fee
, senderPublicKey
, and asset
, has to be signed by the private key corresponding to the senderPublicKey
.
Otherwise, the signing process has to be repeated for each of the private keys associated with an applicable set of public keys specified in the keys
property of the account.
In the Appendix section more details about the signing process are given.
Transaction ID
In Lisk, every transaction is associated with a transaction ID, which uniquely identifies a transaction in the blockchain. The transaction ID is the SHA-256 (Secure Hash Algorithm 256), hash of the serialized transaction.
Minimum balance
A token transfer transaction must make the balance of the receiving account equal to or greater than 5 × 106 (0.05 LSK in Lisk Mainnet). Subsequently, any transaction sent from an account is only valid if the resulting balance of the sender account is at least 5 × 106. This constraint exists to account for the cost of creating and storing accounts in Lisk.
Transactions
The 6 different transactions from the default modules of the Lisk protocol are listed in the table displayed above.
Each one induces a concrete operation on accounts and is defined by a unique schema and transaction logic.
The specific data is given in the asset
property previously mentioned.
The key points and useful information for each of these transactions are commented in the following subsections.
Token transfer
This transaction transfers the amount of tokens specified in the amount
property from the account corresponding to the senderPublicKey
, i.e. the sender account, to the account specified in recipientAddress
.
This transaction offers the possibility to send a message in the optional property data
.
The maximum length for a string in data
is 64 characters.
Delegate registration
This transaction registers the sender account as a delegate with the name given in username
. A valid name contains only characters from the set [a-z0-9!@$&_.]
and has to be at most 20 characters long.
Delegate vote
This transaction submits the votes specified in votes
from the sender account.
This is accomplished by specifying the Lisk address of the voted delegate in delegateAddress
together with the amount of support given to this delegate in amount
.
The quantity given in amount
is subsequently locked and cannot be used for other transactions.
If the amount is negative, it implies that the specified amount of votes are removed from the delegate.
The maximum number of votes that can be cast in a single transaction is 20 and amount
has to be a multiple of 109 (10 LSK in Lisk Mainnet).
Token unlock
This transaction unlocks the tokens specified in amount
that were previously unvoted for the delegate specified by delegateAddress
by a vote transaction at the height given in the property unvoteHeight
.
This transaction is only valid if it is issued after the unlocking period has been completed since unvoteHeight
.
For a regular vote the unlocking period is 2000 blocks (around 5 hours).
For self-votes, i.e. if the delegateAddress
property of the transaction is equal to the account address, this period is 260,000 blocks (around 30 days).
As described in the Punishment of Lisk-BFT protocol violations section, the validity of the unlock transaction also depends on potential misbehaviors by the unvoted delegate. An unvote for a punished delegate has its unlocking period extended. For regular votes, this period is extended from 2000 blocks to 260,000 blocks (from 5 hours to 30 days). For self-votes, this period is extended from 260,000 blocks to 780,000 blocks (from 30 days to 3 months). This affects any amount currently voting for the punished delegate or amounts that were used for voting for this delegate, but were still in the unlocking period at the inclusion height of the proof-of-misbehavior.
Multisignature group registration
This transaction registers the sender account as a multisignature group account.
The set of mandatory keys needs to be specified in mandatoryKeys
whereas the set of optional keys have to be specified in optionalKeys
.
The total number of keys required for every future outgoing transaction from the account is given in numberOfSignatures
.
Once this transaction is included in a block, every transaction from this account has to be signed by an applicable set of private keys.
Delegate misbehavior report
This transaction can be utilized to report a misbehavior of a certain delegate.
It contains the information necessary to prove that the delegate who signed the block headers given in header1
and header2
has violated the Lisk-BFT protocol.
The Punishment of Lisk-BFT protocol violations section provides the details regarding the implications of this transaction.