Smart Contracts

 

Bevor wir einen Smart Contract definieren, ist es wichtig, zunächst zu verstehen, was ein rechtlicher Vertrag ist.

Rechtsverträge sind nicht deterministische Vereinbarungen, die komplexen Rechtssystemen unterliegen. Die Gesetze zu Verträgen variieren in Abhängigkeit von einer Reihe von Faktoren, z. B. dem Land, in dem alle Parteien den Vertrag geschlossen haben. Das wichtigste Wort hier ist „nicht deterministisch“ . Dies bedeutet, dass Verträge häufig nicht eindeutig sind und ihre subjektive Auslegung zu Streitigkeiten führen kann.

 

 

Was ist ein Smart Contract (SC)?

Ein Smart Contract (dt. Intelligenter Vertrag) ist eine programmierte Vereinbarung, die vollständig deterministisch ist und automatisch durchgesetzt wird, dazu werden die vertraglichen Verpflichtungen zwischen Käufer und Verkäufer verkapselt in der Software verankert. Dies macht es unmöglich diese getroffene Vereinbarung zu bestreiten. 

Grundsätzlich wurden SCs erschaffen, um die Durchsetzung eines Vertrages durch Dritte, wie beispielsweise einer zentralen Behörde überflüssig machen. SCs ermöglichen die Durchführung vertrauenswürdiger Transaktionen, welche nachvollziehbar, transparent und nicht umkehrbar sind. Von "Experten" wird allgemein erwartet, dass diese SCs in der Zukunft verwendet werden, um viele Arten realer Papierverträge zu ersetzen. Mit diesen neuen technologischen Möglichkeiten lassen sich in vielen Branchen viele Arten von Geschäftsprozessen erheblich effizienter ausführen und Kosten reduzieren.

Ob und wie SCs in Zukunft den Weg in den Mainstream finden werden, wird die Zukunft zeigen. Denn neben den ungeklärten rechtliche Fragen versuchen derzeit 99% der bestehenden SCs, einfach einen "Token" zu erstellen, der sich auf einen bestimmten Anwendungsfall bezieht, dies könnte man bei IOTA auch mit den zweckgebundenen IOTA Colored Coins lösen.

 

 

IOTAs Smart Contracts

Das IOTA-Smart-Contract-Protocol (ISCP) wurde aus dem Qubic-Projekt abgeleitet und behalten viele seiner nützlichen Eigenschaften bei. Die neuen SCs können als ein Ableger betrachtet werden, welcher die Prioritäten zu einer pragmatischen Lösung verschiebt. Im Wesentlichen sind IOTA Smart Contracts "Quorum-based Computations" und weichen daher nicht allzu weit von der "ursprünglichen" Qubic Vision ab.

Wie von vielen Mitgliedern der Community und den Industriepartnern gefordert, sind die neuen SCs jetzt völlig losgelöst gegenüber Hardware und Berechnungsmodell. Daher ist es in Zukunft nicht so wichtig, welche Art von Prozessor (Binär, Ternär, CPU oder Datenfluss) diese Berechnungen durchführt, wichtig ist, wie eine Gruppe unabhängiger Prozessoren einen verteilten Konsens mittels Quorum-Abstimmung durchführt.

Ziel war es, eine konkrete Architektur zu spezifizieren und zu implementieren, welche QubicsAssembliesOraclesQ-Nodes und Oracle-Maschinen zusammenwirken lässt, aber ohne Qubic-Berechnungsmodell und der Programmiersprache Abra. Viele Konzepte, aus der ursprünglichen Qubic-Vision wie On-Tangle-Messaging, On-Tangle-Konsens und Q-Tangle mussten aufgeben werden, denn diese waren langsam und anfällig für alle Arten von Angriffen. Es konnten aber auch Einschränkungen gelöst werden, Qubics waren im alten Qubic-Konstrukt nicht in der Lage, Token (Gelder) zu bewegen. Mit der Einführung des UTXO-Transaktionsmodells ist dies nun möglich, damit können IOTA-SCs jetzt IOTA-Token und Colored-Token, besitzen und verschieben.

 

 

Wie funktionieren SCs bei IOTA?

IOTA SCs werden als unveränderliche Zustandsmaschinen definiert:

Zustandsmaschine: Jeder Smart Contract hat einen Zustand, der mit dem Tangle verbunden ist. Der Zustand enthält Daten wie Kontostände, Eingabebedingungen und Konsequenzen im Laufe der Zeit. Jede Zustandsaktualisierung stellt einen Zustandsübergang auf dem Tangle dar.

Unveränderlich: Der Zustand und der Programmcode des Smart Contract sind beide unveränderlich, da sie auf dem Tangle gespeichert sind. Der Zustand kann inkrementell aktualisiert werden, indem neue Transaktionen an das Tangle angehängt werden.

Das Tangle bietet einen verifizierbaren Prüfpfad der Zustandsübergänge. Dadurch kann darauf vertraut werden, dass die Zustandsübergänge gültig sind und nicht durch böswillige oder fehlerhafte Nodes korrumpiert werden können.

 

 

 

Der Nutzen von Second Layer Smart-Contracts

Um die Anwendungsfälle, einschließlich des Internet der Dinge, zu erleichtern, baut IOTA seine SCs auf dem Layer 2, "off-Tangle".

Obwohl die "on-chain" Smart Contracts von Ethereum aufgrund ihrer Eigenschaften sehr beliebt sind, haben sie einige bedeutende Nachteile. Der hervorstechendste ist, dass jeder Node für jeden SC, den es gibt, eine Kopie des Programmcodes und -status des Vertrages behalten muss. Jeder Node im Netzwerk muss genau den gleichen Code ausführen, wenn der SC ausgelöst wird.

Es gibt keine Begrenzung der Anzahl der Nodes, die diesen identischen Code ausführen müssen, nur um ein einziges Ergebnis zu erzeugen. Und je größer das Netzwerk wird, desto mehr Verarbeitung ist erforderlich, um dasselbe Ergebnis zu erzielen. Dies stellt ein enormes Hindernis für die Skalierbarkeit dar.

Zusätzlich zu den Transaktionsgebühren, die Sie zahlen müssen, um für die Aufnahme in das Ledger in Betracht gezogen zu werden, müssen Sie auch Gasgebühren zahlen, um das Programm lange genug laufen zu lassen, damit es abgeschlossen werden kann. Das bedeutet, dass die Kosten für den Betrieb dieser SCs unerschwinglich hoch werden, wenn man von bestimmten Anwendungsfällen absieht, in denen der Kostenaufwand relativ unbedeutend ist.

Aus diesem Grund werden IOTA SCs nicht als Teil des Kernprotokolls implementiert, sondern als ein Second-Layer-Protokoll.

Infolgedessen bieten IOTA SCs eine natürlichere Art und Weise, verteilte Berechnungen auszuführen. Jeder Smart-Contract kann in einem lokalisierten Kontext ausgeführt werden, ohne dass das gesamte Netzwerk zur Ausführung gezwungen wird. Dies bedeutet auch, dass IOTA SCs in Zukunft nicht zu einem Hindernis für die Skalierung des IOTA-Netzwerks mit Sharding-Lösungen werden.

 

 

 

Durchführung 

Die Durchführung eines SCs wird von einem Komitee von Nodes fester Größe (mit verteilter gemeinsamer Nutzung privater Schlüssel) durchgeführt, welche ein Programm im Konsens durchführen und die Ergebnisse an den Tangle senden. Die feste Größe wird von dem Eigentümer (Aussteller u. Betreiber) des SCs festgelegt, für die Schwellenwert-Kryptographie sind Hunderte noch eine praktische Größe, dass Minimum ist 1 Node, was bedeutet, dass es nur ein zentralisiertes Skript ist, welches SC-Anfragen verarbeitet. Komitee-Nodes werden durch ihre Adressen im Netzwerk identifiziert, die nur dem Eigentümer, anderen Komitee-Nodes und auch anderen vertrauenswürdigen (sogenannten Access-)Nodes bekannt sind.

 

 

 

Eigentümer eines Smart Contracts

Jeder Smart-Vertrag hat einen Eigentümer, er ist verantwortlich für:

  • Die Erstellung des SC-Programm und beim Netzwerk einzureichen.
  • Festlegung der Größe des Komitees (die Zahl N) und die Auswahl der Nodes, die Teil des Komitees sein sollen.
  • Entscheidung, wie viele Komitee-Nodes einen Konsens über Aktualisierungen des SC-Status erreichen müssen. Diese Zahl wird als Quorum bezeichnet.
  • Festlegung anderer allgemeiner Konfigurationsparameter des SCs.

Ein Eigentümer kann eine einzelne Einheit sein, z. B. eine Organisation oder eine Person, oder es kann sich um eine dezentralisierte Sammlung von Peers handeln, z. B. ein Konsortium von Organisationen. In jedem Fall verwaltet der Eigner nur die Einrichtung und Konfiguration des SCs und nimmt nicht an dessen Betrieb teil.

Der Eigentümer kann je nach Kontext und Zweck wählen, wie SCs eingerichtet werden sollen. Beispielsweise kann ein SC, der hochwertige Transaktionen abwickelt, ein großes Komitee von Nodes erfordern. Während ein SC, der Mikrotransaktionen abwickelt, unter Umständen nur 20-30 Nodes im Komitee benötigt.

 

 

 

Motivationen: Belohnungen und Reputation

Es gibt viele mögliche Gründe, einen SC zu erstellen oder zu betreiben. Ein Grund ist die Belohnung. Obwohl IOTA-Transaktionen gebührenfrei sind, bieten IOTA-SCs den Unternehmen die Möglichkeit, eine Gebühr in IOTA-Tokens zu verlangen, z.B. zur Deckung der Betriebskosten. Wir nennen diese Gebühr eine Belohnung.

Sowohl Eigentümer als auch Komitee-Nodes können SC Belohnungen erhalten. Es ist Sache des Eigentümers, mit den Betreibern von Komitee-Nodes zu verhandeln, um die minimal akzeptable Belohnung festzulegen.

  • Komitee-Nodes können Belohnungen erhalten, indem sie einen bestimmten SC bearbeiten, der eine Belohnung anbietet.
  • Eigentümer haben auch die Möglichkeit, Smart Contracts zu erstellen, die dem Eigentümer einen Prozentsatz der Belohnung zukommen lassen.

Eine weitere potenzielle Motivation für die Mitgliedschaft in einem Komitee ist der Aufbau eines guten Rufs. Kluge Vertragsinhaber können sich dafür entscheiden, Komitees nur aus Nodes mit einem guten Ruf zu bilden. Diese Art von Reputationssystem könnte einen offenen Markt für Komitee-Nodes schaffen, welcher gutes Verhalten im Netzwerk fördert.

 

 

 

Das Smart Contract Programm

Ein SC-Programm ist ein Algorithmus, der Anweisungen für eine virtuelle Maschine (VM) enthält. IOTA verwendet WebAssembly (WASM) als Haupt-VM für IOTA SC. Aber im Allgemeinen kann die VM in jeder Sprache oder sogar fest in der Software des Nodes programmiert sein.

Das Programm nimmt zwei Transaktionen als Input: die Anfragetransaktion und die Transaktion des aktuellen Zustands. Die Transaktion des nächsten Zustands bezieht sich immer auf die Anfragetransaktion und die Transaktion des vorherigen Zustands. Auf diese Weise verfügt das SC-Programm über eine deterministische Methode zum Aufbau einer Kette von Zustandsaktualisierungen, die durch eingehende Anfragen ausgelöst werden.

Der Hash des Programms wird im Tangle gespeichert und ist daher unveränderlich.

(Hinweis: IOTA Smart-Contracts werden durch eine Transaktion und nicht durch ein Bundel definiert, da sie im Post-Coordicid IOTA-Protokoll implementieren werden, welches ein UTXO-Modell für Werttransaktionen verwendet.)

 

 

 

Ein Beispiel für ein intelligentes Vertragsprogramm

Es folgt eine kurze Beschreibung des FairRoulette SCs, welcher bei internen Tests bei IOTA verwendet wird:

Betrachten Sie einen SC, der Wetten auf ein Rouletterad annimmt. Der Smart Contract würde in seinem Konto gestapelte IOTA-Token sowie Daten über jede platzierte Wette (Summe, Farbe, Spieler) enthalten. Letzteres wird für Auszahlungen an die Gewinner von Roulette-Spielen benötigt.

Um eine Wette zu platzieren, senden Sie eine Antragstransaktion an den Smart-Contract. Die Transaktion würde enthalten:

  • Eine Gebührenzahlung von IOTA-Token für die Bearbeitungskosten
  • Eine Einzahlung von IOTA-Token, die Sie setzen möchten
  • Die Farbe, auf die Sie wetten

Wenn die Komitee-Nodes dann diese Transaktion sehen, werden sie das Programm des SCs ausführen, um den Zustand mit Ihrer Wette zu aktualisieren. Die Auszahlung an die Gewinner wird nach Spielende automatisch gemäß dem Programm des SCS ausgeführt.

 

Es gibt zudem viele Möglichkeiten, wie SCs zusammen mit anderen SCs durchgeführt werden können. Beispielsweise können sich mehrere SCs dasselbe Programm teilen, aber auf verschiedenen Adressen/Komitees laufen, wenn sie zusammen automatisch angefordert werden, würde diese Konfiguration eine redundante Verarbeitungsgruppe von doppelten SCs bilden. Es können aber auch mehrere SCs mit unterschiedlichen Programmen auf derselben Adresse (=gleiches Komitee) laufen, oder dass ein SC einen weiteren SC hervorbringt und so weiter.

 

 

 

Das Komitee und das Quorum

Die Kontoadresse des Smart-Vertrags ist Eigentum des Komitees, diese Adresse enthält die hinterlegten IOTA-Token. Nur ein Quorum von Komitee-Nodes ist in der Lage, Tokens von der Adresse weg zu transferieren. Mit anderen Worten, ein Quorum von Komitee-Nodes muss zusammenarbeiten, um die IOTA-Token vom Konto zu transferieren.

IOTA verwendet das Boneh-Lynn-Shacham Schwellenwert-Signaturschema (BLS) für Multisignatur-Adressen, um den Nodes im Komitee gleiche Eigentumsrechte an der Adresse einzuräumen. Diese Adressen ermöglichen Schwellenwertsignaturen, was bedeutet, dass eine bestimmte Anzahl von Nodes im Komitee, das Quorum, dieselbe Transaktion mit ihrem geheimen Schlüssel unterzeichnen muss.

Jeder Node im Komitee besitzt einen geheimen Anteil am Schlüssel und nur gemeinsam durch das Quorum-Konsensus-Verfahren (normalerweise 2/3 plus 1), kann eine gültige Signatur erzeugt, der Zustand des SCs aktualisiert und Gelder bewegt werden, die durch den SC kontrolliert werden.

Anders ausgedrückt bedeutet dies, dass Signaturen für Transaktionen ohne Kenntnis des Master-Key (Seed) durch Zusammenarbeit zwischen den Nodes erstellt werden. Die dafür benötigte Seed-Verwaltung wird mittels des BLS umgesetzt. Der Seed für den Geldwerttransfer befindet sich aufgeteilt zwischen den Komitee-Nodes, denn so etwas wie "den Seed" gibt es nicht, stattdessen gibt es viele Private-Keys, die zusammen die Adresse kontrollieren. Jeder Private-Key ist in der Registry des Nodes versteckt und niemandem sonst bekannt. Zusammen stellen diese Private-Keys einen Master-Private-Key dar, einen virtuellen, weil er niemandem einschließlich der Nodes bekannt ist. Die SC Konto-Adresse wird durch diesen Private-Master-Key gesteuert. 

 

 

 

Wie SCs erstellt werden

Der Eigentümer eines SCs erstellt das Programm, und sein Binärcode wird in Komitee-Node gespeichert. Der Hash des Programms ist durch den Zustand- der Transaktion immer zugänglich, so dass der SC unveränderlich ist.

Der Eigentümer setzt ein Komitee von Nodes ein, die für die Ausführung des Programms, das Abhören des Tangle für Anfragetransaktionen und die kollektive Aktualisierung des Zustands des SCs verantwortlich sind.

Während der Einsetzung des Komitees bestimmt der Eigentümer die Größe des Komitees und das Quorum und initialisiert einen Prozess der verteilten Schlüsselgenerierung (Distributed Key Generation, DKG) zwischen den Komitee-Nodes. Dieser Prozess erzeugt:

  • Eine durch den SC kontrollierte Kontoadresse.
  • Einen privaten Schlüssel für jeden Komitee-Node (weder dem Eigentümer noch anderen Komitee-Nodes bekannt).

Dieser Prozess kann entweder zentralisiert oder dezentralisiert sein. In der zentralisierten Version kann der Eigentümer bei Bedarf einen Generalschlüssel verwenden, um Komiteebeschlüsse außer Kraft zu setzen. In der dezentralisierten Version kann der Verantwortliche Entscheidungen nicht außer Kraft setzen.

 

 

 

Wie der Status eines Smart Contract aktualisiert wird

Die Komitee-Nodes hören immer auf das Tangle, wenn es um Anfragetransaktionen geht, die an den SC geschickt werden sollen.

Wenn ein Komitee-Node eine Transaktion entdeckt, berechnet er den nächsten Zustand, indem er das SC-Programm ausführt. Auf diese Weise werden ehrliche und synchronisierte Nodes immer genau die gleiche Zustandsaktualisierungstransaktion erzeugen. Komitee-Nodes tauschen nie echte Ergebnisse aus, sondern nur Hashes. Es besteht also kein Risiko, dass Nodes die Ergebnisse der anderen kopieren, um zu versuchen, die Belohnung einzuspielen.

Wenn sich die Nodes nicht über den aktualisierten Zustand einigen, wird jeder eine andere Transaktion unterschreiben, was zu einer ungültigen Unterschrift führt. Die Nodes müssen daher einen mehrheitlichen Konsens über den aktualisierten Zustand erreichen.

In der asynchronen Einstellung des Tangle kann jeder Komitee-Node einen anderen Zustand sehen, je nach seiner lokalen Uhr oder seinen Nachbarn. Komitee-Nodes müssen daher einen verteilten Konsensalgorithmus ausführen, um einen Konsens über das Ergebnis zu erzielen. Das Ergebnis des Konsenses ist ein Hash des Ergebniskerns, eine Sammlung von Teilunterschriften des BLS und ein Zeitstempel. Alle SC-Transaktionen werden mit einem Zeitstempel versehen, und der Zeitstempel stimmt mit den lokalen Uhren der meisten Nodes überein.

Wenn alle Nodes einen Konsens erreicht haben, sammelt ein Komiteemitglied, der Leiter, alle Teil-BLS-Signaturen der Nodes, bevor die endgültige Transaktion an das Tangle übermittelt wird. Diese Transaktion muss sich auf den vorherigen Zustand beziehen, um eine Kette von Zustandsaktualisierungen zu erstellen, die als Prüfpfad dient. Wenn die Transaktion bestätigt wird, wird sie zum neuen Zustand des Smart Contract.

 

 

 

Vertrauen, Dezentralität, Datensicherheit, Mana, Ratenkontrollsystem

Jeder Akteur sollte wissen, dass es kein 100%iges Vertrauen gibt, weder in der Kryptographie noch sonst wo, es gibt immer nur ein gewisses, nachvollziehbares Ausmaß an Dezentralisierung und Vertrauen. Grundsätzlich sollte der Eigentümer des SC/Komitee, wie jeder andere Teilnehmer auch, dem Komitee als Ganzem vertrauen, nicht jedem einzelnen Teil. Genau wie in einer Blockchain vertraut man dem Ganzen und nicht jedem einzelnen Node. 

Die neuen IOTA-SCs ermöglichen es zudem, dass nur eine ausgewählte Interessensgemeinschaft untereinander „Vertrauensvoll“ SC-Transaktionen durchführen können. Diese erforderliche Node-Auswahl für das Komitee liegt derzeit außerhalb des Anwendungsbereichs des IOTA Protokolls, der SC-Eigentümer, der das Komitee erstellt, ist derjenige, der zu entscheiden hat, welchen Nodes er vertraut. Für einen SC, der von einem Unternehmen erstellt und betrieben wird, können dies ihre eigener Node sein, oder falls mehr Vertrauen erforderlich ist, könnte ein Konsortium jeweils einen Node zur Verfügung stellen. Beispielsweise könnten Konsortien einen SC betreiben, um bei logistischen Transaktionen eine gemeinsame Sichtweise zu haben, oder bei einem nur von verschiedenen Banken betriebenen SC würde den korrekten Ablauf der Transaktionen enorm erhöhen (kaum Konflikte).

Eine maximale Dezentralisierung ist auch nicht immer notwendig, z.B. weil eine Organisation vielleicht ein Komitee einrichten möchte, nur um eine fehlertolerante Konfiguration zu haben, beispielsweise für ein Sensor-Oracle auf dem eigenen Firmengelände.

Die Frage nach der Sicherheit der Daten lässt sich nicht allgemein beantworten, denn die Größe des Komitees beeinflusst die Aussagekraft der resultierenden Daten, valide Daten von 100 Komitee-Nodes haben natürlich eine höhere Aussagekraft, als wenn nur 3 Komitee-Nodes am Quorum teilnehmen. Die Anzahl der Komitee-Nodes wird von dem Eigentümer des SCs festgelegt, er könnte sich daher auch entscheiden nur das Minimum von 1 Node vorzuschreiben, was bedeutet, dass er nun ein zentralisiertes Skript hat, welches SC-Anfragen verarbeitet. Es bleibt daher dem Eigentümer des SCs überlassen, welche Sicherheit er für seinen Anwendungsfall benötigt, beispielsweise könnte man bei einem internen Anwendungsfall, welcher nur im eigenen Unternehmen ausgeführt wird, zugunsten einer schnellen Durchführung des SCs auf eine sehr hohe Sicherheit verzichteten und nur eigene interne Komitee-Nodes zulassen.

Die Komitee-Nodes werden für SCs kein Mana verwenden, ein Komitee gilt als zugelassen (engl. permissioned), so dass es keinen Bedarf für einen Sybil-Schutz wie Mana gibt.

Laut dem SC Entwickler Evaldas besteht aber in Zukunft durchaus die Möglichkeit, dass das SC-Netzwerk irgendwann ein eigenes Reputationssystem und sogar ein Ratenkontrollsystem benötigen wird. Dieses Reputationssystem könnte als eine Reihe von SCs implementiert werden, während die Ratenkontrolle auf dem Gebührenverhalten der SC und der Node-Betreiber basieren muss. Andernfalls ist es einfach, eine SC einzurichten, die endlos Anfragen an sich selbst sendet und so das Netzwerk mit nutzlosen Spamm-Transaktionen überflutet. Das liegt an der gebührenfreien Natur von IOTA und es ist derzeit noch nicht geklärt, wie man dies verhindert, aus diesem Grund hält Evaldas eine gebührenfrei SC-Transaktionen aufgrund von Spamm-Angriffen für eine schlechte Idee. Daher wird IOTA vorerst wie oben beschrieben ein Schutzmechanismus hart-codieren, der "Eigentümer" des SC sollte dem Node-Betreiber bekannt sein und von ihm anerkannt werden, zudem müssen beide rechenschaftspflichtig sein und die richtigen Anreize erhalten. (Komitee und Belohnungen)

 


 

Update Mai'20

Wasp: Ein Node für IOTA Smart Contracts

Das IOTA Smart Contract Protocol (ISCP) ist ein 2-Layer-Protokoll, das auf dem Kernprotokoll Value Tangle aufbaut und von Goshimmer-Nodes ausgeführt wird. Die Entwicklung dieses Protokolls wird vollständig in einen separaten Nodes namens Wasp entkoppelt. Wasp wird sich mit GoShimmer-Nodes verbinden, um Zugriff auf das Value Tangle zu erhalten.

 



Schlussfolgerung

IOTA SCs sind intelligente Vertragsprogramme, die von einem genehmigten Komitee auf dem zweiten Layer (Off-Tangle) ausgeführt werden. Das Komitee der Nodes aktualisiert das Ledger kollektiv, indem er unterzeichnete Transaktionen (unter Verwendung von Schwellenwertunterschriften) an das Tangle einreicht.

IOTA SCs sind sehr flexibel und benötigen viel weniger Ressourcen als die Blockchain-Alternativen. Sie ermöglichen Anwendungsfälle, die mit Gebühren als einzigem Anreiz nicht möglich gewesen wären. Dies gilt insbesondere im Bereich des IoT, wo Mikroverträge und Mikrotransaktionen die Norm sein dürften.

In der ersten SC Version wird IOTA zunächst WebAssembly verwenden, in Zukunft wird dies nicht die einzige virtuelle Maschine (VM) bleiben, daher werden auch andere Programmiersprachen und VMs verwendet werden können.

 

 

Rechtsfragen

Generell gibt noch es viele offene Rechtsfragen und dementsprechende Einschränkungen bei allen SCs.

Smart-Contracts sind Computerprogramme und beruhen auf einfache Wenn-Dann-Befehle, sie sind keine unmittelbaren Verträge im zivilrechtlichen Sinne (§ 158 BGB). Dies bedeutet, dass der SC nicht der Vertrag selbst ist, Sie dienen nur der Durchsetzung des Vertrags. Angebot und Annahme, also der Vertragsschluss selbst, erfolgen außerhalb der Blockchain / Tangle. Beispielsweise kann in einem Kaufvertrag über einen Gegenstand per SC hinterlegt werden, dass der Käufer den Gegenstand erst erhält, wenn er den Kaufpreis bezahlt hat.

SC eignen sich (noch) nicht dazu, komplette kompliziertere Verträge, welche oft einen Graubereich beinhalten abzuwickeln. Heutige Verträge sind auf Anpassungsfähigkeit ausgelegt und setzen eine Wertung im Einzelfall voraus, die ein SC-Code nicht vornehmen kann. Zudem fehlen für spezielle Verträge wie für einen Immobilen Kauf die im Gesetz vorgeschriebenen Aufklärungs-, Beratungs- und ggf. Warnfunktion einer dritten Instanz (Bsp. Notar). Diese können nicht durch automatisierte Prozesse ersetzt werden, sodass diese Beratung außerhalb der Blockchain stattfinden muss.

 

Weitere Probleme sind:

  • Datenschutz, beispielsweise die Einwilligung in die Datenverarbeitung und die Rücknahme dieser.
  • Recht auf die Löschung der Privaten Daten (Recht auf Vergessenwerden).
  • Rückabwicklung von Verträgen nach gerichtlicher Anordnung.
  • Jedes Land hat unterschiedliche Gesetzte
  • Es gibt noch etliche weitere Punkte, weitere Details siehe Blockchain und Recht im Kontext von Industrie 4.0

 

Rechtlich gesehen stehen SCs auf sehr wackligen Füßen, einen einheitlichen und zudem Internationalen Lösungsansatz für diese Probleme gibt es noch nicht. SCs lassen sich derzeit wohl am ehesten mit den sogenannte "Button-Verträgen" vergleichen, diese regeln den Verkauf im Internet. Erst mit dem Klick auf den Kauf-Button kommt zwischen Verkäufer und Käufer ein Vertrag mir den innewohnenden Rechten und Pflichten zustande. 

 

 


Smart Contract - IOTA vs. Ethereum

Bis auf das Schlagwort "Smart-Contract" haben diese beiden Ansätze nicht viel gemeinsam.

 

 

Bei Ethereum, sind SCs Teil des Kernprotokolls, sie werden auf dem Baselayer ("On-chain") durchgeführt. Dies bedeutet, dass sie von allen Nodes im Netzwerk ausgeführt und validiert werden.

Vorteile

  • Die Sicherheit intelligenter Verträge ist proportional zur Größe des Netzwerks
  • Intelligente Verträge können Token ohne Unterschrift von ihrem Konto übertragen

Nachteile

  • Intelligente Verträge lassen sich schlecht skalieren, da ihre Programme von allen Nodes ausgeführt werden müssen
  • Für SCs fallen Netzwerk-Transaktionsgebühren an, die ebenso volatil sind wie der zugrunde liegende Token-Preis, bei einer starken Auslastung des Netzwerks, steigen die Kosten sehr stark an, Mikro-Transaktionen sind unmöglich.
  • Die durchschnittlichen Kosten einer Smart-Contract-Transaktion sind in etwa proportional zum zugrunde liegenden Token-Preis

 

 

Bei IOTA, sind SCs eine Second Layer Protokoll ("Off-Chain") und wird außerhalb des Kernprotokolls ausgeführt. Nur eine Teilmenge von Nodes, die als Komitee bezeichnet wird, muss sie ausführen. Dies bedeutet, dass außerhalb des Kernprotokolls ein Konsens erzielt werden kann.

Vorteile

  • Intelligente Verträge belasten den Rest des Netzwerks nicht. Daher sollte eine beliebte Anwendung (a la "Crypto Kitties") auf IOTA die Leistung einer anderen Anwendung oder von Aktivitäten auf dem Base-Layer nicht beeinträchtigen.
  • Die durchschnittlichen Kosten einer intelligenten Vertragstransaktion sind niedrig und vorhersehbar, Anwendungsfälle über Mikro-Transaktionen werden ermöglicht.
  • Der erforderliche Grad an Dezentralisierung (und damit Sicherheit) eines intelligenten Vertrags kann an jeden Anwendungsfall angepasst werden.

Nachteile

  • Um Token zu übertragen, müssen SCs Programme Transaktionen signieren, um nachzuweisen, dass sie Zugriff auf die Kontoadresse haben
  • Die Dezentralisierung (und damit die Sicherheit) intelligenter Verträge hängt von der Größe des Komitees, der Mitglieder des Komitees und der Stelle ab, die das Komitee einrichtet

 

 

 

 

Schlussfolgerung

Wer möchte denn in Zukunft sein Business auf eine Technologie aufbauen, welche keine berechenbare Transaktionskosten garantieren kann?

Beispiel: Jedes ETH-Oracle muss für die Veröffentlichung seiner Bewertungen Gebühren aufwenden, anschließend lesen die Miner diese Bewertungen bei der Durchführung des SC aus der Blockchain aus, bewerten ihre Konsistenz und setzen die daraus folgende Aktion um. Die Kosten und der Zeitaufwand für die Durchführung dieser Operation mit beispielsweise 100 Oracle, sind sicherlich sehr hoch. Aufgrund der volatilen Kosten und des volatilen Zeitaufwandes für das Mining, kann beides nie genau beziffert werden, weil Kosten und Zeit voneinander abhängen, höhere Gebühren bedeuten schnelleres Mining.

Ein ähnlicher Prozess, der bei der IOTA durchgeführt wird, hat viel geringere Kosten, da das Schreiben von Transaktionen in den Tangle nicht durch Gebühren belastet wird, auch der Zeitaufwand von allen 100 Nodes, die die SC durchführen ist viel geringer, weil parallel in den Tangle geschrieben werden kann.

 

Die hohe Flexibilität der IOTA SCs hat auch Nachteile, wer große Geldbeträge für einen langen Zeitraum in einem Vertrag sperren will, der ist mit den ETH-SCs derzeit deutlich sicherer, denn man kann sich darauf verlassen, dass das gesamte Netzwerk noch einer längeren Zeit noch da ist, um sie weiter zu bearbeiten.  Dies ist bei IOTA weniger sicher, denn die Komitees haben eine begrenzten Größe und das diese nach einem langen Zeitraum immer noch da sind, ist weniger sicher.  Für diese Anwendungsfälle müsste/könnte ein SC von Fall zu Fall andere Notfallpläne aufstellen.

Bei IOTA basiert die Sicherheit von Komitees auf anderen spieltheoretischen Prinzipien im Vergleich zu einem Layer 1 Ledger wie ETH.  In der Blockchain ist es ein globales Konsensgleichgewicht, das von gierigen Minern aufrechterhalten wird, bei IOTA sind es die kooperativen Verhaltensprinzipien des Tangle-Konsensus. Die Sicherheit des Komitees sollte auf verschiedenen Prinzipien basieren, und diese Prinzipien hängen vom Anwendungsfall ab. Die Sicherheit funktioniert ähnlich wie Gemeinschaften in der menschlichen Gesellschaft funktionieren, wie sich Vertrauenshierarchien in der Gesellschaft bilden, wobei die Motive der Akteure von Fall zu Fall bekannt sein müssen. Wenn wir einen Vorstand auswählen, um eine Organisation oder eine Jury vor Gericht zu leiten, dann tun wir das nicht durch blinde Zufallsauswahl, sondern indem wir prüfen, wer die Mitglieder sind: ihr historischer Ruf, mögliche Verbindungen und Interessenkonflikte, was auf dem Spiel steht und so weiter.

 

 

 

Zuletzt bearbeitet 07.05.2020