1 00:00:00,000 --> 00:00:13,890 *33C3-Vorspannmusik* 2 00:00:13,890 --> 00:00:20,810 Herald: Gut, dann machen wir weiter mit dem nächsten Vortrag. 3 00:00:20,810 --> 00:00:24,509 Der ist von vimja, der ist Informatikstudent aus Bern in der Schweiz, 4 00:00:24,509 --> 00:00:28,740 und er arbeitete bzw. er beschäftigte sich mit Bitcoin 5 00:00:28,740 --> 00:00:32,890 und Ethereum, und schrieb seine Bachelorarbeit über die Suche 6 00:00:32,890 --> 00:00:38,210 nach Informationen in der Bitcoin- Blockchain. Und da macht es total Sinn, 7 00:00:38,210 --> 00:00:43,120 dass der uns jetzt eine Einführung zu Blockchains präsentieren wird. 8 00:00:43,120 --> 00:00:45,580 Ein großer Applaus für vimja! 9 00:00:45,580 --> 00:00:50,030 *Applaus mit Pfeifen und Jubel* Das ist deine Bühne! 10 00:00:50,030 --> 00:00:56,519 *weiterhin Applaus* 11 00:00:56,519 --> 00:00:58,920 vimja: Toll, das ist jetzt gerade kaputtgegangen. 12 00:00:58,920 --> 00:01:05,460 *Gelächter* 13 00:01:05,460 --> 00:01:08,000 So ist es besser. 14 00:01:08,000 --> 00:01:13,230 *Applaus* Danke. 15 00:01:13,230 --> 00:01:19,980 Genau, das geht jetzt natürlich auch nicht. 16 00:01:19,980 --> 00:01:22,240 Mache ich es halt von Hand. 17 00:01:22,240 --> 00:01:27,740 Ist vermutlich, weil ihr alle das Wi-Fi braucht, geht das 2,4-GHz-Band nicht mehr. 18 00:01:27,740 --> 00:01:31,570 Ja das hat er euch ja alles schon gesagt, der Herald. 19 00:01:31,570 --> 00:01:34,680 In dieser Zeit, in der ich mich mit Blockchains befasst habe, 20 00:01:34,680 --> 00:01:39,270 durfte ich natürlich sehr viele sehr interessante Dinge lernen, 21 00:01:39,270 --> 00:01:41,830 und ich möchte jetzt heute abend einen Teil dieses Wissens 22 00:01:41,830 --> 00:01:48,810 an euch weitergeben. Genau. 23 00:01:48,810 --> 00:01:52,710 Das Ganze ist natürlich ein sehr komplexes Thema, das viele komplizierte Dinge 24 00:01:52,710 --> 00:01:56,120 enthält, und deshalb fangen wir jetzt mit etwas sehr einfachem an, was wir alles 25 00:01:56,120 --> 00:01:59,850 kennen. Und zwar herkömmliche Besitzsysteme – also Systeme, 26 00:01:59,850 --> 00:02:04,100 die ausdrücken wem etwas gehört. Und, eigentlich, mit der Erkenntnis, dass man 27 00:02:04,100 --> 00:02:11,190 all diese Besitzsysteme als Zustandsübergangssysteme darstellen kann. 28 00:02:11,190 --> 00:02:16,019 Das gilt sowohl für Finanzsysteme, die wir haben um Geld zu verwalten, 29 00:02:16,019 --> 00:02:20,090 als auch etwa für Grundstücke, also Systeme mit denen wir verwalten, 30 00:02:20,090 --> 00:02:23,490 wem ein Grundstück gehört. 31 00:02:23,490 --> 00:02:27,520 Das Mapping funktioniert dann in etwa so, dass wir sagen, der Zustand ist 32 00:02:27,520 --> 00:02:33,510 die Sammlung der Informationen wem was gehört. Und jedes Übertragen 33 00:02:33,510 --> 00:02:37,720 eines Besitzes ist eine Transition, die zu einem neuen Zustand führt. 34 00:02:37,720 --> 00:02:41,760 Also am Beispiel eines finanziellen Systems sagen wir, der Zustand ist 35 00:02:41,760 --> 00:02:45,879 die Sammlung aller Konten, die es gibt. Das drückt für jede Person aus, 36 00:02:45,879 --> 00:02:51,230 wieviel Geld ihr gehört. Und ein Übergang ist, wenn jemand eine Transaktion macht, 37 00:02:51,230 --> 00:02:54,160 also Geld überweist, von einem Konto zu einem anderen, dann führt das 38 00:02:54,160 --> 00:02:58,440 zu einem neuen Zustand. So, das sehen wir hier abgebildet 39 00:02:58,440 --> 00:03:02,280 mit Grundstücken. Wir sehen hier, der Zustand, der enthält diese Information, 40 00:03:02,280 --> 00:03:06,760 wem die Grundstücke gehören. Und dann verkauft der Bob 41 00:03:06,760 --> 00:03:10,890 sein Grundstück Nr. 42 an Alice und das führt zu einem neuen Zustand. 42 00:03:10,890 --> 00:03:15,660 Ich habe da den Unterschied markiert, damit der eindeutig sichtbar ist. 43 00:03:15,660 --> 00:03:20,410 Nun, in all diesen Systemen ist es sehr wichtig, dass sich alle Teilnehmer des 44 00:03:20,410 --> 00:03:26,150 Systems auf einen Zustand einigen können. Dass sie sich einig sind, wem was gehört. 45 00:03:26,150 --> 00:03:30,050 Denn wenn sie das nicht können, sind Angriffe auf das System möglich, 46 00:03:30,050 --> 00:03:32,950 insbesondere der sogenannte Double-Spend-Angriff, 47 00:03:32,950 --> 00:03:37,840 der in der Blockchain-Welt bekannt und gefürchtet ist. Und was bedeutet das? 48 00:03:37,840 --> 00:03:41,440 Das ist ganz einfach, wenn jemand etwas zweimal ausgibt. Bei Geld ist das ein 49 00:03:41,440 --> 00:03:45,310 wenig abstrakt (also wie gibt man zweimal dasselbe Geld aus), aber bei Grundstücken 50 00:03:45,310 --> 00:03:48,990 ist das ganz einfach. Stellen wir uns vor, jemand verkauft dasselbe Grundstück 51 00:03:48,990 --> 00:03:54,880 zweimal. Das ist natürlich kriminell und darf nicht vorkommen. 52 00:03:54,880 --> 00:03:57,850 Schauen wir uns jetzt mal an wie das funktioniert. Stellen wir uns vor, 53 00:03:57,850 --> 00:04:01,940 Malroy hat ein schönes Grundstück, das Grundstück Nr. 5. Und sowohl Alice 54 00:04:01,940 --> 00:04:05,700 als auch Bob möchten gerne das Grundstück kaufen. Und Malroy 55 00:04:05,700 --> 00:04:10,020 wird jetzt versuchen, das an beide zu verkaufen. Also trifft er sich mit Alice. 56 00:04:10,020 --> 00:04:13,761 Das ist also jetzt der aktuelle Zustand. Wir haben gesehen, das Grundstück Nr. 5 57 00:04:13,761 --> 00:04:20,430 gehört hier dem Malroy. Der trifft sich mit Alice. Und er verkauft es an Alice. 58 00:04:20,430 --> 00:04:24,550 Er überweist ihr das Grundstück. Wir sehen diese Transition – überweist das Grundstück 59 00:04:24,550 --> 00:04:29,129 von Malroy an Alice. Und im neuen Zustand gehört es jetzt der Alice. So, der Bob, 60 00:04:29,129 --> 00:04:31,990 der hat davon nichts mitgekriegt. Irgendwie – Bob und Alice wissen 61 00:04:31,990 --> 00:04:36,300 immer noch nicht recht wie man sicher miteinander kommuniziert. Und deshalb 62 00:04:36,300 --> 00:04:39,199 weiß der Bob jetzt nichts davon, dass die Alice das Grundstück gekauft hat. 63 00:04:39,199 --> 00:04:43,680 Er denkt, das Grundstück gehört immer noch Malroy. Also trifft er sich mit Malroy. 64 00:04:43,680 --> 00:04:47,939 Und auch er einigt sich mit Malroy auf einen Preis. Und Malroy tut jetzt so, 65 00:04:47,939 --> 00:04:52,710 als würde er den Besitz des Grundstücks an Bob übertragen. 66 00:04:52,710 --> 00:04:56,460 Und für Bob sieht die Welt jetzt so aus, d.h. Bob ist überzeugt, das ist 67 00:04:56,460 --> 00:05:00,339 der korrekte Zustand des Systems. Da haben wir natürlich ein Problem, 68 00:05:00,339 --> 00:05:03,290 weil Bob und Alice, die sind sich jetzt gar nicht einig darüber, 69 00:05:03,290 --> 00:05:07,499 wem das Grundstück gehört. Ja, Malroy ist natürlich abgehauen mit dem Geld. 70 00:05:07,499 --> 00:05:10,980 Und das System ist kaputt, weil Bob und Alice die können nicht mehr 71 00:05:10,980 --> 00:05:14,690 miteinander handeln. Und auch wenn jetzt jemand anderes das Grundstück 72 00:05:14,690 --> 00:05:18,749 kaufen möchte: Bei wem kauft er es denn jetzt? Was ist denn rechtmäßig? 73 00:05:18,749 --> 00:05:23,859 Nun, in der Welt der Grundstücke gibt es dafür eine ganz einfache Lösung, 74 00:05:23,859 --> 00:05:27,560 nämlich das Grundbuchamt. Und das Grundbuchamt fungiert eigentlich 75 00:05:27,560 --> 00:05:33,310 als zentrale Referenzstelle, die den Zustand verwaltet, 76 00:05:33,310 --> 00:05:37,460 und alle Änderungen verwaltet. Jedesmal wenn jemand ein Grundstück verkauft, 77 00:05:37,460 --> 00:05:42,089 muss das über das Grundbuchamt erledigt werden. Das Grundbuchamt überprüft, 78 00:05:42,089 --> 00:05:46,020 dass das überhaupt zulässig ist, ob das Grundstück wirklich der Person gehört 79 00:05:46,020 --> 00:05:50,169 und führt das dann nach. Und so kann das Grundbuchamt diese einfachen Angriffe 80 00:05:50,169 --> 00:05:58,960 verhindern. Diese Lösung funktioniert auch für Finanzsysteme. 81 00:05:58,960 --> 00:06:02,770 Also wenn wir an Banken denken, wenn ich ein Konto habe, da ist dann halt die Bank 82 00:06:02,770 --> 00:06:07,289 die zentrale Autorität, welche den Zustand verwaltet. Für jede… jedesmal, 83 00:06:07,289 --> 00:06:11,499 wenn ich eine Transaktion mache, also Geld überweise, überprüft die Bank vorher, 84 00:06:11,499 --> 00:06:15,759 ob ich wirklich das nötige Geld dazu habe. Und dann wird mein Kontostand 85 00:06:15,759 --> 00:06:22,499 nachgeführt. Und die verwaltet so für alle Teilnehmer den Zustand. 86 00:06:22,499 --> 00:06:26,919 Und das funktioniert eigentlich erstaunlich gut. Nun wollen wir ein System, mit dem 87 00:06:26,919 --> 00:06:31,229 wir Zahlungen über das Internet abwickeln können. Und wir hätten gerne, dass das 88 00:06:31,229 --> 00:06:34,849 dezentral ist. Weil, wenn das nicht dezentral ist, dann kann natürlich 89 00:06:34,849 --> 00:06:39,909 eine zentrale Autorität das System zensieren und manipulieren. 90 00:06:39,909 --> 00:06:43,539 Und eine zentrale Stelle kann angegriffen werden. Ich denke, wir haben das alle 91 00:06:43,539 --> 00:06:47,719 in den letzten Jahren beobachten müssen, wie Paypal sehr einfach willkürlich 92 00:06:47,719 --> 00:06:52,650 Konten sperrt, und das System zensiert. So, und deshalb brauchen wir ein 93 00:06:52,650 --> 00:06:56,250 besseres System, eine bessere Lösung für das Internetzeitalter. 94 00:06:56,250 --> 00:06:59,840 Und diese bessere Lösung ist natürlich die ‚Blockchain‘. 95 00:06:59,840 --> 00:07:05,760 Die Blockchain bringt einige ganz unglaubliche Eigenschaften mit sich. 96 00:07:05,760 --> 00:07:09,529 Die Blockchain braucht keine zentrale Stelle um den Zustand zu verwalten. 97 00:07:09,529 --> 00:07:12,930 Die Teilnehmer des Systems müssen sich gegenseitig nicht vertrauen, sie müssen 98 00:07:12,930 --> 00:07:16,419 sich gegenseitig nicht kennen. Sie müssen nicht einmal wissen, wieviele Leute 99 00:07:16,419 --> 00:07:19,990 denn eigentlich da teilnehmen. Und trotzdem können die sich alle immer 100 00:07:19,990 --> 00:07:25,469 auf einen Zustand des Systems einigen. 101 00:07:25,469 --> 00:07:27,960 Ich werde das jetzt demonstrieren, die Regeln, die wir brauchen 102 00:07:27,960 --> 00:07:32,250 um das zu ermöglichen. Anhand einer sehr einfachen Blockchain, 103 00:07:32,250 --> 00:07:35,759 die in diesem ersten Kapitel auch noch keinen Proof-of-Work hat. Also 104 00:07:35,759 --> 00:07:39,149 diese erste Blockchain wird noch angreifbar sein. Und ich werde auch 105 00:07:39,149 --> 00:07:42,970 zeigen wie es geht. Und erst im nächsten Kapitel dann werde ich erklären, 106 00:07:42,970 --> 00:07:47,820 welche Maßnahmen wir ergreifen müssen, um Angriffe zu verhindern. 107 00:07:47,820 --> 00:07:51,659 Und das Ganze fängt an mit dem Netzwerk welches wir nutzen. Also wir sagen quasi, 108 00:07:51,659 --> 00:07:55,039 wir sind alle diese Leute, und wir würden gerne miteinander Transaktionen machen 109 00:07:55,039 --> 00:07:59,759 können. Und zuerst einigen wir uns alle auf einen Ursprungszustand. 110 00:07:59,759 --> 00:08:03,319 Damit fangen wir an. Wir sagen z.B. „am Anfang gehört allen nichts“. 111 00:08:03,319 --> 00:08:08,429 Das ist ein leerer Zustand. Und dann brauchen wir ein p2p-Netzwerk. 112 00:08:08,429 --> 00:08:13,529 Und jedesmal wenn jemand Geld überweist an jemand anderes, dann veröffentlicht er 113 00:08:13,529 --> 00:08:17,490 die Transaktion in diesem Netzwerk, und das Netzwerk leitet die Transaktion 114 00:08:17,490 --> 00:08:21,949 solange an alle Teilnehmer weiter, bis alle Teilnehmer diese Transaktion 115 00:08:21,949 --> 00:08:27,169 gesehen haben. Das bringt natürlich viele Probleme mit sich. 116 00:08:27,169 --> 00:08:29,529 Das Netzwerk ist irgendwie nicht synchronisiert, nicht alle Leute 117 00:08:29,529 --> 00:08:34,510 sehen die gleichen Transaktionen, die Reihenfolge der Transaktionen ist unklar. 118 00:08:34,510 --> 00:08:37,940 Leute werden versuchen das anzugreifen – das wird dazu führen, dass es 119 00:08:37,940 --> 00:08:42,458 Transaktionen gibt die nicht miteinander kompatibel sind. Und irgendwie 120 00:08:42,458 --> 00:08:45,310 Transaktionen, die abhängen von nicht-kompatiblen Transaktionen und 121 00:08:45,310 --> 00:08:49,790 dann auch wieder nicht kompatibel sind. Das ist ein riesengroßes Durcheinander da. 122 00:08:49,790 --> 00:08:52,370 Und deshalb brauchen wir jetzt eine Möglichkeit, wie wir uns alle 123 00:08:52,370 --> 00:08:57,180 auf einen Zustand, auf einen Konsens einigen können. Und – wie gesagt – 124 00:08:57,180 --> 00:09:00,790 das ist jetzt die ‚Blockchain‘. 125 00:09:00,790 --> 00:09:04,420 Und wir definieren einige Regeln, die wir anwenden um uns zu einigen. 126 00:09:04,420 --> 00:09:08,240 Wir sagen, wir gruppieren die Transaktionen die vorher so lose auf dem Netzwerk waren 127 00:09:08,240 --> 00:09:13,470 zu Blöcken. Die Blöcke hängen alle voneinander ab. Wir sagen dann auch, 128 00:09:13,470 --> 00:09:17,780 der aktuelle Zustand des Netzwerks ist das Ende der längsten Kette zusammenhängender 129 00:09:17,780 --> 00:09:22,720 Blöcke. Und die Blöcke müssen einige Kriterien erfüllen. Ich habe das da… 130 00:09:22,720 --> 00:09:26,940 also das ist jetzt quasi der Ur… der leere Zustand, mit dem wir beginnen. 131 00:09:26,940 --> 00:09:32,300 Und da kommen da Transaktionen über das Netzwerk. Und irgendwann 132 00:09:32,300 --> 00:09:34,950 macht jemand einen Block der diese Transaktionen zusammenfasst. Und jetzt 133 00:09:34,950 --> 00:09:39,810 sehen wir am Ende dieses Blocks ist der Zustand. Wenn ich diesen Zustand 134 00:09:39,810 --> 00:09:43,110 nachvollziehen will dann nehme ich den leeren Ursprungszustand, und dann 135 00:09:43,110 --> 00:09:47,080 jede Transaktion aus dem ersten Block, und dann wende ich diese Transaktionen, 136 00:09:47,080 --> 00:09:52,170 eine nach der anderen, auf den Zustand an, und dann erhalte ich den Endzustand. 137 00:09:52,170 --> 00:09:55,421 Mit der Zeit kommen neue Transaktionen rein 138 00:09:55,421 --> 00:10:00,140 über das Netzwerk. Und diese Transaktionen werden nicht Teil des Zustands 139 00:10:00,140 --> 00:10:02,950 – wir haben ja gesagt der Zustand ist das Ende der längsten Kette von Blöcken, 140 00:10:02,950 --> 00:10:06,270 und die sind in keinem Block. Erst wenn jemand einen Block daraus macht, 141 00:10:06,270 --> 00:10:09,890 werden die Teil des Zustands. Wir sehen auch, die Blöcke hängen jeweils 142 00:10:09,890 --> 00:10:13,540 voneinander ab, die haben so einen Pfeil, der sie miteinander verbindet, also 143 00:10:13,540 --> 00:10:18,590 jeder Block zeigt auf den vorhergehenden Block, und bildet so eben diese Kette 144 00:10:18,590 --> 00:10:23,650 von Blöcken. Nun, jetzt versucht trotzdem jemand da eine bösartige Transaktion 145 00:10:23,650 --> 00:10:27,810 zu machen, die mit den anderen nicht kompatibel ist. Da macht jemand 146 00:10:27,810 --> 00:10:32,000 einen Block daraus. Und jetzt sagen wir aber einfach, Blöcke, die 147 00:10:32,000 --> 00:10:35,470 Transaktionen enthalten welche sich widersprechen sind nicht valide. 148 00:10:35,470 --> 00:10:38,360 Der Block, den kann zwar jemand erstellen, aber wir sagen dann, das ist 149 00:10:38,360 --> 00:10:42,180 kein valider Block, der wird vom Netzwerk nicht akzeptiert. Und der wird auch 150 00:10:42,180 --> 00:10:46,450 nicht Teil des Zustands. Also wenn jemand einen Block bauen will und eine dieser 151 00:10:46,450 --> 00:10:52,610 Transaktionen enthält, dann muss sich derjenige der den Block erstellt 152 00:10:52,610 --> 00:10:56,090 entscheiden welche der Transaktionen denn jetzt enthalten sein sollen 153 00:10:56,090 --> 00:11:00,280 in dem Block. Und die anderen lässt er außen vor. Für welche er sich entscheidet, 154 00:11:00,280 --> 00:11:04,660 das ist dem Typen ganz allein überlassen. Er kann das selber entscheiden was er da 155 00:11:04,660 --> 00:11:10,690 reinpacken will. Dann kommen mit der Zeit neue Transaktionen rein. 156 00:11:10,690 --> 00:11:14,300 Und jetzt könnte es sein, dass jemand so einen Block Nummer 4 macht, welcher 157 00:11:14,300 --> 00:11:18,730 jetzt trotzdem wieder die böse Transaktion enthält. Und dann sagen wir aber einfach, 158 00:11:18,730 --> 00:11:21,911 Blöcke welche Transaktionen enthalten, welche nicht kompatibel sind 159 00:11:21,911 --> 00:11:25,450 mit Transaktionen in älteren Blöcken sind auch ungültig, und der Block wird auch 160 00:11:25,450 --> 00:11:29,870 nicht Teil des Zustands. So. Was aber gültig ist, ist jemand der einen Block 161 00:11:29,870 --> 00:11:33,880 Nummer 3 macht, der so aussieht. Und jetzt haben wir das Problem: Wir haben gesagt, 162 00:11:33,880 --> 00:11:36,640 der Zustand ist die längste Kette von Blöcken. Hier ist jetzt der Zustand 163 00:11:36,640 --> 00:11:40,370 nicht mehr eindeutig definiert und da muss jetzt halt jeder Teilnehmer des Netzwerkes 164 00:11:40,370 --> 00:11:44,960 selbst entscheiden wie er damit umgeht, was er jetzt als Zustand anerkennt. 165 00:11:44,960 --> 00:11:48,240 So, aber dann kommen halt neue Transaktionen wieder rein. Und irgendwann 166 00:11:48,240 --> 00:11:52,590 baut jemand einen Block Nummer 4, der diese Transaktion enthält. Und dadurch, 167 00:11:52,590 --> 00:11:57,920 dass der Block Nr. 4 auf den vorherigen Block Nr. 3 verweist, ist es jetzt klar, 168 00:11:57,920 --> 00:12:01,530 von welchem Block der abhängt. Und damit ist die Kette auch wieder klar, 169 00:12:01,530 --> 00:12:06,300 und die längste Kette wird wieder zum Zustand. So. Jetzt habe ich gesagt, 170 00:12:06,300 --> 00:12:09,830 diese Blockchain die ich jetzt beschrieben habe hat keinen Proof-of-Work und folglich 171 00:12:09,830 --> 00:12:14,510 ist sie angreifbar für ein double-spend. Sagen wir Malroy würde gerne 172 00:12:14,510 --> 00:12:19,050 ein Fahrrad klauen. Er geht da so in den Fahrradladen von Alice, und möchte dort 173 00:12:19,050 --> 00:12:23,510 gerne ein Fahrrad kaufen, das kostet jetzt 1000 Euro in dem Beispiel. 174 00:12:23,510 --> 00:12:26,170 Ich werde jetzt… hier habe ich die Darstellung etwas geändert, 175 00:12:26,170 --> 00:12:30,370 diese Vierecke mit Pfeilen dran, das sind jetzt halt einfach Blöcke. Ich werde 176 00:12:30,370 --> 00:12:34,570 nicht mehr jede Transaktion einzeln zeichnen. Und die sehen den Zustand, 177 00:12:34,570 --> 00:12:39,110 wie er da ist. Da sind all die Konten aufgeführt, unter anderem diejenigen 178 00:12:39,110 --> 00:12:45,070 von Alice und Malroy. So. Malroy geht also in den Laden, 179 00:12:45,070 --> 00:12:51,340 sucht sich das [Fahrrad] aus, geht zum Tresen und macht dort die Transaktion 180 00:12:51,340 --> 00:12:56,880 an Alice. Und diese Transaktion wird übers Netzwerk zu Alice weitergeleitet. 181 00:12:56,880 --> 00:13:00,480 Sie sieht die Transaktion, aber da sie noch nicht Teil eines Blockes ist, 182 00:13:00,480 --> 00:13:04,260 ist sie auch noch nicht Teil des Zustands. Irgendwann aber erstellt jemand halt 183 00:13:04,260 --> 00:13:07,880 einen Block der diese Transaktion enthält. Die ist jetzt Teil des Zustandes. 184 00:13:07,880 --> 00:13:12,760 Wir sehen im Zustand des Systems, dass Alice das Geld erhalten hat. 185 00:13:12,760 --> 00:13:17,130 Sie gibt das Fahrrad an Malroy, und der fährt davon. Neue Blöcke kommen dazu. 186 00:13:17,130 --> 00:13:20,860 Und jetzt startet Malroy den Angriff. Und was Malroy macht, er erstellt 187 00:13:20,860 --> 00:13:25,230 eine alternative Transaktion, die dasselbe Geld überweist, diesmal aber nicht 188 00:13:25,230 --> 00:13:30,260 an Alice sondern an sich selbst. Genauer: an ein zweites Konto das ebenfalls ihm 189 00:13:30,260 --> 00:13:36,510 gehört. Und er erstellt einen alternativen Block, der diese Transaktion enthält. 190 00:13:36,510 --> 00:13:40,830 Und dann erstellt er ganz viele neue Blöcke die davon abhängen. Solange, 191 00:13:40,830 --> 00:13:44,670 bis seine Kette von Blöcken länger ist als die anderen, also die Kette, 192 00:13:44,670 --> 00:13:49,570 die zur Zeit auf dem Netzwerk ist. Und dann veröffentlicht er die gesamte Kette 193 00:13:49,570 --> 00:13:53,540 auf dem Netzwerk. Und jetzt ist seine Kette die längste Kette. Die wird 194 00:13:53,540 --> 00:13:58,380 vom Netzwerk als Zustand anerkannt. Und in diesem Zustand hat er das Geld erhalten. 195 00:13:58,380 --> 00:14:02,210 Alice hat das Geld nicht erhalten. Und Malroy hat das Fahrrad erfolgreich 196 00:14:02,210 --> 00:14:05,720 gestohlen. So, das hat also funktioniert. 197 00:14:05,720 --> 00:14:09,650 Wir müssen das verhindern. Das Problem weshalb Malroy diesen Angriff 198 00:14:09,650 --> 00:14:13,780 machen konnte ist natürlich, dass er in einer sehr kurzen Folge viele Blöcke 199 00:14:13,780 --> 00:14:18,230 erstellen konnte. Also das Problem ist eigentlich, es ist zu einfach neue Blöcke 200 00:14:18,230 --> 00:14:23,250 zu erstellen. Also machen wir es halt schwieriger, neue Blöcke zu erstellen. 201 00:14:23,250 --> 00:14:27,030 Und dazu sagen wir, für jeden Block der erstellt wird, muss eine Aufgabe 202 00:14:27,030 --> 00:14:33,980 gelöst werden, eine Challenge. Und um diese Challenge zu erstellen, 203 00:14:33,980 --> 00:14:40,120 muss man halt Zeit, und Rechenzeit aufwenden. Die Lösung für diese Aufgabe 204 00:14:40,120 --> 00:14:45,161 nennen wir den Proof-of-Work. Und den Prozess um den Proof-of-Work zu erstellen 205 00:14:45,161 --> 00:14:49,560 nennen wir das ‚Mining‘. Und dann sagen wir, zusammen mit jedem neuen Block 206 00:14:49,560 --> 00:14:53,800 muss der passende Proof-of-Work veröffentlicht werden. Und nur Blöcke, 207 00:14:53,800 --> 00:14:58,210 welche einen passenden Proof-of-Work haben werden vom Netzwerk als Teil des Zustands 208 00:14:58,210 --> 00:15:03,300 anerkannt. Jetzt funktioniert das Erstellen neuer Blöcke etwas anders. 209 00:15:03,300 --> 00:15:06,810 Und zwar ist es jetzt so, dass ein Block nicht mehr einfach entsteht, sondern 210 00:15:06,810 --> 00:15:10,650 ein ‚Miner‘ muss daran arbeiten. Jeder Miner arbeitet natürlich für sich selbst 211 00:15:10,650 --> 00:15:14,540 daran, einen neuen Block zu erstellen. Wir sehen hier, der Block an dem der Miner 212 00:15:14,540 --> 00:15:19,991 arbeitet, ist hier so gestrichelt markiert. Und dann, wenn der Miner 213 00:15:19,991 --> 00:15:23,920 daran arbeitet, kommen neue Transaktionen rein. Und irgendwann gelingt es dem Miner 214 00:15:23,920 --> 00:15:27,910 den Block fertigzustellen. In dem Moment veröffentlicht er den Block zusammen mit 215 00:15:27,910 --> 00:15:31,440 dem Proof-of-Work im Netzwerk. Der wird vom Netzwerk anerkannt, und der Miner 216 00:15:31,440 --> 00:15:39,740 beginnt sofort an einem neuen Block zu arbeiten, und das geht dann halt so weiter. 217 00:15:39,740 --> 00:15:43,990 Nun, die Funktion die wir brauchen um das Erstellen der Blöcke schwierig zu machen 218 00:15:43,990 --> 00:15:49,730 muss einige Bedingungen erfüllen. Sie muss natürlich schwierig sein zu lösen. 219 00:15:49,730 --> 00:15:53,110 Dann muss aber… obwohl es lange gehen muss die zu erstellen, muss es sehr 220 00:15:53,110 --> 00:15:56,580 einfach sein, das Ergebnis zu prüfen. Also wenn ich einen Block erhalte, und 221 00:15:56,580 --> 00:16:00,460 den passenden Proof-of-Work, muss ich – zack! – sofort sagen können, 222 00:16:00,460 --> 00:16:03,390 der Proof-of-Work ist gültig oder nicht, weil ich will ja entscheiden, ob das 223 00:16:03,390 --> 00:16:07,500 Teil meines Zustandes sein soll oder nicht. 224 00:16:07,500 --> 00:16:11,960 Und dann ist es wichtig, dass die Funktion abhängt von genau dem Block, 225 00:16:11,960 --> 00:16:15,230 für den sie erstellt wird. Also der Proof-of-Work soll nur genau 226 00:16:15,230 --> 00:16:19,140 für den einen Block gültig sein. Das ist sehr wichtig, denn ansonsten 227 00:16:19,140 --> 00:16:23,589 könnte Malroy auf Vorrat über mehrere Wochen hinweg einfach 228 00:16:23,589 --> 00:16:27,220 Proof-of-Works erstellen und dann die einfach an einen Block ranflanschen, 229 00:16:27,220 --> 00:16:31,810 und so in kurzer Zeit trotzdem wieder eine lange Kette erstellen. Wenn aber 230 00:16:31,810 --> 00:16:37,150 der Proof-of-Work direkt abhängig ist vom Block für den er erstellt wird, 231 00:16:37,150 --> 00:16:40,150 dann muss Malroy mit dem Erstellen des Proof-of-Work so lange warten, 232 00:16:40,150 --> 00:16:44,290 bis der vorhergehende Block bekannt ist und damit auch ihm bekannt ist, 233 00:16:44,290 --> 00:16:47,360 was er jetzt in den neuen Block packt. 234 00:16:47,360 --> 00:16:52,010 Und dann soll es auch noch möglich sein, die Schwierigkeit der Aufgabe zu variieren. 235 00:16:52,010 --> 00:16:56,110 Denn damit das System als stabiles Finanzsystem funktioniert, möchte ich 236 00:16:56,110 --> 00:16:59,250 gerne wissen, wie lange es geht von dem Moment wo ich eine Transaktion 237 00:16:59,250 --> 00:17:04,409 veröffentliche bis sie Teil des Zustandes wird. Und wenn das Netzwerk 238 00:17:04,409 --> 00:17:08,000 sehr viel mehr Rechenkraft hat, dann geht es plötzlich schneller, neue Blöcke 239 00:17:08,000 --> 00:17:11,179 zu erstellen und dann will ich diese Schwierigkeit anpassen können, damit es 240 00:17:11,179 --> 00:17:16,660 wieder länger geht. Nun jetzt, wo das Mining nicht mehr einfach ist, 241 00:17:16,660 --> 00:17:20,169 und es aufwendig ist, müssen wir irgendwie einen Incentive haben, damit die Leute 242 00:17:20,169 --> 00:17:25,089 es auch tun – also irgendeinen Anstoß. So und wir sagen halt, der Miner, 243 00:17:25,089 --> 00:17:29,020 dem es gelingt einen Block zu erstellen, der bekommt eine Belohnung, 244 00:17:29,020 --> 00:17:34,350 den sogenannten ‚Block Reward‘, und wir implementieren das, indem wir sagen, 245 00:17:34,350 --> 00:17:38,010 der Miner darf für sich selbst eine zusätzliche Transaktion in den Block 246 00:17:38,010 --> 00:17:41,999 hineinpacken, und mit dieser Transaktion überweist er sich selbst Geld 247 00:17:41,999 --> 00:17:45,809 aus dem Nichts heraus. Wo das Geld herkommt: Es gibt eigentlich 248 00:17:45,809 --> 00:17:48,779 zwei Möglichkeiten, die populär sind. Entweder sagen wir, das sind 249 00:17:48,779 --> 00:17:53,110 die Überweisungsgebühren der anderen Transaktionen in dem Block. 250 00:17:53,110 --> 00:17:57,540 Oder dann sagen wir halt, das ist Geld, welches neu geschaffen wird. Wir haben ja 251 00:17:57,540 --> 00:18:02,670 vorhin gesehen, wir haben einen leeren Zustand als den Ursprungszustand definiert, 252 00:18:02,670 --> 00:18:06,069 und wenn wir das so tun, muss das Geld, welches die Leute ausgeben, 253 00:18:06,069 --> 00:18:10,250 irgendwo herkommen. Und das ist halt eine Möglichkeit, Geld in das System zu bringen, 254 00:18:10,250 --> 00:18:14,559 die nicht von einer zentralen Stelle kontrolliert wird, und eigentlich 255 00:18:14,559 --> 00:18:21,290 eine faire Möglichkeit. Etwas weiteres ist, dass… 256 00:18:21,290 --> 00:18:25,290 diese zusätzliche Transaktion macht den Block natürlich individuell, denn 257 00:18:25,290 --> 00:18:29,770 jeder Miner wird das Geld an sich selbst zu überweisen versuchen und, also, 258 00:18:29,770 --> 00:18:35,130 diese eine Transaktion wird für jeden Miner anders sein. Und das stellt sicher, 259 00:18:35,130 --> 00:18:39,599 dass die alle an einem ein wenig anderen Problem arbeiten. Wenn die alle 260 00:18:39,599 --> 00:18:43,659 versuchen würden, das genau selbe Problem zu lösen, auf die genau selbe Art, 261 00:18:43,659 --> 00:18:47,809 dann würde es immer demjenigen als erstes gelingen, der die meiste Rechenkraft hat, 262 00:18:47,809 --> 00:18:51,679 und das wollen wir nicht, denn dann würde ja eine Person alle Blöcke erzeugen, 263 00:18:51,679 --> 00:18:54,570 und wir wollen ja, dass viele Personen Blöcke erzeugen, damit das niemand 264 00:18:54,570 --> 00:18:59,830 zensieren kann. Dadurch, dass das Problem, an welchem sie arbeiten, für jeden Miner 265 00:18:59,830 --> 00:19:02,749 etwas anders ist, gelingt es halt zwischendurch auch jemandem 266 00:19:02,749 --> 00:19:06,879 mit weniger Rechenkraft, als erstes eine Lösung zu finden. Und in der Praxis 267 00:19:06,879 --> 00:19:12,159 geht das dann ganz gut, dass wir sagen können, wer 20% der Rechenkraft hat 268 00:19:12,159 --> 00:19:15,559 dem wird es auch in etwa einem Fünftel der Fälle gelingen als erstes einen Block 269 00:19:15,559 --> 00:19:21,210 zu finden. Dann muss der Miner halt noch entscheiden, an welchem Block 270 00:19:21,210 --> 00:19:25,399 er arbeiten will. Aber der Miner will ja… also an welchem Ende der Kette… 271 00:19:25,399 --> 00:19:29,129 Wir haben vorhin gesehen, es kann sein, dass diese Ketten mehrere Enden haben. 272 00:19:29,129 --> 00:19:33,730 Aber das ist ganz einfach, denn der Miner will ja den Reward kriegen. Der Reward ist 273 00:19:33,730 --> 00:19:37,719 eine Transaktion, welche nur dann Teil des Zustandes wird wenn es Teil 274 00:19:37,719 --> 00:19:40,740 in einem Block ist, wenn es Teil der längsten Kette ist. Und der Block ist 275 00:19:40,740 --> 00:19:44,249 nur dann Teil der längsten Kette wenn er an diesem Ende angesetzt wird. 276 00:19:44,249 --> 00:19:49,039 Also arbeiten alle Miner am Ende der längsten Kette. So, jetzt habe ich 277 00:19:49,039 --> 00:19:52,970 versprochen, dass wir so den Double-Spend verhindern können, von vorhin. 278 00:19:52,970 --> 00:19:57,389 Wollen wir mal gucken, ob das geht! Das Szenario ist wieder dasselbe. 279 00:19:57,389 --> 00:20:03,290 Malroy will das Fahrrad klauen, im Laden von Alice. 280 00:20:03,290 --> 00:20:08,760 Der Unterschied ist, dass das Netzwerk arbeiten muss um die Blöcke zu erstellen. 281 00:20:08,760 --> 00:20:13,090 Und dann geht es wieder so vonstatten. Malroy erstellt jetzt zwei Transaktionen. 282 00:20:13,090 --> 00:20:17,110 Eine, um das Geld der Alice zu überweisen. Diese Transaktion macht er öffentlich 283 00:20:17,110 --> 00:20:20,550 im Netzwerk, damit die von allen gesehen werden kann. Und eine Transaktion, 284 00:20:20,550 --> 00:20:25,330 um das Geld an sich selbst zu überweisen. Die behält er vorläufig geheim. Dann wird 285 00:20:25,330 --> 00:20:29,350 der vorhergehende Block fertiggestellt, und sofort fängt das Netzwerk an 286 00:20:29,350 --> 00:20:34,220 den nächsten Block zu erstellen. Das Netzwerk enthält in dem Block natürlich 287 00:20:34,220 --> 00:20:37,750 die Transaktion von Malroy an Alice, denn das ist ja die einzige Transaktion 288 00:20:37,750 --> 00:20:42,129 die dem Netzwerk bekannt ist. Und Malroy arbeitet jetzt ganz alleine daran, 289 00:20:42,129 --> 00:20:47,579 den alternativen Block zu erstellen. In dem die andere Transaktion enthalten ist. 290 00:20:47,579 --> 00:20:51,539 Jetzt ist es aber so: das Netzwerk hat natürlich mehr Rechenkraft als Malroy 291 00:20:51,539 --> 00:20:56,659 allein. Der hat halt nicht so viele Computer. Und deshalb wird das Netzwerk 292 00:20:56,659 --> 00:21:01,340 immer schneller sein darin, neue Blöcke zu erstellen als Malroy. Malroys Kette 293 00:21:01,340 --> 00:21:06,169 wird nie die längste Kette, wird nie Teil des Zustands. Und der Angriff wurde 294 00:21:06,169 --> 00:21:13,779 erfolgreich abgewehrt. Die einzige Art und Weise wie Malroy gewinnen könnte, 295 00:21:13,779 --> 00:21:17,639 also wie Malroy den Angriff trotzdem durchführen könnte, wäre, wenn er 296 00:21:17,639 --> 00:21:21,899 schneller Blöcke erstellen könnte als das Netzwerk. Und das wird ihm aber 297 00:21:21,899 --> 00:21:25,909 nur dann gelingen, wenn er mehr als 50% der Rechenkraft im Netzwerk hätte. 298 00:21:25,909 --> 00:21:28,679 Denn dann wäre die Wahrscheinlichkeit, dass er einen Block findet, höher 299 00:21:28,679 --> 00:21:33,469 als bei allen anderen Minern gemeinsam. Und dann könnte er das tun. Und deshalb 300 00:21:33,469 --> 00:21:40,500 spricht man bei Bitcoin und anderen Kryptowährungen von diesen 50%-Attacken. 301 00:21:40,500 --> 00:21:43,769 So, jetzt gibt es noch eine andere Art, einen Double-Spend auszuführen. Das ist 302 00:21:43,769 --> 00:21:49,020 ein etwas schwierigerer Angriff. Und er hat jetzt damit zu tun, wie 303 00:21:49,020 --> 00:21:53,429 das Peer-to-Peer-Netzwerk funktioniert, das wir brauchen um die Transaktionen 304 00:21:53,429 --> 00:22:01,279 und Blöcke zu verteilen. Jetzt ist der Angriff ein wenig schwieriger, also 305 00:22:01,279 --> 00:22:05,330 muss Malroy etwas wertvolleres stehlen. Er geht zu Bob. Bob verkauft Autos. 306 00:22:05,330 --> 00:22:09,520 Er wird versuchen ein Auto zu stehlen. Und um das zu tun, wird er versuchen 307 00:22:09,520 --> 00:22:13,210 die Verbindung von Bob mit dem Peer-to-Peer-Netzwerk zu kontrollieren. 308 00:22:13,210 --> 00:22:17,260 Wir sehen hier, Bob ist mit dem Netzwerk verbunden. Mit diesen drei Peers. Und 309 00:22:17,260 --> 00:22:21,710 Malroy hat zwei Möglichkeiten: entweder er kontrolliert die Internetverbindung 310 00:22:21,710 --> 00:22:26,490 von Bob. Oder dann kontrolliert er halt die drei Nodes, mit denen Bob 311 00:22:26,490 --> 00:22:30,400 verbunden ist. Wie realistisch das ist, das will ich hier nicht diskutieren. 312 00:22:30,400 --> 00:22:34,820 Grundsätzlich ist es ja schon vorstellbar. Und jetzt hat Malroy 313 00:22:34,820 --> 00:22:39,190 einige interessante Möglichkeiten. Er kann jetzt nämlich kontrollieren, welche Blöcke 314 00:22:39,190 --> 00:22:43,330 und Transaktionen der Bob sieht. Also Transaktionen und Blöcke, 315 00:22:43,330 --> 00:22:47,710 welche auf dem Netzwerk erscheinen, kann Malroy quasi vor Bob geheimhalten. 316 00:22:47,710 --> 00:22:52,059 Und er kann Bob auch Transaktionen und Blöcke präsentieren, die er dem Rest 317 00:22:52,059 --> 00:22:57,920 des Netzwerkes nicht präsentiert. So, das ist der Angriff. Wir sehen, 318 00:22:57,920 --> 00:23:01,880 was das Netzwerk sieht. Links und rechts, was Bob sieht. 319 00:23:01,880 --> 00:23:06,929 Am Anfang ist das natürlich an beiden Orten gleich. Jetzt geht der Malroy 320 00:23:06,929 --> 00:23:12,230 zu dem Bob und wird das Auto kaufen. Er macht eine Transaktion. 321 00:23:12,230 --> 00:23:15,850 Er macht zwei Transaktionen. Eine, um das Geld an Bob zu überweisen. 322 00:23:15,850 --> 00:23:19,480 Diese schickt er nur an Bob. Und versteckt sie vor dem Netzwerk. 323 00:23:19,480 --> 00:23:23,960 Und eine zweite Transaktion, mit der er das Geld wieder an sich selbst überweist. 324 00:23:23,960 --> 00:23:28,480 Diese Transaktion veröffentlicht er im Netzwerk. Jetzt wird das Netzwerk 325 00:23:28,480 --> 00:23:33,950 daran arbeiten, einen Block zu erstellen, mit der Transaktion von Malroy zu Malroy. 326 00:23:33,950 --> 00:23:38,990 Weil das Netzwerk kennt keine andere Transaktion. Und Malroy allein arbeitet 327 00:23:38,990 --> 00:23:44,750 daran einen Block zu erstellen, mit dem er das Geld an Bob überweist. 328 00:23:44,750 --> 00:23:48,130 Natürlich wiederum, das Netzwerk hat viel mehr Rechenkraft, es ist viel schneller 329 00:23:48,130 --> 00:23:51,549 darin, neue Blöcke zu erstellen. So, und 330 00:23:51,549 --> 00:23:56,149 schlussendlich gelingt es dann aber Bob [Malroy!] trotzdem, einen Block zu erstellen. 331 00:23:56,149 --> 00:23:59,690 Und alle diese Blöcke die auf dem Netzwerk erstellt wurden – muss man vielleicht 332 00:23:59,690 --> 00:24:05,350 noch sagen – die hält der Malroy vor Bob geheim. Also, alle diesen neuen Blöcke, 333 00:24:05,350 --> 00:24:08,919 die hat Bob nie gesehen. Und deshalb wird Bob diesen einen Block von Malroy 334 00:24:08,919 --> 00:24:13,269 als die längste Kette von Blöcken akzeptieren. Und jetzt ist die Transaktion 335 00:24:13,269 --> 00:24:18,469 von Malroy an Bob Teil von Bobs Zustand. Er gibt Malroy das Auto. 336 00:24:18,469 --> 00:24:25,210 Malroy fährt davon. Er beendet die Attacke. Und jetzt verbindet sich Bob 337 00:24:25,210 --> 00:24:29,339 wieder ganz normal mit dem Netzwerk. Die beiden Ketten werden synchronisiert. 338 00:24:29,339 --> 00:24:33,410 Und wir sehen, in der schlussendlich resultierenden Kette hat Bob das Geld 339 00:24:33,410 --> 00:24:41,690 nicht erhalten. Malroy hat also das Auto erfolgreich stehlen können. 340 00:24:41,690 --> 00:24:45,690 Das ist gar nicht gut. Jetzt hat ja dieser Angriff funktioniert. Oder hat er das 341 00:24:45,690 --> 00:24:52,659 denn wirklich? Denn diesmal war der Angriff erfolgreich. Aber Malroy musste 342 00:24:52,659 --> 00:24:56,519 jetzt dafür arbeiten. Er musste diesen einen Block erstellen. Und das hat ihn 343 00:24:56,519 --> 00:25:00,400 viel Zeit gekostet. Natürlich kostet es ihn auch irgendwie Rechenkraft, 344 00:25:00,400 --> 00:25:03,440 und den Strom den er braucht um seinen Computer zu betreiben. Das wollen wir 345 00:25:03,440 --> 00:25:07,360 jetzt aber gar nicht mit einbeziehen. Sondern wir schauen jetzt nach diesen 346 00:25:07,360 --> 00:25:11,509 Dings die Zeit gekostet. Denn der Malroy hat ja einen Computer, den er braucht, 347 00:25:11,509 --> 00:25:15,760 um die Blöcke zu erstellen. Und dieser Computer kann immer nur eines auf’s Mal 348 00:25:15,760 --> 00:25:20,290 tun. Entweder erstellt er jetzt diesen Fake-Block für Bob, oder er erstellt 349 00:25:20,290 --> 00:25:25,789 richtige Blöcke auf die richtige Chain. Er kann nicht beides auf’s Mal tun. 350 00:25:25,789 --> 00:25:31,750 So, und das macht es sehr, sehr teuer diesen Angriff durchzuführen. 351 00:25:31,750 --> 00:25:35,759 Stellen wir uns vor… das sind jetzt einfach irgendwelche Annahmewerte für unser 352 00:25:35,759 --> 00:25:39,379 Netzwerk… die sind da halt in jeder Kryptowährung etwas anders definiert. 353 00:25:39,379 --> 00:25:44,730 Sagen wir, unser Netzwerk erzeugt einen Block alle zehn Minuten. Der Block Reward, 354 00:25:44,730 --> 00:25:49,700 welchen der Miner kriegt ist 1000 Euro. Und Malroy hätte jetzt 20% der Rechenkraft 355 00:25:49,700 --> 00:25:54,691 des Netzwerkes. Wenn wir sagen 100% der Rechenkraft erzeugt alle zehn Minuten. 356 00:25:54,691 --> 00:26:00,309 einen Block, dann erzeugt Malroy auf sich alleine gestellt nur alle 50 Minuten 357 00:26:00,309 --> 00:26:06,409 einen Block. D.h. der Angriff auf Bob dauert 50 Minuten. Nun, wenn aber Malroy 358 00:26:06,409 --> 00:26:12,000 50 Minuten lang minen würde, anstatt Bob anzugreifen, dann würde er in dieser Zeit 359 00:26:12,000 --> 00:26:16,289 durchschnittlich 1000 Euro verdienen. Er kann sich jetzt also entscheiden, 360 00:26:16,289 --> 00:26:22,590 entweder greift er Bob an und stiehlt das 23.000 Euro teure Auto, oder er verdient 361 00:26:22,590 --> 00:26:26,470 mit fairem Mining 1000 Euro. Natürlich wird er dieses Auto immer noch 362 00:26:26,470 --> 00:26:31,810 stehlen wollen. Der Mechanismus, um das zu verhindern ist aber ganz einfach. 363 00:26:31,810 --> 00:26:36,419 Wir sagen jetzt, Bob gibt dem Malroy das Auto nicht, sobald Bob 364 00:26:36,419 --> 00:26:41,259 das Geld erhalten hat, sondern er wartet dann noch einige Blöcke. 365 00:26:41,259 --> 00:26:43,849 Das sieht dann in etwa so aus. Ich habe jetzt nicht genügend Blöcke gemalt, 366 00:26:43,849 --> 00:26:49,279 weil die da nicht Platz hatten. Also sagen wir halt, wir sehen 367 00:26:49,279 --> 00:26:54,510 auf der rechten Seite, wo die Transaktion Teil des Zustandes wird. 368 00:26:54,510 --> 00:26:59,609 Und in diesem Moment gibt halt der Bob das Auto noch nicht an Malroy, 369 00:26:59,609 --> 00:27:05,179 sondern erst einige Blöcke später. Und für jeden zusätzlichen Block, den Malroy 370 00:27:05,179 --> 00:27:08,039 erstellen muss, um Bob davon zu überzeugen, dass das jetzt wirklich 371 00:27:08,039 --> 00:27:12,230 die richtige Kette ist, muss Malroy weitere 50 Minuten aufwenden, 372 00:27:12,230 --> 00:27:17,580 und das kostet ihn jedesmal 1000 Euro. Wenn also Bob sagt: „Ich warte 24 Blöcke 373 00:27:17,580 --> 00:27:22,530 bevor ich dem Malroy das Auto gebe“. Dann ist der Angriff für Malroy plötzlich teurer 374 00:27:22,530 --> 00:27:27,360 als das Auto einen Wert hat. Und dadurch kann Bob den Angriff verhindern. 375 00:27:27,360 --> 00:27:31,179 Malroy kann den zwar immer noch durchführen, aber es ist schlicht einfach 376 00:27:31,179 --> 00:27:35,069 nicht interessant für Malroy das zu tun, weil er mehr Geld macht wenn er 377 00:27:35,069 --> 00:27:44,739 in der selben Zeit mint. So. Jetzt haben wir viel gesprochen über generische 378 00:27:44,739 --> 00:27:48,580 Konzepte von Blockchains. Jetzt will ich noch etwas dazu sagen, wie das 379 00:27:48,580 --> 00:27:53,820 in Bitcoin implementiert wird. Zumindest einige der Dinge. Schauen wir uns zuerst 380 00:27:53,820 --> 00:27:58,499 die Blöcke an. Und wir wissen ja, in der Informatik mögen wir es, Bodys und Header 381 00:27:58,499 --> 00:28:03,340 zu definieren. Das tun wir überall, irgendwie, in unseren Netzwerkprotokollen; 382 00:28:03,340 --> 00:28:07,799 in Nachrichten und Dateiformaten sagen wir, der Body enthält den Inhalt, 383 00:28:07,799 --> 00:28:12,049 die eigentlichen Daten. Und der Header enthält die Metadaten. Und genau dasselbe 384 00:28:12,049 --> 00:28:17,390 tun wir auch in unseren Blockchains. In Bitcoin ist es so, der Body eines Blockes 385 00:28:17,390 --> 00:28:22,500 enthält alle Transaktionen. Die sind dort geordnet aufgeführt. Der Miner muss 386 00:28:22,500 --> 00:28:29,130 einige Regeln einhalten, wenn er das macht. Z.B. wenn Transaktion B 387 00:28:29,130 --> 00:28:32,460 von Transaktion A abhängt, die beide im selben Block sind, müssen die 388 00:28:32,460 --> 00:28:36,190 in der richtigen Reihenfolge drin sein. Aber sonst kann der die irgendwie 389 00:28:36,190 --> 00:28:40,350 dort einpacken. Aber sobald er das mal gemacht hat, ist dann… diese Reihenfolge 390 00:28:40,350 --> 00:28:44,739 ist anschließend wichtig. Und die erste Transaktion im Block ist jeweils 391 00:28:44,739 --> 00:28:47,750 die coin-based-Transaktion, mit der sich der Miner 392 00:28:47,750 --> 00:28:53,019 den Block Reward überweist. 393 00:28:53,019 --> 00:28:59,000 Um jetzt diesen Body zu verbinden mit dem Header nutzt Bitcoin einen Merkle Tree. 394 00:28:59,000 --> 00:29:02,249 Das ist ein binärer Baum, 395 00:29:02,249 --> 00:29:08,470 bei dem jeweils… der Node ist der hash der konkatenierten Werte 396 00:29:08,470 --> 00:29:11,480 der Children des Nodes. 397 00:29:11,480 --> 00:29:15,049 Und Bitcoin verwendet fast überall… wo Bitcoin Hashes macht, 398 00:29:15,049 --> 00:29:17,990 wenden sie einen – dhash nennen sie das, 399 00:29:17,990 --> 00:29:22,979 das ist ein double-sha256-Hash, also so nennt sich der Hash eines Hashes 400 00:29:22,979 --> 00:29:27,700 eines Wertes, den sie nehmen. Das sieht dann so aus: wir haben unseren Body 401 00:29:27,700 --> 00:29:31,539 des Blocks. Dann erstellen wir für jede Transaktion den double-hash. 402 00:29:31,539 --> 00:29:34,710 Und dann beginnen wir damit, den Tree zu erstellen. Also auf jeden Node, 403 00:29:34,710 --> 00:29:40,629 für jeden blauen Node konkatenieren wir die beiden grünen Nodes, und machen dann 404 00:29:40,629 --> 00:29:44,410 den Hash davon. Das machen wir für jede Ebene, bis wir schlussendlich 405 00:29:44,410 --> 00:29:49,850 beim Merkle Root angelangen, und der wird dann Teil des Block Headers. 406 00:29:49,850 --> 00:29:53,879 Und der Block Header enthält diese Dinge: die Version – das ist irgendwie 407 00:29:53,879 --> 00:29:58,480 eine arbitrary Nummer, die von den Entwicklern von Zeit zu Zeit geändert wird, 408 00:29:58,480 --> 00:30:01,809 wenn sie irgendwie finden, dass wird jetzt Zeit dafür. 409 00:30:01,809 --> 00:30:05,559 Dann den Previous Block Hash. Wir haben gesehen, die Blöcke verweisen jeweils 410 00:30:05,559 --> 00:30:09,199 auf den vorhergehenden Block. Das ist in Bitcoin so gelöst, dass der Header 411 00:30:09,199 --> 00:30:13,069 eines Blocks den Hash des vorhergehenden Blocks enthält. Also auch hier wieder 412 00:30:13,069 --> 00:30:18,730 den double-hash. Den Merkle Root haben wir bereits gesehen. Dann enthält 413 00:30:18,730 --> 00:30:22,460 der Block-Header noch einen Time Stamp. Das sind ziemlich komplizierte Regeln, 414 00:30:22,460 --> 00:30:26,780 wonach dieser Time Stamp gebildet wird, aber das ist egal. Das ist 415 00:30:26,780 --> 00:30:31,850 nicht so wichtig. Die ‚Difficulty‘ ist ein Ausdruck dafür wie schwierig es war 416 00:30:31,850 --> 00:30:35,989 den Proof-of-Work für diesen bestimmten Block zu definieren. Und die ‚Nonce‘ 417 00:30:35,989 --> 00:30:43,579 ist ein Wert der gebraucht wird zum Minen. 418 00:30:43,579 --> 00:30:48,359 Ja und der Proof-of-Work in Bitcoin ist nichts anderes als der Hash des Blocks. 419 00:30:48,359 --> 00:30:53,139 Und der muss dann eine Bedingung erfüllen. Und zwar muss dieser Hash 420 00:30:53,139 --> 00:30:58,580 mit einer gewissen Anzahl Nullen beginnen. Also ich nehme den Header des Blocks 421 00:30:58,580 --> 00:31:04,359 und bilde den double-hash davon. Und dann müssen die ersten paar Bits 422 00:31:04,359 --> 00:31:08,559 von diesem Hash müssen Null sein. Und wieviele Bits das sind, das ist dann eben 423 00:31:08,559 --> 00:31:13,470 die variable Schwierigkeit. Also wenn ich mehr Nullen haben muss zu Beginn 424 00:31:13,470 --> 00:31:16,970 dann ist es schwieriger den Proof-of-Work zu erstellen. Und bei weniger 425 00:31:16,970 --> 00:31:22,229 natürlich einfacher. Das Mining funktioniert dann so dass… der Miner 426 00:31:22,229 --> 00:31:25,919 nimmt einfach mal diesen Header, und bildet den double-hash davon. 427 00:31:25,919 --> 00:31:29,919 Dann prüft er ob der jetzt diese Bedingung erfüllt. Das wird er vermutlich nicht tun. 428 00:31:29,919 --> 00:31:34,210 Und dann inkrementiert er halt die nonce, dadurch hat sich der Header verändert, 429 00:31:34,210 --> 00:31:39,109 er bildet wieder den hash davon, und prüft das. Und so macht er immer weiter. 430 00:31:39,109 --> 00:31:45,509 Es ist aber so, diese nonce ist lediglich 32 bit lang, und der Hash mit 256 bit 431 00:31:45,509 --> 00:31:50,249 ist wesentlich größer. Es kann also gut sein, dass einfach durch das Inkrementieren 432 00:31:50,249 --> 00:31:55,130 der Nonce kein passender Proof-of-Work gefunden wird. Und in dem Fall wird 433 00:31:55,130 --> 00:32:00,949 der Miner die coin-based Transaktion verändern. Und zwar hat diese coin-based 434 00:32:00,949 --> 00:32:05,450 Transaktion hat den Transaction Input, der wird bei einer normalen Transaktion 435 00:32:05,450 --> 00:32:09,729 dafür gebraucht zu beschreiben, woher das Geld kommt in dieser Transaktion. 436 00:32:09,729 --> 00:32:14,229 Das hat die coin-based nicht, denn die macht ja quasi Geld aus dem Nichts heraus, 437 00:32:14,229 --> 00:32:18,179 und den Wert in diesem Fall kann dann der Miner frei beeinflussen. 438 00:32:18,179 --> 00:32:22,239 Dadurch ändert sich der Hash dieser Transaktion, und das setzt sich dann 439 00:32:22,239 --> 00:32:27,799 durch den Merkle Tree hindurch fort bis es quasi auch den Merkle Root verändert. 440 00:32:27,799 --> 00:32:32,679 Und dadurch ist der ganze Blockheader wieder verändert und der Miner 441 00:32:32,679 --> 00:32:37,799 kann weiterarbeiten. So, das lässt sich ja dann auch sehr einfach prüfen, ob das jetzt 442 00:32:37,799 --> 00:32:41,700 ein korrekter Proof-of-Work ist. Ich nehme einfach diesen Blockheader und bilde 443 00:32:41,700 --> 00:32:48,449 den Hash und schaue ob das so stimmt. 444 00:32:48,449 --> 00:32:53,330 Das Bitcoin-Netzwerk versucht alle zehn Minuten einen neuen Block zu erstellen. 445 00:32:53,330 --> 00:32:57,519 Um diese Zeit stabil zu halten, wird die Schwierigkeit im Netzwerk 446 00:32:57,519 --> 00:33:02,899 alle 14 Tage, also alle 2016 Blöcke, angepasst, mit einem Algorithmus 447 00:33:02,899 --> 00:33:10,539 wo jeder Miner feststellen kann wie weit muss ich jetzt die Schwierigkeit verändern. 448 00:33:10,539 --> 00:33:14,379 Die coin-based Transaktion, mit der sich der Miner Geld überweist, 449 00:33:14,379 --> 00:33:18,039 enthält in Bitcoin zwei Dinge: einerseits die Transaction Fees, also 450 00:33:18,039 --> 00:33:24,759 die Transaktionsgebühren der Transaktion in den Block; und anderseits auch noch 451 00:33:24,759 --> 00:33:29,500 neue Bitcoin, die neu ins System kommen. Das waren ursprünglich 50 Bitcoin pro Block, 452 00:33:29,500 --> 00:33:34,619 heute sind es noch 12,5, der Wert halbiert sich alle vier Jahre. 453 00:33:34,619 --> 00:33:38,509 Das war das letzte Mal in diesem Sommer, da hat sich der Wert halbiert. Seither 454 00:33:38,509 --> 00:33:47,810 gibt es nur noch 12,5 Bitcoin für einen neuen Block. 455 00:33:47,810 --> 00:33:51,999 Jetzt wollen wir noch uns anschauen wie wir ‚Light Clients‘ bauen können. 456 00:33:51,999 --> 00:33:56,509 Bitcoin kennt eigentlich mehr oder weniger, drei Arten von Clients: ein ‚Full Node‘ 457 00:33:56,509 --> 00:34:02,589 ist ein Client, welcher die gesamte Blockchain speichert. 458 00:34:02,589 --> 00:34:06,630 Der überprüft jede eingehende Transaktion, jeden eingehenden Block 459 00:34:06,630 --> 00:34:10,639 überprüft dieser Client, ob der auch wirklich valide ist. Und er tut noch 460 00:34:10,639 --> 00:34:14,119 etwas anderes, nämlich er seeded diese Blöcke die er hat an das Netzwerk. 461 00:34:14,119 --> 00:34:17,800 Also wenn jemand kommt und sagt: „Ich hätte gern einen Block“ dann gibt 462 00:34:17,800 --> 00:34:22,149 der Full Node diesen Block raus. Dann gibt es ‚Pruning Clients‘. Der macht eigentlich 463 00:34:22,149 --> 00:34:27,940 das genau selbe wie der Full Node. Also der überprüft auch alle Transaktionen 464 00:34:27,940 --> 00:34:32,520 und alle Blöcke. Aber der speichert jetzt halt nicht die ganze Blockchain, sondern 465 00:34:32,520 --> 00:34:35,550 wenn er findet „den Block brauche ich nicht mehr“, dann löscht er den. 466 00:34:35,550 --> 00:34:39,100 Und das macht dem Client Speicherplatz. Der braucht aber immer noch 467 00:34:39,100 --> 00:34:43,580 sehr viel Rechenkraft und sehr viel Bandbreite, deutlich zuviel als dass ich 468 00:34:43,580 --> 00:34:48,130 das auf meinem Smartphone laufen lassen möchte. Und deshalb gibt es noch 469 00:34:48,130 --> 00:34:53,520 die Light Clients oder SPV Clients. Die dann auch geeignet sind, 470 00:34:53,520 --> 00:34:56,980 um [sie] auf einem mobilen Gerät laufen zu lassen. Und wie die funktionieren, 471 00:34:56,980 --> 00:35:01,210 will ich jetzt noch besprechen. 472 00:35:01,210 --> 00:35:05,590 Ein Light Client oder ein SPV Client, was der tut zuerst ist, er lädt 473 00:35:05,590 --> 00:35:09,020 die Header aller Blöcke herunter. Wir haben ja gesehen, der Proof-of-Work 474 00:35:09,020 --> 00:35:15,420 ist der Hash des Block Headers. D.h. um den Proof-of-Work zu kontrollieren 475 00:35:15,420 --> 00:35:18,760 brauche ich nicht den gesamten Block, der Block Header genügt. 476 00:35:18,760 --> 00:35:23,230 Und dasselbe gilt auch für die Verknüpfung der Blöcke untereinander. 477 00:35:23,230 --> 00:35:26,390 Welches der vorhergehende Block ist, das steht ja auch im Header. 478 00:35:26,390 --> 00:35:30,510 D.h. auch für diese Funktion brauche ich nicht die ganzen Blöcke herunterzuladen. 479 00:35:30,510 --> 00:35:35,450 Und so kann ich korrekt die längste Kette erstellen, 480 00:35:35,450 --> 00:35:40,350 innerhalb des Netzwerks, indem ich nur die Header herunterlade. 481 00:35:40,350 --> 00:35:45,560 Und der Gewinn dabei ist natürlich enorm. Zur Zeit gibt es etwa 450.000 Blöcke. 482 00:35:45,560 --> 00:35:52,350 Die brauchen mehr als 95 GB Speicherplatz. Wenn man dann noch TX Index aktiviert 483 00:35:52,350 --> 00:35:56,230 sind es, glaube ich, so um die 110 GB Speicherplatz, die es braucht. 484 00:35:56,230 --> 00:36:00,450 Das ist natürlich blödsinnig viel auf einem Smartphone. Aber nur die Block Headers, 485 00:36:00,450 --> 00:36:03,730 alle Block Headers von diesen 450.000 Blöcken, die passen 486 00:36:03,730 --> 00:36:10,180 in deutlich weniger als 100 MB rein. Und das ist dann durchaus ein realistischer Wert, 487 00:36:10,180 --> 00:36:14,940 dass ich das auf einem Smartphone habe. Das zweite Konzept ist der Merkle Branch, 488 00:36:14,940 --> 00:36:18,540 und das ist dann eigentlich noch fast die interessantere Funktion, die uns 489 00:36:18,540 --> 00:36:22,790 der Merkle Tree bildet. Und damit kann jeder beweisen, dass eine Transaktion 490 00:36:22,790 --> 00:36:26,770 tatsächlich Teil des Zustands ist. 491 00:36:26,770 --> 00:36:30,650 Nun, die eine Möglichkeit, wie wir den Merkle Tree nachbauen können, 492 00:36:30,650 --> 00:36:35,210 ist natürlich, indem wir den Block Body herunterladen, und dann 493 00:36:35,210 --> 00:36:39,580 den ganzen Merkle Tree bauen. Wenn ich jetzt aber nur beweisen will 494 00:36:39,580 --> 00:36:44,200 dass eine Transaktion Teil des Blockes ist, gibt es eine effizientere Möglichkeit. 495 00:36:44,200 --> 00:36:47,950 Angenommen ich will jetzt beweisen, dass die Transaktion (3) tatsächlich 496 00:36:47,950 --> 00:36:51,920 Teil des Blocks ist. Dann brauche ich nicht alle Transaktionen herunterzuladen, 497 00:36:51,920 --> 00:36:57,760 sondern es reicht diese Transaktion (3) herunterzuladen. – Ui, das war falsch. – 498 00:36:57,760 --> 00:37:01,480 Und dann die restlichen Hashes, also von jeder Ebene des Baums 499 00:37:01,480 --> 00:37:04,480 lade ich einen Hash herunter. Und damit kann ich jetzt 500 00:37:04,480 --> 00:37:11,420 den Merkle Root Node wieder nachbilden, und so feststellen, dass diese Transaktion 501 00:37:11,420 --> 00:37:15,890 tatsächlich Teil des Blocks ist. Das ist genau das was… 502 00:37:15,890 --> 00:37:19,150 das hat jetzt natürlich auch einige Vorteile. Ich brauche jetzt 503 00:37:19,150 --> 00:37:23,520 weniger Elemente herunterzuladen, und ich kann halt Hashes herunterladen, also 504 00:37:23,520 --> 00:37:27,110 anstatt Transaktionen. Vorhin in dem Beispiel hat das nicht soviel gebracht. 505 00:37:27,110 --> 00:37:30,371 Aber wenn wir einen Block nehmen mit 1600 Transaktionen, das ist 506 00:37:30,371 --> 00:37:34,880 dieser Tage durchaus ein üblicher Block, dann brauche ich jetzt zum Validieren 507 00:37:34,880 --> 00:37:38,810 nicht mehr 1600 Transaktionen herunterzuladen, sondern es genügt 508 00:37:38,810 --> 00:37:42,400 eine Transaktion herunterzuladen und dann elf Hashes, und damit kann ich 509 00:37:42,400 --> 00:37:47,270 den Merkle Branch nachbauen. 510 00:37:47,270 --> 00:37:52,640 Und so funktioniert ein SPV Client. SPV steht für ‚simple payment verification‘. 511 00:37:52,640 --> 00:37:56,660 Und das hat eigentlich… das wurde schon im White Paper zu Bitcoin beschrieben, 512 00:37:56,660 --> 00:38:00,890 wie das funktioniert. Alles was der tun muss, um zu beweisen, dass 513 00:38:00,890 --> 00:38:04,950 eine Transaktion reingekommen ist, ist, er lädt zuerst alle Block Header herunter, 514 00:38:04,950 --> 00:38:10,320 wie vorhin besprochen, er bildet den längsten Branch daraus, 515 00:38:10,320 --> 00:38:15,580 dann lädt er eine Transaktion herunter. Und wenn ich jetzt wissen will… 516 00:38:15,580 --> 00:38:18,331 wenn ich von jemandem Geld erhalte und ich will jetzt zeigen, ich habe das Geld 517 00:38:18,331 --> 00:38:22,610 tatsächlich erhalten, lade ich halt diese Transaktion herunter, und dann lade ich 518 00:38:22,610 --> 00:38:27,110 den passenden Merkle Branch herunter. Und jetzt kann ich quasi zeigen, dass 519 00:38:27,110 --> 00:38:32,160 dieser Merkle Branch tatsächlich mit der längsten Kette von Blöcken verbunden ist. 520 00:38:32,160 --> 00:38:36,990 Und so habe ich jetzt den Beweis dafür, dass ich das Geld tatsächlich erhalten habe. 521 00:38:36,990 --> 00:38:40,560 So, das ist diese Funktionsweise. Jetzt haben wir noch etwas mehr Zeit, 522 00:38:40,560 --> 00:38:44,290 als ich gehofft hatte. Ich werde jetzt noch versuchen, die Pruning Clients 523 00:38:44,290 --> 00:38:49,010 zu erklären. Das hängt dann damit zusammen wie eigentlich Bitcoin-Transaktionen 524 00:38:49,010 --> 00:38:53,910 funktionieren. Nun, wir sind es ja gewohnt, dass wir irgendwie auf der Bank 525 00:38:53,910 --> 00:38:58,440 ein Konto haben. Und das Konto hat einen Besitzer. Hoffentlich mich! 526 00:38:58,440 --> 00:39:02,720 Und es hat einen Geldbetrag. Und jedesmal, wenn ich eine Transaktion durchführe, 527 00:39:02,720 --> 00:39:06,760 verändert sich der Geldbetrag. Also ich überweisen jemandem Geld, und dann 528 00:39:06,760 --> 00:39:11,520 verändert sich halt der Betrag auf meinem Konto. In Bitcoin funktioniert das 529 00:39:11,520 --> 00:39:15,620 wesentlich anders, dort besitze ich nicht ein Konto, sondern ich besitze 530 00:39:15,620 --> 00:39:20,170 sogenannte ‚Unspent Transaction Outputs‘. Und wir sehen jetzt hier, sagen wir Alice 531 00:39:20,170 --> 00:39:23,880 hat diese fünf Unspent Transaction Outputs, die haben jeweils einen Besitzer, 532 00:39:23,880 --> 00:39:29,230 nämlich Alice. Und jeweils einen Betrag der dort verfügbar ist. Und der Betrag 533 00:39:29,230 --> 00:39:33,840 kann nicht geändert werden. Das ist fest. Und nehmen wir jetzt an, Alice würde gerne 534 00:39:33,840 --> 00:39:38,910 eine Transaktion machen, an Bob, die würde ihm gerne 42 Bitcoin überweisen. 535 00:39:38,910 --> 00:39:42,200 Dann erstellt sie eine Transaktion, und sagt, das Geld dieser Transaktion, 536 00:39:42,200 --> 00:39:47,270 42 Bitcoin, sollen an Bob gehen. Und jetzt muss sie das Geld irgendwoher haben. 537 00:39:47,270 --> 00:39:53,200 Und dann sagt sie halt, ich gebe diese drei Transaction Outputs aus. 538 00:39:53,200 --> 00:39:56,920 Und das Interessante an Transaction Outputs… wie gesagt, den Betrag 539 00:39:56,920 --> 00:40:01,760 kann man nicht verändern, sondern Alice muss die alle komplett ausgeben. 540 00:40:01,760 --> 00:40:05,930 Jetzt sind aber diese Transaction Outputs zusammengenommen 44 Bitcoin, 541 00:40:05,930 --> 00:40:10,990 und nicht 42 Bitcoins. D.h. diese Transaktion gibt jetzt zuviel Geld aus, 542 00:40:10,990 --> 00:40:17,330 also sie gibt mehr Transaction Outputs aus als sie dann schlussendlich Geld dem Bob 543 00:40:17,330 --> 00:40:21,400 überweist. Und was kann jetzt Alice tun? Was sie tut, ist, sie macht 544 00:40:21,400 --> 00:40:27,360 einen zweiten Output in ihrer Transaktion. Und hier überweist sie jetzt Geld an Alice. 545 00:40:27,360 --> 00:40:31,670 D.h. eine Transaktion in Bitcoin kann beliebig viele Inputs und beliebig viele 546 00:40:31,670 --> 00:40:36,740 Outputs haben. Was es hier noch zu sagen gibt, ist, haben wir immer noch 547 00:40:36,740 --> 00:40:41,070 einen Unterschied. Jetzt haben wir 44 Bitcoin, die in die Transaktion reinkommen, 548 00:40:41,070 --> 00:40:45,860 und nur 43 die rausgehen. Das restliche Bitcoin, das jetzt hier nicht ausgegeben wird, 549 00:40:45,860 --> 00:40:50,810 das ist quasi impliziert die Transaction Fee, welche der Miner erhält, der diese 550 00:40:50,810 --> 00:40:56,400 Transaktion mint. So eine Transaction Fee ist implementiert. Jetzt haben wir gesehen, 551 00:40:56,400 --> 00:40:59,640 Alice hat durch das Erstellen dieser Transaktion neue Transaction Outputs 552 00:40:59,640 --> 00:41:05,760 erstellt. Nämlich einen, der jetzt Bob gehört, und einen der Alice gehört. 553 00:41:05,760 --> 00:41:08,980 Und jetzt können wir auch nachvollziehen, diese Transaction Outputs, welche Alice 554 00:41:08,980 --> 00:41:13,850 ausgegeben hat, die gehören alle irgendwie zu anderen Transaktionen, welche es vorhin 555 00:41:13,850 --> 00:41:19,800 gegeben hat. Nun, ein Transaction Output kann einen von zwei Zuständen haben. 556 00:41:19,800 --> 00:41:24,930 Er kann ausgegeben sein, oder nicht. Und natürlich kann man nur die ausgeben, 557 00:41:24,930 --> 00:41:29,320 die noch nicht ausgegeben sind. Und das heißt, wenn ich wissen will, wieviel Geld 558 00:41:29,320 --> 00:41:33,350 Alice gehört, dann suche ich mir alle Transaction Outputs zusammen, 559 00:41:33,350 --> 00:41:38,360 die Alice gehören, und addiere die Summe, und dann weiß ich, Alice gehört „soviel“ Geld. 560 00:41:38,360 --> 00:41:41,200 Das kann ich für jeden Teilnehmer des Systems machen, dann weiß ich 561 00:41:41,200 --> 00:41:46,900 für jeden Teilnehmer, wieviel Geld denn der Person gehört. Wenn ich jetzt also 562 00:41:46,900 --> 00:41:50,980 alle Transaction Outputs nehme, die nicht ausgegeben sind, dann habe ich 563 00:41:50,980 --> 00:41:56,530 den aktuellen Zustand des Netzwerks. Dann weiß ich für jeden Teilnehmer, wieviel Geld 564 00:41:56,530 --> 00:42:04,960 diese Person hat. Und genau diesen Mechanismus macht sich ein Pruning Client 565 00:42:04,960 --> 00:42:09,470 zunutze. Der sagt nämlich, eigentlich brauche ich nicht die ganze Blockchain 566 00:42:09,470 --> 00:42:12,931 zu speichern, das ist ja blöd, denn wenn eine neue Transaktion reinkommt, und 567 00:42:12,931 --> 00:42:17,260 ich wissen will ob die tatsächlich valide ist, dann muss ich nur prüfen, ob die 568 00:42:17,260 --> 00:42:22,060 einen Output ausgibt, der noch unspent ist, denn wenn die Transaktion einen 569 00:42:22,060 --> 00:42:25,520 Transaction Output ausgibt, der schon ausgegeben ist, dann ist die natürlich 570 00:42:25,520 --> 00:42:29,430 nicht valide, man kann ja nicht dasselbe Geld zweimal ausgeben. Oder wenn 571 00:42:29,430 --> 00:42:32,790 die Transaktion versucht, einen Transaction Output auszugeben, 572 00:42:32,790 --> 00:42:36,220 den es gar nicht gibt, dann ist die natürlich auch nicht valide. 573 00:42:36,220 --> 00:42:42,290 Was jetzt also ein Pruning Client tut – und das tut übrigens auch ein Full Node: 574 00:42:42,290 --> 00:42:46,270 wenn eine neue Transaktion reinkommt, und da steht in der Transaktion „ich gebe 575 00:42:46,270 --> 00:42:51,770 diesen Transaction Output aus“, dann geht der Full Node nicht und versucht, 576 00:42:51,770 --> 00:42:55,930 die 100 GB große Blockchain zu durchsuchen nach diesem Transaction Output, das wäre 577 00:42:55,930 --> 00:43:00,160 ja blödsinnig, sondern der legt sich halt eine kleine Datenbank an, und dort 578 00:43:00,160 --> 00:43:05,520 stehen alle Transaction Outputs drin. Und dann sagt er sich, für jeden… 579 00:43:05,520 --> 00:43:08,580 also alle Unspent Transaction Outputs stehen dort drin, und dann sagt sich 580 00:43:08,580 --> 00:43:12,090 der Client, für jede Transaktion, die reinkommt und die valide ist, 581 00:43:12,090 --> 00:43:17,540 entferne ich alle Transaction Outputs die die Transaktion ausgibt aus der Datenbank, 582 00:43:17,540 --> 00:43:22,870 und alle neuen Transaction Outputs füge ich dort ein. Und so behält der Client 583 00:43:22,870 --> 00:43:28,530 den Zustand. Und der Pruning Client sagt sich dann halt: „Naja, die Blöcke, die 584 00:43:28,530 --> 00:43:31,550 brauche ich jetzt ja nicht mehr, weil ich habe den Zustand in der Datenbank, 585 00:43:31,550 --> 00:43:35,380 der ist auch viel kleiner als all die blöden Blöcke, die Blöcke werfe ich fort.“ 586 00:43:35,380 --> 00:43:39,260 Der muss dann noch etwas vorsichtig sein, denn wenn jetzt plötzlich von weiter hinten 587 00:43:39,260 --> 00:43:42,770 eine längere Kette kommt, dann muss er das ja wieder nachvollziehen können, 588 00:43:42,770 --> 00:43:47,520 also wird er sich noch einige Blöcke zusätzlich speichern, als nur den neuesten. 589 00:43:47,520 --> 00:43:54,720 Aber er kann so sehr viel Speicherplatz sparen. Er muss aber… trotzdem 590 00:43:54,720 --> 00:44:00,420 muss ein Pruning Client eigentlich jede Transaktion, die es jemals gegeben hat, 591 00:44:00,420 --> 00:44:04,490 herunterladen, und muss dann halt auch die alle verifizieren. Das braucht auch 592 00:44:04,490 --> 00:44:08,280 immer noch sehr viel Rechenkraft, und sehr viel Bandbreite. Und deshalb sind 593 00:44:08,280 --> 00:44:13,300 solche Clients nicht geeignet für Mobilgeräte. 594 00:44:13,300 --> 00:44:15,870 Und was man hier vielleicht noch sagen kann, ich habe jetzt eigentlich irgendwie 595 00:44:15,870 --> 00:44:25,300 gesagt, … 596 00:44:25,300 --> 00:44:31,510 …ich habe jetzt gesagt, Alice gibt einen Transaction Output aus. Das ist… 597 00:44:31,510 --> 00:44:34,570 In Wirklichkeit ist es in Bitcoin recht kompliziert implementiert. 598 00:44:34,570 --> 00:44:38,790 Das funktioniert nämlich so, dass der Transaction Output hat ein Stück Code 599 00:44:38,790 --> 00:44:44,940 drin. Dafür gibt es in Bitcoin eine eigene Assemblersprache, die das betreibt. 600 00:44:44,940 --> 00:44:50,960 Und der Input muss jetzt ebenfalls ein Stück Code enthalten. Und wenn die dann 601 00:44:50,960 --> 00:44:55,670 nacheinander ausgeführt werden, muss das am Schluss den Wert 'two' ergeben, 602 00:44:55,670 --> 00:44:59,740 und nur in dem Fall wurde der Output richtig ausgegeben. Und das ist 603 00:44:59,740 --> 00:45:03,820 ein ziemlich kompliziertes System, wie das wirklich funktioniert. Das ist dann halt 604 00:45:03,820 --> 00:45:07,440 eine eigene Programmiersprache, die ist zwar nicht Turing-vollständig, aber damit 605 00:45:07,440 --> 00:45:11,940 lassen sich dann alle möglichen lustigen Regeln implementieren. Die häufigste Regel 606 00:45:11,940 --> 00:45:23,410 die man findet, in über 80% der Fälle, sind sogenannte… 607 00:45:23,410 --> 00:45:28,250 …die Regel sagt dann irgendsowas wie: „Um diesen Output ausgeben zu können, 608 00:45:28,250 --> 00:45:32,380 musst du beweisen, dass du den geheimen Schlüssel besitzt zu dem öffentlichen 609 00:45:32,380 --> 00:45:37,400 Schlüssel, dessen Hash ich jetzt hier reinpacke.“ Und in dem Input steht dann 610 00:45:37,400 --> 00:45:43,310 halt: „Ja, ich besitze diesen geheimen Schlüssel, und ich beweise dir das, 611 00:45:43,310 --> 00:45:47,680 indem ich hier den öffentlichen Schlüssel reinpacke und die Transaktion mit dem 612 00:45:47,680 --> 00:45:52,840 geheimen Schlüssel signiere.“ Und dann kann jemand, der das verifizieren will, 613 00:45:52,840 --> 00:45:56,930 kann einfach den öffentlichen Schlüssel nehmen, schauen ob das dem Hash entspricht, 614 00:45:56,930 --> 00:46:04,630 und dann mit dem öffentlichen Schlüssel die Signatur der Transaktion verifizieren. 615 00:46:04,630 --> 00:46:09,940 Das ist die mit Abstand häufigste Art, wie diese Transaktionen in Wirklichkeit 616 00:46:09,940 --> 00:46:14,240 funktionieren. Aber das ist halt dann sehr kompliziert, und damit könnte man leicht 617 00:46:14,240 --> 00:46:22,250 einen eigenen Vortrag füllen. Deshalb werde ich jetzt hier aufhören. 618 00:46:22,250 --> 00:46:28,900 Habe ich da diese tolle Seite gebastelt. 619 00:46:28,900 --> 00:46:32,920 – Ups, das ist eigentlich zu weit – 620 00:46:32,920 --> 00:46:42,750 Finde ich es, oder nicht? 621 00:46:42,750 --> 00:46:45,760 Ja, ha, gefunden! Unglaublich. *Lachen* 622 00:46:45,760 --> 00:46:48,860 Also wir haben jetzt noch Zeit für Fragen, wenn ihr noch was wissen wollt. 623 00:46:48,860 --> 00:46:54,940 Oder ihr könnt mich auch erreichen, am einfachsten hier über das DECT-Telefon 624 00:46:54,940 --> 00:47:01,890 in dem Kongress, wenn ihr Fragen habt. Ihr findet einen Handout der Slides 625 00:47:01,890 --> 00:47:06,000 auch im Fahrplan. Und ich werde auch die Folien selbst noch hochladen, 626 00:47:06,000 --> 00:47:09,520 und den entsprechenden Source Code zum Erzeugen der Folien werde ich auch 627 00:47:09,520 --> 00:47:11,460 verlinken. 628 00:47:11,460 --> 00:47:12,960 *Beifall* 629 00:47:12,960 --> 00:47:14,550 Herald: vimja!! 630 00:47:14,550 --> 00:47:24,790 *andauernder Beifall* 631 00:47:24,790 --> 00:47:31,540 Es ist noch einiges an Zeit für Fragen; also wenn ihr Fragen habt, 632 00:47:31,540 --> 00:47:35,440 dann reiht euch an den Mikrofonen auf. Eine Sache möchte ich sagen: 633 00:47:35,440 --> 00:47:40,280 wenn ihr jetzt rausgehen wollt, verlasst bitte leise den Saal, damit das 634 00:47:40,280 --> 00:47:44,360 mit den Fragen einigermaßen klappt. Liebe Tür-Engel, wir lassen im Moment 635 00:47:44,360 --> 00:47:50,430 noch niemanden rein. Erstmal können Leute nur rausgehen. Und bitte tut das leise. 636 00:47:50,430 --> 00:47:55,520 Wir fangen mit dem Signal-Engel an. 637 00:47:55,520 --> 00:47:58,730 Signal Angel: Eine Frage aus dem Internet bezüglich dem Man-in-the-middle 638 00:47:58,730 --> 00:48:02,290 double-spending-Angriff. Könnte Mallory nicht diesen Angriff gleichzeitig 639 00:48:02,290 --> 00:48:07,210 mit derselben Fake-Blockchain gegen zehn verschiedene Autohändler machen, und 640 00:48:07,210 --> 00:48:12,890 mit dem gleichen Aufwand zehn Autos klauen? Damit würde es sich doch wieder lohnen, 641 00:48:12,890 --> 00:48:20,050 auch wenn man mit dem Gegenwert eines Autos an Rechenzeit investieren müsste. 642 00:48:20,050 --> 00:48:25,590 vimja: Das ist eine gute Überlegung die ich mir so noch auch gar nie gemacht habe. 643 00:48:25,590 --> 00:48:30,030 Ich müsste darüber mal nachdenken. Ich nehme aber grundsätzlich an, dass es 644 00:48:30,030 --> 00:48:35,670 vermutlich funktionieren würde. Der Aufwand wird dann aber halt sehr viel 645 00:48:35,670 --> 00:48:40,970 größer, irgendwie um die Netzwerk-Nodes zu kontrollieren. Grundsätzlich denke ich 646 00:48:40,970 --> 00:48:44,950 aber, dass es kein… damit das System wirklich sicher ist, sollte das 647 00:48:44,950 --> 00:48:50,730 kein Argument sein dürfen. Also ich hätte jetzt auf Anhieb gesagt, dass es vermutlich 648 00:48:50,730 --> 00:48:54,790 klappen würde. 649 00:48:54,790 --> 00:48:58,251 Herald: Okay, dann machen wir weiter mit Mikrofon 2, hier vorne, bitte! 650 00:48:58,251 --> 00:49:03,220 Frage: Ja, hallo. Du hast gesagt, mit einer 50%-Attack kann man im Prinzip 651 00:49:03,220 --> 00:49:07,140 die Blockchains hijacken. Wenn man sich jetzt mal eine hypothetische 652 00:49:07,140 --> 00:49:11,480 Regierungsorganisation mit sehr, sehr, sehr viel Rechenpower überlegt, 653 00:49:11,480 --> 00:49:16,220 mal so ganz in den Raum geraten, gibt’s Überlegungen, wie wahrscheinlich das ist? 654 00:49:16,220 --> 00:49:19,540 vimja: Nun, es ist so, mit einfach herkömmlicher Rechenpower wird das 655 00:49:19,540 --> 00:49:22,750 kaum möglich sein, also irgendwie für diese spezielle Aufgabe, 656 00:49:22,750 --> 00:49:28,400 den Double-SHA256-Hash, hat das Bitcoin- Netzwerk ein Vielfaches der Rechenkraft, 657 00:49:28,400 --> 00:49:32,510 die selbst die 500 schnellsten Supercomputer aufbringen könnten. Es gibt aber eine 658 00:49:32,510 --> 00:49:36,580 viel einfachere Möglichkeit, unser guter Freund China, denn die meisten… 659 00:49:36,580 --> 00:49:40,070 denn heute ist es halt so: eigentlich möchte man gerne, dass die Miner 660 00:49:40,070 --> 00:49:43,740 verteilt sind, und jeder ein wenig zuhause minet. In Praxis ist es aber so, dass 661 00:49:43,740 --> 00:49:47,770 das heute das große Geschäft ist. Und das wird dann halt heute in Rechenzentren 662 00:49:47,770 --> 00:49:54,280 in China betrieben. Und China hat heute mehr als 50% der Rechenkraft von Bitcoin, 663 00:49:54,280 --> 00:49:57,430 also, toll, unsere unabhängige Währung gehört jetzt den Chinesen. 664 00:49:57,430 --> 00:50:01,030 Und selbst wenn das nicht stimmen sollte, und das nicht funktionieren sollte, 665 00:50:01,030 --> 00:50:04,630 ist es so, dass all die spezielle Hardware, die heute zum Mining 666 00:50:04,630 --> 00:50:08,940 notwendig ist, in China hergestellt wird. Und China könnte einfach all diese Fabriken, 667 00:50:08,940 --> 00:50:12,710 in denen die hergestellt werden, beschlagnahmen, und nach einigen Monaten 668 00:50:12,710 --> 00:50:15,120 hätten sie trotzdem wieder mehr Rechenleistung als jeder andere, 669 00:50:15,120 --> 00:50:21,250 und könnte die Währung so kontrollieren. Also, das ist durchaus wahrscheinlich. 670 00:50:21,250 --> 00:50:24,680 Herald: Dann machen wir weiter mit Mikrofon 1, hier vorne, bitte. 671 00:50:24,680 --> 00:50:28,970 Frage: Ja, mir geht’s auch gerade um die Rechenpower. Also gibt es da irgendwie 672 00:50:28,970 --> 00:50:34,200 Ansätze in anderen elektronischen Währungen, wie das verhindert werden kann, 673 00:50:34,200 --> 00:50:40,380 dass immer quasi zum Stand der aktuellen Technik die maximale Rechenpower nötig ist, 674 00:50:40,380 --> 00:50:44,041 um so ein System laufen zu lassen? 675 00:50:44,041 --> 00:50:47,400 vimja: Es hat zur Zeit, im Verlauf der Zeit verschiedene Möglichkeiten, 676 00:50:47,400 --> 00:50:51,700 also verschiedene Ansätze gegeben. 677 00:50:51,700 --> 00:50:55,150 Das eine was man immer wieder versucht hat, ist halt, dass man das nicht nur auf 678 00:50:55,150 --> 00:50:59,720 Rechenkraft beschränkt, sondern dass man sagt, der Angriff der braucht nicht nur 679 00:50:59,720 --> 00:51:03,950 Rechenpower sondern auch viel RAM, oder viel Memory. Und dadurch ist es 680 00:51:03,950 --> 00:51:08,250 sehr viel schwieriger, Hardware zu bauen. Oder sehr viel teurer, Hardware zu bauen, 681 00:51:08,250 --> 00:51:12,240 die darauf spezialisiert ist, und man erhofft sich davon Erfolge, aber 682 00:51:12,240 --> 00:51:16,010 schlussendlich hat man dort wieder dasselbe Problem. Ich weiß aber, 683 00:51:16,010 --> 00:51:21,500 dass Ethereum arbeitet an einem Konzept, das nennen sie Proof-of-Stake. 684 00:51:21,500 --> 00:51:24,730 Und wie genau das funktioniert, kann ich dir nicht sagen. Aber da hängt dann 685 00:51:24,730 --> 00:51:29,160 die Wahrscheinlichkeit, dass du einen Block erstellst, davon ab wieviel Geld 686 00:51:29,160 --> 00:51:32,900 du besitzt in dem Netzwerk, oder sowas. Und die brauchen dann eigentlich 687 00:51:32,900 --> 00:51:35,840 kein Mining mehr. Und die haben dann halt auch das Problem nicht mehr dass man 688 00:51:35,840 --> 00:51:40,700 unglaublich viel Strom braucht, um das Ding zu minen. Und ich dachte, die wollten 689 00:51:40,700 --> 00:51:44,660 diesen Sommer umstellen. Ich habe dann aber das Ganze ein wenig aus den Augen 690 00:51:44,660 --> 00:51:47,560 verloren, und kann dir jetzt nicht sagen wie weit die damit sind. 691 00:51:47,560 --> 00:51:48,260 Also grundsätzlich… 692 00:51:48,260 --> 00:51:50,100 Frage: Wie heißt das nochmal? 693 00:51:50,100 --> 00:51:53,570 vimja: ‚Proof-of-Stake‘. Und das wird in Ethereum implementiert. Aber wie weit 694 00:51:53,570 --> 00:51:57,490 die sind, kann ich dir nicht sagen. Das müsstest du selbst nachschauen gehen. 695 00:51:57,490 --> 00:51:58,770 Frage: Danke. 696 00:51:58,770 --> 00:52:02,440 Herald: Dann machen wir weiter mit Mikrofon 4, dort drüben, bitte! 697 00:52:02,440 --> 00:52:06,550 Frage: Ich stelle mal zwei Fragen. Das eine ist: öffentliche Grundbuchämter 698 00:52:06,550 --> 00:52:11,470 könnte man doch sehr gut in der Blockchain umlegen [anlegen], und dadurch könnte 699 00:52:11,470 --> 00:52:14,590 doch die Verwaltung sehr viel Geld einsparen, und z.B. Handelsregister 700 00:52:14,590 --> 00:52:16,730 sind ja auch öffentlich, die könnte man doch auch in die Blockchain verschieben. 701 00:52:16,730 --> 00:52:20,450 Oder mache ich da irgendeinen Denkfehler, dass es am Schluss für die Verwaltung 702 00:52:20,450 --> 00:52:22,980 teurer kommt? Und was mich auch noch wundert, was deine Meinung 703 00:52:22,980 --> 00:52:26,250 zu Smart Contracts ist. 704 00:52:26,250 --> 00:52:30,300 vimja: Also, zu der ersten Frage, das ist so, daran wird tatsächlich gearbeitet. 705 00:52:30,300 --> 00:52:35,030 Insbesondere die britische Regierung hat auch Forschungsgruppen, die erforschen 706 00:52:35,030 --> 00:52:41,890 sollen, wie Blockchains der Verwaltung helfen können. Gerade beim Grundbuchamt, 707 00:52:41,890 --> 00:52:46,000 also solche Systeme brauchen starke Anpassungen, gerade wenn wir uns 708 00:52:46,000 --> 00:52:52,460 vorstellen, ein Grundbuchamt, wenn es dann jemandem gelingen würde, irgendwie 709 00:52:52,460 --> 00:52:55,690 jetzt trotzdem ein Grundstück quasi zu stehlen, und das würde einfach 710 00:52:55,690 --> 00:53:01,960 in dieser Blockchain drin feststehen, wie würde man das wieder rückgängig machen? 711 00:53:01,960 --> 00:53:06,120 Also wenn wir heute ein Grundbuchamt haben, dann können die alles überschreiben. 712 00:53:06,120 --> 00:53:10,230 Und irgendwie möchten wir ja dann trotzdem nicht einfach nur dieser Blockchain vertrauen. 713 00:53:10,230 --> 00:53:14,810 Wir möchten trotzdem die Möglichkeit haben, dass gewisse Stellen, gerade eben 714 00:53:14,810 --> 00:53:18,020 unser Staat, das überschreiben können. Da müssen dann in diese Blockchains 715 00:53:18,020 --> 00:53:22,460 zusätzliche Mechanismen eingebaut werden, dass das trotzdem geht, und das ist dann 716 00:53:22,460 --> 00:53:26,850 halt bedenklich, weil jetzt trotzdem da jemand das Zeugs kaputtmachen kann. 717 00:53:26,850 --> 00:53:30,750 Also das ist nicht ganz einfach, diese Dinge zu tun. Aber ich denke schon, 718 00:53:30,750 --> 00:53:38,360 dass gerade Grundbuchämter eine gute Chance sind, und das ist vermutlich auch 719 00:53:38,360 --> 00:53:43,760 etwas vom Ersten, was wir implementiert sehen werden. Soviel für öffentliche Ämter. 720 00:53:43,760 --> 00:53:48,000 Aber ich denke auch, dass es einen Hybridbetrieb geben wird. Also 721 00:53:48,000 --> 00:53:51,580 dass man quasi sagt, das ist zwar öffentlich in einer Blockchain, aber 722 00:53:51,580 --> 00:53:56,360 schlussendlich, was wirklich gilt ist immer noch das, was im Grundbuchamt steht, 723 00:53:56,360 --> 00:53:59,480 und das wird dann halt solange so weiterbetrieben, bis sich das wirklich 724 00:53:59,480 --> 00:54:03,220 bewährt hat, und man den Übergang macht. Und die zweite Frage, sorry, habe ich 725 00:54:03,220 --> 00:54:07,190 wieder vergessen. 726 00:54:07,190 --> 00:54:10,500 Herald: Okay, wenn das die Frage beantwortet und er nicht wieder aufsteht, 727 00:54:10,500 --> 00:54:14,760 dann würde ich jetzt mit Mikrofon 7 weitermachen, dort oben, bitte. 728 00:54:14,760 --> 00:54:20,140 Frage: Ja, vielen Dank für den spannenden Vortrag. Mich würde noch interessieren, 729 00:54:20,140 --> 00:54:24,970 vielleicht noch was zu dem Thema ‚Ende der Bitcoins‘, die sind ja anscheinend 730 00:54:24,970 --> 00:54:29,220 begrenzt, soweit ich das verstanden habe. Und wie wird das Erstellen von neuen 731 00:54:29,220 --> 00:54:33,880 Blöcken letztendlich in ferner Zukunft dann belohnt, werden die einfach immer so 732 00:54:33,880 --> 00:54:36,690 weiter unterteilt, und man bekommt dann nur noch Bruchteile von Bitcoins 733 00:54:36,690 --> 00:54:38,280 als Belohnung, oder wie funktioniert das? 734 00:54:38,280 --> 00:54:41,520 vimja: Das ist eine sehr gute Frage, die sich natürlich auch diesen Sommer 735 00:54:41,520 --> 00:54:45,470 gestellt hat, weil sich ja der Block Reward halbiert hat. 736 00:54:45,470 --> 00:54:49,150 Und erstaunlicherweise ist es dann aber eigentlich ohne Weiteres weitergegangen. 737 00:54:49,150 --> 00:54:53,210 Nun ist es so, der Mechanismus, der eigentlich greifen sollte, ist 738 00:54:53,210 --> 00:54:57,880 die Transaction Fees. Dass es durch die Transaction Fees getragen wird, 739 00:54:57,880 --> 00:55:02,550 diese Gebühr. Nur ist es heute so, dass die Transaction Fees so niedrig sind, 740 00:55:02,550 --> 00:55:07,410 dass das Minen sich nicht rentieren würde, also der Stromverbrauch ist viel zu hoch, 741 00:55:07,410 --> 00:55:13,720 als dass es sich lohnen würde, nur für die Transaction Fees zu minen. 742 00:55:13,720 --> 00:55:17,230 Andererseits ist es aber so, dass die Transaction Fees heute schon sehr hoch 743 00:55:17,230 --> 00:55:21,090 sind, also die kommen heute irgendwo zwischendurch schon in die Bereiche 744 00:55:21,090 --> 00:55:24,740 der Transaction Fees, die man auch zahlt bei Kreditkartenüberweisungen. 745 00:55:24,740 --> 00:55:28,580 Und das ist natürlich absolut lächerlich hoch. Und dann ist es aber auch so, 746 00:55:28,580 --> 00:55:32,970 dass die Blöcke voll sind, d.h. wenn das Block Limit – das ist ein künstliches 747 00:55:32,970 --> 00:55:37,260 Limit, wie groß die Blöcke sein dürfen, und die Community führt da großen Krieg 748 00:55:37,260 --> 00:55:41,690 darüber ob man das jetzt ändern soll oder nicht – aber wenn dieses Limit halt nicht 749 00:55:41,690 --> 00:55:44,770 erhöht wird, dann passen nicht mehr Transaktionen rein, und dann ist 750 00:55:44,770 --> 00:55:48,770 der einzige Weg höhere Transaction… also mehr Transaction Fees zu haben 751 00:55:48,770 --> 00:55:51,620 für den Miner, ist diese Transaction Fees zu erhöhen. Und wenn man die weiter 752 00:55:51,620 --> 00:55:55,920 erhöht, dann lohnt es sich einfach nicht mehr, Bitcoin zu verwenden. 753 00:55:55,920 --> 00:55:58,531 Im Moment ist es noch nicht so ein Problem, für die nächsten vier Jahre 754 00:55:58,531 --> 00:56:02,640 sind es ja noch 12,5 Bitcoin die man kriegt. Aber wie es danach 755 00:56:02,640 --> 00:56:07,200 weitergehen wird, das muss man abwarten, und dann schauen, was da genau passiert. 756 00:56:07,200 --> 00:56:10,750 Und ich denke dass das ist auch noch ein dynamisches System, das sich schnell 757 00:56:10,750 --> 00:56:14,960 wandelt, und da werden auch noch viele Leute viele gute Ideen haben. 758 00:56:14,960 --> 00:56:17,770 Frage: Darf ich noch mal kurz was nachfragen? D.h. der Proof-of-Work 759 00:56:17,770 --> 00:56:22,980 ist nicht der direkte Bitcoin, den ich bekomme, also nicht die 12,5 Bitcoins, 760 00:56:22,980 --> 00:56:28,230 die ich bekomme, um einen Block zu erstellen, ist nicht der Proof-of-Work? 761 00:56:28,230 --> 00:56:31,930 vimja: Nein nein, das ist… die 12,5 Bitcoin die du kriegst, also die 12,5 Bitcoin 762 00:56:31,930 --> 00:56:34,940 plus das klein weniger, was von den Transaction Fees kommt, das ist 763 00:56:34,940 --> 00:56:39,430 der Block Reward. Nennt sich das. Und der Proof-of-Work ist einfach der Beweis dafür, 764 00:56:39,430 --> 00:56:44,790 dass du die Arbeit auf dich genommen hast, einen Block zu erstellen. 765 00:56:44,790 --> 00:56:49,500 Herald: Gut, dann machen wir oben auf dem Balkon weiter mit der 8. Bitte. 766 00:56:49,500 --> 00:56:52,600 Frage: Ja, das ganze Erstellen von den Blöcken basiert ja darauf, dass 767 00:56:52,600 --> 00:56:56,680 Transaktionen in des System reinkommen. Die Frage wäre jetzt, was passiert, wenn 768 00:56:56,680 --> 00:57:01,880 keine Transaktionen zur Verfügung stehen. Werden dann Dummy-Transaktionen erzeugt, 769 00:57:01,880 --> 00:57:03,880 oder leere Blöcke, oder was passiert dann? 770 00:57:03,880 --> 00:57:08,220 vimja: Nein, das kannst du sehen, wenn du ganz zurückgehst, die ersten Blöcke, die 771 00:57:08,220 --> 00:57:11,690 überhaupt erstellt wurden, dort gab es ja noch keine Transaktionen. Was hätte auch 772 00:57:11,690 --> 00:57:16,550 überwiesen werden sollen wenn niemand Geld hat. Und da war es dann halt so, dass 773 00:57:16,550 --> 00:57:21,180 der Block enthält dann nur die Coin-based- Transaktion. Der Miner wird ja immer 774 00:57:21,180 --> 00:57:25,000 eine Coin-based-Transaktion machen. Einfach, weil es für ihn interessant ist. 775 00:57:25,000 --> 00:57:33,150 Und dann erstellt er halt einen Block, der nur diese Coin-based-Transaktion enthält. 776 00:57:33,150 --> 00:57:35,940 Herald: Dann machen wir weiter hier vorne mit der 2. Bitte. 777 00:57:35,940 --> 00:57:38,300 *Mikro 2 will Mikro 4 Vorrang geben* Bitte? 778 00:57:38,300 --> 00:57:41,720 Wenn du nicht möchtest, dann machen wir mit der 4 weiter! Sehr fair von dir! 779 00:57:41,720 --> 00:57:48,830 Frage: Och, dankeschön. Ich habe das Thema ‚Blockchain‘ in verschiedenen Kontexten 780 00:57:48,830 --> 00:57:51,480 jetzt im letzten Jahr sehr viel gesehen. Es ist fast ein Buzzword in sehr sehr 781 00:57:51,480 --> 00:57:55,900 vielen Branchen, von FinTech bis zu IoT oder wo auch immer. Konntest du 782 00:57:55,900 --> 00:57:59,920 im Kontext deiner Arbeit ein bisschen so einen Trend raussehen, wo sich da 783 00:57:59,920 --> 00:58:04,100 erste Anwendungen wirklich bewähren können? 784 00:58:04,100 --> 00:58:08,420 vimja: Erste Anwendungen gibt es ja bereits. Du kannst mit Bitcoin Dinge bezahlen. 785 00:58:08,420 --> 00:58:13,930 Aber das ist so ein wenig eine Sache. Eines, was ich gesehen habe, wo ich mich 786 00:58:13,930 --> 00:58:17,800 aber schlicht weigere mich zu beteiligen, ist halt dass Banken das zu verwenden 787 00:58:17,800 --> 00:58:22,890 versuchen, um die Transaktionen zwischen den Banken zu regeln. Da wird es ja, 788 00:58:22,890 --> 00:58:26,410 glaube ich, im Anschluss im Saal G einen Talk geben dazu, wie das heute 789 00:58:26,410 --> 00:58:30,980 gemacht wird, wie Banken zwischeneinander Geld austauschen. Und das möchte man 790 00:58:30,980 --> 00:58:34,220 in Zukunft mit Bitcoin [*eher: Blockchain*] machen. Und da sind die Banken auch dran, 791 00:58:34,220 --> 00:58:38,940 sehr viel Geld und sehr viel Zeit rein zu investieren. Das ist halt sehr schade, 792 00:58:38,940 --> 00:58:43,210 dass diese eigentlich coole Technologie jetzt für sowas verwendet werden soll. 793 00:58:43,210 --> 00:58:48,940 Aber ich denke das ist eine Anwendung die kommt. Dann eben einfache Kryptowährungen, 794 00:58:48,940 --> 00:58:53,540 wie etwa Bitcoin, um Dinge zu bezahlen. Und auch… 795 00:58:53,540 --> 00:58:57,590 ich denke auch mit Ethereum, eben gerade diese Smart Contracts werden kommen, 796 00:58:57,590 --> 00:59:01,340 dass man halt eben irgendwelche Dinge, irgendwelche Third Parties, die man 797 00:59:01,340 --> 00:59:05,970 verwendet für Dinge zu regeln, ersetzen wir jetzt aber. Was jetzt als Erstes 798 00:59:05,970 --> 00:59:09,560 quasi den Durchbruch schaffen wird und als Großes eingesetzt werden wird, 799 00:59:09,560 --> 00:59:11,770 kann ich dir nicht sagen. 800 00:59:11,770 --> 00:59:15,630 Herald: Gut, dann, wir sind so ganz knapp an der Zeit, aber du darfst deine Frage 801 00:59:15,630 --> 00:59:17,050 auf jeden Fall stellen, bitte! 802 00:59:17,050 --> 00:59:20,520 Frage: Ist auch nur eine ganz kurze, schnelle Frage. Gibt es einen Schutz 803 00:59:20,520 --> 00:59:24,460 gegen DDoS, dass ich irgendwie das Netzwerk mit falschen Transaktionen 804 00:59:24,460 --> 00:59:27,890 bombardiere, und dann bricht alles zusammen, gibt es da irgendwie 805 00:59:27,890 --> 00:59:29,120 einen Schutz dagegen? 806 00:59:29,120 --> 00:59:31,930 vimja: Ja, das war ja ganz interessant. Das hat es glaube ich vor über einem Jahr 807 00:59:31,930 --> 00:59:35,050 gegeben, bei Bitcoin, dass das passiert ist, und die waren sich dann 808 00:59:35,050 --> 00:59:38,630 nicht so ganz einig in der Community, weil die mögen sich sowieso nicht mehr, 809 00:59:38,630 --> 00:59:42,270 und ‚kriegen‘ nur miteinander, die waren sich da nicht so ganz einig, ob das jetzt 810 00:59:42,270 --> 00:59:46,391 ein Test war, oder ob das ein DDoS war. Und das Interessante daran ist ja, 811 00:59:46,391 --> 00:59:51,630 dass es ja tatsächlich Geld kostet, eine Transaktion zu machen. Also du zahlst 812 00:59:51,630 --> 00:59:55,790 zuerst eine Transaction-Gebühr, und der Schutz sollte eigentlich, hoffentlich, 813 00:59:55,790 --> 00:59:59,520 sein, dass das da zu teuer ist. Aber offenbar gibt es immer noch 814 00:59:59,520 --> 01:00:04,340 so viele Bitcoin-Millionäre, die einfach Bitcoins haben zum Davonschmeißen, 815 01:00:04,340 --> 01:00:08,200 und die dann sowas tun können. Es wird auf jeden Fall an irgendwelchen 816 01:00:08,200 --> 01:00:11,770 Schutzmechanismen gearbeitet, aber was das ist… *zuckt mit den Schultern* 817 01:00:11,770 --> 01:00:15,530 Also was es gibt, in Bitcoin, ist dieses Replace-by-Fee, 818 01:00:15,530 --> 01:00:22,890 damit die Transaction-Gebühr nach der Veröffentlichung der Transaktion 819 01:00:22,890 --> 01:00:25,920 anschließend noch erhöht werden kann. Und damit kannst du halt… 820 01:00:25,920 --> 01:00:29,030 wenn du jetzt siehst, es kommen sehr viele DDoS-Transaktionen rein, kannst du halt 821 01:00:29,030 --> 01:00:33,640 im Nachhinein die Transaction-Gebühr erhöhen, und das dadurch den Minern 822 01:00:33,640 --> 01:00:38,480 quasi schmackhaft machen, deine valide Transaktion zu includen. 823 01:00:38,480 --> 01:00:43,600 Dieses Replace-by-Fee, dieses RBF, ist aber sehr stark umstritten, und 824 01:00:43,600 --> 01:00:49,580 wird auch standardmäßig nicht aktiviert von der Client-Software. 825 01:00:49,580 --> 01:00:56,290 Herald: Gut, dann danke vimja, für diese großartige Einführung in die Blockchain! 826 01:00:56,290 --> 01:01:01,030 *Beifall* 827 01:01:01,030 --> 01:01:05,070 *Abspannmusik* 828 01:01:05,070 --> 01:01:24,901 *Untertitel erstellt von c3subtitles.de im Jahr 2017. Mach mit und hilf uns!*