At SINE, we are building an engine for Secure Multi-Party Computation to help us solve data-sharing dilemmas in the sustainability sector. Our first piece of the puzzle is our new programming language for SMPC, Garble, which we are releasing as open source (under an MIT license).
Secure Multi-Party Computation (SMPC) is a cryptographic field with the goal of allowing two or more parties to cooperatively compute a result while keeping their inputs private.
One of the oldest and simplest examples is the so-called "millionaires' problem": Imagine two millionaires who want to find out which of them is richer without revealing their net worth to the other. With SMPC, the two millionaires keep their inputs private from each other and then compute the function a < b, receiving as a result an answer of true or false, but with no way to infer the exact input of the other party from the computation.[1]
This example might be a bit contrived, but SMPC is a very general technique that goes far beyond such a simple use case. A much more intricate example is "mental poker": Imagine that you want to play poker with a group of friends, but without sitting in the same room, for example by mail. In the case of games such as chess this is easy, because there is no information that needs to be kept hidden from another player. But in the case of poker, how do you keep the hands of all the players hidden from each other, while also guaranteeing that nobody is cheating and claiming to have cards that they do not have? You could of course elect a neutral third party that is trusted by all players and have it act as a central hub, but what if you cannot or do not want to trust a central party? It might seem impossible to solve this dilemma in a decentralized way, but SMPC provides a very elegant and general solution.
Although the resulting protocols require more back-and-forth communication between the parties than plain-text program execution, they allow almost arbitrary computations to be performed without revealing the inputs of the different parties to each other.
Our aim at SINE is to make advanced technology, such as SMPC, available to as many companies as possible. We are especially keen to apply SMPC for the exchange of sustainability data in situations where it would otherwise not have been feasible, for instance whenever there is no trusted third party that could perform the computation on behalf of the parties. One such example is benchmarking of carbon footprints: How can companies benchmark the footprint of their products against the ones of their competitors, to find out how they compare in their industry, without revealing their exact data to their competitors? SMPC can solve this dilemma, by computing a benchmark result cooperatively without revealing carbon footprint data.
Garble, our programming language for SMPC, allows anyone to write SMPC programs and run them against our soon-to-be-released SMPC engine. We want every software developer to make use of SMPC with as least friction as possible.
To achieve this, Garble compiles down to so-called Garbled Circuits (hence the name of the language). Garbled Circuits are a foundational approach to SMPC, based on the execution of boolean gates (AND, XOR and NOT gates) very similar to how CPUs work at the gate level.
Garble's syntax and some of its semantics are borrowed from Rust, but in contrast to Rust there is no borrow checker in Garble, which makes the language very easy to pick up even for non-Rust developers. Garble is statically typed and supports structs, enums and pattern matching. Before looking at the language semantics in more detail, here is a snippet of Garble to compute the millionaires' problem mentioned above:
As you can see, the code looks like an ordinary Rust program. In fact, Garble is practically a subset of Rust, except that there is no borrow checker and all values in Garble are conceptually always cloned, even large arrays. There is no garbage collection either, values always "stay around" (for as long as they are in scope). This might sound incredibly inefficient, but is a consequence of the computational model of garbled circuits, which are boolean circuits without any notion of main memory, stateful latches or any looping construct. All values in such a boolean circuits are just a collection of binary "wires" in the circuit, which can be connected to an arbitrary number of other gates. There is nothing that could be garbage collected, because there is no memory that could be overwritten, it is boolean gates all the way down.
As a result, garbled circuits cannot represent arbitrary programs which might loop endlessly. Instead, circuits express terminating functions and are Turing-incomplete. This is one of the reasons why we chose to implement a custom programming language instead of using something off the shelf: A general purpose language such as Rust contains constructs such as loops or recursion that are potentially unbounded, with the exact number of iterations depending on values only known at runtime. In contrast, Garble deliberately only supports bounded recursion, with loops over fixed-size arrays or ranges.
Apart from being compiled to garbled circuits, here are some other reasons that differentiate Garble from other languages:
- practically a (pure) subset of Rust
- static types, structs, enums, pattern matching
- no crate dependencies (even serde is optional)
- runs on WASM in addition to native architectures
At the moment, the only way to execute Garble programs is by using the binary shipped inside the crate, which you can install using cargo install garble-lang.
We are currently working on an SMPC engine that can run Garble programs and will release it as open source as soon as it has reached a usable alpha state. If you want to learn more about Garble in the meantime, head over to the repository or check out the language tour. We are building the language primarily for our own use, so some of the documentation might still be a bit rough. Please reach out if anything is unclear or if you would like to contribute to the language in any way.
Additionally, if (non-blockchain) cryptography, governance mechanisms and sustainability sound interesting and you are looking for work as a cryptographer / protocol engineer, we are hiring. Even though we are a non-profit, we believe that employees should be compensated fairly and transparently, so all our job descriptions list salary ranges and are based on a 4 day work week.
[1]: The millionaires' problem does raise another question, however: How do you guarantee that both millionaires are telling the truth? Such a question is outside the purely mathematical scope of SMPC, but becomes extremely relevant when you want to actually use SMPC in practice. It is fundamentally an issue of trust and cannot be solved with cryptographic techniques alone, instead requiring governance mechanisms that incentivize the different parties to tell the truth. This is why we believe that SMPC and cryptography are just one side of the coin and why we are actively working on truth-telling mechanisms.