HoneyBadgerMPC is a robust MPC-based confidentiality layer for blockchains.
Compared to other blockchain privacy techniques, like zero knowledge proofs, the main appeal of HoneyBadgerMPC is that it is much more flexible --- MPC can be used to write arbitrary smart contracts that compute on secret data, while providing availability, integrity, and confidentiality guarantees. While there are many MPC implementations, HoneyBadgerMPC is uniquely suited for blockchain integration because of its focus on robustness --- it is the first MPC toolkit to provide guaranteed output in spite of Byzantine faults.
HoneyBadgerMPC is a research prototype, and is best used for prototyping, proofs of concept, and benchmarking experiments. As a library, HoneyBadgerMPC provides a python-based programming environment for writing custom MPC programs. The programs can be run in several ways:
- for testing and development, they can be running in a single-process simulated network
- to test the entire protocol implementation including socket communications, it can be run in a docker network with multiple containers
- For distributed benchmarks, HoneyBadgerMPC can also be deployed to different cloud datacenters
- To try out HoneyBadgerMPC, we recommend following these instructions to set up the Docker-based development environment. Then check out
apps/tutorial/
for a walkthrough that explains some sample MPC programs and shows how to run in different modes
Secure Multiparty Computation (MPC) is about computing on secret-shared data. For each piece of confidential data x
, each of the n
server nodes stores a different share [x]
. Any t
of the servers can be compromised without revealing any information about the confidential data. However, as long as n-t
parties are runnng correctly, they can work together to perform arbitrary computations and disclose only the outputs, leaking no additional information about the inputs.
The HoneyBadgerMPC protocol is based on known MPC techniques, carefully selected to achieve the robustness goals. HoneyBadgerMPC consists of three main phases:
- Collecting client inputs.
Clients submit input to the servers through an input masking technique [COPS15]. The servers start with a secret sharing of a random mask
[r]
. A client retrieves shares of this mask from the servers and reconstructsr
, and then publishes their masked message(m+r)
. The servers obtain their share of the input as[m] := (m+r)-[r]
.
Our programming model is mainly inspired by Viff. In fact our codebase began as a rewrite of Viff, porting it to Python3/asyncio
rather than Python2/Twisted
.
The programming model is based on Python mixins, which extend a Share
that represents a pipelined MPC computation.
To reach agreement on the published inputs, we make use of either the built-in asynchronous broadcast protocol (a port of HoneyBadgerBFT), or else an external blockchain service (See Fabric Integration and Ethereum Integration).
- Online phase.
Once clients provide input, the protocol computes an MPC program layer by layer.
An MPC program consist of linear operations on secret shared data, as well as batch reconstruction. Linear operations can be computed locally, non-linear operations like multiplication must be emulated using share reconstruction and preprocessed values.
See
mpc.py
,batch_reconstruction.py
,taskprogramrunner.py
,reed_solomon.py
Our share reconstruction implementation is aggressively batched, and uses C++ and the NTL library for performance.
The bottleneck operation in MPC is generally batch reconstruction of secret-shared values. Here the batch operations are implemented in C++ using the NTL library, and wrapped using Cython. We implement both FFT-based (quasilinear) and matrix based (superlinear). (TODO: link to benchmarks about FFT vs matrix mul)
- Offline phase (generating preprocessing ingredients).
Since the online phase consumes preprocessed random values, we need to generate these values ahead of time.
For a continuously running service, we need to generate such values at the same rate we consume them.
We use a linear overhead method
RanDouSha
[BH08]. Seeoffline_randousha.py
For more detail on the HoneyBadgerMPC components, see docs/subprotocols.rst.
Compared to oher MPC toolkit implementations (https://www.multipartycomputation.com/mpc-software, https://github.com/rdragos/awesome-mpc#software), HoneyBadgerMPC is unique in that it focuses on robustness.
In a network of n
server nodes, assuming at most t<n/3
are compromised, then HonyeBadgerMPC provides confidentiality, integrity, and availability guarantees. In MPC terminology, it is asynchronous, provides active security, has linear communication overhead, and guarantees output delivery.
Other MPC toolkits, such as SCALE-MAMBA, Viff, EMP, SPDZ, and others, do not provide guaranteed output delivery, and so if even a single node crashes they stop providing output at all.
Linear communication overhead is about scaling to large network sizes. HoneyBadgerMPC implements aggressive batching and amortization, so as more server nodes are added, the communication cost per server approaches a constant).
So far, one of the main ways to provide privacy for blockchains is to use commitments and zero knowledge proofs. As an alternative, the main advantage of MPC is that it can provide better availability guarantees. With commitments, there is usually a sngle party (the prover) who knows the witness. This becomes a problem when writing general smart contract applications, like auctions or mixers. If the prover aborts the protocol, then the committed data is inaccessible. In MPC, the secret data is stored as secret shares on the server nodes, so if any 1/3 of the server nodes fail, the data is still available.
As an illustration of the use of HoneyBadgerMPC, we include a mixnet application called AsynchroMix.
AsynchroMix provides an anonymous communication service. Compared to alternative mixnet protocols, such as CoinJoin and PathShuffle, the main benefit of AsynchroMix is its robustness - any t
of the servers can fail and the system will still produce guaranteed output.
AsynchroMix explanation is coming soon... TODO
HoneyBadgerMPC is designed to be a useful starting point for other research prototypes involving cryptography and MPC.
We parameterize HoneyBadgerMPC with a finite field based on the BLS12-381 pairing-friendly elliptic curve (the same one used in Zcash Sapling).
The codebase comes with a python wrapper for the rust-based implementation of BLS12-381
(see betterpairing.py
).
This is used to provide constant size polynomial commitments (see the hbavss.py
).
HoneyBadgerMPC also includes an MPC implementation of MiMC
symmetric cryptography (honeybadgermpc/progs/mimc.py
), and the JubJub
elliptic curve for public key cryptography (honeybadgermpc/progs/jubjub.py
).
HoneyBadgerMPC is designed to be linked up with external (transparent) blockchain so it can provide a privacy-preserving extension. The following integration ideas have been explored so far:
- a built-in asynchronous BFT protocol (HoneyBadgerBFT)
- The AsynchroMix applications
apps/asynchromix/asynchromix.py
contains an exampleweb3
(Ethereum) ropsten integration. Run it withpython apps/asynchromix/asynchromix.py
. - (Coming Soon) HoneyBadgerMPC has been integrated with Hyperledger Fabric.
The HoneyBadgerMPC library documentation is under the docs/ directory.
This is an open project we welcome contributions from others. See CONTRIBUTING.md to get started!
See CHANGELOG.md for credits to individual contributors. Work on HoneyBadgerMPC has been funded in part by grants from:
- Initiative for Cryptocurrencies and Contracts (IC3)
- Center for Cognitive Systems and Research
- National Science Foundation (#1801321, #1943499)
- Cyber Resilient Energy Delivery Consortium (CREDC)