Neptune-Crypto / neptune-core / 15778825012

75%

Build Type

push

github

Committed by Sword-Smith

Commit Message

Merge branch `jfs/separate_upgrader`

This merge works towards two goals:
- Improve the likelihood that weak computers have their transactions mined, and
- move closer to the vision of three-step mining as outlined here:
  https://talk.neptune.cash/t/thoughts-on-the-mempool-issue-and-upgrading/52/26

Three main changes:

    - Refactor mempool to never throw away PrimitiveWitness data.
    - Don't automatically run SingleProof's "update" branch when receiving a new
      block, but let "update" be handled by proof upgraders.
    - Add new task for upgraders: The updating of SingleProof backed transactions.

    Since ProofCollection-backed transactions cannot be updated to be valid under a new mutator set, we instead update them with their PrimitiveWitness if one such is present. A PrimitiveWitness will be present in the mempool if the transaction was initiated locally. Previously, a ProofCollection backed transaction would always throw out the PrimitiveWitness but with this change, the PrimitiveWitness is always preserved in the mempool, if it was ever present there (i.e. if the transaction was initiated locally).
    Replace TransactionOrigin in the mempool with an ordered UpgradePriority that can be used by proof upgraders to pick the most favorable transaction for proof upgrading -- this especially helps pick the best transaction for "update".
    Remove execution of the "update" branch from being done automatically by any composer when a new block is received to being a task that only the proof upgrader performs.
    Only locally initiated transactions (as checked by the presence of a primitive witness) are updated immediately after the receival of a new block.

The central part of the code to understand is, in my opinion, this loop in mempool's update_with_block, as it defined the rules for what to do with transactions that did not get mined in the new block.

Two questions are relevant for each transaction:
 - Should the transaction be updated ... (continued)

Run Details

650 of 753 new or added lines in 19 files covered. (86.32%)

21 existing lines in 5 files now uncovered.

20624 of 28526 relevant lines covered (72.3%)

505014.56 hits per line