Quickest: compare with the archive canister did file and translate in your head. The order of lines stays the same between whatās mentioned in the .did file and how itās outputted.
Nicer solution: Download the .did file (linked above) and use the --candid <path/to/can.did> option with dfx canister call.
However, there is still 2 fields (ātoā and āparent_hashā) of type āblobā and āopt blobā respectively that I donāt know how to decode. How can I decode them?
$ dfx canister --network ic call qjdve-lqaaa-aaaaa-aaaeq-cai get_blocks '(record {start = 1: nat64; length = 1:nat64})' --candid ./src/ledger_archive.did
dfx.json not found, using default.
(
variant {
Ok = record {
blocks = vec {
record {
transaction = record {
memo = 0 : nat64;
operation = opt variant {
Mint = record {
to = blob "t\ec\82\f5\e0\d8\05*\a1\1d\c7H$\9b\dd\0a\ec)\d6(\19\9e\ee\ef\ad\d0\13\8f\8b\1b\10Y";
amount = record { e8s = 311_585_714_285 : nat64 };
}
};
created_at_time = record {
timestamp_nanos = 1_620_328_630_192_468_691 : nat64;
};
};
timestamp = record {
timestamp_nanos = 1_620_328_630_192_468_691 : nat64;
};
parent_hash = opt blob "\ff\ca\0e\cf^\83uA\c7\ee[\e41\e43\ad\8e\97*\7f7\1e\86\fb\e4\f8\addl|\bc\ea";
};
};
}
},
)
In both cases Iād expect the data to be binary data - the to field is likely an account identifier and the parent_hash is just what it says: a hash. As for how that would be converted to actual bytes (or hex) I donāt know. Iāll ping the Candid specialists for that.
blob is a short hand for vec nat8, which represents binary data. If the byte is a printable ascii, we show that character directly. Otherwise, we use \xx to represent its hex byte. For example, blob āt\ec\82ā would be 74ec82 in hex.
@chenyan@Severin, could you help me with these more detailed questions about the record format:
What is āmemoā for? it seems that it is always 0. If it always 0, why is it there?
Every record has information about the destination of the transaction (ātoā field) but it has no information about the origin (there is no āfromā field). Without this information, it is not possible to trace the flow of transactions. Is this correct? How can I identify the origin of every transaction?
Iām only 99% sure, but I think the memo is for transaction (TX) deduplication. I have a canister that triggers multiple identical transfers in the same function and if I donāt change the memo between the TXs then it only executes one payment. Maybe thereās some more behind the memo, but thatās the use case I know about.
If you look at the .did file, you can see that thereās three TX types: Mint, Burn, and Transfer. It looks like you only found blocks with Mint operations in them, thatās why you havenāt seen a from field yet.
@Severin@chenyan, I have successfully decoded the principal_ids and confirmed that they exist, so the decoding works. However, when I apply the same decoding algorithm to the parent_hash field, I am not able to find the transaction (FYI, I use ICP Explorer<parent_hash_decoded> ). Is the parent_hash field using a different decoding algorithm?
I think that would be a different algorithm. Iām not familiar with ledger, but I would assume this is a good entry point to start searching: ic/lib.rs at master Ā· dfinity/ic Ā· GitHub
actually, before sending my question, I tried to reverse engineer the encoding strategy for parent_has unsuccessfully probably because my rust skills are quiet bad. I would appreciate ledger developerās feedback
Please take a look at the specification for the ledger . In particular, thereās a section which describes how blocks are hashed. Hopefully that will help.
