Conversation
Co-authored-by: bogwar <[email protected]>
Co-authored-by: bogwar <[email protected]>
|
Really important to be able to query txs by deterministic tx hashes. On ETH it is possible to do this, I hope the IC log contains this functionality, which is crucial for finding transactions. |
|
What would be the recommended approach for getting transactions from/to a specific account without fetching the whole transaction history and filtering? Right now most wallets use Is this something that will be handled in another ICRC standard? |
|
@sea-snake ICRC-3 is concerned with the transaction log only. You can write a canister that indexes transactions for wallets/transaction explorers consumption based on the ICRC-3 API. For instance, we implemented an index canister for our ICRC Ledger that allows the NNS Dapp to query an Account transactions via We should discuss about an indexing standard in the L&T WG. |
|
@blutooth ICRC-3 doesn't provide a way to query transactions by transaction hash. This is a good topic for the WG. |
Co-authored-by: Thomas Locher <[email protected]>
Co-authored-by: Thomas Locher <[email protected]>
standards/ICRC-3/README.md
Outdated
| The [candid](https://github.com/dfinity/candid) format supports sharing information even when the client and the server involved do not have the same schema (see the [Upgrading and subtyping](https://github.com/dfinity/candid/blob/master/spec/Candid.md#upgrading-and-subtyping) section of the candid spec). While this mechanism allows to evolve services and clients | ||
| independently without breaking them, it also means that a client may not receive all the information that the server is sending, e.g. in case the client schema lacks some fields that the server schema has. | ||
|
|
||
| This loss of information is not an option for `ICRC-3`. The client must receive the same exact data the server sent. For this reason, `ICRC-3` introduces the `Value` type which never changes: |
There was a problem hiding this comment.
It's explained before.
There was a problem hiding this comment.
The candid format supports sharing information even when the client and the server involved do not have the same schema (see the Upgrading and subtyping section of the candid spec). While this mechanism allows to evolve services and clients
independently without breaking them, it also means that a client may not receive all the information that the server is sending, e.g. in case the client schema lacks some fields that the server schema has.This loss of information is not an option for
ICRC-3. The client must receive the same exact data the server sent.
There was a problem hiding this comment.
Yeah, that's the text that I commented on. It simply states that it's not acceptable, but it does not explain why.
There was a problem hiding this comment.
I've added the following:
This loss of information is not an option for
ICRC-3. The client must receive the same exact data the server sent in order to verify it. Verification is done by hashing the data and checking that the result is consistent with what has been certified by the server.
Is it better?
There was a problem hiding this comment.
Thanks. Why isn't it up to the client if it wants to verify the hashes? If it wants to verify the hashes, it should make sure to have an up-to-date schema. If it only wants certain data, it can use any schema that provides that data. By verifying the hash it can even make sure that its schema is up-to-date so.
There was a problem hiding this comment.
The client cannot check that the schema is identical to the one of the canister. There is no guarantee that the schema will be identical even if the client first fetches it from the canister. Candid was built with a different goal in mind: the schema of the server can evolve independently from the client.
The solution to this problem is to have a type that will never change over time so it is guaranteed that clients and canisters will always know the full structure. That's what Value is.
There was a problem hiding this comment.
If it wants to verify the hashes, it should make sure to have an up-to-date schema.
Because it's not a sustainable solution in a decentralized system. If we went this way, releasing a new Ledger feature would immediately break block validation for all existing clients. We don't have a full list of our clients, so we cannot ask them to upgrade in advance.
The main clients of ICRC-3 standard are the on-chain and off-chain indexers, such as the index canister and Rosetta. We want these to continue working correctly with no intervention as we evolve the ledger.
|
I'd imagine that many apps will store transactions for each user and want to pull in newer transactions when the user loads their transactions page. To do this they'd ideally be able to pass in the latest transaction Id they have stored for the user and request newer transactions than that. |
roman-kashitsyn
left a comment
roman-kashitsyn
left a comment
There was a problem hiding this comment.
One minor remark: I suspect many people might get confused about the schema definition language and how it's different from the Candid definitions. We might want to elaborate on the difference between these two languages and move all the schemas in a separate section so the reader doesn't have to switch back and forth between Candid and the Value Schema language.
Co-authored-by: :Levi. <[email protected]>
Co-authored-by: :Levi. <[email protected]>
|
Instead of "Value", something more-literal would help casual browsers of the Candid understand what is going on. Something like "UpgradableResponse". |
dietersommer
left a comment
dietersommer
left a comment
There was a problem hiding this comment.
Made some comments on necessary fixes we should do.
feat(icrc-ledger-types): add ICRC-3 types Closes FI-1243 This MR adds [ICRC-3 types](dfinity/ICRC-1#128) to the `icrc-ledger-types` package. The new types have ICRC3 as prefix to distinguish them from the existing ones. The plan is to have both types, the standard and non-standard ones, live together until ICRC-3 is voted and then, once ICRC-3 is voted, replace the old non-standard ones with the new ones and do a breaking change release of `icrc-ledger-types`. I added "deprecation" comments to the non-standard types with pointers to the counterpart standardized structures. The reason why I don't use the `deprecated` macro is that technically those types are not deprecated, they just don't belong to the `icrc-ledger-types` package because they are not standard. Closes FI-1243 See merge request dfinity-lab/public/ic!18329
13 participants
No description provided.