Einführung zu Blockchains (33c3)

https://media.ccc.de/v/33c3-7824-einfuhrung_zu_blockchains

Blockchain ist die Technologie welche moderne Kryptowährungen ermöglicht. In dem Vortrag wird die Funktionsweise von Blockchains ganz allgemein erklärt. Anhand der Bitcoin Blockchain wird ausserdem gezeigt, wie diese Funktionen in einem echten System umgesetzt werden können.

['vimja']

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