feat(mimc): adds SetState and State methods to MiMC

[AlexandreBelling]

Description

The PR adds getter and setter methods SetState and a State to the MiMC hasher. In the current state, the method is not raised to the interface level because the interface would not work for other hashers where the state is more than just a field element. In addition, it exposes the Digest method to make the functions reachable by the user. Beside the implementation of hash.Hash is switched to pointer receivers to make changes on the field h effective.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How has this been tested?

It has not been extensively tested as these are just getters and setters.

How has this been benchmarked?

No benchmark done

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[ivokub]

I guess the utility of the function would be to store the state of the hasher and recreate it later?

In this case, wouldn't it make more sense to implement io.WriterTo and io.ReaderFrom interfaces? In this case we can have imo hash-agnostic implementation and it would coincide with the rest of the interfaces we have.

And in that case - a serialize-deserialize roundtrip test would be good.

[AlexandreBelling]

As a piece of context, the use of this PR is to support this PR.

TLDR, I need to save the state of the FS hasher to restore it at specific points during the protocol. A corresponding branch also exists on gnark.

[io.WriterTo] and [io.ReadFrom] are interesting, but I wonder if we can make sense of that in the gnark circuit world. There is also a significant potential for confusion between the state of the hasher and the digest: from a user perspective, it's unclear what the function would serialize. They are the same for MiMC but not for Keccak256, Poseidon and that's a byproduct of these using the sponge construction.

Generally speaking, I prefer to use standard interfaces unless what the function concretely implements is totally unambiguous.

[ivokub]

As a piece of context, the use of this PR is to support this PR.

TLDR, I need to save the state of the FS hasher to restore it at specific points during the protocol. A corresponding branch also exists on gnark.

[io.WriterTo] and [io.ReadFrom] are interesting, but I wonder if we can make sense of that in the gnark circuit world. There is also a significant potential for confusion between the state of the hasher and the digest: from a user perspective, it's unclear what the function would serialize. They are the same for MiMC but not for Keccak256, Poseidon and that's a byproduct of these using the sponge construction.

Generally speaking, I prefer to use standard interfaces unless what the function concretely implements is totally unambiguous.

I agree about the ambiguity when using io.WriterTo and io.ReadFrom that the users could confuse it for the writing data to hasher and computing a digest. For static types (e.g. keys, circuits etc.) they seem to be suitable. Also, it definitely wouldn't work inside a circuit due to mismatching types (we work with frontend.Variable inside the circuit).

And I guess that when we don't care that much about being hasher agnostic, then having dedicated methods only for MiMC would work well. I'll have a look at your PR at monorepo and then review the current PR.

[ivokub]

As a piece of context, the use of this PR is to support this PR.
TLDR, I need to save the state of the FS hasher to restore it at specific points during the protocol. A corresponding branch also exists on gnark.
[io.WriterTo] and [io.ReadFrom] are interesting, but I wonder if we can make sense of that in the gnark circuit world. There is also a significant potential for confusion between the state of the hasher and the digest: from a user perspective, it's unclear what the function would serialize. They are the same for MiMC but not for Keccak256, Poseidon and that's a byproduct of these using the sponge construction.
Generally speaking, I prefer to use standard interfaces unless what the function concretely implements is totally unambiguous.

I agree about the ambiguity when using io.WriterTo and io.ReadFrom that the users could confuse it for the writing data to hasher and computing a digest. For static types (e.g. keys, circuits etc.) they seem to be suitable. Also, it definitely wouldn't work inside a circuit due to mismatching types (we work with frontend.Variable inside the circuit).

And I guess that when we don't care that much about being hasher agnostic, then having dedicated methods only for MiMC would work well. I'll have a look at your PR at monorepo and then review the current PR.

See #564 for a generic proposal. See if it would make more sense. Currently depends on code generator upgrade, but it introduces more changes which I wanted to avoid in this PR.

[ivokub]

See #564 for a generic proposal. See if it would make more sense. Currently depends on code generator upgrade, but it introduces more changes which I wanted to avoid in this PR.

@AlexandreBelling - #564 is now done with all the tests, documentation update etc. The interface for using in Linea should be the same, but you don't have to check interfaces anymore. If that one looks good, then I propose merging #564 and closing this one (#560).

[ivokub]

Closing - work continues in #564