Recommend just using U64: https://github.com/commonwarexyz/monorepo/blob/main/utils/src/sequence/u64.rs

I intentionally wanted to avoid encoding the length as a full 8 bytes, because that's a lot of overhead for small messages.

I'm pretty sure the code as-written is the same as self.hasher.update(UInt(self.pending).encode).as_ref()); However, it seems you are doing this to avoid a heap allocation (?) Related to #1507

I would probably just stick with what's clearer for now (possible heap allocation)

I intentionally wanted to avoid encoding the length as a full 8 bytes, because that's a lot of overhead for small messages.

Curious how much overhead this actually ends up being? When running on a 64-bit machine, seems like this would get padded up anyways (not to mention you avoid the extra work of encoding a varint)?

If you were ok with u64, it would just look like this (avoids the heap as well):

    fn flush(&mut self) {
        self.hasher.update(&self.pending.encode_fixed::<8>());
        self.pending = 0;
    }

I would probably just stick with what's clearer for now (possible heap allocation)

If you do want to keep UInt, I echo Brendan's point that we should try to use codec directly for this (or put up a preliminary PR that allows you to take it to a level of efficiency you are happy with).

Well, we are using codec by virtue of using Write, which Encode requires as a super trait.

I'm pretty sure the code as-written is the same as self.hasher.update(UInt(self.pending).encode).as_ref()); However, it seems you are doing this to avoid a heap allocation (?) Related to #1507

I would probably just stick with what's clearer for now (possible heap allocation)

clarity:

• subsequent calls to what? Maybe: "...append and commit are considered part of the same message until the end of the next commit call." (?0
• Mention that no other functions (besides append) can be called until commit is called, otherwise it will panic

finalizing twice (once in summarize and once in finalize_xof) seems a bit inefficient, so I considered recommending doing self.hasher.clone() and doing something with that, but I realize that creates kind of a minefield for possible collisions. So maybe the way your doing it is safest

Another possibility is adding in an EndTag which would get appended right before calling hasher.finalize (or finalize_xof). Then you could distinguish between summarize and noise without an additional compression function call.

On a second look, this seems unavoidable if you want to keep &self, because you can't write in the label without modifying the state, and what you want to do instead is initialize a new hash object. I've pushed a commit which makes initialization take an optional Summary instead, to be used as the key, but you still need to commit the data to this new keyed hash function.

TIL