Ich habe in theoretischer Informatik promoviert, und zwar im Themengebiet der Komplexitätstheorie. Konkret ging es um Optimierungsprobleme mit mehreren Kriterien. Das bedeutet, dass man eine Lösung sucht, die man nach verschiedenen Gesichtspunkten bewerten kann. Die Frage ist dann natürlich, was man tut, wenn zwei unterschiedliche Bewertungen sich gegenseitig widersprechen – dann ergeben sich ganz interessante Problemfälle.
Die Themenstellungen, in denen ich gearbeitet habe, hatten zwar auf den ersten Blick weder mit Ethereum noch mit Blockchain etwas zu tun, aber in der Komplexitätstheorie ist man an Fragen der folgenden Art interessiert: Welche Funktionen sind berechenbar? Bleiben sie bei Einschränkung der Computer-Ressourcen immer noch berechenbar? Wie stehen diese Ressourcenbeschränkungen zueinander?
Und hier sind wir schon bei Fragestellungen der Kryptographie. Kryptographie heutzutage spielt immer mit dieser Ressourcenbeschränkung. Per se ist moderne Kryptographie immer knackbar, die Frage ist nur, wie lange es dauert (in Abhängigkeit der Ressourcen).
Die virtuelle Maschine bei Ethereum ist auch stark ressourcenbeschränkt. Dies wird über eine Maximalmenge an so genanntem Gas erreicht, die ein Block verbrauchen darf (Gas ist dabei Ethereum-interne Währung, Operationen auf der Ethereum-Blockchain kosten immer etwas Gas – Anmerkung von BTC-Echo). Und hier sind wir bei vielen Fragestellungen, die nahe an der Komplexitätstheorie sind.
Außerdem hat man interaktive Protokolle, bei denen unterschiedliche Parteien miteinander kommunizieren und zusammen eine bestimmte Funktion berechnen wollen – und so finden im Rahmen Smart Contracts bestimmte Bereiche der Komplexitätstheorie hier Anwendung.
Du bist ja jetzt mit Solidity am bekanntesten. War Solidity eigentlich schon immer die Sprache?
Ganz am Anfang gab es Bytecode bzw Assembler. Nach und nach wurden Hochsprachen entwickelt. Vitalik Buterin hatte Serpent auf Basis von Python entwickelt, Mutan sollte C-ähnlich sein, LLL war LISP-ähnlich. Gavin Wood hat den Vorschlag gemacht, mit Solidity eine Sprache auf der Basis von Java Script zu entwickeln, deren grundlegendes Element Smart Contracts sind – da kam ich dann dazu.
Solidity nutzt ja die Ethereum Virtual machine (kurz EVM) . Wie kann ich mir das Zusammenspiel von Solidity, EVM und Blockchain genauer vorstellen? Ist die EVM Code innerhalb des Ethereum Wallets?
Solidity nutzt die EVM als Systemarchitektur. Das ist an sich erstmal ein theoretisches Konzept. Eine Ethereum Node, die eine Transaktion verifizieren will, muss sie dazu innerhalb der EVM ausführen. Die EVM kann man unabhängig von der Blockchain sehen. Sie hat Zugriff auf eine Datenbank und diese Datenbank ist über Merkle Tree hashing auf der Blockchain gespeichert.
Wenn man Smart Contracts in Solidity verfassen will, hat man ja die Wahl zwischen der IDE Mix und der Programmierung von Solidity im Browser. Was sind hier die Unterschiede?
Browser-Solidy wird in Zukunft etwas offizieller laufen, bis vor wenigen Wochen lief es unter meinem privaten Github-Account. Primär ist es dafür da, schnell im Browser einen Smart Contract auszuprobieren, ohne irgendwas zu installieren. Im Textfeld kann man seinen Smart Contract reinschreiben und rechts sieht man dann sofort die dazugehörige IDE und kann die Interaktionen mal durchtesten.
Mix ist letztlich eine richtige Entwicklungsumgebung mit Debugger. Man kann, wenn man will, damit den Code in Assembler schrittweise durchführen, ansehen, wie sich Variablen ändern – all die schönen Dinge, die man mit einer guten IDE halt kann. Ein Problem mit Mix ist jedoch, daß es eine klassische Qt-Anwendung ist. Damit läuft es auf verschiedenen Systemen verschieden gut.
Deshalb werden wir auf lange Sicht alle Features von Mix im Browser zur Verfügung stellen und dadurch einen gewissen Standard schaffen. Da Programmierer gerne in ihrer Lieblings-IDE bleiben – sei es Atom, Sublime, Visual Studio Code etc – haben in letzter Zeit viele Leute für verschiedene Programmierumgebungen Erweiterungen geschrieben. Solange die genutzten IDEs html-basiert sind, kann man den geplanten Debugger einfach zu IDE der Wahl dazuladen.
Solidity – eine Sprache für Visionen
Smart Contracts, zumindest selbst laufende Verträge, ist eines der großen mit Visionen verbundenen Buzzwords der heutigen Tech-Branche. Was ist für Dich eine der großen Visionen bzgl Buzzwords, auf die Du hinarbeitest?
Einerseits, dass man Verwaltungsangelegenheiten auf die Blockchain bekommt, um Kosten und Aufwand zu sparen, und um Leuten, die “verwaltet” werden, mehr Transparenz zu geben.
Andererseits, dass man diese Dinge komplett in die Hände der Einzelpersonen gibt. Wenn ich ein Grundstück verkaufen will, brauche ich dann nur meinen Private Key, der auf das Grundstück registriert ist. Ich hoffe darauf, dass am Ende der gemeine Mensch mehr Kontrolle bekommt – ohne middle men auf verschiedenen Ebenen.
Bisher ist es so, dass, wenn ich eine größere Aktion starten bzw eine größere Organisation gründen will, ich dafür schon viel tun muss, um die Regularien bestimmter externer Regierungen etc. zu befriedigen. Selbst bei kleineren Dingen muß das oft erst durch die Hände von größeren Organisationen, um größere Reichweite zu erlangen und überhaupt legal zu sein.
Im Gegensatz dazu ermöglicht die Blockchain über Smart Contracts, daß zwei Menschen vertraglich ohne middle man und Verwalter interagieren können. Es wird dann das geschehen, was im Smart Contract steht und nichts anderes. Letztlich ist die DAO ein Beispiel dafür, wie stark der Verwaltungsaufwand abgebaut und der Einzelne Mensch zu größeren Dingen bevollmächtigt werden kann.
Was fehlt außer Akzeptanz noch vom System her an Solidty, um diese Vision zu erreichen ?
Sagen wir es eher als Zielstellung: Bei Solidity wollen wir jetzt stärker in Richtung Modularität gehen, so daß man mehr wiederverwendbare Bibliotheken hat. Das Ganze läuft dann unter dem Namen Library contracts. Am Ende hätte man wiederbenutzbare allgemeine Datenstrukturen, die man via Import nutzen kann.
Ein weiteres Ziel ist, daß man die Sprache von außen erweitern kann – bisher muß man für viele Neuerungen in den Compiler gehen und den Compiler ändern. Ziel ist, daß man Solidity so erweitern kann, daß die Erweiterung so aussieht wie ein natives Feature, ähnlich wie es bei Python möglich ist.
Außerdem wollen wir formale Verifikationen ermöglichen. Wenn man einen Smart Contract schreibt, kann man sich natürlich den Quelltext durchlesen und überlegen, ob der Smart Contract die Eigenschaft hat, die man von ihm erwartet. Als Beispiel könnte man einen Smart Contract betrachten, der die Wurzel eines Eingabewerts berechnen will. Man kann eine mathematische Bedingung formulieren in der Form “Für alle x gilt f(x)*f(x)=x”, wobei f(x) dann der Smart Contract mit Eingabewert x ist. Entsprechend der Bedingung würde beim Smart Contract tatsächlich die Wurzel berechnet werden.
Der Mechanismus, um diese Wurzel zu berechnen, ist komplexer, aber mit einer formalen Verifikation auf der Basis der obigen Formel würde der Mechanismus dann verifiziert werden. Am Ende ist das natürlich nur ein Hilfsmittel: Man muß immer noch die mathematische Bedingung verstehen, aber die Komplexität würde damit reduziert und könnte damit den beteiligten Parteien helfen, sich über den Smart Contract zu einigen.
Nach der Frage zur Deiner Vision hinsichtlich Solidity kann man die Frage natürlich auch umdrehen: Wo siehst Du Dinge, wo Du Dich nicht freuen würdest, wenn sich die Infrastruktur um die Smart contracts in die Richtung entwickeln würde?
Im Prinzip kann ein Smart Contract auch für beliebige negativen Dinge genutzt werden – aber das kann man auch über das Internet sagen. Die Nicht-Manipulierbarkeit ist natürlich ein zweischneidiges Schwert. Deshalb braucht es an der Schnittstelle zur Realität verantwortungsvolle Nutzer, die illegale Angebote etc nicht nutzen.
Man muß sich klar machen, daß mit der großen Freiheit, die die Blockchain-Entwicklungen und Ethereum im Besonderen mit sich bringen, auf die einzelnen Nutzerinnen und Nutzer auch viel Verantwortung zu kommt.
Generell hört man aus der Ethereum-Szene oft, daß man eine Zukunft der Koexistenz zw Bitcoin und Etherum sieht. So positiv das Ziel auch ist möchte ich jedoch mal die provokante Frage stellen: Was ist an Bitcoin besser als Ethereum? Ist es einfach der Standard? An sich könnte man ja denken, daß Ethereum den Funktionsumfang von Bitcoin hat und noch einiges mehr kann….
Im Prinzip kann man natürlich alle Features von Bitcoin zu Ethereum hinzufügen, aber es gibt schon ein paar Bereiche, in denen Bitcoin zur Zeit noch besser ist.
Aktuell haben wir keine Light Clients, was Standard bei Bitcoin ist. Das UTX-O-System bei Transaktionen, das Bitcoin nutzt, existiert so bei Ethereum noch nicht, unsere Transaktionen sind Account-basiert.
Die Stärke von Bitcoin ist durchaus seine Einfachheit, der Fokus auf Zahlungsvorgänge. Bitcoin ist rein für Zahlungsverkehr geschaffen, Ethereum ist auf Smart Contracts hin konzipiert.
Zum Thema friedliche Koexistenz kann man auf BTC-Relay hinweisen: Seit kurzer Zeit ist BTC Relay live, womit man in Ethereum Bitcoin-Transaktionen verifizieren kann. Damit ist es möglich, Bitcoin auf der Ethereum-Blockchain als Tokens zu verschieben, quasi als e-Bitcoin. Mit dem Launch von EtherEx, einem dezentralisierten Exchange auf Ethereum, wird es dafür auch einen Standard geben. Aktuell ist die im Beta-Stadium, wird aber bald auf das Main-Net released werden. Dann wird man Ether gegen Bitcoin (und beliebige andere Token) direkt auf dem dezentralisierten Exchange tauschen können.
Du hast ja schon das Fehlen des Light Wallets angesprochen. Das Herunterladen des Ethereum Wallets (Node) dauert aktuell ewig und drei Tage. Das führte sicherlich dazu, daß einige Leute Ethereum nur als Exchange-Ware wahrnahmen, was bis zum DAO Token Sale zum fallenden ETH-Kurs führte.
Unser Client hat auch einen sogenannten “fast sync”-Modus, der einen innerhalb kürzester Zeit auf den neuesten Stand bringt. Dabei lädt man nur die Blockheader herunter und ca 1.000 Blöcke vor dem aktuellen Block fängt der Client dann an, wieder alles zu verifizieren. Das ist gerade wegen des fehlenden UTX-O-Modells möglich.
Wenn man fast sync benutzt, bedeutet das allerdings auch, dass man auf Einträge, die früher angelegt wurden, aber inzwischen gelöscht sind, nicht mehr zugreifen kann. Wenn also alle “fast sync” benutzen, wäre dieser Teil der Blockchain dann gelöscht – was natürlich dem Sinn einer Blockchain widerspricht.
Wir sind nun zeitlich leider am Ende des interessanten Interviews. Irgendwelchen letzte Worte?
Zur Zeit arbeiten wir neben den oben genannten Dingen daran, den EVM-Interpreter zu beschleunigen. Neben dem technischen Aspekten reizt mich an Ethereum das Empowerment, was man jeder Nutzerin und jedem Nutzer gibt – und zwar über die Zahlung hinaus. In der Hinsicht kann jeder Interessierte Ethereum natürlich auch helfen, auch als Nicht Developer hilft man schon allein durch Tests und durch Bug Reports. Mit dem laufen lassen von Full Nodes ist man natürlich auch eine große Hilfe!
Christian, vielen Dank für dieses Interview!
BTC-Echo
