Encoding

For example, we have a table with this definition:

    Complicated: {
       schema: {
         key1: "uint200",
         key2: "uint8",
         val1: "uint200",
         val2: "uint8",
         val3: "uint16",
         dyn1: "string",
         dyn2: "bytes",
         dyn3: "int16[]",
       },
       key: ["key1", "key2"],
    },

And we want to understand this data:

The first four 256-bit words correspond to the four unindexed event fields.

ABI encoding starts with one 32-byte word per field. If the field is static, the word contains that value. If the field is dynamic, the word contains an offset into where the field data starts.

bytes32[] keyTuple

This is a variable-length array. The first word is the array length, followed by the values. The key fields are treated internally as 32-byte values, so every value takes 32 bytes. This gives us

bytes staticData

This is the static data (the static fields that are not in the key).

Because the type is an unspecified number of bytes, the first 32-byte word is the length. In this case, the length is 0x1C=28. This means that only the first (most significant) 28 bytes of word 8 are meaningful. The other four are zero.

Going back to the schema, we see that there are three static data fields:

         val1: "uint200",
         val2: "uint8",
         val3: "uint16",

The first one is 200 bits = 25 bytes, the second one is 8 bits = 1 byte, and the third is 16 bits = 2 bytes. They are written consecutively, so

EncodedLengths encodedLengths

This is the definition of the EncodedLengths type (opens in a new tab).

This is the dynamic field part of the schema:

         dyn1: "string",
         dyn2: "bytes",
         dyn3: "int16[]",

Here we see that the first five bytes of the dynamic data are going to be dyn1, the next five dyn2, and the final six dyn3. The total length is 0x10 = 16.

bytes dynamicData

This value is also bytes, so the first word is the length of the data, in this case 0x10=16. Combining this with the encoded lengths information, we get these values:

To interpret the values we need to get the types from the schema.

Using the same table definition as with Store_SetRecord, we want to understand this data:

The first three 256-bit words correspond to the three unindexed event fields.

keyTuple is interpreted the same way it is in Store_SetRecord.

uint48 start

start is 0x19 = 25.

Going back to the schema, we see that there are three static data fields:

         val1: "uint200",
         val2: "uint8",
         val3: "uint16",

Starting from zero, this means that val1 is bytes 0-24, val2 is byte 25, and val3 is bytes 26-27. We are changing from byte 25, so val1's value stays the same.

bytes data

This data starts at word six (byte 0xC0 = 192 = 32*6).

The first word of this field, word 6, tells us that we are only changing one byte of the data, so we aren't changing val3 either. The first byte of word 7, the only one that matters, is 0xFF. This is the new value of val2.

Using the same table definition as with Store_SetRecord, we want to understand this data. Note that the log entry by itself does not tell us if we are appending data or modifying an existing value. It only tells us that we are changing the data in bytes six and seven, not whether there is already data there or not.

The first six 256-bit words correspond to the unindexed event fields.

keyTuple is interpreted the same way it is in Store_SetRecord.

uint8 dynamicFieldIndex

The index of the dynamic field we are modifying. The value here is two. Counting from zero it is the third schema field.

         dyn3: "int16[]",

uint48 start

The byte at which we start the change. Here is it byte six. The effect on the length of the data depends on what we are doing. If we are appending data, we would have six bytes now (three values) and add to them. If we are modifying data, we should have at least eight bytes now (four values), and we modify the fourth value (dyn3[3]).

uint40 deleteCount

The number of bytes we delete. In this case, zero.

EncodedLengths encodedLengths

The encoded lengths in the data after the change (if they change). This value tells us that only the third field changes, and that it will be eight bytes long.

bytes data

This value starts at byte 0x120 = 288 = 9*32, or word nine.

Again, the first word of the bytes value tells us how many bytes we have (two). The second gives us the value we are adding, in this case 0x1234.

Using the same table definition as with Store_SetRecord, we want to understand this data:

The first six 256-bit words correspond to the unindexed event fields.

This is very similar to appending or modifying data, except that deleteCount has a value. This is the number of bytes we are deleting, two (a single array element). Combining this with the start value of six, we are deleting bytes six and seven.

The other difference is that word 9 is zero - there is a bytes data value, but it is empty.