*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
Computrr. 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… (?)(?)(?)(?)(?)(?)
(?)(?) welche 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 minet. 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 (?)(?)
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 weiterrr.
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 mehrere Ränge (?),
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,
werde 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 Tags 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 (?)(?) 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
dann „plus 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 überlecht,
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 Syschtem 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!*