Computerisierung

Im letzten Blogeintrag haben wir uns Gedanken über den prinzipiellen Aufbau eines Unternehmens gemacht und uns die Frage gestellt, ob wir die Regeln, nach denen ein Unternehmen aufgebaut ist und betrieben werden kann, in reinen Programmiercode übertragen können? Vorab müssen wir uns hier eine Frage stellen: Wie sollen überhaupt über einen Programmcode Entscheidungen getroffen werden? Hier müssen wir zunächst Vereinfachungen vornehmen. Bei klassischen „Ursache-Wirkung-Beziehungen“ ist es einfach, einen Code zu schreiben, der bei gegebenen Variablen Berechnungen vornimmt und eine entsprechende Antwort darauf erzeugt. Die Entscheidungsfindung komplexer Probleme kann nun auf diese einzelnen kausalen Zusammenhänge heruntergebrochen und hierfür ein entsprechender Code geschrieben werden.

Die zweite Herausforderung bezieht sich auf die Ausführung des Codes: Wer ist überhaupt bereit, den Code oder die Regel, die sich dahinter verbirgt, anzuwenden? Existiert der Code nur auf einem einzelnen Rechner, so kann es zu einem Missbrauch kommen. Denn was könnte den Besitzer davon abhalten, diesen Rechner vom Netz zu trennen und somit den Code für andere unzugänglich zu machen? Oder subtiler: Was könnte den Betreffenden davon abhalten, den Code zu seinen Gunsten zu ändern? Wenn wir also eine breite Akzeptanz für Smart-Contracts schaffen wollen, so müssen wir sicherstellen, dass einzelne das System nicht kompromittieren können. „Distributed Computing“ also verteiltes Rechnen kann hier eine Lösung bieten. Damit ist allerdings nicht das gleiche Prinzip wie bei den Projekten „SETI @ home“ und „Folding @ home“ gemeint, sondern ein rein verteiltes Rechnen ohne zentralen Server. Diese Einschränkung ist sehr wichtig, da somit ein „single-point-of-failure“ eliminiert wird und der Vertrag nicht von einer einzelnen Person oder Instanz verändert werden kann.

Das Ziel hierbei muss eine Validierung der in diesem Code definierten Regeln über das hieran beteiligte Netzwerk sein. Im Bitcoin-Netzwerk beispielsweise wird dies über eine einfache Mehrheit bzw. Rechenpower erreicht. Wenn man sich nicht aktiv an der weiteren Berechnung der Blockkette beteiligt oder nicht die benötigte Rechenkapazität aufweist, erhält man auch keine Bitcoins - es sei denn, man bezahlt dafür. Bitcoin ist so konzipiert, dass ein einzelner Angreifer nicht genug Rechenleistung aufbringen kann, um diesen Mechanismus zu untergraben und somit im Wesentlichen „mit dem Strom schwimmen“ und sich am Mining der Bitcoins beteiligen muss und somit zum einen das Netzwerk am Leben erhält und zum anderen auf eine Belohnung in Form von geschürften Bitcoins hoffen darf.

Lässt sich dieses Prinzip nun ohne weiteres auch auf verteiltes Rechnen übertragen ? Die Antwort ist leider nein. Bitcoin ist ein Sonderfall, da es auf einem zwar genialen aber doch an sich sehr einfachem Prinzip aufbaut. Als zugrundeliegende Währung werden beispielsweise keine Sonderformen von Tansaktionszuständen erfasst, die z.B. bei komplexeren Verträgen notwendig werden. Nichts desto trotz brauchen wir wie bei Bitcoin auch üblich Adressen im Netz, die mit entsprechenden Vertragsteilnehmern in Verbindung gebracht werden und gesicherte Verträge, die zwischen den einzelnen Teilnehmern ausgetauscht werden können. Das Prinzip der privaten und öffentlichen Schlüssel, wie von Bitcoin verwendet, erlaubt uns hier einen entsprechenden Ansatz.

Eine Lösung, die einem in den Sinn kommen könnte, sind Multisignaturen. Hier entsteht allerdings das Problem, dass die Transaktionen schnell einen Umfang erreichen würden, der rein von der Rechenkapazität nicht mehr zu bewerkstelligen wäre. Eine andere Lösung besteht im kryptographisch gesicherten verteilten Rechnen. Die Menge an unterschiedlichen Anfragen wird hierbei über einen Algorithmus nach dem Prinzip von „Shamir´s Secret Sharing“ an die jeweiligen Clients verteilt. Hierbei wird ein Polynom mit n Wertepaaren erstellt, wobei zur eindeutigen Bestimmung und somit zur Entschlüsselung t Wertepaare ausreichend sind. Hierbei können nun bis zu t-1 Paare kompromittiert werden, ohne dass das eigentliche Geheimnis in Gefahr gerät. Erst wenn t Wertepaare bekannt sind, ist es möglich, das Geheimnis zu entschlüsseln. Dies bedeutet aber auch, dass die Clients, welche t Wertepaare bestimmt haben, die entsprechenden Daten auch kombinieren müssen, um an das Geheimnis zu gelangen. Die eigentliche Idee hinter diesem Prinzip ist also, dass jeder der Teilnehmer einen Teil des Information besitzt ohne allerdings das Gesamtbild daraus zusammensetzen zu können.

Die Laufzeit des Algorithmus ist ungefähr proportional zur dritten Potenz der Teilnehmerzahl; bei 10 Knoten wären dies dann 1000 Rechenschritte und bei 1000 Knoten 1 Milliarde Schritte. Mit Hilfe verteilen Rechnens können nun Bitcoin-Adressen erstellt und Transaktionen vorgenommen werden. Die Vorgehensweise hierbei ist vergleichsweise einfach:

1. Man erstellt einen privaten Schlüssel.

2. Der zugehörige öffentliche Schlüssel wird berechnet.

3. Der öffentliche Schlüssel wird dem Netz verraten und gleichzeitig wird der Algorithmus von „Shamir´s Secret Sharing“ verwendet, um einen neuen öffentlichen Schlüssel zu erstellen, der mit Hilfe von 501 der insgesamt 1000 veröffentlichten Schlüssel generiert werden kann.

4. Aus diesem öffentlichen Schlüssel wird nun eine Adresse generiert.

Die öffentlichen Schlüssel können nun addiert, subtrahiert, multipliziert oder auch durch ganze Zahlen geteilt werden. Würde man nun in gleicher Weise die privaten Schlüssel wie oben beschrieben erstellen, so könnte man beispielsweise Geld an die entsprechenden öffentlichen Adressen, die aus dem „501 von 1000 – Verfahren“ erstellt wurden, versenden. Dies funktioniert, weil der Algorithmus von Shamir´s Secret Sharing mit den gleichen Operatoren verwendet werden und eine entsprechende Anwendung sowohl bei den Schlüsseln als auch bei den Adressen stattfinden kann. Ob man die entsprechenden Operatoren nun vor oder nach der Konversion von öffentlich zu privaten Schlüsseln anwendet, ist hierbei egal. Diese Regeln können auch auf die entsprechenden Transaktionen angewendet werden.