Compatibility with SAFE API

[mmaker]

It'd be really nice if arkworks was compatible with the SAFE API described here https://hackmd.io/bHgsH6mMStCVibM_wYvb2w
(an upcoming paper will be published here).

[burdges]

IOPattern being exposed makes composition too difficult. Interesting optimization though, maybe viable as a wrapper type.

[mmaker]

A similar feature could be achieved statically chaining IOPatterns,but...

Marlin-style composition (and this) are not really fit for chaining: protocols with non-unique response chained together may have the same transcript for two different protocol executions

[burdges]

I've never looked at marlin, so maybe it brings other specialized concerns, but..

At first blush it looked clear how IOPattern helps: A non-snark-friendly sponge, or merlin, wants many domain separation labels nested everywhere, but those add constraints in a snark-friendly sponge. You've compressed them all into one label, but made gadget composition harder in groth16, etc. (no idea about marlin).

You could maybe impose IOPattern asserts using a wrapper type, but leave the traits more composition friendly.

pub struct AssertIOPattern<.., S: Sponge<..>> {
    sponge: S
    pattern: ...
}

impl<.., S: Sponge<..>> Sponge for AssertIOPattern<.., S> { ... }

impl<.., S: Sponge<..>> Sponge for AssertIOPattern<.., S> {
    pub fn new(s: S, p: &IOPattern) -> Self { .. }
}

pub fn apply_io_pattern_sans_assert<.., S:Sponge<..>>(s: &mut S, p: &IOPattern);

[mmaker]

@burdges I thought a bit more about composition and I really don't understand the claim.
I'm pretty sure any decent protocol can just concatenate IOPatterns before concatenating provers 🥸

I made a repository here: https://github.com/mmaker/nimue with some fairly complete examples and plugins for arkworks. Would people be interested in moving arkworks-plugins here (or, even, the whole repo?)