In den frühen Tagen von Hyperledger Fabric gab es viele Diskussionen darüber, wie Smart Contracts am besten implementiert werden können. Verschiedene Mitwirkende hatten an Kundenengagements/eigenen Projekten gearbeitet und Defizite im EVM festgestellt (aus gutem Grund, denn obwohl das EVM Turing komplett mit Op-Codes ist, beruht es auf Gas und Konten als Konstrukte und macht es schwierig komplexe Datenmodellierung, usw.).
Anstatt zu versuchen, eine neue Vertragssprache und Ausführungssprache zu erstellen, haben wir beschlossen, dass Menschen versuchen sollten, die volle Leistung einer Programmiersprache ihrer Wahl zur Verfügung zu stellen (heute wird Golang vollständig unterstützt, Java ist experimentell) und JavaScript kommt in der nächsten Version).
Um nun mehrsprachige Verträge zuzulassen und keine komplexen eingebetteten Interpreter usw. zu erstellen, haben wir uns dafür entschieden, den Chaincode aus dem Prozess zu kompilieren und auszuführen. Wir mussten dann einen Weg finden, diese externen Prozesse zu isolieren (und zu einem gewissen Grad zu verwalten), und Docker schien eine sehr praktikable Option zu sein.
Ein paar Dinge zu beachten: - die chaincode Prozesse/Container nur mit dem Peer-Prozess kommunizieren (dh sie initiieren Kommunikation mit dem Peer und keinen Endpunkt ihrer eigenen aussetzen) - chaincode tatsächlich passiert Befehle an den Peer (dh wenn Sie einen Get/Put-Status verwenden, wird dieser tatsächlich über eine sichere gRPC-Verbindung an den Peer gesendet) - Der Peer verwaltet/isoliert jeden Chaincode-Aufruf von anderen Aufrufen (dh, ein Aufruf kann nicht auf einen anderen Status aus einem anderen Aufruf zugreifen)) - Hyperledger Fabric selbst bietet einen Mechanismus, durch den Chaincode vom Administrator des Peers installiert werden muss (dies ist ein Vorteil der Ausführung einer genehmigten Blockchain). Bevor also ein Chaincode tatsächlich installiert wird, kann der Administrator/Besitzer des Peers den Chaincode überprüfen und sicherstellen, dass nichts böswillig ist.
Wenn es um Nicht-Determinismus geht, wurden ein paar Dinge untersucht. Zum Beispiel haben wir einige Funktionen für verschiedene Sprachen auf die weiße Liste gesetzt. Aber am Ende ist mit der v1.0-Architektur, die sicherstellt, dass eine Deterministik auf einer pro Chaincode-Aufrufbasis nicht wirklich erforderlich ist. Im v1.0-Modell führt jeder Knoten einen Kettencode aus und die Ausgabe ist tatsächlich ein Lese-/Schreibsatz für die Statuszugriffe/-änderungen. Wenn die Kettencodelogik erfolgreich ausgeführt wird, signiert der Peer die Antwort. Dies nennt man Simulation und Endorsement. Die Anzahl der Bestätigungen (z. B. Peers, die den Kettencode erfolgreich ausführen müssen) ist über Richtlinien konfigurierbar. Sobald genügend Vermerke für eine Transaktion gesammelt wurden, sind sie Pakete und werden an die bestellenden Dienste gesendet, die dann Blöcke von geordneten Transaktionen erstellen und sie zur Validierung und Verpflichtung an die Peers liefern. Diese Logik ist zu 100% deterministisch (prüfen Sie, ob die Transaktion wohlgeformt ist, stellen Sie sicher, dass genügend Vermerke vorhanden sind, um die Richtlinie zu erfüllen, und schließlich klassische MVCC-Prüfungen, um Kollisionen zu vermeiden.)
Hoffentlich dies hilft
Blockchain Determinismus, Terminierung und Isolation
Danke für die Antwort. "Dies nennt man Simulation und Endorsement." Wie unterscheidet sich das Protokoll von 2-Phasen-Commit? – cogitoergosum
Interessante Analogie. In vielerlei Hinsicht ist es wie ein traditionelles Transaktionsprotokoll. Sie können simulieren und unterstützen wie ein "signed prepare" und dann bestellen ist wie Senden einer Reihe von "commit" -Nachrichten und dann die Validieren und Festschreiben Phase ist wie MVCC mit, sondern erfordert eine Politik zu erfüllen sowie das tatsächliche tun MVCC überprüft den Lese-/Schreibsatz. –