ICRC-3 Draft v2 and Next Steps

Developers
64

Blah…found one implementation detail.

In the past, I could dedupe on the tx part of the Value map. Now that the type is moving out of the TX it isn’t as easy. Of course, I can inject it…or in the case of icrc1 and icrc2 put both the type and the op in the block.

65

Shouldn’t this be 2approve?

66

Would there be anything precluding us from putting both the type at the top and op in the tx?

67

I’ve received a lot of feedback during the weekend (thanks!). I’m going to discard the motion proposal I was writing and make some adjustments to the ICRC-3 draft based on that feedback. SpecificallyL

  1. fix typos
  2. Change the name of the field type to something that is not a keyword in most languages, e.g. btype (we have phash so…)
  3. Explain what happens if both btype and tx.op are defined (btype has priority)
  4. Explain what the endpoint icrc2_supported_block_types returns in the default (ICRC-1 and ICRC-2) case when the Ledger doesn’t support btype yet. There are two options: a) the Ledger returns nothing or b) the Ledger returns 1burn, 1mint, 2xfer and 2approve even if the btypes are not set yet in the blocks. I think b) is better because it allows to compose the default behavior with other standards.

Stay tuned :slight_smile: .

2 Likes
68

Hey Austin, can you please share when and where you would be having these conversations? Would love to be part of it.

69

Yes…I will announce it on the forum…likely we’ll do a new WG focused around these ideas.

1 Like
70

I’ve pushed a new version of the draft and replaced type with btype. You can find the preview here. Once again I’ll wait a couple of days for comments.

71

If both are specified then tx.op should be ignored and btype should be used.

Can we be specific about what ‘ignored’ here means? Is it ignored when calculating the hash? Or just when calculating the state of a canister from Genesis?

I’d prefer letting it be included in the hash calc if present as including it makes deduplication much easier and removing it when calculating hashes would likely be an expensive operation.

72

I changed it to say that if both are set then btype defines the type of the block. Both should still be used for the hash.

1 Like
73
  1. the btype field MUST be
  2. "2xfer" if the Ledger supports ICRC-2
  3. "1xfer" if the Ledger doesn’t support ICRC-2

Hmmm…this is confusing to me. And a bit complex from a library perspective. Ideally, an ICRC1 library should exist without having to have any information about what ICRC2 is. The ICRC2 library is like an add-on.

Is there any reason why icrc1_transfer can’t use 1xfer and icrc2_transfer_from use 2xfer? Theoretically, we shouldn’t have a 1xfer with a spender right?

Should they be defined as different blocks with separate schemas?

If my ICRC1 library has to know if it is in ICRC2 mode it kind of creates a circular dependency.

1 Like
74

I was thinking the same thing. One btype for each method. icrc1_transfer: 1xfer, icrc2_transfer_from: 2xfer.

75

Good point, I’ll change the draft. By the way, today’s working group is going to be again about ICRC-3 and the latest updates. If you are interested in the standard then join us!

76

@skilesare @kayicp I’ve made the change. The spec now reads:

  1. the btype field MUST be
    1. "2xfer" for icrc2_transfer_from blocks
    2. "1xfer" for icrc1_transfer blocks

I’ve decided to keep one section for both blocks because they contain the same fields minus the spender.

2 Likes
77

I got no more comments. I’ll let the draft up for a couple more days and then I’ll make the NNS motion proposal.

78

Hi, the motion proposal for ICRC-3 is live and to be voted by the NNS. Thanks everyone who helped with the standard.

7 Likes
79

Marvelous ! Congratulations to you all for this hard and patient work !

2 Likes
80

Rosetta is dependant on ICRC 3 right? How long until rosetta? Got an update?

81

Rosetta is not dependent on ICRC-3 and it’s using the interface for fetching blocks that the existing canisters provide (get_blocks to be specific). This allowed us to develop Rosetta without having to wait for the standard to be voted.

Rosetta is currently feature complete and we just did the security review. The team is now addressing the findings and then we can release it.

The plan is to eventually move Rosetta to use ICRC-3 to fetch the blocks but that doesn’t block the release of Rosetta.

3 Likes
82

Awesome, hope this gets adopted!

3 Likes
83

Does anyone have any thoughts on how one should write a motoko float into an ICRC3 transaction log?

Is there a quick and dirty function to get the components of a float so it can all be put back together again? If so we can do a map of those components.

The options I’m seeing are outputting text with #exact, but I’m not sure how to put the bbs back in the box with that.

Can we not get the sign, exp, and Mantissa exposed to motoko? Can Prim do it?