Ledger & Tokenization Working Group Update

Developers
#16

Yes, but on which level? You mean (principal) is a subtype of (principal, opt blob)? So we don’t even have to write “null” anywhere?

#17

Ok, I think I see your point. You propose that we make the form (principal, blob) as a canonical form so blob always has to be specified in the Ledger interface, but the ledger and the client libraries can take liberties in how they store the “default” value?

I see the null case as a space and usability optimization for the most common case. We can live without it, but it’s a bit hard to go back and change ICRC-1 to make subaccounts required.

#18

Can we just live with the disambiguity of the default account and with not having some natural properties for this special case?

#19

I don’t see any serious issues with that, I’ll update the spec to require unique textual representation.

#20

Alternatively, I think it also acceptable to tell the users that all zeros isn’t a valid subaccount. They can either use the default account or they can specify a non-zero subaccount. It makes sense and the worry that a function isn’t total seems minor. What the internal representation does with that is up to the developer. They can represent the default by all-zeros or in some other way. That is not visible to the user. But the encode and decode functions have to throw an error if you feed in what would result in an all-zero subaccount.

1 Like
#21

I’ve updated the spec; valid textual representations are unique now. I’ve also sketched a reference implementation in Motoko.

Using the principals' textual encoding for other things than principals
#22

Could we make the special trailing byte 0x7f instead of 0xff?

In case the use of principals proliferates and more values of that byte get a meaning assigned to them then we don’t close off the option to expand the space via leb encoding of those values.

#23

Dear community!

The next meeting of the Ledger & Tokenization Working Group is scheduled for tomorrow, September 20. Please note that it has been scheduled an hour earlier than the usual time slot due to various overlaps.

There are two topics on the agenda of tomorrow’s Working group meeting, as agreed in the most recent meeting:

We are looking forward to the discussions on those important aspects of the token standard!

#24

Hi all, I want to raise an important security related issue, that the working group could include on the agenda for this week or for the next session.

Can we have a fixed size representation for the internal tokens. At the moment, I can see from the official reference implementation that:

public type Tokens = Nat;

rather than:

public type Tokens = Nat64;

I believe this could lead to memory errors or attack vectors where attackers try to consume all the memory of a canister.

The benefit of this using a wrapper over using u64/nat64 directly is that we can define the behaviour for arithmetical overflow: in particular we can return an option rather than a panic on overflow. Other operations can also be defined. So, the internal use of the Tokens struct in the ledger made total sense from a safety perspective - we shouldn’t get rid of this imo. We can, however, make this more ergonomic by serialising from Nat.

Not sure how we would do all this in Motoko, but perhaps with a new type?

3 Likes
#25

Hi @Maxfinity!
I don’t think there is an attack vector. To create a transaction with a huge amount, you need to own this amount first. So if the ledger author knows that there are no more than 2^64 tokens, the author is free to use u64/Nat64 internally.

For example, here is how the DFINITY implementation of the ICRC-1 ledger works: main.rs - dfinity/ic - Sourcegraph. All the externally visible balances are Nats, but internally all balances are u64. If the amount in the transfer arg doesn’t fit into u64, we report an InsufficientFunds error.

#26

Dear Working Group!

The next meeting of the Ledger & Tokenization Working Group is scheduled for October 4. We propose to have the items agreed upon last time and one additional item requested by the community on the agenda for this meeting:

  • Working Group governance
  • ICRC-2 proposal by Psychedelic (ICRC-2)
  • Textual encoding for accounts (ICRC-1#55) (if time)

We are looking forward to the discussions in the upcoming meeting!

#27

Do you mind reposting the zoom link ?

#28

If anybody requires the Zoom link for the working group meeting, please send it to @nikhil.ranjan or @dieter.sommer via a private forum message so that we can add you to the email invitation. We do not want to post the link publicly as we have been experiencing severe Zoom bombing with a public link.

#29

Sometimes useful to look how it’s been done, here’s a thread on “Rough Consensus” circa btc 2015:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html

1 Like
#30

Few notes from me:

From a scalping trade, arbitrage bot, or leverage trader perspective, the best solution is when the trader funds are in an account controlled by the DEX/DeFI canister. This way there is no need to do ledger calls, trading can be done without async calls. The faster they are, the more profit they will make.

From the end user’s perspective - the best solution is to use the Swapper pattern which I have published in forums (it lacks slippage, but that can be added). End-users make a few transfers a month and just want them to be successful. This pattern guarantees the user will get what they agreed for and no developer errors or malicious behavior can result in fund loss.

So we have 3 ways of doing it. fast(risk) - medium(risk) - slow (guaranteed). I am not sure the medium one (approve flow) is worth it since the other two will beat it at everything.

Both Swapper and the fastest approach can be done with the core we have right now.

To be more specific: I think approve in Ethereum was invented to make the fastest exchange with slippage possible. In IC the fastest exchange with slippage is just preloading an account = (dex_canister_principal, caller) and then trading (buying + selling) with a single call (or placing orders which get triggered). Once a trader is done, they withdraw funds. Now that Stable Memory got increased, there will be no need for a DEX to be multi-canister to be able to hold trader’s accounts.
I think we shouldn’t blindly copy Ethereum, instead work towards the most optimal solution.

Even if approve flow gets approved, DEXes which do what’s mentioned above will be better for traders and will make DEXes using approve obsolete. On the other hand, DEXes using swapping will be more secure so end users will prefer them.

Additionally, you can’t have loans or leverage with approve flow. You will need to lock the funds inside the DeFI contract. The reason swaps in Ethereum don’t work like Compound loans is the gas fee, which in IC is not a problem.

This means multi or single-canister ledgers :+1:
Single canister DeFi :+1:

And because a single canister DeFi at some point won’t have the throughput, there will be many such and arbitrage synchronizing them. An arbitrage bot won’t open an account in one DeFi canister, it will open accounts in all of them.

This is pretty far-fetched. I would like it if someone proves me wrong.

1 Like
#31

Where can we find the info presented and proposed in yesterday’s working group?

#32

I put notes and links to slides in the Charters.md file in the ICRC-1 repo:

Feel free to open a PR against this file if I misrepresented something or missed something important.

1 Like
#33

Dear community!

The next meeting of the Ledger & Tokenization Working Group is scheduled for tomorrow, October 18, 2022.

We propose to discuss the following items in tomorrow’s meeting:

  • Working Group governance
    • Continuing the discussion from where we left off
  • ICRC-2 proposal by Psychedelic (ICRC-2)
    • Asking the WG once more for feedback on the most recent version of the proposal (Note: The agreed-upon PR from the most recent meeting is still outstanding)
  • Transaction log API (ICRC-3)
    • First overview of the proposal

We are looking forward to the discussions!

1 Like
#34

Hi Dieter, how can I take part tomorrow?

Thanks :slight_smile:

#35

Hi @Embark
Just saw this after the fact. If you want to take part in the future WG meetings, just send a private message with your email address to me. Then you will receive a Zoom invitation by mail.