Financial Innovation and the Internet 2019 Fall Kenji Saito Professor, Graduate School of Business and Finance, Waseda University [email protected] Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.1/28
Blockchain Problems of blockchain Blockchain’s true worth and the “last will test” Prove that data digitally signed at a cetain past point of time has not been tampered with since then Even after the private key is leaked Assignment Review Science fiction prototyping of smart contracts Smart Contracts and Ethereum Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.4/28
Programming Programming language Characteristics and challenges Blockchain and Smart Contract Example : automated escrow for purchasing a land Example : ADEPT and a washing machine Authenticity of contracts and how to disappear Assignment — a hard one ;) — how to disappear completely Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.5/28
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 (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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.7/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.8/28
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 Contract ⇐ coherence of manifestation of intention between the parties Authenticity is ensured by being written in blockchain Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.9/28
JOWPLF DPOUSBDUDPEF NFTTBHFPSBOFXBVUPOPNPVTPCKFDU EBUBFYDIBOHFEBNPOHBDDPVOUTPS&UIFS TUPSBHF TUBUF` TFUPG USBOTBDUJPOT EJHJUBMTJHOBUVSF &7. IVNBO GPSFYBNQMF BVUPOPNPVT PCKFDU Triggered when an autonomous object receives a message, runs a contract code, 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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.10/28
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 Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.12/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.14/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.15/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.16/28
a land Example : ADEPT and a washing machine Meaning of smart contracts in the narrow sense Authenticity of contracts How to hide the content of transactions Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.17/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.18/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.19/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.20/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.21/28
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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.22/28
3 parts G is Generator : G(λ, C) → (pk, vk) where C is a circuit, λ is a secret Circuit 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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.23/28
hash function H The contract manages H(a’s balance) for all accounts a Cs (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) Cr (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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.24/28
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 (vks , [H(balance s ), H(post-tx balance s ), H(remittance)], πs ) Verifies receiving by V (vkr , [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 — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.25/28
method of remittance using zk-SNARKs that conceals the following, and write the algorithm briefly (in English) Who sends money? To whom? 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 11, 2019 at 17:59 JST From Course N@vi Lecture 10 : Smart Contracts — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-06 – p.27/28