Decode account state blob

phil · June 23, 2019, 4:21pm

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/account_config.rs 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?

drussi · June 23, 2019, 5:01pm

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

phil · June 30, 2019, 2:28pm

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:

github.com

perfectmak/libra-core/blob/5b6a57edde835b80640631d25acd7b1431182319/lib/client.ts#L250


  return new Promise((resolve, reject) => {
    this.client.submitTransaction(request, (error: ServiceError | null, response: SubmitTransactionResponse) => {
      if (error) {
        return reject(error);
      }
      resolve(response);
    });
  });
}


private _decodeAccountStateBlob(blob: Uint8Array): AccountState {
  const cursor = new CursorBuffer(blob);
  const blobLen = cursor.read32();


  const state: { [key: string]: Uint8Array } = {};


  for (let i = 0; i < blobLen; i++) {
    const keyLen = cursor.read32();
    const keyBuffer = new Uint8Array(keyLen);
    for (let j = 0; j < keyLen; j++) {
      keyBuffer[j] = cursor.read8();

My implementation in Go is this one:

github.com

philippgille/libra-sdk-go/blob/6ab03e9c7091dd97461ae64cc246d792f8c25e29/account.go#L26


// AccountState represents the state of an account.
type AccountState struct {
	// The whole account state as raw bytes
	Blob []byte
	// The account resource with balance etc.
	AccountResource AccountResource
	// TODO: AccountEvents?
}


// FromAccountStateBlob converts an account state blob into an object of the AccountState struct.
func FromAccountStateBlob(accountStateBlob []byte) (AccountState, error) {
	result := AccountState{
		Blob: accountStateBlob,
	}


	r := bytes.NewReader(accountStateBlob)


	// Inspired by https://github.com/perfectmak/libra-core/blob/6dc45f7b72aee0162d52a9d53d99cdae1adae6f1/lib/client.ts#L250


	var mapEntryCount uint32
	err := binary.Read(r, binary.LittleEndian, &mapEntryCount)

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.

yehors · June 30, 2019, 3:01pm

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

You can look at its structure here: https://github.com/libra/libra/blob/master/types/src/account_config.rs#L176

dbascans · September 5, 2019, 2:55am

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

glachac · September 5, 2019, 4:16pm

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.