You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is proposed by @SebastienGllmt and elaborated on by @colll78, whom I'm quoting verbatim:
"let's consider that if somebody shows us what exactly it's supposed to improve"
I think Sebastien Guillemot did so quite eloquently with his provided example:
*createFiniteMint() -> Generator<Bool> {
const maxSupply = 10_000;
for (let supply = 0; supply < maxSupply; supply++) {
yield true; // yielding ends this UTXO and creates a new UTXO with the rest of the continuation
}
// here the function ends, which consumed the UTXO forever
}
function* mint10nfts() {
for (let i = 0; i < 10; i++) {
yield mintUtxo // this is the NFT mint script above
}
}
If you look at how the same script is implemented in the original EUTxO paper it's significantly more painful from both an onchain and offchain code perspective (albeit the design of this script in that paper is not what anyone would use in production).
To do this in plutus you would need the following scripts:
Minting Policy for state thread NFT
Spending Policy for the state UTxO
Minting Policy for the capped minting policy (mints up to N tokens).
Which you would then use as:
Mint state thread NFT and put it into output with datum that keeps track of the total minted.
Spend the state UTxO from spending script back to spending script.
a. Check that the remaining canBeMinted amount in the state UTxO's datum is greater than or equal to the amount minted.
b. Check that the output state UTxO datum canBeMinted is equal to the input state amount datum canBeMinted minus the minted amount.
c. Check that the state thread NFT is included in the continuing output.
Clearly there is a lot more boilerplate than the delimited continuations example, but there is a lot of nuance in that boilerplate, and especially for non-trivial examples I fail to see how the checks above can be easily abstracted away without significant sacrifices in efficiency.
To be honest, I'm not sure how the example delimited continuations code would uniquely identify the state UTxO or handle the other required checks that I mentioned above. I assume it would just compile to UPLC that adds the checks for the state NFT (as the Plinth state machine used to), but if that's the case then that is where the hidden complexity of this solution lies, because generating such code efficiently is the biggest challenge of these types of abstractions.
The text was updated successfully, but these errors were encountered:
This is proposed by @SebastienGllmt and elaborated on by @colll78, whom I'm quoting verbatim:
The text was updated successfully, but these errors were encountered: