33C3-Vorspannmusik Herald: Gut, dann machen wir weiter mit dem nächsten Vortrag. Der ist von vimja, der ist Informatikstudent aus Bern in der Schweiz, und er arbeitete bzw. er beschäftigte sich mit Bitcoin und Ethereum, und schrieb seine Bachelorarbeit über die Suche nach Informationen in der Bitcoin- Blockchain. Und da macht es total Sinn, dass der uns jetzt eine Einführung zu Blockchains präsentieren wird. Ein großer Applaus für vimja! Applaus mit Pfeifen und Jubel Das ist deine Bühne! weiterhin Applaus vimja: Toll, das ist jetzt gerade kaputtgegangen. Gelächter So ist es besser. Applaus Danke. Genau, das geht jetzt natürlich auch nicht. Mache ich es halt von Hand. Ist vermutlich, weil ihr alle das Wi-Fi braucht, geht das 2,4-GHz-Band nicht mehr. Ja das hat er euch ja alles schon gesagt, der Herald. In dieser Zeit, in der ich mich mit Blockchains befasst habe, durfte ich natürlich sehr viele sehr interessante Dinge lernen, und ich möchte jetzt heute abend einen Teil dieses Wissens an euch weitergeben. Genau. Das Ganze ist natürlich ein sehr komplexes Thema, das viele komplizierte Dinge enthält, und deshalb fangen wir jetzt mit etwas sehr einfachem an, was wir alles kennen. Und zwar herkömmliche Besitzsysteme – also Systeme, die ausdrücken wem etwas gehört. Und, eigentlich, mit der Erkenntnis, dass man all diese Besitzsysteme als Zustandsübergangssysteme darstellen kann. Das gilt sowohl für Finanzsysteme, die wir haben um Geld zu verwalten, als auch etwa für Grundstücke, also Systeme mit denen wir verwalten, wem ein Grundstück gehört. Das Mapping funktioniert dann in etwa so, dass wir sagen, der Zustand ist die Sammlung der Informationen wem was gehört. Und jedes Übertragen eines Besitzes ist eine Transition, die zu einem neuen Zustand führt. Also am Beispiel eines finanziellen Systems sagen wir, der Zustand ist die Sammlung aller Konten, die es gibt. Das drückt für jede Person aus, wieviel Geld ihr gehört. Und ein Übergang ist, wenn jemand eine Transaktion macht, also Geld überweist, von einem Konto zu einem anderen, dann führt das zu einem neuen Zustand. So, das sehen wir hier abgebildet mit Grundstücken. Wir sehen hier, der Zustand, der enthält diese Information, wem die Grundstücke gehören. Und dann verkauft der Bob sein Grundstück Nr. 42 an Alice und das führt zu einem neuen Zustand. Ich habe da den Unterschied markiert, damit der eindeutig sichtbar ist. Nun, in all diesen Systemen ist es sehr wichtig, dass sich alle Teilnehmer des Systems auf einen Zustand einigen können. Dass sie sich einig sind, wem was gehört. Denn wenn sie das nicht können, sind Angriffe auf das System möglich, insbesondere der sogenannte Double-Spend-Angriff, der in der Blockchain-Welt bekannt und gefürchtet ist. Und was bedeutet das? Das ist ganz einfach, wenn jemand etwas zweimal ausgibt. Bei Geld ist das ein wenig abstrakt (also wie gibt man zweimal dasselbe Geld aus), aber bei Grundstücken ist das ganz einfach. Stellen wir uns vor, jemand verkauft dasselbe Grundstück zweimal. Das ist natürlich kriminell und darf nicht vorkommen. Schauen wir uns jetzt mal an wie das funktioniert. Stellen wir uns vor, Malroy hat ein schönes Grundstück, das Grundstück Nr. 5. Und sowohl Alice als auch Bob möchten gerne das Grundstück kaufen. Und Malroy wird jetzt versuchen, das an beide zu verkaufen. Also trifft er sich mit Alice. Das ist also jetzt der aktuelle Zustand. Wir haben gesehen, das Grundstück Nr. 5 gehört hier dem Malroy. Der trifft sich mit Alice. Und er verkauft es an Alice. Er überweist ihr das Grundstück. Wir sehen diese Transition – überweist das Grundstück von Malroy an Alice. Und im neuen Zustand gehört es jetzt der Alice. So, der Bob, der hat davon nichts mitgekriegt. Irgendwie – Bob und Alice wissen immer noch nicht recht wie man sicher miteinander kommuniziert. Und deshalb weiß der Bob jetzt nichts davon, dass die Alice das Grundstück gekauft hat. Er denkt, das Grundstück gehört immer noch Malroy. Also trifft er sich mit Malroy. Und auch er einigt sich mit Malroy auf einen Preis. Und Malroy tut jetzt so, als würde er den Besitz des Grundstücks an Bob übertragen. Und für Bob sieht die Welt jetzt so aus, d.h. Bob ist überzeugt, das ist der korrekte Zustand des Systems. Da haben wir natürlich ein Problem, weil Bob und Alice, die sind sich jetzt gar nicht einig darüber, wem das Grundstück gehört. Ja, Malroy ist natürlich abgehauen mit dem Geld. Und das System ist kaputt, weil Bob und Alice die können nicht mehr miteinander handeln. Und auch wenn jetzt jemand anderes das Grundstück kaufen möchte: Bei wem kauft er es denn jetzt? Was ist denn rechtmäßig? Nun, in der Welt der Grundstücke gibt es dafür eine ganz einfache Lösung, nämlich das Grundbuchamt. Und das Grundbuchamt fungiert eigentlich als zentrale Referenzstelle, die den Zustand verwaltet, und alle Änderungen verwaltet. Jedesmal wenn jemand ein Grundstück verkauft, muss das über das Grundbuchamt erledigt werden. Das Grundbuchamt überprüft, dass das überhaupt zulässig ist, ob das Grundstück wirklich der Person gehört und führt das dann nach. Und so kann das Grundbuchamt diese einfachen Angriffe verhindern. Diese Lösung funktioniert auch für Finanzsysteme. Also wenn wir an Banken denken, wenn ich ein Konto habe, da ist dann halt die Bank die zentrale Autorität, welche den Zustand verwaltet. Für jede… jedesmal, wenn ich eine Transaktion mache, also Geld überweise, überprüft die Bank vorher, ob ich wirklich das nötige Geld dazu habe. Und dann wird mein Kontostand nachgeführt. Und die verwaltet so für alle Teilnehmer den Zustand. Und das funktioniert eigentlich erstaunlich gut. Nun wollen wir ein System, mit dem wir Zahlungen über das Internet abwickeln können. Und wir hätten gerne, dass das dezentral ist. Weil, wenn das nicht dezentral ist, dann kann natürlich eine zentrale Autorität das System zensieren und manipulieren. Und eine zentrale Stelle kann angegriffen werden. Ich denke, wir haben das alle in den letzten Jahren beobachten müssen, wie Paypal sehr einfach willkürlich Konten sperrt, und das System zensiert. So, und deshalb brauchen wir ein besseres System, eine bessere Lösung für das Internetzeitalter. Und diese bessere Lösung ist natürlich die ‚Blockchain‘. Die Blockchain bringt einige ganz unglaubliche Eigenschaften mit sich. Die Blockchain braucht keine zentrale Stelle um den Zustand zu verwalten. Die Teilnehmer des Systems müssen sich gegenseitig nicht vertrauen, sie müssen sich gegenseitig nicht kennen. Sie müssen nicht einmal wissen, wieviele Leute denn eigentlich da teilnehmen. Und trotzdem können die sich alle immer auf einen Zustand des Systems einigen. Ich werde das jetzt demonstrieren, die Regeln, die wir brauchen um das zu ermöglichen. Anhand einer sehr einfachen Blockchain, die in diesem ersten Kapitel auch noch keinen Proof-of-Work hat. Also diese erste Blockchain wird noch angreifbar sein. Und ich werde auch zeigen wie es geht. Und erst im nächsten Kapitel dann werde ich erklären, welche Maßnahmen wir ergreifen müssen, um Angriffe zu verhindern. Und das Ganze fängt an mit dem Netzwerk welches wir nutzen. Also wir sagen quasi, wir sind alle diese Leute, und wir würden gerne miteinander Transaktionen machen können. Und zuerst einigen wir uns alle auf einen Ursprungszustand. Damit fangen wir an. Wir sagen z.B. „am Anfang gehört allen nichts“. Das ist ein leerer Zustand. Und dann brauchen wir ein p2p-Netzwerk. Und jedesmal wenn jemand Geld überweist an jemand anderes, dann veröffentlicht er die Transaktion in diesem Netzwerk, und das Netzwerk leitet die Transaktion solange an alle Teilnehmer weiter, bis alle Teilnehmer diese Transaktion gesehen haben. Das bringt natürlich viele Probleme mit sich. Das Netzwerk ist irgendwie nicht synchronisiert, nicht alle Leute sehen die gleichen Transaktionen, die Reihenfolge der Transaktionen ist unklar. Leute werden versuchen das anzugreifen – das wird dazu führen, dass es Transaktionen gibt die nicht miteinander kompatibel sind. Und irgendwie Transaktionen, die abhängen von nicht-kompatiblen Transaktionen und dann auch wieder nicht kompatibel sind. Das ist ein riesengroßes Durcheinander da. Und deshalb brauchen wir jetzt eine Möglichkeit, wie wir uns alle auf einen Zustand, auf einen Konsens einigen können. Und – wie gesagt – das ist jetzt die ‚Blockchain‘. Und wir definieren einige Regeln, die wir anwenden um uns zu einigen. Wir sagen, wir gruppieren die Transaktionen die vorher so lose auf dem Netzwerk waren zu Blöcken. Die Blöcke hängen alle voneinander ab. Wir sagen dann auch, der aktuelle Zustand des Netzwerks ist das Ende der längsten Kette zusammenhängender Blöcke. Und die Blöcke müssen einige Kriterien erfüllen. Ich habe das da… also das ist jetzt quasi der Ur… der leere Zustand, mit dem wir beginnen. Und da kommen da Transaktionen über das Netzwerk. Und irgendwann macht jemand einen Block der diese Transaktionen zusammenfasst. Und jetzt sehen wir am Ende dieses Blocks ist der Zustand. Wenn ich diesen Zustand nachvollziehen will dann nehme ich den leeren Ursprungszustand, und dann jede Transaktion aus dem ersten Block, und dann wende ich diese Transaktionen, eine nach der anderen, auf den Zustand an, und dann erhalte ich den Endzustand. Mit der Zeit kommen neue Transaktionen rein über das Netzwerk. Und diese Transaktionen werden nicht Teil des Zustands – wir haben ja gesagt der Zustand ist das Ende der längsten Kette von Blöcken, und die sind in keinem Block. Erst wenn jemand einen Block daraus macht, werden die Teil des Zustands. Wir sehen auch, die Blöcke hängen jeweils voneinander ab, die haben so einen Pfeil, der sie miteinander verbindet, also jeder Block zeigt auf den vorhergehenden Block, und bildet so eben diese Kette von Blöcken. Nun, jetzt versucht trotzdem jemand da eine bösartige Transaktion zu machen, die mit den anderen nicht kompatibel ist. Da macht jemand einen Block daraus. Und jetzt sagen wir aber einfach, Blöcke, die Transaktionen enthalten welche sich widersprechen sind nicht valide. Der Block, den kann zwar jemand erstellen, aber wir sagen dann, das ist kein valider Block, der wird vom Netzwerk nicht akzeptiert. Und der wird auch nicht Teil des Zustands. Also wenn jemand einen Block bauen will und eine dieser Transaktionen enthält, dann muss sich derjenige der den Block erstellt entscheiden welche der Transaktionen denn jetzt enthalten sein sollen in dem Block. Und die anderen lässt er außen vor. Für welche er sich entscheidet, das ist dem Typen ganz allein überlassen. Er kann das selber entscheiden was er da reinpacken will. Dann kommen mit der Zeit neue Transaktionen rein. Und jetzt könnte es sein, dass jemand so einen Block Nummer 4 macht, welcher jetzt trotzdem wieder die böse Transaktion enthält. Und dann sagen wir aber einfach, Blöcke welche Transaktionen enthalten, welche nicht kompatibel sind mit Transaktionen in älteren Blöcken sind auch ungültig, und der Block wird auch nicht Teil des Zustands. So. Was aber gültig ist, ist jemand der einen Block Nummer 3 macht, der so aussieht. Und jetzt haben wir das Problem: Wir haben gesagt, der Zustand ist die längste Kette von Blöcken. Hier ist jetzt der Zustand nicht mehr eindeutig definiert und da muss jetzt halt jeder Teilnehmer des Netzwerkes selbst entscheiden wie er damit umgeht, was er jetzt als Zustand anerkennt. So, aber dann kommen halt neue Transaktionen wieder rein. Und irgendwann baut jemand einen Block Nummer 4, der diese Transaktion enthält. Und dadurch, dass der Block Nr. 4 auf den vorherigen Block Nr. 3 verweist, ist es jetzt klar, von welchem Block der abhängt. Und damit ist die Kette auch wieder klar, und die längste Kette wird wieder zum Zustand. So. Jetzt habe ich gesagt, diese Blockchain die ich jetzt beschrieben habe hat keinen Proof-of-Work und folglich ist sie angreifbar für ein double-spend. Sagen wir Malroy würde gerne ein Fahrrad klauen. Er geht da so in den Fahrradladen von Alice, und möchte dort gerne ein Fahrrad kaufen, das kostet jetzt 1000 Euro in dem Beispiel. Ich werde jetzt… hier habe ich die Darstellung etwas geändert, diese Vierecke mit Pfeilen dran, das sind jetzt halt einfach Blöcke. Ich werde nicht mehr jede Transaktion einzeln zeichnen. Und die sehen den Zustand, wie er da ist. Da sind all die Konten aufgeführt, unter anderem diejenigen von Alice und Malroy. So. Malroy geht also in den Laden, sucht sich das [Fahrrad] aus, geht zum Tresen und macht dort die Transaktion an Alice. Und diese Transaktion wird übers Netzwerk zu Alice weitergeleitet. Sie sieht die Transaktion, aber da sie noch nicht Teil eines Blockes ist, ist sie auch noch nicht Teil des Zustands. Irgendwann aber erstellt jemand halt einen Block der diese Transaktion enthält. Die ist jetzt Teil des Zustandes. Wir sehen im Zustand des Systems, dass Alice das Geld erhalten hat. Sie gibt das Fahrrad an Malroy, und der fährt davon. Neue Blöcke kommen dazu. Und jetzt startet Malroy den Angriff. Und was Malroy macht, er erstellt eine alternative Transaktion, die dasselbe Geld überweist, diesmal aber nicht an Alice sondern an sich selbst. Genauer: an ein zweites Konto das ebenfalls ihm gehört. Und er erstellt einen alternativen Block, der diese Transaktion enthält. Und dann erstellt er ganz viele neue Blöcke die davon abhängen. Solange, bis seine Kette von Blöcken länger ist als die anderen, also die Kette, die zur Zeit auf dem Netzwerk ist. Und dann veröffentlicht er die gesamte Kette auf dem Netzwerk. Und jetzt ist seine Kette die längste Kette. Die wird vom Netzwerk als Zustand anerkannt. Und in diesem Zustand hat er das Geld erhalten. Alice hat das Geld nicht erhalten. Und Malroy hat das Fahrrad erfolgreich gestohlen. So, das hat also funktioniert. Wir müssen das verhindern. Das Problem weshalb Malroy diesen Angriff machen konnte ist natürlich, dass er in einer sehr kurzen Folge viele Blöcke erstellen konnte. Also das Problem ist eigentlich, es ist zu einfach neue Blöcke zu erstellen. Also machen wir es halt schwieriger, neue Blöcke zu erstellen. Und dazu sagen wir, für jeden Block der erstellt wird, muss eine Aufgabe gelöst werden, eine Challenge. Und um diese Challenge zu erstellen, muss man halt Zeit, und Rechenzeit aufwenden. Die Lösung für diese Aufgabe nennen wir den Proof-of-Work. Und den Prozess um den Proof-of-Work zu erstellen nennen wir das ‚Mining‘. Und dann sagen wir, zusammen mit jedem neuen Block muss der passende Proof-of-Work veröffentlicht werden. Und nur Blöcke, welche einen passenden Proof-of-Work haben werden vom Netzwerk als Teil des Zustands anerkannt. Jetzt funktioniert das Erstellen neuer Blöcke etwas anders. Und zwar ist es jetzt so, dass ein Block nicht mehr einfach entsteht, sondern ein ‚Miner‘ muss daran arbeiten. Jeder Miner arbeitet natürlich für sich selbst daran, einen neuen Block zu erstellen. Wir sehen hier, der Block an dem der Miner arbeitet, ist hier so gestrichelt markiert. Und dann, wenn der Miner daran arbeitet, kommen neue Transaktionen rein. Und irgendwann gelingt es dem Miner den Block fertigzustellen. In dem Moment veröffentlicht er den Block zusammen mit dem Proof-of-Work im Netzwerk. Der wird vom Netzwerk anerkannt, und der Miner beginnt sofort an einem neuen Block zu arbeiten, und das geht dann halt so weiter. Nun, die Funktion die wir brauchen um das Erstellen der Blöcke schwierig zu machen muss einige Bedingungen erfüllen. Sie muss natürlich schwierig sein zu lösen. Dann muss aber… obwohl es lange gehen muss die zu erstellen, muss es sehr einfach sein, das Ergebnis zu prüfen. Also wenn ich einen Block erhalte, und den passenden Proof-of-Work, muss ich – zack! – sofort sagen können, der Proof-of-Work ist gültig oder nicht, weil ich will ja entscheiden, ob das Teil meines Zustandes sein soll oder nicht. Und dann ist es wichtig, dass die Funktion abhängt von genau dem Block, für den sie erstellt wird. Also der Proof-of-Work soll nur genau für den einen Block gültig sein. Das ist sehr wichtig, denn ansonsten könnte Malroy auf Vorrat über mehrere Wochen hinweg einfach Proof-of-Works erstellen und dann die einfach an einen Block ranflanschen, und so in kurzer Zeit trotzdem wieder eine lange Kette erstellen. Wenn aber der Proof-of-Work direkt abhängig ist vom Block für den er erstellt wird, dann muss Malroy mit dem Erstellen des Proof-of-Work so lange warten, bis der vorhergehende Block bekannt ist und damit auch ihm bekannt ist, was er jetzt in den neuen Block packt. Und dann soll es auch noch möglich sein, die Schwierigkeit der Aufgabe zu variieren. Denn damit das System als stabiles Finanzsystem funktioniert, möchte ich gerne wissen, wie lange es geht von dem Moment wo ich eine Transaktion veröffentliche bis sie Teil des Zustandes wird. Und wenn das Netzwerk sehr viel mehr Rechenkraft hat, dann geht es plötzlich schneller, neue Blöcke zu erstellen und dann will ich diese Schwierigkeit anpassen können, damit es wieder länger geht. Nun jetzt, wo das Mining nicht mehr einfach ist, und es aufwendig ist, müssen wir irgendwie einen Incentive haben, damit die Leute es auch tun – also irgendeinen Anstoß. So und wir sagen halt, der Miner, dem es gelingt einen Block zu erstellen, der bekommt eine Belohnung, den sogenannten ‚Block Reward‘, und wir implementieren das, indem wir sagen, der Miner darf für sich selbst eine zusätzliche Transaktion in den Block hineinpacken, und mit dieser Transaktion überweist er sich selbst Geld aus dem Nichts heraus. Wo das Geld herkommt: Es gibt eigentlich zwei Möglichkeiten, die populär sind. Entweder sagen wir, das sind die Überweisungsgebühren der anderen Transaktionen in dem Block. Oder dann sagen wir halt, das ist Geld, welches neu geschaffen wird. Wir haben ja vorhin gesehen, wir haben einen leeren Zustand als den Ursprungszustand definiert, und wenn wir das so tun, muss das Geld, welches die Leute ausgeben, irgendwo herkommen. Und das ist halt eine Möglichkeit, Geld in das System zu bringen, die nicht von einer zentralen Stelle kontrolliert wird, und eigentlich eine faire Möglichkeit. Etwas weiteres ist, dass… diese zusätzliche Transaktion macht den Block natürlich individuell, denn jeder Miner wird das Geld an sich selbst zu überweisen versuchen und, also, diese eine Transaktion wird für jeden Miner anders sein. Und das stellt sicher, dass die alle an einem ein wenig anderen Problem arbeiten. Wenn die alle versuchen würden, das genau selbe Problem zu lösen, auf die genau selbe Art, dann würde es immer demjenigen als erstes gelingen, der die meiste Rechenkraft hat, und das wollen wir nicht, denn dann würde ja eine Person alle Blöcke erzeugen, und wir wollen ja, dass viele Personen Blöcke erzeugen, damit das niemand zensieren kann. Dadurch, dass das Problem, an welchem sie arbeiten, für jeden Miner etwas anders ist, gelingt es halt zwischendurch auch jemandem mit weniger Rechenkraft, als erstes eine Lösung zu finden. Und in der Praxis geht das dann ganz gut, dass wir sagen können, wer 20% der Rechenkraft hat dem wird es auch in etwa einem Fünftel der Fälle gelingen als erstes einen Block zu finden. Dann muss der Miner halt noch entscheiden, an welchem Block er arbeiten will. Aber der Miner will ja… also an welchem Ende der Kette… Wir haben vorhin gesehen, es kann sein, dass diese Ketten mehrere Enden haben. Aber das ist ganz einfach, denn der Miner will ja den Reward kriegen. Der Reward ist eine Transaktion, welche nur dann Teil des Zustandes wird wenn es Teil in einem Block ist, wenn es Teil der längsten Kette ist. Und der Block ist nur dann Teil der längsten Kette wenn er an diesem Ende angesetzt wird. Also arbeiten alle Miner am Ende der längsten Kette. So, jetzt habe ich versprochen, dass wir so den Double-Spend verhindern können, von vorhin. Wollen wir mal gucken, ob das geht! Das Szenario ist wieder dasselbe. Malroy will das Fahrrad klauen, im Laden von Alice. Der Unterschied ist, dass das Netzwerk arbeiten muss um die Blöcke zu erstellen. Und dann geht es wieder so vonstatten. Malroy erstellt jetzt zwei Transaktionen. Eine, um das Geld der Alice zu überweisen. Diese Transaktion macht er öffentlich im Netzwerk, damit die von allen gesehen werden kann. Und eine Transaktion, um das Geld an sich selbst zu überweisen. Die behält er vorläufig geheim. Dann wird der vorhergehende Block fertiggestellt, und sofort fängt das Netzwerk an den nächsten Block zu erstellen. Das Netzwerk enthält in dem Block natürlich die Transaktion von Malroy an Alice, denn das ist ja die einzige Transaktion die dem Netzwerk bekannt ist. Und Malroy arbeitet jetzt ganz alleine daran, den alternativen Block zu erstellen. In dem die andere Transaktion enthalten ist. Jetzt ist es aber so: das Netzwerk hat natürlich mehr Rechenkraft als Malroy allein. Der hat halt nicht so viele Computer. Und deshalb wird das Netzwerk immer schneller sein darin, neue Blöcke zu erstellen als Malroy. Malroys Kette wird nie die längste Kette, wird nie Teil des Zustands. Und der Angriff wurde erfolgreich abgewehrt. Die einzige Art und Weise wie Malroy gewinnen könnte, also wie Malroy den Angriff trotzdem durchführen könnte, wäre, wenn er schneller Blöcke erstellen könnte als das Netzwerk. Und das wird ihm aber nur dann gelingen, wenn er mehr als 50% der Rechenkraft im Netzwerk hätte. Denn dann wäre die Wahrscheinlichkeit, dass er einen Block findet, höher als bei allen anderen Minern gemeinsam. Und dann könnte er das tun. Und deshalb spricht man bei Bitcoin und anderen Kryptowährungen von diesen 50%-Attacken. So, jetzt gibt es noch eine andere Art, einen Double-Spend auszuführen. Das ist ein etwas schwierigerer Angriff. Und er hat jetzt damit zu tun, wie das Peer-to-Peer-Netzwerk funktioniert, das wir brauchen um die Transaktionen und Blöcke zu verteilen. Jetzt ist der Angriff ein wenig schwieriger, also muss Malroy etwas wertvolleres stehlen. Er geht zu Bob. Bob verkauft Autos. Er wird versuchen ein Auto zu stehlen. Und um das zu tun, wird er versuchen die Verbindung von Bob mit dem Peer-to-Peer-Netzwerk zu kontrollieren. Wir sehen hier, Bob ist mit dem Netzwerk verbunden. Mit diesen drei Peers. Und Malroy hat zwei Möglichkeiten: entweder er kontrolliert die Internetverbindung von Bob. Oder dann kontrolliert er halt die drei Nodes, mit denen Bob verbunden ist. Wie realistisch das ist, das will ich hier nicht diskutieren. Grundsätzlich ist es ja schon vorstellbar. Und jetzt hat Malroy einige interessante Möglichkeiten. Er kann jetzt nämlich kontrollieren, welche Blöcke und Transaktionen der Bob sieht. Also Transaktionen und Blöcke, welche auf dem Netzwerk erscheinen, kann Malroy quasi vor Bob geheimhalten. Und er kann Bob auch Transaktionen und Blöcke präsentieren, die er dem Rest des Netzwerkes nicht präsentiert. So, das ist der Angriff. Wir sehen, was das Netzwerk sieht. Links und rechts, was Bob sieht. Am Anfang ist das natürlich an beiden Orten gleich. Jetzt geht der Malroy zu dem Bob und wird das Auto kaufen. Er macht eine Transaktion. Er macht zwei Transaktionen. Eine, um das Geld an Bob zu überweisen. Diese schickt er nur an Bob. Und versteckt sie vor dem Netzwerk. Und eine zweite Transaktion, mit der er das Geld wieder an sich selbst überweist. Diese Transaktion veröffentlicht er im Netzwerk. Jetzt wird das Netzwerk daran arbeiten, einen Block zu erstellen, mit der Transaktion von Malroy zu Malroy. Weil das Netzwerk kennt keine andere Transaktion. Und Malroy allein arbeitet daran einen Block zu erstellen, mit dem er das Geld an Bob überweist. Natürlich wiederum, das Netzwerk hat viel mehr Rechenkraft, es ist viel schneller darin, neue Blöcke zu erstellen. So, und schlussendlich gelingt es dann aber Bob [Malroy!] trotzdem, einen Block zu erstellen. Und alle diese Blöcke die auf dem Netzwerk erstellt wurden – muss man vielleicht noch sagen – die hält der Malroy vor Bob geheim. Also, alle diesen neuen Blöcke, die hat Bob nie gesehen. Und deshalb wird Bob diesen einen Block von Malroy als die längste Kette von Blöcken akzeptieren. Und jetzt ist die Transaktion von Malroy an Bob Teil von Bobs Zustand. Er gibt Malroy das Auto. Malroy fährt davon. Er beendet die Attacke. Und jetzt verbindet sich Bob wieder ganz normal mit dem Netzwerk. Die beiden Ketten werden synchronisiert. Und wir sehen, in der schlussendlich resultierenden Kette hat Bob das Geld nicht erhalten. Malroy hat also das Auto erfolgreich stehlen können. Das ist gar nicht gut. Jetzt hat ja dieser Angriff funktioniert. Oder hat er das denn wirklich? Denn diesmal war der Angriff erfolgreich. Aber Malroy musste jetzt dafür arbeiten. Er musste diesen einen Block erstellen. Und das hat ihn viel Zeit gekostet. Natürlich kostet es ihn auch irgendwie Rechenkraft, und den Strom den er braucht um seinen Computer zu betreiben. Das wollen wir jetzt aber gar nicht mit einbeziehen. Sondern wir schauen jetzt nach diesen Dings die Zeit gekostet. Denn der Malroy hat ja einen Computer, den er braucht, um die Blöcke zu erstellen. Und dieser Computer kann immer nur eines auf’s Mal tun. Entweder erstellt er jetzt diesen Fake-Block für Bob, oder er erstellt richtige Blöcke auf die richtige Chain. Er kann nicht beides auf’s Mal tun. So, und das macht es sehr, sehr teuer diesen Angriff durchzuführen. Stellen wir uns vor… das sind jetzt einfach irgendwelche Annahmewerte für unser Netzwerk… die sind da halt in jeder Kryptowährung etwas anders definiert. Sagen wir, unser Netzwerk erzeugt einen Block alle zehn Minuten. Der Block Reward, welchen der Miner kriegt ist 1000 Euro. Und Malroy hätte jetzt 20% der Rechenkraft des Netzwerkes. Wenn wir sagen 100% der Rechenkraft erzeugt alle zehn Minuten. einen Block, dann erzeugt Malroy auf sich alleine gestellt nur alle 50 Minuten einen Block. D.h. der Angriff auf Bob dauert 50 Minuten. Nun, wenn aber Malroy 50 Minuten lang minen würde, anstatt Bob anzugreifen, dann würde er in dieser Zeit durchschnittlich 1000 Euro verdienen. Er kann sich jetzt also entscheiden, entweder greift er Bob an und stiehlt das 23.000 Euro teure Auto, oder er verdient mit fairem Mining 1000 Euro. Natürlich wird er dieses Auto immer noch stehlen wollen. Der Mechanismus, um das zu verhindern ist aber ganz einfach. Wir sagen jetzt, Bob gibt dem Malroy das Auto nicht, sobald Bob das Geld erhalten hat, sondern er wartet dann noch einige Blöcke. Das sieht dann in etwa so aus. Ich habe jetzt nicht genügend Blöcke gemalt, weil die da nicht Platz hatten. Also sagen wir halt, wir sehen auf der rechten Seite, wo die Transaktion Teil des Zustandes wird. Und in diesem Moment gibt halt der Bob das Auto noch nicht an Malroy, sondern erst einige Blöcke später. Und für jeden zusätzlichen Block, den Malroy erstellen muss, um Bob davon zu überzeugen, dass das jetzt wirklich die richtige Kette ist, muss Malroy weitere 50 Minuten aufwenden, und das kostet ihn jedesmal 1000 Euro. Wenn also Bob sagt: „Ich warte 24 Blöcke bevor ich dem Malroy das Auto gebe“. Dann ist der Angriff für Malroy plötzlich teurer als das Auto einen Wert hat. Und dadurch kann Bob den Angriff verhindern. Malroy kann den zwar immer noch durchführen, aber es ist schlicht einfach nicht interessant für Malroy das zu tun, weil er mehr Geld macht wenn er in der selben Zeit mint. So. Jetzt haben wir viel gesprochen über generische Konzepte von Blockchains. Jetzt will ich noch etwas dazu sagen, wie das in Bitcoin implementiert wird. Zumindest einige der Dinge. Schauen wir uns zuerst die Blöcke an. Und wir wissen ja, in der Informatik mögen wir es, Bodys und Header zu definieren. Das tun wir überall, irgendwie, in unseren Netzwerkprotokollen; in Nachrichten und Dateiformaten sagen wir, der Body enthält den Inhalt, die eigentlichen Daten. Und der Header enthält die Metadaten. Und genau dasselbe tun wir auch in unseren Blockchains. In Bitcoin ist es so, der Body eines Blockes enthält alle Transaktionen. Die sind dort geordnet aufgeführt. Der Miner muss einige Regeln einhalten, wenn er das macht. Z.B. wenn Transaktion B von Transaktion A abhängt, die beide im selben Block sind, müssen die in der richtigen Reihenfolge drin sein. Aber sonst kann der die irgendwie dort einpacken. Aber sobald er das mal gemacht hat, ist dann… diese Reihenfolge ist anschließend wichtig. Und die erste Transaktion im Block ist jeweils die coin-based-Transaktion, mit der sich der Miner den Block Reward überweist. Um jetzt diesen Body zu verbinden mit dem Header nutzt Bitcoin einen Merkle Tree. Das ist ein binärer Baum, bei dem jeweils… der Node ist der hash der konkatenierten Werte der Children des Nodes. Und Bitcoin verwendet fast überall… wo Bitcoin Hashes macht, wenden sie einen – dhash nennen sie das, das ist ein double-sha256-Hash, also so nennt sich der Hash eines Hashes eines Wertes, den sie nehmen. Das sieht dann so aus: wir haben unseren Body des Blocks. Dann erstellen wir für jede Transaktion den double-hash. Und dann beginnen wir damit, den Tree zu erstellen. Also auf jeden Node, für jeden blauen Node konkatenieren wir die beiden grünen Nodes, und machen dann den Hash davon. Das machen wir für jede Ebene, bis wir schlussendlich beim Merkle Root angelangen, und der wird dann Teil des Block Headers. Und der Block Header enthält diese Dinge: die Version – das ist irgendwie eine arbitrary Nummer, die von den Entwicklern von Zeit zu Zeit geändert wird, wenn sie irgendwie finden, dass wird jetzt Zeit dafür. Dann den Previous Block Hash. Wir haben gesehen, die Blöcke verweisen jeweils auf den vorhergehenden Block. Das ist in Bitcoin so gelöst, dass der Header eines Blocks den Hash des vorhergehenden Blocks enthält. Also auch hier wieder den double-hash. Den Merkle Root haben wir bereits gesehen. Dann enthält der Block-Header noch einen Time Stamp. Das sind ziemlich komplizierte Regeln, wonach dieser Time Stamp gebildet wird, aber das ist egal. Das ist nicht so wichtig. Die ‚Difficulty‘ ist ein Ausdruck dafür wie schwierig es war den Proof-of-Work für diesen bestimmten Block zu definieren. Und die ‚Nonce‘ ist ein Wert der gebraucht wird zum Minen. Ja und der Proof-of-Work in Bitcoin ist nichts anderes als der Hash des Blocks. Und der muss dann eine Bedingung erfüllen. Und zwar muss dieser Hash mit einer gewissen Anzahl Nullen beginnen. Also ich nehme den Header des Blocks und bilde den double-hash davon. Und dann müssen die ersten paar Bits von diesem Hash müssen Null sein. Und wieviele Bits das sind, das ist dann eben die variable Schwierigkeit. Also wenn ich mehr Nullen haben muss zu Beginn dann ist es schwieriger den Proof-of-Work zu erstellen. Und bei weniger natürlich einfacher. Das Mining funktioniert dann so dass… der Miner nimmt einfach mal diesen Header, und bildet den double-hash davon. Dann prüft er ob der jetzt diese Bedingung erfüllt. Das wird er vermutlich nicht tun. Und dann inkrementiert er halt die nonce, dadurch hat sich der Header verändert, er bildet wieder den hash davon, und prüft das. Und so macht er immer weiter. Es ist aber so, diese nonce ist lediglich 32 bit lang, und der Hash mit 256 bit ist wesentlich größer. Es kann also gut sein, dass einfach durch das Inkrementieren der Nonce kein passender Proof-of-Work gefunden wird. Und in dem Fall wird der Miner die coin-based Transaktion verändern. Und zwar hat diese coin-based Transaktion hat den Transaction Input, der wird bei einer normalen Transaktion dafür gebraucht zu beschreiben, woher das Geld kommt in dieser Transaktion. Das hat die coin-based nicht, denn die macht ja quasi Geld aus dem Nichts heraus, und den Wert in diesem Fall kann dann der Miner frei beeinflussen. Dadurch ändert sich der Hash dieser Transaktion, und das setzt sich dann durch den Merkle Tree hindurch fort bis es quasi auch den Merkle Root verändert. Und dadurch ist der ganze Blockheader wieder verändert und der Miner kann weiterarbeiten. So, das lässt sich ja dann auch sehr einfach prüfen, ob das jetzt ein korrekter Proof-of-Work ist. Ich nehme einfach diesen Blockheader und bilde den Hash und schaue ob das so stimmt. Das Bitcoin-Netzwerk versucht alle zehn Minuten einen neuen Block zu erstellen. Um diese Zeit stabil zu halten, wird die Schwierigkeit im Netzwerk alle 14 Tage, also alle 2016 Blöcke, angepasst, mit einem Algorithmus wo jeder Miner feststellen kann wie weit muss ich jetzt die Schwierigkeit verändern. Die coin-based Transaktion, mit der sich der Miner Geld überweist, enthält in Bitcoin zwei Dinge: einerseits die Transaction Fees, also die Transaktionsgebühren der Transaktion in den Block; und anderseits auch noch neue Bitcoin, die neu ins System kommen. Das waren ursprünglich 50 Bitcoin pro Block, heute sind es noch 12,5, der Wert halbiert sich alle vier Jahre. Das war das letzte Mal in diesem Sommer, da hat sich der Wert halbiert. Seither gibt es nur noch 12,5 Bitcoin für einen neuen Block. Jetzt wollen wir noch uns anschauen wie wir ‚Light Clients‘ bauen können. Bitcoin kennt eigentlich mehr oder weniger, drei Arten von Clients: ein ‚Full Node‘ ist ein Client, welcher die gesamte Blockchain speichert. Der überprüft jede eingehende Transaktion, jeden eingehenden Block überprüft dieser Client, ob der auch wirklich valide ist. Und er tut noch etwas anderes, nämlich er seeded diese Blöcke die er hat an das Netzwerk. Also wenn jemand kommt und sagt: „Ich hätte gern einen Block“ dann gibt der Full Node diesen Block raus. Dann gibt es ‚Pruning Clients‘. Der macht eigentlich das genau selbe wie der Full Node. Also der überprüft auch alle Transaktionen und alle Blöcke. Aber der speichert jetzt halt nicht die ganze Blockchain, sondern wenn er findet „den Block brauche ich nicht mehr“, dann löscht er den. Und das macht dem Client Speicherplatz. Der braucht aber immer noch sehr viel Rechenkraft und sehr viel Bandbreite, deutlich zuviel als dass ich das auf meinem Smartphone laufen lassen möchte. Und deshalb gibt es noch die Light Clients oder SPV Clients. Die dann auch geeignet sind, um [sie] auf einem mobilen Gerät laufen zu lassen. Und wie die funktionieren, will ich jetzt noch besprechen. Ein Light Client oder ein SPV Client, was der tut zuerst ist, er lädt die Header aller Blöcke herunter. Wir haben ja gesehen, der Proof-of-Work ist der Hash des Block Headers. D.h. um den Proof-of-Work zu kontrollieren brauche ich nicht den gesamten Block, der Block Header genügt. Und dasselbe gilt auch für die Verknüpfung der Blöcke untereinander. Welches der vorhergehende Block ist, das steht ja auch im Header. D.h. auch für diese Funktion brauche ich nicht die ganzen Blöcke herunterzuladen. Und so kann ich korrekt die längste Kette erstellen, innerhalb des Netzwerks, indem ich nur die Header herunterlade. Und der Gewinn dabei ist natürlich enorm. Zur Zeit gibt es etwa 450.000 Blöcke. Die brauchen mehr als 95 GB Speicherplatz. Wenn man dann noch TX Index aktiviert sind es, glaube ich, so um die 110 GB Speicherplatz, die es braucht. Das ist natürlich blödsinnig viel auf einem Smartphone. Aber nur die Block Headers, alle Block Headers von diesen 450.000 Blöcken, die passen in deutlich weniger als 100 MB rein. Und das ist dann durchaus ein realistischer Wert, dass ich das auf einem Smartphone habe. Das zweite Konzept ist der Merkle Branch, und das ist dann eigentlich noch fast die interessantere Funktion, die uns der Merkle Tree bildet. Und damit kann jeder beweisen, dass eine Transaktion tatsächlich Teil des Zustands ist. Nun, die eine Möglichkeit, wie wir den Merkle Tree nachbauen können, ist natürlich, indem wir den Block Body herunterladen, und dann den ganzen Merkle Tree bauen. Wenn ich jetzt aber nur beweisen will dass eine Transaktion Teil des Blockes ist, gibt es eine effizientere Möglichkeit. Angenommen ich will jetzt beweisen, dass die Transaktion (3) tatsächlich Teil des Blocks ist. Dann brauche ich nicht alle Transaktionen herunterzuladen, sondern es reicht diese Transaktion (3) herunterzuladen. – Ui, das war falsch. – Und dann die restlichen Hashes, also von jeder Ebene des Baums lade ich einen Hash herunter. Und damit kann ich jetzt den Merkle Root Node wieder nachbilden, und so feststellen, dass diese Transaktion tatsächlich Teil des Blocks ist. Das ist genau das was… das hat jetzt natürlich auch einige Vorteile. Ich brauche jetzt weniger Elemente herunterzuladen, und ich kann halt Hashes herunterladen, also anstatt Transaktionen. Vorhin in dem Beispiel hat das nicht soviel gebracht. Aber wenn wir einen Block nehmen mit 1600 Transaktionen, das ist dieser Tage durchaus ein üblicher Block, dann brauche ich jetzt zum Validieren nicht mehr 1600 Transaktionen herunterzuladen, sondern es genügt eine Transaktion herunterzuladen und dann elf Hashes, und damit kann ich den Merkle Branch nachbauen. Und so funktioniert ein SPV Client. SPV steht für ‚simple payment verification‘. Und das hat eigentlich… das wurde schon im White Paper zu Bitcoin beschrieben, wie das funktioniert. Alles was der tun muss, um zu beweisen, dass eine Transaktion reingekommen ist, ist, er lädt zuerst alle Block Header herunter, wie vorhin besprochen, er bildet den längsten Branch daraus, dann lädt er eine Transaktion herunter. Und wenn ich jetzt wissen will… wenn ich von jemandem Geld erhalte und ich will jetzt zeigen, ich habe das Geld tatsächlich erhalten, lade ich halt diese Transaktion herunter, und dann lade ich den passenden Merkle Branch herunter. Und jetzt kann ich quasi zeigen, dass dieser Merkle Branch tatsächlich mit der längsten Kette von Blöcken verbunden ist. Und so habe ich jetzt den Beweis dafür, dass ich das Geld tatsächlich erhalten habe. So, das ist diese Funktionsweise. Jetzt haben wir noch etwas mehr Zeit, als ich gehofft hatte. Ich werde jetzt noch versuchen, die Pruning Clients zu erklären. Das hängt dann damit zusammen wie eigentlich Bitcoin-Transaktionen funktionieren. Nun, wir sind es ja gewohnt, dass wir irgendwie auf der Bank ein Konto haben. Und das Konto hat einen Besitzer. Hoffentlich mich! Und es hat einen Geldbetrag. Und jedesmal, wenn ich eine Transaktion durchführe, verändert sich der Geldbetrag. Also ich überweisen jemandem Geld, und dann verändert sich halt der Betrag auf meinem Konto. In Bitcoin funktioniert das wesentlich anders, dort besitze ich nicht ein Konto, sondern ich besitze sogenannte ‚Unspent Transaction Outputs‘. Und wir sehen jetzt hier, sagen wir Alice hat diese fünf Unspent Transaction Outputs, die haben jeweils einen Besitzer, nämlich Alice. Und jeweils einen Betrag der dort verfügbar ist. Und der Betrag kann nicht geändert werden. Das ist fest. Und nehmen wir jetzt an, Alice würde gerne eine Transaktion machen, an Bob, die würde ihm gerne 42 Bitcoin überweisen. Dann erstellt sie eine Transaktion, und sagt, das Geld dieser Transaktion, 42 Bitcoin, sollen an Bob gehen. Und jetzt muss sie das Geld irgendwoher haben. Und dann sagt sie halt, ich gebe diese drei Transaction Outputs aus. Und das Interessante an Transaction Outputs… wie gesagt, den Betrag kann man nicht verändern, sondern Alice muss die alle komplett ausgeben. Jetzt sind aber diese Transaction Outputs zusammengenommen 44 Bitcoin, und nicht 42 Bitcoins. D.h. diese Transaktion gibt jetzt zuviel Geld aus, also sie gibt mehr Transaction Outputs aus als sie dann schlussendlich Geld dem Bob überweist. Und was kann jetzt Alice tun? Was sie tut, ist, sie macht einen zweiten Output in ihrer Transaktion. Und hier überweist sie jetzt Geld an Alice. D.h. eine Transaktion in Bitcoin kann beliebig viele Inputs und beliebig viele Outputs haben. Was es hier noch zu sagen gibt, ist, haben wir immer noch einen Unterschied. Jetzt haben wir 44 Bitcoin, die in die Transaktion reinkommen, und nur 43 die rausgehen. Das restliche Bitcoin, das jetzt hier nicht ausgegeben wird, das ist quasi impliziert die Transaction Fee, welche der Miner erhält, der diese Transaktion mint. So eine Transaction Fee ist implementiert. Jetzt haben wir gesehen, Alice hat durch das Erstellen dieser Transaktion neue Transaction Outputs erstellt. Nämlich einen, der jetzt Bob gehört, und einen der Alice gehört. Und jetzt können wir auch nachvollziehen, diese Transaction Outputs, welche Alice ausgegeben hat, die gehören alle irgendwie zu anderen Transaktionen, welche es vorhin gegeben hat. Nun, ein Transaction Output kann einen von zwei Zuständen haben. Er kann ausgegeben sein, oder nicht. Und natürlich kann man nur die ausgeben, die noch nicht ausgegeben sind. Und das heißt, wenn ich wissen will, wieviel Geld Alice gehört, dann suche ich mir alle Transaction Outputs zusammen, die Alice gehören, und addiere die Summe, und dann weiß ich, Alice gehört „soviel“ Geld. Das kann ich für jeden Teilnehmer des Systems machen, dann weiß ich für jeden Teilnehmer, wieviel Geld denn der Person gehört. Wenn ich jetzt also alle Transaction Outputs nehme, die nicht ausgegeben sind, dann habe ich den aktuellen Zustand des Netzwerks. Dann weiß ich für jeden Teilnehmer, wieviel Geld diese Person hat. Und genau diesen Mechanismus macht sich ein Pruning Client zunutze. Der sagt nämlich, eigentlich brauche ich nicht die ganze Blockchain zu speichern, das ist ja blöd, denn wenn eine neue Transaktion reinkommt, und ich wissen will ob die tatsächlich valide ist, dann muss ich nur prüfen, ob die einen Output ausgibt, der noch unspent ist, denn wenn die Transaktion einen Transaction Output ausgibt, der schon ausgegeben ist, dann ist die natürlich nicht valide, man kann ja nicht dasselbe Geld zweimal ausgeben. Oder wenn die Transaktion versucht, einen Transaction Output auszugeben, den es gar nicht gibt, dann ist die natürlich auch nicht valide. Was jetzt also ein Pruning Client tut – und das tut übrigens auch ein Full Node: wenn eine neue Transaktion reinkommt, und da steht in der Transaktion „ich gebe diesen Transaction Output aus“, dann geht der Full Node nicht und versucht, die 100 GB große Blockchain zu durchsuchen nach diesem Transaction Output, das wäre ja blödsinnig, sondern der legt sich halt eine kleine Datenbank an, und dort stehen alle Transaction Outputs drin. Und dann sagt er sich, für jeden… also alle Unspent Transaction Outputs stehen dort drin, und dann sagt sich der Client, für jede Transaktion, die reinkommt und die valide ist, entferne ich alle Transaction Outputs die die Transaktion ausgibt aus der Datenbank, und alle neuen Transaction Outputs füge ich dort ein. Und so behält der Client den Zustand. Und der Pruning Client sagt sich dann halt: „Naja, die Blöcke, die brauche ich jetzt ja nicht mehr, weil ich habe den Zustand in der Datenbank, der ist auch viel kleiner als all die blöden Blöcke, die Blöcke werfe ich fort.“ Der muss dann noch etwas vorsichtig sein, denn wenn jetzt plötzlich von weiter hinten eine längere Kette kommt, dann muss er das ja wieder nachvollziehen können, also wird er sich noch einige Blöcke zusätzlich speichern, als nur den neuesten. Aber er kann so sehr viel Speicherplatz sparen. Er muss aber… trotzdem muss ein Pruning Client eigentlich jede Transaktion, die es jemals gegeben hat, herunterladen, und muss dann halt auch die alle verifizieren. Das braucht auch immer noch sehr viel Rechenkraft, und sehr viel Bandbreite. Und deshalb sind solche Clients nicht geeignet für Mobilgeräte. Und was man hier vielleicht noch sagen kann, ich habe jetzt eigentlich irgendwie gesagt, … …ich habe jetzt gesagt, Alice gibt einen Transaction Output aus. Das ist… In Wirklichkeit ist es in Bitcoin recht kompliziert implementiert. Das funktioniert nämlich so, dass der Transaction Output hat ein Stück Code drin. Dafür gibt es in Bitcoin eine eigene Assemblersprache, die das betreibt. Und der Input muss jetzt ebenfalls ein Stück Code enthalten. Und wenn die dann nacheinander ausgeführt werden, muss das am Schluss den Wert 'two' ergeben, und nur in dem Fall wurde der Output richtig ausgegeben. Und das ist ein ziemlich kompliziertes System, wie das wirklich funktioniert. Das ist dann halt eine eigene Programmiersprache, die ist zwar nicht Turing-vollständig, aber damit lassen sich dann alle möglichen lustigen Regeln implementieren. Die häufigste Regel die man findet, in über 80% der Fälle, sind sogenannte… …die Regel sagt dann irgendsowas wie: „Um diesen Output ausgeben zu können, musst du beweisen, dass du den geheimen Schlüssel besitzt zu dem öffentlichen Schlüssel, dessen Hash ich jetzt hier reinpacke.“ Und in dem Input steht dann halt: „Ja, ich besitze diesen geheimen Schlüssel, und ich beweise dir das, indem ich hier den öffentlichen Schlüssel reinpacke und die Transaktion mit dem geheimen Schlüssel signiere.“ Und dann kann jemand, der das verifizieren will, kann einfach den öffentlichen Schlüssel nehmen, schauen ob das dem Hash entspricht, und dann mit dem öffentlichen Schlüssel die Signatur der Transaktion verifizieren. Das ist die mit Abstand häufigste Art, wie diese Transaktionen in Wirklichkeit funktionieren. Aber das ist halt dann sehr kompliziert, und damit könnte man leicht einen eigenen Vortrag füllen. Deshalb werde ich jetzt hier aufhören. Habe ich da diese tolle Seite gebastelt. – Ups, das ist eigentlich zu weit – Finde ich es, oder nicht? Ja, ha, gefunden! Unglaublich. Lachen Also wir haben jetzt noch Zeit für Fragen, wenn ihr noch was wissen wollt. Oder ihr könnt mich auch erreichen, am einfachsten hier über das DECT-Telefon in dem Kongress, wenn ihr Fragen habt. Ihr findet einen Handout der Slides auch im Fahrplan. Und ich werde auch die Folien selbst noch hochladen, und den entsprechenden Source Code zum Erzeugen der Folien werde ich auch verlinken. Beifall Herald: vimja!! andauernder Beifall Es ist noch einiges an Zeit für Fragen; also wenn ihr Fragen habt, dann reiht euch an den Mikrofonen auf. Eine Sache möchte ich sagen: wenn ihr jetzt rausgehen wollt, verlasst bitte leise den Saal, damit das mit den Fragen einigermaßen klappt. Liebe Tür-Engel, wir lassen im Moment noch niemanden rein. Erstmal können Leute nur rausgehen. Und bitte tut das leise. Wir fangen mit dem Signal-Engel an. Signal Angel: Eine Frage aus dem Internet bezüglich dem Man-in-the-middle double-spending-Angriff. Könnte Mallory nicht diesen Angriff gleichzeitig mit derselben Fake-Blockchain gegen zehn verschiedene Autohändler machen, und mit dem gleichen Aufwand zehn Autos klauen? Damit würde es sich doch wieder lohnen, auch wenn man mit dem Gegenwert eines Autos an Rechenzeit investieren müsste. vimja: Das ist eine gute Überlegung die ich mir so noch auch gar nie gemacht habe. Ich müsste darüber mal nachdenken. Ich nehme aber grundsätzlich an, dass es vermutlich funktionieren würde. Der Aufwand wird dann aber halt sehr viel größer, irgendwie um die Netzwerk-Nodes zu kontrollieren. Grundsätzlich denke ich aber, dass es kein… damit das System wirklich sicher ist, sollte das kein Argument sein dürfen. Also ich hätte jetzt auf Anhieb gesagt, dass es vermutlich klappen würde. Herald: Okay, dann machen wir weiter mit Mikrofon 2, hier vorne, bitte! Frage: Ja, hallo. Du hast gesagt, mit einer 50%-Attack kann man im Prinzip die Blockchains hijacken. Wenn man sich jetzt mal eine hypothetische Regierungsorganisation mit sehr, sehr, sehr viel Rechenpower überlegt, mal so ganz in den Raum geraten, gibt’s Überlegungen, wie wahrscheinlich das ist? vimja: Nun, es ist so, mit einfach herkömmlicher Rechenpower wird das kaum möglich sein, also irgendwie für diese spezielle Aufgabe, den Double-SHA256-Hash, hat das Bitcoin- Netzwerk ein Vielfaches der Rechenkraft, die selbst die 500 schnellsten Supercomputer aufbringen könnten. Es gibt aber eine viel einfachere Möglichkeit, unser guter Freund China, denn die meisten… denn heute ist es halt so: eigentlich möchte man gerne, dass die Miner verteilt sind, und jeder ein wenig zuhause minet. In Praxis ist es aber so, dass das heute das große Geschäft ist. Und das wird dann halt heute in Rechenzentren in China betrieben. Und China hat heute mehr als 50% der Rechenkraft von Bitcoin, also, toll, unsere unabhängige Währung gehört jetzt den Chinesen. Und selbst wenn das nicht stimmen sollte, und das nicht funktionieren sollte, ist es so, dass all die spezielle Hardware, die heute zum Mining notwendig ist, in China hergestellt wird. Und China könnte einfach all diese Fabriken, in denen die hergestellt werden, beschlagnahmen, und nach einigen Monaten hätten sie trotzdem wieder mehr Rechenleistung als jeder andere, und könnte die Währung so kontrollieren. Also, das ist durchaus wahrscheinlich. Herald: Dann machen wir weiter mit Mikrofon 1, hier vorne, bitte. Frage: Ja, mir geht’s auch gerade um die Rechenpower. Also gibt es da irgendwie Ansätze in anderen elektronischen Währungen, wie das verhindert werden kann, dass immer quasi zum Stand der aktuellen Technik die maximale Rechenpower nötig ist, um so ein System laufen zu lassen? vimja: Es hat zur Zeit, im Verlauf der Zeit verschiedene Möglichkeiten, also verschiedene Ansätze gegeben. Das eine was man immer wieder versucht hat, ist halt, dass man das nicht nur auf Rechenkraft beschränkt, sondern dass man sagt, der Angriff der braucht nicht nur Rechenpower sondern auch viel RAM, oder viel Memory. Und dadurch ist es sehr viel schwieriger, Hardware zu bauen. Oder sehr viel teurer, Hardware zu bauen, die darauf spezialisiert ist, und man erhofft sich davon Erfolge, aber schlussendlich hat man dort wieder dasselbe Problem. Ich weiß aber, dass Ethereum arbeitet an einem Konzept, das nennen sie Proof-of-Stake. Und wie genau das funktioniert, kann ich dir nicht sagen. Aber da hängt dann die Wahrscheinlichkeit, dass du einen Block erstellst, davon ab wieviel Geld du besitzt in dem Netzwerk, oder sowas. Und die brauchen dann eigentlich kein Mining mehr. Und die haben dann halt auch das Problem nicht mehr dass man unglaublich viel Strom braucht, um das Ding zu minen. Und ich dachte, die wollten diesen Sommer umstellen. Ich habe dann aber das Ganze ein wenig aus den Augen verloren, und kann dir jetzt nicht sagen wie weit die damit sind. Also grundsätzlich… Frage: Wie heißt das nochmal? vimja: ‚Proof-of-Stake‘. Und das wird in Ethereum implementiert. Aber wie weit die sind, kann ich dir nicht sagen. Das müsstest du selbst nachschauen gehen. Frage: Danke. Herald: Dann machen wir weiter mit Mikrofon 4, dort drüben, bitte! Frage: Ich stelle mal zwei Fragen. Das eine ist: öffentliche Grundbuchämter könnte man doch sehr gut in der Blockchain umlegen [anlegen], und dadurch könnte doch die Verwaltung sehr viel Geld einsparen, und z.B. Handelsregister sind ja auch öffentlich, die könnte man doch auch in die Blockchain verschieben. Oder mache ich da irgendeinen Denkfehler, dass es am Schluss für die Verwaltung teurer kommt? Und was mich auch noch wundert, was deine Meinung zu Smart Contracts ist. vimja: Also, zu der ersten Frage, das ist so, daran wird tatsächlich gearbeitet. Insbesondere die britische Regierung hat auch Forschungsgruppen, die erforschen sollen, wie Blockchains der Verwaltung helfen können. Gerade beim Grundbuchamt, also solche Systeme brauchen starke Anpassungen, gerade wenn wir uns vorstellen, ein Grundbuchamt, wenn es dann jemandem gelingen würde, irgendwie jetzt trotzdem ein Grundstück quasi zu stehlen, und das würde einfach in dieser Blockchain drin feststehen, wie würde man das wieder rückgängig machen? Also wenn wir heute ein Grundbuchamt haben, dann können die alles überschreiben. Und irgendwie möchten wir ja dann trotzdem nicht einfach nur dieser Blockchain vertrauen. Wir möchten trotzdem die Möglichkeit haben, dass gewisse Stellen, gerade eben unser Staat, das überschreiben können. Da müssen dann in diese Blockchains zusätzliche Mechanismen eingebaut werden, dass das trotzdem geht, und das ist dann halt bedenklich, weil jetzt trotzdem da jemand das Zeugs kaputtmachen kann. Also das ist nicht ganz einfach, diese Dinge zu tun. Aber ich denke schon, dass gerade Grundbuchämter eine gute Chance sind, und das ist vermutlich auch etwas vom Ersten, was wir implementiert sehen werden. Soviel für öffentliche Ämter. Aber ich denke auch, dass es einen Hybridbetrieb geben wird. Also dass man quasi sagt, das ist zwar öffentlich in einer Blockchain, aber schlussendlich, was wirklich gilt ist immer noch das, was im Grundbuchamt steht, und das wird dann halt solange so weiterbetrieben, bis sich das wirklich bewährt hat, und man den Übergang macht. Und die zweite Frage, sorry, habe ich wieder vergessen. Herald: Okay, wenn das die Frage beantwortet und er nicht wieder aufsteht, dann würde ich jetzt mit Mikrofon 7 weitermachen, dort oben, bitte. Frage: Ja, vielen Dank für den spannenden Vortrag. Mich würde noch interessieren, vielleicht noch was zu dem Thema ‚Ende der Bitcoins‘, die sind ja anscheinend begrenzt, soweit ich das verstanden habe. Und wie wird das Erstellen von neuen Blöcken letztendlich in ferner Zukunft dann belohnt, werden die einfach immer so weiter unterteilt, und man bekommt dann nur noch Bruchteile von Bitcoins als Belohnung, oder wie funktioniert das? vimja: Das ist eine sehr gute Frage, die sich natürlich auch diesen Sommer gestellt hat, weil sich ja der Block Reward halbiert hat. Und erstaunlicherweise ist es dann aber eigentlich ohne Weiteres weitergegangen. Nun ist es so, der Mechanismus, der eigentlich greifen sollte, ist die Transaction Fees. Dass es durch die Transaction Fees getragen wird, diese Gebühr. Nur ist es heute so, dass die Transaction Fees so niedrig sind, dass das Minen sich nicht rentieren würde, also der Stromverbrauch ist viel zu hoch, als dass es sich lohnen würde, nur für die Transaction Fees zu minen. Andererseits ist es aber so, dass die Transaction Fees heute schon sehr hoch sind, also die kommen heute irgendwo zwischendurch schon in die Bereiche der Transaction Fees, die man auch zahlt bei Kreditkartenüberweisungen. Und das ist natürlich absolut lächerlich hoch. Und dann ist es aber auch so, dass die Blöcke voll sind, d.h. wenn das Block Limit – das ist ein künstliches Limit, wie groß die Blöcke sein dürfen, und die Community führt da großen Krieg darüber ob man das jetzt ändern soll oder nicht – aber wenn dieses Limit halt nicht erhöht wird, dann passen nicht mehr Transaktionen rein, und dann ist der einzige Weg höhere Transaction… also mehr Transaction Fees zu haben für den Miner, ist diese Transaction Fees zu erhöhen. Und wenn man die weiter erhöht, dann lohnt es sich einfach nicht mehr, Bitcoin zu verwenden. Im Moment ist es noch nicht so ein Problem, für die nächsten vier Jahre sind es ja noch 12,5 Bitcoin die man kriegt. Aber wie es danach weitergehen wird, das muss man abwarten, und dann schauen, was da genau passiert. Und ich denke dass das ist auch noch ein dynamisches System, das sich schnell wandelt, und da werden auch noch viele Leute viele gute Ideen haben. Frage: Darf ich noch mal kurz was nachfragen? D.h. der Proof-of-Work ist nicht der direkte Bitcoin, den ich bekomme, also nicht die 12,5 Bitcoins, die ich bekomme, um einen Block zu erstellen, ist nicht der Proof-of-Work? vimja: Nein nein, das ist… die 12,5 Bitcoin die du kriegst, also die 12,5 Bitcoin plus das klein weniger, was von den Transaction Fees kommt, das ist der Block Reward. Nennt sich das. Und der Proof-of-Work ist einfach der Beweis dafür, dass du die Arbeit auf dich genommen hast, einen Block zu erstellen. Herald: Gut, dann machen wir oben auf dem Balkon weiter mit der 8. Bitte. Frage: Ja, das ganze Erstellen von den Blöcken basiert ja darauf, dass Transaktionen in des System reinkommen. Die Frage wäre jetzt, was passiert, wenn keine Transaktionen zur Verfügung stehen. Werden dann Dummy-Transaktionen erzeugt, oder leere Blöcke, oder was passiert dann? vimja: Nein, das kannst du sehen, wenn du ganz zurückgehst, die ersten Blöcke, die überhaupt erstellt wurden, dort gab es ja noch keine Transaktionen. Was hätte auch überwiesen werden sollen wenn niemand Geld hat. Und da war es dann halt so, dass der Block enthält dann nur die Coin-based- Transaktion. Der Miner wird ja immer eine Coin-based-Transaktion machen. Einfach, weil es für ihn interessant ist. Und dann erstellt er halt einen Block, der nur diese Coin-based-Transaktion enthält. Herald: Dann machen wir weiter hier vorne mit der 2. Bitte. Mikro 2 will Mikro 4 Vorrang geben Bitte? Wenn du nicht möchtest, dann machen wir mit der 4 weiter! Sehr fair von dir! Frage: Och, dankeschön. Ich habe das Thema ‚Blockchain‘ in verschiedenen Kontexten jetzt im letzten Jahr sehr viel gesehen. Es ist fast ein Buzzword in sehr sehr vielen Branchen, von FinTech bis zu IoT oder wo auch immer. Konntest du im Kontext deiner Arbeit ein bisschen so einen Trend raussehen, wo sich da erste Anwendungen wirklich bewähren können? vimja: Erste Anwendungen gibt es ja bereits. Du kannst mit Bitcoin Dinge bezahlen. Aber das ist so ein wenig eine Sache. Eines, was ich gesehen habe, wo ich mich aber schlicht weigere mich zu beteiligen, ist halt dass Banken das zu verwenden versuchen, um die Transaktionen zwischen den Banken zu regeln. Da wird es ja, glaube ich, im Anschluss im Saal G einen Talk geben dazu, wie das heute gemacht wird, wie Banken zwischeneinander Geld austauschen. Und das möchte man in Zukunft mit Bitcoin [eher: Blockchain] machen. Und da sind die Banken auch dran, sehr viel Geld und sehr viel Zeit rein zu investieren. Das ist halt sehr schade, dass diese eigentlich coole Technologie jetzt für sowas verwendet werden soll. Aber ich denke das ist eine Anwendung die kommt. Dann eben einfache Kryptowährungen, wie etwa Bitcoin, um Dinge zu bezahlen. Und auch… ich denke auch mit Ethereum, eben gerade diese Smart Contracts werden kommen, dass man halt eben irgendwelche Dinge, irgendwelche Third Parties, die man verwendet für Dinge zu regeln, ersetzen wir jetzt aber. Was jetzt als Erstes quasi den Durchbruch schaffen wird und als Großes eingesetzt werden wird, kann ich dir nicht sagen. Herald: Gut, dann, wir sind so ganz knapp an der Zeit, aber du darfst deine Frage auf jeden Fall stellen, bitte! Frage: Ist auch nur eine ganz kurze, schnelle Frage. Gibt es einen Schutz gegen DDoS, dass ich irgendwie das Netzwerk mit falschen Transaktionen bombardiere, und dann bricht alles zusammen, gibt es da irgendwie einen Schutz dagegen? vimja: Ja, das war ja ganz interessant. Das hat es glaube ich vor über einem Jahr gegeben, bei Bitcoin, dass das passiert ist, und die waren sich dann nicht so ganz einig in der Community, weil die mögen sich sowieso nicht mehr, und ‚kriegen‘ nur miteinander, die waren sich da nicht so ganz einig, ob das jetzt ein Test war, oder ob das ein DDoS war. Und das Interessante daran ist ja, dass es ja tatsächlich Geld kostet, eine Transaktion zu machen. Also du zahlst zuerst eine Transaction-Gebühr, und der Schutz sollte eigentlich, hoffentlich, sein, dass das da zu teuer ist. Aber offenbar gibt es immer noch so viele Bitcoin-Millionäre, die einfach Bitcoins haben zum Davonschmeißen, und die dann sowas tun können. Es wird auf jeden Fall an irgendwelchen Schutzmechanismen gearbeitet, aber was das ist… zuckt mit den Schultern Also was es gibt, in Bitcoin, ist dieses Replace-by-Fee, damit die Transaction-Gebühr nach der Veröffentlichung der Transaktion anschließend noch erhöht werden kann. Und damit kannst du halt… wenn du jetzt siehst, es kommen sehr viele DDoS-Transaktionen rein, kannst du halt im Nachhinein die Transaction-Gebühr erhöhen, und das dadurch den Minern quasi schmackhaft machen, deine valide Transaktion zu includen. Dieses Replace-by-Fee, dieses RBF, ist aber sehr stark umstritten, und wird auch standardmäßig nicht aktiviert von der Client-Software. Herald: Gut, dann danke vimja, für diese großartige Einführung in die Blockchain! Beifall Abspannmusik Untertitel erstellt von c3subtitles.de im Jahr 2017. Mach mit und hilf uns!