Privacy Preserving Smart Contracts… >10yrs in

Beyond ZK workshop

Andrew Miller

UIUC, Flashbots, Cycles

Privacy in smart contracts is an innovation bottleneck

The toolbox of ZK has done a great job of expanding what’s possible, MPC, FHE, and TEE are coming along as well.

These all turn out to be complementary. You will eventually want TEE plus {ZK, MPC, FHE} in your dApp.

TEEs continue to be underappreciated, which I’m trying to fix

This talk: walk through all these in one context

envisioned not just programmable smart contracts, �but smart contracts with privacy

(This is the “ideal world” model from cryptography theory)

Sufficient Motivating Application: Batch auctions

Bid $X, Bid $Y

Updated ledger or state root

View of updated account

Can we do this without revealing residual bids?

Batch auctions are a microcosm of privacy ⇒ strategy

Everywhere there are smart contracts, there are AMMs… and front running

Front-running turns an information advantage into visible effects.

To make a private auction, need to start with private assets

“Shielded Pool:” It turns out, ZKP is sufficient for transfers of digital assets

Sander and Ta Shma, CRYPTO 1999

This vision was continued by BCTGMVZ14 in 2014, the Zcash science paper

Shielded pools are now the standard for privacy… in Zcash & adopted in many others as well.

….

Spend proof:

ZK{(x,r): z = g(x,r),� z is in the list of coins,� i is the Key image….�}

To spend: prove in ZK you know a valid coin w/o revealing which:

z

Public list of coins:

To mint (“withdraw”): Add z to a public list of coins

Sander and Ta Shma, CRYPTO 1999

​

Where ZKP falls short - sequencer has to see everything

Encrypted bids,

ZK proofs

But, the auctioneer must be able to decrypt the transactions in order to apply the auction computation.

ZK proof of Auction function

Hawk: Privacy Preserving Smart Contracts 2016, KMSWP16.

Envisioned not just programmable smart contracts, �but smart contracts with privacy

… via Multi-Party Computation

Three limitations:

1. Performance.. MPC is slow

2. Code is law / contract bugs

3. Fundamental tradeoffs between privacy and fault tolerance

​

MPC tolerates faults, but does nothing about collusion

Encrypted bids,

ZK proofs

A “multisig” of key holder nodes

If a quorum of key holders collude, they could decrypt everything. �Difficult to disincentivize, as it produces no evidence

ZK proof of Auction function

Ratel: MPC-extensions for Smart Contracts (eprint)

Visualization of secret sharing:

MPC: we can compute arbitrary functions over this encoding

K/N trust: we can’t stop key holders from decrypting everything if they collude

Flow chart for the conservative security viewpoint:

Must use a �trusted sequencer, �TEEs, and/or �K-of-N “multisig” MPC

Use ZK, ZK rollup,

Shielded pool

Global private state?

No

Yes

• Even here, we can use TEE as an additional multi-prover.

​

It is also faster for development, so comes down to which you do first.

• Only the use of TEE provides a defense against key holders decrypting all the data

FHE turns I/O bottleneck of MPC into compute tradeoff

Encrypted bids,

ZK proofs

ZK proof of Auction function

No change regarding collusion

Multisig only shows up to decrypt

Untrusted compute does the work

Untrusted compute

How TEEs disintermediate app developers and clouds

TEE Manufacturer

TEE operators

Developers

Inspect evidence

and attestations

Contribute sensitive data

Using TEE as a Co-processor in SUAVE “Sirrah”

Smart Contract

Off-chain & confidential functions

On-chain functions

TEE Kettles

Validators

Users

CIphertexts

xPriv

Attested results

Speedrunning “Ekiden” 2019�CZKHHJJMS19

Use TEE

Use ZK

Use MPC

ZK,MPC,TEE

Design Space

WIP: Global Private State: mapping the design space and consequences

Takeaway: moving from No TEE → TEE is a good tradeoff� if you concerned about collude-to-decrypt risk

We ALL will need ORAM for private data access

We hear a lot about side channels in SGX. We don’t hear about them in MPC or in FHE so much. Why not?

In all of FHE, MPC, and TEE we encounter this… so far only even try in TEE

global public balances;

def checkBalance(private address a) {

return global.balances[a];

​

}

Secure computation on global state

Large dataset

In ZKP, the prover knows these accesses, so just use a Merkle tree

Leaks info about which elements are accessed or not!

We need blockchain native hardware, � with decentralized root of trust

Requirements:

1. Tamper resistance…. e.g., Physically Uncloneable Functions (PUFs)

2. Transparency of hardware design and fab technique

3. Amenable to Destructive analysis

​

Putting these together, we would have hardware that we can randomly test to determine if it’s secure, regardless of who manufacturers

We need blockchain native hardware, � with decentralized root of trust

https://www.acsu.buffalo.edu/~mblanton/cse708/pufs-tutorial.pdf

Randomized destructive analysis

Random sampling for destructive analysis

Significant fraction of network is sampled.

Marked for Destructive analysis

Safe to run Secret Sharing

Follow for more illumination on � Programmable privacy using TEEs

Sirrah: Speedrunning a TEE Coprocessor

​

SGXonerated

More Security research�SGX.Fail

Upcoming SoK on Programmable Privacy (w/ Inversed Tech, Geometry Research)

​

Upcoming Cycles whitepaper: Credit Network using �TEEs and ZK, on Cosmos

​

Talk to Nerla from IC3 at EthDenver

Talk to Tianyao at EthDenver about Oblivious Labs

Thanks!!!

xPriv, xPub

xPub, att

xPub

xPub

Confidential queries run on off-chain EVM coprocessor

ciphertexts

ciphertexts

secondPrice

secondPrice

Ordinary EVM functions run on-chain

Auction end

1

4

att

2

5

Sealed bid Auction using TEE Coprocessor

3

Untrusted�Host

On-chain:

- Validates attestation

- Stores validated kettle addresses and public key

light client verifier

stdin/out

REVM +�precompiles

/dev/attestation

/dev/urandom

Light client proofs

Kettle Enclave

KeyManager.sol

Andromeda.sol

Gramine

​

Off-chain:

- Generate private key

- Retrieve private key

- Generate attestation

Suave Network

suave-geth

kettle.py

Key Holder Singleton

Derived Keys

1. Distributing keys to other Kettles

Key Management starting point

3. Many applications can use shared attestation

KeyManager

Auction App

2. Use attestation once, afterwards use cheaper signatures

Attacker Model: Advanced Kettle Operator

Kettle Operator

Enclave

Goal: wants to interfere with execution, cause to reveal confidential info to trade on

​

Capabilities:

- controls the OS kernel

​

What it can do:

- Control all threads

- Control network packets

- Observes side channels

- Unpin pages (including EPC)

- Receive page faults

​

What the operator can’t see:

- Register values

- Contents of memory pages

- Which cache line is being accessed?