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

lint

This commit is contained in:
waalge 2025-07-29 08:59:56 +00:00
parent 7e2aca1277
commit a4f145894f
2 changed files with 961 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

942
assets/css/mini.css
View File

File diff suppressed because one or more lines are too long

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

@ -6,14 +6,13 @@ date: 2025-07-21
## Abstract
CIP 118 fails to demonstrate sufficient need for the ledger changes it proposes.
The use cases CIP 118 cites can already be supported.
No evidence is provided that the specific contexts which cannot be supported are critical,
nor is there an attempt to quantify the claimed performance improvements.
Accepting CIP 118 will not only add to ledger complexity,
it is an open invitation for a series of subsequent ledger changes,
both tweaks and fixes of missteps, and as more of the inexhaustible list of intents
gets shoe horned in.
Efforts and energies would be much better spent making accessible and utilizing what we already have.
The use cases CIP 118 cites can already be supported. No evidence is provided
that the specific contexts which cannot be supported are critical, nor is there
an attempt to quantify the claimed performance improvements. Accepting CIP 118
will not only add to ledger complexity, it is an open invitation for a series of
subsequent ledger changes, both tweaks and fixes of missteps, and as more of the
inexhaustible list of intents gets shoe horned in. Efforts and energies would be
much better spent making accessible and utilizing what we already have.
## Context
@ -190,21 +189,18 @@ it would otherwise cost, particularly with CIP 32.
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
spending party, who must watch the whole chain to spot it".
I find this argument incredibly weak. To create a transaction, a user already
needs access to the chain via functions `getUtxosAtTip` and `submitTx`. Having
another `getDatumByHash` is not a big deal - it is just a tooling issue.
A more compelling case is that it reduces the size of transactions.
Prior to the change and in normal application an output datum hash
would need to be validated,
and so the datum would be present in the witness set, adding to the
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.
spending party, who must watch the whole chain to spot it". I find this argument
incredibly weak. To create a transaction, a user already needs access to the
chain via functions `getUtxosAtTip` and `submitTx`. Having another
`getDatumByHash` is not a big deal - it is just a tooling issue. A more
compelling case is that it reduces the size of transactions. Prior to the change
and in normal application an output datum hash would need to be validated, and
so the datum would be present in the witness set, adding to the 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
the transaction. As mentioned, scripts can easily exhaust most if not all the