user5906: Question for Plutus Pioneer cohort 3 Q&A week 1
I'm new to Plutus dev and trying to work out where the datum value is actually stored in a typical Plutus application.
From various sources (docs/blogs/videos) it seems that the value can be stored in the EUTxO or provided in the Tx (from the off-chain Tx creation code)?
I understand that initially the datum is provided in the Tx when the first script EUTxO is created, but when the datum is updated after the mechanics of querying/updating the datum are confusing/unclear. Some of the sources I've looked at use code to explain what's happening, but I'm not yet that skilled with Haskell so they don't help.
Can someone walk through an example or two and clarify where the data value comes from and where it is stored?
For example (with my limited understanding), it seems like in the EnglishAuction example the datum could be actually stored in the EUTxO (with the first Tx) - not just a hash of the datum - and then when future Tx's are created (by off-chain code) the Plutus app code would read this datum value from the EUTxO, update it and pass it with the new Tx.
First, is this correct?  Or does it work differently?
This interpretation sort of makes sense, but how does this relate/work with the Datum hash that people/docs say is stored in the EUTxO?
Also the EnglishAuction example seems to make sense where there's only one script EUTxO at any time (for a script instance), but how does this work in applications where the applications state is split across multiple EUTxOs (multiple datums - fragmented state)?

user4911: This was Lars response to this question in the ppp Q&A on 25/Jan/22. Recording timestamp 0:53:57

The datum is not stored in UTxO but in the transaction. Even if the
datum was included in the transaction it is not completely trivial to
get your hands on it. The Cardano node, for example, does not know it,
the Cardano node sees it during validation but then sort of forgets
about it, so you can't ask the node what's the datum for a transaction
or a UTxO.
There are tools such as DbSync, which scans and writes all your
blockchain transaction to a database, including the datum, so there is
one way to get to the datum by hand.
Also the Plutus apps team has come up with a lightweight option of
DbSync called chainindex, so that's exactly for that reason, also
keeps track of all the datums.
There also 3rd party providers, blockfrost, a website where they
run dbSync for you, you just do REST calls to their server, give a TX
ID, or some reference UTxO and they give you the datum. It is stored
in the transaction and somehow it disappears in the wherever the
blockchain stores it on the machine.
If the datum was not stored with the transaction, then people that
don't know it have no way of consuming this UTxO, if the person that
created this UTxO, the default is to include just the hash of the
datum then other people normally wouldn't be able to spend the UTxO,
because in order to spend it you have to provide the Datum, in this
case there must be another channel to communicate the datum. Maybe by
design you don't want people to spend your UTxO, but if do you want
them to spend it and you don't include the Datum just the datum hash,
then you must put the datum on your website or something, so  people
is able to spend the UTxO.
Last question, I'm not too sure if I understand the question, if there
are more than one instances:
Yes it can happen or also it should happen, that's one way of handling
concurrency in Plutus, to do this: that you don't just rely only in
one specific UTxO that carries all the state, you fragment the state
and then you can achieve massive concurrency, but I'm not really sure
of what the question is about how does it work? The stated is
fragmented.
It depends on the specific example: in the auction example in the
first iteration, there was a question of what happens if it is a
popular auction and lots of people want to bid, in the way the example
is written, there can only be one bid per block, so basically 3 bits
per minute. Small auctions should be fine, but if it is highly
contentious then maybe that's too slow and then you will have this
concurrency issue because only one bid can successfully consume the
current UTxO and produce a new one, so you can only have one bid per
block in this setup.
One way to sort this issue is to split the auction into several, for
example ten auction UTxOs, and if you want to make a bid you can do
that on each of those, but then you wont know globally what's the
highest bidder, each of the 10 could keep track of the highest bid
that that one has seen, but it is not aware of the other, in that
specific example, in the end, in the close, you would combine all of
them and find out which one is the highest bid and then reimburse the
others. but it is a specific example. It depends on your business
case.
In the auction example you achieve concurrency but you need to
recombine again. For a DEX for example, on a decentralized exchange,
in Uniswap in Ethereum for one token pair they have one pool normally,
and that would be horrible on Cardano because it would mean one swap
per pair per block, so one idea would be to split the liquidity pools
into several UTxOs and you may not need to recombine, they could
happily coexist, each pool doing their own thing, it could be one
option.
But it always depends on  your use case, what fragmented state even
means and whether it is feasible.


5906: <p>Question for Plutus Pioneer cohort 3 Q&amp;A week 1</p>
<p>I'm new to Plutus dev and trying to work out where the datum value is actually stored in a typical Plutus application.</p>
<p>From various sources (docs/blogs/videos) it seems that the value can be stored in the EUTxO or provided in the Tx (from the off-chain Tx creation code)?</p>
<p>I understand that initially the datum is provided in the Tx when the first script EUTxO is created, but when the datum is updated after the mechanics of querying/updating the datum are confusing/unclear. Some of the sources I've looked at use code to explain what's happening, but I'm not yet that skilled with Haskell so they don't help.</p>
<p>Can someone walk through an example or two and clarify where the data value comes from and where it is stored?</p>
<p>For example (with my limited understanding), it seems like in the EnglishAuction example the datum could be actually stored in the EUTxO (with the first Tx) - not just a hash of the datum - and then when future Tx's are created (by off-chain code) the Plutus app code would read this datum value from the EUTxO, update it and pass it with the new Tx.</p>
<p>First, is this correct?  Or does it work differently?</p>
<p>This interpretation sort of makes sense, but how does this relate/work with the Datum hash that people/docs say is stored in the EUTxO?</p>
<p>Also the EnglishAuction example seems to make sense where there's only one script EUTxO at any time (for a script instance), but how does this work in applications where the applications state is split across multiple EUTxOs (multiple datums - fragmented state)?</p>
 4911: <p><em><strong>This was Lars response to this question in the ppp Q&amp;A on 25/Jan/22. Recording timestamp 0:53:57</strong></em></p>
<blockquote>
<p><em>The datum is not stored in UTxO but in the transaction. Even if the
datum was included in the transaction it is not completely trivial to
get your hands on it. The Cardano node, for example, does not know it,
the Cardano node sees it during validation but then sort of forgets
about it, so you can't ask the node what's the datum for a transaction
or a UTxO.</em></p>
<p><em>There are tools such as <strong>DbSync</strong>, which scans and writes all your
blockchain transaction to a database, including the datum, so there is
one way to get to the datum by hand.</em></p>
<p><em>Also the Plutus apps team has come up with a lightweight option of
DbSync called <strong>chainindex</strong>, so that's exactly for that reason, also
keeps track of all the datums.</em></p>
<p><em>There also 3rd party providers, <strong>blockfrost</strong>, a website where they
run dbSync for you, you just do REST calls to their server, give a TX
ID, or some reference UTxO and they give you the datum. It is stored
in the transaction and somehow it disappears in the wherever the
blockchain stores it on the machine.</em></p>
<p><em>If the datum was not stored with the transaction, then people that
don't know it have no way of consuming this UTxO, if the person that
created this UTxO, the default is to include just the hash of the
datum then other people normally wouldn't be able to spend the UTxO,
because in order to spend it you have to provide the Datum, in this
case there must be another channel to communicate the datum. Maybe by
design you don't want people to spend your UTxO, but if do you want
them to spend it and you don't include the Datum just the datum hash,
then you must put the datum on your website or something, so  people
is able to spend the UTxO.</em></p>
<p><em>Last question, I'm not too sure if I understand the question, if there
are more than one instances:</em></p>
<p><em>Yes it can happen or also it should happen, that's one way of handling
concurrency in Plutus, to do this: that you don't just rely only in
one specific UTxO that carries all the state, you fragment the state
and then you can achieve massive concurrency, but I'm not really sure
of what the question is about how does it work? The stated is
fragmented.</em></p>
<p><em>It depends on the specific example: in the auction example in the
first iteration, there was a question of what happens if it is a
popular auction and lots of people want to bid, in the way the example
is written, there can only be one bid per block, so basically 3 bits
per minute. Small auctions should be fine, but if it is highly
contentious then maybe that's too slow and then you will have this
concurrency issue because only one bid can successfully consume the
current UTxO and produce a new one, so you can only have one bid per
block in this setup.</em></p>
<p><em>One way to sort this issue is to split the auction into several, for
example ten auction UTxOs, and if you want to make a bid you can do
that on each of those, but then you wont know globally what's the
highest bidder, each of the 10 could keep track of the highest bid
that that one has seen, but it is not aware of the other, in that
specific example, in the end, in the close, you would combine all of
them and find out which one is the highest bid and then reimburse the
others. but it is a specific example. It depends on your business
case.</em></p>
<p><em>In the auction example you achieve concurrency but you need to
recombine again. For a DEX for example, on a decentralized exchange,
in Uniswap in Ethereum for one token pair they have one pool normally,
and that would be horrible on Cardano because it would mean one swap
per pair per block, so one idea would be to split the liquidity pools
into several UTxOs and you may not need to recombine, they could
happily coexist, each pool doing their own thing, it could be one
option.</em></p>
<p><em>But it always depends on  your use case, what fragmented state even
means and whether it is feasible.</em></p>
</blockquote>
