The fate of WASM bindings

[fjarri]

Do we need the WASM bindings in this repo? If yes, we need to decide on what API to export, and, consequently, what to test. Right the bindings are basically a placeholder.

[tmpfs]

Hi @fjarri,

I have been working on a networking layer for MPC protocols (with first-class support for webassembly) that communicates via an E2EE relay server (using the noise protocol).

The aim is to have an abstraction for different protocols and I would like to integrate synedrion as the CGGMP implementation.

There are webassembly bindings there so if I can integrate with synedrion perhaps you don't need to maintain bindings here?

The library drivers use round-based and it would be really useful if we could provide a wrapper for synedrion that uses round based, would you accept a PR that adds that? Maybe behind a feature flag?

[fjarri]

I think it would be nice to have a round-based wrapper, but I'm not sure it should be a part of the main crate; probably a separate crate would work out better.

Having only skimmed the docs, I am not certain how well the round-based abstraction would match synedrion's API. Problem points may include:

• caching messages received from nodes already in the next round and later applying them (synedrion does this; if it can't be offloaded to round-based the users of that abstraction will lose the functionality)
• parallel message generation and verification
• correctly propagating malicious behavior reports and correctness proofs to the users and their verification by third parties (this is complicated by the fact that this feature is not entirely finalized in synedrion itself)

[tmpfs]

Thanks @fjarri for the pointers.

1. I already implemented caching as it was not something that existed in the MPC implementations I tried (which caught be by surprise) so this shouldn't be a problem.
2. Could you elaborate here, my understanding was that message processing needs to be sequential but that parallelism could be applied to computationally expensive aspects of the protocol?
3. This is definitely an issue, but I am not too concerned about it for my use case (MPC wallets) where there is already some level of trust, for other use cases (such as untrusted nodes on a network) this is a much bigger issue. How are malicious behavior reports raised? If they are generated as an Error then these could be propagated via round-based I expect.

I am going to try to write a wrapper for synedrion using round-based to see how feasible it is.

Will let you know if I hit any other issues. Thanks 🙏

[fjarri]

Could you elaborate here, my understanding was that message processing needs to be sequential but that parallelism could be applied to computationally expensive aspects of the protocol?

No, for CGGMP at least both message creation and verification (where most of the time is spent) can be done in parallel.

How are malicious behavior reports raised? If they are generated as an Error then these could be propagated via round-based I expect.

Yes, they are returned as a variant of Error, but right now there's no API to actually verify them - I am working on that (the relevant issue is #43). But if you're not interested in the verification, you can just use the offending party ID that's returned as well.

A more complicated case is the correctness proof. In some cases during round finalization there may occur an error where it's not possible to determine who was at fault; in this case the protocol prescribes for each node to generate a proof that they did they part of the work correctly, and these proofs are supposed to be verified by a third party (or other nodes).