(feat)examples: Halo2 Keccak256 Example Circuit

[ElusAegis]

1. Added a Keccak256 Circuit to mopro-core/examples/halo2/keccak256 and templates/core/circuits/halo2-keccak256.
2. Added an option to run a halo2-keccak circuit to the template config.
3. Added a Swift view for halo2-keccak circuit.

[ElusAegis]

The situation with workspace is quite tough.

Both keccak and fibonacci crates are actually called halo2-circuit, as the idea is that whenever anyone wants to add another circuit to the mix, they just create a crate called halo2-circuit, provide a path to it in the config, and it will overwrite it in the dependencies (a hack way to include a dynamic build dependency, I looked for a better way, but could not find anything).

And the idea behind the examples/halo2 was to provide an example of such substitution. However, apparently, as you can not have two same-named workspace members, both examples need to be either their own workspace or one of them should be in mopro workspace, one on its own.

At the same time, if we include a local dependency in another create, that is located inside of the another crate's workspace, Cargo enforces it to be in a workspace, and if it is its own workspace, it throws an error. However, if it is a path override, it is okay...

So the following should work:

• fibonacci example to be added to the main workspace
• keccak example to be as its own workspace

[vivianjeng]

@ElusAegis how about also setting them different feature flags e.g. fibonacci and keccak256 so we enable different circuits by enabling different feature flags

[ElusAegis]

I also thought about this. One option is to do place both samples inside of one crate crate, and use features to select between them, similar to FFI. However, that would make the examples complicated and also not quite right, as instead of two independent crates we will get just one shared. This is not ideal as the whole point of examples what in my opinion to show how to have separate crates and do paths overrides.

Another option is to overwrite the dependency in the 'mopro-core' based on the feature flag. However, that seems impossible if both crates have the same name.

I propose to create an issue for that, and figure out something later - if there is a better solution.

@vivianjeng

[vivianjeng]

@ElusAegis one other idea from @vimwitch is that we just use the srs, pk, vk in each example you can maintain the halo2 circuits in either your repo or zkmopro repo and write down in readme or doc: https://zkmopro.org/docs/halo2/introduction how to generate the srs, pk, vk so that we don't have to maintain the halo2 circuits in mopro

[ElusAegis]

I am not sure I understand. The issue is not just in the circuit assets, like srs, pk, vk, but also the logic to generate the proof. So when a user calls generateStaticProof, it should pick up a custom logic implemented by each circuit crate (may be there is a way not to have it like that, which I am not aware)

So by moving the srs, pk, vk out of the equation is unlikely to help. The feature approach is valid, however, again, these two circuits should be separate examples ideally showing how to substitute one for another