Sign Transaction

Signing transaction

The transaction is processed for signing. It is classified into 2 types of transactions based on status:

Signed Transactions

• Signed transactions contain the signature of the account that issued the transaction and stands to pay a fee to have the transaction included on the chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam.

• Signed transactions fit the concept of a transaction in Ethereum or Bitcoin.

Unsigned Transactions

• Some cases call for unsigned transactions. Use unsigned transactions with care, as their validation logic can be difficult.

• Since the transaction is not signed, there is nobody to pay a fee. Because of this, the transaction queue lacks economic logic to prevent spam. Unsigned transactions also lack a nonce, making replay protection difficult. A few transactions warrant using the unsigned variant, but they will require some form of spam prevention based on a custom implementation of a signed extension, which can exist on unsigned transactions.

• An example of an unsigned transaction is the I'm Online heartbeat transaction sent by authorities.

Example: If the local node is a validator (i.e. contains an authority key), this module gossips a heartbeat transaction with each new session. The heartbeat functions as a simple mechanism to signal that the node is online in the current era.

Received heartbeats are tracked for one era and reset with each new era. The module exposes two public functions to query if a heartbeat has been received in the current era or session.

The heartbeat is a signed transaction, which was signed using the session key and includes the recent best block number of the local validators chain as well as the NetworkState. It is submitted as an Unsigned Transaction

Signed Extension

• SignedExtension is a trait by which a transaction can be extended with additional data or logic. Signed extensions are used anywhere you want some information about a transaction prior to execution. This is heavily used in the transaction queue.

  The runtime can use some of this data, for example, the Call that will be dispatched, to calculate transaction fees. Signed extensions also include a AdditionalSigned type that can hold any encodable data, and therefore allow you to perform any custom logic prior to including or dispatching a transaction. The transaction queue regularly calls functions SignedExtension to validate transactions prior to block construction to avoid including transactions that will fail in blocks.

• Despite the name, SignedExtension can also be used to verify unsigned transactions. The *_unsigned set of methods can be implemented to encapsulate validation, spam, and replay protection logic that is needed by the transaction pool.