Decode account state blob

Hi, maybe this is similar to Libra clients for other languages, but I’m already using gRPC to send an UpdateToLatestLedger request and get a proper account state response back. But the GetAccountStateResponse only contains a AccountStateWithProof which contains the AccountStateBlob and a proof. The blob is exactly the same that the CLI prints as AccountStateBlob { Raw: ... when using for example query account_state 0, so it seems like I’m on the right track. But how should this be decoded?

In the Rust code there’s types/src/ and it contains pub fn make_from(account_map: &BTreeMap<Vec<u8>, Vec<u8>>) -> Result<Self>, which seems to be the function that I need to port to the language I’m using, but I don’t speak Rust and don’t understand how this is being deserialized.

I also couldn’t find any spec in the documentation (like: “x bytes for the account number, 5 bytes for the balance, 3 bytes for the sequence number, …”).

Or is there some proto I’m overlooking that already lets me directly get the balance of an account for example?

try reading this topic and see if it gives you a path to follow.
We understand we need to produce a specification for the data format (overall and as related to the VM) and we are working on that. It will be coming at some point, sorry it’s missing now


Yesterday I found an implementation that was easier for me to understand than the Rust one. Although I don’t know if it behaves exactly like the Rust implementation it worked with the accounts that I tried. I also implemented it the same way in Go and it works as well.

The implementation I found is this one:

My implementation in Go is this one:

There’s still some clarification required, for example about which map key values exist (other than 01217da6c6b3e19f1825cfb2676daecce3bf3de03cf26647c78df00b371b25cc97 for the account resource).

@drussi: Unpacking AccountResource in Python and this thread overlap, so if you rename that other thread to something more generic (and not Python-focused) you can close this thread. Or maybe the other way around.

1 Like

Actually, in clients, there is must be decoding for AccountResourcePath too.

You can look at its structure here:

It seems that the AccountResource has changed in the last update, anybody knows the new order of bytes? it seems that some new property is changed or something, when I decoded it return very huge numbers

It now include the EventKey in the EventHandle, which is the type for the received and sent events. At least as far as I can tell. I just modified a copy of the javascript libra-core to fix this. You can see it at this commit. Essentially, there is a couple of uint8 buffers in there now.