ICRC-3 Draft v2 and Next Steps

[kayicp]

@levi

nested archives

what do you mean by this?
I thought the usual design was always the “one main ledger with multiple archive canisters”.

[mariop]

Hi,
I got a couple of requests for change for the ICRC-3 standard from outside the working group. This was the feedback I was waiting for before moving on with ICRC-3. The two suggestions are the following:

1. point 2 of the Generic Block Schema section requires ICRC-3 blocks to have a field tx: Map with a field of type op: Text inside. The change request is to drop this requirement in favour of having a field type: Text at top level which defines the type of the block. This type should follow a schema such as <standard_number><field_type> e.g. for ICRC-1 transfer block it would be 1xfer. We should also propose a schema for custom blocks, e.g. prefix the type with c plus a unique code of some sort, so that custom standards could be supported. Note that for this to work <field_type> should never start with a digit. For backward compatibility with existing Ledgers (ck, SNS, …) we should still support the current approach of having tx: Map with the op: Text field inside but mark the new block style with the type at top level as the favored approach.
2. Add a new endpoint icrc3_supported_block_types to list all the supported block types. Given the open nature of ICRC-3 each client will always have to query the supported blocks from the Ledger to understand if they can interpret all the blocks. The original plan was to use the icrc1_supported_standard endpoint from ICRC-1 to query this info. Some people proposed to instead have an endpoint in ICRC-3 so that any Ledger, including the ones not supporting ICRC-1, could use ICRC-3. The endpoint icrc3_supported_block_types is also more fine grained compared to icrc1_supported_standards. Both the name icrc3_supported_block_types and the type returned are yet to be clarified.

We could discuss this tomorrow in the working group but I wanted to write it here first so that everybody can have a look.

What do you think?

[kayicp]

@mariop

<standard_number><field_type>

I’m okay with this, since icrc-7 also is doing the same thing… eg: 7xfer

hopefully icrc-3 will start progressing now.

[mariop]

@kayicp

what do you mean by this?
I thought the usual design was always the “one main ledger with multiple archive canisters”.

ICRC-3 is designed to be used with generic Ledgers and we cannot make assumptions about archives or what not. Therefore ICRC-3 was designed such that any block holder (Ledger, Archive, Index, …) can either have the blocks locally or know who to ask to.

[skilesare]

Regarding 1: I don’t have a strong prejudice except that I don’t want to have to refactor my code I guess it does make sense to have this at the top level.

@mariop

Add a new endpoint icrc3_supported_block_types to list all the supported block types. Given the open nature of ICRC-3 each client will always have to query the supported blocks from the Ledger to understand if they can interpret all the blocks.

I do like this idea. I don’t want to slow down ICRC3 though…could this be a separate ICRC so we can move forward? I’d propose that it also consider something like GitHub - ZhenyaUsenko/motoko-candy-utils so that it can not only reply with a list, but also the schema of those block types. It would really help for indexing canisters.

@mariop

The original plan was to use the icrc1_supported_standard endpoint from ICRC-1 to query this info.

I guess I just always assumed that this would be used across ICRCs. I guess we should have put that endpoint in its own standard. I guess it should have been icrc0_supported_standard. Hmm…I’m not really sure I want each standard to have its own supports infrastructure(although as mentioned, for ICRC3 being able to return schemas would be nice).

We should certainly use the time tomorrow to talk about it!

[Maxfinity]

@mariop

• improved definition of the icrc3_get_tip_certificate endpoint to fetch the certified tip of the chain, i.e. the last block index and the last block hash

Hey Mario, can we get a certified approval? This will help with DOS attacks.

[mariop]

@Maxfinity

Hey Mario, can we get a certified approval? This will help with DOS attacks.

Yes, you can (if you are not a canister):

1. make an approval and get back the approval block index
2. get the tip certificate via icrc3_get_tip_certificate
3. fetch all blocks from the tip in 2. to the block index received in 1 using ICRC-3
4. send all the data received to the service which then can verify the approval using ICRC-3

There are some drawbacks to this solution though. The first one is that the length of the suffix depends on the blocks/s in the Ledgers. If the Ledger creates a lot of block between 1. and 2. then the suffix may be big and eventually too big to be sent to the service.
More importantly, the certificate verification can be quite expensive which so I’m not sure this approach would solve the issue you mentioned. We would have to test it.
The general question is whether sending certified results to a canister is a good approach or not because checking the certification is expensive.

[dieter.sommer]

The ICRC-3 topic will be discussed in the WG meeting this afternoon.

Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group

Dear WG! We have a topic of broad interest for tomorrow’s agenda: ICRC-3 Specifically, the session will be centered around the following issues discussed on the forum already, see the original post and the following discussion for details. @mariop will be presenting and driving the discussion! Hope to see many of you there, I know many people are waiting for ICRC-3 to be finalized and resolving those issues is a key missing piece of the puzzle. See you tomorrow! See the Google Calendar l…

[levi]

@mariop

point 2 of the Generic Block Schema section requires ICRC-3 blocks to have a field tx: Map with a field of type op: Text inside. The change request is to drop this requirement in favour of having a field type: Text at top level which defines the type of the block.

I think this is a great idea, and makes sense for a generic block log. If there is a way to do it and still make it work with existing ledgers that sounds great.

@mariop

Add a new endpoint icrc3_supported_block_types to list all the supported block types. Given the open nature of ICRC-3 each client will always have to query the supported blocks from the Ledger to understand if they can interpret all the blocks.

Since a ledger can upgrade to support more block types, a client that has called icrc3_supported_block_types before the ledger upgraded, will still end up getting the new block types when reading the block log. If the client must call icrc3_supported_block_types before every time it reads blocks, then it might be the same as just processing the blocks and reading out their types.

[mariop]

@levi

Since a ledger can upgrade to support more block types, a client that has called icrc3_supported_block_types before the ledger upgraded, will still end up getting the new block types when reading the block log. If the client must call icrc3_supported_block_types before every time it reads blocks, then it might be the same as just processing the blocks and reading out their types.

That’s a great point. My take on this is that Ledgers rarely change the block types and when that happens it’s fine for the client to crash and, when restart, give the error to the developer that a new block type was found. The advantage of icrc3_supported_block_types is that you get an error as quickly as possible before doing any operation and that it is a well defined error containing e.g. the URL of the supported block so that the dev can immediately understand the work they have to do to support the new block type.

[Maxfinity]

That works, the certificate verification can be used in inspect message.

[levi]

@mariop

The advantage of icrc3_supported_block_types is that you get an error as quickly as possible before doing any operation and that it is a well defined error containing e.g. the URL of the supported block so that the dev can immediately understand the work they have to do to support the new block type.

If the method returns a URL for each block-type-name then I think it is useful and am in favor of adding the method to the standard.

Something like this:

icrc3_supported_block_types : () -> (vec record { block_type : text; url : text }) query;

[mariop]

Hi,

I pushed the new draft of the ICRC-3 standard. Changes:

1. add icrc3_supported_block_types as described by @levi
2. add the top level field type for block and removed tx.op. Specified that type is optional but recomanded and if not set then the type fallbacks to ICRC-1 or ICRC-2 blocks
3. specify the value of type for ICRC-1 and ICRC-2 blocks (1burn, 1mint, 1xfer, 2approve, 2xfer)
4. added example of ICRC-1 and ICRC-2 with and without the type field

Please have a look.

[Saumay-Agrawal]

Hi all - Is it possible to add support for something like solidity events in this draft?

I think that would be a great feature for getting updates related to on-chain activities of various canisters.

[mariop]

ICRC-3 is for the blocks in a Ledger. Events are something else. You could use the Value type defined in ICRC-3 to represent events on the IC.

[skilesare]

I’m hoping to have some conversations around events with a few others in the ecosystem in the next couple of weeks. Would you be interested in contributing?

@infu has some interesting code you should check out if you want to try to use an ICRC3 log as a type of event log. DeVeFi Ledger - ICRC ledger middleware - #12 by infu

Which features from solidity are you most interested in?

[Saumay-Agrawal]

Would love to contribute, let me know how I can help!

I’m mainly interested in emit events for now because I’m building Ping (https://h7jna-pqaaa-aaaak-afgiq-cai.icp0.io/), a notification delivery system for the dapps in ICP ecosystem. I’ll let you know if something else crosses my mind.

[mariop]

I will leave the draft up for a couple more days and then, unless there are further comments, I’ll make the motion proposal for ICRC-3.

[mariop]

FYI the cycles-ledger will be the first ledger supporting ICRC-3 GitHub - dfinity/cycles-ledger: The cycles ledger is a global ledger canister that enables principal IDs to hold cycles.. I added today the last endpoints.

[skilesare]

Should these lines and others have async in the definition?

dfinity/ICRC-1/blob/be22f710523324d2a4e2574706b5cf5753f5931c/standards/ICRC-3/README.md?plain=1#L369