*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!*