I heard from @ArthurB that mempool management is one of the core aspects of developing a new blockchain. This in turn is impacted by the choice of how to represent balances in the chain, namely UTXO vs account model.

Since Tezos is a chain that can manage smart contracts there are good arguments on why account model is more expressive to facilitate interactions between users and contracts. See here for example

UTXO vs account model

On the flipside when it comes to mempool management i have heard that UTXO makes it easier for a miner to choose any subset of transactions to include because the final chain state is indifferent to the order of those UTXO being applied whereas in an account model the order of transaction hitting a contract may impact its final state.

Does "non-commutativity" of the mempool due to account model create challenges for the mempool management strategy in Tezos ?

  • 2
    please accept the answer if you've found that it has provided you the necessary information – Sm00g15 Feb 3 '19 at 22:04

Sure, "non-commutativity" has its challenges. Mempool management is closely aligned with incentive mechanism and thus the baker's strategy. In tezos, as far I know, endorsement operations have higher precedence (preferred by bakers) as they determine the fitness of the block they are going to produce and therefore the chance of it being part of canonical chain.

Right now, other operations are then added to block using knapsack with constraints on block size and maximizing transaction fee. So it is the case that order in which operations are applied can invalidate some operations in mempool.

  • Thanks! Could you please expand on what is knapstack ? Also what is the location in the code base of tezos that relates to the mempool management if you are familiar with it ? – Ezy Feb 2 '19 at 18:58
  • Note also that you have answered why certain operations would be preferred by bakers before others (endorsements, high fees) but i don't fully grasp yet from your answer how non-commutativity is dealt with in practice. – Ezy Feb 2 '19 at 19:03
  • 2
    Details Knapsack can be found here (en.wikipedia.org/wiki/Knapsack_problem) . essential packing as many operations in block within block size limit and maximizing total tx fee. "Dealing with non commutativity" operation from a single account are always in a order (account + nonce), only one of the operations (with same nonce) will be executed, others become invalid. It is just really the order in which operation enter the canonical chain. Bakers don't really base their decision to include operation based on their effects on state. – Amit Panghal Feb 2 '19 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.