I noticed that in the current implementation of the ledger rules all transactions outputs must at least contain a certain amount of ada (see https://hydra.iohk.io/build/6433467/download/1/ledger-spec.pdf, tho the current implementation changed this abit with the alonzo HFC). This means that all interactions with smart contracts must result in some ada at the address of the smart contact. This unintentionally results in the fact that ada is deflationary, this because most on-chain plutus scripts do not include the withdraw of this stacking of ada. As an example look at the contract address of naming the lobster (Address addr1w8433zk2shufk42hn4x7zznjjuqwwyfmxffcjszw5l2ulesdt3jff - Cardanoscan). Here these is 2034438 lovelace locked with the main UTXO of the contract (that is consumed by voting). Also there is another problem (this is smaller). People can send ada to the contract with no datum, and thus making them (assuming the smart contact needs a specific datum to unlock) unlockable for ever. Now of course as time progresses people be aware to not send ada in such a way, but still, this “burns” the supply. At the same address of the lobster naming there is now 39768137 lovelace (39 ada) stuck with no datum!
Wouldn’t it be good practise to include in the validator script that UTXO’s at the script address without a datum are 1) claimable by the address that put it there or 2) claimable by anyone (that is the script succeeds if datum is empty. The implementation of both options is not hard and resolves the latter problem. That said, not all scripts benefit from such an addition.
Yes, such UTxOs are forever locked at the address. Unfortunately the validator script cannot specify what to do with such UTxOs because there is no datum that hashes to nothing, which means that a transaction trying to spend such a UTxO will fail Phase 1 validation and not even progress to Phase 2 validation where the validator is run. (I hadn’t realized that folks have been sending datumless transactions to the lobster address—thanks for pointing this out.)
Actually, I think that nearly every well-constructed script will allow for withdrawal under the proper circumstances (i.e., with the correct redeemer).
After reading the alonzo specification, this was my conclusion as well. I would like to see a change in this implementation, it should be possible to validate without the need of a datum right? Take for example the famous AlwaysSucceds.plutus script in the Alonzo-testnet repository (https://github.com/input-output-hk/Alonzo-testnet/tree/main/resources/plutus-sources/plutus-alwayssucceeds). This validates true independent of the choice of datum, redeemer or context. Still one has to provide these tree scripts to a transaction to even validate. Currently there is an UTXO sitting at the address of this script on mainnet with no datum, and thus unclaimable. This while the script associated with the address will validate true if the datum in the transaction could be void. Almost every script I interact with has such an unclaimable UTXO which is sad and unnecessary. I think we can do better.
How do we propose such a change? Is it trough a CIP? Or a git proposal? What is the best way? I am quite new to the community and still learning the ways. What I have done previously and will do again is to write this up and send a IOHK ticket via the zendesk. Hopefully this helps.
I think that this would be a major change for the ledger spec, and it could have undesirable side effects.
However, wallets and cardano-cli could detect and warn (or prevent) users from sending datumless output to a script address. For instance, if you parse the address of one of the lobster contracts, you can see that it is a script:
The issue here is that it is safe to send datumless output to a simple script (version 1 or 2), but not to a Plutus script. The wallet would need to do extra work to make that distinction, and it wouldn’t necessarily have sufficient information to do that: but at least it could warn.
I see, thanks for the fruitful discussion on the topic. I learned a lot! I wonder what those side effects will be and why this implementation is chosen. Last question, what is that mantra command you are using to parse the address? I have never seen it, is it something you wrote yourself?
@bwbush good god man, why have you not joined the Cardano foundation yet? Every time I try to help you have a better exemplary response. Retirement is overrated btw
I think I have an addition question that is in line with the above discussion. In lecture 2 of the plutus pioneer youtube video there was a validator script that always succeeds. Now in the implementation of the endpoints and more explicit in the construction of the take endpoint the function just takes an arbitrary hard coded datum (I 42 that is of type Data) and sends that with the transaction. What I dont get is how this is allowed since the cardano-cli does not allow a transaction to have another datum then the UTXO that is consuming? If it is possible to make such transaction using such endpoint an implementation of claiming UTXO’s with no datum can be scripted, so this is interesting
The “always succeeds” Plutus script always passes phase 2 validation (executing the validator). In order to pass phase 1 validation (making sure the transaction conforms to the ledger rules), it needs to receive the datum that does indeed hash to the datum hash of the eUTxO that is being consumed.
That sounds logical, thank you for the clear representation of the situation. I forgot that the two phases work together for validation and prohibit the always succeed app as a whole to “always succeed”. I just considered only the plutus code and forgot about the other network rules! Much appreciated, this helps my understanding of the process at hand. So the off chain code of that plutus app is not so usefull since the take endpoint will only validate if there was a utxo with the exact hardcoded datum That had me confused.
Thank you for contacting the IOHK Technical Service Desk.
I am so sorry to reply to you so late.
First of all, thank you very much for your suggestion.
It’s true that UTxO’s at a script address without datum are not claimable. So either such transactions should be invalid to begin with, or it should be possible for everyone to claim them.
I passed your message to the Plutus team to improve.
That had me confused.