API v0.5

[survived]

New API proposal that integrates the router into Mpc trait. Protocol implementation registers rounds by using methods of Mpc trait, and then uses the same trait to send and receive messages.

This allows the protocol expose its rounds structure to outside world. For instance, that can be used to generically implement echo broadcast mechanism that will work with any protocol.

• Integrate the rounds router into the Mpc trait
• Add .send_many() to MpcExecution trait so the protocol can send many messages followed by single flush (instead of flushing per each outgoing message, which can be impractical for p2p rounds for certain delivery implementations)
• Implement echo broadcast
• Remove re-exports of StreamExt, SinkExt
• Make sure existing protocol implementations work well with the new version

[maurges]

Looks useful, maybe we should add this to the crate itself

[survived]

Error here is random beacon-specific error type, we can't add it to the crate itself

[maurges]

Did we really need to change the name here? It does nothing but make the diff bigger and force you to make changes in the consumer crate

[survived]

I did really need to change it, yes 🙂

[maurges]

I had a thought that this api has weird extension points. Mpc is a very big trait and hard to implement, our own implementation is split across four files. Does it need to be a trait? Do you forsee another implementation existing?

On the other hand, MpcParty now hardcodes RoundsRouter, which I previously used as an extension point. How big will ku23 code now become that I have to reimplement the whole of Mpc for it?

[survived]

Pushed changes per your review @maurges

[survived]

I had a thought that this api has weird extension points. Mpc is a very big trait and hard to implement, our own implementation is split across four files. Does it need to be a trait? Do you forsee another implementation existing?

Yes, the whole point of this PR is that Mpc becomes a trait. The purpose is to allow one to wrap Mpc, so we can "intercept" rounds being registered.

One of the use-cases: generic echo broadcast support for any protocol, that is provided out-of-box in this library. It wraps Mpc and adds echo broadcast round per each registered reliable broadcast round.

Among other use-cases, one can wrap Mpc trait and get useful tracing information, e.g. how long each round lasts, how long we wait for messages to be received. I plan on adding stage() method so the protocol can emit more traces, and we can write generic profiler for any MPC protocol, once and for all.

Also this design is a step forwards composable protocols, e.g. we will be able to define subroutines (e.g. rss, triple and others in ku23, each of them is an interactive subroutine) and then define a protocol as a composition of those primitives.

On the other hand, MpcParty now hardcodes RoundsRouter, which I previously used as an extension point. How big will ku23 code now become that I have to reimplement the whole of Mpc for it?

Any code that was using RoundsRouter can painlessly switch to new Mpc trait. Mpc trait provides polished version of RoundsRouter interface, so you won't need to re-implement Mpc. Actually, I can't think of any scenario in which a protocol implementation needs to implement its own Mpc: you implement Mpc when you need to take control of rounds being registered, not something you do in your own protocol.

The only "customization" you did in ku23 is defining your own RoundStore. It's still possible via Mpc trait obviously as it's essential functionality. No need to define your own Mpc for that. But in the end, you end up using a default rounds store with a bit different input parameters, so there's nothing special in how ku23 uses round-based.

[survived]

@maurges okay to merge?

[survived]

@maurges reminder

[maurges]

lbtm