Archiv IOTA Smart Contracts

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

Rechtsverträge sind nichtdeterministische 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 Digital Assets lösen.

IOTAs Smart Contracts

Das IOTA-Smart-Contract-Protocol (ISCP) wurde aus dem Qubic-Projekt abgeleitet und behält viele nützliche 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 Qubics, Assemblies, Oracles, Q-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 Digital Assets, besitzen und verschieben.

Gebühren

Update 01.11.2021: Hier wird es Änderungen geben, Colored Coins werden nicht umgesetzt, stattdessen wird es nativ Assets geben, ich warte auf weitere Infos.

IOTA-Smart-Contracts verwenden die Logik der UTXO-Digital Assets (aka Colored Coins). Um einen SC zu erstellen, muss 1 neues Digital Asset erstellt und an die Adresse des SCs gesendet werden, diese Sendetransaktion wird zur Ursprungstransaktion (Genesis) des SCs, bei diesem Vorgang fallen keine zusätzlichen Gebühren oder ähnliches an. Diese erstellte Digital Asset, welcher den SC repräsentiert, verbleibt während der Laufzeit des SCs auf der Adresse des SC, ist also Eigentum des SC. 

Um eine Anfrage an den SCs zu senden, muss ebenfalls 1 Digital Asset in dieser Anfragetransaktion erstellt und an die Adresse des SC gesendet werden, dieser Anfrage-Coin wird immer an den SC gesendet und bleibt im Eigentum des SC (auf seiner Adresse). Dieses nur temporäre Digital Asset wird wieder in der originalen IOTA-Token konvertiert, wenn der Antrag abgearbeitet (abgerechnet, bestätigt) wird und verbleibt im SC. 

Da die Ursprungstransaktion normalerweise auch eine Initialisierungsanfrage zur Erstellung eines SCs umfasst, werden mindestens 2 IOTA-Token benötigt, um einen SC zu erstellen.

Gebühren sind notwendig, sie sind ein Anreiz, um Nodes dazu zu veranlassen, den SC-Code auszuführen. Mit dieser Lösung wird nicht das gesamte Netzwerk gezwungen jeden SC-Code auszuführen (wie bei ETH), stattdessen wird nur eine relativ kleine Gruppe von Nodes speziell für die Ausführung eines bestimmten SC ausgewählt und ggf. dementsprechend belohnt.

Wenn es allerdings andere Anreize gibt, den SC-Code zu bearbeiten, ist eine Gebühr nicht erforderlich. Ein bereits ausreichender Anreiz könnte beispielsweise die Registrierung der SC-Zustandsänderungen auf dem Tangle an sich sein. Ein Beispiel dafür wäre das Aggregieren von Oracle-Rohdaten zur Weiterverarbeitung. Ein anderes Beispiel wäre, wenn ein Konsortium von konkurrierenden Akteuren einen ehrlichen Prüfpfad haben wollen, den keiner von ihnen beeinflussen kann. Ihr Anreiz, eine SC durchzuführen, wäre, alle anderen im Auge zu behalten.

Das IOTA SC Gebühren Modell:

• das Gebührenmodell ist fest im Kern-Protokoll programmiert
• Gebühren = 0 ist voreingestellt (Gebührenfrei)
• Gebühren = Validator Gebühr + Chain Besitzer Gebühr
• Unterschiedliche Chain Gebühren-Token möglich (Colored Coins), IOTA-Color-ID ist voreingestellt
• Chain Level: voreingestellte Validator und Chain-Besitzer Gebühren 
• Smart-Contract Level: Individuelle Validator und Chain-Besitzer Gebühren für einen Contract.
• Gebühren werden vom Chain-Besitzer verwaltet/festgelegt indem der root contract konsultiert wird.
• das Gebührenmodell kann durch Smart Contracts für jeden Anwendungsfall erweitert werden.
  

Bild: Volatile und unvorhersehbare Gebühren sind ein Hindernis für die Einführung von Smart Contracts. In IOTA Smart Contracts werden die Gebühren vom Eigentümer definiert, beginnen bei 0 und sind im Voraus bekannt. Es gibt keinen “Bieterkrieg” wie bei regulären Blockchains, es kann mit vorhersehbaren Geschäftsmodellen und Einnahmequellen kalkuliert werden.

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 (Erklärung folgt) 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. 

Komitees können von einer Einzelperson, einem Unternehmenskonsortium oder durch einen offenen, erlaubnisfreien Marktplatz von Validator-Nodes gebildet werden, somit sind IOTA Smart Contracts hochflexibel.

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 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)

Wasp: Ein Node für IOTA Smart Contracts

Das IOTA Smart Contract Protocol (ISCP) ist ein 2-Layer-Protokoll, das auf dem Kernprotokol aufbaut und von Goshimmer-Nodes ausgeführt wird. Die Entwicklung dieses Protokolls wird vollständig in einen separaten Nodes namens Wasp entkoppelt. Die Smart Contracts von IOTA werden also durch das Netzwerk der Wasp-Nodes betrieben, die alle mit dem Tangle verbunden sind.

Smart Contract Chain 

Smart Contracts werden über eine sogenannte Contract Chain, die Repräsentation des Contract-Zustands, abgewickelt. Ein Smart Contract schreibt seinen Status bei jeder Anfrage und bei jeder dieser Aktualisierungen des Zustands wird ein neuer Block hinzugefügt, all diese Aktualisierungen werden in einem Block gesammelt und bestätigt. Die Chain enthält also auch alle vergangenen Zustände. Die Chain kann viele Smart Contracts enthalten, die alle am gleichen globalen Zustand der Chain arbeiten. Aus dieser Perspektive betrachtet, ist die Contract Chain im Wesentlichen eine Blockchain, die auf dem Tangle verankert ist. IOTA Smart Contracts können als „klassische“ Smart Contracts betrachtet werden, aber mit dem zusätzlichen Merkmal, dass Sie mehrere solcher parallelen Chains haben können, die alle dasselbe native IOTA-Token nutzen und zwischen denen Sie auf vertrauenswürdige Weise auf dem Tangle handeln können. Dadurch wird eine vertrauenswürdige Interoperabilität zwischen verschiedenen Anwendungen ermöglicht.

Multi-Chain-Umgebung

Der Hauptunterschied von IOTA Smart Contracts zu herkömmlichen Smart Contracts (Bsp. ETH) ist die Multi-Chain-Umgebung, die durch den Tangle gesichert ist und viele reguläre Blockchains parallel ausführen kann. Die IOTA Smart-Contract-Chains laufen asynchron, daher hat die Aktivität eines Smart Contracts  keinen Einfluss auf die Geschwindigkeit und den Durchsatz der anderen.

Mit dem Alpha Release wurde eine Multi-Chain-Umgebung, welche die durch den Tangle, den “Base-Layer 1”, gesichert wird integriert: Subnetze, bestehend aus Wasp-Nodes (Komitees), können viele Blockchains parallel darauf laufen lassen, ohne den Blick auf die Tangle Umgebung zu verlieren, der die digitalen Vermögenswerte von IOTA sichert. Jede dieser Chains, die ein funktionales Äquivalent zu einer Ethereum-Blockchain darstellen, ist in der Lage, viele Smart Contracts zu hosten.

Struktur eines Smart Contracts

Der Ansatz der IOTA Foundation für Smart Contracts ist eine Abkehr von bestehenden Architekturen und beseitigt deren Ineffizienzen, wie z.B. die Unfähigkeit zur parallelen und skalierbaren Ausführung, die Unfähigkeit, “fremde” Smart Contracts auf verschiedenen virtuellen Maschinen laufen zu lassen und die Beeinträchtigung durch volatile und manchmal unerschwingliche Gebühren, um nur ein paar zu nennen.

Mit dem IOTA Smart Contracts Protokoll steht es Entwicklern und Unternehmen frei, ihre eigenen, flexiblen Umgebungen zu definieren, die ihren Anforderungen entsprechen (Smart Contract Sprachen/virtuelle Maschinen) sowie Größen von Validierungskomitees, die ihrem erforderlichen oder gewünschten Grad an Dezentralisierung und Sicherheit entsprechen. Das IOTA Smart Contract Protocol erlaubt es ihnen, eine “permissioned” Smart-Contract-Chain zu betreiben, die z.B. von einem Komitee ihrer eigenen Nodes validiert wird oder ein Komitee von Nodes unter Konsortialpartnern zu definieren. ISCP ist auch mit der Absicht gebaut, vollständig “permissionless” zu laufen, was bedeutet, dass ein Komitee von Validierern auf einem offenen Markt von Validierern ausgewählt werden kann. Alle Smart Contract Chains – ob offen oder privat – profitieren von der inhärenten Sicherheit und Interoperabilität, die durch die Verankerung jedes Smart-Contract-Zustands und ihrer Ergebnisse auf dem gebührenfreien IOTA Basis-Layer entsteht.

IOTA Smart Contracts erfordern daher nicht, dass alle Nodes im Netzwerk alle Smart Contracts ausführen, sondern erlauben eine flexiblere, sinnvolle Definition, die den Anforderungen des Smart-Contract-Besitzers entspricht. Dies wird die Kosten und den Energieaufwand drastisch reduzieren, während die Flexibilität stark erhöht wird und keine Kompromisse bei den individuellen Sicherheitsanforderungen und der von dApps geforderten Kompatibilität und Interoperabilität eingegangen werden müssen.

Gibt es eine minimale Anzahl von WASP-Nodes die miteinander verbunden sein müssen, um ein 2-Layer “Netzwerk” bilden zu können?

ISCP ist ein Multi-Chain-System mit vertrauenswürdigen Cross-Chain-Transaktionen. Jede Chain wird von einer festen (aber dynamisch anpassbaren) Anzahl von Validator-Nodes validiert, ähnlich wie bei der Binance Smart Chain (BSC). Der HoneyBadger Byzantine Fault Tolerance-Konsens erfordert 2/3+1, um ehrlich zu sein. Wenn also 30 Validator-Nodes für die Chain einsetzen, können bis zu 9 von ihnen böswillig sein oder ausfallen, ohne ein falsches Ergebnis zu produzieren. Um Gelder zu stehlen, benötigen Sie daher mindestens 21 kolludierende böswillige Nodes. Beachten Sie, dass jeder Block im Tangle verankert ist, also unveränderbar ist. Auf diese Weise wird die Dezentralisierung und Sicherheit gewährleistet. Neben den Validator-Nodes kann eine beliebige Anzahl von Access-Nodes teilnehmen. Sie werden den Benutzern einen garantiert gültigen Zustand der Chain zur Verfügung stellen.

Ethereum Virtual Machine (EVM)

IOTA Smart Contracts sind skalierbar und mehrere Smart-Contract-Chains, die von verschiedenen Virtualmachines betrieben werden und können gleichzeitig / parallel über mehrere Komitees laufen.

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.

Quellen

https://blog.iota.org/iota-smart-contracts-protocol-alpha-release/

https://www.reddit.com/r/Iota/comments/fzv1hm/an_introduction_to_iota_smart_contracts_qubics/

https://blog.iota.org/an-introduction-to-iota-smart-contracts-16ea6f247936

https://discord.iota.org/ > #smartcontracts