AIP-17 transaction pool

[fix]

  AIP: 17
  Title: transaction pool
  Authors: fx thoorens , chris
  Status: Done
  Type: Standards Track
  Created: 2018-05-29
  Last Update: 2018-11-29

Abstract

This is the description of transaction pool mechanism

Motivation

In order to manage properly the transaction pool and prevent spam, the rules are described in this document and implemented in ark-core v2

Rationale

Transaction pool rules:

1 - new unverified transaction is received:

• verify the transaction (using AIP-11 SER/DER), signature
• check if the txid (the one computed) is already in db -> if yes: reject
• find the wallets of the recipient and of the sender inside the pool
• if no wallet, COPY it from the blockchain
• test wallet.canApply
• if successful,apply transaction only to sender.

2 - new block added on blockchain

• find the wallet of delegate in txpool. if found apply the block rewards and fees to the delegate wallet, otherwise do nothing
• for each transaction
  • if txid in pool: remove tx from pool.
  • else find wallets from sender/recipient
    • if found recipient wallet, apply tx
    • if found sender wallet check canApply.
    • if ok use applyTransaction on this wallet
    • else (ouch: double spending): drop all tx from the sender in the txpool, apply this tx (canApply should be ok otherwise the txpool should be resetted)
    • if sender.apply succesfull
      • check if balance ==0 and no more transactions from sender then delete wallet from wallet Manager

3 - drop transaction (that was already in txpool as per rule 1)

• revert tx on wallets of sender and recipient. if recipient wallet is empty, remove from txpool

4 - every now and then clean unchanged wallet for over 24 hours or so

5 - apply some limit transactions per sender (configurable, around 50)

Specifications

Technical details or example of implementation

[doubled1c3]

5 - apply some limit transactions per sender (configurable, around 50)

Is this per a certain time period? Also, would this cause issues for delegate payout scripts, or completely valid transaction activity that happens to be high use?

[MatthewDC]

@doubled1c3 Keep in mind delegates will be able to transition to the new multiple recipient transaction type soon. This will negate the older scripts and would bundle delegate payouts into 1 actual transactions with multiple recipients that would then not be seen as spam in this case.

The same goes for vendors. Any traditional vendor processing multiple transactions in one block would be able to bundle said transactions into a multiple recipient transaction and reduce congestion on the network and avoid these limits. In a way it encourages the use of the new transaction type where possible while helping reduce spam/congestion on the network from a bad actor.

[kristjank]

@doubled1c3 besides multiple-payment transaction a delegate can whitelist his own sender in order to send a larger payload. Although it is recommended to batch the transactions so you don't spam the network. For other not know addresses a max of 100 transaction in pool per sender is set (you can change this on your own node actually). Until some of the senders transactions are forged and confirmed, he will have to wait, or add his sender public key to the allowed list.

[doubled1c3]

@MatthewDC @kristjank Hey, that's pretty cool!

[kristjank]

moved content to AIP folder: https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-17.md