CIP-0113? | Programmable token-like assets#444
CIP-0113? | Programmable token-like assets#444michele-nuzzi wants to merge 88 commits intocardano-foundation:masterfrom
Conversation
|
Please note that at this moment this is only a draft and may contain errors in the logic. If you spot any or have suggestions on how to improve the logic contributions are more than welcome! |
|
Question: |
|
@matiwinnetou How it works on EVM compatible chains is that the wallet stores locally a list of common tokens / users can manually add token addresses to track. Try installing Metamask and interacting with milkomeda.muesliswap.com |
|
@matiwinnetou the solution proposed emulates the way tokens are used on EVM chains in many aspects As @nielstron said the user of a wallet needs to manually add the contract to track Wallets can find the user balance by the NFT associated with the payment credentials. |
|
I see, thanks, this helps a lot. So I guess it would be of course also possible to have some registry for those tokens so wallets could use it. |
rphair
changed the title
|
thanks @michele-nuzzi - I just edited title to be specific & put the Draft status into the review stage itself; feel free to change back when you feel the drafting process is complete: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request Also I'm adding a link to the readable proposal into the original comment & please keep updated if it changes path 🙏 |
L-as
left a comment
L-as
left a comment
There was a problem hiding this comment.
As I've noted elsewhere, a system as described in this CIP is inherently centralised (but trustless) and thus can't support the throughput it would on account-model based ledgers.
A much simpler system which likely serves your needs is a system where the owner is noted in the token name of a token. Let's assume it's a PKH for simplicity, but in the future we want scripts + datums as owners too.
You then only own a token if you 1) actually hold it and 2) the token name includes your PKH. The token name can also contain extra information through hashing the PHK along with token-specific information. If necessary, a UTXO can be created to ensure the preimage is stored on Cardano itself. Then sending a token to someone would entail burning then minting it again. In this process, arbitrary checks can be done through the minting policy.
Implement royalties is trivial, and would be done by including the author name in the token name too.
Implementing freezing for USD stablecoins would include checking a centralised Merkle tree of frozen addresses and checking that yours is not included.
As for supporting scripts, I think just allowing a script + datum to be used as owner might be enough.
Also, unrelated to the idea itself, I would appreciate it if the CIP was better checked for grammatical/formatting errors/typos, etc.
|
@michaelpj might be interested |
|
@L-as Thank you for helping with the CIP. I like a lot the system you propose but from a first read I believe is missing an equivalent for the Regarding throughput, it is only limited to the phase of the creation of a new account; while I understand it is a bottleneck it is an operation performed only once and it should not cause too many problems. Once an account is created it remembers its own state and multiple accounts can be used in parallel. I recognize my writing is not the best and I'll try to put more effort into it. |
|
@michele-nuzzi That is somewhat true, however, you could implement it by freezing the old tokens (ref inputs) and minting new ones, but this might not be any better than what you describe. How common is There is also the issue of complexity, the scheme described in this CIP is not simple, and also requires more effort from wallet developers to show the information. I'm not sure which scheme is better when taking that into account. |
|
From what I can tell It is true that for this first draft, it might be tricky to implement something like freezing; I was thinking to add a second field to the const AccountManagerDatum = pstruct({
Account: {
amount: int,
state: data
},
/* ... */
});and then make sure that the the account manager can have other redeemers after the standard one so that maybe a Regarding wallet implementation, it shouldn't be any harder than the current resolution of ADAHandles. |
I would say to avoid the ERC-20 approve function at all costs. It has plagued the Ethereum eco-system and even they are standardizing a new key signature method called permit to try to correct this terrible mistake. I'd recommend instead signatories be checked for transferFrom methods instead of the far outdated approve. I have not had the time to fully go through this. But I just want to warn against the mistake of implementing approve. |
|
@MicroProofs If that's the case then there is no difference from the |
|
@michele-nuzzi |
|
With those two removed is there any reason not to go for the token approach? |
|
@L-as There would still be the problem of additional (trusted) data for script execution.
As you said implementing logic like freezing requires some external contract; this external contract would not be a standard, so someone else that wants to move around ERC20-like tokens would (and should) not know of this additional requirement |
|
@michele-nuzzi It would always be the case that transferring tokens can fail. It should not be part of the interface in the first place. For wallets to support it seemlessly, you could have a helper untrusted script associated with the MP that tells you what you need to add to fix it. That would have to be the case even with your system to support arbitrary behaviour and keep the interface simple. |
|
I don't particularly have an opinion here and I'm not currently planning to review this. If this is a thing that people want then they can create it. I think it may not perform well (as @L-as says), and it sacrifices essentially all of the benefits of native tokens on Cardano. A few thoughts:
|
After putting it in Draft stage I've been watching the feedback expecting that it will produce a Rationale and other CIP prerequisites to be added before @michele-nuzzi brings it into the "Ready for review" stage. I'm not recommending anything specifically yet in case a broader approach suggests presentation as a CPS instead. The discussion has been productive so far even without a mature proposal yet. |
|
@michaelpj me and @L-as have had a very productive discussion regarding performances, the only bottle neck is the Merkle tree which is there to guarantee the uniqueness of an account. This constraint is not really useful, there is no harm in having multiple accounts with the same credentials so it will be removed before the final CIP. The implementation will only require the account manager. |
rphair
added
the
State: Waiting for Author
|
Added |
rphair
added
the
State: Last Check
|
Thanks @rphair for the reply. I think this strikes a good compromise for all reviewers and editors. On one side it shows momentum and consolidation, on the other signals maturity and urgency for developers and adopters to get their feedback in. My next few weeks will be all about this along with accompanying the code and the spec through a formal auditing process. One lesson learned for me here and possibly the wider group is that, although I believe all CIPs are important CIPs, some might require additional social amplification, If it's not, it could be worth documenting it in the CIP process docs. This could be totally informal or a simple ☑️ that reads "requires CF/IO/Emurgo to post about this CIP on relevant socials". I will continue to keep an eye on the convo of this CIP and attend CIP meetings in order to ensure questions and feedback are promptly addressed. In the interim my focus will shift on developing and improving tooling required to bring programmable tokens live as well as supporting partners and community teams in adopting the standard. All feedback gathered through this process will be funnelled here. Thanks again everyone for the support and the work put into this. I apologise if I came across strong or a bit rough. Keep up the good work. |
|
GM, The anticipated round of comms have just hit the socials:
I will also host a "CIP 113 Deep Dive" on March 19th here: https://app.addevent.com/calendar/TG807216 Thanks again everyone involved. Have y'all an awesome week 💪 |
|
thanks @nemo83 ... I've read through all the communiqués and the central message seems to be the CF blog article. It conveys the overall message of a "we've done it / finished it" announcement (argued against at the CIP meeting), although the blog does contain these passages such as @colll78 recommended about still looking for feedback before considering complete:
The editorial opinion is that @colll78 at least needs to say that document is final before we merge it. (We would also consider that PoC implementors themselves might be guided directly here with their own suggestions to update the document... which would be welcome as always in the CIP process.)
@nemo83 one thing I would strongly recommend based on many past experiences... especially if Phil doesn't post here saying "go ahead and merge this CIP" (at least as a baseline) before the highly publicised 19 March meeting... Important If this PR is still unmerged, the meeting promotion & content should refer to this as a CIP candidate rather than "CIP-0113" which does not exist until this document is merged. If that sense of finality is falsely conveyed, exactly as @colll78 emphasised at the meeting (backed up by years of CIP editor experience) we'll lose our last best opportunity to get any usable feedback here about the CIP document itself. |
Hi @rphair The tl;dr is: now that as proposers and editors, we believe we have a viable solution to programmable tokens, my current goal is to introduce the programmable token platform and the underlying suggested cip113 standard to as many people, companies and developers as possible, to ensure we have a sound design, a secure architecture and usable tooling. The longer replyI and CF have been working on several aspects of CIP 113. Two in particular are:
In this round of comms we announced the platform and we requested feedback on both the platform itself and the standard. The "we've done it / completed it" is more for the platform rather than the cip113 standard itself:
As you correctly highlighted in several places in the blogpost we invited people to provide feedback. As a result of the announcement, a few people already working on it have interacted with the X post:
No worries, in the March 19th meeting (dev office hours) I will make plenty clear that the standard is still open for review and requires both functional and technical feedback. It's actually the whole purpose of the meeting:
Meeting will also be recorded and shared on youtube to allow further reach Given this wave of community and tech engagement has just taken place, I would expect and hope for feedback, and hopefully validation, in a few days or even a week or two. So on my side, as there wasn't before, there is still currently no urgency in getting this merged. At the same time, as previously mentioned, I would encourage everyone to chime in now that things have stabilised and calmed down a bit so that when the time comes to merge it, there will be no further delays. I get your point about |
The spec for ThirdPartyTransferAct was incorrect. > `input_idxs`: A list of indices (in transaction inputs) pointing to the UTxOs from programmableLogicBase being acted upon Is wrong in two critical ways. `input_idxs` is not a list of indices in the transaction inputs of the UTxOs spent from programmable logic base. It is a list of relative indices of ALL script inputs (not just those from `programmableLogicBase`) with respect to each-other. This of-course means: > Each input at `input_idxs[i]` is paired with an output at `outputs_start_idx + i`. This allows batch processing of multiple UTxOs while maintaining a predictable structure. is also incorrect.
|
There is a critical issue in the spec, which I have submitted a PR to address (@michele-nuzzi review at your convenience). Namely the following is incorrect:
The correct specification is: When using this constructor:
Meaning of
Instead, it encodes an ordered subsequence of
Equivalently, if the selected inputs are at absolute positions
then
Conversely, the absolute positions can be reconstructed as:
In particular, for This encoding allows the validator to traverse Input/Output Pairing Let Then the selected input at
|
Fix incorrect spec of ThirdPartyTransferAct
|
@colll78 it appears that the problem you reported in #444 (comment) has been fixed with the commits that came after it. Would you be in favour of merging this at the CIP meeting tomorrow if there were a general call to do so? |
|
Almost, there are two outstanding changes that are needed:
|
|
Discussion at CIP meeting today covered:
Thanks again to both co-authors for the updates. Editors have again committed to following both co-authors' expertise in determining when this is ready & I've also urged @Ryun1 @perturbing to review the document itself so we can concur that it's ready to merge as soon as all known technical problems are confirmed solved & updated in the CIP text... to consider again to merge from |
GM, I took some time to review the points above and okay for 2 and 3 but I'm unsure about point 1. What's the benefit of this? Would it fix any issues or is it a performance improvement? At this level of optimisation, I believe optimisation is possible but in the thousands of lovelaces, at the cost of a more complex and hence error prone redeemer. Also for point (3), despite the fix, the attack will still unfortunately be possible, but the mitigation is to immediately and correctly mark the "bogus" token as programmable, signalling wallets and offchain infrastructure to prefer not to mix up with other programmable tokens unless strictly necessary (usually in defi protocols). |
The attack (turning a non-programmable token into a programmable one) will be impossible after the fix. The fix would enforce that: The key invariant this vulnerability breaks is that programmable tokens can never exist outside the mini-ledger, the problem is that you can mint a non-programmable token from the issuance policy, and then at your own convenience, register that token as a programmable token and brick any DEX pools / user UTxOs in the mini-ledger with that token. |
Yup I got that and that's a great finding, but if someone manages to sneak a "bogus" programmable token into a utxo with other programmable tokens, he can still freeze the whole utxo and blackmail the user. For sure this is a super important fix. What about the point (1)
EDIT: I also realise writing this on a public forum is not ideal... coz could give ideas... will eventually nuke or amend the post later... |
The main goal of script optimization is not to reduce transaction fees (although that is a meaningful byproduct), it's primarily to increase dApp throughput, and secondarily to expand the range of what features are possible and feasible to implement within dApps. This is critical for any production dApp which expects non-trivial onchain activity, which is why you see protocols like Minswap, SundaeSwap, Liqwid, and others that need to be able to facilitate more than a handful of concurrent users spend so much time and effort on micro-optimization. If a DEX processing contract hits the transaction ex-unit limits with 16 orders then the dApps throughput is less than 1 request / second, and with backlog users can end up waiting close to half an hour for their orders to process. All production dApps fall into one of two categories with respect to how they handle this:
The theoretical throughput limitations for most dApps right now are between 40-50 orders per block, this is around the threshold at which you have enough capacity to support most onchain activity right now and you only really see this threshold exceeded and the subsequent throttling become a UX issue for short bursts during very high interest launches or liquidation events; but for most onchain activity now, the current level of optimization in these dApps is sufficient. The problem is that with programmable tokens they won't be able to achieve anywhere near that level of throughput because a huge percentage of the transaction ex-budget will be consumed by the core mini-ledger contracts, and the individual programmable token transfer logic contracts. For a programmableToken/Ada pool, without even considering the ex-unit costs of the token's transferLogicScript, you hit the ex-unit limit far before processing even 15 swaps in a block. At this point any non-trivial user activity hits this threshold and UX slows to a crawl. Ex-units are already a huge constraint for throughput and feature capabilities of dApps today, this issue becomes even more prominent for dApps on the programmable tokens mini-ledger since a huge portion of the budget is already consumed by the mini-ledger smart contracts which are entirely out of their control. If the ex-unit footprint of the mini-ledger isn't minimized to the absolute limit then programmable token dApps will be forced to gut logic or leave end users to suffer the UX downgrade of request bottlenecks. Also transaction fees aren't the only fees that are impacted by throughput, dApp infrastructure costs are directly correlated to the amount of batches that must be processed, if 60 swap requests can be processed in a single batch, this results in substantially less work (especially with respect to coordination) for batchers than processing three batches of 20 swaps, and this difference can be reflected in the batcher fee. We aren't talking about micro-optimizations; we are talking about an average difference in efficiency of 30-80% across every class of real-world use-cases. |
|
All, I've just addressed the issues raised in previous comments here: cardano-foundation/cip113-programmable-tokens#45. |
|
@colll78 if @nemo83's #444 (comment) fixes the issues you raised in #444 (comment) please post here so we can consider this confirmation at the upcoming meeting. |
|
I added my review to the PR, there's a pending issue namely that issuance is limited to a single asset per policy, this kills a huge category of use-cases, ie. soulbound DIDs and so on which require minting multiple tokens under the same policy id. |
|
GM, Few updates,
Thanks all for the continuous support. |
|
HarmonicLabs#6 Absolutely should not be merged as is. It deviates the interface of the standard to cater to the desires of a specific implementation, to circumvent of a constraint of their specific offchain library (it struggles with indexing), at the expense of huge negative impacts on efficiency and maximum throughput. CIPs should not cater to any specific implementation, they should always prefer the option that is objectively best (via standardized measurable criteria). It is up to individual implementations to cater to the specification of the CIP, not vice-versa. |
|
Sorry, maybe I didn't communicate adequately. The API/Interfaces are modified yes, but simplified to provide better overall user experience, ie. not having to care for indexes. Offchain code/library has nothing to do with this. On top of this, additional benchmarking, has provided useful insights where overall costs are reduced, please check PR description cardano-foundation/cip113-programmable-tokens#46 for more details, but for handiness I'm gonna report the comment here:
|
|
@colll78 @nemo83 since the last round of comments above suggest critical remaining issue(s), as per the previous agreement & public expectations we'll leave this at If I'm reading this wrong, please post here or clarify at the upcoming meeting discussion (in less than 1 hour: https://hackmd.io/@cip-editors/132) and it'll remain at |
|
Meeting resolved that @nemo83 would contact @colll78 by DM to confirm or dismiss the criticality of the latest problem identified: possibly "cosmetic" because of good performance measured in recent benchmarks. Editorial status — waiting for these 2 expert opinions to converge/agree (or at least lack of dispute) before merging — remains unchanged. |
20 participants
Developers wishing to participate: please read & follow the definitive recommendations at #444 (comment) which include:
For lightweight discussions prior to posting, feel free to use the Discord CIP server channel
#cip-113(server invite on this page)This CIP proposes a solution to CPS-0003 (Smart Tokens) implementable already with V2 Plutus contracts.
If adopted as a standard it would allow to emulate the behavior of account-based ledgers tokens on Cardano.
(rendered proposal in branch)