Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

FinTech - Lecture 10 : Smart Contracts (2)

FinTech - Lecture 10 : Smart Contracts (2)

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

Kenji Saito

December 04, 2020
Tweet

More Decks by Kenji Saito

Other Decks in Technology

Transcript

  1. QIPUPCZ0MJWFS) FinTech — Financial Innovation and the Internet 2020 Fall

    Lecture 10 : Smart Contracts (2) Kenji Saito Professor, Graduate School of Business and Finance, Waseda University Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.1/39
  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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.2/39
  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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.3/39
  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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.4/39
  5. Last Week, We Did. . . Possibilities and Impossibilities of

    Blockchain – Continued Problems of blockchain Blockchain’s true worth and the “last will test” Assignment Review Smart Contracts and Ethereum Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.5/39
  6. Today’s Topic Smart Contracts and Ethereum (revisited) Overview Smart Contract

    Programming Programming language Characteristics and challenges Blockchain and Smart Contract Example : automated escrow for purchasing a land ← for next week Example : ADEPT and a washing machine Authenticity of contracts, demonstraion, and how to disappear Assignment — a hard one ;) — how to disappear completely Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.6/39
  7. Overview of Ethereum Blockchain and State Transition EVM (Ethereum Virtual

    Machine) Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.7/39
  8. What is Ethereum? Vitalik Buterin, “Ethereum White Paper: A NEXT

    GENERATION SMART CONTRACT & DECENTRALIZED APPLICATION PLATFORM” Applying blockchain technology Targeted average block interval : 15 seconds Put a programming language on it Turing complete = can emulate a universal Turing machine = can emulate computers (well that’s almost a definition of a programming language) Foundation for DApps (applications that automate the center) An attempt to make the current financial and monetary system obsolete That’s what smart contracts are all about Automate digital asset transfers and their state transitions Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.8/39
  9. Blockchain and State Transitions TUBUF FYUFSOBMBDUPST BDDPVOU &7.DPEF &UIFSˠHBT JOWPLF

    DPOUSBDUDPEF NFTTBHFPSBOFXBVUPOPNPVTPCKFDU EBUBFYDIBOHFEBNPOHBDDPVOUTPS&UIFS TUPSBHF TUBUF` TFUPG USBOTBDUJPOT EJHJUBMTJHOBUVSF &7. IVNBO GPSFYBNQMF Blockchain = Run of a state machine (state transition system) = Operation of a computer Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.9/39
  10. Glossary Ether (ETH) Native currency of Ethereum (compensation for mining)

    External Actor A real person/entity who can digitally sign, having an account EOA : Externally-Owned Account Autonomous Object (internal actor) Operates autonomously within the system, and has an account That said, if you don’t send a message, it won’t work (and miners run them) Account Has an Ether balance, and can have storage (state) and EVM code EVM Code Smart contract program Smart contract = application program on Ethereum = intelligent contract Authenticity is ensured by being written in blockchain Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.10/39
  11. EVM : Ethereum Virtual Machine TUBUF FYUFSOBMBDUPST BDDPVOU &7.DPEF &UIFSˠHBT

    JOWPLF DPOUSBDUDPEF NFTTBHFPSBOFXBVUPOPNPVTPCKFDU EBUBFYDIBOHFEBNPOHBDDPVOUTPS&UIFS TUPSBHF TUBUF` TFUPG USBOTBDUJPOT EJHJUBMTJHOBUVSF &7. IVNBO GPSFYBNQMF BVUPOPNPVT PCKFDU Triggered when an autonomous object receives a message, performs a contract, and changes state Gas must be supplied for each execution step (to avoid an infinite loop and to compensate EVM executor = miner) Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.11/39
  12. Technical Challenges of Blockchain Non real-time (probabilistic behavior) Difficulty of

    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) 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.12/39
  13. Ethereum’s Approach (solutions blockchain-way) Non real-time (probabilistic behavior) ⇒ Towards

    transaction finalization mechanism (Casper) 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, 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.13/39
  14. BBc-1’s Approach (solutions non-blockchain-way) Non real-time (probabilistic behavior) ⇒ No

    probabilistic behavior before transaction commits Difficulty of secrecy (guarantee of verifiability to all) ⇒ Transaction content is kept secret outside the domain, and can be encrypted inside Oneness (distribution vs. replication) Not scalable (do not scale if replicated to all participants) ⇒ Scale-out on a domain-by-domain basis, intra-domain DHT in the future Harder governance of evolution (can’t change if everyone needs to be united) ⇒ Autonomy by domain (don’t care about intra-domain protocols) Incentive mismatch (discrepancy of motivations for participation in infrastructure and applications) Supported by the value of the native currency (crash would stop all applications) ⇒ No native currency, proof of context work by mutual aid Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.14/39
  15. Smart Contract Programming Programming language Characteristics and challenges Lecture 10

    : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.15/39
  16. Programming Language EVM interprets bytecode (instruction set for virtual machines

    or interpreters) Programmers don’t usually program in bytecode or machine languages — although some do ;) Requires compilers for other, high-level languages High-level language : human-readable/writable language On the other hand, languages close to machines are called low-level languages . . . We may be scolded by artificial intelligence in the near future ;) Examples : Solidity — JavaScript-like language Current primary language Vyper — Python-like language LLL — Lisp-like language Fe — Rust-like features with reference to Vyper? ← NEW! Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.16/39
  17. Solidity Sample Code (this is a high-level language!) pragma solidity

    >=0.4.18 <0.6.0; contract IndivisibleAsset { /* transfer ownership of non-divisible assets */ string public _name; string public _symbol; uint256 public _quantity; address public _owner; constructor(string name, string symbol, uint256 quantity) public { _name = name; _symbol = symbol; _quantity = quantity; _owner = msg.sender; } function transfer(address to) public returns (bool) { require (_owner == msg.sender); _owner = to; return true; } } Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.17/39
  18. Another Solidity Sample Code (snippet) . . . function transfer(address

    to, uint256 value) public returns (bool) { balances[msg.sender] = balances[msg.sender] - value; balances[to] = balances[to] + value; return true; } . . . This can be the core of a (not-so-secure) token contract Without considering overflow/underflow A token contract typically manages the balances of all users Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.18/39
  19. Features of Programming Language Solidity JavaScript-like Object-oriented Describe a contract

    as a template (type or class) Constructor is called during deployment Deploy here means to deploy the contract to the blockchain Decides what parameters to pass to the constructor upon deployment Conforms to Ethereum programming model Deployed contract is a specific entity (instance) Has an account (identified by the address, just like a human user) Has storage and ETH balance Can send messages to other contracts Model where deployed contracts are manipulated by sending messages On the assumption that the authenticity of the code that responds to the message is guaranteed Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.19/39
  20. Characteristics and Challenges Characteristics Execute the program during the block

    validation process, and reflect the results in the “world state” Redundant verifiers Closed within the state of blockchain (maintained by the verifiers) This design is consistent in the Ethereum system Challenges I/O commands cannot be issued from within the program Not affected by the outside world other than external actors who send signed messages ⇒ ex. Data from sensors cannot be read directly Not able to directly affect the outside world ⇒ ex. Cannot send commands to the motor to turn it on/off Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.20/39
  21. Blockchain and Smart Contracts Example : automated escrow to purchase

    a land ← to be demoed next week Example : ADEPT and a washing machine Meaning of smart contracts in the narrow sense Authenticity of contracts Demonstration, and understanding applications of blockchain How to hide the content of transactions Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.21/39
  22. Promise Fixation Device in the Air (no matter if it’s

    made of a chain of blocks) %FpOFEb"JS` HMPCBMqBUTQBDFGPSBQVCMJDCMPDLDIBJO PQ*' QSPNJTFPSBTTFU DSFBUFBOEpYJOUIFBJS USBOTGFSSJHIU DBOGSFFMZKPJOBOEMFBWF DBOGSFFMZKPJOBOEMFBWF PQFSBCMF SFRVJSFT EJHJUBMTJHOBUVSF DBOSFGFSGSPN XJUIJOUIFTBNFTQBDF QBSUJDJQBOU QBSUJDJQBOU QBSUJDJQBOU QBSUJDJQBOU QBSUJDJQBOU JOUFSOBMTUBUF PQ*' PQ*' SFG*' The defined air is maintained solely by the participants (no specific administrator) Promises/assets can only be manipulated by authorized participants Promises/assets can survive as long as the defined air survives, since they are not maintained by any particular party Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.22/39
  23. ex. Automated Escrow to Purchase Land (automation of centers) %FpOFEb"JS`

    SFUVSOMBOE 1VSDIBTF$POUSBDU -BOE"TTFU MBOE EFQPTJU USBOTGFSMBOESJHIUTUPCVZFS USBOTGFSQBZNFOUUPTFMMFS QBZNFOU EFQPTJU %JHJUBM5PLFO DSFBUFBOEpYJOUIFBJS FJUIFSDBOEPUIJT DSFBUFBOEpYJOUIFBJS DBOGSFFMZKPJOBOEMFBWF DBOGSFFMZKPJOBOEMFBWF 4FMMFS #VZFS JOUFSOBM TUBUF SFUVSONPOFZ 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.23/39
  24. ADEPT and a Washing Machine ADEPT : IoT (Internet of

    Things) research project by IBM ADEPT stands for Autonomous Decentralised Peer-to-Peer Telemetry An example of a washing machine connected with blockchain What for? Blockchain cannot control motors Each miner is processing by their own timing → I/O commands cannot be issued from within the blockchain ⇒ Designed behavior to match the “narrow sense” Order detergent! A system for automatically transferring and transitioning digitally represented assets according to predetermined rules Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.24/39
  25. Authenticity of Contracts Anyone can participate in block validation and

    contract execution as a verifier ⇒ Everyone has access to the contract code It is in principle verifiable that the correct contract is being executed I/O is outside blockchain → this is possible without revealing the entirety of the agreement True worth of smart contract is that everyone can confirm that “the correct contract was executed”? Program code and its execution results as “record whose contents and existence cannot be denied by anyone” But Ethereum’s method should not be the only one There are many issues including how to manage the contracts’ life cycles We have already talked about The DAO Incident Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.25/39
  26. Demonstration Based on the following sample API/App of BBc-1 and

    Ethereum https://github.com/beyond-blockchain/examples/tree/master/certify-web 1. Creates digital ID cards for Addams’ family members Digitally signed by a local government Proofs of existence of the cards are verified This conceptually allows them to make verifiable digital signatures (because their public keys are on their cards) 2. Hides their ID numbers on the cards to see if they are still verifiable Presumably, the ID numbers are used for opening bank accounts and so on Better to hide them when the ID cards are used just for identification (really?) Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.26/39
  27. Example ID Card Document { "id": "4445 4558 1689", "name":

    "Wednesday Addams", "born": "1980-02-12", "address": "0001 Cemetery Lane", "public-key": "04d49e0786a37efce8552d6fd1566d7cfd86f110d4d95f1...4edb", "algo": "ecdsa-p256v1", "sig": "609b390f9486110d1ba39fc59cc46f1c2aa31ae8e40d3454c05a42...48e2", "pubkey": "0479c6676de61b41b7d0291b338f3279671d649f0a71bbb495...4bd1", } Local government has certified this document by digitally signing the structure And then the digest of the signed document is put into Ethereum blockchain (after forming a Merkle tree), and existence of the document becomes verifiable Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.27/39
  28. Document Digest Calculation in the Sample ID Card Doc <id>4445

    4558 1689</id> <name>Wednesday Addams</name> of Wednesday Addams of the local government <born>1980-02-12</born> <address>0001 Cemetery Lane</address> <public-key>04d49e...1c4edb</public-key> Digest of ID Card Doc Digest of Signed ID Card Doc Calculated after concatination Calculated after verifying signature and concatination digest digest digest algorithm signature public key digest digest digest digest * JSON data structures are translated into XML structures for processing. * The digest is computed for each section so that it can be proven even if partially concealed. * For example, if seeing the ID number is not allowed by the law if the ID card is used for just checking the person’ s age or address, or even public key, the certificate may be proven without disclosing the ID number. * "Digest" is a value calculated by a cryptographic hash function (SHA -256 this time). If the original data differs even by just 1 bit, the returned value is completely different, and the original data cannot be inferred from the digest. Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.28/39
  29. Merkle Proof in the Sample API/App EPD  EJHFTU EJHFTU

    EJHFTU EJHFTU EJHFTU EJHFTU EJHFTU EVQMJDBUFJO DBTFPGPEE OVNCFS 6QPOSFDFJWJOHEPD "MJDFBMTPSFDFJWFTEJHFTUTTIPXOJOCMVFBOEXIFUIFSUIFZBSFPOUIFMFGUPSSJHIU 4UBSUJOHXJUIUIFEJHFTUPGEPD "MJDFXJMMLOPXUIFTFSJFTPGEJHFTUTUPCFDPODBUFOBUFE TPTIFDBOSFQSPEVDFUIFDBMDVMBUJPOTVQUP UIF.BSLMFSPPUBOEDPOpSNUIBUUIFSFTVMUJOH.BSLMFSPPUNBUDIFTUIFWBMVFSFDPSEFEJOUIF&UIFSFVNTNBSUDPOUSBDU ##D"ODIPSTPM  5IFTBNQMF"1*EPFTUIFNBUIGPSZPV BOZPOFDBOSFQSPEVDFJUJGUIFZVOEFSTUBOEUIFQSJODJQMFBOEIBWFJOGPSNBUJPO  SFDPSE DBOSFUSJFWFJOGPSNBUJPO *OGPSNBUJPOEJTDMPTFE UPQBSUJFTSFRVJSJOH DFSUJpDBUFT "MUIPVHI##DTUPSFTUIJT TUSVDUVSF ##DJTOPUSFRVJSFE GPSQSPPGCFDBVTFBMMTVCUSFFTIBWF BMSFBEZCFFOQBTTFEUPUIPTF JOUFSFTUFEQBSUJFTBTDFSUJpDBUFT QVCMJDJOGPSNBUJPO .FSLMFSPPU .FSLMFUSFF LFQUCZUIFTFSWJDF BOETFOUQBSUJBMMZUPFBDIDMJFOU ʜʜ ʜʜ ʜʜ ʜʜ ʜʜ EJHFTU EJHFTU EJHFTU EJHFTU EJHFTU EJHFTU &UIFSFVNCMPDLDIBJO ʜ ʜ 4USVDUVSFJTDSFBUFECZ ##D-JCSBSZ  $FSUJGZ8FCTBNQMF"1* EPD  EPD  EPD  EPD O Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.29/39
  30. BBcAnchor.sol (excerpt) contract BBcAnchor { mapping (uint256 => uint) public

    _digests; constructor () public { } function getStored(uint256 digest) public view returns (uint block_no) { return (_digests[digest]); } function isStored(uint256 digest) public view returns (bool isStored) { return (_digests[digest] > 0); } function store(uint256 digest) public returns (bool isAlreadyStored) { bool isRes = _digests[digest] > 0; if (!isRes) { _digests[digest] = block.number; } return (isRes); } } Save the block number at the time for the registered digest / This simple code is an all-purpose smart contract Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.30/39
  31. Understanding Applications of Blockchain Token Smart Contract Provenance Fungible Non-redeemable

    Fungible Redeemable Non-fungible Redeemable Non-fungible Non-redeemable Certifying Identifying payment ID card security token last will logistics insurance claim Tracking Sensing fiat money crypto-pet Proves you are the one since you can handle the private key? Transfers numerical representations of debt / asset? Maintains authenticity of registered code, data and resulted states? (Authority) issues certificates about some content? Updates records about sustained presences? Is data still valid even if the subject is gone? Certify Web API makes all applications of blockchain possible in principle In as much sense as all sequential processing can be described in structured programming Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.31/39
  32. How to Disappear Lecture 10 : Smart Contracts (2) —

    FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.32/39
  33. 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.33/39
  34. 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 are executed “off-chain” so to speak Lecture 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.34/39
  35. 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.35/39
  36. 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(balance s ), H(post-tx balance s ), H(remittance)], π s ) Verifies receiving by V (vk r , [H(balance r ), H(post-tx balance r ), 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.36/39
  37. Assignment Lecture 10 : Smart Contracts (2) — FinTech —

    Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.37/39
  38. 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 8, 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 10 : Smart Contracts (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.38/39
  39. See You Next Week! Lecture 10 : Smart Contracts (2)

    — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-04 – p.39/39