Aleksei Koren and Matthijs Van Den from ING present on DevDay at CordaCon 2019.

1. Have Your Cake and Eat it too
Matthijs van den Bos
Both Privacy + Security with Zero Knowledge Notarisation in Corda
CordaCon 2019, London

2. Is there a problem?
In Corda:
Validating notaries get to see
everything
We want to share our
transaction details on a
need-to-know basis only.

3. What can we do right now?
Use a non-validating Notary
and/or
Confidential identities, etc.
These either solve it partially,
or introduce new issues.
We prefer to have our cake and eat it too!

4. Non-validating Notary: denial-of-state attack
Does NOT validate:
Smart contract rules, or signatures
DOES check if inputs are already
consumed
Attackers can consume any
unspent state they know ref of,
no matter who owns it.
Real owner will be denied use of the state for ever.
Do you want
to run this
risk?

5. So there is a trade-off
We want to share our transaction details on a
need-to-know basis only.
Trade-off:
non-validating: denial-of-state risk
validating: privacy
So can we have our cake
and eat it too?
Privacy Security

6. Solution 1: Ignore!
Pro: it's what we do now
Con: If you close your eyes and don’t
see a problem, a problem still sees you

7. Solution 2: Lawyer up!
Pro: will fix situation eventually
Con: resolution might not be fast
Con: during investigation you will
have to reveal everything
Con: (centralized) arbitration
needed
Con: undefined how to 'revert'
transactions

8. Solution 3: Trusted Hardware (SGX)
Pro: solves everything!
Con: vendor lock-in
Con: more complex development
Fact: need to trust vendor (current
security issues, backdoors)

9. Solution 4: ZKP (no knowledge - no problem)
Pro: solves everything as well
Con: also more complex development
Fact: need to trust global scientific
community
Extra bonus: verifier scalability

10. Non-validating Notary as base. Same privacy, same
checks.
Initiator creates a zero-knowledge proof that:
• for the id of the tx we want to verify,
• they know a matching tx data structure
• that satisfies the smart contract rules
• and that they know the matching signatures
The Notary verifies this proof and is convinced of these
facts.
This prevents Denial of State attack: attacker can no
longer spend a state that they do not own.
Zero-Knowledge Notarisation: Overview

11. /*
* Initiator ZK Notarisation flow
*/
ZKNotaryFlow.Client(SignedTx) {
// The tx we want notarised
val ftx = buildFilteredTx()
// Create proof that we know full tx + sigs
val proof = ZKProof(LedgerTx, sigs)
// Build ZK transaction
val zktx = ZKTx(ftx, proof)
val notarySig = notarise(zktx)
}
Custom Corda Notary + flows
/*
* Custom ZK Notary
*/
ZKNotaryServiceFlow {
// Normal checks
ftx.verify
// Verify ZKP
proof.verify(ftx.id)
signTxAndSend(ftx.id)
}

12. ZK Notarisation: the ZKP toolchain
Setup Once: Notary
1) Translates Corda smart
contract to C (manually at
the moment
😔
)
2) Compiles C code to
libsnark-compatible
R1CS using Pepper
3) Performs trusted setup
for libsnark (spoiler: it’s no
problem!)
4) Distributes prover key
Proving: Tx Initiator
1) From Corda, generates a
proof for tx with libsnark
using prover key, with tx
id as public input and
transaction data and
signatures as secret
input.
Secret input is a
serialised version of a full
LedgerTransaction
Verification: Notary
1) Verifies the proof with
libsnark using verifier
key, with only tx id as
input

13. Pseudo C contract
int prove(pub_tx_id, secret_tx_data) {
// Verify that the tx merkle root == tx.id
if (calculate_merkle_root(secret_tx_data) != pub_tx_id)
return 0;
// Example contract logic: only one input
if (get_input_count(secret_tx_data) != 1) return 0;
// More contract rules here
// Check required signatures
if (!required_sigs_present(secret_tx_data, pub_tx_id))
return 0;
return 1;
}
hash calculate_merkle_root(secret_tx_data) {
// multiple calls to SHA256 gadget
}
int required_sigs_present(secret_tx_data, pub_tx_id) {
// multiple calls to RSA signature verification gadget
}

14. Building a constraint system for contract code
is hard and error prone!
Either by hand, or using compiler like Pepper.
Prover performance:
Contract code will have to be simplified,
to prevent huge constraint systems.
You need hand crafted gadgets for heavy
computations. There are few, and interoperability is an
issue.
For wide adoption, this needs to be simplified.
All very nice, what's the catch?
NOT

15. Corda notarisation trade off: privacy vs. security.
We believe SGX and ZKP can be solutions.
Working on proof of concept for a Zero Knowledge Notary.
This provides both privacy AND security.
Next steps:
• Make more mature and performant
• Simplify toolchain:
• same contract code for non-zkp and zkp verification
• less ZKP tools
• Hopefully convince Corda team to incorporate it :-)
• More ZKP-friendly signature scheme in Corda
Yes, you can have your cake and eat it too!
Interested?
Want to help out?
Come talk to us!

16. Matthijs van den Bos
ING Bank | Distributed Ledger Technology Team
matthijs.van.den.bos@ing.com
Corda Slack: @mvdbos
Links:
• libsnark: https://github.com/scipr-lab/libsnark
• Pepper: https://github.com/pepper-project/pepper &
• Jsnark: https://github.com/akosba/jsnark
Contact details & links

17. Thank you!