INTRODUCING DFINITY Crypto Techniques

V1 - 19th May 2017 Threshold Relay Produce randomness that is incorruptible, unmanipulable and unpredictable BACKGROUNDER Explain “unique deterministic” threshold signatures… Usually a signer creates a signature on message data

Shared seed data (“message”)

01010101010 11010111011 01010101010 10101001010

Verifier Signature SIGN 10101010101 Private 00101101010 Key 10010101010 10010101001 Verifier Signer’s identity Public Key Signer Verifier

AUTHORIZED SIGNER SIGNATURE VERIFIERS That can be verified using the signer’s public key

Shared seed data (“message”)

01010101010 11010111011 01010101010 10101001010

Verifier Signature

SIGN 10101010101 Private 00101101010 Key 10010101010 10010101001 VERIFY Verifier Signer’s identity Public Key Signer Verifier

AUTHORIZED SIGNER SIGNATURE VERIFIERS If scheme unique and deterministic then only 1 correct signature

Shared seed data THE SIGNATURE IS A RANDOM NUMBER, AS IF (“message”) IT WERE PREDICTABLE, THE SIGNATURE SCHEME WOULD NOT BE SECURE 01010101010 11010111011 01010101010 10101001010

Verifier Signature

SIGN 10101010101 DETERMINISTIC Private 00101101010 RANDOM Key 10010101010 10010101001 VERIFY NUMBER Verifier Signer’s identity Public Key Signer Verifier

AUTHORIZED SIGNER SIGNATURE VERIFIERS Unique and deterministic threshold signature scheme possible

GROUP MEMBERS INDEPENDENTLY SIGN THE Shared seed data MESSAGE TO CREATE “SIGNATURE SHARES”. (“message”) A THRESHOLD NUMBER ARE COMBINED TO CREATE THE OUTPUT SIGNATURE 01010101010 11010111011 01010101010 10101001010

Verifier Signature

SIGN SIGN SIGN COMBINE 10101010101 DETERMINISTIC 00101101010 RANDOM 10010101010 10010101001 VERIFY NUMBER Share 1 Share 3 Share 2 Verifier Group’s identity Public Key Signer Signer Signer Verifier

THRESHOLD GROUP SIGNATURE VERIFIERS Whatever subset (threshold) of group sign still same signature

Shared seed data (“message”)

Share 1 01010101010 Share 3 11010111011 01010101010 Signer Signer Signer 10101001010 Verifier Signature Share 4 Share 5 COMBINE 10101010101 DETERMINISTIC 00101101010 RANDOM Signer Signer Signer 10010101010 10010101001 VERIFY NUMBER Verifier Group’s identity Share 7 Share 9 Public Key Signer Signer Signer Verifier

THRESHOLD GROUP SIGNATURE VERIFIERS Important observations of powerful magic

1. A group identified by its threshold public key can only produce a single valid output signature on given seed data

Verifier

DETERMINISTIC RANDOM NUMBER Verifier

Verifier Important observations of powerful magic

1. A group identified by its threshold public key can only produce a single valid output signature on given seed data

2. A group is fault tolerant and any subset of threshold size can distribute signature shares for combination into the signature Verifier

DETERMINISTIC RANDOM NUMBER Verifier

Verifier Important observations of powerful magic

1. A group identified by its threshold public key can only produce a single valid output signature on given seed data

2. A group is fault tolerant and any subset of threshold size can distribute signature shares for combination into the signature Verifier 3. The resulting threshold signature can be validated by anyone who has the group’s public key and the seed data DETERMINISTIC RANDOM NUMBER Verifier

Verifier Important observations of powerful magic

1. A group identified by its threshold public key can only produce a single valid output signature on given seed data

2. A group is fault tolerant and any subset of threshold size can distribute signature shares for combination into the signature Verifier 3. The resulting threshold signature can be validated by anyone who has the group’s public key and the seed data DETERMINISTIC RANDOM 4. The signature is a deterministically produced random number NUMBER Verifier

Verifier Important observations of powerful magic

1. A group identified by its threshold public key can only produce a single valid output signature on given seed data

2. A group is fault tolerant and any subset of threshold size can distribute signature shares for combination into the signature Verifier 3. The resulting threshold signature can be validated by anyone who has the group’s public key and the seed data DETERMINISTIC RANDOM 4. The signature is a deterministically produced random number NUMBER Verifier 5. Given a group’s public key and the input seed data the verifiers reach immediate consensus on the random number produced without running a consensus protocol… Verifier A unique deterministic threshold signature scheme Boneh-Lynn-Shacham signatures (BLS)

TIP 1 Ben Lynn is a full time member of the Key Generation DFINITY team - Secret key: x mod r - Public key: P = xQ G TIP 2 You don’t need to understand this 2 2 2 crypto to understand the remaining slides… Signing - Message hashed to H (m) G Parameters 2 1 - Signature: s = xH(m) G1 - Two groups G 1 ,G 2 of prime order r 2 (on two elliptic curves) Verification e ( s, Q 2 )= e ( H ( m ) ,P ) ? - Generators Q1 G1,Q2 G2 2 2 - Bi-linear pairing e : G1 G2 GT ⇥ 7! BLS, 2001 (Stanford University) DECENTRALIZED VERIFIABLE RANDOM FUNCTION Relay between groups to create a random sequence A vast peer-to-peer broadcast network of mining clients… Whose public keys are registered on a supporting ledger

PUBKEY 0x1bd1ccf169d755306e077b38cb9aeae28e245351 DEPOSIT: 1000 DFN

PUBKEY 0x9a197453dcface85be2fbe32c8cc19bd30576ee1 DEPOSIT: 1000 DFN PUBKEY 0x2b197453dcfabe85be2fbe31c8cc19bd30576ed0 DEPOSIT: 1000 DFN Each client (“process”) belongs to threshold groups Whose public keys are also registered on the supporting ledger

… GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY 0x7de4ac5… 0x8fb251b… 0x1a7234e… 0x2b197453… 0xb6e1a33… At each height in the sequence, there is a current group…

h That signs the previous group’s signature…

BLS Signature Scheme Their random number selects the next group (the “relay”)

Gh+1 = [h mod ] G |G| The relaying between groups is unmanipulable and infinite This is what Threshold Relay looks like h 1

SIGNATURE

h 1 The signature created at h-1 selects the group at h

h

=) h h 1 G = [ mod ] G |G| Group members at h broadcast signature shares

h

BROADCAST

h,p Gh { p 2 } Collect threshold of shares & create unique group signature…

h

SIGNATURE

h = bls( h,p Gh ) { p 2 } That selects the next group, ad infinitum

h +1

=) Gh+1 = [h mod ] G |G| Producing a decentralized Verifiable Random Function (VRF)

h 7 h 6 h 5 h 4 h 3 h 2 h 1 h , , , , , , , = )

Random number sequence is Deterministic . Verifiable . Unmanipulable

Next value released on agreement a threshold of the current group… Unpredictable

No consensus protocol is necessary! Random numbers should not be generated with a “ method chosen at random - Donald Knuth TLDR; such unmanipulable randomness is powerful…

Decentralized Protocols Decentralized Applications for “Scaling Out” with advanced features

COMING UP… PSP Designs E.g. PHI autonomous loan Validation Towers issuance and crypto “fiat” Validation Trees USCIDs Validate anything… Fair financial exchanges… Lottery Charging Lazy Validation Fault Tolerance Example

NETWORK METRICS P (Faulty 200) Processes 10,000 Faulty 3,000 1e 17 (Correct) 7,000 Probability that a sufficient Group Size 400 proportion of the group are faulty Threshold 201 that it cannot produce a signature Calculated using hypergeometric probability e.g. Note: in practice the probability 30% http://www.geneprof.org/GeneProf/tools/ of professionally run mining hypergeometric.jsp processes “just stop” is very low. Miners will generally deregister IDs Note: groups should expire to thwart to retrieve deposits when exiting. “adaptive” adversaries Communications Overhead Example

MESSAGE FORMAT GROUP SIZE

Process ID 20 bytes Group size 400 Threshold 201 Signature share 32 bytes

Signature on comms 32 bytes COMMUNICATION OVERHEAD

Total 84 bytes Expected 22 KB

In order for a group to produce a 400 messages involve 34 KB of data threshold signature, its members transfer. However, only 17 KB (half must broadcast “signature shares” the messages) are required to on the message that can be construct the signature. Thereafter combined. Here is a typical packet signature shares are not relayed, so carrying a signature share. a more typical overhead is 22 KB. BACKGROUNDER How to setup groups… Clients randomly assigned to groups by randomness (VRF)

… GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY - - - - - Need setup threshold scheme within 1000 blocks using DKG…

Joint Feldman DKG

… GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY - - - - - Successful groups register their Public Key on the ledger

… GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY - - - 0x2b197453… - Setup is independent of blockchain progression…

Joint Joint Feldman Feldman DKG DKG

… GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY - - - 0x2b197453… - And occurs asynchronously

… GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY GRP PUBKEY 0x7de4ac5… 0x8fb251b… - 0x2b197453… - New clients and groups activated in CURRENT_EPOCH + 2

KEY FRAME KEY FRAME KEY FRAME KEY FRAME BLOCK BLOCK BLOCK BLOCK ⇠ 3 ⇠ 2 ⇠ 1 ⇠ CHAIN HEAD

Activation…

GROUP Join tx Join tx 0x2b197453… GROUP CLIENT 0x2b197453… 0x6e22e1ba… CLIENT 0x6e22e1ba…

In choosing the epoch length there are a number of considerations. For correctness, an epoch must minimally contain more blocks than may ever be present in a chain . However, since light clients only require key frame header copies, for reasons of efficiency, epochs may be much longer e.g. one week Probabilistic Slot Protocol Extend the Threshold Relay system to produce a more secure and faster (50X faster than ) blockchain At each height, the randomness orders the processes…

h 3 VRF

P0xA19...

P0x9E3...

P0x11F...

P0x402... At each height, the randomness orders the processes…

h 3 h 2 VRF

P0xA19... P0x8C2...

P0x9E3... P0x398...

P0x11F... P0x2DA...

P0x402... P0x7A5... At each height, the randomness orders the processes…

h 3 h 2 h 1 VRF

P0xA19... P0x8C2... P0x49B...

P0x9E3... P0x398... P0x621...

P0x11F... P0x2DA... P0xB0B...

P0x402... P0x7A5... P0x904... At each height, the randomness orders the processes…

h 3 h 2 h 1 h VRF

P0xA19... P0x8C2... P0x49B... P0xC6A...

P0x9E3... P0x398... P0x621... P0x03E...

P0x11F... P0x2DA... P0xB0B... P0xD1D...

P0x402... P0x7A5... P0x904... P0x3E1... Indexes are priority “slots” for forging (zero highest)

h 3 h 2 h 1 h VRF

SLOT0 P0xA19... P0x8C2... P0x49B... P0xC6A...

SLOT1 P0x9E3... P0x398... P0x621... P0x03E...

SLOT2 P0x11F... P0x2DA... P0xB0B... P0xD1D...

SLOT3 P0x402... P0x7A5... P0x904... P0x3E1...... Value of candidate blocks scored by author’s slot…

h 3 h 2 h 1 h VRF 1pt P0xA19... P0x8C2... P0x49B... P0xC6A... 1 pt 2 P0x9E3... P0x398... P0x621... P0x03E... 1 pt 4 P0x11F... P0x2DA... P0xB0B... P0xD1D... 1 pt 8 P0x402... P0x7A5... P0x904... P0x3E1... Can also introduce block relay rules, e.g. delays

h 3 h 2 h 1 h VRF 5s 1pt P0xA19... P0x8C2... P0x49B... P0xC6A... 1 6s pt 2 P0x9E3... P0x398... P0x621... P0x03E... 1 7s pt 4 P0x11F... P0x2DA... P0xB0B... P0xD1D... 1 8s pt 8 P0x402... P0x7A5... P0x904... P0x3E1... We can create & score that converge

h 3 h 2 h 1 h BEST 1 5s 1pt 3 pts PARENT 4 1 6s pt 3pts 2 1 7s pt 4 1 8s pt 8 Very nice. But usual limitations. O no…

SELFISH MINING NOTHING ATTACKS AT STAKE The adversary can withhold The adversary can go back in blocks to gain an advantage time and create forks from over honest processes. below h to Double Spend.

Selfish mining attacks He only needs to be lucky increase the confirmations and be granted a sequence of necessary for finality. zero slots. Solution?

Threshold groups “notarize” (sign) at least one block at their height before relaying…

A valid block proposed at h must reference a block that was notarized at h-1

Thus, blocks must be published in good time or have no chance of notarization When group selected, its members start their timers…

Triggered by propagation threshold signature p Gh 2 h 1 Members start 1s 2s 3s processing blocks after expiry h 1 BLOCK_TIME. 1s 2s 3s Clocks will be slightly out-of-sync, h 1 but that's OK! 1s 2s 3s Queue blocks score order while waiting BLOCK_TIME

base score base score + + 1 3 pts 3pts 4 PRIORITY QUEUE OF CHAIN HEADS SEEN WHILE WAITING

Highest scoring chain head When BLOCK_TIME expires, witness by notarizing… Group members sign until ≥1 blocks receive threshold signature

NO Is YES Signed Block @ h valid and Broadcast sig. Sign the best higher scoring received from P P’s SLOT share on block blocks seen chain? ready?

Thresh. sig. on block Broadcast sig. Stop signing, HALT at h received share on σ h-1 relay and halt An important observation

In normal operation, if BLOCK_TIME is sufficiently large considering network synchrony, each group member will remove from its queue and process the highest scoring chain head first…

Consequently, the group will ONLY witness (notarize/sign) the block representing the highest scoring chain head

This prevents and immediately collapses forks in normal operation driving extremely high consistency and rapid finality TLDR; tweaking to address the threat of equivocation

A faulty process in SLOT 0 controlled by an adversary might wish to broadcast vast numbers different versions of its block to DOS…

Of course, this faulty process will later be expelled for its provably Byzantine actions, but why provide room for misbehavior…

SOLUTION if process sees equivocated highest scoring block(s), only forward to peers that haven’t detected equivocation yet. If group member sees equivocated highest scoring block, don’t sign it, and instead start signing next highest scoring block seen when from a different slot Fair mining, super high consistency and rapid finality

h 3 h 2 h 1 h 5s 1pt 1 6s pt 2 DEAD 1 7s pt 4 1 Publish immediately or your block loses 8s pt 8 its chance to be notarized and included…. Optimal case. Overwhelming finality in 2 blocks + relay

h 2 h 1 h h +1 5s 1pt 1 Gh+1 RELAY 6s pt 2 DEAD No alternative chain head The trap shuts! or even partially signed chain Now group h+1 has head is visible. Yet, for a relayed it will not viable chain head to exist, it notarize/sign any more must have been shared with blocks. Too late for any some correct processes to alternative chain head at collect signatures, and they h to “appear” and get would have propagated notarized… (broadcast) it… Gains from Notarization

Fast Optimal Avg. Finality Addresses Key Challenges Quantifiable finality Hooks make possible BLOCK TIME =5s - Selfish Mining calculate probabilities more = meaningfully - Nothing At Stake ) SPV - Equivocation Light client needs only 7.5s Merkle root of groups Relative Performance Copper Release

Average 10 mins Average 20 secs Average 5 secs Block Time varies wildly varies wildly low variance

6 confirmations 37 confirmations 2 confirmations+relay “TX finality” (speed) avg. 1 hr avg. 10 mins avg. 7.5 secs Optimal case normal operation Low due to - - - 50X+ Ethereum Gas available Poisson distribution Unlimited scale-out achieved by applying randomness in following techniques… Miscellanea Death By Poisson Process

The Simplest Flaws Are The Worst…

50% of Ethereum blocks are empty !

Miners prefer to build on empty blocks since no need validate/delay = more profitable Could Consume as An empty block has more chance being Much Electricity as Denmark confirmed…. by 2020, Motherboard Duh ! 3/29/2016 Separate and decouple concerns

Proof-of-Work Blockchain DFINITY

Sybil resistance Consensus Sybil ValidationState storage Validation Consensus resistance State storage

TCP/IP

Application Computer Science should not go out of fashion Transport Internet Network Access “Scale-out” using 3-layer architecture CONSENSUS Threshold Relay chain generates randomness and records network metadata and STATE ROOT Validation Tree “state root”.

RANDOM BEACON DRIVES TREE VALIDATION Asynchronous “Validation Tree” composed “Validation Towers”. Does for state validation what Merkle tree does for data.

(TX,ReadTX, S) STORAGE State and updates to state TX stored on shards. State transitions passed to STATE SHARDS Validation Tree. Near Term Client Releases

1 COPPER 2 ZINC 3 TUNGSTEN

- Threshold Relay + PSP - Special features enabling - State sharding (basic) creation robust and high - Blockchain Nervous performance private - Validation Towers (basic) System (BNS) networks using unlimited host computers - Asynchronous model for - Security deposits cross-shard programming - Single atomic call from - State-root-only-chain on private - USCIDs (transaction logging not cloud into smart contract (Unique State Copy IDs) necessary) on public cloud network - Advancements in BNS President/Chief Scientist DFINITY Stiftung http:// .com /dominic_williams President/CTO String Labs http:// linkedin.com /in/thedwilliams/

The Decentralized Cloud