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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
_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
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
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
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
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
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
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
ks91
sudoakiy
chanyou0311
sakaitakeshi
ryder472
knih
.png){kind=icon}
pharma_x_tech
maimyyym
kanzaki
narirou
mizdra
nikkei_engineer_recruiting
recruitengineers
tammyeverts
holman
iamctodd
bkeepers
chriscoyier
vanstee
stephaniewalter
sstephenson
aarron
reverentgeek
palkan
kneath
