chore: explain magic number 4 for unencrypted logs [hash] length

[dbanks12]

No description provided.

[MirandaWood]

Hey - added a comment to the PR as well.
This +4 exists because when we serialise in unencrypted_l2_log:

  public toBuffer(): Buffer {
    return Buffer.concat([
      this.contractAddress.toBuffer(),
      this.selector.toBuffer(),
      prefixBufferWithLength(this.data), <--- prefixing with length
    ]);
  }

We prefix the data portion with its own length in 4 bytes. This is useful as the data is variable length so we can tell readers how to process it.
I don't think it's strictly necessary though, because the reader should get the full length of this buffer, read the first 32 for the address, read the next 4 for the event selector, then simply read the rest. This is how it works for encrypted event logs, for example.

Re the mismatch you were getting, I'll look into it, but ulog.length in journal.ts does already include this +4 so it should have aligned. Possibly I missed removing some extra +4s in the public kernels!

[MirandaWood]

I see the problem - I should have added the extra +4 you merged in #6580 in my PR #6466, sorry about that! The code in master is correct.

To explain (may not be useful) - before my PR, both the journal and contexts were tracking total logs length. This turned out to be uneccesary because we track individual logs with their lengths, and in a lot of cases sum these lengths anyway. What I missed was that, in the journal, the +4 for processed log length was added and managed via the total. In the contexts, it's now managed per log.
e.g. An unencrypted log of 100 bytes:

unencrypted_l2_log: toBuffer() -> [ addr ][ event ][ [len] log ]
                          bytes:  [.  32 ][   4   ][ [ 4 ] 100 ]  <--- this len 4 is included in ulog.length
function_l2_logs: toBuffer() =
   prefixBufferWithLength(log.toBuffer()) -> [ len [ addr ][ event ][ [len] log ]]
                                     bytes:  [ 4   [.  32 ][   4   ][ [ 4 ] 100 ]]  <--- above + another 4

We want the length of the buffer output from function_l2_logs -> toBuffer to be the stored log length in the kernels. The prefixed +4 in function_l2_logs is the processed log length included in the contexts and (now, after 6580) in the journal. We need to track this to correctly attribute it to DA gas costs.

Later on, ts bundles logs together in TxL2Logs and then in L2BlockL2Logs, which are again prefixed, but we don't currently care about these lengths in the kernels as they are not attributed to a user's DA gas cost. We also extract, chop, and sort logs before sending them to a block so ensuring the 'bundles' and their total lengths match something inside the circuit is pretty complex for tracking 4 bytes!