Is that any ICRC4 batch code exist. I saw this but dont see it implemented on dfinity ledger code
Summarise it in a paragraph, and weāll go from there.
Nobody wants to read all this.
There is a TLDR at the top for just this purpose. Those two paragraphs are the main point. Iām happy to answer questions if you want something in between three tweets and the full specification. The topic came up out of band or Iād have a better primer.
80 is compatible with 1+2 in that no actual change has to be made to wallets for it to āworkā. The backend change is that the subaccount becomes the token ID and you canāt co-mingle across subaccounts. Ie, if Principal X sends tokens at subaccount Y to Principal Z at subaccount J, the canister should trap. So in this sense, wallets may initially be confusing, but you shouldnāt be able to lose funds through accident.
You do lose subaccounts in ICRC-80, but I think that is ok in this sense, given that canisters can still transact with source canisters and the advantages of them working over ICRC-1/2 give speed to uptake.
Even shorter: Multi-token canister using existing icrc-1/2 infrastructure. Accommodates Fungies and NFTs.
The rest is just details(important to define, but in the weeds).
I intend on doing everything with canister-wallets which need all subaccounts. How about using the memo instead. If we want a Rune like protocol - that works great with the current ledgers. You send a normal transfer, memo is like OP_RETURN and contains [ledger_id, amount]. That allows you to have unlimited amount of meme coin .fun ledgers, print them in kilos if you want. They will not be reverse gas tho, which is actually better.
Iād argue that rune-like protocol is to be avoided at all costs. It is a solution that exists because of an accident of implementation(ie Bitcoin sucks as an information systemā¦good at other things).
But, yesā¦memo is a possibility, but often used to store other important information.
Speaking of accidents of implementation, Iāll point out this is yet another reason to have Derived Canister IDs
Derived canister principals - there is one problem with that compared to canister+subaccount. The canister will have to register the user before the user sends tokens to it and give it a principal, which makes it not DoS resistant.
I think that depends on the derivation scheme.
In theory each canister already has a schemeā¦just use the sub-account as the derivation mechanismā¦if you have an existing deterministic mechanism for sub accounts then it works same/same. Principal X = d(CanisterID + subaccount)
You will have to be able to convert it back for that to work. principal => canister + id. I donāt think that will be possible.
Hmmmā¦
What are you trying to do? Why do you need to reverse it without knowing who wants it reversed?
If the user knowās their principle and the canister and can calculate it, and the canister know the user later when the user asks to do something it can derive it from its own canister Id and the calling principal.
If you really need a reversible one then use a new flag and call these derived. Do we need more than 64 bits of canisters? So that is 4 byte and that gives us up to 25 byte of sub-accounts? If you maintain the original bytes of the canister principal then messages are even still routable.
For non-reversible(and thus I guess non-routable) it seems there is already a spec: https://internetcomputer.org/docs/references/ic-interface-spec#id-classes
The scenario which protects your canister against DoS is:
you send a tx to a canister subaccount, the canister already knows it received it by reading the log, users donāt need to call anything.
Not DoS resistant:
you send a tx to an account which the canister canāt reverse to canister+id. This means the user needs to call the canister and let it know it received something, or for the user to call the canister and register itself before sending tokens.
The only way to protect that is to depend on something else like proof of humanity, captchas, etc.
Before I catch up with ICRC-80 pros and cons discussion above - I just recorded a small demo of multi-token ledger canister with multiple tokens - performing basic ops. Of course its not production ready - but it will get there, eventually
3 Likes
Itās gonna be ICRC-151
First product built on top of it - coming out in next few days.
Iāll make the initial Rust implementation public from mid-October tho.
3 Likes
Some questions/comments I have:
Why is the Token identifier a principal? Why is it not, for example, merely the nonce itself, ie. token are numbered 1,2,3,ā¦?
You should consider allowing the transfer fee to be paid in some fee token, instead of in the transferred token. At least as an option, not mandatory. This is possible in a multi-token ledger but is not possible in a single-token ledger and we should take advantage of it. The advantages is convenience for people who have a round amount and want to send and keep the round amount. I can have and send exactly 1.00 USDT without losing anything on the way.
Spam protection, as already mentioned, is very hard or impossible. So definitely transaction history has to be shipped off to a different archive canister to store. In the future, when available, to Blob storage.
For spam protection the fee token can help because charging fee in a token that is known to have some value is better than charging fee in the transferred token itself. Because a spammer can just create his own worthless token and then spam by transferring that token and paying fee in the worthless token itself.
Mints and burn should be part of the atomic multi-token transfers. For example, there will be minters who issue new tokens in exchange for receiving other tokens. So there has to be a method to allow one to draw from an allowance one token and atomically issue a different token. Same for burning one token and sending another at the same time.
We have learned over time that the query interface of ICRC-1 isnāt sufficient. In practice, it is often needed to atomically query multiple balances at the same time. That can be for multiple accounts of the same token or for different tokens. Because it is such a recurring problem not only for ledgers I recommend that all query interfaces basically have a single query(..)function for the entire canister. It takes a record specifying everything the caller wants. For example the record can have a field balance and the value is a vec of Accounts. The return value is a record that contains everything the caller wanted to know.
2 Likes
I also proposed this to him already. personally I think Cycles would be great to have predictable and fixed costs for specific operations (assuming we donāt want to introduce dynamic fees).
thanks for the reminder on this one. @bogwar do you have this noted somewhere? is it worth discussing a standard to deal with this so that clients know how to interpret the generic query function?
1 Like
Thatās an interesting idea. Iām curious though what is the advantage of having a generic query function? One would need to standardise its payloads/replies so is this different than having distinct endpoints?
Why is the Token identifier a principal? Why is it not, for example, merely the nonce itself, ie. token are numbered 1,2,3,ā¦?
I agree ā using principals here seems like an overkill. I suspect this comes from the architecture alluded in a later comment where one can add a āfront-endā canister to a token (which implements the standard ICRC-1/2) and this convention would help map the token name to canisters. But for architectures where one does not want this additional complication it would be a hindrance.
You should consider allowing the transfer fee to be paid in some fee token, instead of in the transferred token. At least as an option, not mandatory. This is possible in a multi-token ledger but is not possible in a single-token ledger and we should take advantage of it. The advantages is convenience for people who have a round amount and want to send and keep the round amount. I can have and send exactly 1.00 USDT without losing anything on the way.
+1
Implementation: GitHub - xfusion-dev/icrc-151
Docs: Multi-Token Ledger Standard | XFusion Docs
2 Likes