Einführung in die Philosophie und den Consensus von Hyperledger Business Blockchain Design

Dies ist die erste einer Reihe von Arbeiten der Hyperledger Architecture Working Group (WG). Diese Papiere beschreiben eine verallgemeinerte Referenzarchitektur für erlaubte Blockchain-Netzwerke und teilen die Empfehlungen der Arbeitsgruppe Hyperledger-Architektur mit dem Endziel, alle Hyperledger-Projekte in Richtung modularer Designs zu führen. Diese Artikel dienen auch als herstellerneutrale Ressource für Benutzer von technischen Blockchain und für Entwickler, die an der Verwendung von erlaubten Blockchain-Netzwerken interessiert sind.

In diesem ersten Artikel wollen wir:

  1. Skizzieren Sie die übergeordnete Hyperledger-Designphilosophie für erlaubte Blockchain-Netzwerke.
  2. Erläutern Sie, wie unser Ansatz die Entwicklung flexibler, interoperabler Technologien für Unternehmensblockketten optimiert.
  3. Ermitteln Sie die Kern-Netzwerkkomponenten für Blockchain, die von der Architecture WG im Rahmen ihrer Arbeit definiert wurden und werden.
  4. Stellen Sie eine generalisierte Referenzarchitektur für den Consensus bereit.
  5. Erfahren Sie, wie jedes Hyperledger-Business-Blockchain-Framework die Referenzarchitektur darstellt.

Zukünftige Arbeiten in dieser Reihe werden die generalisierte Hyperledger-Referenzarchitektur um die folgenden Komponenten der Business-Blockchain erweitern: Smart Contract-Schicht, Kommunikationsebene, Datenspeicherabstraktion, Crypto-Abstraktion, Identitätsdienste, Richtliniendienste, APIs und Interoperation.

 

Über die Arbeitsgruppe Hyperledger-Architektur

Die WG Hyperledger Architecture dient als projektübergreifendes Forum für Architekten und Technologen aus der Hyperledger-Community, um Ideen auszutauschen und alternative Architekturoptionen und Kompromisse zu erkunden. Ihr Fokus liegt auf der Entwicklung eines modularen Architekturrahmens für verteilte Ledger der Enterprise-Klasse. Dies umfasst das Identifizieren gemeinsamer und kritischer Komponenten, die Bereitstellung einer funktionalen Zerlegung eines Enterprise-Blockchain-Stacks in Komponentenschichten und -module, die Standardisierung der Schnittstellen zwischen den Komponenten und die Sicherstellung der Interoperabilität zwischen Ledgern.

Einführung

Die Anforderungen an die Geschäftsblockkette sind unterschiedlich. Einige Anwendungen erfordern schnelle NetzwerkConsensussysteme und kurze Bestätigungszeiten für Blöcke, bevor sie der Kette hinzugefügt werden. Für andere kann eine langsamere Verarbeitungszeit als Gegenleistung für geringere Vertrauensanforderungen akzeptabel sein. Skalierbarkeit, Vertraulichkeit, Compliance, Workflow-Komplexität und sogar Sicherheitsanforderungen unterscheiden sich je nach Branche und Verwendung erheblich. Jede dieser Anforderungen und viele andere stellen einen potenziell einzigartigen Optimierungspunkt für die Technologie dar. Aus diesen Gründen führt Hyperledger eine Reihe von Business-Blockchain-Technologien ein, einschließlich verteilter Ledger, intelligenter Vertrags-Engines, Client-Bibliotheken, grafischen Schnittstellen, Utility-Bibliotheken und Beispielanwendungen. Die Dachstrategie von Hyperledger fördert die Wiederverwendung gängiger Bausteine ​​mithilfe eines modularen Architekturrahmens. Dies ermöglicht eine schnelle Innovation der Distributed-Ledger-Technologie (DLT), gemeinsamer Funktionsmodule und der Schnittstellen zwischen ihnen. Die Vorteile dieses modularen Ansatzes umfassen die Erweiterbarkeit, Flexibilität und die Möglichkeit, dass jede Komponente unabhängig modifiziert werden kann, ohne den Rest des Systems zu beeinträchtigen.

 

Überblick über die Architektur

Alle Hyperledger-Projekte folgen einer Designphilosophie, die einen modular erweiterbaren Ansatz, Interoperabilität, einen Schwerpunkt auf hochsichere Lösungen, einen token-agnostischen Ansatz ohne native Kryptowährung und die Entwicklung einer umfassenden und einfach zu verwendenden Anwendungsprogrammierschnittstelle (API) umfasst. Die WG Hyperledger Architecture hat die folgenden Komponenten der Business-Blockchain unterschieden:

  • Consensus Layer - Verantwortlich für die Erstellung einer Vereinbarung über die Bestellung und die Bestätigung der Richtigkeit der Menge von Transaktionen, die eine Sperre bilden.
  • Smart Contract Layer - Verantwortlich für die Verarbeitung von Transaktionsanforderungen und für das bestimmen, ob Transaktionen gültig sind, indem die Geschäftslogik ausgeführt wird.
  • Kommunikationsschicht - Verantwortlich für den Peer-to-Peer-Nachrichtentransport zwischen den Knoten, die an einer Shared-Ledger-Instanz teilnehmen.
  • Datenspeicherabstraktion - Ermöglicht die Verwendung verschiedener Datenspeicher für andere Module.
  • Krypto-Abstraktion - Ermöglicht das Auslagern verschiedener Krypto-Algorithmen oder -Module, ohne die anderen Module zu beeinflussen.
  • Identity Services - Ermöglicht die Einrichtung eines Vertrauensstammes beim Einrichten einer Blockchain-Instanz, die Registrierung und Registrierung von Identitäten oder Systemeinheiten während des Netzwerkbetriebs sowie die Verwaltung von Änderungen wie Verwalten, Hinzufügen und Widerrufen. Bietet außerdem Authentifizierung und Autorisierung.
  • Policy Services - Verantwortlich für die Richtlinienverwaltung für verschiedene im System festgelegte Richtlinien, z. B. die Endorsement-Richtlinie, die Consensusrichtlinie oder die Gruppenverwaltungsrichtlinie. Es ist eine Schnittstelle und hängt von anderen Modulen ab, um die verschiedenen Richtlinien durchzusetzen.
  • APIs - Ermöglicht Clients und Anwendungen eine Schnittstelle zu Blockketten.
  • Interoperation - Unterstützt die Interoperation zwischen verschiedenen Blockchain Instanzen

In diesem Dokument werden wir den Consensus untersuchen. Das Ziel des Consensuses besteht darin, eine Vereinbarung über die Bestellung zu generieren und die Richtigkeit der Menge von Transaktionen zu überprüfen, die die Sperre bilden.

Consensus

Consensus ist der Prozess, durch den ein Knotennetzwerk eine garantierte Reihenfolge von Transaktionen bereitstellt und den Transaktionsblock validiert. Consensus muss die folgenden Kernfunktionen bereitstellen:

  • Bestätigt die Richtigkeit aller Transaktionen in einem vorgeschlagenen Block gemäß den Richtlinien für die Übernahme und Consensus.
  • stimmt der Ordnung und Korrektheit und damit den Ergebnissen der Ausführung zu (impliziert die Einigung über den Weltstaat).
  • Schnittstellen und hängen von der Smart-Contract-Schicht ab, um die Richtigkeit einer geordneten Menge von Transaktionen in einem Block zu überprüfen.

 

Vergleich der Consensusarten

Der Consensus kann auf verschiedene Weise implementiert werden, z. B. durch die Verwendung von lotteriebasierten Algorithmen, einschließlich des Nachweises der verstrichenen Zeit (PoET) und des Arbeitsnachweises (PoW), oder durch die Verwendung von auf Abstimmungen basierenden Methoden, einschließlich der redundanten Byzantin-Fehlertoleranz (RBFT) und Paxos. Jeder dieser Ansätze zielt auf unterschiedliche Netzwerkanforderungen und Fehlertoleranzmodelle ab. Die auf einer Lotterie basierenden Algorithmen sind insofern vorteilhaft, als sie auf eine große Anzahl von Knoten skaliert werden können, da der Gewinner der Lotterie einen Block vorschlägt und ihn zur Validierung an den Rest des Netzwerks übermittelt. Auf der anderen Seite können diese Algorithmen zur Verzweiflung führen, wenn zwei "Gewinner" einen Block vorschlagen. Jede Gabelung muss aufgelöst werden, was zu einer längeren Endzeit führt. Die auf Abstimmungen basierenden Algorithmen sind insofern vorteilhaft, als sie eine Endgültigkeit mit niedriger Latenzzeit bieten. Wenn eine Mehrheit der Knoten eine Transaktion oder einen Block validiert, besteht Consensus und Endgültigkeit. Da Abstimmungs-basierte Algorithmen normalerweise erfordern, dass Knoten Nachrichten an jeden der anderen Knoten im Netzwerk übertragen, gilt: Je mehr Knoten im Netzwerk vorhanden sind, desto länger dauert das Prozess, bis ein Consensus erreicht wird. Dies führt zu einem Kompromiss zwischen Skalierbarkeit und Geschwindigkeit. Die betriebliche Annahme für Hyperledger-Entwickler ist, dass Business-Blockchain-Netzwerke in einer Umgebung mit teilweisem Vertrauen betrieben werden. Aus diesem Grund schließen wir standardmäßige Pro-of-Work-Consensusus-Ansätze mit anonymen Bergleuten ausdrücklich nicht mit ein. Nach unserer Einschätzung verursachen diese Ansätze zu hohen Kosten und Ressourcen, um für Netzwerke der Business-Blockchain optimal zu sein. Tabelle 1 bietet einen Überblick über die wichtigsten Überlegungen und Vor- und Nachteile verschiedener Business-Blockchain-Ansätze, um einen Consensus zu erzielen.

tabella-blockchain-consensus-bianca-en
CONSENSUS2

Consensus und seine Interaktion mit anderen Architekturschichten

Zwar gibt es viele Wege, auf denen ein Consensus erzielt werden kann, unsere Analyse von Blockchain-Plattformen legt jedoch nahe, dass der in Abbildung 1 gezeigte Prozess allgemein verwendet wird. Dies ist eine verallgemeinerte Ansicht, und die verschiedenen Hyperledger-Frameworks können diese Schritte unterschiedlich implementieren. Die unternehmensinternen Blockchain-Frameworks Hyperledger erzielen Consensus durch zwei verschiedene Aktivitäten:

 

  1. Reihenfolge der Transaktionen
  2. Validierung von Transaktionen

 

Durch die logische Trennung dieser Aktivitäten garantieren wir, dass jedes Hyperledger-Framework mit jedem Hyperledger-Einwilligungsformular zusammenarbeiten kann. Der erste Schritt im Zustimmungsprozessfluss ist das Empfangen von Transaktionen von der Clientanwendung. Die Zustimmung hängt von einem Bestellservice ab, um Transaktionen zu bestellen. Der Bestelldienst kann auf verschiedene Arten implementiert werden: von einem zentralisierten Dienst, der in Entwicklung und Test verwendet werden kann, bis hin zu verteilten Protokollen, die unterschiedliche Muster von Netzwerk- und Knotenausfällen behandeln. Um die Vertraulichkeit von Transaktionen zu gewährleisten, kann der Bestellservice unabhängig von der Transaktion sein. Das heißt, der Inhalt der Transaktion kann Hashing oder Verschlüsselung unterzogen werden.

 

Transaktionen werden über eine Schnittstelle an den Bestellservice gesendet. Dieser Dienst erfasst Transaktionen basierend auf dem Zustimmungsalgorithmus und der Konfigurationsrichtlinie, die ein Zeitlimit oder die Anzahl der zulässigen Transaktionen angeben können. Aus Effizienzgründen wird der Sortierservice aus Effizienzgründen meist mehrere Transaktionen in einem einzigen Block zusammenfassen, anstatt einzelne Transaktionen auszugeben. In diesem Fall muss der Bestellservice eine deterministische Reihenfolge der Transaktionen in jedem Block festlegen und übertragen. Für die Validierung von Transaktionen hängt die Einwilligung von der Stufe des intelligenten Vertrags ab, da er die Geschäftslogik für die Gültigkeit einer Transaktion enthält. Das intelligente Vertragsniveau überprüft jede Transaktion und stellt sicher, dass sie die für die Transaktion festgelegten Richtlinien und Verträge einhalten. Ungültige Transaktionen werden abgelehnt und können durch Einfügen in einen Block gelöscht werden. Wir können mögliche Validierungsfehler in zwei Kategorien einteilen: Syntax- und logische Fehler. Bei Syntaxfehlern wie ungültiger Eingabe, nicht überprüfbarer Signatur und wiederholten Transaktionen (aufgrund von Fehlern oder Wiederholungsangriffen) muss die Transaktion gelöscht werden. Die zweite Kategorie von Fehlern ist komplexer und sollte durch Richtlinien bestimmt werden, ob die Verarbeitung fortgesetzt werden soll oder nicht. Beispielsweise eine Transaktion, die zu einem Doppelausgaben- oder Versionskontrollfehler führen würde. Möglicherweise möchten wir diese Transaktionen zur Kontrolle aufzeichnen, wenn die Richtlinie dies erfordert. Die Zustimmungsebene verwendet die Kommunikationsebene für die Kommunikation mit dem Client und anderen Peers im Netzwerk.

 

Consensus-Eigenschaften

Ein Consensus muss zwei Eigenschaften erfüllen, um eine Übereinstimmung zwischen den Knoten zu gewährleisten: Sicherheit und Lebensfähigkeit. Sicherheit bedeutet, dass jedem Knoten die gleiche Reihenfolge der Eingaben garantiert wird und auf jedem Knoten dieselbe Ausgabe erfolgt. Wenn die Knoten eine identische Reihe von Transaktionen empfangen, werden auf jedem Knoten dieselben Statusänderungen vorgenommen. Der Algorithmus muss sich identisch zu einem Einzelknotensystem verhalten, das jede Transaktion einzeln atomar ausführt. Lebendigkeit bedeutet, dass jeder nicht fehlerhafte Knoten schließlich jede übermittelte Transaktion empfängt, vorausgesetzt, dass die Kommunikation nicht fehlschlägt.

 

Consensus in den Hyperledger-Frameworks

Da die Anforderungen an die Business-Blockchain variieren, arbeitet die Hyperledger-Community an verschiedenen Consensusmechanismen sowie an Implementierungsansätzen, um die Modularität sicherzustellen. Tabelle 2 enthält einen Vergleich der Consensusalgorithmen, die in Hyperledger-Frameworks verwendet werden. Apache Kafka in Hyperledger Fabric, RBFT in Hyperledger Indy und Sumeragi in Hyperledger Iroha verwenden einen stimmrechtsbasierten Ansatz für einen Consensus, der innerhalb von Sekunden Fehlertoleranz und Endgültigkeit bietet. PoET in Hyperledger Sawtooth verwendet einen lotteriebasierten Consensusansatz, der eine Skalierung auf Kosten der Endgültigkeit zur Folge hat, da sich Gabeln lösen müssen, die gelöst werden müssen.

table consensus

Consensus im Hyperledger-Gewebe Der Consensus im Hyperledger-Gewebe wird in drei Phasen unterteilt: Bestätigung, Bestellung und Validierung.

  • Die Bestätigung erfolgt durch Richtlinien (z. B. m bei n Signaturen), nach denen die Teilnehmer eine Transaktion billigen.
  • Die Bestellphase akzeptiert die bestätigten Transaktionen und stimmt der Bestellung zu, an das Ledger gebunden zu werden.
  • Bei der Validierung werden die bestellten Transaktionen blockiert und die Richtigkeit der Ergebnisse überprüft, einschließlich der Überprüfung der Endorsement-Richtlinien und der Doppelausgabe.
schema transd cons

Hyperledger Fabric unterstützt steckbaren Consensusus-Service für alle 3 Phasen. Anwendungen können je nach ihren Anforderungen unterschiedliche Endorsement-, Bestell- und Validierungsmodelle einbinden. Insbesondere ermöglicht das Bestellservice-API das Einfügen von BFT-basierten Übereinstimmungsalgorithmen. Die Bestellservice-API umfasst zwei grundlegende Vorgänge: Broadcast und Delivery.

  • Broadcast (Blob): Ein Client ruft dies an, um einen beliebigen Nachrichten-Blob zur Verbreitung über den Kanal zu senden. Dies wird im BFT-Kontext auch als Request (Blob) bezeichnet, wenn eine Anfrage an einen Dienst gesendet wird.
  • deliver (seqno, prevhash, blob): Der Bestellservice ruft den Peer dazu auf, das Message-Blob mit der angegebenen nicht-negativen Ganzzahl-Sequenznummer (seqno) und dem Hash des zuletzt ausgelieferten Blob (prevhash) zuzustellen. Es handelt sich also um ein Ausgabeereignis des Bestelldienstes. deliver () wird manchmal auch in pub-sub-Systemen als notify () oder in BFT-Systemen als commit () bezeichnet.

Derzeit werden mehrere Bestell-Plugins entwickelt, darunter BFT Smart, Vereinfachte Byzantinische Fehlertoleranz (SBFT), Honey Badger von BFT usw. Für Fabric v1 wird Apache Kafka standardmäßig als Referenzimplementierung bereitgestellt. Die Anwendungsfälle und das Fehlertoleranzmodell der Anwendung sollten das zu verwendende Plugin bestimmen.

 

Consensus in Hyperledger Indy

Der Consensus in Hyperledger Indy basiert auf Redundant Byzantine Fault Tolerance (RBFT), einem Protokoll, das von Plenum Byzantine Fault Tolerance (Plenum) inspiriert ist. Stellen Sie sich vor, dass RBFT mehrere Instanzen des Plenums parallel ausführt. Bestellanfragen von einer einzigen Instanz, die als Master bezeichnet wird, werden zum Aktualisieren des Ledgers verwendet. Die Leistung des Masters in Bezug auf Durchsatz und Latenz wird jedoch regelmäßig mit der Durchschnittsleistung anderer Instanzen verglichen. Wenn festgestellt wird, dass der Master beeinträchtigt ist, tritt eine Ansichtsänderung ein, die eine andere Instanz als die Rolle des Masters bestimmt. Wie PBFT benötigt RBFT mindestens 3f + 1 Knoten, um fehlerhafte Knoten zu behandeln. Abbildung 3 zeigt ein Netzwerk mit 4 Knoten, das 1 fehlerhaften Knoten verarbeiten kann, auf dem zwei PBFT-ähnliche Instanzen, ein Master und ein Backup ausgeführt werden. Jeder Knoten kann eine primäre Instanz (Leader) hosten.

griglia

Abbildung 4 zeigt eine andere Ansicht von RBFT. Hier sendet der Client eine Anfrage an Knoten. Es muss nicht an alle Knoten gesendet werden, da das Senden an f + 1 Knoten ausreichend ist. Nach Erhalt der Client-Anforderung führen die Knoten einen Verbreitungsprozess über PROPAGATE durch, bei dem jeder andere Knoten auf die Anforderung aufmerksam gemacht wird. Jede Primärdatenbank erstellt aus den empfangenen Anforderungen ein Angebot, das als PRE-PREPARE bezeichnet wird, und sendet es an alle anderen Knoten. Wenn die Knoten den Vorschlag des Primärknotens akzeptieren, senden sie eine Bestätigung mit einer Nachricht namens PREPARE an den Vorschlag. Sobald ein Knoten einen PRE-PREPARE-Vorschlag und 2f PREPARE-Nachrichten erhalten hat, verfügt er über ausreichende Informationen, um den Vorschlag anzunehmen, und sendet eine COMMIT-Nachricht. Sobald ein Knoten 2f + 1 COMMIT-Nachrichten erhält, kann der Batch von Anforderungen angeordnet und zum Ledger hinzugefügt werden, da eine ausreichende Anzahl von Knoten zugestimmt hat, dass eine Mehrheit der Knoten den Vorschlag akzeptiert hat. Für den primären Server ist kein Antrag erforderlich, bevor der nächste Vorschlag gesendet werden kann.

replicants

Hyperledger Indy verwendet RBFT zur Abwicklung von Bestellungen und Validierungen, was zu einem einzigen Ledger führt, dass sowohl geordnete als auch validierte Transaktionen enthält. Dies ist anders als bei vielen Blockchain-Netzwerken, die ein BFT-Protokoll (Byzantine Fault Tolerance) nur zur Bestellung verwenden. Diese Netzwerke lassen die domänenspezifische Validierung erst nach der Bestellung von Anforderungen zu. Das Plenum und damit auch die RBFT unterhält eine Projektion des Ledgers, den Zustand. Alle gültigen, akzeptierten Operationen können den Status ändern, der in einer Datenbank als eine Sammlung von Variablen und deren Werten gespeichert ist. Der Zustand wird in einer kryptographisch authentifizierten Datenstruktur gehalten, die als Merkle Patricia-Baum bezeichnet wird und von Ethereum festgelegt wird. Hyperledger Indy speichert Dezentralized Identifiers (DIDs) als Zustandsvariablen mit Werten, die den aktuellen Überprüfungsschlüssel und einige andere Dinge enthalten. Die In-Memory-Kopie der Ledger-Transaktionen und der resultierende Status werden während der Angebotsphase optimistisch aktualisiert. Die Primärdatenbank wird beim Senden des Angebots aktualisiert, und Nichtprimärdateien werden aktualisiert, während ein gültiger Vorschlag akzeptiert wird. Der Vorschlag wird bestellt, anschließend werden das Ledger und der resultierende Status festgelegt. Wenn der Vorschlag aus irgendeinem Grund abgelehnt wird, werden die am Ledger vorgenommenen Änderungen und der resultierende Status zurückgesetzt. Diese optimistische Aktualisierung ist erforderlich, damit mehrere Vorschläge vorgeschlagen werden, ohne dass die vorherigen Vorschläge vollständig angeordnet wurden. Wenn der erste Vorschlag beispielsweise eine Anforderung enthielt, mit der eine neue Identität Id1 im Ledger erstellt wurde, und der zweite Vorschlag eine Anforderung enthielt, die ein Attribut für Id1 hinzufügte, dann wäre der zweite Vorschlag, wenn der Staat die Existenz von Id1 nicht widerspiegelt abgelehnt. Bevor der zweite Vorschlag angenommen wird, sollten die Änderungen im ersten Vorschlag sichtbar sein. Wenn Änderungen vorgeschlagen wurden, aber noch nicht festgeschrieben wurden, spricht man von einer unverbindlichen Änderung.

Consensus in Hyperledger Iroha

Der Hyperledger Iroha führt einen BFT-Consensusus-Algorithmus mit dem Namen Sumeragi ein, der, wie alle BFT-Systeme, eine Anzahl Byzantinischer fehlerhafter Knoten in einem Netzwerk toleriert. Es ist stark vom B-Ketten-Algorithmus inspiriert, der von Duan, Meling, Peisert & Zhang (2014) beschrieben wurde. Wie in der B-Kette betrachten wir das Konzept einer globalen Ordnung über die Validierung von Peers und Sets A und B von Peers, wobei A aus den ersten 2f + 1 Peers und B aus dem Rest besteht. Da zur Bestätigung einer Transaktion 2f + 1-Signaturen benötigt werden, sind im Normalfall nur 2f + 1-Peers an der Transaktionsvalidierung beteiligt. Die verbleibenden Peers nehmen nur an der Validierung teil, wenn Fehler in Peers in Gruppe A angezeigt werden. Der 2f + 1-te Peer wird als Proxy-Tail bezeichnet. Für normale (nicht fehlerhafte) Fälle wird der Transaktionsablauf wie in Abbildung 5 gezeigt.

iroha

Der Client, bei dem es sich in der Regel um einen API-Server handelt, der mit einem Endbenutzer-Client verbunden ist, übermittelt zunächst eine Transaktion an den Lead-Validierungs-Peer. Dieser Anführer überprüft die Transaktion, ordnet sie in die Warteschlange ein und signiert die Transaktion. Anschließend wird diese Transaktion an die verbleibenden 2f + 1-Validierungs-Peers gesendet. Die Reihenfolge der Verarbeitungsknoten wird auf der Grundlage des Server-Reputationssystems Hijiri festgelegt. Hijiri berechnet die Zuverlässigkeit von Servern anhand von drei Faktoren. Erstens basierend auf der Zeit, zu der sich jeder Server beim Mitgliedschaftsdienst registriert hat. Zweitens basierend auf der Anzahl der erfolgreichen Transaktionen, die von jedem Server verarbeitet werden. Drittens, basierend darauf, ob Fehler erkannt wurden.

 

Um Fehler zu erkennen, stellt jeder Server einen Zeitgeber ein, wenn er eine Transaktion signiert und eine Übertragung an das Proxy-Ende sendet. Wenn auf einem Zwischenserver ein Fehler auftritt und keine Antwort empfangen wird, bevor der Zeitgeber abläuft, sendet der Server die Transaktion und ihre Signatur erneut an den nächsten Server in der Kette nach dem Proxy-Tail. Der Fall eines Ausfalls im Proxy-Tail ist in Abbildung 6 dargestellt.

iroha2

In Sumeragi wird ein Consensus über einzelne Transaktionen und den aus der Anwendung der Transaktion resultierenden globalen Zustand erzielt. Wenn ein validierender Peer eine Transaktion über das Netzwerk erhält, führt er die folgenden Schritte in der angegebenen Reihenfolge aus:

  1. Überprüfen Sie die Unterschrift (oder Unterschriften bei Transaktionen mit mehreren Unterschriften) der Transaktion.
  2. Überprüfen Sie ggf. den Inhalt der Transaktion. Beispielsweise müssen Überweisungstransaktionen das Konto des Zahlers mit einem nicht negativen Saldo verlassen.
  3. Wenden Sie die Transaktion vorübergehend auf das Ledger an. Dies beinhaltet die Aktualisierung der Merkle-Wurzel des globalen Staates.
  4. Signieren Sie den aktualisierten Merkle-Stamm und den Hash des Transaktionsinhalts.
  5. Senden Sie das Tupel, das eine endlich geordnete Liste von Transaktionen ist.
  6. Wenn Sie Knoten miteinander synchronisieren, werden gültige Teile des Merkle-Baums gemeinsam genutzt, bis die Wurzeln übereinstimmen.

 

Consensus im Hyperledger-Sawtooth

Hyperledger Sawtooth ermöglicht einen steckbaren Consensus sowohl für Lotterie- als auch für Abstimmungsalgorithmen. Hyperledger Sawtooth verwendet standardmäßig einen lotsenbasierten Nakamoto-Consensusus-Algorithmus namens PoET. Wie bei Bitcoin's PoW verwendet PoET eine Lotterie zur Wahl der Führungspersönlichkeit auf der Grundlage einer garantierten Wartezeit, die durch eine Trusted Execution Environment (TEE) bereitgestellt wird (Sandell, Bowman & Shah, 2016). Um einen verteilten Consensus effizient zu erreichen, weist eine gute Lotteriefunktion mehrere Eigenschaften auf, die von Sandell et al. Definiert wurden. (2016) als:

  • Fairness - Die Funktion sollte die Wahl des Führers auf die größtmögliche Teilnehmerzahl verteilen.
  • Investitionen - Die Kosten für die Kontrolle des Wahlprozesses der Führer sollten dem erzielten Wert proportional sein.
  • Überprüfung - Es sollte für alle Teilnehmer relativ einfach sein, zu überprüfen, ob der Leiter rechtmäßig ausgewählt wurde.

Die aktuelle Implementierung von Hyperledger Sawtooth basiert auf einem TEE, das von Intel Software Guard Extensions (SGX) bereitgestellt wird. Dies gewährleistet die Sicherheit und Zufälligkeit des Führerauswahlprozesses, ohne dass kostspielige Investitionen in Energie und spezielle Hardware erforderlich sind, die den meisten „Proof“ -Algorithmen zugrunde liegen. Jeder PoET-Validierer fordert eine zufällige Zeit zum Warten von einer vertrauenswürdigen Funktion an, bevor er die Führung beansprucht. Der Prüfer mit der kürzesten Wartezeit für einen bestimmten Transaktionsblock wird implizit zum Anführer gewählt. Die Funktion "CreateTimer" erstellt einen Timer für einen Transaktionsblock, der garantiert vom TEE erstellt wurde. Die Funktion "CheckTimer" überprüft, ob der Timer vom TEE erstellt wurde, und erstellt, wenn er abgelaufen ist, eine Bestätigung, mit der überprüft werden kann, ob der Validator tatsächlich die zugewiesene Zeit gewartet hat, bevor er die Führungsrolle beansprucht. Der PoET-Leader-Wahlalgorithmus erfüllt die Kriterien für einen guten Lotterie-Algorithmus. Es verteilt zufällig die Führungswahlen auf die gesamte Validator-Population, wobei die Verteilung ähnlich der von anderen Lotterie-Algorithmen ist. Die Wahlwahrscheinlichkeit ist proportional zu den eingebrachten Ressourcen, wobei es sich bei den Ressourcen um Universalverarbeiter mit einem TEE handelt. Eine Ausführungsbestätigung enthält Informationen zum Überprüfen, ob das Zertifikat innerhalb des TEE erstellt wurde und der Prüfer die zugewiesene Zeit gewartet hat. Darüber hinaus erhöhen die geringen Kosten der Teilnahme die Wahrscheinlichkeit, dass die Validatorpopulation groß ist, was die Robustheit des Consensusalgorithmus erhöht.

 

Fazit

In diesem ersten Artikel haben wir das modulare Architektur-Framework vorgestellt, das von allen Hyperledger-Projekten verwendet wird, und es wurden mehrere Möglichkeiten untersucht, wie ein Consensus innerhalb dieses modularen Frameworks implementiert werden kann.

Zu den wichtigsten Einnahmequellen gehören:

  1. Die übergreifende Hyperledger-Designphilosophie für erlaubte Blockchain-Netzwerke folgt einem modularen Ansatz, der Erweiterbarkeit und Flexibilität ermöglicht.
  2. Im Rahmen dieses modularen Ansatzes definiert Hyperledger gemeinsame Funktionskomponenten und die Schnittstellen zwischen ihnen. Dadurch kann jede Komponente unabhängig geändert werden, ohne dass der Rest des Systems beeinflusst wird.
  3. Die WG Architecture hat und wird weiterhin die folgenden Kernkomponenten für genehmigte Blockchain-Netzwerke definieren: Consensus Layer, Smart Contract Layer, Kommunikation Layer, Abstraktion von Datenspeichern, Crypto Abstraction, Identity Services, Policy Services, APIs und Interoperation.
  4. Die WG Architecture verfügt über eine verallgemeinerte Referenzarchitektur für Consensus, die von jedem Hyperledger-Projekt verwendet werden kann.
  5. Hyperledger Fabric, Hyperledger Indy, Hyperledger Iroha und Hyperledger Sawtooth manifestieren die Prinzipien der Referenzarchitektur auf einzigartige Weise. Der Vergleich der üblicherweise mit diesen Frameworks verwendeten Consensusus-Algorithmen ist in Tabelle 1 dargestellt. Mit dieser Tabelle können die Stärken und Schwächen von Algorithmen wie Kafka, RBFT, Sumeragi und PoET schnell ermittelt werden.

Zukünftige Arbeiten in dieser Reihe werden die generalisierte Referenzarchitektur von Hyperledger erweitern, um alle Kernkomponenten für erlaubte Blockchain-Netzwerke abzudecken. Die nächste Arbeit in der Serie behandelt die Smart Contract Layer. Wenn Sie sich für eine Teilnahme an der Arbeitsgruppe "Architektur" von Hyperledger interessieren, besuchen Sie die Wiki-Seite, um weitere Informationen zu erhalten.