These slides: slides.cuban.tech/dapps.html
Network: cubantech
Password: meet-ups
- Replicated state machines (a.k.a RSM)
- Infrastructure, management and admin tools
- Relation betwen RSM and Blockchain
- Execution rules and consensus
- General Theory of DApps
- Blockstack overview
- Blockchain-independent DApp RSM with VirtualChain
Notes about Bitcoin P2P network in-between
--
- Fault tolerance beyond single-node processors
- Replicas of a single server executed on separate processors
- Protocols for client interactions with replicas
- Physical and electrical isolation for independent server failures
- Let's assume deterministic state machine
- ... even if Turing complete is possible
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Software package repositories
- e.g. bitcoind @ Debian, Blockstack apt repo, ...
- Containers and registries
- e.g. Lisk, Blockstack, ... @ Docker Hub
- CM tools (Ansible, Puppet, Chef, Habitat, ...)
--
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Multiple solutions
- e.g. Bitcoin transactions
--
Important meta-data (except coinbase transactions)
- Transaction (global) ID
- Version number (protocol evolution)
- Locktime
- Earliest time TX can be added to the block chain
- Time-locked transactions only valid in the future
- Cancellations
--
- Output(s) : Implicit array index
- Amount (satoshis)
- Pubkey script ( Unlock to spend )
- Input(s)
- Spent output (Transaction ID + Output index)
- Sequence number (related to locktime)
- Signature script (params to unlock Pubkey script)
Bitcoin is a public distributed ledger.
--
blocktrail.com
--
- ECDSA secp256k1 (elliptic) curve
- Deterministic public key (hash) generation
--
- Redeem script hash instead of public key hash
- Supports PubKey scripts opcodes
--
- Sender creates UTXO with PubKey script
- ... using the public key hash of the receiver
- Sender broadcasts transaction (P2P network)
- Miners add it to a block (... more details later ...)
- Wallet : UTXO amount as spendable balance
--
- Lookup transaction ID and index for UTXO
- Sender creates TX input and also add:
- Sequence number
- Signature & PubKey (script params)
--
- Lookup transaction ID and index for UTXO
- Sender creates TX input and also add:
- Sequence number
- Signature & PubKey (script params)
--
- Sender prepares UTXO for recipient (as before)
- Sender broadcasts transaction (P2P network)
- Miners add it to a block
- Script validation ! ( A-ha! )
- Wallet : Update balance
--
A very peculiar monster
--
;; QUESTION SECTION
;seed.bitcoin.sipa.be IN A
;; ANSWER SECTION
seed.bitcoin.sipa.be. 60 IN A 192.0.2.113
seed.bitcoin.sipa.be. 60 IN A 198.51.100.231
seed.bitcoin.sipa.be. 60 IN A 203.0.113.183
- Connect to port
8333(mainnet) or18333(testnet) - Followed by
addrmessages announcing addresses of peers
--
- Send
versionmessage- local version number, block, and current time
- Peer responds with its own
versionmessage - Send
getaddrand receiveaddrof new peers (discovery)
--
- Send
invmessage to a peer. - Wait for
getdatamessage - Send transaction data in
txmessage - Peer forwards transactions to other peers
- Full nodes keep track of unconfirmed transactions in memory pool
... to be continued ...
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Mutiple solutions
- Blockchain ?
- Bitcoin transactions !
--
Causal ordering : Chain of ownership
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Execute inputs in the chosen order on each replica
--
- Public ledger
- Ordered and timestamped transactions
- Storage distributed over Bitcoin full nodes
- Protect against
- double spending
- modification of previous transaction records
--
--
- Version : 4 bytes
- Previous block header hash : 32 bytes
- Merkle root hash : 32 bytes
- Time : 4 bytes
- nBits : 4 bytes
- nonce : 4 bytes
--
blocktrail.com
--
Coinbase transaction comes first
- Metric
- Prove legitimate interest, irreversibility
- Make decisions about changes in a DApp
- Modifying past blocks harder than adding new ones
- Common examples
- Proof of work (PoW)
- Proof of stake (PoS)
- Proof of space (PoSpace)
- Proof of collaboration (PoC)
- Proof of replication (PoR)
- Can be used in parallel
- e.g. PeerCoin relies on PoW + PoS
--
- Driver : Amount of computational work (CPU, GPU, NPU, ...) that contributed to the operation of the DApp.
- Resource intense (power, cooling, ...)
- The mechanism for establishing consensus through POW is commonly called mining.
Bitcoin uses that approach for its day-to-day operation.
--
- Driver : new coins according to number of coins (stake) you hold
- May be abused by those who hold enough coins.
- Usually combined with other proof
OmniLayer is based on the POS mechanism.
--
- Driver : allocation of non-trivial amounts of memory or storage needed to solve a challenge (memory-hard functions).
- Greener alternative to PoW
PoStorage is used in PermaCoin, SpaceMint, BurstCoin
--
- Collaboratively Validating Nodes (in short CVNs)
- Decide what node creates next block
- Approve CVN by digitally signing a piece of data containing winner's ID
- With required signatures gather TX and create new block
- No reward (new money) for block creation (small fee)
- Power consumption is low (CVNs on a Raspberry3)
FairCoin (fork of Bitcoin 0.12) implements PoC since July 18th 2017
Operating modes : SPV clients vs full node
- First run : Node only contains block 0
- Choose remote peer (a.k.a sync node)
- Download from block 1 to current tip of sync node's best block chain
- Blocks-first (up until version 0.9.3)
- Headers-first (from 0.10.0 onwards)
- Add new blocks to the block chain
- Make transation history hard to modify
- Strategies
- Solo mining
- Pooled mining
- Miner generates new blocks on his own
- Completely claims block reward and transaction fees
- Large payments
- Higher variance (longer time between them)
- Group of miners pool resources with other miners
- Find bocks more often at easier bits targets
- Proceeds shared amongst miners
- Correlated to relative hash power PoW
- Small payments
- Lower variance (i.e. shorter time between payments)
--
Minted coins : +1M BTC mined since Dec 2010. ZCASH since Apr 20th 2017
--
--
--
Minted coins : BTC
--
--
Minted coins : BTC
- 6.4 EHash/s , 80,704,290.84 PFLOPS
- 10,000 metric tonnes of hardware. Enough material to build another Eiffel tower.
--
Application specific integrated circuits, a.k.a. ASICs
--
... according to BitcoinEnergyConsumption.com
- Projected to be comparable to Denmark's in 2020
- Miner includes mined block in new
blockmessage - Miner sends message to its full nodes peers
since version 0.12.0
--
- Standard method
- Miner sends
invmessage to all (SPV and full node) peers- Includes inventory referring to the block
- BF peer ⇒
getdatarequesting the full block- Miner ⇒
blockmessage
- Miner ⇒
- HF peer ⇒
getheaders(few headers in best block chain)- Miner ⇒
headersmessage
- Miner ⇒
- SPV clients ⇒
getdatarequesting a Merkle block- Miner ⇒
merkleblockfollowed by sometxmessages
- Miner ⇒
since version 0.12.0
--
- Used if peer signals with
sendheadersduring handshake - Miner sends
headersmessage fror new block - HF peer ⇒ Partial validation and sends
getdata - Miner ⇒
blockormerkleblock
since version 0.12.0
- Deploy replicas of the software
- Receive client requests (i.e. inputs)
- Order the inputs
- Execute SM transition over and over
- Monitor replicas for differences in State or Output
- Each replica generates output
- Non faulty replicas will always produce same output
- Faulty outputs filtered out
- Consensus
- Correct output sent back to client
--
- Simultaneous blocks mined, nodes choose winner
- Peers prefer forks with stronger PoW
- longest fork
- highest block height : distance to block 0
--
- When ?
--
- Eliminate (stale and orphan) blocks in low PoW forks
- Iterate over transactions in stale and orphan blocks
- discard it if TX belongs in another block of highest PoW fork
- move it back to TX mempool otherwise
- to be included in a future block by this miner
- (optionally?) broadcast to the P2P network
--
- When?
- Extend blockchain to prevent third-party 51% attack
- Upgraded consensus accept formerly rejected blocks
- Network partition
--
- Warning in
getnetworkinfoand run-alertnotifycommand if set.- +6 blocks PoW than best valid chain
- Repetition of block and TX with version numbers higher than expected consensus
- Coinbase transaction may be spent only after 100 blocks
- SPV clients may contact different full nodes
- discard chains with weaker PoW
Wallet software : Add up UTXO to determine balance
- Tolerance for F random independent failures
- memory errors, hard-drive crash, ...
- Requires
2F + 1replicas
- Failed replica can stop without generating outputs
- Only
F + 1replicas required - ... no existing systems achieve this limit
- Only
- Byzantine failures
- random, spurious faults ⇒
2F + 1 - malicious, intelligent attacks ⇒
3F + 1
- random, spurious faults ⇒
--
- Desktop or laptop (Windows, Mac OS X, or Linux)
- 125 GB of HDD space, 2 GB RAM
- Broadband Internet with upload ≥ 400 Kbps (50 KB/s)
- Unmetered connection, or high upload limits, respect upload limits
- +100 GB IBD
- ≈ 20 gigabytes download a month
- +200 GB upload a month
- +6 hours a day with full node running
- +8 connections and active sync peers
--
Most ordinary folks should NOT be running a full node. We need full nodes that are always on, have more than 8 connections (if you have only 8 then you are part of the problem, not part of the solution), and have a high-bandwidth connection to the Internet.
Gavin Andresen, Bitcoin Foundation’s Chief Scientist, in Reddit post
- It must operate autonomously
- No entity controlling the majority of its tokens
- Data and records in a public, decentralized block chain.
e.g. Bitcoin apps are open-source, no entity controls Bitcoin and its records are open and public.
- The purpose of a token is to allow access to the DApp application.
- Must generate tokens according to a standard algorithm
- Possibly distribute tokens at the beginning of operation
- Tokens must be necessary for the use of the application
- Contribution from users rewarded by payment in the application's tokens.
e.g. Bitcoin generates bitcoins (tokens) with a predetermined algorithm that cannot be changed. Tokens are necessary for Bitcoin to function. Bitcoin miners are rewarded with bitcoins for their contributions in securing the Bitcoin network.
- Protocol may be adapted in response to
- proposed improvements
- market feedback
- Changes decided by majority consensus of its users.
e.g. All changes to Bitcoin must be approved by a majority consensus of its users through the proof-of-work mechanism.
- They have their own block chain.
Bitcoin, Litecoin and other alt-coins
- Use the block chain of a type I decentralized application.
- They are protocols
- Tokens that are necessary for their function.
OmniLayer (formerly Master Protocol) and Blockstack are examples of type II decentralized application.
--
- Embed additional data in DApp type I transactions
- Bitcoin OP_RETURN code
- Provably prune-able outputs
- Bitcoin miners will have the option to prune those data
Blockstack is a type II DApp
- They use the protocol of a type II decentralized application.
- They are protocols and have tokens that are necessary for their function.
Omni (formerly Mastercoin), and Blockstack apps are examples of type III decentralized applications.
- Publication of whitepaper
- Distribution of initial tokens
- Delegation of ownership
- Intentions and goals of the DApp
- Plans for token distribution
- Mechanism for establishing consensus
- Oversight of the DApp
- Management of developer bounties
- Technical description of the DApp
- Tokens are distributed to those who contribute most work to the operation of a DApp.
Taking Bitcoin as an example, bitcoins are distributed through a predetermined algorithm to the miners that verify transactions and maintain the Bitcoin block chain.
- Tokens are distributed to those who fund the initial development of the DApp.
Taking the Master Protocol as an example, Mastercoins were initially distributed to those who sent bitcoins to a given address at the rate of 100 Mastercoins per bitcoin sent. The bitcoins collected were then used to fund the development of applications that promoted the development of the Master Protocol.
- Tokens are generated using a predefined mechanism and are only available for the development of the DApp.
In addition to its fund-raising mechanism, the Master Protocol used the collaboration mechanism to fund its future development. Some Mastercoins are distributed via a community-driven bounty system based on the PoS mechanism.
The Internet is +40 years old now
- Critical services offline by attacks like DDoS on DNS servers
- Implicit trust e.g. [TurkTrust CA issued false security certificates for Google](http: //cnet.co/2oArU6O)
- Desktop to cloud creates SPoF e.g. [Yahoo! losing data for 500M people](http: //nyti.ms/2oAqn0G.)
--
- A New Internet for Decentralized Applications
- Open source
- Re-decentralize the Internet
- Users own their data
--
- Decentralized Naming & Discovery
- Register and use human-readable names
- Discover network resources without trusting any remote parties
- Decentralized Storage
- Store data without revealing it to any remote parties.
- Comparable Performance
- Survive Failures of Underlying Blockchains
- Keep Complexity and Logic Outside of Blockchains
- opposite to NameCoin, Ethereum, etc ...
- Scalable Index for Global Data
- Virtual blockchain, on top of Bitcoin blockchain
- Atlas, a peer-network
- Global index for discovery information
- Gaia, decentralized storage system
Users do not need to trust any data layer
DApp type II
--
--
NAME_REGISTRATION bluestack.id
- Fork*-consistent RSMs on existing blockchains
- Fork detection & recovery
- Cross-chain migration
- Reasons for Blockstack to migrate from Namecoin to Bitcoin
--
--
- Thank you for coming!
- We'd love your feedback: bit.ly/blockstack-cuba-feedback