1.
1
Can we safely adapt the construction of
permissionless blockchain to user demand?
Emmanuelle Anceaume (CNRS)
Joint work with
Antoine Durand (IRT SystemX), Romaric Ludinard
(IMT-Atlantique), Bruno Sericola (INRIA)
Journées Futur & Ruptures - January, 31st of January 2019

2.
2
Bitcoin is a cryptocurrency and payment system
• Fully decentralized
• No public key infrastructure
• Permissionless
Such constraints make the general problem of consensus
impossible to solve
• Relies on rational behavior and incentives mechanisms
To reach a consensus on the cryptocurrency state

3.
3
Deconstructing Bitcoin
Transactions
Nakamoto consensus algorithm
Communication network

4.
4
The state of the cryptocurrency system is represented by transactions
• Transfers currency from one user to another
• Does not contain any encrypted information nor confidential
information
Transaction 20ab3701i
Transaction 74201ab3c
UTXO
UTXO = Unspent Transaction Output
Output #2
account + ฿ + script
Output #1
account + ฿ + script
Output #1
account + ฿ + script
Output #1
account + ฿ + script
Input #1
Output ref. + script
Transaction 1206ac34e
Output #2
account + ฿ + script
Output #3
account + ฿ + script
Output #1
account + ฿ + script
Input #1
Output ref. + script
Input #2
Output ref. + script
Input #1
Output ref. + script
Input #2
Output ref. + script
Do not forget Tx fees, i.e., ฿ input ฿ output
UTXO

5.
5
Checking the ownership of an account
• How can anyone check that I am the legitimate owner of an
account since there are no identities in a transaction ?
• Using « public keys as identities » principle 1
• Ownership = knowing a private key that redeems an output
Account / address / UTXO = « single use » object
• debited once
• should be credited once
1. D. Chaum, « Untraceable Electronic Mail, Return Addresses, and Digital
Pseudonums », Communications of the ACM 24(2), pp :84–90,1981

6.
6
Signed transactions guarantee that only the owner of an
output can spend bitcoins
However signatures do not prevent double-spending attacks
• I.e., the fact that Alice spends an output twice
A publicly, immutable, and totally ordered sequence of transactions

7.
7
2. Nakamoto Consensus protocol : Adversary model 2
The Computational Threshold Adversary (CTA) model
• The adversary controls a minority of the total amount of
computational power
• The CTA model is also called the permissionless model
• There is no membership protocol
• Incorporates some degree of synchrony
The Stake Threshold Adversary (STA) model
• The adversary controls a minority stake in some limited
resource, i.e., the crypto-currency
• May allow to punish malicious parties via some stake deposit
2. Ittai Abraham and Dahlia Malkhi, « The blockchain consensus layer and
BFT », The distributed Computing Column, 2017

8.
8
2. Nakamoto Consensus protocol
Two ingredients : Leader Election Oracle + Heavier Fork Strategy
1 A leader election oracle by relying on the PoW mechanism
• Each party is elected independently
• The probability of electing each party is proportional to its
relative computational power
• Each party commits to a single block
→ Synchronize the creation of blocks
→ Prevent Sybil attacks
→ Incentivize correct behavior through currency creation

9.
9
2. Nakamoto Consensus protocol
Two ingredients : Leader Election Oracle + Heavier Fork Strategy
2 The simple and local Heavier Fork Strategy
• Select the chain which required the greatest among of work
• Random nature of the PoW + Non-faulty leaders always use
the chain which required the greatest among of work
→ One chain will be extended more than the others
→ The blockchain
B0 Bi
Bi+1
Bi+1

10.
10
2. Nakamoto Consensus protocol
The goal of the Consensus Nakamoto protocol is to implement a
blockchain replication protocol 3
• (Uniqueness) There is a unique chain of blocks (i.e., the
blockchain) extracted from the tree
• (Liveness) The blockchain is constantly growing
• (Safety) The deeper a block is buried in the blockchain the
harder it is to abort it
• (Fairness) The proportion of blocks of non-faulty parties in the
blockchain is proportional to their computation power
3. J. Garay and A. Kiayias, The Bitcoin Backbone Protocol : Analysis and
Application, Eurocrypt 2015

11.
11
3. Peer-to-Peer Network
• Topology formed through a randomized process
• No coordinating entity
• Broadcast is based on flooding/gossiping neighbors’ link
Tx d - e
Tx a - B
Tx a - B Tx a - B
Tx a - B
Tx a - B
Tx a - B
Tx a - B
Tx a - B
Tx a - B
Tx a - B
Tx d - e
Tx d - e
Tx d - e
Tx d - e
Tx d - e
Tx a - B
Tx d - e
Tx d - e
Tx a - B
Tx a - B
Tx d - e

12.
12
Required properties
1. Connectivity
• Each node should receive any broadcast information
2. Low latency 4
msg. transmission time
block time interval
1
Allows to keep the probability of fork small (i.e. 10−3)
PoW mechanism allows this ratio to continuously hold
Safety requires to wait one hour (i.e., no instant finality)
No more than 7 trans/s can be permanently confirmed in
average ! !
4. J. Garay and A. Kiayias, The Bitcoin Backbone Protocol : Analysis and
Application, Eurocrypt 2015

13.
13
Electing a leader in a permissionless setting
• Proof-of-work
Works in practice and this is true since 2009
Security analysis
Environmental issues
Diminishing returns
Distinction between miners and crypto-currency holders (i.e.,
miners control what is inside blocks)
• Proof-of-work with useful computation, proof-of-space,
proof-of-storage, . . .
Physical resources
• Proof-of-stake
Abstract but limited resource : coin itself
All the required information is already in the blockchain
Numerous attacks

14.
14
Proof-of-stake approaches
Proof-of-stake motto : « The probability for party p of winning the
leader election is proportional to the fraction of currency p owns »
• Eventual-consensus
• Protocols that apply some form of longest-chain rule to the
blockchain
• Immutability of a block increases gradually
• e.g. PPcoin, NXT, Ouroboros, . . .
• Blockwise-BA
• Immutability of a block is achieved by BA before working on
the next one
• e.g. Algorand

15.
15
Proof-of-stake approaches
PoS approaches are subject to attacks 5 essentially because it costs
nothing to create blocks and because of currency transfer from
transacting parties to the parties that maintain the ledger
• Checkpointing mechanisms
• Provide newcomers with a relatively recent block (trust issue)
• Prevent to adopt a new chain that originates to much in the
past (knowledge of the honest chain)
• Key-evolving cryptography : secret keys are evolving so that
past signatures cannot be forged (does not apply to UTXO
based model)
• Enforce strict chain density statistics (knowledge of the
number of parties at any time)
• Add context in each transaction (knowledge of the honest
chain)
5. P. Gazi, A. Kiayias, A. Russel, « Stake-Bleeding Attacks on Proof-of-Stake
Blockchains », IOHK

16.
16
Preventing conflicts as soon as possible
1. Valid blocks should never be confronted with any other
conflicting blocks
→ No fork !
→ 0-confirmation delay
2. Valid transactions should never be confronted with any other
conflicting transactions
→ No double spending attacks !
→ Fast payments feasible

17.
17
Preventing conflicts as soon as possible 6
1. Valid blocks should never be confronted with any other
conflicting blocks
How ? Agreement on the unique block that can reference an earlier
block in the blockchain
2. Valid transactions should never be confronted with any other
conflicting transactions
How ? Agreement on the unique transaction that can redeem unspent
transaction outputs (UTXOs)
6. Joint work with Antoine Durand (IRT SystemX), Romaric Ludinard (IMT),
Bruno Sericola (Inria)
E. Anceaume, A. Guellier, R. Ludinard, UTXO as a proof of membership for
Byzantine Agreements, IEEE Blockchain 2018.

18.
18
Model
• Permissionless system
• Partially synchronous environment
• Adversary : no more than 1/3 of the total amount of money is
held by the adversary
• Nodes have access to safe cryptographic functions (hash
function and signature scheme)
• Each object of the system (i.e., UTXO, transaction and block)
is assumed to be uniquely identified
• No public key infrastructure to establish node identities

19.
19
Properties
Most of the permissionless blockchain-based cryptosystems
guarantee that :
Property (Safety)
If a valid transaction T is deeply confirmed at some
non-compromised node then no transaction conflicting with T will
ever be deeply confirmed by any non-compromised nodes
Property (Liveness)
Any conflict-free and valid transaction will eventually be deeply
confirmed in the blockchain of all non-compromised nodes at the
same height in the blockchain

20.
20
Properties
We aim at strengthening both properties
Property (Strong safety)
If a valid transaction T is confirmed at some non-compromised
node then no transaction conflicting with T will ever be confirmed
by any non-compromised nodes
Property (Strong liveness)
Any valid transaction will eventually be confirmed in the blockchain
of all non-compromised nodes at the same height in the blockchain

21.
21
Transaction validation protocol
At most one transaction is allowed to use
all the UTXOs referenced in its input set
TRANSACTION
WITH BOB
VALID ??
YES !
ALICE

22.
22
Transaction validation protocol
At most one transaction is allowed to re-
deem all the UTXOs referenced in its input set

23.
23
Transaction validation protocol
At most one transaction is allowed to re-
deem all the UTXOs referenced in its input set
TRANSACTION
WITH BOB
VALID ??
YES !
ALICE
TRANSACTION
WITH EVE
VALID ??
NO!

24.
24
Block validation protocol
Any validated block has at most one
valid block as immediate successor
VALID ??
YES !
Pred=0001001
Block 0000111

25.
25
Block validation protocol
Any validated block has at most one
valid block as immediate successor
VALID ??
YES !
Pred=0001001
Block 0000111
Pred=0001001
Block 0000001
NO !
VALID ??

26.
26
A set of ingredients
1. Byzantine Agreement (BA)
• Primitive enabling a set of committee members to agree on a
single value, each member holding a possibly different initial
value.
• Tolerate the presence of a minority of malicious members

27.
27
2. « Public keys as identities » principle
• Users, i.e. owners of accounts (owners of UTXOs), participate
to BA 7
• Alternative to existing designs
• Rely on the unique association UTXO/identity as a proof of
membership for BA
7. E. Anceaume, A. Guellier, R. Ludinard, UTXO as a proof of membership
for Byzantine Agreements, IEEE Blockchain 2018.

28.
28
3. Clustered-based Distributed Hash Table (DHT)
• P2P overlay whose topology approximates a structured graph
• For resiliency reasons, each vertex of the graph is a set of
nodes
• Nodes logically close to each other belong to the same cluster
• e.g., PeerCube is a clustered-based overlay 8
resilient to
adversarial behavior and robust to high churn
8. E. Anceaume, R. Ludinard and B. Sericola. Performance evaluation of large-scale
dynamic systems. ACM Sigmetrics Performance Evaluation Review, 39(4), 2012.

29.
29
3. Clustered-based Distributed Hash Table (DHT) (cont’d)
By reaching an agreement around the objects to be validated
• Resistance to Eclipse attacks
• IDs are random, ephemeral and verifiable
• Resistance to Sybil attacks
• Participation to committees is weighted by UTXOs amount
• Resistance to Selfish attacks
• Miners cannot create a block without disclosing it
• No double-spending
• No forks

30.
30
Sycomore : from a chain of blocks to a DAG of blocks 9
9. E. Anceaume, A. Guellier, R. Ludinard, B. Sericola, Sycomore : a
Permissionless Distributed Ledger that self-adapts to Transactions Demand,
IEEE NCA, 2018

31.
31
Sycomore : from a chain of blocks to a DAG of blocks
• Transactions are partitioned over the blocks of the ledger -
verifiable by anyone

32.
32
Sycomore : from a chain of blocks to a DAG of blocks
• The number of blocks and their creation rate self-adapt to
transactions demand - verifiable by anyone

33.
33
Sycomore : from a chain of blocks to a DAG of blocks
• The predecessor of a block is not predictable - verifiable by
anyone

34.
34
0
100
200
300
400
500
600
1 5 10 15 20 25 30 35
Meaninter-blocktime(s)
c
1/(cλ0)
• With c = 30 leaf blocks,
a block is mined every
20s (7, 000 Tx/s) with a
proba of fork of 10−6
• Bitcoin : a block every 10
mns (7 Tx/s) with a
proba of fork of 10−3
• Could even go faster by
relying on our structured
DHT
Mean inter-block time as a function
of the number of leaf blocks c.

35.
35
Collaborations and financial support
Current collaborations
• Local : R. Ludinard (IMT Atlantique), B. Sericola and Y.
Mocquard (Dionysos), F. Tronel (Cidre).
• National : A. Durand (IRT SystemX), M. Potop-Butucaru
(LIP6), A. Del Pozzo and S. Tucci (CEA)
• International : P. Tzigas (Chalmers Univ), L. Querzoni (La
Sapienza Univ),
Financial support
• PEPS INS2I Securite 2016 and 2017 : BIPs
• Labex Cominlabs 2019 : Blockchain FM

36.
36
Collaborations and financial support
We are looking for students, engineers, researchers to join us in this
adventure to build a nice and secure infrastructure
Thanks for your attention