FinTech - Lecture 11 : Other Ledger Technology and Applications (1)

These slides were used in the lecture 11 of FinTech - Financial Innovation and the Internet 2020 Fall at the Graduate School of Business and Finance, Waseda University, on December 11, 2020.

Transcript

1. QIPUP
   CZ
   0MJWFS
   ) FinTech — Financial Innovation and the Internet 2020 Fall Lecture 11 : Other Ledger Technology and Applications (1) Kenji Saito Professor, Graduate School of Business and Finance, Waseda University Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.1/28
2. This class is recorded Camera ON is recommended, but not required You do need to speak often (we are going to have a lot of dialogue) We will use breakout rooms a lot, but those won’t be recorded unless you do it yourselves (need to be allowed) Keep your Zoom client updated! We might use latest features The recordings could be used for research on online learning Transcribed for use and anonymized Will let you know when the necessity arises Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.2/28
3. The lecture slides can be found at : https://speakerdeck.com/ks91 Recording and chat text will be posted at Moodle and Discord Trial automatic transcription of the lecturer’s part will be posted at Discord Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.3/28
4. Schedule (provisional) Lecture 1 9/25 Overview of FinTech (1) • Lecture 2 10/2 Overview of FinTech (2) • Lecture 3 10/9 Internet Technology and Governance (1) • Lecture 4 10/16 Internet Technology and Governance (2) • Lecture 5 10/23 The World of Apps (1) • Lecture 6 10/30 The World of Apps (2) • Lecture 7 11/13 Blockchain (1) • Lecture 8 11/20 Blockchain (2) • Lecture 9 11/27 Smart Contracts (1) • Lecture 10 12/4 Smart Contracts (2) • Lecture 11 12/11 Other Ledger Technology and Applications (1) • Lecture 12 12/18 Other Ledger Technology and Applications (2) Lecture 13 1/8 Cyber-Physical Society and Future of Finance Lecture 14 1/15 FinTech Ideathon Lecture 15 1/22 Presentations and Conclusions Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.4/28
5. Last Week, We Did. . . Smart Contracts and Ethereum Overview (revisited) Smart Contract Programming Programming language Characteristics and challenges Blockchain and Smart Contract Example : ADEPT and a washing machine Authenticity of contracts Demonstraion : digital ID cards and relations to other applications Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.5/28
6. Today’s Topic How to Disappear Re-assignment — how to disappear completely More on Anonymity UTXO and anonymity Mixing with or without trust More on Ethereum Applications and demonstrations Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.6/28
7. How to Disappear Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.7/28
8. ZoE (Zcash on Ethereum) In Ethereum, too, an “address” is a public key digest In Ethereum, which manages account status (balance, etc.) rather than UTXO (coin with destination), it’s difficult to adopt the Bitcoin-like method of changing the receiver’s address from transaction to transaction Which is not a perfect way to hide themselves anyway zk-SNARKs, zero-knowledge proof algorithm used in Zcash, has also been implemented for Ethereum Can conceal transactions (Who sent it to whom ← not straightforward, and) how much? Deployed with Byzantium hardfork in 2017 Gas (transaction cost) is expensive Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.8/28
9. zk-SNARKs Zero Knowledge - Succinct (compact) Non-interactive ARgument of Knowledge 3 parts G is Generator : G(λ, C) → (pk, vk) where C is a circuit, λ is a secret Circuit (or function) C returns true or false; pk is the prover key, vk is the verifier key P is Prover : P(pk, x, w) → π where x is the public input of C, w (witness) is the secret input of C π is the proof V is Verifier : V (vk, x, π) = true ⇒ ∃w : C(x, w) = true Can perform in Ethereum by executing V inside smart contracts G and P (knows secret) are executed “off-chain” so to speak Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.9/28
10. C’s (circuits) to Conceal Balances and Remittances Use the cryptographic hash function H The contract manages H(a’s balance) for all accounts a C s (x, w) for sender : x is [H(pre-tx balance), H(post-tx balance), H(remittance)], w is [pre-tx balance, remittance] Confirm pre-tx balance ≥ remittance Apply H to w to verify that H(pre-tx balance) and H(remittance) in x are correct Verifies that H(post-tx balance) in x equals H(pre-tx balance − remittance) C r (x, w) for receiver : x is [H(pre-tx balance), H(post-tx balance), H(remittance)], w is [pre-tx balance, remittance] Apply H to w to verify that H(pre-tx balance) and H(remittance) in x are correct Verifies that H(post-tx balance) in x equals H(pre-tx balance + remittance) Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.10/28
11. Contract to Conceal Balances and Remittances Accepts the following as arguments (sender address is self-evident as the caller of the contract) Receiver address, H(remittance), H(post-tx balance s ), H(post-tx balance r ) π s , π r obtained by applying P in advance Verifies sending by V (vk s , [H(balances ), H(post-tx balances ), H(remittance)], π s ) Verifies receiving by V (vk r , [H(balancer ), H(post-tx balancer ), H(remittance)], π r ) Replaces both H(balance) with their H(post-tx balance) Sender and receiver need to communicate off-chain They cannot tell how much each other had and has now Others cannot tell, in addition to the above, how much was sent But they can tell who sent money to whom Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.11/28
12. Assignment (reprise) Those who have already submitted can rethink and resubmit Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.12/28
13. Assignment 5. “How to Disappear Completely” Please think of a method of remittance using zk-SNARKs that conceals the following, and write the algorithm briefly (in English) Who sends money? ← NEW! To whom? ← NEW! How much? How much were the balances of those before remittance, and how much afterward? Is your solution perfect? What problems are there? Deadline and how to submit December 15, 2020 at 23:59 JST From Moodle (mandatory) Optionally, you can also post to #assignments channel at Discord So that your classmates can read your report, refer to it, and comment on it Just plain text, and be concise, please Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.13/28
14. More on Anonymity This may be a disturbing story, but. . . How do we share and transfer a request to Golgo 13 (assassin) while hiding his and the client’s identities. . . From each other and third parties? Of course, we want to keep secret the contents of the request and the amount of money in question What impact would this have on law enforcement? Is it good for society that this is possible? Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.14/28
15. Bitcoin and Anonymity — Pseudonymity “Address” is the digest of a public key Must equal the digest derived from the public key presented by the certifier, and Digital signature by the certifier must be verified with the public key ⇒ Has corresponding private key ⇒ authorized user Existence of an entity can be inferred if the same “address” is used more than once However, it is not known which specific individual the subject is (no linkability) Once it is linked somewhere, anonymity is stripped Ex : tied to a bank account at an exchange Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.15/28
16. Bitcoin and Anonymity — Linkability Just one-time use of the same “address” is encouraged They try to minimize the extent to which they are identified when an address is linked to some identity. . . Since “address” is actually referred to as TX input, a series of addresses can be clustered to estimate the existence of a subject by analyzing the appearance distribution Ex : D.Ron and A.Shamir, “Quantitative Analysis of the Full Bitcoin Transaction Graph” https://eprint.iacr.org/2012/584.pdf Ex : S.Meiklejohn et al., “A Fistful of Bitcoins: Characterizing Payments Among Men with No Names” http://conferences.sigcomm.org/imc/2013/papers/ imc182-meiklejohnA.pdf Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.16/28
17. Mixing (Concealing Recipients) " # 4IBSFE
    8BMMFU BEESFTT
     BEESFTT
     BEESFTT
     BEESFTT
     
    #5$ 
    #5$ 
    #5$ 
    #5$ "DDPSEJOH
    UP
    UIF
    VTFST`
    JOTUSVDUJPOT UIF
    NPOFZ
    JT
    USBOTGFSSFE
    GSPN
    "
    UP
    # $
    UP
    %
    BOE
    
    DPNNJTTJPO
    JT
    DIBSHFE CVU
    UIF
    SFMBUJPOTIJQT
    CFUXFFO
    "
    BOE
    # $
    BOE
    %
    BSF
    VOLOPXO
    GSPN
    UIF
    UY
    IJTUPSZ % $ Mixing operators know the secret . . . is there any possibility of undercover investigations in which law enforcement is in fact in charge of mixing? Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.17/28
18. TumbleBit Eliminates trust in mixing in Bitcoin Assumes “tumbler” for mixing (but you can’t trust them) Protocol to send 1 BTC from Alice to Bob (1) Tumbler makes time-limited deposit of 1 BTC on blockchain (upon Bob’s request) Bob’s signature and the solution of a puzzle will release this 1 BTC (2) Bob blindfolds (like multiplies by a random number) the puzzle (that tumbler can still solve, but they don’t know for whom it was made), and sends it to Alice (3) Alice blindfolds the sent puzzle once again (tumbler can still solve it) (4) Alice makes a time-limited deposit of 1 BTC on blockchain This 1 BTC can be obtained with tumbler’s signature and the solution to the double-blindfolded puzzle (5) Tumbler gets the 1 BTC with signature and solution to the double-blindfolded puzzle This solution is a double-blindfolded version for the original puzzle, and cannot unlock the payment to Bob (6) Alice takes away one blindfold from the solution, and sends it to Bob (7) Bob takes away one more blindfold from the solution, gets the real solution to the original puzzle, and gets 1 BTC Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.18/28
19. Applications and Demonstrations : Automated Escrow An attempt to automate real-estate brokerage, banking, and Legal Affairs Bureau (or judicial scrivener) Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.19/28
20. ex. Automated Escrow to Purchase Land (automation of centers) %FpOFE
    b"JS` SFUVSO
    MBOE 1VSDIBTF
    $POUSBDU -BOE
    "TTFU MBOE EFQPTJU USBOTGFS
    MBOE
    SJHIUT
    UP
    CVZFS USBOTGFS
    QBZNFOU
    UP
    TFMMFS QBZNFOU EFQPTJU %JHJUBM
    5PLFO DSFBUF
    BOE
    pY
    JO
    UIF
    BJS FJUIFS
    DBO
    EP
    UIJT DSFBUF
    BOE
    pY
    JO
    UIF
    BJS DBO
    GSFFMZ
    KPJO
    BOE
    MFBWF DBO
    GSFFMZ
    KPJO
    BOE
    MFBWF 4FMMFS #VZFS JOUFSOBM TUBUF SFUVSO
    NPOFZ TFUUMF USBOTGFS JOUFSOBM TUBUF USBOTGFS JOUFSOBM TUBUF     1. Purchase contract is fixed in the air to prevent taking away of land or money (both parties can verify the contract) 2. Deposit land rights and purchase money in the contract (if they change their minds, they can take them back) 3. When settled (anyone can do it if both right and money are deposited), the rights and money for the property are transferred simultaneously Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.20/28
21. Sample Code and Demo git clone from GitHub $ git clone https://github.com/ks91/sample-smart-contracts.git Follow README 1. Setup a sample token project with brownie Brownie is a Python-based Ethereum programming and test environment Javascript-based one is called Truffle, and an Ethereum remote procedure call client is called Ganache See? Engineers are fun people to work with! 2. Copy the content of contracts, scripts and tests directories of this sample project into the corresponding directories of the token project 3. Compile 4. Test Today, I will demonstrate manually the test for automated escrow Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.21/28
22. settle() from OneTimeEscrow function settle() public returns (bool) { require(_token_.balanceOf(address(this)) >= _price_); /* ’this’ means this contract */ require(_asset_.getOwner() == address(this)); _token_.transfer(_seller_ , _price_); _asset_.transfer(_buyer_); emit Settled(); /* event log */ return true; } Just to introduce the settle() part from the sample code Only if both the price and the asset are deposited with the contract, It transfers money to the seller and asset to the buyer Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.22/28
23. Open console and connect to Ropsten testnet Use brownie console >>> network.disconnect() # disconnect from the default, simulated environment of Ethereum >>> network.connect(’ropsten’) >>> len(accounts) 0 >>> accounts.add(paste the hexadecimal string of the private key here) <LocalAccount object ’hexadecimal string of the account’> >>> accounts[0].balace() Here is the ETH balance of the account We set up two accounts Once you have created multiple accounts, you can try to transfer ETH, for example as follows >>> accounts[0].transfer(accounts[1], "1 ether") But before that, you may want to feed the accounts with Ropsten ETH from some public faucet Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.23/28
24. Test Code (1) from brownie import * import pytest def test_deploy_and_settle(Token, IndivisibleAsset, OneTimeEscrow): asset = accounts[0].deploy(IndivisibleAsset, "5322 Endo", "mˆ2", 300) token = accounts[0].deploy(Token, "Test Token", "TEST", 18, "1000 ether") Deploying token and asset contracts The above is just the test code as it is, so in the console we will just type the inside of the function First, let’s do seller = accounts[0] and buyer = accounts[1] for readability Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.24/28
25. Test Code (2) token.transfer(accounts[1], 300, {’from’: accounts[0]}) escrow = accounts[0].deploy(OneTimeEscrow, token, accounts[1], asset, accounts[0], 300) Sending 300 coins from seller (accounts[0]) to buyer (accounts[1]) to prepare Because the buyer has to cast a transaction that pays 300 coins Deploying Escrow Contracts Buyer is accounts[1], seller is accounts[0], and the price is 300 coins Since we are using the sample arguments of the baked Token as they are, 300 coins is actually a very small unit, like wei in ETH Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.25/28
26. Test Code (3) token.transfer(escrow, 300, {’from’: accounts[1]}) asset.transfer(escrow, {’from’: accounts[0]}) assert token.balanceOf(accounts[0]) == 999999999999999999700 assert token.balanceOf(accounts[1]) == 0 assert token.balanceOf(escrow) == 300 assert asset.getOwner() == escrow Buyer (accounts[1]) deposits 300 coins in escrow, and Seller (accounts[0]) deposits the asset in escrow assert tests a statement, and fails the test if it turns out to be false But we are in console (not doing an automated test), so we just see the values Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.26/28
27. Test Code (4) escrow.settle({’from’: accounts[0]}) assert token.balanceOf(accounts[0]) == 1000000000000000000000 assert token.balanceOf(accounts[1]) == 0 assert token.balanceOf(escrow) == 0 assert asset.getOwner() == accounts[1] Calling settle() and closing the transaction In this code, it is called by seller (accounts[0]), but it is OK to call from either side Let’s see some transactions on an Ethereum Ropsten testnet explorer Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.27/28
28. See You Next Week! Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-11 – p.28/28