Top Banner
Blockchain Hackathon Moscow Alexander Chepurnoy On Private Blockchains, Technically
23

On Private Blockchains, Technically

Apr 16, 2017

Download

Engineering

Alex Chepurnoy
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: On Private Blockchains, Technically

Blockchain Hackathon Moscow

Alexander Chepurnoy

On Private Blockchains, Technically

Page 2: On Private Blockchains, Technically

My Background

● Java then Scala development

● Distributed / P2P systems development

● Nxt Core Developer

● SmartContract.com / Secureae.com cofounder/dev

● Consensus Research member

● Scorex project

Page 3: On Private Blockchains, Technically

Fields of Interest

● Distributed & P2P systems

● Blockchain Tech

● Functional Programming (Haskell / Scala)

● Formal Methods (model checking / Coq)

● Finite State Machines and some other topics in CS

Page 4: On Private Blockchains, Technically

The Design of a Cryptocurrency

● P2P Network

● Persistent distributed fully-replicate database (aka Blockchain)

● Transactions operating with tokens grouped within blocks, a block is a database version

● Consensus algorithm

● Optional: additional layers on top of transactional layer(mesages, colored coins, code)

Page 5: On Private Blockchains, Technically

A Blockchain Structure

Page 6: On Private Blockchains, Technically

Consensus About Blockchain

● Proof-of-Work

● Proof-of-Stake

● Hybrid: Proof-of-Work+Proof-of-Activity, Proof-of-Stake+Proof-of-Activity

Page 7: On Private Blockchains, Technically

BlockTree

Page 8: On Private Blockchains, Technically

Blockchain As A Database

● Persistent(versioned) database

● Genesis state – initial verion of the database

● Block as state modifier: State(h) * Block → State(h+1)

● Very weak consistency!

Page 9: On Private Blockchains, Technically

PoW-based Trustless Database

If adversarial hashing power is less than 50% :

● replicated log and state

● a probability of transaction exclusion from a blockchain is going down exponentially with time

● a probability of valid trransaction non-inclusion into a blockchain is going down exponentially with time

● node's state divergence from a canonical one(majority has) is going down exponentially with time(if exists)

● dependless on who mined a concrete block

Page 10: On Private Blockchains, Technically

Private Blockchains

● want to get maximum from the trustless db model

● have non-monetary purposes, usually

● limited number of participants(or just miners)

Page 11: On Private Blockchains, Technically

Private Blockchains

are proposed for:

● art objects ownership history

● real estate ownership history (chain of title)

● Inter-banks procedures(clearing etc)

● etc

Page 12: On Private Blockchains, Technically

Implementation

● consensus protocol

● transactional model

● incentives model

Page 13: On Private Blockchains, Technically

Consensus – PoW

● Not fair(richer parties will take control over a network soon)

● Attacks via outsourcing work to Bitcoin miners

● Why art gallery or real estate agency needs for a lot of expensive special hardware in addition to the database software?

Page 14: On Private Blockchains, Technically

Consensus - PoS

● Generation rights

● Predefined distribution of generation rights

● Works in practice for few years

● Some security investigations are done...

but more needed! As well as formalizations.

Page 15: On Private Blockchains, Technically

Trusted Random Beacon

● Bitcoin / Nxt / other public blockchain could be used as a trusted source of randomness, to chose next block generator

● Blocks frequency is the same in both chains

● (SPV) client is needed to be inbuilt in a node

Page 16: On Private Blockchains, Technically

Byzantine Agreement Scheme

● A lot of well-known formalized solutions to the distributed commit problem

● Up to ~5000 participants

● Verification could be costly

Page 17: On Private Blockchains, Technically

Transactional Model

● Should be suitable for max performance

● Min transaction size

● Prunable state

● Bitcoin's transactions with multiple inputs & outputs and scripts attached to both sides probably isn't the most suitable model for many non-monetary cases

Page 18: On Private Blockchains, Technically

Incentives Model

Long-term security

● Why to participate in a network?

● Why to run a fullnode?

● Why to generate a block?

● Why to include transactions in a block?

Page 19: On Private Blockchains, Technically

Better Quality of Blockchain Impls

● Modular approach

● Safer languages(Scala/Ocaml, Haskell, Idris/Coq)

● Formal methods usage

● Prototypes before products

Page 20: On Private Blockchains, Technically

SCOREX

● The cryptocurrency engine in less than 4K lines of Scala code

● To make proof-of-concepts FAST!● Compact code● Not production-ready● CC0 license

Page 21: On Private Blockchains, Technically

Lagonaki Release

● 100% Proof-of-stake

● Simplified account-based transaction model

● Simple payments only

● Curve25519 for signing

● JSON API

● Command-line client

Page 22: On Private Blockchains, Technically

Under The Hood:

● Scala

● Akka

● MapDB

● Spray

● Play Json

● Scalatest

● Logback

Page 23: On Private Blockchains, Technically

Questions?

● Articles:

● „On Private Blockchains, Technically“ http://chepurnoy.org/blog/2015/11/on-private-blockchains-technically/

● „On the Way to a Modular Cryptocurrency, Part 1: Generic Block Structure“ http://chepurnoy.org/blog/2015/10/on-the-way-to-a-modular-cryptocurrency-part-1-generic-block-structure/

● „A Cryptocurrency Architecture“

http://chepurnoy.org/blog/2015/08/a-cryptocurrency-architecture/

Mail: [email protected]