3

I've been thinking on restrictions around concurrency of smart contracts given the deterministic nature of the EUTXO model, and I've had trouble finding an answer to how transactions are prioritized for a block in the case where multiple valid transactions exist visible to a node redeeming a single UTXO. Is this left to the slot leader to decide?

This question also leads into another question I have, which is: Is network spam somehow a viable concurrency model since fees are not charged for simple validation failure? Like say you change the Uniswap implementation to allow for multiple liquidity pools of a given trading pair (thus multiple corresponding UTXOs) Would it be viable to submit multiple transactions redeeming overlapping UTXO's in the hope that only one transaction would go through?

Maybe this is still being thought about and maybe this question is ultimately silly, but I was hoping to hone in my thinking around this a bit.

Improve this question

1 Answer 1

Reset to default
2

We may need different models than what has been done in Uniswap, Keep in mind that Hyrda is coming and can get us around this problem. Unlike other L2 solutions for other blockchains, Plutus code runs with Hydra out of the box so by then this may not be an issue.

Prof, Aggelos Kiayias explains here I recommend watching the whole video.

Improve this answer
1
  • I understand that Hydra may render all this moot, but I'm still curious about what sort of tricks we'll have at our disposal for achieving something closer to concurrency at the base layer.
    – AscendantMediocre
    Commented Jul 8, 2021 at 5:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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