Transactions Pool

What is a Transactions Pool?

The transaction pool is a collection of unconfirmed transactions on the Ellcrys network. Each node on the Ellcrys network maintains its collection of unconfirmed transactions.

When a user creates a transaction and sends it to a node, it adds the transaction to its transaction pool and broadcasts that transaction to its peers who also add the transaction to their transaction pool and rebroadcast.

Miners collect transactions from the pool to create to blocks. When a miner successfully finds a correct proof-of-work nonce for a given block, she sends the candidate block to her peers who then validate and add the blocks to their local chain. Once a block is accepted, the transactions in the block are removed from the transaction pool.

Block Space & Transaction Fee

An Ellcrys block has a limited number of transactions that can be added to it. Miners primarily select transactions in a way that maximizes their profit in relation to the transaction fee, size and amount of available block space.

Since transactions vary in size, users are expected to pay a minimum transaction fee which depends on the amount of space their transactions will use up in a block. The formula for calculating minimum transaction fee:

Minimum Fee = Transaction Byte Size x Fee Per Byte

Transaction fees act as a deterrent against spam and DDOS attacks. They also serve as incentives for miners to continue to run nodes and support the network.

Fee Rate

To maximize profit, a miner calculates a score for each transaction that allows them to select the transactions that will earn them the most money. This score is known as feerate. The feerate of a transaction determines how fast the transaction is added to a block. A transaction with a high fee rate will be prioritised over a transaction with a lower fee rate.

Transaction feerate is calculated easily:

Feerate = Transaction Fee / Byte Size of Transaction

Transaction Ordering

Transactions in the pool are ordered first by their fee rate. However, transactions from same originating address are ordered by their nonce first and then by feerate.

For example, if Alice sent two transactions X and Y with X having a fee rate of 10, nonce of 2 and Y with a feerate of 30, nonce of 3; Transaction X will have a higher priority even though it has a lower feerate. Transaction nonce maintains the order of transactions and protects against double-spend attacks.