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

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?

Will there be a layer 2 that allows this functionality? Is this the idea of IELE?


Appreciate any clarification here!

user4302: 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. 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)

2776: <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>
 4302: <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>
