The clients submitting secret data to the EthBadgerMPC system may differ from the clients consuming the output of the multiparty computation that was performed on the secret inputs. It may therefore be useful to split the client into 2 parts: 1) a client that submits secret inputs, i.e. masked inputs and 2) a client that consumes the output of the multiparty computation. In the context of the current development framework that relies on docker-compose service, that would imply an additional independent service, solely responsible for consuming MPC outputs, via a function call to the relevant smart contract.
This should be useful for quickly checking that the MPC outputs have properly made their way to the contract, and can be correctly retrieved from the contract by the "consumer" service.
The clients submitting secret data to the EthBadgerMPC system may differ from the clients consuming the output of the multiparty computation that was performed on the secret inputs. It may therefore be useful to split the client into 2 parts: 1) a client that submits secret inputs, i.e. masked inputs and 2) a client that consumes the output of the multiparty computation. In the context of the current development framework that relies on docker-compose service, that would imply an additional independent service, solely responsible for consuming MPC outputs, via a function call to the relevant smart contract.
This should be useful for quickly checking that the MPC outputs have properly made their way to the contract, and can be correctly retrieved from the contract by the "consumer" service.