Partially homomorphic encryption is ridiculously under-utilized.

It opens up a massive swath of use cases via strong concurrency and minimal data leakage.

And you can get it with just 256 lines of circom.

...

founder @seismic // product-focused cryptography // rookie years @ stanford, google

The simplest way to tap into this is via Pedersen Commitments. Calling the Pedersen func PD() here.

They're hiding + additively homomorphic. Means that the following two properties hold.
[1] Hard to recover 5 given PD(5)
[2] PD(2) + PD(5) = PD(7)

Why is this useful?

Easy to way demonstrate is with the encrypted balances example.

Suppose [Alice, Bob, Charlie] all have wallets with $30 in USDC as encrypted balances.

Observers CAN see 1) who has USDC and 2) who transfers USDC to who. Observers CANNOT see how much.

Let's say both Alice and Bob want to pay Charlie $5.

Fairly doable to see how we can do this with a quick ZKP.

Alice / Bob can submit a ZKP that asserts "my new balance is $25 and Charlie's is $35".

This works, but has two problems.

[2] Counterparty data leakage.

Notice both Alice and Bob must know Charlie's balance to pay him.

Defeats much of the purpose of encrypted balances.

You must leak initial state to counterparties if you're using just ZK.

Fix?

Instead of using a ZKP to modify balances, Alice / Bob should send a tx that adds PD(-5) to their balance and PD(5) to Charlie's.

So the statement goes from "my new balance is $25 and Charlie's is $35" to "my new balance is $5 less and Charlie's is $5 more".

Concretely

INITIAL STATE
> Alice: PD(30)
> Bob: PD(30)
> Charlie: PD(30)

FINAL STATE
> Alice: PD(30) + PD(-5) = PD(25)
> Bob: PD(30) + PD(-5) = PD(25)
> Charlie: PD(30) + PD(5) + PD(5) = PD(40)

Works because PD() is hiding + additively homomorphic.

Speaking in diffs instead of updates solves both problems:

[1] Weak concurrency. The second diff to land is still valid since it doesn't rely on a specific snapshot of initial state.

[2] Data leakage. Alice / Bob doesn't need to know Charlie's balance to describe the diff.

This is why partially homomorphic encryption, PD(), is so powerful.

Best part? Can be done using a 256-line, audited, circom template.

You don't need FHE, MPC, or any other 3 letter acronym.

Crazy to me that we don't see more dapps that use this production-ready, grokkable, powerful concept.

Shoutout to two systems that use this today:
> @monero, the encrypted balances discussed here.
> @penumbrazone, for batch swaps. They use PD() to fix problem #1. They don't need to fix problem #2 since pool parameters are public.


Excited to see many more examples spring up as people learn about how practical partially homomorphic encryption is.

We're pushing a few out ourselves. Will share soon!

[1] Weak concurrency.

What if both payments are submitted in the same block?

Suppose Alice's tx is ordered first. Then, Bob's would fail because Charlie's balance should now go from $35 to $40, not $30 to $35.

Two concurrent txs can't modify the same value using just ZK.