5

Scenario

There are two transactions tx1 and tx2 both trying to consume an arbitrary eUTXo oRef. Both tx1 and tx2 are submitted to the mempool in the same block, and are valid transactions; we can consider them identical for the purpose of the question.

Questions:

  1. When does oRef get consumed? Would oRef exist until the next block?

  2. Would oRef be observable in the same block to a third transaction tx3 which was submitted later than the initial two?

  3. Is there a deterministic mechanism chosing which of the two/three transactions gets accepted?

1
4

The question was also answered by a member of the IOHK team, on a secondary channel. I will post the answer here for community reference.

Answer

  1. UTxO entries are consumed "immediately after" the Tx that uses them as an input is validated. That is "after" in the blockchain order. No subsequent transaction in the same block or later blocks can use the oRef input. This is the "no double spend" property, also enforced for Txs in the mempool of any individual node.

  2. The order of execution is inherently non-deterministic. If one Tx is submitted well before the other then the first one is most likely to make it in first. If they are submitted from different points in the network (i.e. by different users) then it is very much non-deterministic which one makes it first. In future there will be limited ways to prioritise, but this example would still depend on timing and be non-deterministic. (The priority mechanism is aimed at ensuring a certain class of latency for inclusion).

Extra information

Txs, disimilar to bitcoin, don't hang around in the mempool for long. The Cardano mempool only acts as a small buffer to smooth out the traffic flow. If the system is saturated, Txs are held at the edge of the network (e.g. in the mempool of on the local node).

So Txs are not in the mempool for long at all. Its behaviour is more like a narrow pipe of fast-flowing water rather than a pool.

4

Great questions.

When does oRef get consumed? Would oRef exist until the next block?

oRef will be consumed when a transaction spends it. If txn1 is executed before txn2, even in the same block, txn2 will fail. Luckily, the sender of txn2 will not pay a fee for such a failed transaction.

Would oRef be observable in the same block to a third transaction tx3 which was submitted later than the initial two?

No. See above.

Is there a deterministic mechanism choosing which of the two/three transactions gets accepted?

By default, the block builder will just include the transactions in the order they see them. Of course, no one is able to stop the builder from putting them in whichever order they want (or excluding them altogether). This is where the concept of Miner Extractable Value comes from, which is still possible on Cardano.

0

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.