Proof-of-Stake in details, formal methos in cryptocurrencies, project SCOREX

1. 1
Proof-of-Stake And It's Improvements
@chepurnoy

2. 2
About Myself
●
Nxt Core Developer
●
Secureae.com / SmartContract.com cofounder
●
Consensus Research member

3. 3
Fields of Interest
●
Distributed & P2P systems
●
Blockchain Tech
●
Functional Programming (Haskell / Scala)
●
Finite State Machines
●
Formal Methods (model checking / Coq)

4. 4
Consensus Research
Me + Andrew Lyashin
●
Andrew is a big fan of concrete math, category theory,
Coq, proven code
●
Asset on Nxt AE

5. 5
Consensus
●
A lonely toy for computer scientists for > 50 years
●
Crash failure
●
Byzantine failure

6. 6
Problems in Distributed Systems
●
CAP theorem
●
FLP impossibility

7. 7
Byzantine Consensus
●
Has been studying since 80s
●
A lot of algos found & analyzed

8. 8
Anonymous Byzantine Agreements
●
Anonymous Byzantine Agreements are vulnerable to
sybil attacks
●
Moderately-Hard Puzzles(a.k.a Proof-of-Work) as
anonymous identity tools were proposed since mid 90s
●
Finally, an approach was used(along with pretty informal
definition) by „Satoshi Nakamoto“

9. 9
Bitcoin Consensus?
Anonymous Byzantine Agreement with Computational
Puzzles as Identity Tool

10. 10
Good Papers To Read!
●
Anonymous Byzantine Consensus from Moderately-Hard
Puzzles: A Model for Bitcoin (A. Miller / J. LaViola)
●
Research Perspectives and Challenges for Bitcoin
and Cryptocurrencies (J. Bonneau, A. Miller et al)
●
The Bitcoin Backbone Protocol: Analysis and Applications
( https://eprint.iacr.org/2014/765.pdf )

11. 11
Bitcoin Consensus Simply
●
Random oracle (a.k.a sha256)
●
x questions to the oracle, which is sha256(~mining
power) at each round(say, 1 sec)
●
probability of positive answer should be → 0
●
honest players should have 50+% queries to the
oracle(„mining power“), with some glitches below
2/3(selfish mining etc)
●
length(chain) as chain quality measure

12. 12
BlockTree

13. 13
Blockchain As Database
●
Persistent(versioned) database
●
Genesis state – initial verion of the database
●
Block(„Block Delta“ by Bill White)
●
State(h) * Block → State(h+1)
●
Very weak consistency!

14. 14
Common chain prefix property
●
After k permutations a state of the blockchain database
for versions 1..N-k is considered to be stable (the
chance of opposite is negligible) (with some
assumptions made)
●
Bitcoin: k = 6

15. 15
Proof-of-Stake
●
Anonymous Byzantine Agreement with internal tokens
as identity tools
●
So no mining
●
Right to generate a block depends on stake
●
So a bunch of oracles (hit < target)
●
Cumulative difficulty(maxvalid in Backbone's paper) is
the chain quality measure(in a blocktree)

16. 16
Hit & Target (Nxt's Random Oracle)
●
hit = first8BytesAsNumber (sha256 (append
(lastBlock.generationSignature account.publicKey)))
●
target = lastBlock.baseTarget * (currentTime()-
lastBlock.time()) * account.effectiveBalance
●
block.baseTarget = prevBlock.baseTarget*((block.time-
lastBlock.time) / 60) then bounded by
(prevBlock.baseTarget / 2,prevBlock.baseTarget * 2)
●
hit < target

17. 17
Cumulative difficulty - Chain Quality Measure
●
sum(1 / block.baseTarget)

18. 18
●
Inside a Proof-of-Stake Cryptocurrency Part 1: Basic
Structures
http://chepurnoy.org/blog/2014/10/inside-a-proof-of-stake-cryptocu
●
Inside a Proof-of-Stake Cryptocurrency Part 2: Forging
Algorithm
http://chepurnoy.org/blog/2014/10/inside-a-proof-of-stake-cryptocu
●
Inside a Proof-of-Stake Cryptocurrency Part 3: A Local
Ledger
http://chepurnoy.org/blog/2014/11/inside-a-proof-of-stake-cryptocu
●
Inside a Proof-of-Stake Cryptocurrency Part 4: The
Executable Forging Simulation
http://chepurnoy.org/blog/2014/12/inside-a-proof-of-stake-cryptocu

19. 19
Part 1 is finished!
●
Questions?

20. 20
Let's try to crack it!
●
https://github.com/ConsensusResearch/ForgingSimulation
(Haskell)
●
https://github.com/ConsensusResearch/MultiBranch
(Coq)

21. 21
Nxt Promises Revisited
●
Avg time beetwen blocks is ~1.9 mins not 1.
●
http://www.scribd.com/doc/243341106/nxtforging-1

22. 22
Private Branch Attack
●
Example: attacker with 20% decides to work on his own private
branch(with no contribution to the canonical one)
●
After that we have two networks, one with 0.8*X forging stake,
another with 0.2*X (X - forging stake of last block)
●
Retargeting is needed for both the networks
●
But it's limited by factor of 0.5..2
●
So attacker's chain will be worse
●
So the attack is impossible if block delays are close to 1 minute

23. 23
Private chain attack (multibranching adversary)
●
Contributing to both forks
●
Attack could be successul in case of long delays for major network
●
Only few blocks overtake is possible
●
There's no way to predict an outcome of an attack(but it's cheap to try)
●
Attack allows collect more forging profits
●
Attack has positive outcome for the network(shorter avg. block delays)
●
Wait for 10 confirmations, as recommended by Nxt developers!

24. 24
Multiple-Branching Forging
●
Forging is cheap, so forging to every branch is possible
●
But number of branches is growing exponentially with
time, so the only strategy is to forge to N best chains
●
Simulation tools:
https://github.com/ConsensusResearch/MultiBranch,
https://github.com/ConsensusResearch/ForgingSimulation
(multibranch-experimental branch)

25. 25
Nothing-At-Stake Attack
●
Buterin: „Possible with 1% stake even“
●
Not possible at the moment!
●
Will be possible when most of forgers are multi-
branching
●
With 25 confirmations needed 10% attacker can't make
an attack(in simulations, in real world probably less
confirmations is needed)
●
Attack outcome is unpredictable

26. 26
History Attack
●
Buy IPO whale's key for $5
●
Build better history
●
???
●
Profit!
●
(impossible in Nxt because of few checkpoints within
code)

27. 27
Others attempts to improve Proof-of-Stake
●
Deposits / fines(Tendermint, GHOST)
●
Delegates(DPoS)
●
Totally unclear mixes of consensus & economics
properties!

28. 28
Proof-of-Stake with Multiple-Branching
Forging
●
N forks running parallel (N is to be set in client)
●
BlockTree instead of Blockchain
●
Quantum view of a system
●
Large Common Prefix Property is met (k could be found
with some assumptions made) (in simulations)
●
That's not formally proven(yet!)

29. 29
Proof-of-Stake Improvements
●
Better blockchain quality measure(than cumulative
difficulty)
●
Proof-of-Stake + Proof-of-Activity Hybrid
(paper on PoW+PoA Hybrid: „Proof of Activity: Extending
Bitcoin's Proof of Work via Proof of Stake“
http://eprint.iacr.org/2014/452.pdf )
●
(Semi)Formal model, not simulations

30. 30
Proof-of-Stake
●
Greener(no millions to be spent on planet heating)
●
More suitable for some classes of blockchain
systems(industrial chains, small-scale chains)
●
Allows systems with different economics properties(than
w. mining rewards)

31. 31
Part 2 is finished!
●
Questions?

32. 32
Better Quality of Coins
●
Safer languages(Scala/Ocaml, Haskell, Idris/Coq)
●
Formal methods & simulations usage
●
Prototypes first, not products!

33. 33
Security Problems
●
Consensus algo flaws – FATAL
●
Transaction layer flaws – from trivial to critical
●
Network layer – ddoses, unconfirmed pool attacks

34. 34
Bitcoin: Transaction Layer bug
On July 28 2010, two bugs were discovered and
demonstrated on the test network. One exploited a bug
in the transaction handling code and allowed an attacker
to spend coins that they did not own. This was never
exploited on the main network, and was fixed by Bitcoin
version 0.3.5.
●
After these bugs were discovered, many currently-
unused script words were disabled for safety.

35. 35
Bitcoin: Transaction Layer Bug
●
On 15 August 2010, with an exploit over 184 billion
bitcoins were generated in a transaction, and sent to two
addresses on the network. This was the only major
security flaw found and exploited in Bitcoin's history.
●
Fixed with hard-fork

36. 36
Formalizations & tools
●
Network layer – simulations / monitoring
●
Transactions layer – formal models(w. Coq as well)
●
Consensus layer – formal models(Coq?)

37. 37
Formal Approach
●
Formal Models on Paper
●
Interactive Theorem Provers(Coq etc)
●
Certified cryptocurrency engine

38. 38
Formal Approach w. Coq Examples
●
Formal Idealizations of Cryptographic Hashing
https://github.com/billlwhite/cryptohash
●
A Theory for Lightweight Cryptocurrency Ledgers
https://github.com/billlwhite/ledgertheory
●
Upcoming Consensus Research paper

39. 39
SemiFormal Approach
●
Hoare Logic
●
QuickSpec / HipSpec / ScalaLeon
●
Simulation tools

40. 40
SCOREX
●
SCala + QOra EXperimental cryptocurrency engine
●
To make proof-of-concepts FAST!
●
Compact code
●
Intentionally not-production-ready

41. 41
Lagonaki Release
●
100% Proof-of-stake
●
Simplified account-based transaction model
●
Simple payments only
●
Curve25519 for signing
●
JSON API
●
Command-line client

42. 42
Lagonaki Release
●
Scala, just 4K lines of code
●
YoctoDb / MapDb
●
Release: March 2015
●
Contributions are welcomed!

43. 43
Kizhi Release
●
Multiple-Branching Forging
●
Test network(please contribute with hardware!)
●
Scripts for attacks (Nothing-At-Stake)
●
Release: April-May 2015

44. 44
Part 3 is finished!
Questions?
Consensus Research Wallets:
●
NXT-R58Z-PUMK-JCG4-5TC6M
●
(„consensus“ tokens on Nxt Assets Exhange)
●
17YksFD7eRB4NhPfEtGrGnuvuwpkAeBd7f

45. 45
Pictures Taken From
●
Blockchain
https://sophosnews.files.wordpress.com/2013/03/bitcoin-dia
●
BlockTree
http://www.bitcoinsecurity.org/wp-content/uploads/2012/07/b