zengo-x / white-city

Network layer for MPC (Secure Multi-Party Computation) based on Tendermint

white-city

API to integrate distributed network for secure computation protocols.

Read more details in our technical report:
White-City

Background

Secure Multiparty Computation (MPC) has transitioned from a thoretical field to applied technology with real life use cases. In MPC a set of n parties are running a distributed computation over private inputs. To do so, MPC protocols designers make assumptions on the required network and communication channels. A complete p2p network setup might turn out to be costly, effectively eliminating the practicallity of running MPC at scale.

Instead, we suggest using untrusted coordinator, connected in a star topology to all clients. This gets us immidiate improvment on communication complexity of simple p2p, and potentially benefits robustness, accountabillity and fault tolarance.

Project Status:

The current stage is focused on the idea of replicated state machine. The repo contains three proofs of concepts. The latest implementation uses Tendermint to replicate the state machine across a set of known servers. Clients broadcast transactions to the servers to change the state, and read messages from the public bulletin board. Older PoCs are using a single untrusted coordinator.

• Tendermint: Broadcast channel using Tendermint as an immutable bulletin board.
• TokioServer: a socket level implementation using Tokio Crate.
• RocketServer: a Http server implementation using Rocket crate. Proofs of concept are currently running multi party EdDSA library. In general, all messages in the MPC protocol should be broadcast messages (p2p messages are broadcasted encrypted).

As a side project there is also an effort to formally verify the centralized state machine model in Coq/TLA+

Hall of Fame:

Here is a list of contributors to White City (not ordered):

• Avi Kozokin
• Alex Manuskin
• Frederic Peschanski
• Omer Shlomovits
• Roman Zeyde
• Haoyu LIN

Want to Contribute:

Please send an email to [email protected] containing your github username. We will get in touch and bring you up to speed. We try to keep the list of issues relevant so it might also be a good place to start. Join the ZenGo X Telegram for discussions on code and research.

white-city's Issues

server support for more than one session

Currently the server is being re-run for each full flow of a protocol session. It would be better to expand the server in such a way that when a session ends, it can receive connections and start a new relay session. Optimally, it should support sessions in parrallel

build a simple proxy

A proxy is a server that manages and routes all communication in the system.
Each party should register to the server and get some id that will indicate what role the party should play in the protocol: what is the order of messages. Party 1 will start the protocol. Party 2 will have its turn after a message from Party 1 has arrived, etc.. After Party n the round is over and we go back to party1.

all messages are sent to the server and the server can have two forwarding options:

1. s2p [server to peer]: send the message received from Party i to Party j
2. sb [server broadcast]: send the message to all parties i != j.

The forwarding option should be specified as part of the message sent to the server.

Finally the server can accept an abort message at any time during the run of the protocol. After which we need to restart from registration.

We assume no encryption and only one session can take place at a time.

For testing, ECDH from #1 can be used.

Use PKi for client identification

Currently in the Tendermint implementation, the client and server are using an IP address for identification.
This should be replaced with public/private key infrastructure, possibly predefined in a separate file

Move client implementation to a new sub-crate

Clients are currently implemented as examples.
These should be moved to a separate sub-crate with its own library, and remove repeated code

Make clear room for cryptographic protocol

Ideally we would like a cryptographer to be able to write /copy his protocol in a nice an easy way to plug in. For example: it should be clear : here write the code for first round, here write the code for last round etc.
Currently a cryptographer needs to be also a developer to understand where to write his code.

p2p diffie-hellman key exchange

ECDH is a simple two party protocol .
In our implementation the protocol consists of two rounds of communication (each party sends 2 messages).

1. choose proper Rust network library (see list with options below)
2. build a rust project from scratch that implements the network layer, simulated in the chain-code test
3. Benchmark and test with two computers

Client support for p2p

Currently the client (specifically two_part_eddsa_client.rs) messaging works as broadcast:
The Client instance sets the bc_dest field to be a vector of all peers [1,..,capacity].
In order to support messaging to an arbitrary vector of peer_identifiers,
The function get_next_item needs to also return the desired to vector.

Client timeout on no answer

The client connects to one of the servers. In case the server fails, or does not respond within a reasonable time, the client should try to relay its messages to another server

two_party_eddsa_client expansion

check if and why the two_party_eddsa_client fails for n>2 clients.

questions on relay_server

#2

• number of rounds should be determined like number of parties.
• peer_number is currently abusing connections hash map, why not just use the hash value?
• server IP should not be constant (localhost)
• where timeout is defined ? (i.e. if a message from party i was not received in a specific round for more than x sec - send abort to all and make round number zero)

Efficiently request information from the log

Currently the app responds sends a response of messages in a certain round to a client after all messages of this round are received.
This means the final message can be too big, and possibly fail due to maximum RPC response size.

Instead, the client should request all messages it is missing, and receive as a response all available messages of that round, up to some reasonable limit.

For a large number of participants, the client will receive all message within a few rounds

Setup scripts to run any number of servers

Add configurations for any number of Tendermint servers

Clients busy wait while waiting for peers to connect

Clients keep polling server while not all peers are connected.

Make transcript of protocols

@amanusk I think you might started something like this with your log file. We need to have a way for the server to produce a transcript that will record all messages in the protocol

add mp-ecdsa protocol to TokioServer

timeout in messaging for two_party_eddsa_client

Check the lowest time constraint for timout between message sending of clients to server (to avoid throttling)