This "hello shards" program should demonstrate the basics of using HoneyBadgerMPC "in sharded mode". It can be put under the apps/tutorial directory.
Initial thoughts on how to go about:
[ ] Modify the current config mechanism to support/specify shards.
[ ] Design and implement the intra-shard communication functionalities required.
[ ] Design and implement the cross-shard communication functionalities required.
Configuration mechanism
A node should be configured with a shard id to identify which shard it belongs to. Nodes with the same id will belong to the same shard, and a deployment with a single shard should be equivalent more-or-less to a non-sharded deployment as it is right now. From a user perspective this means, that a user could omit specifying any shard id when deploying a non-sharded application. Internally this can perhaps be handled with a default shard id.
Although the key idea is perhaps simple, it may be worthwhile to briefly look into existing sharded systems to see how they handle the configuration.
This "hello shards" program should demonstrate the basics of using HoneyBadgerMPC "in sharded mode". It can be put under the
apps/tutorialdirectory.Initial thoughts on how to go about:
Configuration mechanism
A node should be configured with a shard id to identify which shard it belongs to. Nodes with the same id will belong to the same shard, and a deployment with a single shard should be equivalent more-or-less to a non-sharded deployment as it is right now. From a user perspective this means, that a user could omit specifying any shard id when deploying a non-sharded application. Internally this can perhaps be handled with a default shard id.
Although the key idea is perhaps simple, it may be worthwhile to briefly look into existing sharded systems to see how they handle the configuration.