2. My Background
● Java then Scala development
● Distributed / P2P systems development
● Nxt Core Developer
● SmartContract.com / Secureae.com cofounder/dev
● Consensus Research member
● Scorex project
3. 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
4. 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)
8. 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!
9. 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
10. Private Blockchains
● want to get maximum from the trustless db model
● have non-monetary purposes, usually
● limited number of participants(or just miners)
11. Private Blockchains
are proposed for:
● art objects ownership history
● real estate ownership history (chain of title)
● Inter-banks procedures(clearing etc)
● etc
13. 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?
14. 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.
15. 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
16. Byzantine Agreement Scheme
● A lot of well-known formalized solutions to the distributed
commit problem
● Up to ~5000 participants
● Verification could be costly
17. 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
18. 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?
20. 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
21. Lagonaki Release
● 100% Proof-of-stake
● Simplified account-based transaction model
● Simple payments only
● Curve25519 for signing
● JSON API
● Command-line client
22. Under The Hood:
● Scala
● Akka
● MapDB
● Spray
● Play Json
● Scalatest
● Logback
23. 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: kushti@protonmail.ch
