Hashing without memory allocations

[scnale]

This adds a few functions that allow the user to hash without extra memory allocations.

This doesn't include calldata variants because they would be pointless: the KECCAK256 instruction only operates with data in memory so a copy to memory would be necessary anyway.

[AgusVelez5]

I got the idea that have the calldata variant is pointless but with the current implementation of keccak256SubarrayUnchecked and keccak256Subarray if we are working on the calldata, we will not be copying the whole bytes to memory?
Could there be a way to avoid that and copy only the necessary bytes, like making a slice, saving it in memory and then using it?
However, I am not sure it is worth do it.

[scnale]

Ah, you're right. It might be worth adding a calldata variant in that case.

[scnale]

Actually, I think it's not necessary. You can slice the calldata buffer and it'll copy just the slice, not the whole buffer.

Like this:

function test_calldataSlice(bytes calldata data) public {
        bytes calldata slice = data[5:data.length];
        bytes32 hash = slice.keccak256Subarray(0, slice.length);
}

[AgusVelez5]

Yeah, that's true but the user should be aware of that. The common way we usually use the BytesParsingLib is doing the operations directly over the encoded buffer. Maybe if we offer the functions outside the lib, like utils makes you pay more attention.

[scnale]

I don't think we should add functions without good reason. Every new piece of code means more maintenance in the long run. Harder to read codebase, etc.

[scnale]

When reviewing this PR after the latest changes I realized something: it's actually useful to have a calldata variant because we can use the space after the free memory pointer to copy the data, hash it and then return the result. The good thing about this is that we don't consume a fragment of the memory while respecting the memory model.

[nonergodic]

Love it!

[nonergodic]

One thought:
The current signature of function keccak256SliceCdUnchecked(bytes calldata encoded, uint offset, uint length) is in line with the memory version which is good.

Otoh, since slicing calldata is now cheap, one could reduce the signature to just function keccak256Cd(bytes calldata encoded) and rely on composition with BytesParsing.sliceCdUnchecked (using Solidity's [start:end] syntax would introduce checks).

Would have the small advantage that hashing a full bytes calldata is cleaner because you don't have to manually specify offset and length when you don't need it, and cheaper because you don't have to push it on the stack and have that offset add.

[scnale]

Hm, makes sense. I'll do that then.