Blockchain For Developers (Talk at Innopolis Blockchain Hackathon 2016)

Blockchain Hackathon @ Innopolis

Blockchain For Developers

Alexander Chepurnoy(aka kushti)

@chepurnoyIOHK Research

Background

● Nxt core developer

● smartcontract.com cofounder (left)

● Scorex since late 2014

● IOHK Research

The talk is about

● How a developer can view a blockchain system

● What are open problems in blockchains

Environment

● P2P network

● No central party

● Probabilistic broadcast

Read Books!

● Cachin et al. „Introduction to Reliable and Secure Distributed Programming“

● Russian: „Введение в надежное и безопасное распределенное программирование“ (Качин и др.)

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)

A transaction

● Atomic state modifier

● Authenticated

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

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!

Blockchain

● Transactions packed into blocks

● Blocks are linked

Blockchain

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

Bitcoin's Proof-of-Work

● hash(blockheader) < target

● target T = 1 / difficulty

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

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

Chain Quality

any sequence of blocks in an honest party’s chain will contain some number of honest blocks with overwhelming probability

Chain Growth

honest party's chain grows with some minimal pace with an overwhelming probability

Bitcoin

● digital cash

● transaction is a set of token transfers

Bitcoin: Transaction

Bitcoin Script

output: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

input: <sig> <pubKey>

Bitcoin: UTXO set

● unspent outputs set

● enough to validate any transaction

● application is about removing outputs spent and add new ones

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)

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)

Memory Pool

● contains unconfirmed transaction

● inconsistent across a network

Vault (Wallet)

● node-specific information

● e.g. transactions for selected pubkeys

Node view

(MinimalState, Blockchain, MemoryPool, Wallet)

(MinimalState, Blockchain) is eventually the same for all the honest nodes

What app developer should know

● Rollbacks are possible!

● Transaction is always visible before inclusion

● Frontrunning / replay attacks

● Malleability

Incentives and Rationality

● why participants are following a protocol?

● do they do some additional things altruistically?

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)

Bitcoin's Troughput (TPS)

● 7 ??? no

● 2-3 in fact

● 1/600 in worse case

https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/

Better throughput

● Bitcoin-NG

● GHOST/SPECTRE

Blockchain Pruning

Rollerchain

● http://arxiv.org/abs/1603.07926

● „Rollerchain, a Blockchain With Safely Pruneable Full Blocks“

Rollerchain

● Only last n full blocks to be stored collectively

● and n state snapshots

● Each miner stores k state snapshots

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

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

Unload the chain

● Move things off-chain

● Sidechains

● Avoid all the transactions execution(RsCoin)

Offchain

● Lightning Network

● Offchain contracts(SMC/SMP)

Smart Contracts

● Ethereum isn't scalable

● Hawk

● Enigma

Questions?

Twitter: @chepurnoy

Mail: kushti@protonmail.ch