Technical description of the platform
The Waves Enterprise platform supports atomic operations. Atomic operations consist of multiple actions, if any action cannot be finalized, other actions also will not be performed. Atomic operations are realized through the 120 AtomicTransaction, which is a container consisting of two or more signed transactions.
Atomic transaction support 2 and more transactions of the following types:
4. Transfer Transaction, ver. 3
102. Permission Transaction, ver. 2
103. CreateContract Transaction, ver. 3
104. CallContract Transaction, ver. 4
105. ExecutedContract Transaction, ver. 1 and 2
106. DisableContract Transaction, ver. 3
107. UpdateContract Transaction, ver. 3
112. CreatePolicy Transaction, ver. 3
113. UpdatePolicy Transaction, ver. 3
114. PolicyDataHash Transaction, ver. 3
Once the blockchain feature1122 is activated, you can include the following transaction types in an atomic transaction:
3. Issue Transaction, ver.3
5. Reissue Transaction, ver. 3
6. Burn Transaction, ver. 3
8. Lease Transaction, ver. 3
9. LeaseCancel Transaction, ver. 3
10. CreateAlias Transaction, ver. 4
11. MassTransfer Transaction, ver. 3
12. Data Transaction, ver. 3
14. Sponsorship Transaction, ver. 2
111. RegisterNode Transaction, ver. 2
The key peculiarity of transactions that are supported by atomic transactions, is an
atomicBadge field. This field contains a
trustedSender value: a trusted address of a transaction sender to include into the 120 transaction container. If a sender address is not specified, an address of a sender of the 120 transaction becomes the sender of the included transaction.
Processing of atomic transactions¶
Atomic transactions have two signatures. First signature belongs to its sender and is used for broadcasting. Second signature is generated by a miner and is used for including of the transaction into the blockchain. When an atomic transaction is added to the UTX pool, the node checks its own signature, as well as signatures of all transactions included into the atomic container.
Validation of included transactions is carried out as follows:
There should be more than one included transactions.
All transactions should have different identifiers.
An atomic transaction should contain only supported transaction types.
Including of an atomic transaction to another atomic transaction is not allowed.
There should not be executed transactions inside an atomic transaction to be sent into the UTX pool, the
miner field should be empty. This field is filled during transferring of the transaction into a block.
There should not be executable transactions in an atomic transaction which is in the UTX pool.
After execution of an atomic transaction, its ‘copy’ is included into a block. This ‘copy’ is generated as follows:
minerfield is not engaged for transaction signing and is filled with a miner public key.
A block miner generates a
proofsarray, the source of which are identifiers of transactions included into an atomic transaction. When included into a block, an atomic transaction has 2 signatures: a signature of a source transaction and a miner signature.
If executable transactions are included into an atomic transaction, they are substituted with executed transactions. While validating an atomic transaction in a block, both signatures are checked.
Generating of atomic transactions¶
An access to the node REST API is required for generating of an atomic transaction.
A user picks supported transactions that should be used as an atomic operation.
After that, a user fills fields of all transactions and signs them.
A user fills the
transactionsfield of an atomic transaction with data of signed, but not broadcasted transactions.
After filling an atomic transaction with data of all included transaction, a user signs it and broadcasts into the blockchain.
Data structures for signing and broadcasting of an atomic transaction, are listed in the list of transactions.
If you create an atomic transaction including a 114 transaction, set its
broadcast value as
false while signing.