0:00:00.000,0:00:13.890
33C3-Vorspannmusik
0:00:13.890,0:00:20.810
Herald: Gut, dann machen wir[br]weiter mit dem nächsten Vortrag.
0:00:20.810,0:00:24.509
Der ist von vimja, der ist[br]Informatikstudent aus Bern in der Schweiz,
0:00:24.509,0:00:28.740
und er arbeitete bzw. er[br]beschäftigte sich mit Bitcoin
0:00:28.740,0:00:32.890
und Ethereum, und schrieb seine[br]Bachelorarbeit über die Suche
0:00:32.890,0:00:38.210
nach Informationen in der Bitcoin-[br]Blockchain. Und da macht es total Sinn,
0:00:38.210,0:00:43.120
dass der uns jetzt eine Einführung[br]zu Blockchains präsentieren wird.
0:00:43.120,0:00:45.580
Ein großer Applaus für vimja!
0:00:45.580,0:00:50.030
Applaus mit Pfeifen und Jubel[br]Das ist deine Bühne!
0:00:50.030,0:00:56.519
weiterhin Applaus
0:00:56.519,0:00:58.920
vimja: Toll, das ist jetzt[br]gerade kaputtgegangen.
0:00:58.920,0:01:05.460
Gelächter
0:01:05.460,0:01:08.000
So ist es besser.
0:01:08.000,0:01:13.230
Applaus[br]Danke.
0:01:13.230,0:01:19.980
Genau, das geht jetzt[br]natürlich auch nicht.
0:01:19.980,0:01:22.240
Mache ich es halt von Hand.
0:01:22.240,0:01:27.740
Ist vermutlich, weil ihr alle das Wi-Fi[br]braucht, geht das 2,4-GHz-Band nicht mehr.
0:01:27.740,0:01:31.570
Ja das hat er euch ja alles[br]schon gesagt, der Herald.
0:01:31.570,0:01:34.680
In dieser Zeit, in der ich mich[br]mit Blockchains befasst habe,
0:01:34.680,0:01:39.270
durfte ich natürlich sehr viele[br]sehr interessante Dinge lernen,
0:01:39.270,0:01:41.830
und ich möchte jetzt heute abend[br]einen Teil dieses Wissens
0:01:41.830,0:01:48.810
an euch weitergeben. Genau.
0:01:48.810,0:01:52.710
Das Ganze ist natürlich ein sehr komplexes[br]Thema, das viele komplizierte Dinge
0:01:52.710,0:01:56.120
enthält, und deshalb fangen wir jetzt mit[br]etwas sehr einfachem an, was wir alles
0:01:56.120,0:01:59.850
kennen. Und zwar herkömmliche[br]Besitzsysteme – also Systeme,
0:01:59.850,0:02:04.100
die ausdrücken wem etwas gehört. Und,[br]eigentlich, mit der Erkenntnis, dass man
0:02:04.100,0:02:11.190
all diese Besitzsysteme als[br]Zustandsübergangssysteme darstellen kann.
0:02:11.190,0:02:16.019
Das gilt sowohl für Finanzsysteme,[br]die wir haben um Geld zu verwalten,
0:02:16.019,0:02:20.090
als auch etwa für Grundstücke, also[br]Systeme mit denen wir verwalten,
0:02:20.090,0:02:23.490
wem ein Grundstück gehört.
0:02:23.490,0:02:27.520
Das Mapping funktioniert dann in etwa[br]so, dass wir sagen, der Zustand ist
0:02:27.520,0:02:33.510
die Sammlung der Informationen wem[br]was gehört. Und jedes Übertragen
0:02:33.510,0:02:37.720
eines Besitzes ist eine Transition,[br]die zu einem neuen Zustand führt.
0:02:37.720,0:02:41.760
Also am Beispiel eines finanziellen[br]Systems sagen wir, der Zustand ist
0:02:41.760,0:02:45.879
die Sammlung aller Konten, die es gibt.[br]Das drückt für jede Person aus,
0:02:45.879,0:02:51.230
wieviel Geld ihr gehört. Und ein Übergang[br]ist, wenn jemand eine Transaktion macht,
0:02:51.230,0:02:54.160
also Geld überweist, von einem Konto[br]zu einem anderen, dann führt das
0:02:54.160,0:02:58.440
zu einem neuen Zustand.[br]So, das sehen wir hier abgebildet
0:02:58.440,0:03:02.280
mit Grundstücken. Wir sehen hier, der[br]Zustand, der enthält diese Information,
0:03:02.280,0:03:06.760
wem die Grundstücke gehören.[br]Und dann verkauft der Bob
0:03:06.760,0:03:10.890
sein Grundstück Nr. 42 an Alice und[br]das führt zu einem neuen Zustand.
0:03:10.890,0:03:15.660
Ich habe da den Unterschied markiert,[br]damit der eindeutig sichtbar ist.
0:03:15.660,0:03:20.410
Nun, in all diesen Systemen ist es sehr[br]wichtig, dass sich alle Teilnehmer des
0:03:20.410,0:03:26.150
Systems auf einen Zustand einigen können.[br]Dass sie sich einig sind, wem was gehört.
0:03:26.150,0:03:30.050
Denn wenn sie das nicht können, sind[br]Angriffe auf das System möglich,
0:03:30.050,0:03:32.950
insbesondere der sogenannte[br]Double-Spend-Angriff,
0:03:32.950,0:03:37.840
der in der Blockchain-Welt bekannt und[br]gefürchtet ist. Und was bedeutet das?
0:03:37.840,0:03:41.440
Das ist ganz einfach, wenn jemand etwas[br]zweimal ausgibt. Bei Geld ist das ein
0:03:41.440,0:03:45.310
wenig abstrakt (also wie gibt man zweimal[br]dasselbe Geld aus), aber bei Grundstücken
0:03:45.310,0:03:48.990
ist das ganz einfach. Stellen wir uns vor,[br]jemand verkauft dasselbe Grundstück
0:03:48.990,0:03:54.880
zweimal. Das ist natürlich kriminell[br]und darf nicht vorkommen.
0:03:54.880,0:03:57.850
Schauen wir uns jetzt mal an wie[br]das funktioniert. Stellen wir uns vor,
0:03:57.850,0:04:01.940
Malroy hat ein schönes Grundstück,[br]das Grundstück Nr. 5. Und sowohl Alice
0:04:01.940,0:04:05.700
als auch Bob möchten gerne das[br]Grundstück kaufen. Und Malroy
0:04:05.700,0:04:10.020
wird jetzt versuchen, das an beide zu[br]verkaufen. Also trifft er sich mit Alice.
0:04:10.020,0:04:13.761
Das ist also jetzt der aktuelle Zustand.[br]Wir haben gesehen, das Grundstück Nr. 5
0:04:13.761,0:04:20.430
gehört hier dem Malroy. Der trifft sich[br]mit Alice. Und er verkauft es an Alice.
0:04:20.430,0:04:24.550
Er überweist ihr das Grundstück. Wir sehen[br]diese Transition – überweist das Grundstück
0:04:24.550,0:04:29.129
von Malroy an Alice. Und im neuen Zustand[br]gehört es jetzt der Alice. So, der Bob,
0:04:29.129,0:04:31.990
der hat davon nichts mitgekriegt.[br]Irgendwie – Bob und Alice wissen
0:04:31.990,0:04:36.300
immer noch nicht recht wie man sicher[br]miteinander kommuniziert. Und deshalb
0:04:36.300,0:04:39.199
weiß der Bob jetzt nichts davon, dass[br]die Alice das Grundstück gekauft hat.
0:04:39.199,0:04:43.680
Er denkt, das Grundstück gehört immer noch[br]Malroy. Also trifft er sich mit Malroy.
0:04:43.680,0:04:47.939
Und auch er einigt sich mit Malroy auf[br]einen Preis. Und Malroy tut jetzt so,
0:04:47.939,0:04:52.710
als würde er den Besitz des[br]Grundstücks an Bob übertragen.
0:04:52.710,0:04:56.460
Und für Bob sieht die Welt jetzt so[br]aus, d.h. Bob ist überzeugt, das ist
0:04:56.460,0:05:00.339
der korrekte Zustand des Systems.[br]Da haben wir natürlich ein Problem,
0:05:00.339,0:05:03.290
weil Bob und Alice, die sind sich[br]jetzt gar nicht einig darüber,
0:05:03.290,0:05:07.499
wem das Grundstück gehört. Ja, Malroy[br]ist natürlich abgehauen mit dem Geld.
0:05:07.499,0:05:10.980
Und das System ist kaputt, weil Bob[br]und Alice die können nicht mehr
0:05:10.980,0:05:14.690
miteinander handeln. Und auch wenn[br]jetzt jemand anderes das Grundstück
0:05:14.690,0:05:18.749
kaufen möchte: Bei wem kauft er es[br]denn jetzt? Was ist denn rechtmäßig?
0:05:18.749,0:05:23.859
Nun, in der Welt der Grundstücke gibt[br]es dafür eine ganz einfache Lösung,
0:05:23.859,0:05:27.560
nämlich das Grundbuchamt. Und das[br]Grundbuchamt fungiert eigentlich
0:05:27.560,0:05:33.310
als zentrale Referenzstelle,[br]die den Zustand verwaltet,
0:05:33.310,0:05:37.460
und alle Änderungen verwaltet. Jedesmal[br]wenn jemand ein Grundstück verkauft,
0:05:37.460,0:05:42.089
muss das über das Grundbuchamt erledigt[br]werden. Das Grundbuchamt überprüft,
0:05:42.089,0:05:46.020
dass das überhaupt zulässig ist, ob das[br]Grundstück wirklich der Person gehört
0:05:46.020,0:05:50.169
und führt das dann nach. Und so kann das[br]Grundbuchamt diese einfachen Angriffe
0:05:50.169,0:05:58.960
verhindern. Diese Lösung[br]funktioniert auch für Finanzsysteme.
0:05:58.960,0:06:02.770
Also wenn wir an Banken denken, wenn ich[br]ein Konto habe, da ist dann halt die Bank
0:06:02.770,0:06:07.289
die zentrale Autorität, welche den Zustand[br]verwaltet. Für jede… jedesmal,
0:06:07.289,0:06:11.499
wenn ich eine Transaktion mache, also Geld[br]überweise, überprüft die Bank vorher,
0:06:11.499,0:06:15.759
ob ich wirklich das nötige Geld dazu[br]habe. Und dann wird mein Kontostand
0:06:15.759,0:06:22.499
nachgeführt. Und die verwaltet so[br]für alle Teilnehmer den Zustand.
0:06:22.499,0:06:26.919
Und das funktioniert eigentlich erstaunlich[br]gut. Nun wollen wir ein System, mit dem
0:06:26.919,0:06:31.229
wir Zahlungen über das Internet abwickeln[br]können. Und wir hätten gerne, dass das
0:06:31.229,0:06:34.849
dezentral ist. Weil, wenn das nicht[br]dezentral ist, dann kann natürlich
0:06:34.849,0:06:39.909
eine zentrale Autorität das System[br]zensieren und manipulieren.
0:06:39.909,0:06:43.539
Und eine zentrale Stelle kann angegriffen[br]werden. Ich denke, wir haben das alle
0:06:43.539,0:06:47.719
in den letzten Jahren beobachten müssen,[br]wie Paypal sehr einfach willkürlich
0:06:47.719,0:06:52.650
Konten sperrt, und das System zensiert.[br]So, und deshalb brauchen wir ein
0:06:52.650,0:06:56.250
besseres System, eine bessere[br]Lösung für das Internetzeitalter.
0:06:56.250,0:06:59.840
Und diese bessere Lösung ist[br]natürlich die ‚Blockchain‘.
0:06:59.840,0:07:05.760
Die Blockchain bringt einige ganz[br]unglaubliche Eigenschaften mit sich.
0:07:05.760,0:07:09.529
Die Blockchain braucht keine zentrale[br]Stelle um den Zustand zu verwalten.
0:07:09.529,0:07:12.930
Die Teilnehmer des Systems müssen sich[br]gegenseitig nicht vertrauen, sie müssen
0:07:12.930,0:07:16.419
sich gegenseitig nicht kennen. Sie müssen[br]nicht einmal wissen, wieviele Leute
0:07:16.419,0:07:19.990
denn eigentlich da teilnehmen. Und[br]trotzdem können die sich alle immer
0:07:19.990,0:07:25.469
auf einen Zustand des Systems einigen.
0:07:25.469,0:07:27.960
Ich werde das jetzt demonstrieren,[br]die Regeln, die wir brauchen
0:07:27.960,0:07:32.250
um das zu ermöglichen. Anhand[br]einer sehr einfachen Blockchain,
0:07:32.250,0:07:35.759
die in diesem ersten Kapitel auch[br]noch keinen Proof-of-Work hat. Also
0:07:35.759,0:07:39.149
diese erste Blockchain wird noch[br]angreifbar sein. Und ich werde auch
0:07:39.149,0:07:42.970
zeigen wie es geht. Und erst im nächsten[br]Kapitel dann werde ich erklären,
0:07:42.970,0:07:47.820
welche Maßnahmen wir ergreifen[br]müssen, um Angriffe zu verhindern.
0:07:47.820,0:07:51.659
Und das Ganze fängt an mit dem Netzwerk[br]welches wir nutzen. Also wir sagen quasi,
0:07:51.659,0:07:55.039
wir sind alle diese Leute, und wir würden[br]gerne miteinander Transaktionen machen
0:07:55.039,0:07:59.759
können. Und zuerst einigen wir uns[br]alle auf einen Ursprungszustand.
0:07:59.759,0:08:03.319
Damit fangen wir an. Wir sagen z.B.[br]„am Anfang gehört allen nichts“.
0:08:03.319,0:08:08.429
Das ist ein leerer Zustand. Und dann[br]brauchen wir ein p2p-Netzwerk.
0:08:08.429,0:08:13.529
Und jedesmal wenn jemand Geld überweist[br]an jemand anderes, dann veröffentlicht er
0:08:13.529,0:08:17.490
die Transaktion in diesem Netzwerk,[br]und das Netzwerk leitet die Transaktion
0:08:17.490,0:08:21.949
solange an alle Teilnehmer weiter,[br]bis alle Teilnehmer diese Transaktion
0:08:21.949,0:08:27.169
gesehen haben. Das bringt[br]natürlich viele Probleme mit sich.
0:08:27.169,0:08:29.529
Das Netzwerk ist irgendwie nicht[br]synchronisiert, nicht alle Leute
0:08:29.529,0:08:34.510
sehen die gleichen Transaktionen, die[br]Reihenfolge der Transaktionen ist unklar.
0:08:34.510,0:08:37.940
Leute werden versuchen das anzugreifen[br]– das wird dazu führen, dass es
0:08:37.940,0:08:42.458
Transaktionen gibt die nicht miteinander[br]kompatibel sind. Und irgendwie
0:08:42.458,0:08:45.310
Transaktionen, die abhängen von[br]nicht-kompatiblen Transaktionen und
0:08:45.310,0:08:49.790
dann auch wieder nicht kompatibel sind.[br]Das ist ein riesengroßes Durcheinander da.
0:08:49.790,0:08:52.370
Und deshalb brauchen wir jetzt[br]eine Möglichkeit, wie wir uns alle
0:08:52.370,0:08:57.180
auf einen Zustand, auf einen Konsens[br]einigen können. Und – wie gesagt –
0:08:57.180,0:09:00.790
das ist jetzt die ‚Blockchain‘.
0:09:00.790,0:09:04.420
Und wir definieren einige Regeln,[br]die wir anwenden um uns zu einigen.
0:09:04.420,0:09:08.240
Wir sagen, wir gruppieren die Transaktionen[br]die vorher so lose auf dem Netzwerk waren
0:09:08.240,0:09:13.470
zu Blöcken. Die Blöcke hängen alle[br]voneinander ab. Wir sagen dann auch,
0:09:13.470,0:09:17.780
der aktuelle Zustand des Netzwerks ist das[br]Ende der längsten Kette zusammenhängender
0:09:17.780,0:09:22.720
Blöcke. Und die Blöcke müssen einige[br]Kriterien erfüllen. Ich habe das da…
0:09:22.720,0:09:26.940
also das ist jetzt quasi der Ur… der[br]leere Zustand, mit dem wir beginnen.
0:09:26.940,0:09:32.300
Und da kommen da Transaktionen[br]über das Netzwerk. Und irgendwann
0:09:32.300,0:09:34.950
macht jemand einen Block der diese[br]Transaktionen zusammenfasst. Und jetzt
0:09:34.950,0:09:39.810
sehen wir am Ende dieses Blocks ist[br]der Zustand. Wenn ich diesen Zustand
0:09:39.810,0:09:43.110
nachvollziehen will dann nehme ich den[br]leeren Ursprungszustand, und dann
0:09:43.110,0:09:47.080
jede Transaktion aus dem ersten Block,[br]und dann wende ich diese Transaktionen,
0:09:47.080,0:09:52.170
eine nach der anderen, auf den Zustand[br]an, und dann erhalte ich den Endzustand.
0:09:52.170,0:09:55.421
Mit der Zeit kommen[br]neue Transaktionen rein
0:09:55.421,0:10:00.140
über das Netzwerk. Und diese Transaktionen[br]werden nicht Teil des Zustands
0:10:00.140,0:10:02.950
– wir haben ja gesagt der Zustand ist das[br]Ende der längsten Kette von Blöcken,
0:10:02.950,0:10:06.270
und die sind in keinem Block. Erst wenn[br]jemand einen Block daraus macht,
0:10:06.270,0:10:09.890
werden die Teil des Zustands.[br]Wir sehen auch, die Blöcke hängen jeweils
0:10:09.890,0:10:13.540
voneinander ab, die haben so einen Pfeil,[br]der sie miteinander verbindet, also
0:10:13.540,0:10:18.590
jeder Block zeigt auf den vorhergehenden[br]Block, und bildet so eben diese Kette
0:10:18.590,0:10:23.650
von Blöcken. Nun, jetzt versucht trotzdem[br]jemand da eine bösartige Transaktion
0:10:23.650,0:10:27.810
zu machen, die mit den anderen nicht[br]kompatibel ist. Da macht jemand
0:10:27.810,0:10:32.000
einen Block daraus. Und jetzt sagen[br]wir aber einfach, Blöcke, die
0:10:32.000,0:10:35.470
Transaktionen enthalten welche sich[br]widersprechen sind nicht valide.
0:10:35.470,0:10:38.360
Der Block, den kann zwar jemand[br]erstellen, aber wir sagen dann, das ist
0:10:38.360,0:10:42.180
kein valider Block, der wird vom Netzwerk[br]nicht akzeptiert. Und der wird auch
0:10:42.180,0:10:46.450
nicht Teil des Zustands. Also wenn jemand[br]einen Block bauen will und eine dieser
0:10:46.450,0:10:52.610
Transaktionen enthält, dann muss sich[br]derjenige der den Block erstellt
0:10:52.610,0:10:56.090
entscheiden welche der Transaktionen[br]denn jetzt enthalten sein sollen
0:10:56.090,0:11:00.280
in dem Block. Und die anderen lässt er[br]außen vor. Für welche er sich entscheidet,
0:11:00.280,0:11:04.660
das ist dem Typen ganz allein überlassen.[br]Er kann das selber entscheiden was er da
0:11:04.660,0:11:10.690
reinpacken will. Dann kommen mit[br]der Zeit neue Transaktionen rein.
0:11:10.690,0:11:14.300
Und jetzt könnte es sein, dass jemand so[br]einen Block Nummer 4 macht, welcher
0:11:14.300,0:11:18.730
jetzt trotzdem wieder die böse Transaktion[br]enthält. Und dann sagen wir aber einfach,
0:11:18.730,0:11:21.911
Blöcke welche Transaktionen enthalten,[br]welche nicht kompatibel sind
0:11:21.911,0:11:25.450
mit Transaktionen in älteren Blöcken sind[br]auch ungültig, und der Block wird auch
0:11:25.450,0:11:29.870
nicht Teil des Zustands. So. Was aber[br]gültig ist, ist jemand der einen Block
0:11:29.870,0:11:33.880
Nummer 3 macht, der so aussieht. Und jetzt[br]haben wir das Problem: Wir haben gesagt,
0:11:33.880,0:11:36.640
der Zustand ist die längste Kette von[br]Blöcken. Hier ist jetzt der Zustand
0:11:36.640,0:11:40.370
nicht mehr eindeutig definiert und da muss[br]jetzt halt jeder Teilnehmer des Netzwerkes
0:11:40.370,0:11:44.960
selbst entscheiden wie er damit umgeht,[br]was er jetzt als Zustand anerkennt.
0:11:44.960,0:11:48.240
So, aber dann kommen halt neue[br]Transaktionen wieder rein. Und irgendwann
0:11:48.240,0:11:52.590
baut jemand einen Block Nummer 4, der[br]diese Transaktion enthält. Und dadurch,
0:11:52.590,0:11:57.920
dass der Block Nr. 4 auf den vorherigen[br]Block Nr. 3 verweist, ist es jetzt klar,
0:11:57.920,0:12:01.530
von welchem Block der abhängt.[br]Und damit ist die Kette auch wieder klar,
0:12:01.530,0:12:06.300
und die längste Kette wird wieder zum[br]Zustand. So. Jetzt habe ich gesagt,
0:12:06.300,0:12:09.830
diese Blockchain die ich jetzt beschrieben[br]habe hat keinen Proof-of-Work und folglich
0:12:09.830,0:12:14.510
ist sie angreifbar für ein double-spend.[br]Sagen wir Malroy würde gerne
0:12:14.510,0:12:19.050
ein Fahrrad klauen. Er geht da so in den[br]Fahrradladen von Alice, und möchte dort
0:12:19.050,0:12:23.510
gerne ein Fahrrad kaufen, das kostet[br]jetzt 1000 Euro in dem Beispiel.
0:12:23.510,0:12:26.170
Ich werde jetzt… hier habe ich[br]die Darstellung etwas geändert,
0:12:26.170,0:12:30.370
diese Vierecke mit Pfeilen dran, das sind[br]jetzt halt einfach Blöcke. Ich werde
0:12:30.370,0:12:34.570
nicht mehr jede Transaktion einzeln[br]zeichnen. Und die sehen den Zustand,
0:12:34.570,0:12:39.110
wie er da ist. Da sind all die Konten[br]aufgeführt, unter anderem diejenigen
0:12:39.110,0:12:45.070
von Alice und Malroy. So.[br]Malroy geht also in den Laden,
0:12:45.070,0:12:51.340
sucht sich das [Fahrrad] aus, geht zum[br]Tresen und macht dort die Transaktion
0:12:51.340,0:12:56.880
an Alice. Und diese Transaktion wird[br]übers Netzwerk zu Alice weitergeleitet.
0:12:56.880,0:13:00.480
Sie sieht die Transaktion, aber da sie[br]noch nicht Teil eines Blockes ist,
0:13:00.480,0:13:04.260
ist sie auch noch nicht Teil des Zustands.[br]Irgendwann aber erstellt jemand halt
0:13:04.260,0:13:07.880
einen Block der diese Transaktion enthält.[br]Die ist jetzt Teil des Zustandes.
0:13:07.880,0:13:12.760
Wir sehen im Zustand des Systems,[br]dass Alice das Geld erhalten hat.
0:13:12.760,0:13:17.130
Sie gibt das Fahrrad an Malroy, und der[br]fährt davon. Neue Blöcke kommen dazu.
0:13:17.130,0:13:20.860
Und jetzt startet Malroy den Angriff.[br]Und was Malroy macht, er erstellt
0:13:20.860,0:13:25.230
eine alternative Transaktion, die dasselbe[br]Geld überweist, diesmal aber nicht
0:13:25.230,0:13:30.260
an Alice sondern an sich selbst. Genauer:[br]an ein zweites Konto das ebenfalls ihm
0:13:30.260,0:13:36.510
gehört. Und er erstellt einen alternativen[br]Block, der diese Transaktion enthält.
0:13:36.510,0:13:40.830
Und dann erstellt er ganz viele neue[br]Blöcke die davon abhängen. Solange,
0:13:40.830,0:13:44.670
bis seine Kette von Blöcken länger[br]ist als die anderen, also die Kette,
0:13:44.670,0:13:49.570
die zur Zeit auf dem Netzwerk ist. Und[br]dann veröffentlicht er die gesamte Kette
0:13:49.570,0:13:53.540
auf dem Netzwerk. Und jetzt ist seine[br]Kette die längste Kette. Die wird
0:13:53.540,0:13:58.380
vom Netzwerk als Zustand anerkannt. Und[br]in diesem Zustand hat er das Geld erhalten.
0:13:58.380,0:14:02.210
Alice hat das Geld nicht erhalten. Und[br]Malroy hat das Fahrrad erfolgreich
0:14:02.210,0:14:05.720
gestohlen. So, das hat also funktioniert.
0:14:05.720,0:14:09.650
Wir müssen das verhindern. Das[br]Problem weshalb Malroy diesen Angriff
0:14:09.650,0:14:13.780
machen konnte ist natürlich, dass er in[br]einer sehr kurzen Folge viele Blöcke
0:14:13.780,0:14:18.230
erstellen konnte. Also das Problem ist[br]eigentlich, es ist zu einfach neue Blöcke
0:14:18.230,0:14:23.250
zu erstellen. Also machen wir es halt[br]schwieriger, neue Blöcke zu erstellen.
0:14:23.250,0:14:27.030
Und dazu sagen wir, für jeden Block[br]der erstellt wird, muss eine Aufgabe
0:14:27.030,0:14:33.980
gelöst werden, eine Challenge.[br]Und um diese Challenge zu erstellen,
0:14:33.980,0:14:40.120
muss man halt Zeit, und Rechenzeit[br]aufwenden. Die Lösung für diese Aufgabe
0:14:40.120,0:14:45.161
nennen wir den Proof-of-Work. Und den[br]Prozess um den Proof-of-Work zu erstellen
0:14:45.161,0:14:49.560
nennen wir das ‚Mining‘. Und dann sagen[br]wir, zusammen mit jedem neuen Block
0:14:49.560,0:14:53.800
muss der passende Proof-of-Work[br]veröffentlicht werden. Und nur Blöcke,
0:14:53.800,0:14:58.210
welche einen passenden Proof-of-Work haben[br]werden vom Netzwerk als Teil des Zustands
0:14:58.210,0:15:03.300
anerkannt. Jetzt funktioniert das[br]Erstellen neuer Blöcke etwas anders.
0:15:03.300,0:15:06.810
Und zwar ist es jetzt so, dass ein Block[br]nicht mehr einfach entsteht, sondern
0:15:06.810,0:15:10.650
ein ‚Miner‘ muss daran arbeiten. Jeder[br]Miner arbeitet natürlich für sich selbst
0:15:10.650,0:15:14.540
daran, einen neuen Block zu erstellen.[br]Wir sehen hier, der Block an dem der Miner
0:15:14.540,0:15:19.991
arbeitet, ist hier so gestrichelt[br]markiert. Und dann, wenn der Miner
0:15:19.991,0:15:23.920
daran arbeitet, kommen neue Transaktionen[br]rein. Und irgendwann gelingt es dem Miner
0:15:23.920,0:15:27.910
den Block fertigzustellen. In dem Moment[br]veröffentlicht er den Block zusammen mit
0:15:27.910,0:15:31.440
dem Proof-of-Work im Netzwerk. Der wird[br]vom Netzwerk anerkannt, und der Miner
0:15:31.440,0:15:39.740
beginnt sofort an einem neuen Block zu[br]arbeiten, und das geht dann halt so weiter.
0:15:39.740,0:15:43.990
Nun, die Funktion die wir brauchen um das[br]Erstellen der Blöcke schwierig zu machen
0:15:43.990,0:15:49.730
muss einige Bedingungen erfüllen. Sie[br]muss natürlich schwierig sein zu lösen.
0:15:49.730,0:15:53.110
Dann muss aber… obwohl es lange gehen[br]muss die zu erstellen, muss es sehr
0:15:53.110,0:15:56.580
einfach sein, das Ergebnis zu prüfen.[br]Also wenn ich einen Block erhalte, und
0:15:56.580,0:16:00.460
den passenden Proof-of-Work, muss[br]ich – zack! – sofort sagen können,
0:16:00.460,0:16:03.390
der Proof-of-Work ist gültig oder nicht,[br]weil ich will ja entscheiden, ob das
0:16:03.390,0:16:07.500
Teil meines Zustandes[br]sein soll oder nicht.
0:16:07.500,0:16:11.960
Und dann ist es wichtig, dass die[br]Funktion abhängt von genau dem Block,
0:16:11.960,0:16:15.230
für den sie erstellt wird. Also der[br]Proof-of-Work soll nur genau
0:16:15.230,0:16:19.140
für den einen Block gültig sein.[br]Das ist sehr wichtig, denn ansonsten
0:16:19.140,0:16:23.589
könnte Malroy auf Vorrat über[br]mehrere Wochen hinweg einfach
0:16:23.589,0:16:27.220
Proof-of-Works erstellen und dann die[br]einfach an einen Block ranflanschen,
0:16:27.220,0:16:31.810
und so in kurzer Zeit trotzdem wieder[br]eine lange Kette erstellen. Wenn aber
0:16:31.810,0:16:37.150
der Proof-of-Work direkt abhängig ist[br]vom Block für den er erstellt wird,
0:16:37.150,0:16:40.150
dann muss Malroy mit dem Erstellen[br]des Proof-of-Work so lange warten,
0:16:40.150,0:16:44.290
bis der vorhergehende Block bekannt[br]ist und damit auch ihm bekannt ist,
0:16:44.290,0:16:47.360
was er jetzt in den neuen Block packt.
0:16:47.360,0:16:52.010
Und dann soll es auch noch möglich sein,[br]die Schwierigkeit der Aufgabe zu variieren.
0:16:52.010,0:16:56.110
Denn damit das System als stabiles[br]Finanzsystem funktioniert, möchte ich
0:16:56.110,0:16:59.250
gerne wissen, wie lange es geht von[br]dem Moment wo ich eine Transaktion
0:16:59.250,0:17:04.409
veröffentliche bis sie Teil des Zustandes[br]wird. Und wenn das Netzwerk
0:17:04.409,0:17:08.000
sehr viel mehr Rechenkraft hat, dann[br]geht es plötzlich schneller, neue Blöcke
0:17:08.000,0:17:11.179
zu erstellen und dann will ich diese[br]Schwierigkeit anpassen können, damit es
0:17:11.179,0:17:16.660
wieder länger geht. Nun jetzt, wo[br]das Mining nicht mehr einfach ist,
0:17:16.660,0:17:20.169
und es aufwendig ist, müssen wir irgendwie[br]einen Incentive haben, damit die Leute
0:17:20.169,0:17:25.089
es auch tun – also irgendeinen Anstoß.[br]So und wir sagen halt, der Miner,
0:17:25.089,0:17:29.020
dem es gelingt einen Block zu erstellen,[br]der bekommt eine Belohnung,
0:17:29.020,0:17:34.350
den sogenannten ‚Block Reward‘, und wir[br]implementieren das, indem wir sagen,
0:17:34.350,0:17:38.010
der Miner darf für sich selbst eine[br]zusätzliche Transaktion in den Block
0:17:38.010,0:17:41.999
hineinpacken, und mit dieser Transaktion[br]überweist er sich selbst Geld
0:17:41.999,0:17:45.809
aus dem Nichts heraus. Wo das[br]Geld herkommt: Es gibt eigentlich
0:17:45.809,0:17:48.779
zwei Möglichkeiten, die populär sind.[br]Entweder sagen wir, das sind
0:17:48.779,0:17:53.110
die Überweisungsgebühren der anderen[br]Transaktionen in dem Block.
0:17:53.110,0:17:57.540
Oder dann sagen wir halt, das ist Geld,[br]welches neu geschaffen wird. Wir haben ja
0:17:57.540,0:18:02.670
vorhin gesehen, wir haben einen leeren[br]Zustand als den Ursprungszustand definiert,
0:18:02.670,0:18:06.069
und wenn wir das so tun, muss das[br]Geld, welches die Leute ausgeben,
0:18:06.069,0:18:10.250
irgendwo herkommen. Und das ist halt eine[br]Möglichkeit, Geld in das System zu bringen,
0:18:10.250,0:18:14.559
die nicht von einer zentralen Stelle[br]kontrolliert wird, und eigentlich
0:18:14.559,0:18:21.290
eine faire Möglichkeit.[br]Etwas weiteres ist, dass…
0:18:21.290,0:18:25.290
diese zusätzliche Transaktion macht[br]den Block natürlich individuell, denn
0:18:25.290,0:18:29.770
jeder Miner wird das Geld an sich selbst[br]zu überweisen versuchen und, also,
0:18:29.770,0:18:35.130
diese eine Transaktion wird für jeden[br]Miner anders sein. Und das stellt sicher,
0:18:35.130,0:18:39.599
dass die alle an einem ein wenig anderen[br]Problem arbeiten. Wenn die alle
0:18:39.599,0:18:43.659
versuchen würden, das genau selbe Problem[br]zu lösen, auf die genau selbe Art,
0:18:43.659,0:18:47.809
dann würde es immer demjenigen als erstes[br]gelingen, der die meiste Rechenkraft hat,
0:18:47.809,0:18:51.679
und das wollen wir nicht, denn dann würde[br]ja eine Person alle Blöcke erzeugen,
0:18:51.679,0:18:54.570
und wir wollen ja, dass viele Personen[br]Blöcke erzeugen, damit das niemand
0:18:54.570,0:18:59.830
zensieren kann. Dadurch, dass das Problem,[br]an welchem sie arbeiten, für jeden Miner
0:18:59.830,0:19:02.749
etwas anders ist, gelingt es halt[br]zwischendurch auch jemandem
0:19:02.749,0:19:06.879
mit weniger Rechenkraft, als erstes eine[br]Lösung zu finden. Und in der Praxis
0:19:06.879,0:19:12.159
geht das dann ganz gut, dass wir sagen[br]können, wer 20% der Rechenkraft hat
0:19:12.159,0:19:15.559
dem wird es auch in etwa einem Fünftel[br]der Fälle gelingen als erstes einen Block
0:19:15.559,0:19:21.210
zu finden. Dann muss der Miner halt[br]noch entscheiden, an welchem Block
0:19:21.210,0:19:25.399
er arbeiten will. Aber der Miner will ja…[br]also an welchem Ende der Kette…
0:19:25.399,0:19:29.129
Wir haben vorhin gesehen, es kann sein,[br]dass diese Ketten mehrere Enden haben.
0:19:29.129,0:19:33.730
Aber das ist ganz einfach, denn der Miner[br]will ja den Reward kriegen. Der Reward ist
0:19:33.730,0:19:37.719
eine Transaktion, welche nur dann[br]Teil des Zustandes wird wenn es Teil
0:19:37.719,0:19:40.740
in einem Block ist, wenn es Teil der[br]längsten Kette ist. Und der Block ist
0:19:40.740,0:19:44.249
nur dann Teil der längsten Kette wenn[br]er an diesem Ende angesetzt wird.
0:19:44.249,0:19:49.039
Also arbeiten alle Miner am Ende der[br]längsten Kette. So, jetzt habe ich
0:19:49.039,0:19:52.970
versprochen, dass wir so den Double-Spend[br]verhindern können, von vorhin.
0:19:52.970,0:19:57.389
Wollen wir mal gucken, ob das geht![br]Das Szenario ist wieder dasselbe.
0:19:57.389,0:20:03.290
Malroy will das Fahrrad klauen,[br]im Laden von Alice.
0:20:03.290,0:20:08.760
Der Unterschied ist, dass das Netzwerk[br]arbeiten muss um die Blöcke zu erstellen.
0:20:08.760,0:20:13.090
Und dann geht es wieder so vonstatten.[br]Malroy erstellt jetzt zwei Transaktionen.
0:20:13.090,0:20:17.110
Eine, um das Geld der Alice zu überweisen.[br]Diese Transaktion macht er öffentlich
0:20:17.110,0:20:20.550
im Netzwerk, damit die von allen gesehen[br]werden kann. Und eine Transaktion,
0:20:20.550,0:20:25.330
um das Geld an sich selbst zu überweisen.[br]Die behält er vorläufig geheim. Dann wird
0:20:25.330,0:20:29.350
der vorhergehende Block fertiggestellt,[br]und sofort fängt das Netzwerk an
0:20:29.350,0:20:34.220
den nächsten Block zu erstellen. Das[br]Netzwerk enthält in dem Block natürlich
0:20:34.220,0:20:37.750
die Transaktion von Malroy an Alice,[br]denn das ist ja die einzige Transaktion
0:20:37.750,0:20:42.129
die dem Netzwerk bekannt ist. Und[br]Malroy arbeitet jetzt ganz alleine daran,
0:20:42.129,0:20:47.579
den alternativen Block zu erstellen. In[br]dem die andere Transaktion enthalten ist.
0:20:47.579,0:20:51.539
Jetzt ist es aber so: das Netzwerk hat[br]natürlich mehr Rechenkraft als Malroy
0:20:51.539,0:20:56.659
allein. Der hat halt nicht so viele[br]Computer. Und deshalb wird das Netzwerk
0:20:56.659,0:21:01.340
immer schneller sein darin, neue Blöcke[br]zu erstellen als Malroy. Malroys Kette
0:21:01.340,0:21:06.169
wird nie die längste Kette, wird nie Teil[br]des Zustands. Und der Angriff wurde
0:21:06.169,0:21:13.779
erfolgreich abgewehrt. Die einzige Art[br]und Weise wie Malroy gewinnen könnte,
0:21:13.779,0:21:17.639
also wie Malroy den Angriff trotzdem[br]durchführen könnte, wäre, wenn er
0:21:17.639,0:21:21.899
schneller Blöcke erstellen könnte als[br]das Netzwerk. Und das wird ihm aber
0:21:21.899,0:21:25.909
nur dann gelingen, wenn er mehr als[br]50% der Rechenkraft im Netzwerk hätte.
0:21:25.909,0:21:28.679
Denn dann wäre die Wahrscheinlichkeit,[br]dass er einen Block findet, höher
0:21:28.679,0:21:33.469
als bei allen anderen Minern gemeinsam.[br]Und dann könnte er das tun. Und deshalb
0:21:33.469,0:21:40.500
spricht man bei Bitcoin und anderen[br]Kryptowährungen von diesen 50%-Attacken.
0:21:40.500,0:21:43.769
So, jetzt gibt es noch eine andere Art,[br]einen Double-Spend auszuführen. Das ist
0:21:43.769,0:21:49.020
ein etwas schwierigerer Angriff.[br]Und er hat jetzt damit zu tun, wie
0:21:49.020,0:21:53.429
das Peer-to-Peer-Netzwerk funktioniert,[br]das wir brauchen um die Transaktionen
0:21:53.429,0:22:01.279
und Blöcke zu verteilen. Jetzt ist der[br]Angriff ein wenig schwieriger, also
0:22:01.279,0:22:05.330
muss Malroy etwas wertvolleres stehlen.[br]Er geht zu Bob. Bob verkauft Autos.
0:22:05.330,0:22:09.520
Er wird versuchen ein Auto zu stehlen.[br]Und um das zu tun, wird er versuchen
0:22:09.520,0:22:13.210
die Verbindung von Bob mit dem[br]Peer-to-Peer-Netzwerk zu kontrollieren.
0:22:13.210,0:22:17.260
Wir sehen hier, Bob ist mit dem Netzwerk[br]verbunden. Mit diesen drei Peers. Und
0:22:17.260,0:22:21.710
Malroy hat zwei Möglichkeiten: entweder[br]er kontrolliert die Internetverbindung
0:22:21.710,0:22:26.490
von Bob. Oder dann kontrolliert er[br]halt die drei Nodes, mit denen Bob
0:22:26.490,0:22:30.400
verbunden ist. Wie realistisch das ist,[br]das will ich hier nicht diskutieren.
0:22:30.400,0:22:34.820
Grundsätzlich ist es ja schon[br]vorstellbar. Und jetzt hat Malroy
0:22:34.820,0:22:39.190
einige interessante Möglichkeiten. Er kann[br]jetzt nämlich kontrollieren, welche Blöcke
0:22:39.190,0:22:43.330
und Transaktionen der Bob sieht.[br]Also Transaktionen und Blöcke,
0:22:43.330,0:22:47.710
welche auf dem Netzwerk erscheinen,[br]kann Malroy quasi vor Bob geheimhalten.
0:22:47.710,0:22:52.059
Und er kann Bob auch Transaktionen und[br]Blöcke präsentieren, die er dem Rest
0:22:52.059,0:22:57.920
des Netzwerkes nicht präsentiert.[br]So, das ist der Angriff. Wir sehen,
0:22:57.920,0:23:01.880
was das Netzwerk sieht.[br]Links und rechts, was Bob sieht.
0:23:01.880,0:23:06.929
Am Anfang ist das natürlich an beiden[br]Orten gleich. Jetzt geht der Malroy
0:23:06.929,0:23:12.230
zu dem Bob und wird das Auto kaufen.[br]Er macht eine Transaktion.
0:23:12.230,0:23:15.850
Er macht zwei Transaktionen. Eine,[br]um das Geld an Bob zu überweisen.
0:23:15.850,0:23:19.480
Diese schickt er nur an Bob. Und[br]versteckt sie vor dem Netzwerk.
0:23:19.480,0:23:23.960
Und eine zweite Transaktion, mit der er[br]das Geld wieder an sich selbst überweist.
0:23:23.960,0:23:28.480
Diese Transaktion veröffentlicht er im[br]Netzwerk. Jetzt wird das Netzwerk
0:23:28.480,0:23:33.950
daran arbeiten, einen Block zu erstellen,[br]mit der Transaktion von Malroy zu Malroy.
0:23:33.950,0:23:38.990
Weil das Netzwerk kennt keine andere[br]Transaktion. Und Malroy allein arbeitet
0:23:38.990,0:23:44.750
daran einen Block zu erstellen, mit[br]dem er das Geld an Bob überweist.
0:23:44.750,0:23:48.130
Natürlich wiederum, das Netzwerk hat viel[br]mehr Rechenkraft, es ist viel schneller
0:23:48.130,0:23:51.549
darin, neue Blöcke zu erstellen. So, und
0:23:51.549,0:23:56.149
schlussendlich gelingt es dann aber Bob[br][Malroy!] trotzdem, einen Block zu erstellen.
0:23:56.149,0:23:59.690
Und alle diese Blöcke die auf dem Netzwerk[br]erstellt wurden – muss man vielleicht
0:23:59.690,0:24:05.350
noch sagen – die hält der Malroy vor Bob[br]geheim. Also, alle diesen neuen Blöcke,
0:24:05.350,0:24:08.919
die hat Bob nie gesehen. Und deshalb[br]wird Bob diesen einen Block von Malroy
0:24:08.919,0:24:13.269
als die längste Kette von Blöcken[br]akzeptieren. Und jetzt ist die Transaktion
0:24:13.269,0:24:18.469
von Malroy an Bob Teil von Bobs[br]Zustand. Er gibt Malroy das Auto.
0:24:18.469,0:24:25.210
Malroy fährt davon. Er beendet die[br]Attacke. Und jetzt verbindet sich Bob
0:24:25.210,0:24:29.339
wieder ganz normal mit dem Netzwerk.[br]Die beiden Ketten werden synchronisiert.
0:24:29.339,0:24:33.410
Und wir sehen, in der schlussendlich[br]resultierenden Kette hat Bob das Geld
0:24:33.410,0:24:41.690
nicht erhalten. Malroy hat also das[br]Auto erfolgreich stehlen können.
0:24:41.690,0:24:45.690
Das ist gar nicht gut. Jetzt hat ja dieser[br]Angriff funktioniert. Oder hat er das
0:24:45.690,0:24:52.659
denn wirklich? Denn diesmal war der[br]Angriff erfolgreich. Aber Malroy musste
0:24:52.659,0:24:56.519
jetzt dafür arbeiten. Er musste diesen[br]einen Block erstellen. Und das hat ihn
0:24:56.519,0:25:00.400
viel Zeit gekostet. Natürlich kostet[br]es ihn auch irgendwie Rechenkraft,
0:25:00.400,0:25:03.440
und den Strom den er braucht um seinen[br]Computer zu betreiben. Das wollen wir
0:25:03.440,0:25:07.360
jetzt aber gar nicht mit einbeziehen.[br]Sondern wir schauen jetzt nach diesen
0:25:07.360,0:25:11.509
Dings die Zeit gekostet. Denn der Malroy[br]hat ja einen Computer, den er braucht,
0:25:11.509,0:25:15.760
um die Blöcke zu erstellen. Und dieser[br]Computer kann immer nur eines auf’s Mal
0:25:15.760,0:25:20.290
tun. Entweder erstellt er jetzt diesen[br]Fake-Block für Bob, oder er erstellt
0:25:20.290,0:25:25.789
richtige Blöcke auf die richtige Chain.[br]Er kann nicht beides auf’s Mal tun.
0:25:25.789,0:25:31.750
So, und das macht es sehr, sehr[br]teuer diesen Angriff durchzuführen.
0:25:31.750,0:25:35.759
Stellen wir uns vor… das sind jetzt einfach [br]irgendwelche Annahmewerte für unser
0:25:35.759,0:25:39.379
Netzwerk… die sind da halt in jeder[br]Kryptowährung etwas anders definiert.
0:25:39.379,0:25:44.730
Sagen wir, unser Netzwerk erzeugt einen[br]Block alle zehn Minuten. Der Block Reward,
0:25:44.730,0:25:49.700
welchen der Miner kriegt ist 1000 Euro.[br]Und Malroy hätte jetzt 20% der Rechenkraft
0:25:49.700,0:25:54.691
des Netzwerkes. Wenn wir sagen 100% der[br]Rechenkraft erzeugt alle zehn Minuten.
0:25:54.691,0:26:00.309
einen Block, dann erzeugt Malroy auf[br]sich alleine gestellt nur alle 50 Minuten
0:26:00.309,0:26:06.409
einen Block. D.h. der Angriff auf Bob[br]dauert 50 Minuten. Nun, wenn aber Malroy
0:26:06.409,0:26:12.000
50 Minuten lang minen würde, anstatt Bob[br]anzugreifen, dann würde er in dieser Zeit
0:26:12.000,0:26:16.289
durchschnittlich 1000 Euro verdienen.[br]Er kann sich jetzt also entscheiden,
0:26:16.289,0:26:22.590
entweder greift er Bob an und stiehlt das[br]23.000 Euro teure Auto, oder er verdient
0:26:22.590,0:26:26.470
mit fairem Mining 1000 Euro.[br]Natürlich wird er dieses Auto immer noch
0:26:26.470,0:26:31.810
stehlen wollen. Der Mechanismus, um[br]das zu verhindern ist aber ganz einfach.
0:26:31.810,0:26:36.419
Wir sagen jetzt, Bob gibt dem[br]Malroy das Auto nicht, sobald Bob
0:26:36.419,0:26:41.259
das Geld erhalten hat, sondern er[br]wartet dann noch einige Blöcke.
0:26:41.259,0:26:43.849
Das sieht dann in etwa so aus. Ich habe[br]jetzt nicht genügend Blöcke gemalt,
0:26:43.849,0:26:49.279
weil die da nicht Platz hatten.[br]Also sagen wir halt, wir sehen
0:26:49.279,0:26:54.510
auf der rechten Seite, wo die[br]Transaktion Teil des Zustandes wird.
0:26:54.510,0:26:59.609
Und in diesem Moment gibt halt der[br]Bob das Auto noch nicht an Malroy,
0:26:59.609,0:27:05.179
sondern erst einige Blöcke später. Und[br]für jeden zusätzlichen Block, den Malroy
0:27:05.179,0:27:08.039
erstellen muss, um Bob davon zu[br]überzeugen, dass das jetzt wirklich
0:27:08.039,0:27:12.230
die richtige Kette ist, muss Malroy[br]weitere 50 Minuten aufwenden,
0:27:12.230,0:27:17.580
und das kostet ihn jedesmal 1000 Euro.[br]Wenn also Bob sagt: „Ich warte 24 Blöcke
0:27:17.580,0:27:22.530
bevor ich dem Malroy das Auto gebe“. Dann[br]ist der Angriff für Malroy plötzlich teurer
0:27:22.530,0:27:27.360
als das Auto einen Wert hat. Und dadurch[br]kann Bob den Angriff verhindern.
0:27:27.360,0:27:31.179
Malroy kann den zwar immer noch[br]durchführen, aber es ist schlicht einfach
0:27:31.179,0:27:35.069
nicht interessant für Malroy das zu tun,[br]weil er mehr Geld macht wenn er
0:27:35.069,0:27:44.739
in der selben Zeit mint. So. Jetzt haben[br]wir viel gesprochen über generische
0:27:44.739,0:27:48.580
Konzepte von Blockchains. Jetzt will[br]ich noch etwas dazu sagen, wie das
0:27:48.580,0:27:53.820
in Bitcoin implementiert wird. Zumindest[br]einige der Dinge. Schauen wir uns zuerst
0:27:53.820,0:27:58.499
die Blöcke an. Und wir wissen ja, in der[br]Informatik mögen wir es, Bodys und Header
0:27:58.499,0:28:03.340
zu definieren. Das tun wir überall,[br]irgendwie, in unseren Netzwerkprotokollen;
0:28:03.340,0:28:07.799
in Nachrichten und Dateiformaten[br]sagen wir, der Body enthält den Inhalt,
0:28:07.799,0:28:12.049
die eigentlichen Daten. Und der Header[br]enthält die Metadaten. Und genau dasselbe
0:28:12.049,0:28:17.390
tun wir auch in unseren Blockchains. In[br]Bitcoin ist es so, der Body eines Blockes
0:28:17.390,0:28:22.500
enthält alle Transaktionen. Die sind dort[br]geordnet aufgeführt. Der Miner muss
0:28:22.500,0:28:29.130
einige Regeln einhalten, wenn er das[br]macht. Z.B. wenn Transaktion B
0:28:29.130,0:28:32.460
von Transaktion A abhängt, die beide[br]im selben Block sind, müssen die
0:28:32.460,0:28:36.190
in der richtigen Reihenfolge drin sein.[br]Aber sonst kann der die irgendwie
0:28:36.190,0:28:40.350
dort einpacken. Aber sobald er das mal[br]gemacht hat, ist dann… diese Reihenfolge
0:28:40.350,0:28:44.739
ist anschließend wichtig. Und die erste[br]Transaktion im Block ist jeweils
0:28:44.739,0:28:47.750
die coin-based-Transaktion,[br]mit der sich der Miner
0:28:47.750,0:28:53.019
den Block Reward überweist.
0:28:53.019,0:28:59.000
Um jetzt diesen Body zu verbinden mit dem[br]Header nutzt Bitcoin einen Merkle Tree.
0:28:59.000,0:29:02.249
Das ist ein binärer Baum,
0:29:02.249,0:29:08.470
bei dem jeweils… der Node ist der[br]hash der konkatenierten Werte
0:29:08.470,0:29:11.480
der Children des Nodes.
0:29:11.480,0:29:15.049
Und Bitcoin verwendet fast überall…[br]wo Bitcoin Hashes macht,
0:29:15.049,0:29:17.990
wenden sie einen – dhash nennen sie das,
0:29:17.990,0:29:22.979
das ist ein double-sha256-Hash, also[br]so nennt sich der Hash eines Hashes
0:29:22.979,0:29:27.700
eines Wertes, den sie nehmen. Das[br]sieht dann so aus: wir haben unseren Body
0:29:27.700,0:29:31.539
des Blocks. Dann erstellen wir für[br]jede Transaktion den double-hash.
0:29:31.539,0:29:34.710
Und dann beginnen wir damit, den Tree[br]zu erstellen. Also auf jeden Node,
0:29:34.710,0:29:40.629
für jeden blauen Node konkatenieren wir[br]die beiden grünen Nodes, und machen dann
0:29:40.629,0:29:44.410
den Hash davon. Das machen wir für[br]jede Ebene, bis wir schlussendlich
0:29:44.410,0:29:49.850
beim Merkle Root angelangen, und der[br]wird dann Teil des Block Headers.
0:29:49.850,0:29:53.879
Und der Block Header enthält diese Dinge:[br]die Version – das ist irgendwie
0:29:53.879,0:29:58.480
eine arbitrary Nummer, die von den[br]Entwicklern von Zeit zu Zeit geändert wird,
0:29:58.480,0:30:01.809
wenn sie irgendwie finden,[br]dass wird jetzt Zeit dafür.
0:30:01.809,0:30:05.559
Dann den Previous Block Hash. Wir haben[br]gesehen, die Blöcke verweisen jeweils
0:30:05.559,0:30:09.199
auf den vorhergehenden Block. Das ist[br]in Bitcoin so gelöst, dass der Header
0:30:09.199,0:30:13.069
eines Blocks den Hash des vorhergehenden[br]Blocks enthält. Also auch hier wieder
0:30:13.069,0:30:18.730
den double-hash. Den Merkle Root haben[br]wir bereits gesehen. Dann enthält
0:30:18.730,0:30:22.460
der Block-Header noch einen Time Stamp.[br]Das sind ziemlich komplizierte Regeln,
0:30:22.460,0:30:26.780
wonach dieser Time Stamp gebildet[br]wird, aber das ist egal. Das ist
0:30:26.780,0:30:31.850
nicht so wichtig. Die ‚Difficulty‘ ist ein[br]Ausdruck dafür wie schwierig es war
0:30:31.850,0:30:35.989
den Proof-of-Work für diesen bestimmten[br]Block zu definieren. Und die ‚Nonce‘
0:30:35.989,0:30:43.579
ist ein Wert der gebraucht wird zum Minen.
0:30:43.579,0:30:48.359
Ja und der Proof-of-Work in Bitcoin ist[br]nichts anderes als der Hash des Blocks.
0:30:48.359,0:30:53.139
Und der muss dann eine Bedingung[br]erfüllen. Und zwar muss dieser Hash
0:30:53.139,0:30:58.580
mit einer gewissen Anzahl Nullen beginnen.[br]Also ich nehme den Header des Blocks
0:30:58.580,0:31:04.359
und bilde den double-hash davon.[br]Und dann müssen die ersten paar Bits
0:31:04.359,0:31:08.559
von diesem Hash müssen Null sein. Und[br]wieviele Bits das sind, das ist dann eben
0:31:08.559,0:31:13.470
die variable Schwierigkeit. Also wenn[br]ich mehr Nullen haben muss zu Beginn
0:31:13.470,0:31:16.970
dann ist es schwieriger den Proof-of-Work[br]zu erstellen. Und bei weniger
0:31:16.970,0:31:22.229
natürlich einfacher. Das Mining[br]funktioniert dann so dass… der Miner
0:31:22.229,0:31:25.919
nimmt einfach mal diesen Header,[br]und bildet den double-hash davon.
0:31:25.919,0:31:29.919
Dann prüft er ob der jetzt diese Bedingung[br]erfüllt. Das wird er vermutlich nicht tun.
0:31:29.919,0:31:34.210
Und dann inkrementiert er halt die nonce,[br]dadurch hat sich der Header verändert,
0:31:34.210,0:31:39.109
er bildet wieder den hash davon, und prüft[br]das. Und so macht er immer weiter.
0:31:39.109,0:31:45.509
Es ist aber so, diese nonce ist lediglich[br]32 bit lang, und der Hash mit 256 bit
0:31:45.509,0:31:50.249
ist wesentlich größer. Es kann also gut[br]sein, dass einfach durch das Inkrementieren
0:31:50.249,0:31:55.130
der Nonce kein passender Proof-of-Work[br]gefunden wird. Und in dem Fall wird
0:31:55.130,0:32:00.949
der Miner die coin-based Transaktion[br]verändern. Und zwar hat diese coin-based
0:32:00.949,0:32:05.450
Transaktion hat den Transaction Input,[br]der wird bei einer normalen Transaktion
0:32:05.450,0:32:09.729
dafür gebraucht zu beschreiben, woher[br]das Geld kommt in dieser Transaktion.
0:32:09.729,0:32:14.229
Das hat die coin-based nicht, denn die[br]macht ja quasi Geld aus dem Nichts heraus,
0:32:14.229,0:32:18.179
und den Wert in diesem Fall kann[br]dann der Miner frei beeinflussen.
0:32:18.179,0:32:22.239
Dadurch ändert sich der Hash dieser[br]Transaktion, und das setzt sich dann
0:32:22.239,0:32:27.799
durch den Merkle Tree hindurch fort bis[br]es quasi auch den Merkle Root verändert.
0:32:27.799,0:32:32.679
Und dadurch ist der ganze Blockheader[br]wieder verändert und der Miner
0:32:32.679,0:32:37.799
kann weiterarbeiten. So, das lässt sich ja[br]dann auch sehr einfach prüfen, ob das jetzt
0:32:37.799,0:32:41.700
ein korrekter Proof-of-Work ist. Ich nehme[br]einfach diesen Blockheader und bilde
0:32:41.700,0:32:48.449
den Hash und schaue ob das so stimmt.
0:32:48.449,0:32:53.330
Das Bitcoin-Netzwerk versucht alle zehn[br]Minuten einen neuen Block zu erstellen.
0:32:53.330,0:32:57.519
Um diese Zeit stabil zu halten,[br]wird die Schwierigkeit im Netzwerk
0:32:57.519,0:33:02.899
alle 14 Tage, also alle 2016 Blöcke,[br]angepasst, mit einem Algorithmus
0:33:02.899,0:33:10.539
wo jeder Miner feststellen kann wie weit[br]muss ich jetzt die Schwierigkeit verändern.
0:33:10.539,0:33:14.379
Die coin-based Transaktion, mit der[br]sich der Miner Geld überweist,
0:33:14.379,0:33:18.039
enthält in Bitcoin zwei Dinge:[br]einerseits die Transaction Fees, also
0:33:18.039,0:33:24.759
die Transaktionsgebühren der Transaktion[br]in den Block; und anderseits auch noch
0:33:24.759,0:33:29.500
neue Bitcoin, die neu ins System kommen.[br]Das waren ursprünglich 50 Bitcoin pro Block,
0:33:29.500,0:33:34.619
heute sind es noch 12,5, der[br]Wert halbiert sich alle vier Jahre.
0:33:34.619,0:33:38.509
Das war das letzte Mal in diesem Sommer,[br]da hat sich der Wert halbiert. Seither
0:33:38.509,0:33:47.810
gibt es nur noch 12,5 Bitcoin[br]für einen neuen Block.
0:33:47.810,0:33:51.999
Jetzt wollen wir noch uns anschauen[br]wie wir ‚Light Clients‘ bauen können.
0:33:51.999,0:33:56.509
Bitcoin kennt eigentlich mehr oder weniger,[br]drei Arten von Clients: ein ‚Full Node‘
0:33:56.509,0:34:02.589
ist ein Client, welcher die[br]gesamte Blockchain speichert.
0:34:02.589,0:34:06.630
Der überprüft jede eingehende[br]Transaktion, jeden eingehenden Block
0:34:06.630,0:34:10.639
überprüft dieser Client, ob der auch[br]wirklich valide ist. Und er tut noch
0:34:10.639,0:34:14.119
etwas anderes, nämlich er seeded diese[br]Blöcke die er hat an das Netzwerk.
0:34:14.119,0:34:17.800
Also wenn jemand kommt und sagt:[br]„Ich hätte gern einen Block“ dann gibt
0:34:17.800,0:34:22.149
der Full Node diesen Block raus. Dann gibt[br]es ‚Pruning Clients‘. Der macht eigentlich
0:34:22.149,0:34:27.940
das genau selbe wie der Full Node.[br]Also der überprüft auch alle Transaktionen
0:34:27.940,0:34:32.520
und alle Blöcke. Aber der speichert jetzt[br]halt nicht die ganze Blockchain, sondern
0:34:32.520,0:34:35.550
wenn er findet „den Block brauche ich[br]nicht mehr“, dann löscht er den.
0:34:35.550,0:34:39.100
Und das macht dem Client Speicherplatz.[br]Der braucht aber immer noch
0:34:39.100,0:34:43.580
sehr viel Rechenkraft und sehr viel[br]Bandbreite, deutlich zuviel als dass ich
0:34:43.580,0:34:48.130
das auf meinem Smartphone laufen lassen[br]möchte. Und deshalb gibt es noch
0:34:48.130,0:34:53.520
die Light Clients oder SPV Clients.[br]Die dann auch geeignet sind,
0:34:53.520,0:34:56.980
um [sie] auf einem mobilen Gerät laufen[br]zu lassen. Und wie die funktionieren,
0:34:56.980,0:35:01.210
will ich jetzt noch besprechen.
0:35:01.210,0:35:05.590
Ein Light Client oder ein SPV Client,[br]was der tut zuerst ist, er lädt
0:35:05.590,0:35:09.020
die Header aller Blöcke herunter. Wir[br]haben ja gesehen, der Proof-of-Work
0:35:09.020,0:35:15.420
ist der Hash des Block Headers. D.h.[br]um den Proof-of-Work zu kontrollieren
0:35:15.420,0:35:18.760
brauche ich nicht den gesamten[br]Block, der Block Header genügt.
0:35:18.760,0:35:23.230
Und dasselbe gilt auch für die[br]Verknüpfung der Blöcke untereinander.
0:35:23.230,0:35:26.390
Welches der vorhergehende Block[br]ist, das steht ja auch im Header.
0:35:26.390,0:35:30.510
D.h. auch für diese Funktion brauche ich[br]nicht die ganzen Blöcke herunterzuladen.
0:35:30.510,0:35:35.450
Und so kann ich korrekt[br]die längste Kette erstellen,
0:35:35.450,0:35:40.350
innerhalb des Netzwerks, indem[br]ich nur die Header herunterlade.
0:35:40.350,0:35:45.560
Und der Gewinn dabei ist natürlich enorm.[br]Zur Zeit gibt es etwa 450.000 Blöcke.
0:35:45.560,0:35:52.350
Die brauchen mehr als 95 GB Speicherplatz.[br]Wenn man dann noch TX Index aktiviert
0:35:52.350,0:35:56.230
sind es, glaube ich, so um die[br]110 GB Speicherplatz, die es braucht.
0:35:56.230,0:36:00.450
Das ist natürlich blödsinnig viel auf einem[br]Smartphone. Aber nur die Block Headers,
0:36:00.450,0:36:03.730
alle Block Headers von diesen[br]450.000 Blöcken, die passen
0:36:03.730,0:36:10.180
in deutlich weniger als 100 MB rein. Und[br]das ist dann durchaus ein realistischer Wert,
0:36:10.180,0:36:14.940
dass ich das auf einem Smartphone habe.[br]Das zweite Konzept ist der Merkle Branch,
0:36:14.940,0:36:18.540
und das ist dann eigentlich noch fast[br]die interessantere Funktion, die uns
0:36:18.540,0:36:22.790
der Merkle Tree bildet. Und damit kann[br]jeder beweisen, dass eine Transaktion
0:36:22.790,0:36:26.770
tatsächlich Teil des Zustands ist.
0:36:26.770,0:36:30.650
Nun, die eine Möglichkeit, wie wir den[br]Merkle Tree nachbauen können,
0:36:30.650,0:36:35.210
ist natürlich, indem wir den Block[br]Body herunterladen, und dann
0:36:35.210,0:36:39.580
den ganzen Merkle Tree bauen.[br]Wenn ich jetzt aber nur beweisen will
0:36:39.580,0:36:44.200
dass eine Transaktion Teil des Blockes[br]ist, gibt es eine effizientere Möglichkeit.
0:36:44.200,0:36:47.950
Angenommen ich will jetzt beweisen,[br]dass die Transaktion (3) tatsächlich
0:36:47.950,0:36:51.920
Teil des Blocks ist. Dann brauche ich[br]nicht alle Transaktionen herunterzuladen,
0:36:51.920,0:36:57.760
sondern es reicht diese Transaktion (3)[br]herunterzuladen. – Ui, das war falsch. –
0:36:57.760,0:37:01.480
Und dann die restlichen Hashes,[br]also von jeder Ebene des Baums
0:37:01.480,0:37:04.480
lade ich einen Hash herunter.[br]Und damit kann ich jetzt
0:37:04.480,0:37:11.420
den Merkle Root Node wieder nachbilden,[br]und so feststellen, dass diese Transaktion
0:37:11.420,0:37:15.890
tatsächlich Teil des Blocks ist.[br]Das ist genau das was…
0:37:15.890,0:37:19.150
das hat jetzt natürlich auch einige[br]Vorteile. Ich brauche jetzt
0:37:19.150,0:37:23.520
weniger Elemente herunterzuladen, und[br]ich kann halt Hashes herunterladen, also
0:37:23.520,0:37:27.110
anstatt Transaktionen. Vorhin in dem[br]Beispiel hat das nicht soviel gebracht.
0:37:27.110,0:37:30.371
Aber wenn wir einen Block nehmen[br]mit 1600 Transaktionen, das ist
0:37:30.371,0:37:34.880
dieser Tage durchaus ein üblicher Block,[br]dann brauche ich jetzt zum Validieren
0:37:34.880,0:37:38.810
nicht mehr 1600 Transaktionen[br]herunterzuladen, sondern es genügt
0:37:38.810,0:37:42.400
eine Transaktion herunterzuladen und[br]dann elf Hashes, und damit kann ich
0:37:42.400,0:37:47.270
den Merkle Branch nachbauen.
0:37:47.270,0:37:52.640
Und so funktioniert ein SPV Client. SPV[br]steht für ‚simple payment verification‘.
0:37:52.640,0:37:56.660
Und das hat eigentlich… das wurde schon[br]im White Paper zu Bitcoin beschrieben,
0:37:56.660,0:38:00.890
wie das funktioniert. Alles was der[br]tun muss, um zu beweisen, dass
0:38:00.890,0:38:04.950
eine Transaktion reingekommen ist, ist,[br]er lädt zuerst alle Block Header herunter,
0:38:04.950,0:38:10.320
wie vorhin besprochen, er bildet[br]den längsten Branch daraus,
0:38:10.320,0:38:15.580
dann lädt er eine Transaktion herunter.[br]Und wenn ich jetzt wissen will…
0:38:15.580,0:38:18.331
wenn ich von jemandem Geld erhalte und[br]ich will jetzt zeigen, ich habe das Geld
0:38:18.331,0:38:22.610
tatsächlich erhalten, lade ich halt diese[br]Transaktion herunter, und dann lade ich
0:38:22.610,0:38:27.110
den passenden Merkle Branch herunter.[br]Und jetzt kann ich quasi zeigen, dass
0:38:27.110,0:38:32.160
dieser Merkle Branch tatsächlich mit der[br]längsten Kette von Blöcken verbunden ist.
0:38:32.160,0:38:36.990
Und so habe ich jetzt den Beweis dafür,[br]dass ich das Geld tatsächlich erhalten habe.
0:38:36.990,0:38:40.560
So, das ist diese Funktionsweise.[br]Jetzt haben wir noch etwas mehr Zeit,
0:38:40.560,0:38:44.290
als ich gehofft hatte. Ich werde jetzt[br]noch versuchen, die Pruning Clients
0:38:44.290,0:38:49.010
zu erklären. Das hängt dann damit zusammen[br]wie eigentlich Bitcoin-Transaktionen
0:38:49.010,0:38:53.910
funktionieren. Nun, wir sind es ja[br]gewohnt, dass wir irgendwie auf der Bank
0:38:53.910,0:38:58.440
ein Konto haben. Und das Konto[br]hat einen Besitzer. Hoffentlich mich!
0:38:58.440,0:39:02.720
Und es hat einen Geldbetrag. Und jedesmal,[br]wenn ich eine Transaktion durchführe,
0:39:02.720,0:39:06.760
verändert sich der Geldbetrag. Also ich[br]überweisen jemandem Geld, und dann
0:39:06.760,0:39:11.520
verändert sich halt der Betrag auf meinem[br]Konto. In Bitcoin funktioniert das
0:39:11.520,0:39:15.620
wesentlich anders, dort besitze ich[br]nicht ein Konto, sondern ich besitze
0:39:15.620,0:39:20.170
sogenannte ‚Unspent Transaction Outputs‘.[br]Und wir sehen jetzt hier, sagen wir Alice
0:39:20.170,0:39:23.880
hat diese fünf Unspent Transaction[br]Outputs, die haben jeweils einen Besitzer,
0:39:23.880,0:39:29.230
nämlich Alice. Und jeweils einen Betrag[br]der dort verfügbar ist. Und der Betrag
0:39:29.230,0:39:33.840
kann nicht geändert werden. Das ist fest.[br]Und nehmen wir jetzt an, Alice würde gerne
0:39:33.840,0:39:38.910
eine Transaktion machen, an Bob,[br]die würde ihm gerne 42 Bitcoin überweisen.
0:39:38.910,0:39:42.200
Dann erstellt sie eine Transaktion, und[br]sagt, das Geld dieser Transaktion,
0:39:42.200,0:39:47.270
42 Bitcoin, sollen an Bob gehen. Und jetzt[br]muss sie das Geld irgendwoher haben.
0:39:47.270,0:39:53.200
Und dann sagt sie halt, ich gebe[br]diese drei Transaction Outputs aus.
0:39:53.200,0:39:56.920
Und das Interessante an Transaction[br]Outputs… wie gesagt, den Betrag
0:39:56.920,0:40:01.760
kann man nicht verändern, sondern[br]Alice muss die alle komplett ausgeben.
0:40:01.760,0:40:05.930
Jetzt sind aber diese Transaction Outputs[br]zusammengenommen 44 Bitcoin,
0:40:05.930,0:40:10.990
und nicht 42 Bitcoins. D.h. diese[br]Transaktion gibt jetzt zuviel Geld aus,
0:40:10.990,0:40:17.330
also sie gibt mehr Transaction Outputs aus[br]als sie dann schlussendlich Geld dem Bob
0:40:17.330,0:40:21.400
überweist. Und was kann jetzt Alice[br]tun? Was sie tut, ist, sie macht
0:40:21.400,0:40:27.360
einen zweiten Output in ihrer Transaktion.[br]Und hier überweist sie jetzt Geld an Alice.
0:40:27.360,0:40:31.670
D.h. eine Transaktion in Bitcoin kann[br]beliebig viele Inputs und beliebig viele
0:40:31.670,0:40:36.740
Outputs haben. Was es hier noch zu[br]sagen gibt, ist, haben wir immer noch
0:40:36.740,0:40:41.070
einen Unterschied. Jetzt haben wir 44[br]Bitcoin, die in die Transaktion reinkommen,
0:40:41.070,0:40:45.860
und nur 43 die rausgehen. Das restliche[br]Bitcoin, das jetzt hier nicht ausgegeben wird,
0:40:45.860,0:40:50.810
das ist quasi impliziert die Transaction[br]Fee, welche der Miner erhält, der diese
0:40:50.810,0:40:56.400
Transaktion mint. So eine Transaction Fee[br]ist implementiert. Jetzt haben wir gesehen,
0:40:56.400,0:40:59.640
Alice hat durch das Erstellen dieser[br]Transaktion neue Transaction Outputs
0:40:59.640,0:41:05.760
erstellt. Nämlich einen, der jetzt Bob[br]gehört, und einen der Alice gehört.
0:41:05.760,0:41:08.980
Und jetzt können wir auch nachvollziehen,[br]diese Transaction Outputs, welche Alice
0:41:08.980,0:41:13.850
ausgegeben hat, die gehören alle irgendwie[br]zu anderen Transaktionen, welche es vorhin
0:41:13.850,0:41:19.800
gegeben hat. Nun, ein Transaction Output[br]kann einen von zwei Zuständen haben.
0:41:19.800,0:41:24.930
Er kann ausgegeben sein, oder nicht.[br]Und natürlich kann man nur die ausgeben,
0:41:24.930,0:41:29.320
die noch nicht ausgegeben sind. Und das[br]heißt, wenn ich wissen will, wieviel Geld
0:41:29.320,0:41:33.350
Alice gehört, dann suche ich mir alle[br]Transaction Outputs zusammen,
0:41:33.350,0:41:38.360
die Alice gehören, und addiere die Summe,[br]und dann weiß ich, Alice gehört „soviel“ Geld.
0:41:38.360,0:41:41.200
Das kann ich für jeden Teilnehmer[br]des Systems machen, dann weiß ich
0:41:41.200,0:41:46.900
für jeden Teilnehmer, wieviel Geld denn[br]der Person gehört. Wenn ich jetzt also
0:41:46.900,0:41:50.980
alle Transaction Outputs nehme, die[br]nicht ausgegeben sind, dann habe ich
0:41:50.980,0:41:56.530
den aktuellen Zustand des Netzwerks. Dann[br]weiß ich für jeden Teilnehmer, wieviel Geld
0:41:56.530,0:42:04.960
diese Person hat. Und genau diesen[br]Mechanismus macht sich ein Pruning Client
0:42:04.960,0:42:09.470
zunutze. Der sagt nämlich, eigentlich[br]brauche ich nicht die ganze Blockchain
0:42:09.470,0:42:12.931
zu speichern, das ist ja blöd, denn wenn[br]eine neue Transaktion reinkommt, und
0:42:12.931,0:42:17.260
ich wissen will ob die tatsächlich valide[br]ist, dann muss ich nur prüfen, ob die
0:42:17.260,0:42:22.060
einen Output ausgibt, der noch unspent[br]ist, denn wenn die Transaktion einen
0:42:22.060,0:42:25.520
Transaction Output ausgibt, der schon[br]ausgegeben ist, dann ist die natürlich
0:42:25.520,0:42:29.430
nicht valide, man kann ja nicht dasselbe[br]Geld zweimal ausgeben. Oder wenn
0:42:29.430,0:42:32.790
die Transaktion versucht, einen[br]Transaction Output auszugeben,
0:42:32.790,0:42:36.220
den es gar nicht gibt, dann ist[br]die natürlich auch nicht valide.
0:42:36.220,0:42:42.290
Was jetzt also ein Pruning Client tut –[br]und das tut übrigens auch ein Full Node:
0:42:42.290,0:42:46.270
wenn eine neue Transaktion reinkommt,[br]und da steht in der Transaktion „ich gebe
0:42:46.270,0:42:51.770
diesen Transaction Output aus“, dann[br]geht der Full Node nicht und versucht,
0:42:51.770,0:42:55.930
die 100 GB große Blockchain zu durchsuchen[br]nach diesem Transaction Output, das wäre
0:42:55.930,0:43:00.160
ja blödsinnig, sondern der legt sich halt[br]eine kleine Datenbank an, und dort
0:43:00.160,0:43:05.520
stehen alle Transaction Outputs drin.[br]Und dann sagt er sich, für jeden…
0:43:05.520,0:43:08.580
also alle Unspent Transaction Outputs[br]stehen dort drin, und dann sagt sich
0:43:08.580,0:43:12.090
der Client, für jede Transaktion,[br]die reinkommt und die valide ist,
0:43:12.090,0:43:17.540
entferne ich alle Transaction Outputs die[br]die Transaktion ausgibt aus der Datenbank,
0:43:17.540,0:43:22.870
und alle neuen Transaction Outputs füge[br]ich dort ein. Und so behält der Client
0:43:22.870,0:43:28.530
den Zustand. Und der Pruning Client sagt[br]sich dann halt: „Naja, die Blöcke, die
0:43:28.530,0:43:31.550
brauche ich jetzt ja nicht mehr, weil ich[br]habe den Zustand in der Datenbank,
0:43:31.550,0:43:35.380
der ist auch viel kleiner als all die[br]blöden Blöcke, die Blöcke werfe ich fort.“
0:43:35.380,0:43:39.260
Der muss dann noch etwas vorsichtig sein,[br]denn wenn jetzt plötzlich von weiter hinten
0:43:39.260,0:43:42.770
eine längere Kette kommt, dann muss er[br]das ja wieder nachvollziehen können,
0:43:42.770,0:43:47.520
also wird er sich noch einige Blöcke[br]zusätzlich speichern, als nur den neuesten.
0:43:47.520,0:43:54.720
Aber er kann so sehr viel Speicherplatz[br]sparen. Er muss aber… trotzdem
0:43:54.720,0:44:00.420
muss ein Pruning Client eigentlich jede[br]Transaktion, die es jemals gegeben hat,
0:44:00.420,0:44:04.490
herunterladen, und muss dann halt auch[br]die alle verifizieren. Das braucht auch
0:44:04.490,0:44:08.280
immer noch sehr viel Rechenkraft, und[br]sehr viel Bandbreite. Und deshalb sind
0:44:08.280,0:44:13.300
solche Clients nicht geeignet[br]für Mobilgeräte.
0:44:13.300,0:44:15.870
Und was man hier vielleicht noch sagen[br]kann, ich habe jetzt eigentlich irgendwie
0:44:15.870,0:44:25.300
gesagt, …
0:44:25.300,0:44:31.510
…ich habe jetzt gesagt, Alice gibt einen[br]Transaction Output aus. Das ist…
0:44:31.510,0:44:34.570
In Wirklichkeit ist es in Bitcoin[br]recht kompliziert implementiert.
0:44:34.570,0:44:38.790
Das funktioniert nämlich so, dass der[br]Transaction Output hat ein Stück Code
0:44:38.790,0:44:44.940
drin. Dafür gibt es in Bitcoin eine eigene[br]Assemblersprache, die das betreibt.
0:44:44.940,0:44:50.960
Und der Input muss jetzt ebenfalls ein[br]Stück Code enthalten. Und wenn die dann
0:44:50.960,0:44:55.670
nacheinander ausgeführt werden, muss das[br]am Schluss den Wert 'two' ergeben,
0:44:55.670,0:44:59.740
und nur in dem Fall wurde der Output[br]richtig ausgegeben. Und das ist
0:44:59.740,0:45:03.820
ein ziemlich kompliziertes System, wie das[br]wirklich funktioniert. Das ist dann halt
0:45:03.820,0:45:07.440
eine eigene Programmiersprache, die ist[br]zwar nicht Turing-vollständig, aber damit
0:45:07.440,0:45:11.940
lassen sich dann alle möglichen lustigen[br]Regeln implementieren. Die häufigste Regel
0:45:11.940,0:45:23.410
die man findet, in über 80%[br]der Fälle, sind sogenannte…
0:45:23.410,0:45:28.250
…die Regel sagt dann irgendsowas wie:[br]„Um diesen Output ausgeben zu können,
0:45:28.250,0:45:32.380
musst du beweisen, dass du den geheimen[br]Schlüssel besitzt zu dem öffentlichen
0:45:32.380,0:45:37.400
Schlüssel, dessen Hash ich jetzt hier[br]reinpacke.“ Und in dem Input steht dann
0:45:37.400,0:45:43.310
halt: „Ja, ich besitze diesen geheimen[br]Schlüssel, und ich beweise dir das,
0:45:43.310,0:45:47.680
indem ich hier den öffentlichen Schlüssel[br]reinpacke und die Transaktion mit dem
0:45:47.680,0:45:52.840
geheimen Schlüssel signiere.“ Und dann[br]kann jemand, der das verifizieren will,
0:45:52.840,0:45:56.930
kann einfach den öffentlichen Schlüssel[br]nehmen, schauen ob das dem Hash entspricht,
0:45:56.930,0:46:04.630
und dann mit dem öffentlichen Schlüssel[br]die Signatur der Transaktion verifizieren.
0:46:04.630,0:46:09.940
Das ist die mit Abstand häufigste Art,[br]wie diese Transaktionen in Wirklichkeit
0:46:09.940,0:46:14.240
funktionieren. Aber das ist halt dann sehr[br]kompliziert, und damit könnte man leicht
0:46:14.240,0:46:22.250
einen eigenen Vortrag füllen.[br]Deshalb werde ich jetzt hier aufhören.
0:46:22.250,0:46:28.900
Habe ich da diese tolle Seite gebastelt.
0:46:28.900,0:46:32.920
– Ups, das ist eigentlich zu weit –
0:46:32.920,0:46:42.750
Finde ich es, oder nicht?
0:46:42.750,0:46:45.760
Ja, ha, gefunden! Unglaublich.[br]Lachen
0:46:45.760,0:46:48.860
Also wir haben jetzt noch Zeit für Fragen,[br]wenn ihr noch was wissen wollt.
0:46:48.860,0:46:54.940
Oder ihr könnt mich auch erreichen,[br]am einfachsten hier über das DECT-Telefon
0:46:54.940,0:47:01.890
in dem Kongress, wenn ihr Fragen habt.[br]Ihr findet einen Handout der Slides
0:47:01.890,0:47:06.000
auch im Fahrplan. Und ich werde auch[br]die Folien selbst noch hochladen,
0:47:06.000,0:47:09.520
und den entsprechenden Source Code[br]zum Erzeugen der Folien werde ich auch
0:47:09.520,0:47:11.460
verlinken.
0:47:11.460,0:47:12.960
Beifall
0:47:12.960,0:47:14.550
Herald: vimja!!
0:47:14.550,0:47:24.790
andauernder Beifall
0:47:24.790,0:47:31.540
Es ist noch einiges an Zeit für Fragen;[br]also wenn ihr Fragen habt,
0:47:31.540,0:47:35.440
dann reiht euch an den Mikrofonen auf.[br]Eine Sache möchte ich sagen:
0:47:35.440,0:47:40.280
wenn ihr jetzt rausgehen wollt, verlasst[br]bitte leise den Saal, damit das
0:47:40.280,0:47:44.360
mit den Fragen einigermaßen klappt.[br]Liebe Tür-Engel, wir lassen im Moment
0:47:44.360,0:47:50.430
noch niemanden rein. Erstmal können Leute[br]nur rausgehen. Und bitte tut das leise.
0:47:50.430,0:47:55.520
Wir fangen mit dem Signal-Engel an.
0:47:55.520,0:47:58.730
Signal Angel: Eine Frage aus dem Internet[br]bezüglich dem Man-in-the-middle
0:47:58.730,0:48:02.290
double-spending-Angriff. Könnte Mallory[br]nicht diesen Angriff gleichzeitig
0:48:02.290,0:48:07.210
mit derselben Fake-Blockchain gegen zehn[br]verschiedene Autohändler machen, und
0:48:07.210,0:48:12.890
mit dem gleichen Aufwand zehn Autos klauen?[br]Damit würde es sich doch wieder lohnen,
0:48:12.890,0:48:20.050
auch wenn man mit dem Gegenwert eines[br]Autos an Rechenzeit investieren müsste.
0:48:20.050,0:48:25.590
vimja: Das ist eine gute Überlegung die[br]ich mir so noch auch gar nie gemacht habe.
0:48:25.590,0:48:30.030
Ich müsste darüber mal nachdenken. Ich[br]nehme aber grundsätzlich an, dass es
0:48:30.030,0:48:35.670
vermutlich funktionieren würde. Der[br]Aufwand wird dann aber halt sehr viel
0:48:35.670,0:48:40.970
größer, irgendwie um die Netzwerk-Nodes[br]zu kontrollieren. Grundsätzlich denke ich
0:48:40.970,0:48:44.950
aber, dass es kein… damit das System[br]wirklich sicher ist, sollte das
0:48:44.950,0:48:50.730
kein Argument sein dürfen. Also ich hätte[br]jetzt auf Anhieb gesagt, dass es vermutlich
0:48:50.730,0:48:54.790
klappen würde.
0:48:54.790,0:48:58.251
Herald: Okay, dann machen wir weiter[br]mit Mikrofon 2, hier vorne, bitte!
0:48:58.251,0:49:03.220
Frage: Ja, hallo. Du hast gesagt, mit[br]einer 50%-Attack kann man im Prinzip
0:49:03.220,0:49:07.140
die Blockchains hijacken. Wenn man[br]sich jetzt mal eine hypothetische
0:49:07.140,0:49:11.480
Regierungsorganisation mit sehr, sehr,[br]sehr viel Rechenpower überlegt,
0:49:11.480,0:49:16.220
mal so ganz in den Raum geraten, gibt’s[br]Überlegungen, wie wahrscheinlich das ist?
0:49:16.220,0:49:19.540
vimja: Nun, es ist so, mit einfach[br]herkömmlicher Rechenpower wird das
0:49:19.540,0:49:22.750
kaum möglich sein, also irgendwie[br]für diese spezielle Aufgabe,
0:49:22.750,0:49:28.400
den Double-SHA256-Hash, hat das Bitcoin-[br]Netzwerk ein Vielfaches der Rechenkraft,
0:49:28.400,0:49:32.510
die selbst die 500 schnellsten Supercomputer[br]aufbringen könnten. Es gibt aber eine
0:49:32.510,0:49:36.580
viel einfachere Möglichkeit, unser guter[br]Freund China, denn die meisten…
0:49:36.580,0:49:40.070
denn heute ist es halt so: eigentlich[br]möchte man gerne, dass die Miner
0:49:40.070,0:49:43.740
verteilt sind, und jeder ein wenig zuhause[br]minet. In Praxis ist es aber so, dass
0:49:43.740,0:49:47.770
das heute das große Geschäft ist. Und das[br]wird dann halt heute in Rechenzentren
0:49:47.770,0:49:54.280
in China betrieben. Und China hat heute[br]mehr als 50% der Rechenkraft von Bitcoin,
0:49:54.280,0:49:57.430
also, toll, unsere unabhängige Währung[br]gehört jetzt den Chinesen.
0:49:57.430,0:50:01.030
Und selbst wenn das nicht stimmen sollte,[br]und das nicht funktionieren sollte,
0:50:01.030,0:50:04.630
ist es so, dass all die spezielle[br]Hardware, die heute zum Mining
0:50:04.630,0:50:08.940
notwendig ist, in China hergestellt wird.[br]Und China könnte einfach all diese Fabriken,
0:50:08.940,0:50:12.710
in denen die hergestellt werden,[br]beschlagnahmen, und nach einigen Monaten
0:50:12.710,0:50:15.120
hätten sie trotzdem wieder mehr[br]Rechenleistung als jeder andere,
0:50:15.120,0:50:21.250
und könnte die Währung so kontrollieren.[br]Also, das ist durchaus wahrscheinlich.
0:50:21.250,0:50:24.680
Herald: Dann machen wir weiter[br]mit Mikrofon 1, hier vorne, bitte.
0:50:24.680,0:50:28.970
Frage: Ja, mir geht’s auch gerade um die[br]Rechenpower. Also gibt es da irgendwie
0:50:28.970,0:50:34.200
Ansätze in anderen elektronischen[br]Währungen, wie das verhindert werden kann,
0:50:34.200,0:50:40.380
dass immer quasi zum Stand der aktuellen[br]Technik die maximale Rechenpower nötig ist,
0:50:40.380,0:50:44.041
um so ein System laufen zu lassen?
0:50:44.041,0:50:47.400
vimja: Es hat zur Zeit, im Verlauf der[br]Zeit verschiedene Möglichkeiten,
0:50:47.400,0:50:51.700
also verschiedene Ansätze gegeben.
0:50:51.700,0:50:55.150
Das eine was man immer wieder versucht[br]hat, ist halt, dass man das nicht nur auf
0:50:55.150,0:50:59.720
Rechenkraft beschränkt, sondern dass man[br]sagt, der Angriff der braucht nicht nur
0:50:59.720,0:51:03.950
Rechenpower sondern auch viel RAM,[br]oder viel Memory. Und dadurch ist es
0:51:03.950,0:51:08.250
sehr viel schwieriger, Hardware zu bauen.[br]Oder sehr viel teurer, Hardware zu bauen,
0:51:08.250,0:51:12.240
die darauf spezialisiert ist, und man[br]erhofft sich davon Erfolge, aber
0:51:12.240,0:51:16.010
schlussendlich hat man dort wieder[br]dasselbe Problem. Ich weiß aber,
0:51:16.010,0:51:21.500
dass Ethereum arbeitet an einem Konzept,[br]das nennen sie Proof-of-Stake.
0:51:21.500,0:51:24.730
Und wie genau das funktioniert, kann ich[br]dir nicht sagen. Aber da hängt dann
0:51:24.730,0:51:29.160
die Wahrscheinlichkeit, dass du einen[br]Block erstellst, davon ab wieviel Geld
0:51:29.160,0:51:32.900
du besitzt in dem Netzwerk, oder sowas.[br]Und die brauchen dann eigentlich
0:51:32.900,0:51:35.840
kein Mining mehr. Und die haben dann halt[br]auch das Problem nicht mehr dass man
0:51:35.840,0:51:40.700
unglaublich viel Strom braucht, um das[br]Ding zu minen. Und ich dachte, die wollten
0:51:40.700,0:51:44.660
diesen Sommer umstellen. Ich habe dann[br]aber das Ganze ein wenig aus den Augen
0:51:44.660,0:51:47.560
verloren, und kann dir jetzt nicht[br]sagen wie weit die damit sind.
0:51:47.560,0:51:48.260
Also grundsätzlich…
0:51:48.260,0:51:50.100
Frage: Wie heißt das nochmal?
0:51:50.100,0:51:53.570
vimja: ‚Proof-of-Stake‘. Und das wird in[br]Ethereum implementiert. Aber wie weit
0:51:53.570,0:51:57.490
die sind, kann ich dir nicht sagen. Das[br]müsstest du selbst nachschauen gehen.
0:51:57.490,0:51:58.770
Frage: Danke.
0:51:58.770,0:52:02.440
Herald: Dann machen wir weiter mit[br]Mikrofon 4, dort drüben, bitte!
0:52:02.440,0:52:06.550
Frage: Ich stelle mal zwei Fragen. Das[br]eine ist: öffentliche Grundbuchämter
0:52:06.550,0:52:11.470
könnte man doch sehr gut in der Blockchain[br]umlegen [anlegen], und dadurch könnte
0:52:11.470,0:52:14.590
doch die Verwaltung sehr viel Geld[br]einsparen, und z.B. Handelsregister
0:52:14.590,0:52:16.730
sind ja auch öffentlich, die könnte man[br]doch auch in die Blockchain verschieben.
0:52:16.730,0:52:20.450
Oder mache ich da irgendeinen Denkfehler,[br]dass es am Schluss für die Verwaltung
0:52:20.450,0:52:22.980
teurer kommt? Und was mich auch[br]noch wundert, was deine Meinung
0:52:22.980,0:52:26.250
zu Smart Contracts ist.
0:52:26.250,0:52:30.300
vimja: Also, zu der ersten Frage, das ist[br]so, daran wird tatsächlich gearbeitet.
0:52:30.300,0:52:35.030
Insbesondere die britische Regierung hat[br]auch Forschungsgruppen, die erforschen
0:52:35.030,0:52:41.890
sollen, wie Blockchains der Verwaltung[br]helfen können. Gerade beim Grundbuchamt,
0:52:41.890,0:52:46.000
also solche Systeme brauchen starke[br]Anpassungen, gerade wenn wir uns
0:52:46.000,0:52:52.460
vorstellen, ein Grundbuchamt, wenn es dann[br]jemandem gelingen würde, irgendwie
0:52:52.460,0:52:55.690
jetzt trotzdem ein Grundstück quasi[br]zu stehlen, und das würde einfach
0:52:55.690,0:53:01.960
in dieser Blockchain drin feststehen, wie[br]würde man das wieder rückgängig machen?
0:53:01.960,0:53:06.120
Also wenn wir heute ein Grundbuchamt[br]haben, dann können die alles überschreiben.
0:53:06.120,0:53:10.230
Und irgendwie möchten wir ja dann trotzdem[br]nicht einfach nur dieser Blockchain vertrauen.
0:53:10.230,0:53:14.810
Wir möchten trotzdem die Möglichkeit[br]haben, dass gewisse Stellen, gerade eben
0:53:14.810,0:53:18.020
unser Staat, das überschreiben können.[br]Da müssen dann in diese Blockchains
0:53:18.020,0:53:22.460
zusätzliche Mechanismen eingebaut werden,[br]dass das trotzdem geht, und das ist dann
0:53:22.460,0:53:26.850
halt bedenklich, weil jetzt trotzdem da[br]jemand das Zeugs kaputtmachen kann.
0:53:26.850,0:53:30.750
Also das ist nicht ganz einfach, diese[br]Dinge zu tun. Aber ich denke schon,
0:53:30.750,0:53:38.360
dass gerade Grundbuchämter eine gute[br]Chance sind, und das ist vermutlich auch
0:53:38.360,0:53:43.760
etwas vom Ersten, was wir implementiert[br]sehen werden. Soviel für öffentliche Ämter.
0:53:43.760,0:53:48.000
Aber ich denke auch, dass es einen[br]Hybridbetrieb geben wird. Also
0:53:48.000,0:53:51.580
dass man quasi sagt, das ist zwar[br]öffentlich in einer Blockchain, aber
0:53:51.580,0:53:56.360
schlussendlich, was wirklich gilt ist[br]immer noch das, was im Grundbuchamt steht,
0:53:56.360,0:53:59.480
und das wird dann halt solange so[br]weiterbetrieben, bis sich das wirklich
0:53:59.480,0:54:03.220
bewährt hat, und man den Übergang macht.[br]Und die zweite Frage, sorry, habe ich
0:54:03.220,0:54:07.190
wieder vergessen.
0:54:07.190,0:54:10.500
Herald: Okay, wenn das die Frage[br]beantwortet und er nicht wieder aufsteht,
0:54:10.500,0:54:14.760
dann würde ich jetzt mit Mikrofon 7[br]weitermachen, dort oben, bitte.
0:54:14.760,0:54:20.140
Frage: Ja, vielen Dank für den spannenden[br]Vortrag. Mich würde noch interessieren,
0:54:20.140,0:54:24.970
vielleicht noch was zu dem Thema ‚Ende[br]der Bitcoins‘, die sind ja anscheinend
0:54:24.970,0:54:29.220
begrenzt, soweit ich das verstanden habe.[br]Und wie wird das Erstellen von neuen
0:54:29.220,0:54:33.880
Blöcken letztendlich in ferner Zukunft[br]dann belohnt, werden die einfach immer so
0:54:33.880,0:54:36.690
weiter unterteilt, und man bekommt dann[br]nur noch Bruchteile von Bitcoins
0:54:36.690,0:54:38.280
als Belohnung, oder wie funktioniert das?
0:54:38.280,0:54:41.520
vimja: Das ist eine sehr gute Frage,[br]die sich natürlich auch diesen Sommer
0:54:41.520,0:54:45.470
gestellt hat, weil sich ja der[br]Block Reward halbiert hat.
0:54:45.470,0:54:49.150
Und erstaunlicherweise ist es dann aber[br]eigentlich ohne Weiteres weitergegangen.
0:54:49.150,0:54:53.210
Nun ist es so, der Mechanismus,[br]der eigentlich greifen sollte, ist
0:54:53.210,0:54:57.880
die Transaction Fees. Dass es durch[br]die Transaction Fees getragen wird,
0:54:57.880,0:55:02.550
diese Gebühr. Nur ist es heute so, dass[br]die Transaction Fees so niedrig sind,
0:55:02.550,0:55:07.410
dass das Minen sich nicht rentieren würde,[br]also der Stromverbrauch ist viel zu hoch,
0:55:07.410,0:55:13.720
als dass es sich lohnen würde, nur[br]für die Transaction Fees zu minen.
0:55:13.720,0:55:17.230
Andererseits ist es aber so, dass die[br]Transaction Fees heute schon sehr hoch
0:55:17.230,0:55:21.090
sind, also die kommen heute irgendwo[br]zwischendurch schon in die Bereiche
0:55:21.090,0:55:24.740
der Transaction Fees, die man auch[br]zahlt bei Kreditkartenüberweisungen.
0:55:24.740,0:55:28.580
Und das ist natürlich absolut lächerlich[br]hoch. Und dann ist es aber auch so,
0:55:28.580,0:55:32.970
dass die Blöcke voll sind, d.h. wenn das[br]Block Limit – das ist ein künstliches
0:55:32.970,0:55:37.260
Limit, wie groß die Blöcke sein dürfen,[br]und die Community führt da großen Krieg
0:55:37.260,0:55:41.690
darüber ob man das jetzt ändern soll oder[br]nicht – aber wenn dieses Limit halt nicht
0:55:41.690,0:55:44.770
erhöht wird, dann passen nicht mehr[br]Transaktionen rein, und dann ist
0:55:44.770,0:55:48.770
der einzige Weg höhere Transaction…[br]also mehr Transaction Fees zu haben
0:55:48.770,0:55:51.620
für den Miner, ist diese Transaction Fees[br]zu erhöhen. Und wenn man die weiter
0:55:51.620,0:55:55.920
erhöht, dann lohnt es sich einfach[br]nicht mehr, Bitcoin zu verwenden.
0:55:55.920,0:55:58.531
Im Moment ist es noch nicht so ein[br]Problem, für die nächsten vier Jahre
0:55:58.531,0:56:02.640
sind es ja noch 12,5 Bitcoin die[br]man kriegt. Aber wie es danach
0:56:02.640,0:56:07.200
weitergehen wird, das muss man abwarten,[br]und dann schauen, was da genau passiert.
0:56:07.200,0:56:10.750
Und ich denke dass das ist auch noch ein[br]dynamisches System, das sich schnell
0:56:10.750,0:56:14.960
wandelt, und da werden auch noch[br]viele Leute viele gute Ideen haben.
0:56:14.960,0:56:17.770
Frage: Darf ich noch mal kurz was[br]nachfragen? D.h. der Proof-of-Work
0:56:17.770,0:56:22.980
ist nicht der direkte Bitcoin, den ich[br]bekomme, also nicht die 12,5 Bitcoins,
0:56:22.980,0:56:28.230
die ich bekomme, um einen Block zu[br]erstellen, ist nicht der Proof-of-Work?
0:56:28.230,0:56:31.930
vimja: Nein nein, das ist… die 12,5 Bitcoin[br]die du kriegst, also die 12,5 Bitcoin
0:56:31.930,0:56:34.940
plus das klein weniger, was von den[br]Transaction Fees kommt, das ist
0:56:34.940,0:56:39.430
der Block Reward. Nennt sich das. Und der[br]Proof-of-Work ist einfach der Beweis dafür,
0:56:39.430,0:56:44.790
dass du die Arbeit auf dich genommen[br]hast, einen Block zu erstellen.
0:56:44.790,0:56:49.500
Herald: Gut, dann machen wir oben[br]auf dem Balkon weiter mit der 8. Bitte.
0:56:49.500,0:56:52.600
Frage: Ja, das ganze Erstellen von[br]den Blöcken basiert ja darauf, dass
0:56:52.600,0:56:56.680
Transaktionen in des System reinkommen.[br]Die Frage wäre jetzt, was passiert, wenn
0:56:56.680,0:57:01.880
keine Transaktionen zur Verfügung stehen.[br]Werden dann Dummy-Transaktionen erzeugt,
0:57:01.880,0:57:03.880
oder leere Blöcke, oder was passiert dann?
0:57:03.880,0:57:08.220
vimja: Nein, das kannst du sehen, wenn du[br]ganz zurückgehst, die ersten Blöcke, die
0:57:08.220,0:57:11.690
überhaupt erstellt wurden, dort gab es ja[br]noch keine Transaktionen. Was hätte auch
0:57:11.690,0:57:16.550
überwiesen werden sollen wenn niemand Geld[br]hat. Und da war es dann halt so, dass
0:57:16.550,0:57:21.180
der Block enthält dann nur die Coin-based-[br]Transaktion. Der Miner wird ja immer
0:57:21.180,0:57:25.000
eine Coin-based-Transaktion machen.[br]Einfach, weil es für ihn interessant ist.
0:57:25.000,0:57:33.150
Und dann erstellt er halt einen Block, der[br]nur diese Coin-based-Transaktion enthält.
0:57:33.150,0:57:35.940
Herald: Dann machen wir weiter[br]hier vorne mit der 2. Bitte.
0:57:35.940,0:57:38.300
Mikro 2 will Mikro 4 Vorrang geben[br]Bitte?
0:57:38.300,0:57:41.720
Wenn du nicht möchtest, dann machen[br]wir mit der 4 weiter! Sehr fair von dir!
0:57:41.720,0:57:48.830
Frage: Och, dankeschön. Ich habe das Thema[br]‚Blockchain‘ in verschiedenen Kontexten
0:57:48.830,0:57:51.480
jetzt im letzten Jahr sehr viel gesehen.[br]Es ist fast ein Buzzword in sehr sehr
0:57:51.480,0:57:55.900
vielen Branchen, von FinTech bis zu[br]IoT oder wo auch immer. Konntest du
0:57:55.900,0:57:59.920
im Kontext deiner Arbeit ein bisschen[br]so einen Trend raussehen, wo sich da
0:57:59.920,0:58:04.100
erste Anwendungen[br]wirklich bewähren können?
0:58:04.100,0:58:08.420
vimja: Erste Anwendungen gibt es ja bereits.[br]Du kannst mit Bitcoin Dinge bezahlen.
0:58:08.420,0:58:13.930
Aber das ist so ein wenig eine Sache.[br]Eines, was ich gesehen habe, wo ich mich
0:58:13.930,0:58:17.800
aber schlicht weigere mich zu beteiligen,[br]ist halt dass Banken das zu verwenden
0:58:17.800,0:58:22.890
versuchen, um die Transaktionen zwischen[br]den Banken zu regeln. Da wird es ja,
0:58:22.890,0:58:26.410
glaube ich, im Anschluss im Saal G[br]einen Talk geben dazu, wie das heute
0:58:26.410,0:58:30.980
gemacht wird, wie Banken zwischeneinander[br]Geld austauschen. Und das möchte man
0:58:30.980,0:58:34.220
in Zukunft mit Bitcoin [eher: Blockchain][br]machen. Und da sind die Banken auch dran,
0:58:34.220,0:58:38.940
sehr viel Geld und sehr viel Zeit rein zu[br]investieren. Das ist halt sehr schade,
0:58:38.940,0:58:43.210
dass diese eigentlich coole Technologie[br]jetzt für sowas verwendet werden soll.
0:58:43.210,0:58:48.940
Aber ich denke das ist eine Anwendung die[br]kommt. Dann eben einfache Kryptowährungen,
0:58:48.940,0:58:53.540
wie etwa Bitcoin, um Dinge[br]zu bezahlen. Und auch…
0:58:53.540,0:58:57.590
ich denke auch mit Ethereum, eben gerade[br]diese Smart Contracts werden kommen,
0:58:57.590,0:59:01.340
dass man halt eben irgendwelche Dinge,[br]irgendwelche Third Parties, die man
0:59:01.340,0:59:05.970
verwendet für Dinge zu regeln, ersetzen[br]wir jetzt aber. Was jetzt als Erstes
0:59:05.970,0:59:09.560
quasi den Durchbruch schaffen wird und[br]als Großes eingesetzt werden wird,
0:59:09.560,0:59:11.770
kann ich dir nicht sagen.
0:59:11.770,0:59:15.630
Herald: Gut, dann, wir sind so ganz knapp[br]an der Zeit, aber du darfst deine Frage
0:59:15.630,0:59:17.050
auf jeden Fall stellen, bitte!
0:59:17.050,0:59:20.520
Frage: Ist auch nur eine ganz kurze,[br]schnelle Frage. Gibt es einen Schutz
0:59:20.520,0:59:24.460
gegen DDoS, dass ich irgendwie das[br]Netzwerk mit falschen Transaktionen
0:59:24.460,0:59:27.890
bombardiere, und dann bricht alles[br]zusammen, gibt es da irgendwie
0:59:27.890,0:59:29.120
einen Schutz dagegen?
0:59:29.120,0:59:31.930
vimja: Ja, das war ja ganz interessant.[br]Das hat es glaube ich vor über einem Jahr
0:59:31.930,0:59:35.050
gegeben, bei Bitcoin, dass das passiert[br]ist, und die waren sich dann
0:59:35.050,0:59:38.630
nicht so ganz einig in der Community,[br]weil die mögen sich sowieso nicht mehr,
0:59:38.630,0:59:42.270
und ‚kriegen‘ nur miteinander, die waren[br]sich da nicht so ganz einig, ob das jetzt
0:59:42.270,0:59:46.391
ein Test war, oder ob das ein DDoS war.[br]Und das Interessante daran ist ja,
0:59:46.391,0:59:51.630
dass es ja tatsächlich Geld kostet, eine[br]Transaktion zu machen. Also du zahlst
0:59:51.630,0:59:55.790
zuerst eine Transaction-Gebühr, und der[br]Schutz sollte eigentlich, hoffentlich,
0:59:55.790,0:59:59.520
sein, dass das da zu teuer ist.[br]Aber offenbar gibt es immer noch
0:59:59.520,1:00:04.340
so viele Bitcoin-Millionäre, die einfach[br]Bitcoins haben zum Davonschmeißen,
1:00:04.340,1:00:08.200
und die dann sowas tun können. Es[br]wird auf jeden Fall an irgendwelchen
1:00:08.200,1:00:11.770
Schutzmechanismen gearbeitet, aber[br]was das ist… zuckt mit den Schultern
1:00:11.770,1:00:15.530
Also was es gibt, in Bitcoin,[br]ist dieses Replace-by-Fee,
1:00:15.530,1:00:22.890
damit die Transaction-Gebühr nach[br]der Veröffentlichung der Transaktion
1:00:22.890,1:00:25.920
anschließend noch erhöht werden[br]kann. Und damit kannst du halt…
1:00:25.920,1:00:29.030
wenn du jetzt siehst, es kommen sehr viele[br]DDoS-Transaktionen rein, kannst du halt
1:00:29.030,1:00:33.640
im Nachhinein die Transaction-Gebühr[br]erhöhen, und das dadurch den Minern
1:00:33.640,1:00:38.480
quasi schmackhaft machen, deine[br]valide Transaktion zu includen.
1:00:38.480,1:00:43.600
Dieses Replace-by-Fee, dieses RBF,[br]ist aber sehr stark umstritten, und
1:00:43.600,1:00:49.580
wird auch standardmäßig nicht[br]aktiviert von der Client-Software.
1:00:49.580,1:00:56.290
Herald: Gut, dann danke vimja, für diese[br]großartige Einführung in die Blockchain!
1:00:56.290,1:01:01.030
Beifall
1:01:01.030,1:01:05.070
Abspannmusik
1:01:05.070,1:01:24.901
Untertitel erstellt von c3subtitles.de[br]im Jahr 2017. Mach mit und hilf uns!