<p>You're right, data transformations can be performed on UTXO's, and, to your first point, any app that requires rapid and/or complex data transformation produces too much bloat, as each transformation would produce at least one new UTXO.</p>
<p>Lil' Cardano Design Philosophy Review:</p>
<p>The &quot;main-chain&quot; (a.k.a., The CSL, Cardano L1, e.t.c.) is best suited for the <em>settlement</em> of data and logic, while a diverse ecosystem of &quot;side-chains&quot; (a.k.a. CCLs, Cardano L2s, e.t.c.) are best suited for <em>execution</em> of said data and logic. The extent of this bifurcation can be decided upon by the developer(s), and will vary widely depending on the security and throughput requirements of the dApp. Ultimately, it will be up to the dApp developer(s) to decide on a particular structure that makes sense.</p>
<p>In a PvP game like poker, settling and executing every move on main-chain can be done, but it would be slow, expensive, and uninspiring.
Instead, players/clients can commit their UTXOs as inputs-to-be-operated-on to a <a href="https://hydra.family/head-protocol/" rel="nofollow noreferrer">Hydra Head</a>. Head operators can engage in data transformation that is only limited by their own network throughput, while periodically committing snapshots back to the mainchain for dispute resolution.</p>
<p>(FYI: maintaining high composability while bifurcating settlement and execution of logic is the essence of Cardano's ability to scale limitlessly)</p>

CC BY-SA 4.0
2022-09-24T20:05:12.647Z
2022-09-24T20:05:12.647Z
zhekson
<p>Having a validator script with the ability to change the datum would not increase the power of Cardano's smart contract model. The reason is that, in the current model, validators can only use (as inputs to their logic) data that the transaction provides. The validator cannot run anything that the submitter of the transaction cannot also run. It makes, therefore, no difference if the datum is computed on- or off-chain.</p>
<p>The real reason you have the impression that the Ethereum model is more powerful is that, on the Ethereum blockchain, a smart contract can use the whole blockchain at execution time as input for its computation. This also means that the submitter of the transaction cannot know for sure the result of the smart contract execution as the blockchain could have changed between the moments of submitting and executing the transaction.</p>
<p>The biggest difference I see between Ethereum's and Cardano's smart contract models is that on Cardano it is more difficult to implement some uniqueness constraints in a decentralised way. For example, a minting policy cannot make sure that a token name is unique if the token name space is too large to fit into a script datum. A trusted party is necessary to enforce this uniqueness.</p>
<p>Apart from this, a random number generator is impossible on-chain and no existing blockchain implements one. Randomness always needs to be pushed to the chain from the outside world. This can be done by the means of oracles or by signed random numbers of a trusted off-chain source.</p>

CC BY-SA 4.0
2021-12-29T11:49:22.097Z
I'm not sure if you understand the question. I completely understand what UTXO is and no way calling Ethereum superior! But Cardano validators as they stand can only classify a transaction as valid or not. They still have access to the datum of the input UTXO/s to determine validity, but they cannot run code to set the outputs or datum of transactions that try to consume that UTXO. I don't see how not having access to the global blockchain state would be an issue here, hence my question.
micwallace
CC BY-SA 4.0
2021-12-29T11:54:50.457Z
Also there are a few ways of getting random numbers on-chain, it's not impossible.
micwallace
CC BY-SA 4.0
2021-12-29T13:10:36.047Z
I understood your question. Maybe you did not understand my reply. Also, I did not imply that you think Ethereum is superior. “Powerful” is meant in the programming sense.
Jey
CC BY-SA 4.0
2021-12-29T13:17:44.273Z
Maybe it is not clear to you that the validator script really has access to nothing except the inputs; not even to the slot number. It is purely functional.
Jey
CC BY-SA 4.0
2021-12-30T02:37:41.300Z
I could be wrong but the inputs include the datum hash (of the consumed UTXO), along with the datum and redeemer provided by the user input. So the validator script does have access to these things, but only for the specific UTXO being consumed by the transaction, not other UTXOs at the contract address. I believe that you can also validate based on the outputs of the provided transaction. So I don't see how it would be impossible to have a more advanced validator on-chain that takes a transaction and performs transformations on the outputs. That's what I'm trying to answer here.
micwallace
CC BY-SA 4.0
2021-12-30T02:43:44.850Z
In a purely theoretical sense! I don't expect it to happen anytime soon. Also isn't it the stake pool server that runs the on chain code? And all other nodes just validate that the SP produced a valid block? I didn't think all the nodes would have to run the validator script because they are validating blocks rather than individual transactions included in a block?
micwallace
CC BY-SA 4.0
2021-12-30T08:56:28.527Z
I don't know how else to explain. You already got the fundamental concept but you draw the wrong conclusions. Maybe you should try to write a validator that "performs transformations" to see that it does not make any difference. The reason being, as I said, that the validator can only act upon inputs that are completely determined by the actor constructing the transaction.
Jey
CC BY-SA 4.0
2021-12-31T00:44:26.940Z
But the inputs are a UTXO right? So (transaction signing aside) it wouldn't be impossible to have a validator that transforms the output datum and enforces that the output goes back to the script address? I'm just trying to understand if it would be at all possible to append an on-chain calculated datum in a UTXO ledger, in the way that Ethereum is able to modify the global state using an account model. At the moment all a validator does is return a boolean indicating a valid transaction. But what if it returns a boolean, plus the updated datum to use if a transaction is valid?
micwallace
CC BY-SA 4.0
2021-12-31T00:44:44.913Z
So in a chain of transactions, the last transaction (UTXO) always holds the most updated datum which is used in subsequent transactions.
micwallace
CC BY-SA 4.0
2021-12-31T00:53:51.297Z
Also I'm really looking for a deeper understanding of some of the technical limitations here. You keep repeating that it's not possible at the moment, which I'm already aware of. My question is really related to it's theoretical possibility and the technical considerations that lead to creating smart validators rather than a full-blown state machine.
micwallace
CC BY-SA 4.0
2021-12-31T07:46:51.997Z
No, by inputs I meant the whole transaction. This transaction already includes the updated datums. So in a way, the model does already what you are describing. There is no need to have the validator return anything else than a boolean.
Jey
CC BY-SA 4.0
2022-01-03T07:12:04.350Z
But the datums aren't updated by the on-chain script, they are completely arbitrary. Any user can provide any datum. There may be a way to validate the datum against the datum hash of the previous UTXO, but there's no way to transform that datum using the on-chain script. So I disagree that what I am asking is possible with the current state of Plutus scripts. But I do agree that this is the deterministic design of the current system. I think some use cases (like multi-round games i.e. blackjack) could benefit from non-deterministic datum output.
micwallace
CC BY-SA 4.0
2022-01-03T08:45:25.950Z
By your comments, I guess that you are misunderstanding something but I don’t know what. First, true randomness (needed for your game) is different from non-determinism for the triggerer of the tx. Second, having the script compile the datum makes only a difference in a non-determinististic model. In short: for your game, non-deterministic script execution is neither necessary nor sufficient. What you need is a trustworthy oracle.
Jey
CC BY-SA 4.0
2022-01-06T07:32:28.333Z
Oh man I'm more confused by every response. I'm not talking about randomness here. The limitation I'm trying to address is that in Plutus, a whole transaction is submitted, including the new datum. The the on-chain code is only verifying transaction validity. There is no ability to transform and output a new datum on chain. That's what I'm talking about when I'm talking about a non deterministic script - a script that generates the output datum for the submitted transaction.
micwallace
CC BY-SA 4.0
2022-01-06T07:53:27.080Z
Ok, give me one more chance in my most simple words: On Cardano, the player knows if he won before he posted the transaction (because deterministic). This will almost certainly never change. And because of this, shifting the compilation of  the final datum from off-chain to on-chain doesn't solve anything.
Jey
CC BY-SA 4.0
2022-01-08T11:39:56.243Z
Did the last comment help ?
Jey
CC BY-SA 4.0
2021-12-28T11:13:25.567Z
2021-12-28T15:54:52.473Z
2021-12-28T15:54:52.473Z
Jey
<p>I have been looking into creating a blackjack game on the Cardano Blockchain. I started with learning Haskell, and writing a simple blackjack CLI game. It was heaps of fun and a bit of a learning curve since I have never used functional languages before!</p>
<p>Unfortunately I misunderstood one critical thing about Plutus apps which mean that I could never implement this game in a truely decentralized way. That misunderstanding is that I could run arbitrary code and transform the datum in the on-chain code. This is true on Ethereum but not in Cardano, where the on-chain code can only determine if a transaction is valid.</p>
<p>I can't see any technical reason why a datum transformation couldn't be performed on a single UTXO, apart from performance considerations. So my main questions are:</p>
<ol>
<li><p>Is there any technical limitation preventing Cardano from implementing this functionality on L1 in the future? Or is it just to prevent L1 from becoming bloated with excessive datum storage and code execution?</p>
</li>
<li><p>Will there be a layer 2 that allows this functionality? Is this the idea of IELE?</p>
</li>
</ol>
<p>Appreciate any clarification here!</p>

CC BY-SA 4.0
2021-12-28T03:35:43.477Z
I should clarify that I need to draw a random card and update the state on-chain for this to be a truely decentralized app. It's true that I could probably setup some oracle off-chain to draw a card and update the game datum but this would be a lot more complex and a lot less decentralized.
micwallace
CC BY-SA 4.0
2021-12-28T08:27:14.903Z
Even if you had the functionality to change the datum on-chain, you would not be able to draw a random card. On-chain code is deterministic. Randomness can never be achieved, therefore. This is also true in Ethereum where you couldn‘t implement this as well. You can ask yourself, how would any node be able to verify that the card was really drawn randomly by another node of the network ? It is simply impossible: randomness cannot be proven and is therefore not implementable on-chain.
Jey
CC BY-SA 4.0
2022-01-27T21:45:37.703Z
@Jey At least not until we have verifiable random oracles on chain
zhekson
<plutus><smart-contract><statemachines>
Will Cardano ever have anything more than validators on-chain?
# Will Cardano ever have anything more than validators on-chain?

(Asked by: username_0 on 2021-12-28)

I have been looking into creating a blackjack game on the Cardano Blockchain. I started with learning Haskell, and writing a simple blackjack CLI game. It was heaps of fun and a bit of a learning curve since I have never used functional languages before!

Unfortunately I misunderstood one critical thing about Plutus apps which mean that I could never implement this game in a truely decentralized way. That misunderstanding is that I could run arbitrary code and transform the datum in the on-chain code. This is true on Ethereum but not in Cardano, where the on-chain code can only determine if a transaction is valid.

I can't see any technical reason why a datum transformation couldn't be performed on a single UTXO, apart from performance considerations. So my main questions are:

1. Is there any technical limitation preventing Cardano from implementing this functionality on L1 in the future? Or is it just to prevent L1 from becoming bloated with excessive datum storage and code execution?
2. Will there be a layer 2 that allows this functionality? Is this the idea of IELE?

Appreciate any clarification here!

**Tags:** plutus, smart-contract, statemachines
> **Comments:**
> **username_0**: I should clarify that I need to draw a random card and update the state on-chain for this to be a truely decentralized app. It's true that I could probably setup some oracle off-chain to draw a card and update the game datum but this would be a lot more complex and a lot less decentralized.  
> **username_1**: Even if you had the functionality to change the datum on-chain, you would not be able to draw a random card. On-chain code is deterministic. Randomness can never be achieved, therefore. This is also true in Ethereum where you couldn‘t implement this as well. You can ask yourself, how would any node be able to verify that the card was really drawn randomly by another node of the network ? It is simply impossible: randomness cannot be proven and is therefore not implementable on-chain.  
> **username_2**: @Jey At least not until we have verifiable random oracles on chain  

---

## 2 answers

### Answer by username_2 on 2022-09-24. Score: 1

You're right, data transformations can be performed on UTXO's, and, to your first point, any app that requires rapid and/or complex data transformation produces too much bloat, as each transformation would produce at least one new UTXO.

Lil' Cardano Design Philosophy Review:

The "main-chain" (a.k.a., The CSL, Cardano L1, e.t.c.) is best suited for the *settlement* of data and logic, while a diverse ecosystem of "side-chains" (a.k.a. CCLs, Cardano L2s, e.t.c.) are best suited for *execution* of said data and logic. The extent of this bifurcation can be decided upon by the developer(s), and will vary widely depending on the security and throughput requirements of the dApp. Ultimately, it will be up to the dApp developer(s) to decide on a particular structure that makes sense.

In a PvP game like poker, settling and executing every move on main-chain can be done, but it would be slow, expensive, and uninspiring.
Instead, players/clients can commit their UTXOs as inputs-to-be-operated-on to a [Hydra Head](https://hydra.family/head-protocol/). Head operators can engage in data transformation that is only limited by their own network throughput, while periodically committing snapshots back to the mainchain for dispute resolution.

(FYI: maintaining high composability while bifurcating settlement and execution of logic is the essence of Cardano's ability to scale limitlessly)


---

### Answer by username_1 on 2021-12-28. Score: 0

Having a validator script with the ability to change the datum would not increase the power of Cardano's smart contract model. The reason is that, in the current model, validators can only use (as inputs to their logic) data that the transaction provides. The validator cannot run anything that the submitter of the transaction cannot also run. It makes, therefore, no difference if the datum is computed on- or off-chain.

The real reason you have the impression that the Ethereum model is more powerful is that, on the Ethereum blockchain, a smart contract can use the whole blockchain at execution time as input for its computation. This also means that the submitter of the transaction cannot know for sure the result of the smart contract execution as the blockchain could have changed between the moments of submitting and executing the transaction.

The biggest difference I see between Ethereum's and Cardano's smart contract models is that on Cardano it is more difficult to implement some uniqueness constraints in a decentralised way. For example, a minting policy cannot make sure that a token name is unique if the token name space is too large to fit into a script datum. A trusted party is necessary to enforce this uniqueness.

Apart from this, a random number generator is impossible on-chain and no existing blockchain implements one. Randomness always needs to be pushed to the chain from the outside world. This can be done by the means of oracles or by signed random numbers of a trusted off-chain source.

> **Comments:**
> **username_0**: I'm not sure if you understand the question. I completely understand what UTXO is and no way calling Ethereum superior! But Cardano validators as they stand can only classify a transaction as valid or not. They still have access to the datum of the input UTXO/s to determine validity, but they cannot run code to set the outputs or datum of transactions that try to consume that UTXO. I don't see how not having access to the global blockchain state would be an issue here, hence my question.  
> **username_0**: Also there are a few ways of getting random numbers on-chain, it's not impossible.  
> **username_1**: I understood your question. Maybe you did not understand my reply. Also, I did not imply that you think Ethereum is superior. “Powerful” is meant in the programming sense.  
> **username_1**: Maybe it is not clear to you that the validator script really has access to nothing except the inputs; not even to the slot number. It is purely functional.  
> **username_0**: I could be wrong but the inputs include the datum hash (of the consumed UTXO), along with the datum and redeemer provided by the user input. So the validator script does have access to these things, but only for the specific UTXO being consumed by the transaction, not other UTXOs at the contract address. I believe that you can also validate based on the outputs of the provided transaction. So I don't see how it would be impossible to have a more advanced validator on-chain that takes a transaction and performs transformations on the outputs. That's what I'm trying to answer here.  
> **username_0**: In a purely theoretical sense! I don't expect it to happen anytime soon. Also isn't it the stake pool server that runs the on chain code? And all other nodes just validate that the SP produced a valid block? I didn't think all the nodes would have to run the validator script because they are validating blocks rather than individual transactions included in a block?  
> **username_1**: I don't know how else to explain. You already got the fundamental concept but you draw the wrong conclusions. Maybe you should try to write a validator that "performs transformations" to see that it does not make any difference. The reason being, as I said, that the validator can only act upon inputs that are completely determined by the actor constructing the transaction.  
> **username_0**: But the inputs are a UTXO right? So (transaction signing aside) it wouldn't be impossible to have a validator that transforms the output datum and enforces that the output goes back to the script address? I'm just trying to understand if it would be at all possible to append an on-chain calculated datum in a UTXO ledger, in the way that Ethereum is able to modify the global state using an account model. At the moment all a validator does is return a boolean indicating a valid transaction. But what if it returns a boolean, plus the updated datum to use if a transaction is valid?  
> **username_0**: So in a chain of transactions, the last transaction (UTXO) always holds the most updated datum which is used in subsequent transactions.  
> **username_0**: Also I'm really looking for a deeper understanding of some of the technical limitations here. You keep repeating that it's not possible at the moment, which I'm already aware of. My question is really related to it's theoretical possibility and the technical considerations that lead to creating smart validators rather than a full-blown state machine.  
> **username_1**: No, by inputs I meant the whole transaction. This transaction already includes the updated datums. So in a way, the model does already what you are describing. There is no need to have the validator return anything else than a boolean.  
> **username_0**: But the datums aren't updated by the on-chain script, they are completely arbitrary. Any user can provide any datum. There may be a way to validate the datum against the datum hash of the previous UTXO, but there's no way to transform that datum using the on-chain script. So I disagree that what I am asking is possible with the current state of Plutus scripts. But I do agree that this is the deterministic design of the current system. I think some use cases (like multi-round games i.e. blackjack) could benefit from non-deterministic datum output.  
> **username_1**: By your comments, I guess that you are misunderstanding something but I don’t know what. First, true randomness (needed for your game) is different from non-determinism for the triggerer of the tx. Second, having the script compile the datum makes only a difference in a non-determinististic model. In short: for your game, non-deterministic script execution is neither necessary nor sufficient. What you need is a trustworthy oracle.  
> **username_0**: Oh man I'm more confused by every response. I'm not talking about randomness here. The limitation I'm trying to address is that in Plutus, a whole transaction is submitted, including the new datum. The the on-chain code is only verifying transaction validity. There is no ability to transform and output a new datum on chain. That's what I'm talking about when I'm talking about a non deterministic script - a script that generates the output datum for the submitted transaction.  
> **username_1**: Ok, give me one more chance in my most simple words: On Cardano, the player knows if he won before he posted the transaction (because deterministic). This will almost certainly never change. And because of this, shifting the compilation of  the final datum from off-chain to on-chain doesn't solve anything.  
> **username_1**: Did the last comment help ?  

---

