set default in config.toml: mempool setting to v1

[CharlieMc0]

If we want to encourage validator to use a prioritized mempool (Based on gas price) we should set it as the default config when operators run zetacored init

#######################################################
###          Mempool Configuration Option          ###
#######################################################
[mempool]

# Mempool version to use:
#   1) "v0" - (default) FIFO mempool.
#   2) "v1" - prioritized mempool.
version = "v0"

Explanation:

The Cosmos SDK is a framework for building blockchain applications. It includes a mempool (short for "memory pool") where transactions are temporarily stored before they are included in a block and added to the blockchain. The Cosmos SDK supports two types of mempools: FIFO (First-In-First-Out) and Prioritized.

FIFO Mempool:

Order of Inclusion: In a FIFO mempool, transactions are included in the order they are received. The first transaction to arrive is the first to be processed and added to a block.

Simple and Fair: FIFO mempools are simple to implement and ensure a fair and straightforward way of processing transactions. Transactions are processed on a first-come, first-served basis, which can be desirable in certain scenarios.

Predictable Behavior: Users can reasonably predict when their transactions will be included in a block based on the order they submitted them.

Drawbacks: FIFO mempools may not consider other factors like transaction fees or gas prices, so they may not optimize for transaction inclusion in terms of network congestion or fees.

Prioritized Mempool:

Order of Inclusion: In a prioritized mempool, transactions are ordered based on certain criteria, such as transaction fees or gas prices. Transactions offering higher fees are given priority and are more likely to be included in the next block.

Fee Optimization: Prioritized mempools are designed to optimize transaction inclusion by allowing users to set their transaction fees. Miners and validators are incentivized to prioritize transactions with higher fees, which helps manage network congestion and ensures that users have a way to expedite their transactions when necessary.

Dynamic Behavior: Prioritized mempools adapt to network conditions, as transactions with higher fees become more attractive to validators and are included sooner.

Drawbacks: While prioritized mempools are more efficient in terms of fee optimization, they can sometimes lead to situations where users with lower fees experience longer confirmation times during periods of high network congestion.

The choice between FIFO and prioritized mempools depends on the blockchain's specific requirements and design goals. For example, some blockchains may opt for a FIFO mempool to ensure fairness, while others may prioritize efficient fee optimization to encourage users to pay higher transaction fees for quicker processing.

In practice, many blockchains implement mempool algorithms that combine elements of both FIFO and prioritization, allowing for a balance between fairness and efficiency in transaction processing. Ultimately, the choice of mempool type can impact the user experience, the economics of the network, and the overall performance of the blockchain system.

[lumtis]

Would we consider #734 as resolved upon completion of this one?

[kingpinXD]

@CharlieMc0 Can you provide an example of how you would use the prioritized mempool .
This seems like an option, but it's unclear what the implementation would look like. For example, can attackers exploit the fact the zetaclients submit constant fee transactions?

[lumtis]

@CharlieMc0 Can you provide an example of how you would use the prioritized mempool . This seems like an option, but it's unclear what the implementation would look like. For example, can attackers exploit the fact the zetaclients submit constant fee transactions?

Prioritize mempool prioritizes the transactions based on the gas price. Right now this is already a configuration that validators can set for their node (and they should be incentivized to use this), the idea is to put this configuration by default for initialized nodes.
If we don't support gas price increase in the network on the ZetaClient, it might be something we should consider prioritizing (this is already a problem outside of this issue)

[brewmaster012]

@CharlieMc0 Can you provide an example of how you would use the prioritized mempool . This seems like an option, but it's unclear what the implementation would look like. For example, can attackers exploit the fact the zetaclients submit constant fee transactions?

Prioritize mempool prioritizes the transactions based on the gas price. Right now this is already a configuration that validators can set for their node (and they should be incentivized to use this), the idea is to put this configuration by default for initialized nodes. If we don't support gas price increase in the network on the ZetaClient, it might be something we should consider prioritizing (this is already a problem outside of this issue)

What about txs from the same address? They should follow sequence number instead of gas fee/price right?

[lumtis]

@CharlieMc0 Can you provide an example of how you would use the prioritized mempool . This seems like an option, but it's unclear what the implementation would look like. For example, can attackers exploit the fact the zetaclients submit constant fee transactions?

Prioritize mempool prioritizes the transactions based on the gas price. Right now this is already a configuration that validators can set for their node (and they should be incentivized to use this), the idea is to put this configuration by default for initialized nodes. If we don't support gas price increase in the network on the ZetaClient, it might be something we should consider prioritizing (this is already a problem outside of this issue)

What about txs from the same address? They should follow sequence number instead of gas fee/price right?

Yes, they are processed sequentially from the sequence independently of the gas price