5. Read Books!
● Cachin et al. „Introduction to Reliable and Secure
Distributed Programming“
● Russian: „Введение в надежное и безопасное
распределенное программирование“ (Качин и др.)
6. P2P network
● Each node has own state
● The goal is to have replicated subset of it across the
network
● In the presence of Byzantine adversaries!
● (so only honest nodes agree on the state)
● (and only eventually)
8. Minimal State
● Can answer the question „whether a transaction is valid
and so applicable“
● apply(min_state, tx): (MinimalState | Error)
● apply(apply(min_state, tx), tx) is always Error
● In Bitcoin UTXO set
9. Minimal State
● Transaction application is deterministic
● There's some initial (genesis) state hardcoded
● By applying the same sequence of transactions to the
genesis state, two honest nodes got the same minimal
state
● Thus we need for a guarantee every pair of honest nodes
is eventually applying the same sequence of transactions!
12. Block Generator Election
● random party
● sybil-resistant
● efficient(min communication)
solution
● each party has limited queries to random oracle
● random oracle answers „yes“ with adjustable probability
● replace random oracle with a hash function
14. GKL Model
● „The Bitcoin Backbone Protocol:Analysis and Applications“
by Garay / Kiayias / Leonardos
● slides: https://bitcoinschool.gr/slides/session2.pdf
Bitcoin consensus protocol properties:
● Common Prefix
● Chain Quality
● Chain Growth
15. Common Prefix
no matter the strategy of the adversary, the chains of two
honest parties will fork in the last k blocks with probability
exponentially decreasing with k
16. Chain Quality
any sequence of blocks in an honest party’s chain will
contain some number of honest blocks with overwhelming
probability
21. Bitcoin: UTXO set
● unspent outputs set
● enough to validate any transaction
● application is about removing outputs spent and add new
ones
22. Output Abstraction: Box
● minimal state is a set of closed boxes
● transaction opens some boxes and add new ones
● both UTXO and acccount model (Nxt, Ethereum)
23. Abstract Transaction Authentication
● Box is protected by a proposition (e.g. pubkey)
● To be open with a proof (e.g. a signature)
● check(proposition, proof, message)
27. What app developer should know
● Rollbacks are possible!
● Transaction is always visible before inclusion
● Frontrunning / replay attacks
● Malleability
28. Incentives and Rationality
● why participants are following a protocol?
● do they do some additional things altruistically?
29. Modifications
● alternative consensus protocols (Proof-of-Stake etc)
● richer transactional models (NameCoin, Ethereum, ZCash)
● alternative log structures (Bitcoin-NG, GHOST/SPECTRE)
● incentivization of certain activities (Permacoin, Rollerchain)
30. Bitcoin's Troughput (TPS)
● 7 ??? no
● 2-3 in fact
● 1/600 in worse case
https://www.reddit.com/r/Bitcoin/comments/3cgft7/large
st_transaction_ever_mined_999657_kb_consumes/
34. Rollerchain
● Only last n full blocks to be stored collectively
● and n state snapshots
● Each miner stores k state snapshots
35. Rollerchain
● New node can download a historical snapshot
● Fullblocks not needed for mining could be thrown away
● Blockheaders are to be stored forever, so must be small
36. PoPoW with sublinear complexity
● „Proofs of Proofs of Work with Sublinear Complexity“
Kiayias et. al. (FC 16)
● chain validity could be validated with only last k headers
● efficient sidechains
● static difficulty only atm
37. Unload the chain
● Move things off-chain
● Sidechains
● Avoid all the transactions execution(RsCoin)