<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>

CC BY-SA 4.0
2022-04-06T04:19:57.767Z
Thanks, this was helpful in understanding where ChainIndex comes from. It's not used in PPP iteration 2 (the code I'm referencing) but is used in the Plutus Starter project (what I'm using as a template for my projects). The plutus branch with ChainIndex is also not included in main yet, so it took me a while to find the right plutus commit to match my Plutus repo with the plutus-starter set up.
marcel_g
CC BY-SA 4.0
2022-01-26T02:06:36.663Z
2022-01-26T02:06:36.663Z
LexTRX
<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>

<plutus-pioneer-program>
Pioneer Q&A question: Where is datum actually stored?
# Pioneer Q&A question: Where is datum actually stored?

(Asked by: username_0 on 2022-01-16)

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)?

**Tags:** plutus-pioneer-program

---

## 1 answers

### Answer by username_1 on 2022-01-26. Score: 3

***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.*

> **Comments:**
> **username_2**: Thanks, this was helpful in understanding where ChainIndex comes from. It's not used in PPP iteration 2 (the code I'm referencing) but is used in the Plutus Starter project (what I'm using as a template for my projects). The plutus branch with ChainIndex is also not included in main yet, so it took me a while to find the right plutus commit to match my Plutus repo with the plutus-starter set up.  

---

