Results​

Note: Versions 0, 1, 2 are running all parties on a single thread, which isn't realistic, but the relative improvements are real. Version 3 fixes this, providing numbers that are relevant to real deployments.

Above: Video of the host when running JumboSwap locally in 5 tabs.

IO Buffering​

MPC Framework provides an abstraction for IO so that you can supply any transport for moving bytes between the parties. When I originally created emp-wasm, I did the IO in a pretty naive way - when the C++ code wants to send some bytes, it sends that to JS immediately so that JS can send on the websocket/etc. Now C++ will buffer up to 64KiB before passing it to JS, and this makes a huge difference (see v0->v1 in the sha1 results graph).

Importing Circuits​

emp-toolkit provides a bristol circuit parser using C++'s istringstream. When we compile this to WebAssembly using Emscripten, it's very very slow. So slow that it's much faster to use JS to parse and encode the bristol into binary, and send that binary to C++ instead. For the 2.4MiB sha1 circuit, this reduces the circuit loading time from 1500ms to under 100ms.

In future, I think this space will benefit from a much better standard format for circuits. It's actually a bit silly that we have Summon going to the trouble to serialize the circuit into this verbose format and then emp-wasm has to spend time parsing it. Bristol format also lacks real descriptions for its input and output bits, which is why we currently provide metadata separately - circuit_info.json.

I hope that in the not-too-distant future we can unify these into a single compact circuit format. This will improve speed and reduce complexity. Even if you want a readable format for debug purposes, we could provide something much better than Bristol. We should treat Bristol as a legacy format and provide backwards compatibility by providing a Bristol serializer that is only used when necessary.

Join Us!​

• Telegram group
• Discord (Channel name: 🔮-mpc-framework)
• Github Repo ⭐️
• Website

Thanks for building privacy‑preserving magic with us! 🪄

Importing Circuits​

This is part of a broader feature to translate any Bristol circuit into Summon. You can now do that like this:

# in the summon repo
cargo run --bin bristol_to_summon -- -i sha256.txt -o sha256.ts

The Bristol circuit used defines the core of Sha256 which takes a 512-bit block and a 256-bit state and outputs a new 256-bit state. In Summon we can take that a step further by implementing the static padding and block splitting so that we can simply provide the complete Sha256 function rather than just the core mechanism.

Why​

Adding this enables MPC use cases that need verified data. Our current vanilla demos allow you to input anything you like. With a hash function like Sha256, we can ensure that inputs correspond to hashes:

if (!bitsEqual(hash(input), knownHash)) {
  throw new Error('failed hash check');
}

To make this a little more concrete, suppose input is provided by Alice. Bob knows hash(input), but input is Alice’s secret. Enforcing hash(input) effectively enforces input itself - it’s computationally infeasible for Alice to find evilInput such that hash(evilInput) == hash(input), so Alice has no choice but to provide her genuine input if she wants to participate in an MPC protocol that contains this check.

This is particularly useful for signed data. Signature algorithms are typically structured as sign(hash(input)), rather than simply sign(input) (and hash is very often Sha256). This means Bob can learn that hash(input) represents a correctly signed hash without learning input itself, which means we don’t need to do the signature algorithm inside MPC. In short, we verify the signature outside MPC, then verify the hash inside MPC, which is great for both simplicity and efficiency.

Performance​

In-browser 2PC calculation of sha256('summon') was achieved in 2.4s. The chart below shows how this grows with more parties.

Note:

• This measures a single sha256. If you need a sha256 for each party (eg to verify the inputs of all parties), you'll need to (roughly) multiply these results by the number of parties.
• Each party is running in a web worker. Better results should be possible by running each party on a separate device, especially for large party sizes.
• This local test has negligible latency. Adjust by adding about 20x your ping time (a flat cost that does not grow with parties or gates).

Fun Fact​

Prior to this change, in the bytecode that Summon uses internally, addresses were 16-bit. Sha256 broke that, because it produced bytecodes that were longer than 2^16 bytes (64KiB) for the first time. Summon bytecode now uses 32-bit addresses.

Join Us!​

• Telegram group
• Discord (Channel name: 🔮-mpc-framework)
• Github Repo ⭐️
• Website

Thanks for building privacy‑preserving magic with us! 🪄

1 · Streamlined IO with Summon.IO​

Before​

export default function main(a: number, b: number) {
  const plus = a + b;
  const gt = a > b;

  return [plus, gt];
}

// and separately provide mpcSettings:
const mpcSettings = [
  {
    name: 'alice',
    inputs: ['a'],
    outputs: ['main[0]', 'main[1]'],
  },
  {
    name: 'bob',
    inputs: ['b'],
    outputs: ['main[0]', 'main[1]'],
  },
];

After​

export default function main(io: Summon.IO) {
  const a = io.input('alice', 'a', summon.number());
  const b = io.input('bob', 'b', summon.number());

  io.outputPublic('plus', a + b);
  io.outputPublic('gt', a > b);
}

// mpcSettings is generated automatically

Shorter, self‑contained, and each output has a real name.

Per-party outputs are also coming, and will fit neatly into this API: io.output(partyName, outputName, value).

Type information is available via summon.d.ts:

2 · Typed Inputs (now with bool)​

The third argument of io.input specifies the type:

bools now work properly, so you can pass true/false instead of 1/0. This is both better devX and removes unnecessary bits.

Output bools are also new, decoding correctly as true/false (the values you get out of await session.output()).

This also sets us up to support arrays/etc and grow into comprehensive typing à la zod or io‑ts.

3 · Public Inputs​

Need a single program that adapts to many input sizes/participants? Public inputs let you accept these at compile time:

const N = io.inputPublic('N', summon.number());
let votes: boolean[] = [];

for (let i = 0; i < N; i++) {
  const vote = io.input(`party${i}`, `vote${i}`, summon.bool());
  votes.push(vote);
}

// Now calculate something from `votes`
// Eg majority, 2/3 majority, etc

Pass them via CLI:

summonc program.ts \
  --public-inputs '{ "N": 10 }' \
  --boolify-width 8

or the summon-ts API:

const { circuit } = summon.compile({
  path: 'program.ts',
  boolifyWidth: 8,
  publicInputs: { N: 10 },
  files: { /* ... */ },
});

See it in action: JumboSwap circuit.

4 · Faster Branch Merging​

Merging has to occur whenever your program branches on signals:

const value = cond ? x : y;

Circuits can't evaluate only one side of this like CPUs do, so the Summon compiler has to emit wires for both branches and then merge them together like this:

value = merge(condA, x, condB, y)
//    = (condA * x)  +  (condB * y) // old method
      = (condA * x) XOR (condB * y) // new method

So, + became XOR which is great because XOR is almost free, but why is this allowed?

The key is that condA and condB cannot be true simultaneously. In this example we have condB == !condA, but we don't have to rely on that. These conditions are always non-overlapping - there is only ever one "real" branch with cond == 1. This means each bit of the addition cannot produce a carry and is equivalent to XOR, because XOR is 1-bit addition.

This caused some real speedups in our demos:

• JumboSwap: ≈4× faster
• Lizard‑Spock: ≈20 % faster

Join Us!​

• Telegram group
• Discord (Channel name: 🔮-mpc-framework)
• Github Repo ⭐️
• Website

Thanks for building privacy‑preserving magic with us! 🪄

To be a bit more specific:

• Does a relatively simple obfuscator exist which can take any boolean circuit and produce an obfuscated version which behaves the same way and is resilient against attempts to simplify it back to the input circuit? (Or some other circuit of similar/smaller size.)
• As a simple test case of any candidate obfuscator, if we use it to obfuscate a circuit which simply tests the input against a specific bit string (a single output bit producing 1 when matched, 0 otherwise), could an adversary identify the bit string?
  • If we allocated one minute of CPU to a 128-bit obfuscation, how long would an efficient attack implementation need to find those 128 bits? Minutes? Days? Basically forever?
  • (Related: Boolean Satisfiability Problem)

If you find this interesting, you might also like Summon - a TypeScript-like language for authoring boolean circuits, and the MPC Cryptography that we use it for.

🤔 Why​

This would achieve (and exceed?) indistinguishability obfuscation (iO), which is kinda like the final boss of cryptography. We could reimplement basically all (all?) existing cryptography on top of iO, as well as more things that we can't currently do.

🚫 Provable Security​

I think it would be unfair to reject this idea because it is not provably secure. Prime factoring and the discrete logarithm problem are not proven secure either, we just think they are because very smart people have tried very hard and failed. They are security assumptions.

Perhaps a boolean obfuscator could rest on top of one of those well-respected security assumptions, but I'm more interested in the possibility that we could simply add it as a new security assumption. It may be worth debating whether a new security assumption is a good idea, but I'd contend that a simple boolean obfuscator which stands up to powerful attempts to break it would be, at the very least, extremely interesting.

🤯 Isn't this Security by Obscurity?!​

Maybe! Perhaps the deeper question is whether obscurity actually can work. Of course obscurity can fail—but does it always?

It depends on how you define obscurity. If it means providing an opaque program without revealing how it was constructed, then I’d argue this approach doesn’t qualify. On the contrary, it follows the principle of transparent security: we publish the obfuscator, invite public scrutiny, and only consider it viable if it withstands real-world attempts to break it.

So the security claim isn’t “nobody knows how this works” but rather “even when you know exactly how it works, it still seems hard to undo.”

💡 Possible Implementation​

1. Build a grouping of equivalent subcircuits by exploring all circuits of some manageable size and group them by equivalent results (two circuits are equivalent if they have identical input-output tables). (This is a general step that can be done once and embedded in the obfuscator for use with any circuit.)
2. Randomly sample subcircuits from the input circuit and replace them with random equivalents. Repeat until (say) 90% of wires are affected. (This ensures there will be many overlapping substitutions that aren't trivially reversible with the same process.)
3. Simplify. Apply the best known techniques for simplifying circuits. (But only with a modest amount of compute.)
4. Repeat steps 2 and 3 some amount of times.

Note: Step 2 is expected to expand the circuit, since there are many more large equivalent subcircuits than there are small ones. Step 3 contracts the circuit, but presumably not as much. A concrete implementation might repeat steps 2 and 3 until some expansion factor is achieved.

🦀 Implementation Advice​

We like rust. A proposed implementation would ideally be a rust program which takes a file representing a circuit in Bristol Format and outputs a file in the same format. Parameters (like how many rounds) would ideally be CLI arguments, but could also be provided via a json or toml file.

We also like TypeScript. I'd love to see any attempt at this really.

Let us know on Telegram / Discord / GitHub

⚔️ Contrary Views​

I will try to summarise the best contrary views here as people submit them.

• On the (Im)possibility of Obfuscating Programs (Barak et al, 2001)
  • I found this by talking to ChatGPT.
  • From what I can tell, this paper applies to a very strict black box property which doesn't really apply to the idea here.
  • I suppose it proves that obfuscation can't be a perfect black box, but I don't think it's necessary to be a perfect black box.
  • I think the bit-string test case is a better representation of whether you can extract useful information from the obfuscated program. This paper doesn't appear to show that there is a way to get any of the bits from that bit string, but I could be wrong.
  • From the paper: "Our work rules out the standard, 'virtual black box' notion of obfuscators as impossible, along with several of its applications. However, it does not mean that there is no method of making programs 'unintelligible' in some meaningful and precise sense."

But first — what is Trinity, and why should you care?

🧠 A Classic 2PC Flow​

Let’s start with a traditional secure two-party computation (2PC). Say Alice and Bob want to compute a + b, without revealing their private inputs a and b to each other.

This is typically done using:

• Boolean circuits: The computation is expressed as a sequence of logic gates (AND, OR, XOR, etc.). For example, adding two 8-bit numbers becomes a gate-level network, where each input bit is a wire. You can check out Summon for great examples.
• Garbled Circuits (GC): One party (the garbler) encrypts the entire circuit. Each wire in the circuit gets two cryptographic labels (representing 0 or 1), and the circuit gates are encrypted so that only the correct output label can be unlocked, step by step. The other party (the evaluator) evaluates this encrypted circuit without ever seeing the real bits.
• Oblivious Transfer (OT): The evaluator (Alice) needs to receive just the labels corresponding to her input bits — but without revealing those bits to the garbler.

Classical OT Construction​

In most traditional protocols, OT is built using public key cryptography.

Let’s say Alice has an input bit a ∈ {0,1}:

• Bob (the garbler) prepares two labels for Alice’s input wire: one for 0 and one for 1.
• Alice runs an OT protocol to retrieve only the label that corresponds to her bit, without revealing it.
• This typically involves public key operations where Bob encrypts both labels, and Alice can only decrypt one.

Together, these steps let two parties jointly compute a function without revealing their inputs.

✨ Enter Trinity​

Trinity follows the same broad structure — but introduces key innovations to make the flow more modular, more verifiable, and better aligned with ZK tooling.

Specifically, Trinity leverages:

• 🔑 Laconic OT: Based on the Witness Encryption for KZG paper, Trinity replaces traditional OT with a KZG-based commitment scheme.
• 📦 KZG Commitments:
  • Alice commits to her input using a polynomial commitment (KZG), without targeting Bob specifically. These commitments are reusable across sessions or peers.
  • Since some ZK provers (like Halo2) use KZG already, this means Alice can also prove her committed input in zero-knowledge — if she wants.

In short, Trinity lets you garble circuits in the usual way, but with reusable, verifiable inputs — perfect for privacy-preserving apps, on-chain protocols, or even MPC-enabled credentials.

Now let’s see how to build with it.

Setup​

We need to write our 2PC circuit first, thanks to Summon is going to be super easy. Here we are going with a very simple add circuit, adding Alice and Bob numbers.

export default function main(a: number, b: number) {
  return a + b;
}

In the next snippet, we're going to initialise the trinity library and parse our circuit, so it can be consumed by both the garbler and the evaluator.

import * as summon from "summon-ts";
import getCircuitFiles from "./getCircuitFiles";
import { initTrinity, parseCircuit } from "@trinity-2pc/core";

export default async function generateProtocol() {
  await summon.init();
  const trinityModule = await initTrinity();

  const circuit = summon.compileBoolean(
    "circuit/main.ts",
    16,
    await getCircuitFiles()
  );

  const circuit_parsed = parseCircuit(circuit.circuit.bristol, 16, 16, 16);

  return { trinityModule, circuit_parsed };
}

🧬 Trinity in Action: Evaluator → Garbler → Evaluation​

Evaluator Commitment Phase​

The first phase of the protocol requires the evaluator, here Alice, to commit to its input. For the sake of the example we're going to use the Plain setup (vs. Halo2, who's using full purpose ZK), performing a plain KZG commit.

// Call to the protocol generator we described above
const protocol = await generateProtocol();
// Create a Setup for our KZG protocol.
// Note: For a production setting, these keys should be generated and published.
// It should not be generated on the fly like in this example.
const trinitySetup = protocol.trinityModule.TrinityWasmSetup("Plain");
// Create an instance of a Trinity Evaluator
// and will generate the commitment to Alice's input.
// number: Alice's number a
const evaluator = protocol.trinityModule.TrinityEvaluator(
  trinitySetup,
  intToUint8Array2(number)
);

Now Alice can send both the parameters for the KZG setup and the commitment to her input.

const newSocket = await connect(code, "alice");

newSocket?.send(
  JSON.stringify({
    type: "setup",
    setupObj: Array.from(trinitySetup.to_sender_setup() || new Uint8Array()),
  })
);

newSocket?.send(
  JSON.stringify({
    type: "commitment",
    commitment: evaluator.commitment_serialized,
  })
);

Garbler Phase​

Bob has now received both the setup parameters and the commitment. He can now garble the circuit to encrypt his own input.

// Instantiate the Trinity wasm library
const protocol = await generateProtocol();
// Connect sockets
await connect(joiningCode, "bob");
// Get the messages from Alice
const setupMessage = (await msgQueue.shift()) as SetupMessage;
const setupObj = new Uint8Array(setupMessage.setupObj);
const commitmentMessage = (await msgQueue.shift()) as CommitmentMessage;
const commitment = commitmentMessage.commitment;

// Instantiate KZG setup from evaluator's setup
const garblerSetup = TrinityWasmSetup.from_sender_setup(setupObjValue);
// Instantiate a Trinity Garbler from the commitment and Bob's input
const garblerBundle = protocol?.trinityModule.TrinityGarbler(
  commitmentValue,
  garblerSetup,
  intToUint8Array2(number),
  protocol.circuit_parsed
);
const serializedBundle = Array.from(
  new Uint8Array(garblerBundle?.bundle || [])
);
// Send back the garbled data
socket?.send(
  JSON.stringify({
    type: "garblerBundle",
    garblerBundle: serializedBundle,
  })
);

Evaluate the circuit​

Now Alice can receive the garbeld data from the Bob and evaluate the circuit. Note that the process is assymetric, and only Alice evaluate the circuit on here side and can send back the result to Bob.

// Receiving serialized Garbled data
const bundleArray = new Uint8Array(parsedMsg.garblerBundle);
// Reconstructing Garbled data
const bundle = TrinityGarbler.from_bundle(bundleArray);
// Evaluate our circuit
const resultBytes = currentEvaluator.evaluate(
  bundle,
  currentProtocol?.circuit_parsed
);
// Get the result
const result = booleanArrayToInteger(resultBytes);

🚀 What’s Next?​

This is a minimal example — but Trinity supports:

• Integration with ZK (via Halo2, Noir soon 👀)
• More complex circuits (via Summon)

Check out mpc-hello and trinity to dive deeper, or come chat with us in PSE Discord!

This afternoon I added summon.isSignal(x) to the Summon language. It's just a little ground work towards our larger goal of improving the DevX for getting values into and out of your circuits, but I think it's a good case study for hacking on Summon.

Note: At the time of writing, this change only exists in the main branch of Summon. If you're using summon-ts, it may or may not be released when you read this.

summon.isSignal(x) is defined in the new summon.d.ts:

declare const summon: {
  isSignal(value: unknown): boolean;
};

Just copy summon.d.ts into your circuit project, and you can use it like this:

export default (x: number) => {
  let count = 0;

  if (summon.isSignal("hello")) {
    count++;
  }
  // 'hello' is not a signal, count: 0

  if (summon.isSignal(count)) {
    count++;
  }
  // `count` is not a signal, count: 0

  if (summon.isSignal(x)) {
    count += x;
  }
  // `x` is a signal, count: x

  if (summon.isSignal(count)) {
    count++;
  }
  // `count` is a signal, count: x + 1
  // (even though it wasn't before)

  return count;
};

Here's the code for summon.isSignal:

static IS_SIGNAL: NativeFunction = native_fn(|_this, params| {
  let Some(x) = params.first() else {
    return Ok(false.to_val());
  };

  Ok(val_dynamic_downcast::<CircuitSignal>(x).is_some().to_val())
});

If you want to write some code in rust and incorporate that into a Summon circuit, you could put some other rust code here like this:

static IN_UNIT_CIRCLE: NativeFunction = native_fn(|_this, params| {
  let (
    Some(Val::Number(x)),
    Some(Val::Number(y)),
  ) = (
    params.first(),
    params.get(1),
  ) else {
    return Err("Expected x, y to be numbers".to_type_error());
  };

  let res = x * x + y * y <= 1.0;

  Ok(res.to_val())
});

you also need to add this:

fn bo_sub(key: &str) -> Val {
  match key {
    "isSignal" => IS_SIGNAL.to_val(),
    "inUnitCircle" => IN_UNIT_CIRCLE.to_val(), // <--- add this line

    _ => Val::Undefined,
  }
}

now just cargo build and voila, you can use it like this:

// Use vstc to run programs that don't need signals:
//   ./target/debug/vstc run program.ts

export default () => {
  console.log(summon.inUnitCircle(0.3, 0.4)); // true
};

Check the PR for the full context. Happy hacking :].

About​

After picking docusaurus, we decided we liked the look of https://eightshift.com/.

Happily, their website is open source, so I copied the code, included them in our LICENSE, and have just had to tweak it for our needs.

I'm a little disappointed TypeScript isn't used. I don't really do plain JS these days. Hopefully we'll upgrade this repo to use TypeScript later.