Waves Enterprise platform supports the execution of atomic operations. Such operations consist of several actions, and are either performed completely or not performed at all. To do this, the system has 120 transaction which is a container that holds two or more signed transactions.
The 120 transaction supports the following transaction types:
4 Assets transfer, version 3
102 Adding / removing permissions, version 2
103 Contract creation, version 3
104 Contract calling, version 4
105 Contract execution, versions 1 and 2
106 Contract disabling, version 3
107 Contract updating, version 3
112 Privacy group creation, version 3
113 Privacy group updating, version 3
114 Privacy data edding, version 3
The key difference between new versions of transactions that are supported by the 120 atomic transaction is the presence of the atomicBadge tag field. This field contains the trusted address of the transaction sender trustedSenders to add to the transaction container 120. If the sender’s address is not specified, then the sender is the address from which the 120 transaction is sent to the blockchain.
Processing an atomic transaction¶
The 120 transaction has two signatures. The first transaction is signed by the sender to be successfully sent to the network. The second signature is generated by a miner and is necessary for adding a transaction to the blockchain. When adding 120 a transaction to the unconfirmed transaction pool, its signature is checked, as well as the signatures of all transactions included in the container. Validation of such transactions is performed according to the following rules:
The number of transactions should be more than one.
All transactions should have different IDs.
The list of transactions should contain only supported types of transactions. To put a single atomic transaction to another is not allowed.
There should be no executed transactions inside an atomic transaction sent to the UTX pool, and the
miner field should be empty. Also there should be no executable transactions inside an atomic transaction that is included in a block, and the
miner field should not be empty.
After executing an atomic transaction, the block gets its “copy” formed according to the following rules:
minerfield does not participate in the formation of the transaction signature and is filled in with the public key of the block miner.
The block miner generates an array of
proofs, the source of which is the IDs of transactions included in an atomic transaction. When included in a block, an atomic transaction has 2 signatures – the signature of the original transaction and the signature of the miner.
If the list contains executable transactions, they are replaced with executed transactions. When validating an atomic transaction as part of a block, both signatures are checked.
Creating the atomic transaction¶
To create an atomic transaction, you need access to the node REST API.
The user selects from the list of supported transactions those transactions that should be performed as an atomic operation.
Correctly fills the fields of all transactions and signs them using the sign method.
Next, the user fills the field
transactionsof the 120 transaction with the data of signed but not sent to the blockchain transactions.
After entering all the transaction data, the user signs and sends the 120 transaction to the blockchain.
If you are creating an atomic transaction that includes 114 transactions, set the
broadcast = false parameter when signing it.