Smart Contract Showdown: Hyperledger Fabric gegen MultiChain gegen Ethereum gegen Corda

Es gibt mehr als eine Möglichkeit, Code in eine Blockchain einzufügen

In den meisten Diskussionen über Blockchains dauert es nicht lange, bis der Begriff „intelligente Verträge“ auftaucht. In der gängigen Vorstellung automatisieren intelligente Verträge die Ausführung von Interaktionen zwischen Parteien, ohne dass ein vertrauenswürdiger Vermittler erforderlich ist. Indem sie Rechtsbeziehungen eher in Code als in Worten ausdrücken, versprechen sie, dass Transaktionen direkt und fehlerfrei stattfinden können, ob absichtlich oder nicht.

Aus technischer Sicht ist ein Smart Contract etwas Spezifischeres: Computercode, der auf einer Blockchain lebt und die Regeln für die Transaktionen dieser Kette definiert. Diese Beschreibung klingt einfach genug, aber dahinter verbirgt sich eine große Variation darin, wie diese Regeln ausgedrückt, ausgeführt und validiert werden. Bei der Auswahl einer Blockchain-Plattform für eine neue Anwendung stellt sich die Frage „Unterstützt diese Plattform Smart Contracts?“ ist nicht der richtige zu fragen. Stattdessen müssen wir uns fragen: „Welche Art von Smart Contracts unterstützt diese Plattform?“

In diesem Artikel möchte ich einige der Hauptunterschiede zwischen intelligenten Vertragsansätzen und den damit verbundenen Kompromissen untersuchen. Ich werde mir dazu vier beliebte Blockchain-Plattformen für Unternehmen ansehen, die eine Form von angepasstem On-Chain-Code unterstützen. Erstens IBMs Hyperledger Stoff, die ihre Verträge "Kettencode" nennt. Zweitens unsere MultiChain-Plattform, die vorstellt intelligente Filter in Version 2.0. Dritte, Ethereum (und es ist erlaubt Quorum und Bau Ausgründungen), die den Namen „Smart Contract“ populär machten. Und schlussendlich, R3 Corda, die in ihren Transaktionen auf „Verträge“ verweist. Trotz all der unterschiedlichen Terminologie beziehen sich letztendlich alle auf dasselbe - anwendungsspezifischen Code, der die Regeln einer Kette definiert.

Bevor ich fortfahre, sollte ich den Leser warnen, dass ein Großteil der folgenden Inhalte technischer Natur ist und eine gewisse Vertrautheit mit allgemeinen Programmier- und Datenbankkonzepten voraussetzt. Ob gut oder schlecht, dies kann nicht vermieden werden - ohne auf die Details einzugehen, ist es unmöglich, eine fundierte Entscheidung darüber zu treffen, ob eine Blockchain für ein bestimmtes Projekt und (wenn ja) die richtige Art von Blockchain verwendet werden soll.

Blockchain-Grundlagen

Beginnen wir mit einem Kontext. Stellen Sie sich eine Anwendung vor, die von mehreren Organisationen gemeinsam genutzt wird und auf einer zugrunde liegenden Datenbank basiert. In einer traditionellen zentralisierten Architektur wird diese Datenbank von einer einzigen Partei gehostet und verwaltet, der alle Teilnehmer vertrauen, auch wenn sie sich nicht vertrauen. Transaktionen, die die Datenbank ändern, werden nur von Anwendungen auf den Systemen dieser zentralen Partei initiiert, häufig als Antwort auf von den Teilnehmern empfangene Nachrichten. Die Datenbank macht einfach das, was sie gesagt hat, weil der Anwendung implizit vertraut wird, dass sie nur sinnvolle Transaktionen sendet.

Blockchains bieten eine alternative Möglichkeit zum Verwalten einer gemeinsam genutzten Datenbank ohne einen vertrauenswürdigen Vermittler. In einer Blockchain führt jeder Teilnehmer einen „Knoten“ aus, der eine Kopie der Datenbank enthält, und verarbeitet unabhängig die Transaktionen, die diese ändern. Die Teilnehmer werden anhand öffentlicher Schlüssel oder „Adressen“ identifiziert, von denen jeder einen entsprechenden privaten Schlüssel hat, der nur dem Identitätsinhaber bekannt ist. Während Transaktionen von jedem Knoten erstellt werden können, werden sie vom privaten Schlüssel ihres Initiators „digital signiert“, um ihre Herkunft zu beweisen.

Knoten werden auf Peer-to-Peer-Weise miteinander verbunden, wodurch Transaktionen und die „Blöcke“, in denen sie mit einem Zeitstempel versehen und im Netzwerk bestätigt werden, schnell weitergegeben werden. Die Blockchain selbst ist buchstäblich eine Kette dieser Blöcke, die ein geordnetes Protokoll jeder historischen Transaktion bildet. Ein „Konsensalgorithmus“ wird verwendet, um sicherzustellen, dass alle Knoten eine Einigung über den Inhalt der Blockchain erzielen, ohne dass eine zentrale Steuerung erforderlich ist. (Beachten Sie, dass einige dieser Beschreibungen nicht für Corda gelten, in dem jeder Knoten nur eine Teilkopie der Datenbank hat und es keine globale Blockchain gibt. Wir werden später mehr darüber sprechen.)

Grundsätzlich kann jede gemeinsam genutzte Datenbankanwendung mithilfe einer Blockchain im Kern erstellt werden. Dies schafft jedoch eine Reihe technischer Herausforderungen, die in einem zentralisierten Szenario nicht existieren:

• Transaktionsregeln. Wenn ein Teilnehmer die Datenbank direkt ändern kann, wie stellen wir sicher, dass er die Regeln der Anwendung befolgt? Was hindert einen Benutzer daran, den Inhalt der Datenbank auf eigennützige Weise zu beschädigen?
• Determinismus. Sobald diese Regeln definiert sind, werden sie von mehreren Knoten mehrfach angewendet, wenn Transaktionen für ihre eigene Kopie der Datenbank verarbeitet werden. Wie stellen wir sicher, dass jeder Knoten genau das gleiche Ergebnis erzielt?
• Konfliktverhütung. Wie gehen wir ohne zentrale Koordination mit zwei Transaktionen um, die jeweils den Regeln der Anwendung folgen, aber dennoch in Konflikt miteinander stehen? Konflikte können aus einem absichtlichen Versuch resultieren, das System zu spielen, oder das unschuldige Ergebnis von Pech und Timing sein.

Woher kommen also intelligente Verträge, intelligente Filter und Kettencode? Ihr Hauptzweck ist es, mit der zugrunde liegenden Infrastruktur einer Blockchain zu arbeiten, um diese Herausforderungen zu lösen. Intelligente Verträge sind das dezentrale Äquivalent zum Anwendungscode. Anstatt an einem zentralen Ort ausgeführt zu werden, werden sie auf mehreren Knoten in der Blockchain ausgeführt und erstellen oder validieren die Transaktionen, die den Inhalt dieser Datenbank ändern.

Beginnen wir mit den Transaktionsregeln, der ersten dieser Herausforderungen, und sehen, wie sie in Fabric, MultiChain, Ethereum und Corda ausgedrückt werden.

Transaktionsregeln

Transaktionsregeln erfüllen eine bestimmte Funktion in Blockchain-basierten Datenbanken - sie beschränken die Transformationen Dies kann für den Status dieser Datenbank durchgeführt werden. Dies ist erforderlich, da die Transaktionen einer Blockchain von jedem ihrer Teilnehmer initiiert werden können und diese Teilnehmer sich nicht ausreichend vertrauen, um die Datenbank nach Belieben ändern zu können.

Sehen wir uns zwei Beispiele an, warum Transaktionsregeln benötigt werden. Stellen Sie sich zunächst eine Blockchain vor, mit der PDF-Dokumente, die von den Teilnehmern veröffentlicht werden, zusammengefasst und mit einem Zeitstempel versehen werden können. In diesem Fall sollte niemand das Recht haben, Dokumente zu entfernen oder zu ändern, da dies den gesamten Zweck des Systems - die Persistenz von Dokumenten - untergraben würde. Stellen Sie sich zweitens eine Blockchain vor, die ein gemeinsames Finanzbuch darstellt, das die Salden seiner Benutzer verfolgt. Wir können nicht zulassen, dass ein Teilnehmer willkürlich sein eigenes Guthaben aufbläst oder das Geld anderer wegnimmt.

Eingänge und Ausgänge

Unsere Blockchain-Plattformen basieren auf zwei umfassenden Ansätzen zum Ausdrücken von Transaktionsregeln. Das erste, das ich als „Eingabe-Ausgabe-Modell“ bezeichne, wird in MultiChain und Corda verwendet. Hier listen Transaktionen explizit die Datenbankzeilen oder "Zustände" auf, die sie löschen und erstellen, und bilden eine Reihe von "Eingaben" bzw. "Ausgaben". Das Ändern einer Zeile wird als äquivalente Operation zum Löschen dieser Zeile und zum Erstellen einer neuen Zeile an ihrer Stelle ausgedrückt.

Da Datenbankzeilen nur in Eingaben gelöscht und nur in Ausgaben erstellt werden, muss jede Eingabe die Ausgabe einer vorherigen Transaktion "ausgeben". Der aktuelle Status der Datenbank ist definiert als die Menge von "nicht ausgegebenen Transaktionsausgaben" oder "UTXOs", dh Ausgaben von früheren Transaktionen, die noch nicht verwendet wurden. Transaktionen können auch zusätzliche Informationen enthalten, die als "Metadaten", "Befehle" oder "Anhänge" bezeichnet werden und nicht Teil der Datenbank werden, sondern zur Definition ihrer Bedeutung oder ihres Zwecks beitragen.

Angesichts dieser drei Sätze von Eingaben, Ausgaben und Metadaten wird die Gültigkeit einer Transaktion in MultiChain oder Corda durch einen Code definiert, der beliebige Berechnungen für diese Sätze durchführen kann. Dieser Code kann die Transaktion validieren oder einen Fehler mit einer entsprechenden Erklärung zurückgeben. Sie können sich das Eingabe-Ausgabe-Modell als einen automatisierten „Inspektor“ vorstellen, der eine Checkliste enthält, die sicherstellt, dass Transaktionen jeder einzelnen Regel folgen. Wenn die Transaktion eine dieser Prüfungen nicht besteht, wird sie automatisch von allen Knoten im Netzwerk abgelehnt.

Es ist zu beachten, dass MultiChain und Corda das Input-Output-Modell trotz der gemeinsamen Nutzung sehr unterschiedlich implementieren. In MultiChain können Ausgaben Assets und / oder Daten im JSON-, Text- oder Binärformat enthalten. Die Regeln sind in „Transaktionsfiltern“ oder „Stream-Filtern“ definiert, mit denen alle Transaktionen überprüft werden können oder nur solche, die bestimmte Assets oder Datengruppen betreffen. Im Gegensatz dazu wird ein Corda-Ausgabestatus durch ein Objekt in der Programmiersprache Java oder Kotlin mit definierten Datenfeldern dargestellt. Die Regeln von Corda sind in „Verträgen“ definiert, die bestimmten Staaten zugeordnet sind, und der Vertrag eines Staates wird nur auf Transaktionen angewendet, die diesen Zustand in seinen Ein- oder Ausgängen enthalten. Dies bezieht sich auf Cordas ungewöhnliches Sichtbarkeitsmodell, bei denen Transaktionen nur von ihren Gegenparteien oder von denen gesehen werden können, deren nachfolgende Transaktionen sie betreffen.

Verträge und Nachrichten

Der zweite Ansatz, den ich als "Vertragsnachrichtenmodell" bezeichne, wird in Hyperledger Fabric und Ethereum verwendet. Hier können mehrere "Smart Contracts" oder "Chaincodes" in der Blockchain erstellt werden, und jeder hat seine eigene Datenbank und den zugehörigen Code. Die Datenbank eines Vertrags kann nur durch seinen Code und nicht direkt durch Blockchain-Transaktionen geändert werden. Dieses Entwurfsmuster ähnelt der „Kapselung“ von Code und Daten in der objektorientierten Programmierung.

Bei diesem Modell beginnt eine Blockchain-Transaktion als eine an einen Vertrag gesendete Nachricht mit einigen optionalen Parametern oder Daten. Der Code des Vertrags wird als Reaktion auf die Nachricht und die Parameter ausgeführt und kann im Rahmen dieser Reaktion eine eigene Datenbank lesen und schreiben. Verträge können auch Nachrichten an andere Verträge senden, jedoch nicht direkt auf die Datenbanken des anderen zugreifen. In der Sprache relationaler Datenbanken fungieren Verträge als erzwungen "Gespeicherte Prozeduren", bei denen der gesamte Zugriff auf die Datenbank über einen vordefinierten Code erfolgt.

Sowohl Fabric als auch Quorum, eine Variante von Ethereum, erschweren dieses Bild, indem sie einem Netzwerk ermöglichen, mehrere „Kanäle“ oder „private Zustände“ zu definieren. Ziel ist es, das Problem der Blockchain-Vertraulichkeit zu verringern, indem separate Umgebungen erstellt werden, von denen jede nur für eine bestimmte Untergruppe von Teilnehmern sichtbar ist. Während dies theoretisch vielversprechend klingt, sind in Wirklichkeit die Verträge und Daten in jedem Kanal oder Privatstaat von denen in den anderen isoliert. In Bezug auf intelligente Verträge entsprechen diese Umgebungen daher separaten Blockchains.

Beispielregeln

Lassen Sie uns sehen, wie Sie die Transaktionsregeln für ein Finanzbuch für einzelne Assets mit diesen beiden Modellen implementieren. Jede Zeile in der Datenbank unseres Hauptbuchs enthält zwei Spalten, die die Adresse des Eigentümers und die Menge des Vermögenswerts enthalten. Im Eingabe-Ausgabe-Modell müssen Transaktionen zwei Bedingungen erfüllen:

1. Die Gesamtmenge der Vermögenswerte in den Ausgaben einer Transaktion muss mit der Gesamtmenge in den Eingaben übereinstimmen. Dies verhindert, dass Benutzer willkürlich Geld erstellen oder löschen.
2. Jede Transaktion muss vom Eigentümer jeder ihrer Eingaben signiert werden. Dies verhindert, dass Benutzer ohne Erlaubnis das Geld des anderen ausgeben.

Zusammengenommen sind diese beiden Bedingungen alles, was zur Schaffung eines einfachen, aber tragfähigen Finanzsystems erforderlich ist.

Im Vertragsnachrichtenmodell unterstützt der Vertrag des Assets eine Nachricht "Zahlung senden", die drei Parameter enthält: die Absenderadresse, die Empfängeradresse und die zu sendende Menge. Als Reaktion darauf führt der Vertrag die folgenden vier Schritte aus:

1. Stellen Sie sicher, dass die Transaktion vom Absender signiert wurde.
2. Überprüfen Sie, ob der Absender über ausreichende Mittel verfügt.
3. Ziehen Sie die angeforderte Menge von der Absenderzeile ab.
4. Fügen Sie diese Menge der Zeile des Empfängers hinzu.

Wenn einer der Schecks in den ersten beiden Schritten fehlschlägt, wird der Vertrag abgebrochen und es erfolgt keine Zahlung.

Daher sind sowohl das Eingabe-Ausgabe- als auch das Vertragsnachrichtenmodell effektive Methoden, um Transaktionsregeln zu definieren und eine gemeinsam genutzte Datenbank zu schützen. Auf theoretischer Ebene kann jedes dieser Modelle verwendet werden, um das andere zu simulieren. In der Praxis hängt das am besten geeignete Modell jedoch von der zu erstellenden Anwendung ab. Betrifft jede Transaktion nur wenige oder viele Informationen? Müssen wir in der Lage sein, die Transaktionsunabhängigkeit zu gewährleisten? Hat jedes Datenelement einen eindeutigen Eigentümer oder gibt es einen globalen Status, der gemeinsam genutzt werden kann?

Es liegt hier außerhalb unseres Rahmens zu untersuchen, wie die Antworten die Wahl zwischen diesen beiden Modellen beeinflussen sollten. Als allgemeine Richtlinie lohnt es sich jedoch, bei der Entwicklung einer neuen Blockchain-Anwendung zu versuchen, die Transaktionsregeln in beiden Formen auszudrücken und herauszufinden, welche natürlicher passen. Der Unterschied äußert sich in folgenden Punkten: (a) einfache Programmierung, (b) Speicheranforderungen und Durchsatz und (c) Geschwindigkeit der Konflikterkennung. Wir werden später mehr über diese letzte Ausgabe sprechen.

Eingebaute Regeln

Wenn es um Transaktionsregeln geht, gibt es eine Möglichkeit, in der sich MultiChain speziell von Fabric, Ethereum und Corda unterscheidet. Im Gegensatz zu diesen anderen Plattformen verfügt MultiChain über mehrere integrierte Abstraktionen, die einige grundlegende Bausteine ​​für blockchain-gesteuerte Anwendungen ohne bereitstellen erfordern Entwickler, ihren eigenen Code zu schreiben. Diese Abstraktionen decken drei Bereiche ab, die üblicherweise benötigt werden: (a) dynamische Berechtigungen, (b) übertragbare Assets und (c) Datenspeicherung.

MultiChain verwaltet beispielsweise Berechtigungen zum Herstellen einer Verbindung zum Netzwerk, zum Senden und Empfangen von Transaktionen, zum Erstellen von Assets oder Streams oder zum Steuern der Berechtigungen anderer Benutzer. Mehrere fungible Vermögenswerte können sicher und atomar ausgegeben, übertragen, in den Ruhestand versetzt oder umgetauscht werden. In einer Kette können beliebig viele „Streams“ erstellt werden, um Daten in der Kette oder außerhalb der Kette in JSON-, Text- oder Binärformaten zu veröffentlichen, zu indizieren und abzurufen. Alle Transaktionsregeln für diese Abstraktionen sind sofort verfügbar.

Bei der Entwicklung einer Anwendung auf MultiChain können Sie diese integrierte Funktionalität ignorieren und Transaktionsregeln nur mit intelligenten Filtern ausdrücken. Intelligente Filter sind jedoch so konzipiert, dass sie mit den integrierten Abstraktionen zusammenarbeiten, indem sie ihr Standardverhalten aktivieren eingeschränkt auf kundenspezifische Weise. Beispielsweise kann die Berechtigung für bestimmte Aktivitäten von bestimmten Administratoren gesteuert werden und nicht vom Standardverhalten eines Administrators. Die Übertragung bestimmter Vermögenswerte kann zeitlich begrenzt sein oder eine zusätzliche Genehmigung über einen bestimmten Betrag erfordern. Die Daten in einem bestimmten Stream können überprüft werden, um sicherzustellen, dass sie nur aus JSON-Strukturen mit erforderlichen Feldern und Werten bestehen.

In all diesen Fällen stellen intelligente Filter zusätzliche Anforderungen an die zu validierenden Transaktionen, jedoch nicht entfernen Dies kann dazu beitragen, eine der wichtigsten Herausforderungen in Blockchain-Anwendungen zu bewältigen: Die Tatsache, dass ein Fehler in einem On-Chain-Code zu katastrophalen Folgen führen kann. Wir haben endlose Beispiele für dieses Problem in der öffentlichen Ethereum-Blockchain gesehen, am bekanntesten in der Tod des DAO und für Paritäts-Multisignatur-Fehler. Breitere Umfragen haben eine große Anzahl häufiger Sicherheitslücken in intelligenten Verträgen von Ethereum gefunden, die es Angreifern ermöglichen, Gelder anderer Leute zu stehlen oder einzufrieren.

Natürlich können Smart-Filter von MultiChain auch Fehler enthalten, deren Folgen jedoch eingeschränkter sind. Zum Beispiel verhindern die integrierten Asset-Regeln, dass ein Benutzer das Geld eines anderen ausgibt oder versehentlich sein eigenes Geld verschwindet, unabhängig davon, welche andere Logik ein intelligenter Filter enthält. Wenn ein Fehler in einem intelligenten Filter gefunden wird, kann er deaktiviert und durch eine korrigierte Version ersetzt werden, während die grundlegende Integrität des Hauptbuchs geschützt ist. Philosophisch gesehen ist MultiChain den traditionellen Datenbankarchitekturen näher, bei denen die Datenbankplattform eine Reihe integrierter Abstraktionen wie Spalten, Tabellen, Indizes und Einschränkungen bereitstellt. Leistungsstärkere Funktionen wie Trigger und gespeicherte Prozeduren können optional von Anwendungsentwicklern codiert werden, falls sie tatsächlich benötigt werden.

Transaktionsregeln	Stoff	Multichain	Ethereum	Seil
Modell	Vertragsnachricht	Input-Output	Vertragsnachricht	Input-Output
Eingebaute	Andere	Berechtigungen + Assets + Streams	Andere	Andere

Determinismus

Fahren wir mit dem nächsten Teil unseres Showdowns fort. Unabhängig davon, welchen Ansatz wir wählen, werden die benutzerdefinierten Transaktionsregeln einer Blockchain-Anwendung als Computercode ausgedrückt, der von Anwendungsentwicklern geschrieben wurde. Und im Gegensatz zu zentralisierten Anwendungen wird dieser Code mehr als einmal und an mehr als einer Stelle für jede Transaktion ausgeführt. Dies liegt daran, dass mehrere Blockchain-Knoten, die verschiedenen Teilnehmern gehören, diese Transaktion jeweils für sich selbst überprüfen und / oder ausführen müssen.

Diese wiederholte und redundante Codeausführung führt eine neue Anforderung ein, die in zentralisierten Anwendungen selten zu finden ist: Determinismus. Im Kontext der Berechnung bedeutet Determinismus, dass ein Code immer dieselbe Antwort für dieselben Parameter gibt, unabhängig davon, wo und wann er ausgeführt wird. Dies ist für Code, der mit einer Blockchain interagiert, absolut entscheidend, da der Konsens zwischen den Knoten in dieser Kette ohne Determinismus katastrophal zusammenbrechen kann.

Lassen Sie uns zunächst im Input-Output-Modell sehen, wie dies in der Praxis aussieht. Wenn zwei Knoten unterschiedliche Meinungen darüber haben, ob eine Transaktion gültig ist, akzeptiert einer einen Block, der diese Transaktion enthält, und der andere nicht. Da jeder Block explizit mit einem vorherigen Block verknüpft ist, wird eine permanente „Abzweigung“ im Netzwerk erstellt, wobei ein oder mehrere Knoten ab diesem Zeitpunkt nicht mehr die Mehrheitsmeinung über den Inhalt der gesamten Blockchain akzeptieren. Die Knoten in der Minderheit werden vom sich entwickelnden Status der Datenbank abgeschnitten und können die Anwendung nicht mehr effektiv nutzen.

Lassen Sie uns nun sehen, was passiert, wenn der Konsens im Vertragsnachrichtenmodell zusammenbricht. Wenn zwei Knoten unterschiedliche Meinungen darüber haben, wie ein Vertrag auf eine bestimmte Nachricht reagieren soll, kann dies zu einem Unterschied im Inhalt ihrer Datenbanken führen. Dies kann sich wiederum auf die Antwort des Vertrags auf zukünftige Nachrichten auswirken, einschließlich Nachrichten, die er an andere Verträge sendet. Das Endergebnis ist eine zunehmende Divergenz zwischen der Ansicht verschiedener Knoten über den Status der Datenbank. (Das Feld "State Root" in Ethereum-Blöcken stellt sicher, dass unterschiedliche Antworten der Verträge sofort zu einer vollständig katastrophalen Blockchain-Abzweigung führen, anstatt zu riskieren, für einen bestimmten Zeitraum verborgen zu bleiben.)

Quellen des Nichtdeterminismus

Nichtdeterminismus im Blockchain-Code ist also eindeutig ein Problem. Aber wenn die Grundbausteine ​​der Berechnung wie die Arithmetik deterministisch sind, worüber müssen wir uns dann Sorgen machen? Nun, es stellt sich heraus, einige Dinge:

• Am offensichtlichsten sind Zufallszahlengeneratoren, da diese per Definition so ausgelegt sind, dass sie jedes Mal ein anderes Ergebnis liefern.
• Überprüfen der aktuellen Uhrzeit, da Knoten Transaktionen nicht genau zur gleichen Zeit verarbeiten und ihre Uhren in jedem Fall möglicherweise nicht synchron sind. (Es ist weiterhin möglich, zeitabhängige Regeln zu implementieren, indem auf Zeitstempel in der Blockchain selbst verwiesen wird.)
• Abfragen externer Ressourcen wie Internet, Festplattendateien oder anderer Programme, die auf einem Computer ausgeführt werden. Es kann nicht garantiert werden, dass diese Ressourcen immer dieselbe Antwort geben, und sie sind möglicherweise nicht mehr verfügbar.
• Ausführen mehrerer Codeteile in parallelen "Threads", da dies zu einer "Race-Bedingung" führt, bei der die Reihenfolge, in der diese Prozesse abgeschlossen werden, nicht vorhergesagt werden kann.
• Durchführen von Gleitkommaberechnungen, die auf verschiedenen Computerprozessorarchitekturen auch nur geringfügig unterschiedliche Antworten liefern können.

Unsere vier Blockchain-Plattformen verwenden verschiedene Ansätze, um diese Fallstricke zu vermeiden.

Deterministische Ausführung

Beginnen wir mit Ethereum, da sein Ansatz der „reinste“ ist. Ethereum-Verträge werden in einem speziellen Format namens "Ethereum-Bytecode" ausgedrückt, das von der Ethereum Virtual Machine ("EVM") ausgeführt wird. Programmierer schreiben Bytecode nicht direkt, sondern generieren oder "kompilieren" ihn aus einer JavaScript-ähnlichen Programmiersprache namens Solidity. (Andere Sprachen waren früher verfügbar, sind aber inzwischen veraltet.) Determinismus wird durch die Tatsache garantiert, dass der Bytecode von Solidity und Ethereum keine nicht deterministischen Operationen codieren kann - so einfach ist das.

MultiChain-Filter und Corda-Verträge wählen einen anderen Ansatz, indem vorhandene Programmiersprachen und Laufzeitumgebungen angepasst werden. MultiChain verwendet JavaScript, das in Google ausgeführt wird V8 Engine, die auch den Kern des Chrome-Browsers und der Node.js-Plattform bildet, jedoch Quellen für Nichtdeterminismus deaktiviert. Ebenso verwendet Corda Java oder KotlinBeide werden zu "Java-Bytecode" kompiliert, der in einer Java Virtual Machine ("JVM") ausgeführt wird. Derzeit verwendet Corda die nicht deterministische Standard-JVM von Oracle. Derzeit wird jedoch an der Integration von a gearbeitet deterministische Version. In der Zwischenzeit müssen Corda-Vertragsentwickler darauf achten, dass ihr Code keinen Nichtdeterminismus zulässt.

Wie ist der Purismus von Ethereum mit dem evolutionären Ansatz von MultiChain und Corda zu vergleichen? Der Hauptvorteil von Ethereum ist die Risikominimierung - eine speziell für diesen Zweck entwickelte virtuelle Maschine enthält weniger wahrscheinlich eine versehentliche Quelle von Nichtdeterminismus. Während ein solches Versehen durch ein Software-Update behoben werden könnte, würde es jede Kette stören, die das Pech hatte, darauf zu stoßen. Das Problem von Ethereum ist jedoch, dass Solidity und das EVM ein winziges und aufstrebendes Ökosystem im weiteren Kontext von Programmiersprachen und Laufzeitumgebungen darstellen. Im Vergleich dazu sind JavaScript und Java die Top zwei Sprachen auf Githublaufen auf Milliarden digitaler Geräte und haben Laufzeiten, die über Jahrzehnte optimiert wurden. Vermutlich ist dies der Grund, warum die öffentliche Ethereum-Blockchain einen Übergang zu erwägt eWASM, eine deterministische Abzweigung des aufkommenden WebAssembly-Standards.

Determinismus durch Billigung

Wenn es um Determinismus geht, verfolgt Hyperledger Fabric einen völlig anderen Ansatz. Wenn in Fabric ein "Client" -Knoten eine Nachricht an einen Kettencode senden möchte, sendet er diese Nachricht zuerst an einige "Endorser" -Knoten. Jeder dieser Knoten führt den Kettencode unabhängig aus und bildet eine Meinung zu den Nachrichten bewirken in der Datenbank dieses Kettencodes. Diese Meinungen werden zusammen mit einer digitalen Signatur, die eine formelle „Bestätigung“ darstellt, an den Kunden zurückgesandt. Wenn der Kunde genügend Vermerke für das beabsichtigte Ergebnis erhält, erstellt er eine Transaktion, die diese Vermerke enthält, und sendet sie zur Aufnahme in die Kette.

Um Determinismus zu gewährleisten, verfügt jeder Kettencode über eine „Endorsement-Richtlinie“, die genau definiert, welche Genehmigungsstufe erforderlich ist, um seine Transaktionen gültig zu machen. Beispielsweise könnte die Richtlinie eines Kettencodes besagen, dass Vermerke von mindestens der Hälfte der Knoten der Blockchain erforderlich sind. Ein anderer erfordert möglicherweise eine Bestätigung von einer der drei vertrauenswürdigen Parteien. In beiden Fällen kann jeder Knoten unabhängig prüfen, ob die erforderlichen Vermerke eingegangen sind.

Um den Unterschied zu verdeutlichen, basiert der Determinismus in den meisten Blockchain-Plattformen auf der Frage: "Was ist das Ergebnis der Ausführung dieses Codes für diese Daten?" - und wir müssen absolut sicher sein, dass jeder Knoten diese Frage identisch beantwortet. Im Gegensatz dazu basiert der Determinismus in Fabric auf einer anderen Frage: "Sind sich genügend Endorser über das Ergebnis der Ausführung dieses Codes für diese Daten einig?" Das zu beantworten ist eine ziemlich einfache Frage des Zählens, und es gibt keinen Raum für Nichtdeterminismus, um sich einzuschleichen.

Der Determinismus von Stoff durch Billigung hat eine Reihe interessanter Konsequenzen. Erstens kann Chaincode in vielen verschiedenen Programmiersprachen geschrieben werden, da diese nicht für Determinismus angepasst werden müssen (Go, Java und JavaScript werden derzeit unterstützt). Zweitens kann Chaincode für einige Teilnehmer einer Blockchain ausgeblendet werden, da er nur von Clients und Endorsern ausgeführt werden muss (die Datenbank selbst ist global sichtbar). Schließlich und vor allem kann Fabric Chaincode Dinge tun, die in anderen Blockchain-Umgebungen verboten sind, z. B. das Überprüfen des Wetters mithilfe einer Online-Web-API. Im schlimmsten Fall, wenn jeder Endorser eine andere Antwort von dieser API erhält, erhält der Client nicht genügend Endorsements für ein bestimmtes Ergebnis, und es findet keine Transaktion statt. (Es sollte beachtet werden, dass Fabric-Teammitglieder immer noch empfehlen Verwendung deterministischer Logik innerhalb des Kettencodes, um Überraschungen zu vermeiden.)

Welchen Preis zahlt Fabric für diese Flexibilität? Wenn der Zweck einer Blockchain darin besteht, Vermittler aus einer gemeinsam genutzten datenbankgesteuerten Anwendung zu entfernen, ist Fabric's Vertrauen in Endorser einen großen Schritt von diesem Ziel entfernt. Für die Teilnehmer an der Kette reicht es nicht mehr aus, die Regeln des Kettencodes zu befolgen - sie benötigen auch bestimmte andere Knoten, um zuzustimmen, dass sie dies getan haben. Schlimmer noch, eine böswillige Untergruppe von Endorsern könnte Datenbankänderungen genehmigen, die überhaupt nicht dem Kettencode folgen. Dies gibt Endorsern viel mehr Macht als den Validatoren in regulären Blockchains, die Transaktionen zensieren können, aber nicht gegen die Regeln der Blockchain verstoßen können. Entwickler von Blockchain-Anwendungen müssen entscheiden, ob dieser Kompromiss in ihrem speziellen Fall sinnvoll ist.

Determinismus	Stoff	Multichain	Ethereum	Seil
Modell	Endorsements	Angepasste Laufzeit	Zweckgebundene VM	Angepasste Laufzeit
Sprachen	Gehen Sie + Java + JavaScript	JavaScript	Solidität	Java + Kotlin
Code-Sichtbarkeit	Gegenparteien + Endorser	Blockchain	Blockchain	Gegenparteien + Abhängige
Gesetzt	Nein	Ja	Ja	Nein für jetzt)

Konfliktverhütung

Bisher haben wir diskutiert, wie verschiedene Blockchain-Plattformen Transaktionsregeln im Code ausdrücken und wie sie deterministisch sicherstellen, dass jeder Knoten diese Regeln identisch anwendet. Jetzt ist es Zeit, über einen dritten Aspekt unseres Showdowns zu sprechen: Wie geht jede Plattform mit der Möglichkeit um, dass zwei Transaktionen, die an und für sich gültig sind, miteinander in Konflikt stehen? Stellen Sie sich im einfachsten Beispiel vor, Alice hat 10 US-Dollar in einem Finanzbuch und sendet zwei Transaktionen - eine sendet 8 US-Dollar an Bob und die andere 7 US-Dollar an Charlie. Es ist klar, dass nur eine dieser Transaktionen erfolgreich sein kann.

Zwei Modelle

Wir können damit beginnen, den Ansatz von MultiChain und Corda für dieses Problem zusammenzufassen. Wie bereits beschrieben, verwenden beide ein Eingabe-Ausgabe-Modell zur Darstellung von Transaktionen und deren Regeln, bei dem jede Transaktionseingabe eine vorherige Transaktionsausgabe ausgibt. Dies führt zu einem einfachen Prinzip zur Vermeidung von Konflikten: Jede Ausgabe kann nur einmal ausgegeben werden. MultiChain-Filter und Corda-Verträge können sich auf ihre jeweiligen Plattformen verlassen, um diese Einschränkung absolut durchzusetzen. Da Alices 10 US-Dollar durch eine vorherige Transaktionsausgabe dargestellt werden, stoppt diese Regel für einzelne Ausgaben automatisch, dass sie sie sowohl an Bob als auch an Charlie sendet.

Trotz dieser Ähnlichkeit ist es wichtig, auf einen wesentlichen Unterschied hinzuweisen, wie MultiChain und Corda Konflikte verhindern. In MultiChain sieht jeder Knoten jede Transaktion und kann so unabhängig überprüfen, ob jede Ausgabe nur einmal ausgegeben wird. Jede Transaktion, bei der eine doppelte Ausgabe für eine zuvor bestätigte Transaktion getätigt wird, wird sofort und automatisch abgelehnt. Im Gegensatz dazu gibt es in Corda keine globale Blockchain, daher sind „Notare“ erforderlich, um diese doppelten Ausgaben zu verhindern. Jeder Corda-Ausgabestatus wird einem Notar zugewiesen, der alle Transaktionsausgaben für diese Ausgabe unterzeichnen muss, um zu bestätigen, dass sie zuvor nicht ausgegeben wurden. Die Teilnehmer einer Blockchain müssen Notaren vertrauen, um diese Regel ehrlich zu befolgen, und böswillige Notare können nach Belieben Chaos verursachen. Wie bei Vermerken in Fabric ist dies „einmal als Dienstleistung ausgeben„Design hat Vorteile in Bezug auf die Vertraulichkeit, führt jedoch wieder Vermittler ein, die gegen das Blockchain-Korn verstoßen. (Es ist wichtig zu klären, dass Corda-Notare von Gruppen von Teilnehmern mithilfe eines Konsensalgorithmus betrieben werden können, damit die Integrität des Hauptbuchs weiterhin vor einzelnen schlechten Akteuren geschützt werden kann.)

Gehen wir weiter zu Ethereum. Um sich zu erinnern, verwendet Ethereum Verträge und Nachrichten anstelle von Ein- und Ausgängen. Infolgedessen sind Transaktionskonflikte wie die beiden Zahlungen von Alice für die Blockchain-Engine nicht sofort sichtbar. Stattdessen werden sie von der erkannt und blockiert Vertrag die die Transaktionen verarbeitet, nachdem ihre Bestellung in der Kette bestätigt wurde. Bei der Verarbeitung jeder Zahlung von Alice überprüft der Vertrag, ob ihr Guthaben ausreicht. Wenn die Transaktion, bei der Bob 8 US-Dollar zahlt, an erster Stelle steht, wird sie wie gewohnt verarbeitet, sodass Alice 2 US-Dollar auf ihrem Konto hat. Wenn der Vertrag die zweite Transaktion abwickelt, bei der Charlie 7 US-Dollar erhält, sieht er, dass Alice nicht über die erforderlichen Mittel verfügt und die Transaktion abgebrochen wird.

Outputs gegen Verträge

Bisher haben wir zwei verschiedene Techniken zur Verhinderung widersprüchlicher Transaktionen gesehen - Einzelausgaben in MultiChain und Corda und vertragsbasierte Überprüfung in Ethereum. Also was ist besser?

Um diese Frage zu beantworten, betrachten wir ein Beispielkonto für ein 1-aus-2-Multisignatur-Konto, das 100 US-Dollar für Gavin und Helen enthält und es einem von beiden ermöglicht, dieses Geld unabhängig auszugeben. Gavin weist seine Bewerbung an, Donna 80 Dollar zu zahlen, und ein paar Sekunden später möchte Helen 40 Dollar an Edward schicken. Da für beide Zahlungen nicht genügend Mittel vorhanden sind, würden diese Transaktionen unweigerlich in Konflikt geraten. Für den Fall, dass beide Transaktionen gesendet werden, wird das Ergebnis von dem bestimmt, der es zuerst in die Kette schafft. Beachten Sie, dass dieser Konflikt im Gegensatz zu Alices Beispiel ist zufällig, da niemand versucht, die Regeln der Anwendung zu brechen, hatten sie einfach ein unglückliches Timing.

In Anbetracht der Wahrscheinlichkeit, dass dieser Konflikt auftritt, lautet die Schlüsselfrage: Nachdem Gavin seine Transaktion gesendet hat, wie lange wird es dauern, bis Helens Knoten weiß, dass ihre Zahlung möglicherweise fehlschlägt? Je kürzer dieser Zeitraum ist, desto wahrscheinlicher ist es, dass Helen daran gehindert wird, diese Zahlung zu versuchen, was sie und ihre Bewerbung vor einer späteren Überraschung bewahrt.

Beim Eingabe-Ausgabe-Modell ist jeder Konflikt zwischen Transaktionen für die Blockchain-Plattform direkt sichtbar, da die beiden Transaktionen explizit versuchen, dieselbe vorherige Ausgabe auszugeben. In MultiChain geschieht dies, sobald Gavins Transaktion auf Helens Knoten übertragen wurde, normalerweise in einer Sekunde oder weniger. In Corda lehnt der Notar der Ausgabe die Aufforderung zur Unterzeichnung von Helens Transaktion ab, da er bereits Gavins unterzeichnet hat, sodass Helen sofort weiß, dass ihre Zahlung fehlschlagen wird. (Wenn der Corda-Notar selbst verteilt ist, muss er möglicherweise einige Sekunden auf eine Antwort warten.) In beiden Fällen muss nicht gewartet werden, bis eine Transaktion in der Blockchain bestätigt und bestellt wurde.

Was ist mit dem Modell von Ethereum? In diesem Fall kann die Blockchain-Plattform nicht sofort erkennen, dass ein Konflikt auftritt. Während Helens Knoten möglicherweise Gavins Transaktion im Netzwerk sieht, kann er nicht wissen, wie sich dies auf Helens eigene Transaktion auswirkt, da dies aus seiner Sicht einfach zwei Nachrichten sind, die an denselben Vertrag gesendet werden. Vielleicht zehn Sekunden später, sobald die endgültige Reihenfolge der widersprüchlichen Transaktionen in der Blockchain bestätigt wurde, berechnet Helens Knoten das tatsächliche statt des erwarteten Ergebnisses neu und ihre Anwendung aktualisiert die Anzeige entsprechend. In der Zwischenzeit werden sowohl Gavin als auch Helen im Dunkeln gelassen.

Daraus sollten wir jedoch nicht schließen, dass das Input-Output-Modell immer am besten funktioniert. Stellen Sie sich eine Variation unseres Beispielszenarios vor, in dem sowohl Gavin als auch Helen genau zur gleichen Zeit kleinere 40-Dollar-Zahlungen vom ursprünglichen Saldo von 100 Dollar anfordern. Im Eingabe-Ausgabe-Modell würden diese Transaktionen in Konflikt geraten, da beide dieselbe Datenbankzeile mit diesen 100 US-Dollar ausgeben und nur eine der Zahlungen erfolgreich wäre. In Ethereum würden beide Transaktionen jedoch unabhängig von ihrer endgültigen Bestellung erfolgreich verarbeitet, da das Konto für beide ausreichend Geld enthält. In diesem Fall erfüllt Ethereum die Absichten von Gavin und Helen getreuer.

Lese- / Schreibsätze

Lassen Sie uns abschließend über Fabric sprechen, dessen Endorsement-basierter Ansatz eine Mischung aus diesen beiden Techniken ist. Wie bereits erläutert, fordert ein Fabric-Clientknoten, wenn er eine Nachricht an einen Vertrag senden möchte, zunächst einige unterstützende Knoten auf, diese Nachricht in seinem Namen auszuführen. Die Endorsing-Knoten tun dies auf ähnliche Weise wie Ethereum - sie führen den Vertrag für ihre lokale Datenbank aus -, aber dieser Prozess wird beobachtet und nicht sofort angewendet. Jeder Endorser zeichnet die Zeilen auf, die gelesen und geschrieben werden sollen, und notiert auch die genaue Version dieser Zeilen zu diesem Zeitpunkt. Auf diesen "Lese- / Schreibsatz" versionierter Zeilen wird im Endorsement explizit verwiesen und in der Transaktion enthalten, die der Client sendet.

Konflikte zwischen Fabric-Transaktionen werden gelöst, sobald ihre Bestellung in der Kette abgeschlossen ist. Jeder Knoten verarbeitet jede Transaktion unabhängig, überprüft die Endorsement-Richtlinien und wendet die angegebenen Datenbankänderungen an. Wenn eine Transaktion jedoch eine Datenbankzeilenversion liest oder schreibt, die bereits von einer vorherigen Transaktion geändert wurde, wird diese zweite Transaktion ignoriert. Um zu Alices widersprüchlichen Zahlungen an Bob und Charlie zurückzukehren, lesen und ändern beide Transaktionen dieselbe Zeilenversion, die die 10 US-Dollar enthält, mit denen Alice begonnen hat. Die zweite Transaktion wird also sicher und automatisch abgebrochen.

Der Ansatz von Fabric zur Konfliktlösung funktioniert einwandfrei, kombiniert jedoch in Bezug auf Leistung und Flexibilität das schlechteste der beiden vorherigen Modelle. Da Vermerke Transaktionen in bestimmte Lese- / Schreibsätze umwandeln, würden die gleichzeitigen, aber kompatiblen 40-Dollar-Zahlungen von Gavin und Helen zu einem Konflikt führen, den Ethereum vermeidet. Fabric erhält jedoch nicht den Geschwindigkeitsvorteil des Eingabe-Ausgabe-Modells, da Endorser Verträge mit der neuesten Version der Datenbank ausführen, die von der Blockchain bestätigt wurde, und unbestätigte Transaktionen ignorieren. Wenn Helen ihre Zahlung einige Sekunden nach Gavin einleitet, aber bevor Gavins in der Blockchain bestätigt wurde, erstellt Fabric widersprüchliche Transaktionen, die durch ein reines Eingabe-Ausgabe-Modell vermieden werden.

Konfliktverhütung	Stoff	Multichain	Ethereum	Seil
Modell	Lese- / Schreibsätze	Einzelausgaben	Vertragsüberprüfungen	Einzelausgaben
Verification	Unabhängig	Unabhängig	Unabhängig	Vertrauenswürdige Notare
Schnelligkeit	~ 10s (Bestätigung)	~ 1s (Ausbreitung)	~ 10s (Bestätigung)	0 ~ 5s (Notar)

Eine komplexe Wahl

In diesem Artikel haben wir viele der verschiedenen Möglichkeiten untersucht, mit denen Corda, Ethereum, Fabric und MultiChain die wichtigsten Herausforderungen von „intelligenten Verträgen“ oder Anwendungscode, der in eine Blockchain eingebettet ist, angehen. Und jede Plattform hat unterschiedliche Antworten auf unsere drei Kernfragen: Wie werden Transaktionsregeln dargestellt? Wie wird Code deterministisch ausgeführt? Und wie verhindern wir Konflikte?

Wer ist der Gewinner unseres Smart Contract Showdowns? Es sollte jetzt offensichtlich sein, dass es keine einfache Antwort gibt. Jede Plattform stellt einen komplexen Kompromiss zwischen Flexibilität, Einfachheit, Leistung, Disintermediation, Sicherheit und Vertraulichkeit dar. Die Wahl der Plattform für eine bestimmte Anwendung muss daher mit einem detaillierten Verständnis des Vertrauensmodells dieser Anwendung, der damit verbundenen Transaktionstypen und ihrer wahrscheinlichen Konfliktmuster beginnen. Wenn Sie jemanden finden, der eine bestimmte intelligente Vertragslösung vorantreibt, bevor er die Antworten auf diese Fragen kennt, empfehle ich höflich, aber fest darauf zu bestehen, dass er einen „intelligenteren“ Ansatz verfolgt.

Bitte posten Sie Kommentare auf LinkedIn.