Applications (2) FinTech — Financial Innovation and the Internet 2019 Fall Kenji Saito Professor, Graduate School of Business and Finance, Waseda University [email protected] Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.1/31
completely More on Anonymity UTXO and anonymity Mixing with or without trust More on Ethereum Applications and demonstrations Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.4/31
characteristics Evolution onward The Libra Blockchain Characteristics and discussion Assignment Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.5/31
(zero knowledge proof) → Zcash on Ethereum (ZoE), etc. Constantinople + St.Petersburg (2019) ← we are here Efficiency, state channels (for 2nd Layer), adjustment toward proof of stake (PoS), etc. Serenity ← phase 0 in January 3, 2020 (11th anniversary of Bitcoin 0.1) Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.7/31
extending the current blockchain concept and design Therefore not “beyond blockchain” Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.8/31
secrecy (guarantee of verifiability to all) Oneness (distribution vs. replication) Not scalable (do not scale if replicated to all participants) Harder governance of evolution (can’t change if everyone needs to be united) Incentive mismatch (discrepancy of motivations for participation in infrastructure and applications) Supported by the value of the native currency (crash would stop all applications) ⇒ Can be solved by redesigning it zero-base Actually in progress (ex. BBc -1 (Beyond Blockchain One)) Problem with many ledgers is that they are not redesigned zero-base ex. Hash-chains without proof of work can be tampered with ex. Talking about “newspaper model”, you can’t prove anything by publishing articles in company newsletters Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.9/31
transaction finalization mechanism (Casper) (described later) Difficulty of secrecy (guarantee of verifiability to all) ⇒ ZoE (Zcash on Ethereum) Oneness (distribution vs. replication) Not scalable (do not scale if replicated to all participants) ⇒ Sharding (horizontal partitioning), Plasma (multi-layered) Harder governance of evolution (can’t change if everyone needs to be united) ⇒ Benevolent Dictator For Life (BDFL) (with bitter smile ;) ) Incentive mismatch (discrepancy of motivations for participation in infrastructure and applications) Supported by the value of the native currency (crash would stop all applications) ⇒ Will people who want to run the apps buy Ether and support? Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.10/31
consensus To refined proof of stake (PoS) + council system Let’s start with the current technology Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.11/31
and transactions) SHA-256 × RIPEMD-160 (public key digest ≈ address) Meaning of double application (what if the first stage collides?) . . . no meaning Problems due to use in applications different from the design intent The design intent is to reduce the computational cost Litecoin scrypt (Use a lot of memory) Ethereum Ethash (evolved Dagger-Hashimoto) (for proof of work) DAG : Directed Acyclic Graph https://github.com/ethereum/wiki/wiki/Ethash Keccak-256 (≈SHA-3) (general digest) (used in Ethash too) Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.12/31
interval, More and more miners will waste time Easy for miners not wasting time to become fixed ⇒ Aim to solve the problems through GHOST Cost of proof of work is calculated by referring not only to the direct previous block (parent) but also to orphan “uncles”, and the chain with the heaviest cost is chosen by everyone (modified Nakamoto consensus) In addition, uncles also receive mining rewards Ethereum uses a version of GHOST limiting references to uncles by 7 steps Recently, uncle is being replaced by ommer, a gender-neutral term Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.13/31
Merkle roots embedded in block headers Existence of a TX can be verified if a subtree (digests sitting next in each layer) is provided Originally designed to be able to erase consumed TX data Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.14/31
be any sequence of bytes PATRICIA (Practical Algorithm To Retrieve Information Coded In Alphanumeric) Trie (key, value) pair expressed and searchable A digest is used for referring to a trie node The top node as Merkle root Differences and tampering are detected Each element is encoded in RLP (recursive length prefix encoding) Used for expressing states in Ethereum Merkle roots are stored in block headers Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.15/31
problems Casper Sharding and other trends Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.16/31
(PoS) Original concept : probability of one’s making a block is higher if they possess more native coins (stakes) No wasted electricity Problems 1. Coin hoarding 2. “Nothing at Stake” Miners can bet on all forked chains Initiator can redo the whole chain at any time (because they had 100% of the coins at the beginning) 3. Low-cost so-called 51% attack Coin price can be controlled Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.17/31
who vote for blocks in chains not adopted (Slasher) Confiscates a deposited stake Voting by verifiers who stand for the role by paying a deposit A “checkpoint” is established for each 100 block height, and a proper chain is decided by weighted vote according to the deposit amount If the next checkpoint is justified, the history up to the previous checkpoint is finalized ⇒ How democratic can it be? Seems to assume that there is no network partitioning What if it happens? (what if there were several different “finalized” histories?) → hard fork Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.18/31
every miner/verifier verifies all transactions (load balancing) Need PoS to counter strategic actions on participation in shards PoW would cause large and small hash rates among shards, making it easy for malicious miners to attack PoS identifies the entities that deposited, so shards can be assigned to them algorithmically Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.19/31
networks (like Lightning Network in Bitcoin) Plasma Multi-layered blockchain “Put everything on top” of technologies being studied to solve blockchain problems In a way, performing and lively worthy of public estimation as “experimental system” Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.21/31
do you think of “one global digital currency and one unified global market”? Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.22/31
Paper” Design and use programming languages “Move” (← peculiar, yes) Use the Byzantine Fault Tolerant (BFT) consensus approach (← so what?) Adopt a widely adopted blockchain data structure (← reasonably a feature) Actual technological characteristics It is designed by combining elements and ideas of various existing technologies with “power” Meaning that designers have skill power There are some evaluations that they “picked up the best part” of existing technologies, but whether they are “the best part” needs to be debated Milestones Starts as a private ledger where verifier membership is managed (permissioned) Start transition to a public ledger (permissionless) within 5 years If they think they can extend it with the same technology, very challenging Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.23/31
to participating nodes (1) Begin with an equal initial state (2) Events are copied to all participating nodes (3) and copied in the same order (4) All events act deterministically on a state So you can maintain fault tolerance ⇒ This is not important, but it characterizes the behavior of blockchain in a narrow sense Producing many unfortunate “proof-of-concept experiments” Because this is “state machine replication”, having existed since 1980s Libra is talking about “state machine replication 2.0” so to speak Better than many private ledgers because Libra makes it explicit Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.24/31
transactions and states in Merkle tree structures Merkle trees grow without blocks → Merkle accumulator Put transactions into a block only when replicating state machines Problems (1) If they don’t publish the Merkle root, they can’t prove existence If we can’t match with published root value, anything goes (2) Replicas are the proof? But it doesn’t prevent double bookkeeping Same as above (no proof that the real record has been passed to replicas) (3) Wouldn’t permissioned, block-wise replication simplify BFT protocol? Because you can put a digital signature on a block that’s virtually unforgeable (4) Why adpot Ethereum’s smart contract execution model? Is the cost burden model by gas meaningful in permissioned system? (Why bother with pay-as-you-go?) (5) Why bother to create a new language/VM to raise the learning bar? Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.25/31
and digital signature Proof of Existence e.g. hash-chain with proof of work Consent of Uniqueness e.g. Nakamoto consensus Description of Rules e.g. transfer of bitcoins - The content of a transaction cannot be altered, - not contrary to past history of transactions regarding the asset, - and the transaction is cast by a legitimate user - Cannot delete the evidence of an existing transaction in the past, - and cannot fabricate an evidence of a transaction that did not exist - When two mutually contradicting transactions are cast, (eventually) everyone chooses the same one to place in the history - Application logic to decide what valid transactions are Blockchain ≪or alike≫ (tries to) bring the End-to-End philosophy of the Internet into reality in the control of assets, thereby making a Record Fixation Device in the Air The center is automated Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.26/31
in Move (VM machine language) Uniqueness BFT (= fault tolerance) (with 1,000 machines?) Existence Merkle tree (but don’t publish roots?) Validity State management + digital signatures They say they start transition to permissionless within five years . . . BFT operates on the assumption that at most f units will break arbitrarily (probability) The real problem with permissionless systems is intentional attacks, with a probability of 1 (can’t estimate f) They seem to be trying to be scientific, and they ignore their predecessors’ knowledge somewhere The reason why I think the design is inconsistent Characteristics of Move language Looks like a domain-specific language to represent monetary value as a resource A mechanism to avoid double spending is introduced at the language level (difficult to write?) Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.27/31
written in EVM machine language Uniqueness GHOST (Nakamoto consensus) → Casper (PoS) Existence PoW → Casper checkpoint finality Validity State management + digital signatures BBc-1 (Beyond Blockchain One) (https://beyond-blockchain.org) Rule Descriptions by applications (Python → bbc1-lib-contracts?) Uniqueness Digital assets are liabilities / uniqueness is guaranteed by obligor Existence Proof of Context (inter-domain cross references of hash-tree roots) (initially anchored to public blockchains) Validity UTXO/state plus separation of IDs and public keys, private within domains Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.28/31
and FinTech Please select one from “settlement and remittance”, “asset management”, “deposits and loans”, “financing”, “insurance” and “capital market” Apply FinTech to it with respect to self-driving cars Deadline and how to submit January 8, 2020 at 17:59 JST From Course N@vi Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-20 – p.30/31
ks91
niwatakeru
atsushii
sansantech
miyu_dev
ebiken
shimastripe
16bitidol
ishikawa_satoru
riita10069
pfn
denniskardys
orderedlist
jonrohan
lynnandtonic
akosma
eileencodes
irinanazarova
vanstee
rocio
keavy
yeseniaperezcruz
pauljervisheath
