Incomplete Contracts (and Scaling Crypto)

By Dennis Schlegel

Jul 28

Ein interessanter Weg über Blockchain-Projekte nachzudenken ist durch die Brille der ökonomischen Kontrakt-Theorie. In dieser können Verträge in vollständige und unvollständige unterteilt werden. Vollständige Verträge spezifizieren jede mögliche legale Konsequenz verschiedenster Ereignisse. Damit sind so gut wie alle bis auf die simpelsten Verträge unvollständig. Vertragliche Vereinbarungen können nicht jedes mögliche Ereignis antizipieren oder Aktion definieren, insbesondere in einer komplexen und dynamischen Vertrags-Umwelt, die sich stetig weiterentwickelt. Jesse Walden von der Venture Capital Firma a16z geht in seinem Artikel näher auf das Thema ein.

 

Sind Verträge unvollständig sind sie auf Neuverhandlungen angewiesen, wenn unvorhergesehene Ereignisse eintreten, wie z.B. Insolvenz, Regulierung oder kleinste Detailänderungen. Solche Eventualitäten erfordern meist eine Dritte Partei, wie ein funktionierendes Rechtssystems, die in der Interpretation und Mediation unterstützt, was aber auch zu unvorhersehbaren Ergebnissen führen kann.

 

Unter der Annahme, dass Verträge einer grundlegenden Entscheidungslogik folgen, ähnlich wie Computer-Programme, bietet uns die Kontrakt-Theorie ein Rahmenwerk, um verschiedene Arten von Blockchain-basierten Projekten und Smart Contracts zu klassifizieren, insbesondere in Hinsicht des Skalierungspotentials dieser. Als Gedankenexperiment können wir diese in vollständige und unvollständige Projekte trennen.

 

Vollständige Projekte versuchen ein System Ende-zu-Ende zu spezifizieren, die Notwendigkeit der subjektiven Interpretation, Neuverhandlungen und externe Governance auf ein Minimum zu reduzieren. In Software Terminologie ist das Ziel dieser Systeme „Correct by Construction“ zu sein. Bitcoin’s Proof-of-Work Mining als auch autonome Software Applikationen auf Ethereum, wie z.B. Uniswap, können als solche Systeme verstanden werden. In beiden dieser Beispiele korreliert die Vollständigkeit des Systems mit dem Grad der Automatisierung. Ein System, das vollständig spezifiziert ist kann automatisiert und ohne Intervention betrieben werden. Nick Szabo bezeichnete diese Typen automatisierter Systeme als sozial skalierbar, weil ihre Koordinationsmechanismen Konsistenz garantieren und sich mit dem Eintreten neuer Netzwerkteilnehmern selbst verstärken. Durch die Minimierung externer menschlicher Interpretationen kann Koordinationskomplexität reduziert werden, was dem System die Skalierung unter Zugang weiterer Teilnehmer erlaubt.

 

Projekte, die innerhalb des Bereichs vollständiger Verträge existieren sind in ihrem Design Space allerdings limitiert. Dies ist darauf zurückzuführen, dass Skalierbarkeit durch Automatisierung auf Arbeit (Funktionen) beschränkt ist, die durch Computer deterministisch verifiziert werden können. Diese Funktionen benötigen typischerweise Inputs für eine Entscheidung, die numerisch, quantifizierbar oder auf andere Weise Maschinen-lesbar sind. Unvollständige Projekte dagegen benötigen zusätzlichen subjektiven Input, welcher nur schwierig automatisiert werden kann. MakerDao ist ein Beispiel für ein System, das größtenteils vollständig, aber in einigen kritischen Funktionen unvollständig ist. Abstimmungen unter den Haltern des MKR Tokens zur Stabilitätsgebühr und zum Kollateral-Ratio füllen diese subjektiven Koordinationsmechanismen. Unvollständige Projekte benötigen also andere, zusätzliche Mechanismen, um soziale Skalierbarkeit zu erreichen.

>