Transactions

As an indispensable part of the blockchain, transactions provide the mechanism to modify the information state stored on the chain. Each transaction history will be recorded on the block. The transactions have the following three types:

• Signed transaction

• Unsigned transaction

• Inherent transaction

Signed transaction

In CESS network, signed transaction is the most common transaction type. When sending a signed transaction request, the signature of the requesting account must be attached. Usually, this is achieved by signing the transaction content using the private key of the requesting account. In addition, the requesting account also needs to pay transaction fees. The processing method of transaction fees and other elements depends on the program logic.

For a signed transaction, only the sender needs to pay the transaction fee. For example, if you need to transfer a certain number of tokens from your account to others, you can invoke the transfer transaction in pallet::balance. Since your account called this transaction, you should use your account private key to sign the transaction. At the same time, in the process of sending the request, you can choose to attach a tip to raise the processing priority of this transaction in the network.

Unsigned transaction

The vast majority of transactions are signed transactions, only a few of thme are unsigned transactions. Unsigned transactions are not initiated by the user, but are requested by the network through the off-chain worker.

No fees will be charged for unsigned transactions, and no information of the requester is required. This means that there are no economic restrictions on unsigned transactions, thus spam requests or replay attacks may occur.

Therefore, the logic control of unsigned transactions must be very strict. In addition, since unsigned transactions are user-defined verification processes, they usually consume more resources than signed transactions.

In CESS network, only the validator of current rotation can be the initiator of an unsigned transaction. The request content needs to be attached with the signature digest of the specific account in order to pass the user-defined verification in CESS network.

There is also a module using unsigned transactions in Substrate framework: pallet_im_online::call::heartbeat transaction. This transaction enables the validator node to send a message to the network to confirm that the node is online. For this transaction, Substrate has a strict verification process, and only accounts registered as validator nodes are allowed to send.

Intrinsic transaction

Intrinsic transaction is a special type of unsigned transaction. Through this type of transaction, the block producing node can directly insert information to the block. Generally, this type of transaction will not be gossiped to other nodes or added to the transaction queue. We will consider it valid without specific verification.

In CESS network, the Intrinsic transaction is not used. But in Substrate framework, the pallet::timestamp::call::now transaction uses the Intrinsic type to insert the current timestamp to the produced block. Although the other nodes cannot confirm whether the timestamp contained in the block information is correct, they can determine whether the timestamp is within the acceptable range. If it is not within the range, they can reject the block.

Transaction fee and weight

When executing transactions and uploading data on the chain, it will change the state of the chain and cost blockchain resources. As mentioned earlier, because the available resources in the blockchain are very limited, how to use and manage resources is very important. Besides the fixed resource of storage capacity of the block, there may also be malicious users sending a large number of messages to cause network overload, thus preventing the network from producing blocks.

To prevent the over consumption of resources, two methods are used in CESS, which are weight and transaction fees.

The relationship among transaction, weight and transaction fee is as follows:

The time length of transaction execution is expressed as weight. Weight affects the amount of transaction fee. The greater the weight, the more expensive the transaction fee is.

In addition, the role of weight not only affects the transaction fee, but also affects the execution time of a block. Part of the weight will be consumed in initializing and finalizing the block. In order to prevent malicious users from sending unnecessary transaction requests and causing system overload, the weight is usually used in combination with the transaction fee.

Transaction fees provide economic incentives to limit execution time and the number of calls required to calculate and execute operations. Transaction fees are also used to make blockchain economically sustainable (some of them will be returned to the bonus pool and distributed as a new round of token), because they are usually applied to transactions initiated by users and deducted before executing transaction requests.

The final composition of transaction fee:

Basic fee - the fee is the minimum amount that the user pays for the transaction.

Weighted fee - the fee is proportional to the time consumed by the transaction.

Byte length fee - the fee proportional to the length of the transaction code. The fee for each byte is multiplied by the length of the transaction code.

Target fee adjustment - a multiplier that can be adjusted according to network congestion.

Formula:

Inclusive fee = basic fee + byte length fee + (target fee adjustment * Weighted fee )

Final fee = inclusive fee + tip