Technical description of the platform
Transactions of the blockchain platform¶
Transaction is a separate operation in the blockchain changing the network state and performed on behalf of a participant. By sending a transaction, the participant sends a request to the network with the set of data needed for the corresponding change of the state.
Signing and sending of transactions¶
Prior to signing and sending of transactions, a participant generates a digital signature for it. To do this, he uses a private key of his account. Transaction signing can be done in three ways:
with the use of the blockchain platform client;
with the use of the REST API method (see REST API: transactions);
with the use of the JavaScript SDK.
The transaction signature is inserted into the proofs
field while sending the transaction into the blockchain. As a rule, this field contains one signature of the participant who sent the transaction. But this field supports up to 8 signatures: in case of transaction signing by a smart account, filling of an atomic transaction or smart contract broadcasting.
After signing, the transaction is sent into the blockchain. This can be done in three aforementioned ways, as well as with the use of the gRPC interface (see gRPC: sending of transactions into the blockchain)
Processing of transactions in the blockchain¶
After obtaining of a transaction, the node validates it in the following way:
Timestamp correspondence check: a transaction timestamp should derive from the current block timestamp for not more than 2 hours before or 1,5 hours after it.
Transaction type and version check: if support of such transactions type and versions has been activated in the blockchain (see Activation of blockchain features).
Correspondence of transaction fields with a defined data type;
Sender balance check: if balance is sufficient for fee payment;
Transaction signature check.
If a transaction is not validated, the node declines it. In case of successful validation, a transaction is added to the unconfirmed transaction (UTX) pool, where it is awaiting the next mining round for broadcasting in the blockchain. Together with transfer of this transaction into the UTX pool, the node sends it to other nodes of the network.
Each microblock has a limit of incoming transactions, each separate transaction can be transferred from the UTX pool not at once. During existence of a transaction in the UTX pool, a transaction can become invalid. For instance, its timestamp is not more corresponding with the current block timestamp, or a transaction transferred into the blockchain has decreased a sender balance and made it insufficient for payment of a transaction fee. In this case, a transactions will be declined and removed from the UTX pool.
After adding of a transaction into a block, the transaction changes the blockchain state. After this, transaction is considered executed.
Detailed information about transactions of the Waves Enterprise blockchain platform:
- Description of transactions
- 1. Genesis Transaction
- 3. Issue Transaction
- 4. Transfer Transaction
- 5. Reissue Transaction
- 6. Burn Transaction
- 8. Lease Transaction
- 9. LeaseCancel Transaction
- 10. CreateAlias Transaction
- 11. MassTransfer Transaction
- 12. Data Transaction
- 13. SetScript Transaction
- 14. Sponsorship Transaction
- 15. SetAssetScript Transaction
- 101. GenesisPermission Transaction
- 102. Permission Transaction
- 103. CreateContract Transaction
- 104. CallContract Transaction
- 105. ExecutedContract Transaction
- 106. DisableContract Transaction
- 107. UpdateContract Transaction
- 110. GenesisRegisterNode Transaction
- 111. RegisterNode Transaction
- 112. CreatePolicy Transaction
- 113. UpdatePolicy Transaction
- 114. PolicyDataHash Transaction
- 120. Atomic Transaction
- Actual versions of transactions