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
10010101010
Key
10010101001
Verifier
Signer’s identity
Public
Signer Key
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
10010101010
Key
10010101001 VERIFY
Verifier
Signer’s identity
Public
Signer Key
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

10010101010
Key NUMBER
10010101001 VERIFY
Verifier
Signer’s identity
Public
Signer Key
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
Share 1

Share 2

Share 3

10010101001 VERIFY NUMBER

Verifier
Group’s identity
Public
Signer Signer Signer Key
Verifier

THRESHOLD GROUP SIGNATURE VERIFIERS

Whatever subset (threshold) of group sign still same signature
Shared seed data
(“message”)
Share 1

Share 3
01010101010
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
Signer Signer Signer Key
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
TIP 2 You don’t need to understand this - Public key: P = xQ2 2 G2
crypto to understand the remaining slides…
Signing
Parameters - Message hashed to H(m) 2 G1
- Two groups G1 , G2 of prime order r
 - Signature: s = xH(m) 2 G1
(on two elliptic curves)
- Generators Q1 2 G1 , Q2 2 G2 Verification e(s, Q2 ) = e(H(m), P ) ?
- Bi-linear pairing e : G1 ⇥ G2 7! GT 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”)

h+1 h
G = G[ mod |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 = G[ mod |G|]
Group members at h broadcast signature shares
h

BROADCAST

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

SIGNATURE

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

=)
h+1 h
G = G[ mod |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 Blockchain 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 (F aulty 200)
Processes

Faulty

(Correct)
10,000

3,000

7,000
1e 17
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
must broadcast “signature shares”
on the message that can be
combined. Here is a typical packet
carrying a signature share.
transfer. However, only 17 KB (half
the messages) are required to
construct the signature. Thereafter
signature shares are not relayed, so
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 fork. 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 Ethereum) blockchain
At each height, the randomness orders the processes…
VRF
h 3

P0xA19...

P0x9E3...

P0x11F...

P0x402...
At each height, the randomness orders the processes…
VRF
h 3 h 2

P0xA19... P0x8C2...

P0x9E3... P0x398...

P0x11F... P0x2DA...

P0x402... P0x7A5...
At each height, the randomness orders the processes…
VRF
h 3 h 2 h 1

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

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

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

P0x402... P0x7A5... P0x904...

At each height, the randomness orders the processes…
VRF
h 3 h 2 h 1 h

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

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

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

P0x402... P0x7A5... P0x904... P0x3E1...

Indexes are priority “slots” for forging (zero highest)
VRF
h 3 h 2 h 1 h

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…
VRF
h 3 h 2 h 1 h

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
VRF
h 3 h 2 h 1 h

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 blockchains that converge
h 3 h 2 h 1 h
BEST 1
5s 1pt PARENT
3 pts
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 h
p2G
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 valid and
Block @ h Broadcast sig. Sign the best
higher scoring P’s SLOT
received from P 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

D
EA
2

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

2
D

No alternative chain head
 The trap shuts!

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

Fast Optimal Avg. Finality Addresses Key Challenges Quantifiable finality

Hooks make possible
BLOCK T IM E = 5s - Selfish Mining calculate probabilities more
=) - Nothing At Stake
meaningfully

7.5s
SPV
- Equivocation Light client needs only
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

Gas available ---

Poisson distribution
50X+ Ethereum
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
Bitcoin 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 r Consensus
esistan
io n c e
i d a t Sybil
Va l State storage Validation
Conse resistance
nsus
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.

(T X, ReadT X , 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
- Threshold Relay + PSP
- Blockchain Nervous
System (BNS)
- Security deposits
- State-root-only-chain
(transaction logging not
necessary)
2 ZINC 3 TUNGSTEN
- Special features enabling - State sharding (basic)
creation robust and high
performance private - Validation Towers (basic)
networks using unlimited
host computers
- Asynchronous model for
cross-shard programming
- Single atomic call from
smart contract on private
- USCIDs

cloud into smart contract (Unique State Copy IDs)
on public cloud network
- Advancements in BNS
President/Chief Scientist DFINITY Stiftung http:// twitter.com /dominic_williams
President/CTO String Labs http:// linkedin.com /in/thedwilliams/

The Decentralized
Cloud