waalge
/
kompact-io-landing
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

edit cip-118 commentary

This commit is contained in:
waalge 2025-07-29 08:59:29 +00:00
parent 550f4a1c7f
commit 7e2aca1277
1 changed files with 17 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
content/posts/cip-118.md
View File

@ -188,23 +188,29 @@ much easier and cheaper mechanism for broadcasting state in this sense. The
transaction referencing the input pays in fees and bytes only a fraction of what transaction referencing the input pays in fees and bytes only a fraction of what
it would otherwise cost, particularly with CIP 32. it would otherwise cost, particularly with CIP 32.
CIP 32 purports to address the inconvenience caused by the former design's CIP 32 purports to address an inconvenience caused by the former design's
support only of datum hashes at tip. Quote: "This is also inconvenient for the support only of datum hashes at tip. Quote: "This is also inconvenient for the
spending party, who must watch the whole chain to spot it.". Were it not for CIP spending party, who must watch the whole chain to spot it".
31, then I would find this argument incredibly weak. Without CIP 31 but with CIP I find this argument incredibly weak. To create a transaction, a user already
32, this is simply a tooling issue. To create a transaction, a user already
needs access to the chain via functions `getUtxosAtTip` and `submitTx`. Having needs access to the chain via functions `getUtxosAtTip` and `submitTx`. Having
another `getDatumByHash` is not a big deal. With CIP 31 but without CIP 32, the another `getDatumByHash` is not a big deal - it is just a tooling issue.
referencing transaction would also need to include the datum as part of the A more compelling case is that it reduces the size of transactions.
redeemer which would then be hashed, and then matched with that of the Prior to the change and in normal application an output datum hash
referenced inputs datum hash. With both CIP 31 and 32, a referencing transaction would need to be validated,
does not pay in fees nor bytes for the inclusion of the datum, and the and so the datum would be present in the witness set, adding to the
additional logic is avoided. transaction size.
The consuming transaction would then need to include the same data.
There are some contexts where this can be improved upon,
but CIP 32 essentially halves this problem by paying for the data just once.
The impact of CIP 32 is compounded when used with CIP 31.
With both CIP 31 and 32, any referencing transaction
does not pay in fees nor bytes for the inclusion of the datum.
CIP 33 allowed scripts to be referenced, rather than having to be included in CIP 33 allowed scripts to be referenced, rather than having to be included in
the transaction. As mentioned, scripts can easily exhaust most if not all the the transaction. As mentioned, scripts can easily exhaust most if not all the
transaction size limit. Referencing scripts dramatically reduces the size of transaction size limit. Referencing scripts dramatically reduces the size of
script heavy transactions. script heavy transactions. Generally speaking, of the three CIPs, this was the
most significant.
The ledger changes in Vasil were a small perturbation of what had come before. The ledger changes in Vasil were a small perturbation of what had come before.
CIPs 32 and 33 did not introduce new functionality in and of themselves. They CIPs 32 and 33 did not introduce new functionality in and of themselves. They