This issue has the goal of mapping the different layers that make up an EthBadgerMPC application.
Motivation
Reasoning in terms of layers can be useful to gain an understanding of how a system works, and can also help when designing new components. For instance: "Where should I put this piece of code?" "Which part of the code is responsible for function X?" etc. If one can answer these kinds of questions by saying: "This goes into layer A." it may provide a relatively clear answer as opposed to: "Hmmm .. maybe in file x, or file y ..." Any ways, this is by no means meant to be a dogmatic approach but rather a flexible way to help reasoning about the system as a whole.
More specifically, reasoning in terms of layers may help answering the following questions:
What should be left up to the application developer? (ethbadgermpc application layer)
What should be provided by the EthBadgerMPC SDK? (SDK layer)
What should be baked in the low-level HoneyBadgerMPC code? (HBMPC layer)
Since the development of EthBadgerMPC is taking place in a research and prototyping context, it's perhaps reasonable to assume that an application developer may at certain times need to add something in the lower-level layer of the HoneyBadgerMPC code base, or perhaps they may be mistakenly thinking that they need to do so ... but in any case having an overview of the different layers and their purpose may also be helpful to provide guidance to application developers on how to reason about their application on the context of the EthBadgerMPC framework.
Examples of layers:
Persistence layer: responsible for storing data in an underlying database system, or to a file system.
Ethereum communication layer: responsible to interact with Ethereum contracts.
...
EthBadgerMPC System overview
As a starting point for this issue, here's a broad overview of the EthBadgerMPC system.
A first attempt at a layered view of an EthBadgerMPC node may look like the following:
Concrete Questions
Where should the code to perform a private reconstruction of an input mask go? In Asynchromix and other applications where clients need to send their secret data to MPC servers (via an Ethereum contract), input masks are used by clients to "mask" their private data. Clients reserve an input mask via an Ethereum contract which maps the sender's (eth) address to a unique mask ID. The client then uses this unique mask ID to request the shares of the mask to a known and fixed list of MPC servers. Once the client has received a sufficient number of shares it may start attempting at reconstructing the mask. The code look like:
from honeybadgermpc.elliptic_curve import Subgroup
from honeybadgermpc.field import GF
from honeybadgermpc.polynomial import EvalPoint, polynomials_over
field = GF(Subgroup.BLS12_381)
# TODO shares should be a mapping of server ids to shares, so that the
# reconstruction does not rely on the shares being ordered
def reconstruct_mask(shares, n):
poly = polynomials_over(field)
eval_point = EvalPoint(field, n, use_omega_powers=False)
shares = [(eval_point(i), share) for i, share in enumerate(shares)]
mask = poly.interpolate_at(shares, 0)
return mask
This code needs to be re-usable and could perhaps be in the EthBadgerMPC SDK. But it may make more sense to put that code in a lower-level layer, as input masks are generally speaking random values, and privately reconstructing random shares is most likely needed in all kinds of other contexts, different from EthBadgerMPC.
This issue has the goal of mapping the different layers that make up an EthBadgerMPC application.
Motivation
Reasoning in terms of layers can be useful to gain an understanding of how a system works, and can also help when designing new components. For instance: "Where should I put this piece of code?" "Which part of the code is responsible for function X?" etc. If one can answer these kinds of questions by saying: "This goes into layer A." it may provide a relatively clear answer as opposed to: "Hmmm .. maybe in file x, or file y ..." Any ways, this is by no means meant to be a dogmatic approach but rather a flexible way to help reasoning about the system as a whole.
More specifically, reasoning in terms of layers may help answering the following questions:
Since the development of EthBadgerMPC is taking place in a research and prototyping context, it's perhaps reasonable to assume that an application developer may at certain times need to add something in the lower-level layer of the HoneyBadgerMPC code base, or perhaps they may be mistakenly thinking that they need to do so ... but in any case having an overview of the different layers and their purpose may also be helpful to provide guidance to application developers on how to reason about their application on the context of the EthBadgerMPC framework.
Examples of layers:
EthBadgerMPC System overview
As a starting point for this issue, here's a broad overview of the EthBadgerMPC system.
A first attempt at a layered view of an EthBadgerMPC node may look like the following:
Concrete Questions
Where should the code to perform a private reconstruction of an input mask go? In Asynchromix and other applications where clients need to send their secret data to MPC servers (via an Ethereum contract), input masks are used by clients to "mask" their private data. Clients reserve an input mask via an Ethereum contract which maps the sender's (eth) address to a unique mask ID. The client then uses this unique mask ID to request the shares of the mask to a known and fixed list of MPC servers. Once the client has received a sufficient number of shares it may start attempting at reconstructing the mask. The code look like:
This code needs to be re-usable and could perhaps be in the EthBadgerMPC SDK. But it may make more sense to put that code in a lower-level layer, as input masks are generally speaking random values, and privately reconstructing random shares is most likely needed in all kinds of other contexts, different from EthBadgerMPC.