Open Shimuuar opened 4 years ago
May I suggest a "partial parsing" approach?
First, I am thinking about possibly massively parallel monoidal parsing ([1] and [2] and [3]). Or, if you prefer, a parallel scan.
We sort transactions by their profitability first and perform beam search (basically, a breadth-first search with constrained front size). This can allow us to address several edge cases: we choose between conflicting transactions based on their profitability and we can also handle inclusion of less profitable transactions that allow for more profitable transactions to be included.
The validation part can also be handled partially: for each transaction we can add requirement that effects on the left provide necessary conditions; we also provide effects of transaction; when combining two transactions (or lists of transactions) we Logically AND required conditions that are not canceled and Logically OR conditions that are produced.
Essentially, it is application of associative operation in monoidal parsing or parallel prefix sums. Logical ANDs and ORs above can be implemented as merge operations, for most of the time.
And, as a side note, we can also select transactions that most probably will not be selected in a block or two. That would allow to spend more time selecting these and spare us from checking state more often when new block is received.
Filtering and creation of new block
Performance here is more critical for PoW since miner wants to create new candidate block as soon as he receives new block. Time spent for creation of candidate block is time lost for mining. Below I make assumption that conflicting transaction are relatively rare.
Transaction selection
We also want to be able to sort transaction by their fee/size ratio (or whatever is figure of merit for the miners). Right now they're stored in simple FIFO order. We may need to keep FIFO for transaction gossip purposes.
Gossip
Current transaction gossip is grossly inefficient. Node just send every transaction is has to every node. Following strategy should be more efficient: