Understanding transaction serialization (low-level, here we come)

Technical Discussion
#1

It’s part of the discussion I’ve had some time ago with @Quantum_Mechanics and @kodtycoon about javascript transaction serialization, I thought it might be good to share it publicly (for greater good).

There are two parts:

  • “hi-level” that is creating some objects, and
  • “low-level” that is actually doing serialization of those objects

  1. in services, there are two kinds of methods, those for outside world are things like prepareTransfer or prepareTransferV2 those are sort of hi-level api, and internally it uses low-level apis starting with _ (like _constructTransfer or _multisigWrapper)

  2. actual GUTS are in this huge serializeTransaction, it COULD be splitted into multiple parts, but due to common things it was much easier keep all of that in a single place.
    so let’s consider TransferTransaction for example the serialization, is almost 1-to-1 based on THIS: https://github.com/NewEconomyMovement/nem.core/blob/master/src/main/java/org/nem/core/model/TransferTransaction.java#L239
    super.serializeImpl(serializer); - that’s the part that’s common for all the txes, in JS it’s everything that’s happening till the first if:
    if (d[0] === TransactionType.Transfer) {
    regarding the “counters”, inside serialization 'i' is the dword-based counter, 'e' is the byte-based counter, since it’s not used most of the time, it’s updated only sometimes…
    both arrays (b and d) point to same underlying buffer:

var r = new ArrayBuffer(512 + 2764);
var d = new Uint32Array(r);
var b = new Uint8Array(r);

Usage of d is to make dword-based read/writes easier…
ofc that is possible only if you can guarantee that your current “write” (that is ‘e’) is aligned to 4-bytes

Pasted image1813×675 693 KB

Once you put it side-to-side it becomes much clearer, what is happening :slight_smile:

Message in tx is a bit more complicated as it’s split into SecureMessage and PlainMessage, (and both of them inherit from Message)

The fun part is that this JS serialization backend doesn’t really care if it’s secure or not as actual message encoding has been done earlier :slight_smile:

I know, that the code is FAR from pretty, and it should have some proper class and/or wrappers over it (like write32bits, write64bits).

5 Likes
NCC API Not Able to Send XEM
#2

May I include this in the developer’s guide?

#3

sure why not.

#4

I don’t want to copy content from @gimre without his consent

#5

Whatever’s published here should be considered public.