Applications (1) FinTech — Financial Innovation and the Internet 2019 Fall Kenji Saito Professor, Graduate School of Business and Finance, Waseda University [email protected] Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.1/32
Smart Contract 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 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.4/32
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 2019 Fall — 2019-12-13 – p.5/32
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 2019 Fall — 2019-12-13 – p.6/32
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 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.7/32
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 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.8/32
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(balances), H(post-tx balances), H(remittance)], πs ) Verifies receiving by V (vkr , [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 2019 Fall — 2019-12-13 – p.9/32
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 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.11/32
Countermeasures . . . how to improve the class 13 out of 16 students submitted (as of this morning) (better later than never) Some of you looked up how it is done in Zcash, that’s clever! All of you tried to write down algorithms (instead of mumbling), that’s good! All of you seem to have foun that a perfect solution is very difficult Please take a look at everyone’s report on Course N@vi, because each report is rather too long to show on the pages of the slides Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.12/32
as with a trusted agent They must share keys and addresses, but not balances The agent will know their addresses, and keep it secret . . . ⇒ Basically, the idea seems like a mixing service by a trusted agent Mixing is described later in the slides Mixing has a potential problem of relying on a third party Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.13/32
1 and 100 yen How to verify that the remittance amount is the same? First, Peggy enters a cave which has rooms numbered from 1 to 100 . . . ⇒ Interesting idea for confirming some agreement without revealing each other’s identity But it is difficult to make remittances by this alone Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.14/32
a UTXO is called a “commitment”, and spending a commitment involves revealing a “nullifier” . . . ⇒ Refers to shielded transactions with Zcash Then again, sharing a secret number between parties may be OK, but it is difficult to do it while hiding each other’s identity An example of a problem requiring that level of concealment is described later Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.15/32
example, sender is ABC, receiver is DE and amount is 6 We can first transfer sABCrDEa6 into digits using maybe ASCII code or whatever code . . . ⇒ Don’t know if i really got it, but it seems relatively easy to decrypt the cipher? Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.16/32
. ⇒ Using digests of addresses instead of addresses themselves Clever, but it is subject to dictionary attacks Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.17/32
. . 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 2019 Fall — 2019-12-13 – p.18/32
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 2019 Fall — 2019-12-13 – p.19/32
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 2019 Fall — 2019-12-13 – p.20/32
#5$ #5$ #5$ #5$ "DDPSEJOHUPUIFVTFST`JOTUSVDUJPOT UIFNPOFZJTUSBOTGFSSFEGSPN"UP# $UP% BOEDPNNJTTJPOJTDIBSHFE CVUUIFSFMBUJPOTIJQTCFUXFFO"BOE# $BOE%BSFVOLOPXOGSPNUIFUYIJTUPSZ % $ 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 2019 Fall — 2019-12-13 – p.21/32
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 Bob’s signature and the solution of a puzzle will release this 1 BTC (2) Bob blindfolds the puzzle (that tumbler can 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 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 (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 puzzle, and gets 1 BTC Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.22/32
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 2019 Fall — 2019-12-13 – p.23/32
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 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.24/32
clone https://github.com/ks91/sample-smart-contracts.git Follow README 1. Setup a sample token project with brownie 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 2019 Fall — 2019-12-13 – p.25/32
some of the functions of a university From a real example from “Meta University” Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.26/32
: //eg.beyond − blockchain.org/metauniv/? query string (important!) certificate = %3Cc%3E%3Cid . . . URL-encoded certificate (XML) & subtree = r − 7aa6334a311b357ed6 . . . Merkle subtree SAMPLE Since the URL is very long, we have shortened it to QR code, but. . . Expanded URL must be save for later proof (URL-shortening service may discontinue) Format of the graduation certificate is described later UTF-8/URL-encoded names and other information are listed as they are, but kept secret by HTTPS ⇒ Accessing to the above URL shows “Certificate is Verified!” and “The existence and the content of the following certificate is verified by matching the calculated Merkle root with the one stored in the Ethereum smart contract below.” What does it mean? BTW the certificate is real, but concealing the identity of the graduate (also the URL uses general verifier instead of one dedicated for Meta Univ.) Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.27/32
_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 Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.28/32
stop or discontinue? ⇒ Even if it is stopped or discontinued, as long as there is a copy of the Ethereum blockchain somewhere in the world, you can read from it Can we renew or cancel a certificate? ⇒ BBc-1 library (bbc1-lib-registry) being used has a mechanism to update certificates Don’t you need a digital signature? ⇒ Good question! This time, handling key pairs would be cumbersome, so we omitted it, but BBc-1 allows “a signature by someone in a specific role” (in this case, president or university), or “verification of the signature by someone with the role at some point in the past” · Past digital signatures are generally difficult to verify, given possible leakage of private keys and obsolescence of technology, but BBc-1 presents a design that addresses and solves these challenges If it’s not digitally signed, can’t anyone forge it using the same mechanism? ⇒ Good question again! So we published the Merkle root for Meta Univ. 2019 graduation : 93565db44ffeeb2945e97695265c0578ad2c9e75b958344cb5b8dfa9615d2bc6 (hexadecimal) Lecture 11 : Other Ledger Technology and Applications (1) — FinTech — Financial Innovation and the Internet 2019 Fall — 2019-12-13 – p.31/32
ks91
nina01
andpad
sat
koki_nishihara
nakasho
databricksjapan
chibiegg
kongmingstrap
ohbarye
sansantech
recruitengineers
kyohmizu
tanoku
kastner
myddelton
bcantrill
vanstee
gr2m
andyhume
carmenintech
eitanlees
rasmusluckow
addyosmani
trallard
