WEBVTT 00:00.000 --> 00:19.720 The interesting part of blockchain technology isn't so much the database itself. 00:19.720 --> 00:25.000 How the same database can be used by a network of strangers who don't trust each other. 00:25.000 --> 00:29.120 Without essential authority, this isn't an easy task. 00:29.120 --> 00:35.440 To achieve it, blockchain networks rely heavily on a mix of game theory and cryptography. 00:35.440 --> 00:39.320 In this module, we're going to take a deeper dive into those mechanisms. 00:39.320 --> 00:43.680 It would make much sense for your bank to have a public document detailing every transaction 00:43.680 --> 00:45.400 between users. 00:45.400 --> 00:49.240 Due to their centrally-seed clients' server model, they can validate transactions in 00:49.240 --> 00:50.240 privacy. 00:50.240 --> 00:53.800 A blockchain, though, is a public database-y. 00:53.800 --> 00:58.680 Everyone needs to be able to look at a transaction and say with certainty that it's valid. 00:58.680 --> 01:04.000 If someone adds data that says, Alice gives 50,000 coins to Bob, how can we say that Alice 01:04.000 --> 01:05.880 authorized the transaction? 01:05.880 --> 01:08.720 Who's to say that Bob didn't just add it himself? 01:08.720 --> 01:13.080 Maybe you could have some kind of password system, but that gives you two options. 01:13.080 --> 01:17.320 Whether you use a centralized entity to check them, or Alice publishes her password for 01:17.320 --> 01:19.160 every transaction. 01:19.160 --> 01:21.920 The former doesn't work in a decentralized setting. 01:21.920 --> 01:24.640 You might as well just use a regular database. 01:24.640 --> 01:28.240 The latter doesn't work because everyone would know Alice's password. 01:28.240 --> 01:32.920 After her first transaction, anyone could make a transaction masquerading as her. 01:32.920 --> 01:34.600 To get around this. 01:34.600 --> 01:40.120 We use cryptography, which involves the transformation of data for secure communication. 01:40.120 --> 01:44.200 Even if an adversary intercepts a message from Alice to Bob, they won't be able to decipher 01:44.200 --> 01:46.560 it without a special key. 01:46.560 --> 01:50.320 Something like the Vinner cipher is what we call symmetric encryption. 01:50.320 --> 01:56.400 For example, we can use the key Hodell to transform our plaintext into cipher text. 01:56.400 --> 02:00.760 It's not impossible, but it'll be time-consuming for an adversary to figure out what the plain 02:00.760 --> 02:03.480 text is without knowing the key. 02:03.480 --> 02:08.480 However, if we give someone the key, we use to encrypt the message, they can use it to 02:08.480 --> 02:09.880 decrypt it. 02:09.880 --> 02:11.440 That's why it's symmetric. 02:11.440 --> 02:14.400 The same key is used to encrypt and decrypt. 02:14.400 --> 02:19.280 The thing we're interested in here is public key, cryptography, in which you use a pair 02:19.280 --> 02:25.800 of keys, a private key that you keep secret, and a public key that you can share. 02:25.800 --> 02:30.800 Both keys are linked, so by using your private key, you can easily generate the corresponding 02:30.800 --> 02:32.280 public key. 02:32.280 --> 02:34.080 But this only goes one way. 02:34.080 --> 02:38.320 It's virtually impossible for someone to take a public key and reverse engineer it to 02:38.320 --> 02:40.080 get the private key. 02:40.080 --> 02:44.200 Therefore, there's no security risk to you sharing the public key. 02:44.200 --> 02:48.080 In fact, you need to share it to make transactions. 02:48.080 --> 02:52.720 Private key holders can write a message and digitally sign it using their private key. 02:52.720 --> 02:57.080 By comparing a public key with a signature, you can safely assume that the person who owns 02:57.080 --> 02:59.960 the private key has written the message. 02:59.960 --> 03:03.360 This is an important building block and blockchain systems. 03:03.360 --> 03:08.960 The private key acts like a password, or rather an identity, generated mathematically. 03:08.960 --> 03:14.400 By using your private key to sign a message, certify that you're not authorizing an action. 03:14.400 --> 03:16.400 That's why you should never share it. 03:16.400 --> 03:21.320 Anyone who knows your private key can produce a valid signature to spend your money or otherwise 03:21.320 --> 03:22.920 impersonate you. 03:22.920 --> 03:28.960 In a nutshell, blocks are made up of messages that say something like, I Alice, pay 50,000 03:28.960 --> 03:34.360 coins to Bob, and here is my signature to prove I authorized this transaction. 03:34.360 --> 03:38.720 That message gets passed around the peer-to-peer network as users check that the signature 03:38.720 --> 03:41.040 matches Alice's public key. 03:41.040 --> 03:44.920 If it doesn't, they ignore, and the transaction won't get validated. 03:44.920 --> 03:49.000 So, we figured out how to stop people from spending Alice's funds. 03:49.000 --> 03:53.040 But we haven't figured out how to prevent Alice from spending the same funds twice. 03:53.040 --> 03:56.280 How do we decide which transaction to include in the blockchain? 03:56.280 --> 03:57.440 Who decides? 03:57.440 --> 04:00.240 How do we reach a consensus decision in a distributed system?