Transactions are responsible in every blockchain to create changes in the system. Considering an account/balance based system, they are actually simple statements saying transfer money from an account A to account B, or change the state of account A for a new value. It is important that a properties of a transaction should be set only once, practically at the beginning, to avoid possible hacking attempts. A transaction should contain at least the following elements:
- TransactionId, it is actually a hash of all the important values of a transaction. Practically the hash of all of the previous elements. TransactionId provided on the one hand as a kind of a primary key for the transaction itself, the transaction can be identified based on this Id. On the other hand, it might provide a kind of a hacking resistance consistency the transaction is only valid if the TransactionId is consistent with the other values. It is certainly a question if the TransactionId itself should be stored on the blockhain or if it is enough to generate it. If we generate the value, we might miss one consistency guarantee, on the other hand we might as well save storage space on the chain. At any case TransactionId is practical if we want to refer to created but still not signed transactions on the client side.
- Nonce: the value should avoid replay attacks. It should be set by the wallet software as an incremental value of the account nonce.
- Address: the address of the account that we want to modify, or from which address we want to transfer cryptocurrency. If the address is the public key, this field should contain the public key, if it is calculated value of the public key like with hashing or double hashing, than this calculated value should be here.
- Signature: valid transactions must have a signature, which is the data of all relevant information in the transaction, signed by the private key. The signature is generated by the used cryptographical algorithm, like with the help of Elliptic Curve Cryptography. In case we have TransactionId as well, than this id should not necessarily be presented in the signature. The reason for that is that we might want to administrate valid but still not signed transaction on the wallet side.
Depending on the exact transaction type we can have further properties as well. It is important to note that in a given system, we might as well several different kinds of transactions, like one for transferring money, and further ones for setting data, like in case of an identity management system.
- ToAddress: if our transaction is a value movement transaction, we will need the address where we want to move the money.
- Amount: in case of a value movement transaction, we will need the amount to transfer as well.
- Data: if our transaction is meant to register data in the blockchain, we will need the new data value as well.
Transactions need to have the following functionalities:
- Create transaction: in a way that all of the important properties can only be set once.
- SignTransaction: with a private key and a given cryptography the signature of the transaction can be created. The signature should be in case as well to be able to set only once.
- VerifyTransaction: based on the signature, exiting data parameters and public key, the signature can be verified. If the public key is directly the address, the signature is simple. If the address is derived with a hash function from the public key, the public key must be also given as an input.
Advanced scenarios might have further functionalities as well, like creating raw transactions, or partially sign transactions.
