Tx Priority feature for POSDAO

[varasev]

We decided to have this feature a non-consensus, i.e. each validator can define their own TxPriority contract without the agreement with other validators. The contract's address should be defined in some config parameter (in the MiningConfig section, I think).

Also, tx priority rules described in the contract should be able to be defined in the config file (in the same MiningConfig section). The rules can be in the contract and in the config file simultaneously and should be joined together (union of the on-chain and off-chain sets), so some rules can be defined publicly (in the contract) and some other rules can be defined as hidden rules in the node's config file.

There is TxPriority contract which defines three types of rules:

1. Transaction targets (destinations) sorted by descending of weight.

2. Whitelist of top priority senders.

3. Additional Min Gas Price filter for certain targets.

1. Transaction destinations.

We'd like to prioritize transactions by their to and data fields. There are three functions in the contract for that:

• setPriority
• removePriority
• getPriorities

and a couple of public getters:

• destinationByWeight
• weightByDestination

When we want to add or change the weight for some transaction, we call setPriority and pass a target address, a 4-byte function signature, and the weight for this destination. The more the weight, the more priority such a transaction will have.

The target address can be either EOA or a contract.

The fnSignature parameter defines the first 4 bytes of tx data field: it can be 0x00000000 for EOA target address or if transaction assumes sending coins to a contract without calling any function (when the data field is empty).

For example, we have the following two rules:

target = 0xaa...bb
fnSignature = 0x12345678
weight = 2000

target = 0xaa...bb
fnSignature = 0x90876543
weight = 1000

In this case, if there are transactions with such destinations, the txs matching the first destination (with weight = 2000) should be mined earlier than txs matching the second one (with weight = 1000). If there is a transaction with the same to field but with a different signature in data (the first 4 bytes), it shouldn't be prioritized because there are no rules (destinations) defined for it.

If we define the following destination

target = 0xcc...dd
fnSignature = 0x00000000
weight = 3000

it should only apply to transactions with empty data field and to equal to 0xcc...dd.

The TxPriority contract stores a permanently sorted list of destinations (by their weights). We use Red-Black Binary Search Tree for sorting.

In addition to the getPriorities public getter, the weightByDestination and destinationByWeight public getters can be used to determine a weight of a certain destination or get a destination by its weight.

The weight for each destination is unique and cannot be zero.

2. Whitelist of top priority senders.

There can be a short whitelist of from addresses which must have a top priority (higher than others defined by the setPriority).

We have two simple functions for that:

• setSendersWhitelist
• getSendersWhitelist

If there is a transaction with from field matching one of the whitelisted addresses, such a transaction must be prioritized higher than others.

3. Additional Min Gas Price filter.

This point is not for prioritization, but for tx filtering.

There are the following functions and getters in the contract for this:

• setMinGasPrice
• removeMinGasPrice
• getMinGasPrices

The minGasPrice cannot be zero here and should be ignored if it is less than MinGasPrice defined in node's config. Please, read setMinGasPrice description for details: https://github.com/poanetwork/posdao-contracts/blob/49e2c37e43296f06ee25795ceeb9acc16b8c64c8/contracts/TxPriority.sol#L111-L122

[varasev]

TxPriority ABI JSON: TxPriority.abi.json.zip

[varasev]

TxPriority constructor bytecode: TxPriority.bytecode.txt

[varasev]

@LukaszRozmej I updated the bytecode above 👆 Nothing was changed, just refactored a bit.