Blockchain – Part 2

Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ-Podcasts. Heute sind wir in Teil 2 unserer Blockchain Serie und ich habe mir wieder den Stefan eingeladen; hallo Stefan!

Stefan Tilkov: Hallo Lucas!

Lucas Dohmen: Ich glaube, du musst dich jetzt nicht noch einmal vorstellen. Wer es vergessen hat, kann in der letzten Folge noch einmal nachhören. Wir haben in der letzten Folge ganz ausführlich über Bitcoin gesprochen, auch darüber, was die Blockchain grundlegend ist. Und in dieser Folge wollen wir jetzt ein bisschen darauf schauen, was man quasi an Stellreglern verändern kann, um daraus vielleicht ein anderes System zu bauen. Der erste Stellregler, der mir da einfällt, ist ein System, das sich Ethereum nennt. Ich habe davon gehört, dass man damit irgendwie programmieren kann. Was hat es damit auf sich?

Stefan Tilkov: Ja, das ist ein schöner Stellregler. Im Prinzip passt das mit dem Regler auch ganz gut, weil man auch Bitcoin schon programmieren kann. Das sind relativ wenige Leute, aber Bitcoin hat auch eine kleine, eingebaute Programmiersprache. Die ist sehr, sehr rudimentär, das ist eigentlich so eine Forth-ähnliche, Stack-basierte Sprache, nicht Turing-vollständig. Mit gutem Grund, weil man gesagt hat, man möchte das zwar programmierbar machen, aber bitte nicht zu viele Risiken eingehen. Denn es könnte ja möglicherweise nach hinten losgehen, wenn man Leuten erlaubt, Programme in der Blockchain auszuführen. Aber es ist auch bei Bitcoin schon so, dass man im Prinzip kleine Programme hat, mit denen man so etwas realisieren könnte wie zum Beispiel, ich kann Geld nur ausgeben, wenn mehrere Leute unterschreiben. Also vielleicht: Wir sind eine Erbengemeinschaft oder so, wir haben zusammen hunderttausend Euro geerbt, wir dürfen aber nur gemeinsam irgendwelche Verfügungen über dieses Konto machen, müssen immer beide unterschreiben. Das wäre so etwas, was man mit einem kleinen Bitcoin-Skript machen könnte. Und tatsächlich ist schon das normale, also schon das Transferieren einer Transaktion an eine Person, schon das ist eigentlich ein kleines Skript. Das ist das Standard-Skript, pay to script hash, das da immer hineingepackt wird in jeder Transaktion.

Lucas Dohmen: Bevor du dazu kommst, die Frage: Wer führt denn dieses Programm aus?

Stefan Tilkov: Sehr gute Frage. Im Prinzip führen das die Nodes aus. Und zwar die Nodes beim Mining und beim Validieren. Letztendlich müssen die dieses Stück ablaufen lassen. Dieses kleine bisschen Programmierbarkeit ist auch schon in Bitcoin drin und damit könnte man theoretisch, wie gesagt, irgendwelche abgefahrenen Anwendungen machen.

Lucas Dohmen: Das würde ja auch heißen, dass ich jetzt Code schreiben kann, den dann alle Menschen auf der Welt ausführen und das wäre ein Desaster.

Stefan Tilkov: Uns wird ganz anders. Genau, ganz genau. Deswegen hat man es bewusst so deutlich limitiert. Das sind sehr einfach Dinge, die da möglich sind. Man kann keine Endlosschleifen bauen, man kann das nicht vermurksen. Das ist ein sehr eingeschränkter Befehlssatz, den man da hat, man kann nicht beliebige Dinge machen, keine Netzwerke auf, also um Gottes Willen nichts Schlimmes, sondern einfach nur ganz, ganz rudimentäre Sachen ein ganz, ganz kleines bisschen. Aber die Idee, die hat so ein bisschen eine Wurzel, einen Samen gesät, bei dem man sagt, das könnte doch etwas Cooles sein. Und das hat sich jemand namens Vitalik Buterin, das ist ein relativ smarter Typ, so ein, ich weiß nicht, 25-jähriger Superheld, hat sich Ethereum ausgedacht. Und das ist in vielerlei Hinsicht sehr ähnlich. Also Ethereum ist auch eine öffentliche Blockchain. Da gibt auch private Varianten, aber erst einmal: Es ist eine öffentliche Blockchain, da kann auch jeder mitmachen. Es gibt auch so einen Client, mit dem man damit interagiert, es gibt auch das Proof of Work-Verfahren. Es gibt Blöcke, Transaktionen; Blöcke sind ein bisschen schneller, brauchen eine Minute oder so. Vieles ist ähnlich, aber während Bitcoin nur für Währungstransaktionen da ist, ist Ethereum programmierbar. Es ist also im Prinzip eine virtuelle Maschine, die programmierbar ist und eine Anwendung auf dieser virtuellen Maschine ist Währung. Aber ich kann theoretisch auch andere Anwendungen darauf bauen.

Lucas Dohmen: Und das heißt, ich kann damit auch Dinge kaufen? Also das ist ein Anwendungsfall davon?

Stefan Tilkov: Ja, genau. Das ist sozusagen das, was - da können wir vielleicht nachher noch erklären, warum das so wichtig ist. Eine Frage habe ich nämlich gerade schon kurz angerissen, diese Endlosschleife. Also Ethereum hat auch eine Programmiersprache, hat wirklich eine VM, mit verschiedenen Programmiersprachen, die Byte-Code für diese VM, für diese virtuelle Maschine, erzeugen können. Und diese Programme, die man darauf schreiben kann, die sind Turing-vollständig, die können alles, die können beliebige Dinge tun. Was uns wieder zu dem Problem bringt, wie vermeide ich, dass mir jemand bösartig ein Programm dahin schickt, das die Blockchain lahmlegt. Und der Trick, den sie sich dabei ausgedacht haben - den finde ich sehr raffiniert - der ist im Prinzip, wenn so ein Programm läuft, dann verbraucht das Sprit, gas heißt das dort. Und diesen Sprit, den muss ich dem Programm mitgeben. Und wenn der Sprit leer ist, dann fährt das Auto nicht mehr, das Programm läuft nicht mehr. Das heißt, wenn ich ein Programm aufrufe, sozusagen, das auf der Ethereum-Blockchain läuft, dann gebe ich einen bestimmten Betrag an gas mit, der herunter gezählt wird mit jedem CPU-Tick dieser virtuellen Maschine. Und wenn das verbraucht ist, ist es eben weg. Um das machen zu können, muss dieses gas, muss diese Währung ja schon da sein. Das heißt, auch Ethereum hat eine eingebaute Währung, die heißt ether. Aber ether ist tatsächlich nur eine Beispielwährung. Es gibt so einen Standard, ERC20, der definiert, wie eine Währung aussieht, damit sie mit einem Wallet handeln kann. Es ist übrigens sehr einfach, eine eigene Währung zu definieren. So gesehen gibt es auch unglaublich viele so und so-Coins, die alle auf Ethereum laufen, die ähnlich funktionieren und die man für ähnliche Dinge verwenden kann.

Lucas Dohmen: Wir haben die Währung, wir können da Programme ausführen und das kostet Spritgeld.

Stefan Tilkov: Genau. Im Prinzip kann das alles mögliche sein, was ich an Programmen auf der Ethereum-Blockchain ausführe. Vielleicht muss man kurz erklären, welche Rolle die spielen. Im Prinzip ist es so: Es gibt in Ethereum auch das, was wir vorher hatten. Also in Ethereum gibt es sozusagen auch Konten oder Adressen, die externen Personen gehören. So wie wir eine Bitcoin-Adresse haben können und uns dann Geld-Bitcoins zuschicken, so können wir auch eine Ethereum-Adresse haben, mit jeweils auch irgendetwas. Das gibt es da auch. Aber darüber hinaus gibt es Bitcoin-Adressen, die nicht von Personen bedient werden, sondern vom Programm bedient werden. Also ich kann im Prinzip ein Programm registrieren, das ist dann wie ein agent, wie so ein aktives Element, wie ein Objekt in dieser Blockchain. Das hat eine Adresse. Und dieses Programm agiert dann eben konform zu seinem Code, logischerweise. Was soll das auch sonst tun? Man nennt so etwas smart contract. Andreas Antonopoulos, darauf können wir auch verlinken, sagt immer, das sind eigentlich nur dumb programs. Smart contract, dumb programs, einfach ein Programm. Und wenn man sich das vom Programmiermodell anschaut, in einer der populärsten Sprachen, die heißt Solidity, das ist so ein JavaScript-Derivat, getyptes JavaScript. Damit programmiert man eigentlich sehr klassisch objektorientiert. Also man definiert einen contract, das ist dann praktisch eine Klasse, der contract hat Instanzvariablen. Das heißt, die haben auch state, diese Programme und Methoden und diese Methoden können auf den state zugreifen und damit irgendetwas machen und die können andere Kontrakte aufrufen. Und damit kann ich im Prinzip eigentlich alles umsetzen, was ich mit objektorientierter Programmierung umsetzten kann. Also alles, es ist eben Turing-vollständig, es gibt kein Limit und über meine Wallet-, über meine Client-Software, mit der ich mit Ethereum, mit der Blockchain interagiere oder mit dem Ethereum-Netz interagiere, mit dieser kann ich dann eben nicht nur Geldbeträge machen, sondern ich kann beliebige Methoden aufrufen. Also ich kann mir einen Kontrakt aussuchen und auf diesem Kontrakt eine Methode aufrufen und ich kann ihr Parameter mitgeben, diese Parameter können auch Geld sein, also ether oder andere Coins.

Lucas Dohmen: Das wäre dann wieder auch dieses Spritgeld, quasi?

Stefan Tilkov: Das gibt es immer. Also egal, was ich mache, zumindest für jede Mutierende. Für reine Abfragen brauche ich das nicht, aber bei mutierende Dingen, da muss ich so etwas machen. Und damit kann ich im Prinzip sicherstellen, dass so ein Kontrakt nicht technisch platzt. Also das gas stellt sozusagen sicher, dass nicht diese Endlosschleife läuft. Aber häufig gibt es auch andere Gründe, warum ich von meinem Anwender, von meinem User, irgendwelches Geld haben will. Was man typischerweise macht, ist, man definiert mit so einem contract eine Art Geschäftsmodell, darum geht es normalerweise. Also ich definiere eine Interaktion zwischen verschiedenen Parteien. Eigentlich so ähnlich, wie das ein Vertrag auch tut, den ich abschließe, wenn ich unter Unternehmen irgendeine Vereinbarung treffe. Ein Unternehmen unterschreibt einen Mietvertrag, ich bekomme irgendetwas, dafür zahle ich so und so viel Geld, die Miete erhöht sich jedes Jahr um x Prozent, es gibt eine Kaution und die bekomme ich nur zurück, wenn das und das. Das wäre etwas, was ich in einen contract hineinschreiben könnte, weil das im Prinzip ja nur ein Regelwerk ist, das sagt, was bei bestimmten Sachen passiert. Und dann könnte ich sagen, darüber zahle ich jetzt eben meine Miete. Also ich rufe die Methode miete_zahlen() auf und da gebe ich eben die Miete als Geld mit und dann wird die auf dem Internetkonto verbucht und der Vermieter kann sich das abholen. Vielleicht gibt es irgendeinen Verwalter, der sich dann einen kleinen Obulus einbehält oder so. Das wäre ein typisches Beispiel für einen contract unter mehreren Parteien und das wäre ein schönes Anwendungsbeispiel für so etwas, das man bei Ethereum macht.

Lucas Dohmen: Das heißt, ich könnte meinen Mietvertrag als Ethereum-Programm schreiben.

Stefan Tilkov: Genau. Das bringt uns ein bisschen zu der Use Case-Frage: Warum würde ich so etwas tun wollen? Also erst einmal ist das eine sehr, sehr berechtigte Frage. Denn ich habe ja gerade gesagt, das ist Turing-vollständig, das sind Programme und Programme können wir nicht erst schreiben, seit es Blockchains gibt. Also selbstverständlich können wir das auch anders machen. Wir können zum Beispiel sagen, wir machen einen Dienstleister, ein Software as a Service-Angebot, „Rent-Manager“, „Rentr“, was weiß ich, irgendetwas Cooles ohne Vokale - das war letztes Jahrzehnt, egal. Wir machen irgendein schickes Software as a Service-Angebot, das ist natürlich möglich. Das ist halt eine zentralisierte Lösung. Das ist dann ein Anbieter, der das macht, der da ein Geschäftsmodell aufbaut und der dafür natürlich Geld haben will, irgendwie. Indem er Werbung hineinschaltet oder eine monatliche fee oder sonst irgendetwas baut. Das heißt, wenn eine zentrale Lösung eine gute Alternative ist, dann sollte ich das nicht mit Ethererum machen, warum auch?

Aber manchmal gibt es Use Cases, da gibt es Leute, die miteinander kollaborieren und diese zentrale Einheit vermeiden wollen. Ein schönes Beispiel könnte sein, wir nehmen das Haus- oder Grundstückskaufs- und -verkaufswesen. Also wenn du ein Grundstück oder ein Haus kaufen oder verkaufen möchtest, bedarf das notarieller Hilfe, das kannst du nicht einfach so machen, das ist nicht erlaubt. Ein Grundstücksgeschäft ohne Notar ist einfach rechtlich verboten, nicht gültig. Das ist wie nicht gemacht. Das bedeutet, ich brauche dafür einen Notar. Warum brauche ich das? Weil der Notar sicher stellt, dass da nichts schief geht, nach einem hochkomplexen Protokoll. Also da gibt es irgendwie eine Auflassungsvormerkung und dann gibt es tausende von Eintragungen und dann achtet er darauf, dass das Geld erst überwiesen wird, wenn… Er trägt das ein, wenn Geld überwiesen wurde, was auch immer. Ein schönes Beispiel für einen sehr komplexen Prozess, an dem auch nicht nur Notar, Käufer und Verkäufer beteiligt sind, sondern auch noch das Finanzamt und die Stadt. Alle möglichen Leute haben alle möglichen Rechte in diesem ganzen Spielchen.

Da ist nicht so ganz klar, wer die zentrale Stelle sein könnte. Man könnte sagen, die Bundesrepublik Deutschland könnte einen Service zur Verfügung stellen, ja, das ist legitim. Ich vermute, das geht nicht. Ich glaube, unser Förderalismus sagt: Nicht erlaubt, das ist Stadt-/Gemeindesache. Deswegen muss die Gemeinde das machen. Das ist absolut denkbar. Warum soll nicht die Gemeinde das tun? Das könnte man in der Tat zu Ende diskutieren und sagen, es sollte so etwas geben. Es gibt bestimmt auch ein elektronisches Kataster oder so etwas im Grundbuch.

Aber: So ein zentrales Ding ist nicht nur unter zentraler Kontrolle, es ist auch ein zentrales Risiko. Denn ich habe jetzt eine zentrale Einfallsstelle. Eine Stadt betreibt jetzt so ein Ding, wieviel Vertrauen habe ich, dass die Systemadministration einer durchschnittlichen Kleinstadt so ein System vernünftig betreiben kann? Okay, vielleicht können die das outsourcen, an ein Software as a Service-Angebot. Will ich das? Will ich die Grundbucheinträge bei einem zentralen Dienstleister? Will ich das überhaupt riskieren, dass der da machen kann, was er will? Denn der kann ja jetzt beliebige Dinge machen, der könnte mal eine Grenze ein kleines bisschen verschieben. Und im Moment ist das schon dezentralisiert. Im Moment gibt es Notare, die Grundbücher, die Bank, die ausgedruckte Urkunde mit dem Notarsiegel, die man zu Hause liegen hat. Also es gibt tausende von Dingen, die alle im Prinzip das Gleiche sagen, mit denen ich im Zweifelsfall beweisen kann, was da ist, das spricht eigentlich für Dezentralisierung. Das könnte jetzt ein Fall sein, bei dem ich sage, ich baue mir ein dezentralisiertes System auf. Und ich könnte einen contract definieren. Vielleicht fange ich nicht gleich mit den Grundbüchern an, sondern mit etwas Einfacherem und würde das eben zum Beispiel bei Ethereum laufen lassen.

Lucas Dohmen: Das heißt, das wäre aktuell ein analoges dezentrales System und man könnte es dann quasi zu einem digitalen dezentralen System machen?

Stefan Tilkov: Genau. Das war ein Beispiel. Wir sind ja darauf gekommen, weil wir über contracts, über Programmierung gesprochen haben. Und im Prinzip muss man klar sagen, so ein Kontrakt ist eigentlich nur eine Digitalisierung eines wahrscheinlich vorher analogen Prozesses. Ob ich den auf einer Blockchain laufen lasse oder nicht, ist aus bestimmter Sicht ein Implementierungsdetail. Es ist erst mal nur ein Programm. Und wenn ich jetzt die Anforderung habe, dass das Ganze dezentral und ohne zentralen Intermediär und ohne Zugangskontrolle möglich sein soll - was man bei diesem Use Case sehr bezweifeln kann - wenn das möglich sein soll, dann ist so eine öffentliche, programmierbare Blockchain wie Ethereum die richtige Wahl.

Lucas Dohmen: Weil dann auch jeder nachschauen könnte, wem welches Gebiet gehört?

Stefan Tilkov: Also das ist etwas, was man heute nicht kann.

Lucas Dohmen: Ja, genau.

Stefan Tilkov: Was man mit gutem Grund nicht kann. Deswegen, das Beispiel hakt so ein bisschen. Das Beispiel, das ich gerade gemacht habe, ist ein gutes Beispiel für Programmierbarkeit, aber unter Umständen nicht für eine öffentliche Blockchain. Das bringt uns im Prinzip ganz nett zur nächsten Stellschraube. Wir haben eine Stellschraube gehabt: Programmierbar und nicht programmierbar. Man könnte sagen, Bitcoin, da ist etwas hart kodiert. Da ist der smart contract „Währung“. Der ist einfach hart ausprogrammiert und Bitcoin kann nichts anderes als das. Anders als Ethereum. Ethereum ist sehr ähnlich, hat aber diese Programmierbarkeit. Das heißt, damit könnte ich beliebige Dinge machen. Aber beide sind öffentliche Blockchains. Beide benutzen, zumindest aktuell, Proof of Work. Das heißt, beide verschwenden diese Energie. Das tun sie, weil sie den Zugang jedem gewähren, der sich technisch an die Regeln hält. Das macht sie geeignet für eine bestimmte Menge von Use Cases. Und insofern kann man absolut diskutieren, ob das, was ich gerade geschildert habe, ein guter Use Case ist.

Vielleicht ist ein Beispiel eher: Sagen wir mal, wir machen akademische Kollaboration. Oder Autorenkollaboration. Wir schreiben gemeinsam irgendetwas und wenn wir gemeinsam etwas schreiben, dann wollen wir die Royalties nachher im Verhältnis zu unserem Beitrag teilen. Und das wollen wir gerne Verlagen anbieten. Aber nicht nur einem Verlag, sondern allen Verlagen. Wir wollen das also nicht zentralisiert haben. Und dafür bauen wir uns jetzt einen smart contract auf Ethereum-Basis und Autor kann wirklich jeder werden. Auch jemand, dem man nie eine Kreditkarte geben würde, weil er vielleicht in einem Land wohnt, in dem es kein funktionierendes Bankensystem gibt. Jeder darf theoretisch Inhalt beisteuern und das ist gut, dass das so ist, und jeder wird danach vielleicht in einer Cryptocurrency bezahlt. Das ist vielleicht ein gutes Beispiel. Trotzdem kann der Vertrag damit andere Dinge tun. Da würde dann vielleicht das Ganze programmierbar auf Ethereum passen. Aber es gibt auch eine Menge Use Cases, bei denen Teile von dem, was wir bislang besprochen haben, attraktiv sind, aber das Vertrauen ein anderes ist. Oder das Vertrauensbedürfnis ein anderes ist. Ein Beispiel wäre vielleicht das, was wir gerade gesagt haben, das Notariats- und so weiter Beispiel: Da will ich vielleicht nur bestimmten Leuten den Zugang an dieser Form ermöglichen. Und dann kann ich vielleicht akzeptieren, um das Beispiel ein bisschen weiter zu strapazieren, wenn die Leute, die notarielle Funktion dort ausüben, wenn die sich vielleicht bei einer zentralen Notarregistrierungsstelle einmal anmelden müssen, dann ist nicht das ganze System zentral, sondern die Zugangskontrolle ist zentral.

Lucas Dohmen: Also das Auszeichnen als Notar?

Stefan Tilkov: Ganz genau. Und im Prinzip führt uns das zu einer Alternative zu Proof of Work. Proof of Work ist das, was wir besprochen haben, dieses Mining bei Bitcoin. Das ist bei Ethereum auch noch gibt und bei vielen anderen Blockchains auch, bei dem man im Prinzip mit dieser Brute-Force-Methode sucht. Und das ist tatsächlich der im Moment einzige etablierte, ausgereifte, funktionierende Mechanismus, wenn man niemandem vertraut.

Aber ich könnte ja auch sagen, ich vertraue bestimmten Leuten. Die weisen ihre Identität nach mit ihrem private key. Also wenn ich deren public key habe, kann ich das prüfen, was die gemacht haben, ich kann denen verschlüsselte Nachrichten schicken, die können signieren mit ihrem private key. Also alles so, wie ich das gerne haben möchte. Und wenn ich das akzeptieren kann, wenn ich akzeptieren kann, dass alle, die in meinem System mitspielen, sich vorher auf einem externen Weg, auf außerhalb des Systems irgendwie diese keys besorgt haben - wobei „außerhalb dieses Systems“ auch wieder eine öffentliche Blockchain lösen könnte. Aber das wird jetzt wieder ein bisschen „Die Katze beißt sich in den Schwanz“. Erst einmal gehen wir wieder zurück: Wenn ich das machen kann, dann gehe ich von Proof of Work auf Proof of Authority. Und das gibt es zum Beispiel als eine Art plugable consensus-Mechanismus für Ethereum. Also wenn ich möchte, kann ich Ethereum nehmen, die Software von Ethereum, und kann die auf separaten Knoten betreiben. Das ist dann nicht das große, globale Ethereum-Netzwerk, sondern mein eigenes oder vielleicht das, das ich zusammen mit meinen Partnern betreibe. Also ich und alle anderen, die in demselben Markt tätig sind. Oder meine Lieferanten und Abnehmer und ich. Was auch immer sozusagen das Konsortium ist, das sich zusammen tut, könnte Ethereum-Knoten betreiben und den Proof of Work-Mechanismus durch einen Proof of Authority-Mechanismus ersetzen. Und dann funktioniert alles ganz genauso, nur es ist eben kein Mining mehr notwendig und es geht alles viel schneller, es skaliert alles viel besser. Und das ist in vielerlei Hinsicht total super. Das hat halt nur den kleinen Nachteil, dass ich jetzt Proof of Authority habe. Der Vorteil ist gleichzeitig auch der Nachteil.

Lucas Dohmen: Das heißt, jeder muss sich darüber einig sein, dass das die Autorität ist?

Stefan Tilkov: Ich brauche einen Mechanismus, mit dem ich das mache, mit dem ich Leute onboarde, mit dem sie wieder weggehen. Das muss ich alles managen.

Lucas Dohmen: Das heißt, man hat dann quasi eine zentrale Komponente von Autorität, aber der Rest läuft weiterhin quasi nicht zentral?

Stefan Tilkov: Genau. Bei diesem kann man sich schon gut vorstellen, dass man das auch schön schachteln und mischen und hybride Lösungen bauen kann, die diese Dinge irgendwie zusammenbasteln.

Lucas Dohmen: Aber auch in diesem Modell wäre es so, dass dieses Buch, in dem alles steht, was jemals passiert ist, öffentlich zugänglich ist, in das jeder hineinschauen kann, richtig?

Stefan Tilkov: Genau, bei Ethereum ist das so, ganz genau. Das ist sehr ähnlich in der Beziehung. Es gibt die Historie, es gibt auch den Status. Ich kann auch sehen, was darin steht, in diesen Status-Dingern. Denn das müssen ja letztendlich alle wieder validieren können. Eine Mining-Node könnte ja die Notwendigkeit haben, den Status auszulesen, etwas damit zu machen, ihn neu zu schreiben. Es muss also für alle zugänglich sein und ja, das hat genau das Problem.

Lucas Dohmen: Das heißt, das wäre auch eine public Blockchain, aber nicht mehr mit Proof of Work, sondern mit Proof of Authority?

Stefan Tilkov: Nein, weil ich mich natürlich auch entscheiden kann, den Lesezugriff auch nur bestimmten Leuten zu geben. Ich weiß gar nicht, ob es die Variante gibt. Theoretisch gibt es sie auf jeden Fall. Permissioned und public würde man sagen. Permissioned bedeutet, ich darf nur teilnehmen… Nicht jeder darf teilnehmen, sondern nur die, denen es erlaubt ist, aber es ist trotzdem öffentlich. Das ist denkbar. Typisch ist aber etwas anderes. Typisch ist, dass man Öffentliche hat, die mit Proof of Work funktionieren, und nicht öffentliche, die mit einem anderen Mechanismus funktionieren. Und die sind dann typischerweise einer Gruppe von zum Beispiel Organisationen oder Unternehmen zugänglich. Das wäre so eine Konsortiums-Blockchain. Nehmen wir mal an, ich bin vielleicht im Energiemarkt, dann entscheide ich mich, dass ich ein ganz „schnarchnasiges“ Antragsverfahren habe mit Unterschriften, so richtig schön, das ist egal, das darf vier Wochen dauern, das macht nichts. Aber dann spielen die Leute da mit und danach betreibe ich Emissionshandel oder Energiehandel oder was auch immer in so einer Konsortiums-Blockchain. Da ist es im Prinzip so, da vertraut auch nicht jeder jedem beliebig, aber man vertraut der Summe von allen mehr als einem Einzelnen. Das hat auch ein bisschen was mit Kontrolle zu tun, wenn einer geht und wieviel Macht jemand hat. Das ist nicht immer nur die eine Art Vertrauen. Wenn ich sage, im Moment betreibt einfach Anbieter X das für uns. Also nehmen wir einmal an, ich suche mir ein unabhängiges Softwareunternehmen. Dieses unabhängige Softwareunternehmen betreibt das, ist Partner in diesem Ganzen, betreibt eine zentrale Lösung. Und alle anderen hängen sich einfach daran. Das ist erst einmal sehr convenient, sehr bequem. Jetzt wird diese Firma leider gekauft von einem der anderen. Und jetzt hat auf einmal einer von denen…

Das fühlt sich nicht so gut an, deswegen könnte man da sagen, okay, wir machen jetzt ein gemeinsames – level the playing field – einen gemeinsamen Spielplatz für uns alle. Alle spielen sozusagen nach den gleichen Regeln und deswegen vertrauen wir allen gleich viel und gleich wenig und wir verteilen das einfach. Also gibt es zum Beispiel die Variante, die ich gerade geschildert habe bei Ethereum. Dann gibt es eine Schweizer Versicherung, die können wir in die Shownotes packen, da habe ich, glaube ich, einen Vortrag gehört, die haben das gemacht. Die haben dann im Prinzip nett dockerisierte Umgebungen von diesen Nodes gebastelt, haben die getestet, sodass die bei AWS und bei Google Cloud und im Kubernetes-Cluster laufen und dann kann eben jeder, der mitmachen will und Zutritt bekommt, kann sich diese Software nehmen und auf seiner eigenen Infrastruktur betreiben, dann hat man die Verantwortung einfach auf mehrere Leute aufgeteilt. Das ist also eine Stellschraube.

Und das andere, das man immer wieder erwähnen muss, das habe ich in der ersten Folge schon gesagt und sage ich jetzt noch mal: Man muss keinesfalls alles in dieser Blockchain machen. Man kann wunderbar hybride Lösungen bauen. Also man legt bitte nur das in die Blockchain, was darin auch unbedingt sein muss, und alles andere bitte nicht. Das kann man als gemischtes System konstruieren. Und damit kann man dann auch sehr abgestufte Grade von Vertraulichkeit realisieren. Also vielleicht gibt es bestimmte Informationen, die nur die beiden interessieren, die miteinander interagiert haben, alle anderen nicht. Trotzdem ist ein record, sozusagen eine Absicherung, dass das passiert ist, in der Blockchain, aber das ist praktisch ein anonymes Geschäft. Das ist vielleicht nur ein Hash über den Inhalt, den wir ausgetauscht haben. Also ich habe dir irgendetwas geschickt, irgendwelche Daten, für die du mich bezahlst. Und in der Blockchain registrieren wir nur den Hash von den Daten, die ich dir geschickt habe, und nicht die Daten selbst.

Lucas Dohmen: Damit man später nachvollziehen kann, dass die Daten wirklich die sind, die zu diesem Zeitpunkt ausgetauscht wurden, aber die Daten sind nicht einfach in der Blockchain, in der jeder darauf zugreifen kann?

Stefan Tilkov: Zum Beispiel, ganz genau. Daran kann man auch ein schönes anderes Prinzip gut erläutern. Diese programmierbare Blockchain hat den Vorteil, dass eben auch das Programm abgesichert ist. Das Programm ist eben mit allen Vor- und Nachteilen der Blockchain: Es ist furchtbar langsam. Ich habe so einen riesigen Computer verteilt auf zehntausende von Knoten, der insgesamt so schnell ist wie ein PC von 1988, also ganz gruselig. Aber was darin läuft, läuft eben auch abgesichert. Bei Ethereum zum Beispiel ist es so, dass man die Programme dort hinein schreibt. Also man schickt den Byte-Code hinein. Aber es gibt einen abgestimmten Mechanismus, mit dem man belegen kann, was der Source-Code ist, der zu diesem Byte-Code gehört, sodass ich beweisen kann, was darin ist. Also bevor du eine der Methoden meines Kontraktes aufrufst, könntest du und solltest du den Code gelesen haben, damit du weißt, worauf du dich einlässt. Denn dann kannst du dir auch sicher sein, dass dieser Code läuft. Und hoffentlich verstehst du auch, was in diesem Code steht, oder lässt das vielleicht von jemand Externem prüfen, der weiß, wie dieser Code funktioniert. Und das ist ja eigentlich mehr, als du bei einem Prosavertrag normalerweise machen kannst, denn da passiert die Interpretation später vielleicht durch einen Richter.

Lucas Dohmen: Ja, verstehe. Und wir haben jetzt gesagt, dass ist eine Stellschraube, die ich verändern kann. Gibt es denn neben diesem Proof of Authority und dem Proof of Work noch weitere proofs?

Stefan Tilkov: Sehr gute Frage. Also es gibt ganz viele, dazu können wir auch noch etwas verlinken in den Shownotes. Aber die beiden vielleicht wichtigsten sind Proof of Stake und proof of service. Proof of Stake ist im Prinzip ein Verfahren, bei dem die Menge derjenigen, die abstimmen, reduziert wird. Es ist so, bei Bitcoin, da stimmen eigentlich alle ab, alle Miner stimmen gemeinsam ab. Am Ende kommt sozusagen ein Zweig der Chain als Gewinnerzweig heraus und bleibt der Hauptzweig. Das heißt, wir stellen Konsens her zwischen allen oder sagen wir mal zwischen mindestens 51 Prozent dieser Gesamtmenge von Nodes. Das ist natürlich sehr aufwändig, deswegen dauert das auch so lange, deswegen ist das so ein kompliziertes Verfahren, um das Ganze zu machen. Bei dieser Menge von Knoten, denen ich nicht vertraue, gibt es auch eigentlich nichts anderes. Nein, das ist falsch, es gab lange Zeit nichts anderes.

Was ich hier mache, das ist ja nicht ein klassisches Konsensusproblem, bei dem ich einen Paxos oder so etwas verwenden kann, da können wir wieder unsere „Getauscht“-Episode verlinken, weil Paxos nicht skaliert für so etwas. Denn die funktionieren eben auch nicht, wenn du dem Partner nicht vertraust. So etwas wie Practical Byzantine Fault Tolerance gibt es schon ewig, das skaliert vielleicht bis zehn Knoten, aber nicht für hunderttausend. Das geht einfach nicht. Proof of Work tut das, das nennt man Nakamoto Consensus, nach Satoshi Nakamoto.

Eine Alternative ist Proof of Stake. Da ist es so, dass aus der Menge der möglicherweise Abstimmenden, die theoretisch abstimmen könnten, eine Teilmenge heraus genommen wird: Man hat 100.000, die es theoretisch machen könnten, aber man nimmt nur 25. Diese 25 können dann einen leichteren, schnelleren, klassischeren Algorithmus durchführen, um den Konsens herzustellen. Welche 25 Knoten das sind, entscheidet man zufällig und gewichtet mit dem stake, den sie im Gesamtsystem haben. Also nicht das Steak, das man isst, sondern der Anteil, der stake. Dieser ist im Prinzip der Grad, zu dem sie in das System investiert sind. Wenn man also ganz viele z.B. Ether oder was auch immer besitzt, dann hat man ein großes Interesse, dass das so ist. Und dann kann man auch sagen, man riskiert davon auch noch etwas, man kauft sich praktisch ein. Man kauft sich das Recht ein mit zu voten, indem man sagt: Hier sind x-hundert Währungseinheiten. Wenn man betrügt, verliert man sie und wenn man ausgewählt wird, mitvotet und damit geholfen hat, dass das Ganze weitergeht, dann bekommt man dafür einen Obulus. Es wird einem dann „verzinst“.

Lucas Dohmen: Aber wer kann denn wissen, dass jemand betrogen hat, wenn jetzt alle gemeinsam betrogen hätten?

Stefan Tilkov: Alle gemeinsam? Das ist die Sache des Zufalls. Es muss ein ordentlicher, zufälliger Mechanismus sein, der das auswählt und dann können diejenigen, die zufällig mit einer berechenbaren Wahrscheinlichkeit ausgewählt wurden, sich auf etwas einigen. Wenn dann einer versucht zu betrügen, dann kann man ihn entsprechend aussortieren, er darf nicht mehr mitvoten und verliert seinen Einsatz.

Lucas Dohmen: Okay. Aber wenn es jetzt eine Verschwörung wäre von denen, die zufällig ausgewählt wurden, dann würde es nicht funktionieren?

Stefan Tilkov: Genau das. Das ist ein alternatives Verfahren, das ganz, ganz viele Einfallstore hat, die in epischer Breite diskutiert werden. Es gibt unglaublich aufwendige, akademische Papers dazu, einige glaubwürdig, andere weniger. Es ist eine wahnsinnig schwierige Sache, bei der man überlegen muss: Ist das überhaupt fair? Was passiert, wenn die Leute das kurzfristig nutzen? Was ist, wenn sie versuchen, es mit Geld von früher, das vielleicht viel weniger wert war, zu nutzen? Wenn sie versuchen, eine Transaktion zu fälschen, die lange zurückliegt. Da spielt auf einmal die Wertentwicklung eine Rolle. Gibt es Fluchtwege? Kann man sein Geld woanders hin retten? Dann könnte man nämlich kurz betrügen und sein Geld schon retten, bevor man dafür bezahlt - es ist unglaublich aufwendig. Deswegen ist Proof of Stake aktuell auch noch in keiner öffentlichen Chain als echte Alternative bereits etabliert. Ethereum ist da sehr stark dran, die wollen das unbedingt. Sie wollen unbedingt weg vom Proof of Work wegen der Energieeffizienz. Die haben damit angefangen und bauen so einen Mechanismus langsam auf, der im Moment redundant mitläuft. Da gibt es ganz viele Dinge, da gibt es ganz viele Diskussionen, es ist noch nicht so weit, das ist noch sehr unausgereift, aber es wäre eine mögliche Sache.

Lucas Dohmen: Aber das wäre zum einen ein Lösungsansatz, um den Energieverbrauch zu senken, aber auch, um es skalierbarer zu machen auf mehr Transaktionen.

Stefan Tilkov: Absolut. Wobei es beim Thema Skalierbarkeit noch komplizierter wird, denn richtig gut skalierbar wird es erst, wenn man förderiert. Man macht praktisch sharding. Da können wir wieder ein Begriff verwenden aus unserer anderen Folge. Wenn man sagt, es gibt einzelne Teilbereiche, die sich um etwas kümmern und am Ende wird wieder alles zusammen konsolidiert. Aber dann wird alles noch komplizierter. Denn man hat ja im Prinzip alle die Probleme, die man auch bei verteilten Datenbanken hat, multipliziert mit allen Problemen, die man bei sicherheitsrelevanten Systemen mit malicous actors hat, mit bösartigen Leuten, denn davon muss man ja ausgehen. Das macht es einfach wirklich sehr kompliziert.

Lucas Dohmen: Ja, verstehe.

Stefan Tilkov: Dann habe ich noch von proof of service gesprochen, eine Variante, die ich interessant finde. Proof of service ist ursprünglich aus etwas anderem entstanden: Man belegt nicht, dass man Energie verbraucht hat, um ein „blödsinniges“ Rätsel zu lösen, sondern man belegt, dass man etwas anderes gemacht hat, idealerweise etwas Sinnvolles. Zum Beispiel könnte man in einem System, das vielleicht Dateien speichert, Speicherplatz zur Verfügung stellen und beweisen, dass man Speicherplatz zur Verfügung gestellt hat. Und nur wenn man beweisen kann, dass man das getan hat, darf man einen Block unterschreiben.

Lucas Dohmen: Aber es muss ja etwas sein, das man als externes System nachvollziehen kann, dass du das belegt hast?

Stefan Tilkov: Ganz genau, dafür gibt es entsprechende Verfahren, mit denen man so etwas belegen kann. Entweder indem man vielleicht die Dienstleistung erbracht hat, mit was auch immer das Protokoll darin ergibt oder indem man beweist, dass man irgendetwas hat, also dass man beweist, dass man über eine bestimmte Kapazität verfügt. Man hat sie vielleicht nicht für den Zweck der Blockchain eingesetzt, aber es gibt ein Verfahren, mit dem man beweisen kann, dass man eine bestimmte Menge RAM oder eine bestimmte Menge Speicherplatz hat. Dafür gibt es ein gar nicht so triviales, algorithmisches Verfahren, mit dem man das belegen kann. Da muss ich praktisch zufällig irgendetwas machen, da kann man ähnlich wie beim Hashing nachvollziehen, dass man das gemacht hat, und es ist deutlich billiger, als es zu machen. Dabei ist das Asymmetrische ja immer der Trick bei der Sache. Es gibt also andere Mechanismen, mit denen man diesen Teil ersetzt. Bei proof of service ist es im Prinzip so, dass man belohnt wird. Man könnte sagen, es ist eine Generalisierung des Mining-Rewards von Bitcoin. Bei Bitcoin wird man als „Miner“ dafür belohnt, dass man den Dienst erbracht hat, Blöcke zu finden. Dafür bekommt man einen Reward. Und proof of service ist eigentlich das etwas verallgemeinert: Man bekommt einen Reward für irgendetwas Sinnvolles, das man im System getan hat. Ein schönes Beispiel dafür in vielerlei Hinsicht ist „Dash“. Ich weiß gar nicht, wie populär Dash noch ist. Das ist eine Krypto-Währung, die ursprünglich ein Fork von Bitcoin war, sie macht also sehr viel sehr ähnlich, inklusive proof of work. Aber sie hat eine interessante hybride Lösung: Es gibt dort zwei zusätzliche Arten von Interaktionen oder Transaktionen. Das eine ist das sogenannte InstantSend. Da geht es darum, dass man skalierbar und ganz, ganz schnell Beträge durch die Gegend schicken kann. Und das zweite ist AnonymousSend, Ich kann etwas schicken und es wird anonymisiert. Diese beiden Zusatzdienste gegenüber Bitcoin werden von sogenannten master nodes erbracht. Das sind besondere Nodes, die nur diese Aufgabe haben. Im Prinzip könnte man sagen, darüber ist so eine Art zweites Netz gelegt für diese extra schnellen Transaktionen, könnte man sagen. Diese extra schnellen Transaktionen zum Beispiel werden sofort durchgeführt und sind dann nur von den master nodes bestätigt und nicht von dem gesamten Blockchaining, auch nicht mit dem gleichen Vertrauen, sind aber eben super schnell. Und sie werden praktisch batch-artig alle x Zeiteinheiten oder alle x Blockgrößen in der richtigen Blockchain darunter abgesichert.

Lucas Dohmen: Von den master nodes?

Stefan Tilkov: Sie werden von den Master-Noders in die per Proof of Work abgesicherte Haupt-Blockchain geschrieben. So könnte man es vereinfacht erklären. Das heißt, man hat einen schnellen Mechanismus, wie In-Memory-Transaktionen, die dann irgendwann auf Platte oder auf SSD oder so etwas gespeichert werden. So ähnlich ist es hier auch: Schnell bei diesen master nodes, die kollaborieren, langsam, aber sicher in der gesamten Blockchain. Und diese master nodes müssen ja irgendwie ausgewählt werden. Und man wird ein master node, indem man hunderttausend Dash besitzt, also wenn man das will. Man muss belegen, dass man sie hat. Wenn man sie nicht mehr hat, dann ist man kein master node mehr. Wenn man sie hat, darf man das sein.

Lucas Dohmen: Also nur die Superreichen?

Stefan Tilkov: Im Prinzip, ja. Oder tausend Dash sind es, glaube ich. Es ist meine ich, ein sechsstelliger Eurobetrag, schon viel Geld. Um master node zu werden, muss man also etwas einsetzen, das motiviert, das ist ein bisschen wie bei Proof of Stake. Nicht ganz, aber man zeigt sozusagen, dass man ein kapitales Interesse - im wahrsten Sinne des Wortes - an dem System hat. Aber danach passiert etwas wirklich Cooles: Der Blockchain-Mining-Reward, den die normalen Miner, die wie Bitcoin-Miner funktionieren, bekommen, wird aufgeteilt: Auf den Miner, der gewonnen hat und auf zufällig ausgewählte master nodes. Das heißt, die master nodes werden dafür belohnt, dass sie master nodes sind. Sie erbringen sozusagen einen Dienst und dafür werden sie belohnt. Und das ist im Prinzip der Mechanismus, der dahintersteckt und das finde ich eine sehr schöne hybride Lösung für das Ganze. Wenn man das generalisiert, dann kann man sich vorstellen, dass jemand in so einem entweder hartkodierten oder per smart contract umgesetzten, kollaborierendem System von Parteien, die irgendetwas machen, einfach belegt, etwas getan zu haben, und damit dann dazu beiträgt, dass sich das Ganze weiterbewegt. Das finde ich eine ganz nette Variante.

Lucas Dohmen: Interessant.

Stefan Tilkov: Wir waren bei den Stellschrauben, wir haben über die Programmierbarkeit gesprochen. Wir haben über die Konsensus-Mechanismen gesprochen, insbesondere Proof of Stake und Proof of Work und wir haben auch ein wenig über diese permissioned- bzw. non-permissioned-Geschichte gesprochen. Das kann man vielleicht noch ein bisschen klarer machen. Das eine ist, dass wir gesagt haben, wer mitspielen darf. Wir haben auch schon kurz bei Ethereum gesagt, wir könnten uns theoretisch vorstellen, verschiedene Organisationen gemeinsam zusammenzubringen, damit sie so ein Konsortium bilden. Es gibt aber auch ganz viele Leute, die Blockchain-Lösungen für den unternehmensinternen Einsatz verkaufen. Spätestens da kann man sich absolut fragen, ob das irgendeinen Sinn ergibt: Das Ganze ist ja extra aus diesem Use Case entstanden, bei dem man den Leuten nicht vertraut. Wenn ich in einem unternehmensinternen Use Case bin, dann vertraut man hoffentlich dem eigenen Unternehmen, der eigenen Abteilung. Da wird man so etwas in der Regel nicht brauchen. Nicht alles, was Kryptographie benutzt, nicht alles, was Dinge unterschreibt oder einen Hash benutzt, ist automatisch eine Blockchain. Der Begriff ist tatsächlich auch definiert, nämlich das, was Bitcoin als Blockchain definiert, ist eigentlich auch eine Blockchain, aber das ist mittlerweile so divers, dass ganz viele Leute alles mögliche in diesen Topf hineinwerfen. Sicherlich wird das wieder ein bisschen zurück gehen, da es manchmal jetzt auch schon negative Assoziationen hat, dass weniger Leute das verwenden. Da ist die Stellschraube gültig, das Ganze nicht öffentlich zu machen. Es gibt - das habe ich früher anders gesehen, aber mittlerweile bin ich fest davon überzeugt - eine Menge Use Cases, die sinnvollerweise nicht komplett öffentlich sind oder bzw. nicht komplett für jeden zugänglich sind. Die gibt es absolut. Das ist so ein grauer Bereich zwischen ganz öffentlich und komplett intern.

Lucas Dohmen: Es ist also nicht öffentlich, aber die Parteien vertrauen sich gegenseitig nicht.

Stefan Tilkov: Oder sie vertrauen sich gegenseitig nicht hundertprozentig. Sowohl öffentlich und privat, wie auch vertrauenswürdig und nicht vertrauenswürdig sind beides keine binären Aussagen. Das sind Regler, die man durch die Gegend schieben kann. Wenn man aber komplett vertrauenswürdig ist, ist eine Blockchain einfach Blödsinn. Warum sollte man so etwas tun wollen? Das kann ich nicht erkennen. Da will man vielleicht auch Immutability und möchte Dinge absichern, vielleicht signieren. Das ist alles völlig in Ordnung, aber das bedeutet nicht automatisch eine Blockchain. Eine Blockchain hat immer diese Aspekte, aber nicht anders herum: Nicht immer, wenn man etwas signiert, braucht man automatisch eine Blockchain.

Lucas Dohmen: Ja. Die anderen kryptographischen Verfahren sind ja weiterhin vorhanden und liegen auch teilweise darunter. Man kann auch andere Wege finden zu beweisen, das etwas passiert ist, wenn man ein Grundvertrauen im System hat, richtig?

Stefan Tilkov: Ganz genau. Was Bitcoin und die Blockchain lösen, diese verwandten Dinge, das ist eigentlich dieses „Double-Spend“-Problem und das hat etwas mit Historie zu tun. Man will eine nachvollziehbare Historie haben, was passiert ist, und man möchte auch eine Historie haben, was nicht passiert ist. Es gibt dazu ein klassisches Beispiel: Vielleicht hast du es schon mal gesehen, wenn bei Twitter irgendwelche Leute einen Hash posten?

Lucas Dohmen: Ja.

Stefan Tilkov: Das machen manche Leute. Sie posten so einen Hash und machen ein großes Geheimnis darum, was das bedeutet. Und dann können sie ein halbes Jahr später sagen, dass sie damals schon wussten, dass irgendetwas passiert. Sie nehmen dieses Fakt, hashen es und da kommt der Hash heraus, den sie vor sechs Monaten schon gepostet haben. Das Blöde ist, man weiß nicht, ob sie nicht vielleicht auch schon hunderttausend andere Tweets erstellt haben, die alle gelöscht wurden, sodass nur der eine übrig bleibt, der dazu passt. Das kann in der Blockchain nicht passieren.

Lucas Dohmen: Man muss natürlich auch Twitter vertrauen als Entität.

Stefan Tilkov: Ganz genau. Also Twitter als zentrale Instanz. Selbst da könnte man auch sagen, für viele Use Cases ist es vielleicht eine gute Idee, einfach bei irgendeiner externen Instanz noch etwas abzulegen. Das reicht vielleicht, um den Angriffsvektor, den man da sicherheitsmäßig adressieren will, abzudecken. Oder das wäre vielleicht auch ein Use Case für eine Blockchain: Man möchte irgendetwas absichern, das macht man, indem man ab und zu einen Hash nimmt von irgendetwas und diesen in irgendeine der bestehenden öffentlichen Blockchains reinpostet. Das ist, glaube ich, ein Trend, der noch nicht so häufig vorkommt, wie er es tun könnte. Ich kann mir gut vorstellen, dass man hybride Systeme hat, die auf diese Art und Weise gebaut sind. Bei denen man ein ganz klassisches, zentralistisches System hat, das ab und zu mal abgesichert wird. Dann aber bitte auch mit einer öffentlichen Blockchain. Wir hatten zum Beispiel gerade bei der authority-Sache: Wenn man sich vorstellt, man muss sich registrieren, um bei irgendeiner Blockchain teilnehmen zu können. Dann könnte ich mir vorstellen, dass man die Registrierung in der öffentlichen Blockchain auf Basis eines öffentlichen contracts macht. Dann ist eben eine der Parteien in diesem contract diejenige, die vielleicht bei Video-ID meinen Personalausweis prüft und dann irgendwann sagt, jawohl, das ist passiert. Das wird in der Blockchain auch bestätigt und dann läuft irgendeine Maschinerie, die auf irgendeine Art und Weise meinen Key-Request unterschreibt, damit ich in der anderen Blockchain mitspielen kann, wo nur Zugelassene mitspielen können. Das ist nur ein Beispiel, so etwas könnte ich mir sehr gut vorstellen.

Lucas Dohmen: Eine Sache, die ich auch schon gesehen habe, sind Cloud-Anbieter, die ein Blockchain-Produkt anbieten. Was muss man sich darunter vorstellen. Was bekomme ich von denen?

Stefan Tilkov: Zunächst einmal in das sehr schräg, weil man ja gerade etwas Dezentrales möchte. Was ergibt das für einen Sinn? Und ich glaube, in erster Näherung ist das auch häufig hauptsächlich für Testzwecke gedacht. Also ich kann schneller irgendetwas ausprobieren, habe das dann vielleicht in der Umgebung schon vorkonfiguriert und das ist völlig in Ordnung. Was sicherlich keinen Sinn ergibt, ist, einen externen Dienstleister zentral mit dem Betrieb meiner Blockchain zu betrauen. Das ist einfach totaler Unsinn. Auch wenn der drei Buchstaben hat und ein berühmtes Unternehmen ist, halte ich das nicht für sinnvoll. Aber ein anderes Beispiel, ein schönes Beispiel, ist so etwas wie Amazon. Da gab es ja kürzlich auch entsprechende Ankündigungen, wo es zwei Arten von Ankündigungen gab. Das eine ist einfach nur eine Art und Weise, wie ich meine eigene Lösung betreiben kann, wenn ich Amazon-Kunde bin, das ist natürlich eine denkbare Variante. Das kann ich ja machen für irgendeinen Use Case.

Eine andere Variante, die ich mir vorstellen kann, wäre, dass verschiedene Amazon-Kunden miteinander kooperieren, die alle sozusagen Herr ihrer eigenen Daten, ihrer eigenen Entscheidungen sind und ich praktisch Dezentralisierung über mehrere, unabhängige Amazon-Accounts habe. Reicht mir das jetzt als Dezentralisierung? Keine Ahnung, das kommt wahrscheinlich auf den Anwendungsfall an, den ich da habe.

Lucas Dohmen: Aber dann ist ja immer noch sehr viel Vertrauen in Amazon notwendig?

Stefan Tilkov: Ja. Wobei ich trotzdem gewisse Dinge herausziehe. Das ist immer eine Frage. Generell, je nachdem, wo man sich selbst positioniert auf diesem Sicherheitsspektrum: Lehnt man das vielleicht grundsätzlich komplett ab, irgendetwas in einer Cloud zu machen? Aber wenn man vielleicht sowieso schon Cloud-Partner ist… Wenn ich mir vorstelle, ich habe fünf Unternehmen, die alle mit Cloud kein Problem haben, warum sollten die nicht auf so eine Art und Weise kooperieren? Die würden dann praktisch die Kollaboration zwischen ihren einzelnen Amazon-Inseln kryptographisch abgesichert haben und Amazon selbst hätte die Keys nicht, es sei denn, sie würden überall das Vertrauen komplett ruinieren. Aber dann würden sie wahrscheinlich schon ganz andere Dinge machen können. Also wenn Amazon - oder jeder beliebige Cloud-Anbieter - das Interesse hätte, seine eigenen Kunden auszuspionieren, dann würden die wahrscheinlich als letztes ausgerechnet auf deren Blockchain-Lösungen losgehen. Aber das ist nur eine These, das stimmt wirklich.

Lucas Dohmen: Aber es wäre doch trotzdem so, dass wenn man jetzt sowieso dieses System einsetzt, dass man auch einfach sagen könnte, AWS ist unsere zentrale Entität, die unsere Dinge signiert für uns, und wir vertrauen darauf, dass die das tun, oder?

Stefan Tilkov: Das könnte man selbstverständlich machen und es gibt auch durchaus Angebote von Cloud-Anbietern, die einfach so bestimmte Teil-Use-Cases umsetzen und einfach genau mit diesem Grundsatz. Also was du eigentlich willst, ist: Du glaubst zwar, dass du eine Blockchain möchtest, aber das liegt nur daran, dass du nicht so genau weißt, was das ist. Was du eigentlich möchtest, ist ein fälschungsicheres ledger, in das du Fakten hineinlegen kannst, die abgesichert sind. Und das biete ich dir einfach als Service an. Dann ersetzt sozusagen dieser Service das, was ich mir von der Blockchain verspreche, mit anderen Mitteln, mit viel mehr Zentralisierung, aber das ist für manche Leute vielleicht auch die richtige Wahl.

Lucas Dohmen: Also einfach ein zentrales Logbuch und wir vertrauen darauf, dass der Verwalter des Logbuchs keinen Unsinn macht?

Stefan Tilkov: Genau. Das ist total zentralisiert und etwas anderes, also nicht verwechseln. Aber das ist eben etwas, was man ganz häufig hat. Man hat ganz häufig in diesem Umfeld Use Cases, bei denen man sich am Kopf kratzt und fragt, wer um Himmels Willen hat sich das denn ausgedacht. Dann schaut man näher hinein und dann weiß es auch eigentlich niemand so genau, warum das so ist. Es ist einfach so, zum richtigen Zeitpunkt hat der Richtige ein Lab aufgemacht und wollte etwas mit Blockchain machen und macht es deswegen. Das ist kein guter Grund.

Aber nur weil es schlechte Use Cases gibt, bedeutet das nicht, dass es keine Use Cases gibt. Es gibt durchaus welche und man muss eben sehr genau hinschauen. Und man muss aufpassen, wenn jemand immer für alles eine Blockchain als Lösung empfiehlt, dann ist es ganz bestimmt keine gute Idee. Und vielfach werden auch Sachen verwechselt. Also Digitalisierung wird mit Blockchain verwechselt. Überhaupt irgendetwas zu automatisieren, wird mit Blockchain verwechselt. Das ist natürlich alles abwegig. Trotzdem möchte ich eine Lanze dafür brechen, es gibt durchaus sinnvolle Fälle, bei denen man das Ganze benutzen kann.

Lucas Dohmen: Aber ich meine, das liegt ja auch einfach daran, dass es ein Hype-Thema ist und das passiert ja bei jedem Hype-Thema, dass es als Label benutzt wird für unsinnige Dinge.

Stefan Tilkov: So ist das nun einmal, ja.

Lucas Dohmen: Okay, gut. Gibt es noch irgendetwas, was du jetzt aktuell siehst, wo du sagst, das ist eine Entwicklung, die du beobachtest, bei der du sagst, das könnte wirklich interessant werden. Oder so ein Ausblick, was noch kommt?

Stefan Tilkov: Das Problem ist, es gibt im Moment gerade unglaublich viel. Ich finde, es ist wahnsinnig schwierig, die Spreu vom Weizen zu trennen. Ich bin jetzt sehr sensibilisiert, weil ich jetzt ein paar Mal Marketingsachen gelesen habe, die wirklich entsetzlich waren. Die sahen super toll aus, aber haben einfach keinerlei Fleisch. Ich glaube, dass es da eine heftige Konsolidierung geben wird, dass ganz viele Sachen verschwinden werden, dass ein paar übrig bleiben. Es wird noch ein paar fette Incidents geben, ein paar werden daran zugrunde gehen, dass sie eben viel zu viel versprochen haben und nichts herauskommt. Aber es werden so ein paar Dinge übrig bleiben. Ich finde das ein sehr spannendes Thema, ich habe aber jetzt keinen einzelnen Kandidaten. Vielleicht ist es so, dass ich noch am ungewöhnlichsten in meinen Ansichten in unserer Community bin, weil ich Bitcoin nicht so ablehne wie viele andere. Viele sagen, es ist nicht Bitcoin interessant, sondern die Blockchain. Ich prophezeie tatsächlich Bitcoin eine ziemlich große Zukunft wegen des Netzwerkeffekts. Das ist schon so lange da, es ist sehr ausgereift, sehr solide. Es ist sehr schwer, dagegen anzustinken. Und da passiert auch eine Menge. Also so etwas wie das Lightning-Network, dafür hatten wir jetzt keine Zeit, das adressiert sozusagen das Skalierungsproblem auf Bitcoin obendrauf. Das ist noch nicht so weit, aber das könnte dann tatsächlich sehr spannend werden. Auch bei Ethereum passieren sehr, sehr viele spannende Dinge. Beide finde ich immer noch sehr interessant, aber es gibt zwanzig andere, die auch total cool sind.

Lucas Dohmen: Okay, gut. Dann würde ich sagen: Vielen Dank für die tolle Übersicht.

Stefan Tilkov: Sehr gerne.

Siri: Es war mir eine Freude

Lucas Dohmen: Dann den Hörern und Hörerinnen: Bis zum nächsten Mal.

Stefan Tilkov: Bis dann, tschau.

Lucas Dohmen: Tschau.