Introduction

Transactions are the most important part of the Topl protocol. Everything else in Topl is designed to ensure that transactions can be created, propagated on the network, validated, and finally added to the global ledger of transactions (the blockchain). Transactions are data structures that encode the transfer of tokens between participants in the Topl system. Each transaction is a public entry in Topl's blockchain, the global bookkeeping ledger.

In this section, we will examine all the various forms of transactions, what they contain, how to create them, how they are verified, and how they become a permanent record of all transactions.

Transaction Lifecycle

A transaction's lifecycle begins with the transaction's creation, also known as origination. The transaction is then signed with one or more signatures indicating the authorization to spend the UTXOs referenced by the transaction. The transaction is then broadcast on the Topl network, where each Bifrost node (participant) validates and propagates the transaction until it reaches every node in the network. Finally, the transaction is verified by a forging node, and included in a block of transactions that is recorded on the blockchain.

Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmed), the transaction is a permanent part of the Topl ledger, and is accepted as valid by all participants. The UTXOs allocated to a new owner by the transaction can then be spent in a new transaction, extending the chain of ownership and beginning the lifecycle of a transaction again.

Creating Transactions

In some ways, it helps to think of a transaction in the same way as a paper check. Like a check, a transaction is an instrument that expresses the intent to transfer ownership of an asset and is not visible to the financial system until it is submitted for execution. Like a check, the originator of a transaction does not have to be the one signing the transaction.

Currently, transactions must be created online. But transactions can be created by anyone, they do not have to have the credentials for a particular address. For example, an accounts payable clerk might process payable checks for signature by the CEO. Similarly, an accounts payable clerk can create Topl transactions and then have the CEO apply digital signatures to make them valid. Whereas a check references a specific account as the source of the funds, a Topl transaction references specific boxes that have been generated by a prior transaction as its source, rather than a particular account.

Once a transaction has been created, it is signed by the owner (or owners) of the source of the funds. If it is properly formed and signed, the signed transaction is now valid and contains all the information needed to execute the transfer of tokens. Finally, the valid transaction has to reach the Topl network so that it can be propagated until it reaches a forger for inclusion in the public ledger (the blockchain)

Broadcasting Transactions to the Topl Network

First, a transaction needs to be delivered to the Topl network so that it can be propagated and included in the blockchain. In essence, a Topl transaction is just a few bytes of data and has to reach any one of many Bifrost nodes. The senders do not need to trust the nodes they use to broadcast the transaction, as long as they use more than one to ensure that it propagates. The nodes don't need to trust the sender or establish the sender's "identity". Because the transaction is signed and contains no confidential information, private keys, or credentials, it can be publicly broadcast using the JSON-RPC routes. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on an encrypted network, a Topl transaction can be sent over any network. As long as the transaction can reach a Topl node that will propagate it into the Topl network, it doesn't matter how it is transported to the first node.

Topl transactions can therefore be transmitted to the Topl network over insecure networks like WiFi. As an extreme example, a Topl transaction could even be encoded in smileys (emoticons) and posted in a public forum or sent as a text message or Skype chat message.

Polling for Transactions on the Topl Network

Once a Topl transaction is sent to any node connected to the Topl network, the transaction will be validated by that node. If valid, that node will propagate it to the other nodes to which it is connected. If the transaction is invalid, the node will reject it and remove the transaction from the queue of transactions (mempool).

The Topl network is a peer-to-peer network, meaning that each Bifrost node is connected to a few other Bifrost nodes that it discovers during startup through the peer-to-peer protocol. The entire network forms a loosely connected mesh without a fixed topology or any other structure, making all nodes equal peers. Messages, including transactions and blocks, are propagated from each node to the peers to which it is connected. A new validated transaction injected into any node on the network will be sent to three or four of the neighboring nodes, each of which will send it to three to four more nodes, and so on. In this way, within a few seconds a valid transaction will propagate in an exponentially expanding ripple across the network until all connected nodes have received it.

The Topl network is designed to propagate transactions and blocks to all nodes in an efficient and resilient manner that is resistant to attacks. To prevent spamming, denial of service attacks, or other nuisance attacks against the Topl network, every node independently validates every transaction before propagating it further. A malformed transaction will not get beyond one node.

Due to this setup, the originator should poll the mempool periodically. Once a transaction has left the mempool, it could either be because it was incorporated into a new block, or because it was malformed. Thus, after getting an unsuccessful hit from the mempool, the originator should then query the blockchain itself to see if the transaction was incorporated into a block. Only after getting a successful response from the blockchain should they proceed to using any UTXOs that were generated as a result of the transaction. This can be seen in the flow diagram below: