DE112021005862T5 - Selbstprüfende blockchain - Google Patents

Selbstprüfende blockchain Download PDF

Info

Publication number
DE112021005862T5
DE112021005862T5 DE112021005862.2T DE112021005862T DE112021005862T5 DE 112021005862 T5 DE112021005862 T5 DE 112021005862T5 DE 112021005862 T DE112021005862 T DE 112021005862T DE 112021005862 T5 DE112021005862 T5 DE 112021005862T5
Authority
DE
Germany
Prior art keywords
image
message
blockchain
peer node
process information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112021005862.2T
Other languages
English (en)
Inventor
Dushyant K. Behl
Sayandeep Sen
Palanivel Andiappan Kodeswaran
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112021005862T5 publication Critical patent/DE112021005862T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/002—Countermeasures against attacks on cryptographic mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)

Abstract

Ein Prozessor kann Prozessinformationen sammeln, die einem Peer-Knoten in einer selbstprüfenden Blockchain zugehörig sind. Der Prozessor kann ein Abbild der Prozessinformationen erzeugen. Der Prozessor kann das Abbild des Peer-Knotens mit einem Abbildkonsens vergleichen, um einen Fehler zu erkennen. Der Fehler kann darauf hinweisen, dass der Peer-Knoten beeinträchtigt wurde.

Description

  • HINTERGRUND
  • Die vorliegende Offenbarung bezieht sich allgemein auf das Gebiet des Blockchain-Speicherns und insbesondere auf Ermitteln, ob ein Peer-Knoten in der Blockchain von einem Angriff betroffen ist.
  • Blockchain-Netzwerke beruhen häufig auf Vertrauensgrundsätzen. Um das Vertrauen aufrechtzuerhalten, müssen die von Blockchain-Netzwerken verwalteten Daten fehlerfrei sein. Daher ist es von größter Bedeutung, potenzielle Fehler zu ermitteln, die durch böswillige Aktivitäten im Zusammenhang mit dem Blockchain-Netzwerk verursacht werden, und gleichzeitig sicherzustellen, dass das Vertrauen aufrechterhalten wird.
  • KURZDARSTELLUNG
  • Ausführungsformen der vorliegenden Offenbarung umfassen ein Verfahren, ein System und ein Computerprogrammprodukt zum Selbstprüfen eines Blockchain-Netzwerks. Ein Prozessor kann Prozessinformationen von einem Peer-Knoten in der selbstprüfenden Blockchain sammeln. Der Prozessor kann von den Prozessinformationen des Peer-Knotens ein Abbild (imprint) erzeugen. Der Prozessor kann die Abbilder eines Peer-Knotens mit einem Konsensabbild vergleichen, um einen oder mehrere Fehler zu erkennen. Der eine oder mehrere Fehler können darauf hinweisen, dass ein Peer-Knoten beeinträchtigt wurde.
  • Die vorstehende Kurzdarstellung ist nicht dazu gedacht, jede veranschaulichte Ausführungsform oder jede Implementierung der vorliegenden Offenbarung zu beschreiben.
  • Figurenliste
  • Die in der vorliegenden Offenbarung enthaltenen Zeichnungen sind in der Beschreibung enthalten und bilden einen Teil davon. Sie veranschaulichen Ausführungsformen der vorliegenden Offenbarung und dienen zusammen mit der Beschreibung dazu, die Grundgedanken der Offenbarung zu erläutern. Die Zeichnungen veranschaulichen lediglich bestimmte Ausführungsformen und beschränken die Offenbarung nicht.
    • 1A veranschaulicht eine beispielhafte Blockchain-Architektur gemäß Ausführungsformen der vorliegenden Offenbarung.
    • 1B veranschaulicht einen Blockchain-Transaktionsablauf gemäß Ausführungsformen der vorliegenden Offenbarung.
    • 2A zeigt ein beispielhaftes selbstprüfendes Blockchain-Netzwerk gemäß Ausführungsformen der vorliegenden Offenbarung.
    • 2B veranschaulicht ein Blockschaubild, das eine Ausführungsform zum Erzeugen eines Abbilds gemäß Ausführungsformen der vorliegenden Offenbarung zeigt.
    • 2C veranschaulicht ein Blockschaubild, das eine Ausführungsform einer Hackerangriff-Lokalisierung gemäß Ausführungsformen der vorliegenden Offenbarung zeigt.
    • 3 veranschaulicht einen Ablaufplan eines beispielhaften Verfahrens zum Konfigurieren einer selbstprüfenden Blockchain gemäß Ausführungsformen der vorliegenden Offenbarung.
    • 4A veranschaulicht eine Cloud-Cloud-Computing-Umgebung gemäß Ausführungsformen der vorliegenden Offenbarung.
    • 4B veranschaulicht Abstraktionsmodellschichten gemäß Ausführungsformen der vorliegenden Offenbarung.
    • 5 veranschaulicht ein Übersichts-Blockschaubild eines beispielhaften Computersystems, das zum Implementieren eines oder mehrerer der hier beschriebenen Verfahren, Tools und Module sowie der damit verbundenen Funktionen gemäß Ausführungsformen der vorliegenden Offenbarung verwendet werden kann.
  • Verschiedene Änderungen und andere Formen sind für die hier beschriebenen Ausführungsformen zwar möglich, die Besonderheiten sind jedoch beispielhaft in den Zeichnungen dargestellt und werden ausführlich beschrieben. Es wird jedoch darauf hingewiesen, dass die beschriebenen besonderen Ausführungsformen nicht in einem einschränkenden Sinn zu verstehen sind. Alle Änderungen, Äquivalente und Alternativen, die unter den Anwendungsbereich der Offenbarung fallen, sollen vielmehr mitaufgenommen werden.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Aspekte der vorliegenden Offenbarung beziehen sich allgemein auf die Sicherheit des Blockchain-Netzwerks und insbesondere auf Konfigurieren von Peer-Knoten im Blockchain-Netzwerk, um eine Selbstprüfungsfunktion durchzuführen und gleichzeitig das Vertrauen der Peers aufrechtzuerhalten. Private Blockchain-Netzwerke können hochsensible Informationen austauschen. Diese sensiblen Informationen müssen oft um jeden Preis geschützt werden, aufgrund des Charakters einiger Blockchain-Netzwerke (z.B. Blockchain-Netzwerke auf einer Peer-zu-Peer-Basis) können diese sensiblen Informationen jedoch Angreifern (z.B. Hacker) mit böswilligen Absichten offengelegt werden. Aufgrund des Charakters der Blockchain entzieht sich die Sicherheitsüberwachung im Allgemeinen der Kontrolle des Peer-Knotens. Da Blockchain immer bekannter wird, finden Hacker immer bessere Verfahren, um bestehende Anwendungen zu gefährden, anstatt herkömmliche Hacking-Verfahren anzuwenden (z.B. Einschleusen eines Virus in einen Blockchain-Server). Solche Hacking-Aktivitäten sind sehr schwer zu erkennen und können lange Zeit unentdeckt bleiben.
  • Hier beschriebene Ausführungsformen beziehen sich auf Blockchain-Probleme im Zusammenhang mit dem Ermitteln, ob ein Peer-Knoten Anwendungen beeinträchtigt hat (z.B. Hackerangriffe) und woher diese Hackerangriffe stammen. Es werden zwar Versuche unternommen, Hackerangriffe in Peer-Knoten der Blockchain zu ermitteln, diese Versuche erfordern jedoch häufig den Zugriff auf gemeinsam genutzte, sensible Informationen, die von der Blockchain verwaltet werden, und verringern das Vertrauen in das Blockchain-Netzwerk.
  • Es versteht sich, dass die unmittelbaren Komponenten, die in den Figuren hier allgemein beschrieben und veranschaulicht sind, in vielen verschiedenen Konfigurationen angeordnet und ausgeführt sein können. Die folgende ausführliche Beschreibung der Ausführungsformen eines Verfahrens, einer Vorrichtung, eines nichtflüchtigen, durch einen Computer lesbaren Mediums und/oder eines Systems, wie in den beigefügten Figuren dargestellt, soll daher den Anwendungsbereich der beanspruchten Anmeldung nicht einschränken, sondern stellt lediglich ausgewählte Ausführungsformen dar.
  • Die in dieser Beschreibung dargelegten unmittelbaren Merkmale, Strukturen oder Eigenschaften können in jeder geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert oder entfernt werden. Die Ausdrücke „beispielhafte Ausführungsformen“, „einige Ausführungsformen“ oder andere ähnliche Begriffe in dieser Beschreibung beziehen sich darauf, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform enthalten sein kann. Daher beziehen sich die Ausdrücke „beispielhafte Ausführungsformen“, „in einigen Ausführungsformen“, „in anderen Ausführungsformen“ oder ähnliche Begriffe in dieser Beschreibung nicht unbedingt alle auf dieselbe Gruppe von Ausführungsformen, und die beschriebenen Merkmale, Strukturen oder Eigenschaften können in geeigneter Weise in einer oder mehreren Ausführungsformen kombiniert oder entfernt werden. Weiterhin kann in den FIGUREN jede Verbindung zwischen Elementen eine Einweg- und/oder Hin- und Rückweg-Datenübertragung ermöglichen, auch wenn die dargestellte Verbindung ein einseitig oder zweiseitig gerichteter Pfeil ist. Ferner kann jede in den Zeichnungen dargestellte Einheit eine andere Einheit sein. Wenn zum Beispiel eine mobile Einheit gezeigt wird, die Informationen sendet, könnte auch eine drahtgebundene Einheit verwendet werden, um die Informationen zu senden.
  • Auch wenn in der Beschreibung der Ausführungsformen der Begriff „Nachricht“ verwendet wird, kann die Anwendung auf viele Arten von Netzwerken und Daten angewendet werden. Bestimmte Arten von Verbindungen, Nachrichten und Signalübertragungen können darüber hinaus zwar in beispielhaften Ausführungsformen dargestellt werden, die Anwendung ist jedoch nicht auf eine bestimmte Art von Verbindung, Nachricht und Signalübertragung beschränkt.
  • Hier werden ein Verfahren, ein System und ein Computerprogrammprodukt beschrieben, die eine selbstprüfende Blockchain verwenden, um zu ermitteln, ob ein Peer-Knoten gehackt wurde und wo in der Anwendung (z.B. Prozessinformationen) der Hackerangriff oder Fehler aufgetreten ist, während das Vertrauen in das Blockchain-Netzwerk aufrechterhalten wird. Ein kontinuierliches Vertrauen in das Blockchain-Netzwerk ist möglich, da sensible und geheime Informationen vertraulich bleiben können und keine Partei (z.B. Organisation oder Peer-Knoten) dafür verantwortlich ist, zu ermitteln, ob ein anderer Peer-Knoten von einem Hackerangriff betroffen ist.
  • In einigen Ausführungsformen verwenden das Verfahren, das System und/oder das Computerprogrammprodukt eine dezentrale Datenbank (z.B. eine Blockchain), bei der es sich um ein verteiltes Speichersystem handelt, das mehrere Knoten umfasst, die untereinander Daten austauschen. Die dezentrale Datenbank umfasst eine unveränderliche „Append-only“-Datenstruktur (append-only = nur hinzufügen), die einem Distributed Ledger ähnelt und in der Lage ist, Datensätze zwischen gegenseitig nichtvertrauenswürdigen Parteien zu verwalten. Die nichtvertrauenswürdigen Parteien werden hier als Peers oder Peer-Knoten bezeichnet. Jeder Peer verwaltet eine Kopie der Datenbanksätze, und kein Peer alleine kann die Datenbanksätze ändern, ohne dass darüber ein Konsens zwischen den verteilten Peers erzielt wird. Die Peers können beispielsweise ein Konsensprotokoll ausführen, um Blockchain-Speichertransaktionen zu validieren, die Speichertransaktionen in Blöcke zu gruppieren und eine Hash-Kette über die Blöcke zu erzeugen. Dieser Prozess führt zur Bildung des Ledger, indem die Speichertransaktionen so in eine Reihenfolge gebracht werden, wie es für die Konsistenz erforderlich ist.
  • In verschiedenen Ausführungsformen kann eine genehmigungspflichtige und/oder eine genehmigungsfreie Blockchain verwendet werden. Bei einer öffentlichen oder genehmigungsfreien Blockchain kann jeder teilnehmen, ohne dass eine bestimmte Identität erforderlich ist (z.B. die Anonymität bleibt gewahrt). Öffentliche Blockchains können native Kryptowährungen umfassen und verwenden einen Konsens auf der Grundlage verschiedener Protokolle wie z.B. Proof-of-Work. Andererseits stellt eine genehmigungspflichtige Blockchain-Datenbank sichere Interaktionen zwischen einer Gruppe von Entitäten bereit, die ein gemeinsames Ziel verfolgen, sich jedoch gegenseitig nicht vollständig vertrauen, z.B. Unternehmen, die Geldmittel, Waren, (private) Informationen und Ähnliches austauschen.
  • In einigen Ausführungsformen können das Verfahren, das System und/oder das Computerprogrammprodukt eine Blockchain verwenden, die eine beliebige, programmierbare Logik ausführt, die auf ein dezentrales Schema zur Datenspeicherung zugeschnitten ist und als „Smart Contracts“ der „Chaincodes“ bezeichnet wird. In einigen Fällen können spezielle Chaincodes für Verwaltungsfunktionen und Parameter zur Verfügung stehen, die als System-Chaincode bezeichnet werden. Das Verfahren, das System und/oder das Computerprogrammprodukt können weiterhin Smart Contracts verwenden, bei denen es sich um vertrauenswürdige verteilte Anwendungen handelt, die fälschungssichere Eigenschaften der Blockchain-Datenbank und eine zugrunde liegende Vereinbarung zwischen den Knoten nutzen, die als Endorsement (Bestätigung) oder Endorsement Policy (Bestätigungsrichtlinie) bezeichnet wird. Blockchain-Transaktionen, die dieser Anwendung zugehörig sind, können „bestätigt“ werden, bevor sie in der Blockchain festgeschrieben (committed) werden, während nichtbestätigte Transaktionen ignoriert werden.
  • Eine Endorsement Policy ermöglicht einem Chaincode, Endorser (Bestätiger) für eine Transaktion in Form eines Satzes von Peer-Knoten anzugeben, die für die Bestätigung notwendig sind. Wenn ein Client die Transaktion an die in der Endorsement Policy angegebenen Peers sendet, wird die Transaktion von den Peers ausgeführt, die spekulative Transaktionsergebnisse erzeugen. Wenn genügend Peers, die die Endorsement Policy erfüllen, identische Ausführungsergebnisse erzeugen, gilt die Transaktion als bestätigt. Nach dem Bestätigen beginnt eine Sortierphase für die Transaktionen, in der ein Konsensprotokoll verwendet wird, um eine geordnete Abfolge von bestätigten Transaktionen zu erstellen, die in Blöcken gruppiert sind. Zu den herkömmlich verwendeten Konsensprotokollen gehören First-in-First-out (FIFO) und Leader-/Follower-Protokolle (z.B. Absturz-Fe h lertole ra nzprotokolle).
  • In einigen Ausführungsformen können das Verfahren, das System und/oder das Computerprogrammprodukt Knoten verwenden, bei denen es sich um die Datenübertragungsentitäten des Blockchain-Systems handelt. Ein „Knoten“ kann eine logische Funktion in dem Sinne durchführen, dass mehrere Knoten unterschiedlichen Typs auf demselben physischen Server laufen können. Knoten werden in Vertrauensbereichen gruppiert und sind logischen Entitäten zugehörig, die sie auf verschiedene Weise steuern. Die Knoten können verschiedene Typen umfassen, z.B. einen Client- oder sendenden Client-Knoten, der einen Transaktionsaufruf an einen Endorser (z.B. einen Peer) sendet und Transaktionsvorschläge an einen Sortierdienst (z.B. einen Sortierknoten (ordering node)) übermittelt.
  • Ein anderer Typ von Knoten ist ein Peer-Knoten, der vom Client gesendete sortierte Transaktionen empfangen (z.B. vom Sortierdienst), die Transaktionen festschreiben und einen Zustand und eine Kopie des Ledger der Blockchain-Transaktionen verwalten kann. Peers können auch die Rolle eines Endorser übernehmen, was jedoch nicht zwingend erforderlich ist. Bei einem Sortierdienstknoten oder einem Sortierer handelt es sich um einen Knoten, der einen Sortierdienst ausführt, der einen Strom von bestätigten Transaktionen von Clients empfängt und einen Strom von sortierten Transaktionen sendet. Ein Sortierdienstknoten führt einen Datenübertragungsdienst für alle Peer-Knoten durch und implementiert eine Zustellungsgarantie, z.B. eine Übertragung an alle Peer-Knoten im System, wenn Transaktionen festgeschrieben/bestätigt werden und ein aktueller Zustand (World State) der Blockchain geändert wird, was ein anderer Name für die anfängliche Blockchain-Transaktion ist, die normalerweise Steuerungs- und Einrichtungsinformationen umfasst.
  • In einigen Ausführungsformen können das Verfahren, das System und/oder das Computerprogrammprodukt ein Ledger verwenden, bei dem es sich um eine sequenzierte, fälschungssichere Aufzeichnung aller Zustandswechsel einer Blockchain handelt. Zustandswechsel können sich aus Chaincode-Aufrufen (z.B. Transaktionen) ergeben, die von beteiligten Parteien (z.B. Client-Knoten, Sortierknoten, Endorser-Knoten, Peer-Knoten usw.) gesendet werden. Jede teilnehmende Partei (z.B. ein Peer-Knoten) kann eine Kopie des Ledger unterhalten. Eine Transaktion kann dazu führen, dass ein Satz von Asset-Schlüsselwertpaaren als ein oder mehrere Operanden im Ledger festgeschrieben werden, z.B. Erzeugen, Aktualisieren, Löschen und Ähnliches. Das Ledger umfasst eine Blockchain (auch als Chain bezeichnet), in der ein unveränderlicher, sequenzierter Datensatz in Blöcken gespeichert wird. Das Ledger umfasst auch eine Zustandsdatenbank, in der ein aktueller Zustand der Blockchain festgehalten wird.
  • In einigen Ausführungsformen können das hier beschriebene Verfahren, System und/oder Computerprogrammprodukt eine Chain verwenden, bei der es sich um ein Transaktionsprotokoll handelt, das als Hash-verknüpfte Blöcke strukturiert ist, wobei jeder Block eine Abfolge von N Transaktionen enthält, wobei N gleich oder größer als eins ist. Der Blockkopf umfasst einen Hash der Transaktionen des Blocks sowie einen Hash des Kopfes des vorherigen Blocks. Auf diese Weise können alle Transaktionen im Ledger sequenziert und kryptografisch miteinander verknüpft werden. Es ist daher nicht möglich, die Ledger-Daten zu manipulieren, ohne die Hash-Verknüpfungen zu beschädigen. Ein Hash eines zuletzt hinzugefügten Blockchain-Blocks stellt jede Transaktion in der Chain dar, die vor ihm stattgefunden hat, wodurch sichergestellt werden kann, dass sich alle Peer-Knoten in einem einheitlichen und vertrauenswürdigen Zustand befinden. Die Chain kann in einem Peer-Knoten-Dateisystem gespeichert werden (z.B. lokal, in einem angeschlossenen Speicher, in der Cloud usw.), wodurch der Append-only-Charakter der Arbeitslast der Blockchain wirksam unterstützt wird.
  • Der aktuelle Zustand des unveränderlichen Ledger stellt die neuesten Werte für alle Schlüssel dar, die im Transaktionsprotokoll der Chain enthalten sind. Da der aktuelle Zustand die neuesten Schlüsselwerte darstellt, die einem Kanal bekannt sind, wird er manchmal auch als „World State“ bezeichnet. Chaincode-Aufrufe führen mit den Daten des aktuellen Zustands des Ledger Transaktionen aus. Damit diese Chaincode-Interaktionen effizient sind, können die aktuellen Werte der Schlüssel in einer Zustandsdatenbank gespeichert werden. Die Zustandsdatenbank kann einfach eine indizierte Ansicht des Transaktionsprotokolls der Chain sein, daher kann sie jederzeit anhand der Chain neu erzeugt werden. Die Zustandsdatenbank kann automatisch wiederhergestellt (oder bei Bedarf erzeugt) werden, wenn der Peer-Knoten gestartet wird und bevor Transaktionen angenommen werden.
  • Die Blockchain unterscheidet sich von einer herkömmlichen Datenbank dadurch, dass die Blockchain kein zentraler Speicher, sondern ein dezentraler, unveränderlicher und sicherer Speicher ist, bei dem sich die Knoten an den Änderungen der Datensätze im Speicher beteiligen können. Zu einigen Eigenschaften, die charakteristisch für eine Blockchain sind und die zum Implementieren der Blockchain beitragen, gehören, ohne auf diese beschränkt zu sein, ein unveränderliches Ledger, Smart Contracts, Sicherheit, Datenschutz, Dezentralisierung, Konsens, Bestätigung, Zugänglichkeit usw., die hier weiter beschrieben werden. Gemäß verschiedenen Aspekten wird das hier beschriebene System aufgrund der unveränderlichen Verantwortlichkeit, der Sicherheit, des Datenschutzes, der zulässigen Dezentralisierung, der Verfügbarkeit von Smart Contracts, Bestätigungen und der Zugänglichkeit implementiert, die für die Blockchain charakteristisch und spezifisch sind.
  • Die Daten des Blockchain-Ledger sind insbesondere unveränderlich, was ein effizientes Verfahren zum Ermitteln von Abweichungen in einem Blockchain-Netzwerk bereitstellt. Die Verschlüsselung in der Blockchain stellt darüber hinaus Sicherheit bereit und sorgt für Vertrauenswürdigkeit. Der Smart Contract verwaltet den Zustand des Assets, um den Lebenszyklus zu beenden. Bei den beispielhaften Blockchains handelt es sich um genehmigungspflichtige, dezentrale Blockchains. Auf diese Weise kann jeder Endnutzer seine eigene Kopie des Ledger haben, auf die er zugreifen kann. In das Blockchain-Netzwerk können mehrere Organisationen (und Peers) eingebunden werden. Die Hauptorganisationen können als bestätigende Peers fungieren, um die Ergebnisse der Ausführung des Smart Contract sowie den Lese- und Schreibsatz zu validieren. Mit anderen Worten: die für die Blockchain charakteristischen Merkmale stellen eine effiziente Implementierung zum Verarbeiten einer privaten Transaktion in einem Blockchain-Netzwerk bereit.
  • Einer der Vorteile der beispielhaften Ausführungsformen besteht darin, dass die Funktionalität eines Datenverarbeitungssystems verbessert wird, indem ein Verfahren zum Verarbeiten einer privaten Transaktion in einem Blockchain-Netzwerk implementiert wird. Durch das hier beschriebene Blockchain-System kann ein Datenverarbeitungssystem (oder ein Prozessor in dem Datenverarbeitungssystem) Funktionen für das selbstprüfende Blockchain-Netzwerk, die es von einer oder mehreren Client-Anwendungen erhält, unter Verwendung von Blockchain-Netzwerken durchführen, indem es Zugriff auf Funktionen wie Distributed Ledger, Peers, Verschlüsselungstechnologien, MSP, Ereignisverarbeitung usw. bereitstellt. Die Blockchain ermöglicht es darüber hinaus, ein Geschäftsnetzwerk zu schaffen und Benutzer oder Organisationen für die Teilnahme einzubinden. Bei der Blockchain handelt es sich daher nicht nur um eine Datenbank. Die Blockchain verfügt über Funktionen, um ein Netzwerk von Benutzern und internen/externen Organisationen zu schaffen, die zusammenarbeiten und Dienstprozesse in Form von Smart Contracts (die einem oder mehreren Assets zugehörig sind) auszuführen.
  • Die beispielhaften Ausführungsformen stellen erhebliche Vorteile gegenüber einer herkömmlichen Datenbank bereit. Durch die Blockchain stellen die Ausführungsformen zum Beispiel unveränderliche Verantwortlichkeit, Sicherheit, Datenschutz, zulässige Dezentralisierung, Verfügbarkeit von Smart Contracts, Berechtigungen und Zugänglichkeit bereit, die für die Blockchain charakteristisch und spezifisch sind.
  • Eine herkömmliche Datenbank könnte nicht verwendet werden, um die beispielhaften Ausführungsformen zu implementieren, da sie nicht alle Parteien in das Netzwerk einbindet, keine vertrauenswürdige Zusammenarbeit ermöglicht und kein effizientes Speichern von digitalen Assets bereitstellt. Die herkömmliche Datenbank stellt kein fälschungssicheres Speichern und keinen Schutz der gespeicherten digitalen Assets bereit. Die hier beschriebenen, vorgeschlagenen Ausführungsformen, die Blockchain-Netzwerke verwenden, können daher nicht in einer herkömmlichen Datenbank implementiert werden.
  • Würde eine herkömmliche Datenbank zum Implementieren der beispielhaften Ausführungsformen verwendet, hätten die beispielhaften Ausführungsformen unnötige Nachteile wie die Suchfunktion, mangelnde Sicherheit und langsame Geschwindigkeit der Transaktionen zu verzeichnen. Die beispielhaften Ausführungsformen stellen somit eine spezifische Lösung für ein Problem in der Technik/auf dem Gebiet zum Prüfen (z.B. Selbstprüfen) eines Blockchain-Netzwerks bereit.
  • Mit Bezug nunmehr auf 1A ist eine Blockchain-Architektur 100 gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht. In einigen Ausführungsformen kann die Blockchain-Architektur 100 bestimmte Blockchain-Elemente enthalten, so beispielsweise eine Gruppe von Blockchain-Knoten 102. Die Blockchain-Knoten 102 können einen oder mehrere Blockchain-Knoten, z.B. die Peers 104 bis 110, umfassen (diese vier Knoten sind nur beispielhaft dargestellt). Diese Knoten sind an einer Reihe von Aktivitäten beteiligt, z.B. am Hinzufügen von Blockchain-Transaktionen und am Validierungsprozess (Konsens). Ein oder mehrere Peers 104 bis 110 können Transaktionen auf der Grundlage einer Endorsement Policy bestätigen und/oder empfehlen und einen Sortierdienst für alle Blockchain-Knoten 102 in der Architektur 100 bereitstellen. Ein Blockchain-Knoten kann eine Blockchain-Authentifizierung initiieren und versuchen, in ein unveränderliches Blockchain-Ledger zu schreiben, das in der Blockchain-Schicht 116 gespeichert ist, von der eine Kopie auch in der zugrunde liegenden physischen Infrastruktur 114 gespeichert sein kann. Die Blockchain-Konfiguration kann eine oder mehrere Anwendungen 124 umfassen, die mit Anwendungsprogrammierschnittstellen (APIs) 122 verbunden sind, um auf gespeicherten Programm-/Anwendungscode 120 (z.B. Chaincode, Smart Contracts usw.) zuzugreifen und diesen auszuführen, der entsprechend einer von den Teilnehmern gewünschten individuellen Konfiguration erzeugt werden kann und der seinen eigenen Zustand aufrechterhalten, seine eigenen Assets kontrollieren und externe Informationen empfangen kann. Dies kann als Transaktion implementiert und durch Anhängen an das Distributed Ledger auf allen Blockchain-Knoten 104 bis 110 implementiert werden.
  • Die Blockchain-Basis oder -Plattform 112 kann verschiedene Schichten von Blockchain-Daten, Diensten (z.B. kryptographische Vertrauensdienste, virtuelle Ausführungsumgebung usw.) und die zugrunde liegende physische Computerinfrastruktur umfassen, die dazu verwendet werden kann, neue Transaktionen zu empfangen und zu speichern und Prüfern, die auf Dateneinträge zugreifen wollen, den Zugriff bereitzustellen. Die Blockchain-Schicht 116 kann eine Schnittstelle zur Verfügung stellen, die den Zugriff auf die virtuelle Ausführungsumgebung bereitstellt, die erforderlich ist, um den Programmcode zu verarbeiten und die physische Infrastruktur 114 zu nutzen. Die kryptografischen Vertrauensdienste 118 können verwendet werden, um Transaktionen wie den Austausch von Assets zu überprüfen und Informationen vertraulich zu halten.
  • Die Blockchain-Architektur 100 von 1A kann Programm-/ Anwendungscode 120 über eine oder mehrere von der Blockchain-Plattform 112 zur Verfügung gestellte Schnittstellen und bereitgestellte Dienste verarbeiten und ausführen. Der Code 120 kann Assets in der Blockchain steuern. Der Code 120 kann beispielsweise Daten speichern und übertragen und von den Peers 104 bis 110 in Form eines Smart Contract und eines zugehörigen Chaincodes mit Bedingungen oder anderen Codeelementen ausgeführt werden, die seiner Ausführung unterliegen. In einem nichteinschränkenden Beispiel können Smart Contracts erzeugt werden, um das Übertragen von Ressourcen, das Erzeugen von Ressourcen usw. auszuführen. Die Smart Contracts können ihrerseits dazu verwendet werden, Regeln zu identifizieren, die den Autorisierungs- und Zugriffsanforderungen und der Nutzung des Ledger zugehörig sind. Beispielsweise können die Gruppentransaktionsinformationen 126 von einer oder mehreren Verarbeitungsentitäten (z.B. virtuelle Maschinen) verarbeitet werden, die in der Blockchain-Schicht 116 enthalten sind. Das Ergebnis 128 kann eine Mehrzahl von verknüpften, gemeinsam genutzten Dokumenten sein (wobei jedes verknüpfte, gemeinsam genutzte Dokument z.B. die Ausgabe eines Smart Contract in Bezug auf die Gruppentransaktionsinformationen 126 aufzeichnet usw.). Die physische Infrastruktur 114 kann zum Abrufen der hier beschriebenen Daten oder Informationen verwendet werden.
  • Ein Smart Contract kann über eine hochentwickelte Anwendung und Programmiersprache erzeugt und dann in einen Block in der Blockchain geschrieben werden. Der Smart Contract kann einen ausführbaren Code enthalten, der in einer Blockchain (z.B. einem verteilten Netzwerk von Blockchain-Peers) registriert, gespeichert und/oder repliziert wird. Eine Transaktion ist eine Ausführung des Codes des Smart Contract, die als Reaktion auf Bedingungen, die dem Smart Contract zugehörig sind, durchgeführt werden kann. Das Ausführen des Smart Contract kann (eine) vertrauenswürdige Änderung(en) eines Zustands eines digitalen Blockchain-Ledger auslösen. Die durch das Ausführen des Smart Contract verursachte(n) Änderung(en) des Blockchain-Ledger kann (können) automatisch im gesamten verteilten Netzwerk von Blockchain-Peers durch ein oder mehrere Konsensprotokolle repliziert werden.
  • Der Smart Contract kann Daten im Format von Schlüsselwertpaaren in die Blockchain schreiben. Darüber hinaus kann der Code des Smart Contract die in einer Blockchain gespeicherten Werte lesen und in Operationen der Anwendung verwenden. Der Code des Smart Contract kann die Ausgabe verschiedener logischer Operationen in die Blockchain schreiben. Der Code kann dazu verwendet werden, eine temporäre Datenstruktur in einer virtuellen Maschine oder einer anderen Datenverarbeitungsplattform zu erzeugen. Daten, die in die Blockchain geschriebenen werden, können öffentlich sein und/oder verschlüsselt und als vertraulich behandelt werden. Die temporären Daten, die vom Smart Contract verwendet/erzeugt werden, werden von der bereitgestellten Ausführungsumgebung im Speicher gespeichert und dann gelöscht, sobald die für die Blockchain benötigten Daten identifiziert sind.
  • Ein Chaincode kann die Code-Interpretation eines Smart Contract umfassen und zusätzliche Funktionen enthalten. Wie hier beschrieben, kann es sich bei dem Chaincode um einen Programmcode handeln, der in einem Datenverarbeitungsnetzwerk implementiert wird, wo er von den Chain-Validierern im Rahmen eines Konsensverfahrens ausgeführt und validiert wird. Der Chaincode empfängt einen Hash und ruft aus der Blockchain einen Hash ab, der der Datenvorlage zugehörig ist, die durch die Verwendung eines zuvor gespeicherten Merkmalsextraktors erzeugt wurde. Stimmen die Hashes der Hash-Kennung und der aus den gespeicherten Kennungsvorlagedaten erzeugte Hash überein, sendet der Chaincode einen Autorisierungsschlüssel an den angeforderten Dienst. Der Chaincode kann Daten in die Blockchain schreiben, die den kryptografischen Einzelheiten zugehörig sind (z.B. zum Bestätigen der Gruppe von Transaktionen, Ermitteln eines Konflikts zwischen einer oder mehreren Transaktionen in der Gruppe von Transaktionen usw.).
  • 1B veranschaulicht ein Beispiel eines herkömmlichen Blockchain-Transaktionsablaufs 150 zwischen Knoten der Blockchain gemäß einer beispielhaften Ausführungsform. Mit Bezug auf 1B kann der Transaktionsablauf einen Transaktionsvorschlag 191 enthalten, der von einem Client-Anwendungsknoten 160 an einen oder mehrere bestätigende Peer-Knoten 181 gesendet wird (z.B. in einigen Ausführungsformen kann es sich bei dem Transaktionsvorschlag 191 um eine Transaktionsüberprüfungsanforderung und/oder eine Konfliktüberprüfungsanforderung handeln). Der bestätigende Peer 181 kann die Client-Signatur prüfen und eine Chaincode-Funktion ausführen, um die Transaktion zu initiieren. Die Ausgabe kann die Chaincode-Ergebnisse, einen Satz von Schlüssel/Wert-Versionen, die im Chaincode gelesen wurden (Lesesatz), und den Satz von Schlüsseln/Werten, die in den Chaincode geschrieben wurden (Schreibsatz), umfassen. Die Antwort 192 auf den Vorschlag wird zusammen mit einer Bestätigungssignatur (falls genehmigt) an den Client 160 zurückgesendet. Der Client 160 stellt die Bestätigungen in den Transaktionsnutzdaten 193 zusammen und übertragt diese an einen Sortierdienstknoten 184. Der Sortierdienstknoten 184 gibt dann die sortierten Transaktionen als Blöcke an alle Peers 181 bis 183 in einem Kanal aus. Vor dem Festschreiben in der Blockchain kann jeder Peer 181 bis 183 die Transaktion validieren. So können die Peers beispielsweise die Endorsement Policy überprüfen, um sicherzustellen, dass die richtige Anzahl der angegebenen Peers die Ergebnisse signiert und die Signaturen anhand der Transaktionsnutzdaten 193 authentifiziert hat.
  • Mit erneutem Bezug auf 1B initiiert der Client-Knoten 160 die Transaktion 191, indem er eine Anforderung an den Peer-Knoten 181 erzeugt und sendet, bei dem es sich um einen Endorser handelt. Der Client 160 kann eine Anwendung umfassen, die ein unterstütztes Software-Entwicklungskit (software development kit - SDK) nutzt, das eine verfügbare API verwendet, um einen Transaktionsvorschlag 191 zu erzeugen. Bei dem Vorschlag handelt es sich um eine Anforderung, eine Chaincode-Funktion aufzurufen, damit Daten gelesen und/oder in das Ledger geschrieben werden können (z.B. neue Schlüsselwertpaare für die Assets schreiben). Das SDK kann das Paket des Transaktionsvorschlags 191 in ein geeignetes Architekturformat verkleinern (z.B. Protokollpuffer über einen Fernprozeduraufruf (remote procedure call - RPC)) und die kryptografischen Berechtigungsnachweise des Clients verwenden, um eine eindeutige Signatur für den Transaktionsvorschlag 191 zu erzeugen.
  • Als Reaktion darauf kann der bestätigende Peer-Knoten 181 prüfen, ob (a) der Transaktionsvorschlag 191 korrekt formatiert ist, (b) die Transaktion nicht bereits in der Vergangenheit gesendet wurde (Schutz vor Wiederholungsangriffen), (c) die Signatur gültig ist und (d) dass der Sender (im Beispiel der Client 160) ordnungsgemäß berechtigt ist, die vorgeschlagene Operation auf diesem Kanal durchzuführen. Der bestätigende Peer-Knoten 181 kann die Eingaben des Transaktionsvorschlags 191 als Argumente für die aufgerufene Chaincode-Funktion verwenden. Der Chaincode wird dann auf der Grundlage einer Datenbank mit dem aktuellen Zustand ausgeführt, um Transaktionsergebnisse zu erzeugen, darunter ein Antwortwert, ein Lesesatz und ein Schreibsatz. Das Ledger wird zu diesem Zeitpunkt jedoch nicht aktualisiert. In einigen Ausführungsformen werden der Satz von Werten zusammen mit der Signatur des bestätigenden Peer-Knotens 181 als Antwort 192 auf den Vorschlag an das SDK des Clients 160 zurückgesendet, der die Nutzdaten für die Anwendung zur Nutzung analysiert.
  • Als Reaktion darauf überprüft/verifiziert die Anwendung des Clients 160 die Signaturen der bestätigenden Peers und vergleicht die Vorschlagsantworten, um zu ermitteln, ob die Vorschlagsantwort dieselbe ist. Würde der Chaincode nur das Ledger abfragen, würde die Anwendung die Antwort auf die Abfrage überprüfen und die Transaktion in der Regel nicht an den Sortierdienstknoten 184 senden. Beabsichtigt die Client-Anwendung, die Transaktion zum Aktualisieren des Ledger an den Sortierknotendienst 184 zu senden, ermittelt die Anwendung vor dem Senden, ob die angegebene Endorsement Policy erfüllt ist (d.h., ob eine Transaktionsüberprüfungsanforderung angenommen wurde). In diesem Fall kann der Client nur eine von mehreren an der Transaktion beteiligten Parteien aufnehmen. In diesem Fall kann jeder Client seinen eigenen bestätigenden Knoten haben, und jeder bestätigende Knoten muss die Transaktion bestätigen. Die Architektur ist so angelegt, dass die Endorsement Policy auch dann von den Peers bestätigt und in der Phase des Festschreibens und Validierens aufrechterhalten wird, wenn eine Anwendung sich dafür entscheidet, Antworten nicht zu überprüfen oder ansonsten eine nichtbestätigte Transaktion weiterzuleiten.
  • Nach erfolgreichem Überprüfen stellt der Client 160 in Schritt 193 Bestätigungen zu einer Transaktion zusammen und sendet den Transaktionsvorschlag 191 und die Antwort in einer Transaktionsnachricht an den Sortierknoten 184. Die Transaktion kann die Lese-/ Schreibsätze, die Signaturen der bestätigenden Peers und eine Kanal-ID enthalten. Der Sortierknoten 184 muss nicht den gesamten Inhalt einer Transaktion überprüfen, um seine Operation durchzuführen; stattdessen kann der Sortierknoten 184 einfach Transaktionen von allen Kanälen im Netzwerk empfangen, sie nach Kanal sortieren und Blöcke von Transaktionen pro Kanal erzeugen.
  • Die Blöcke der Transaktion werden vom Sortierknoten 184 an alle Peer-Knoten 181 bis 183 im Kanal übermittelt. Die Transaktionen 194 im Block werden validiert, um sicherzustellen, dass die Endorsement Policy erfüllt ist und dass keine Änderungen am Zustand des Ledger für die Variablen des Lesesatzes vorgenommen wurden, seit der Lesesatz durch das Ausführen der Transaktion erzeugt wurde. Transaktionen im Block werden als gültig oder ungültig gekennzeichnet. Darüber hinaus fügt jeder Peer-Knoten 181 bis 183 in Schritt 195 den Block an die Chain des Kanals an, und für jede gültige Transaktion werden die Schreibsätze in der aktuellen Zustandsdatenbank festgeschrieben. Es wird ein Ereignis ausgelöst, um die Client-Anwendung darüber zu informieren, dass die Transaktion (der Aufruf) unveränderlich an die Chain angehängt wurde, und um mitzuteilen, ob die Transaktion für gültig oder ungültig erklärt wurde. Das Blockchain-Ledger wird mit gültigen Transaktionen und ihren zugehörigen Werten aktualisiert, ungültige Transaktionen werden zwar festgeschrieben, das Blockchain-Ledger wird jedoch nicht mit den ungültigen Transaktionen aktualisiert.
  • Mit Bezug auf 2A ist ein beispielhaftes selbstprüfendes Blockchain-Netzwerk 200 zum Prüfen und Ermitteln möglicher böswilliger Aktivitäten (z.B. Würmer und Viren) in einem Peer-Knoten 202 gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Böswillige Aktivitäten, die im Folgenden allgemein als Fehler und/oder Hackerangriffe bezeichnet werden, können verschiedene Formen von Malware annehmen, darunter Viren, Würmer, Rogue-Software oder eine Kombination davon, ohne auf diese beschränkt zu sein. Hier offenbarte Ausführungsformen beziehen sich zwar häufig auf das selbstprüfende Blockchain-Netzwerk 200 als ein genehmigungspflichtiges Blockchain-Konsortium (z.B. Hyperledger-Fabric-Blockchain-Netzwerk), das selbstprüfende Blockchain-Netzwerk 200 kann jedoch so konfiguriert sein, dass es in jeder Art von Blockchain-Konsortium (z.B. genehmigungsfreie Blockchain) mit Peer-Knoten oder Knoten funktioniert, die ähnliche Rollenfunktionen bereitstellen. Das selbstprüfende Blockchain-Netzwerk 200 ermöglicht es verschiedenen Peers im Blockchain-Konsortium, zu ermitteln, ob Malware/Fehler (z.B. Hackerangriffe und/oder feindselige/böswillige Aktivitäten) einen oder mehrere der Peer-Knoten beeinträchtigen, ohne das Vertrauen im Blockchain-Konsortium zu gefährden. Hier erörterte Ausführungsformen ermöglichen ein Erkennen böswilliger Aktivitäten in Echtzeit sowie Verfahren in Verbindung mit einem Lokalisieren des Ortes, an dem die böswillige Aktivität die Integrität des Blockchain-Konsortiums beeinträchtigt hat.
  • In Ausführungsformen kann das selbstprüfende Blockchain-Netzwerk 200 den Peer-Knoten 202 und eine Abbildrichtlinie 203 umfassen. Der Peer-Knoten 202 kann so konfiguriert sein, dass er ein Abbildsammelmodul 204, ein Prüfmodul 206 und ein Hackerangriff-Lokalisierungsmodul 208 enthält. Während das Prüfmodul 206 und das Hackerangriff-Lokalisierungsmodul 208 in einigen Ausführungsformen (z.B. wie in 2A gezeigt) getrennt vom Abbildsammelmodul 204 konfiguriert sind, sind das Prüfmodul 206 und das Hackerangriff-Lokalisierungsmodul 208 in anderen Ausführungsformen Teilkomponenten des Abbildsammelmoduls 204. Verschiedene Ausführungsformen werden hier in Bezug auf jedes Modul (z.B. Abbildsammelmodul 204, Prüfmodul 206 und Hackerangriff-Lokalisierungsmodul 208) erörtert. Im Allgemeinen umfasst jeder teilnehmende Peer-Knoten (z.B. Peer-Knoten 202): i) ein Abbildsammelmodul 204, das so konfiguriert ist, dass es ein Abbild erzeugt (z.B. Abbild 220), das für den Peer-Knoten spezifisch ist, in dem sich das jeweilige Modul befindet, und die von anderen teilnehmenden Knoten erzeugten Abbilder sammelt; ii) ein Prüfmodul 206, das so konfiguriert ist, dass es einen Konsens unter den gesammelten Abbildern ermittelt und jedes Abbild mit dem Konsensabbild vergleicht; iii) ein Hackerangriff-Lokalisierungsmodul 208, das so konfiguriert ist, dass es Abbilder vom Prüfmodul 206 empfängt, die nicht mit dem Konsensabbild übereinstimmen, und ermittelt, wo in den Prozessinformationen des Peer-Knotens der Hackerangriff aufgetreten ist.
  • Hier offenbarte Ausführungsformen beziehen sich zwar häufig auf einen einzelnen Peer-Knoten (z.B. Peer-Knoten 202), das selbstprüfende Blockchain-Netzwerk 200 kann jedoch eine beliebige Anzahl von ähnlich konfigurierten Peer-Knoten umfassen. Diese Ausführungsformen stellen das selbstprüfende Blockchain-Netzwerk 200 allgemein auf der Ebene der Peer-Knoten dar und sollten nicht als Blockchain-Konsortium mit nur einem Peer-Knoten verstanden werden. In Ausführungsformen können das selbstprüfende Blockchain-Netzwerk 200 und die hier offenbarten Ausführungsformen auf jeden Peer-Knoten (z.B. Peer-Knoten 202) im Blockchain-Konsortium angewendet werden. In diesen Ausführungsformen ist jeder Peer-Knoten ähnlich konfiguriert (z.B. wie in den Verweisen auf den Peer-Knoten 202 offenbart), um eine konsistente und wirksame Selbstprüfung für das gesamte Netzwerk durchzuführen. Wie hier erwähnt, kann das selbstprüfende Blockchain-Netzwerk 200 in einem genehmigungspflichtigen Blockchain-Konsortium konfiguriert sein. Genehmigungspflichtige Blockchains können so konfiguriert sein, dass sie mehrere Organisationen haben, die jeweils über einen oder mehrere Peer-Knoten in ihren jeweiligen Rechenzentren verfügen können.
  • In einigen Ausführungsformen kann das selbstprüfende Blockchain-Netzwerk 200 eine Abbildrichtlinie 203 umfassen. In Ausführungsformen mit einer Abbildrichtlinie 203 kann die Abbildrichtlinie 203 Standards und Bedingungen enthalten, die jeder Peer-Knoten 202, der das selbstprüfende Blockchain-Netzwerk 200 aufweist, beim Durchführen von Selbstprüfungsfunktionen (z.B. Erzeugen von Abbildern) befolgen und implementieren muss. Die Abbildrichtlinie 203 wird hier im Einzelnen erörtert, wobei die Abbildrichtlinie 203 Bedingungen bereitstellt, die jeder Peer-Knoten 202 befolgen muss, um sicherzustellen, dass die Ergebnisse der Selbstprüfungsfunktionen wiederholbar sind und konsistent auf alle Peer-Knoten 202 im Blockchain-Netzwerk angewendet werden. Die Abbildrichtlinie 203 kann zum Beispiel Bedingungen und Regeln bereitstellen, die befolgt werden müssen, damit jeder Peer-Knoten 202 ein Abbild erzeugt (z.B. welche Daten/Informationen Prozessinformationen 212 darstellen, die mit Bezug auf 2B erörtert werden), ermittelt, wie ein Konsensabbild festgelegt wird und wie der Peer-Knoten 202 und/oder das selbstprüfende Blockchain-Netzwerk 200 reagieren, wenn im Abbild des Peer-Knotens 202 ein oder mehrere Fehler (z.B. Hackerangriffe) identifiziert werden.
  • In Ausführungsformen kann der Peer-Knoten 202 ein Abbildsammelmodul 204 enthalten. Das Abbildsammelmodul 204 kann sich im Betriebssystemkernel des Peer-Knotens 202 befinden. In diesen Ausführungsformen, in denen das Abbildsammelmodul 204 im Betriebssystemkernel des Peer-Knotens 202 implementiert ist, ist das Abbildsammelmodul 204 geschützt, und es wird verhindert, dass Anwendungsprogramme oder weniger kritische Komponenten des Betriebssystems des Peer-Knotens 202 darauf zugreifen, die von Malware/Fehlern (z.B. Hackerangriffen) betroffen sein könnten. In Ausführungsformen kann das Abbildsammelmodul 204 Prozessinformationen vom Peer-Knoten 202 sammeln.
  • In einigen dieser Ausführungsformen können die Prozessinformationen zwar in einem oder mehreren Prozessadressräumen im Adressraum des Betriebssystemkernels gespeichert werden, in anderen Ausführungsformen können Prozessinformationen jedoch in einem oder mehreren Prozessadressräumen außerhalb des Betriebssystemkernels des Peer-Knotens 202 gespeichert werden. In Ausführungsformen, in denen die Prozessinformationen in einem oder mehreren Prozessadressräumen außerhalb des Betriebssystemkernels gespeichert werden, kann das Abbildsammelmodul so konfiguriert sein, dass es die Prozessinformationen aus den entsprechenden Prozessadressräumen sammelt. Der Peer-Knoten 202 kann auch jede Art von Computersicherheitstechnik wie Address Space Layout Randomization (Zufallsgestaltung des Adressraumaufbaus, ASLR) verwenden, um Schwachstellen in Bezug auf Datenverluste im Speicher zu verringern oder zu beseitigen. Durch die Verwendung solcher Computersicherheitstechniken wird sichergestellt, dass Angreifer ihre böswilligen Aktivitäten nicht verschleiern oder verbergen können, während das selbstprüfende Blockchain-Netzwerk 200 Prüfungsfunktionen durchführt.
  • Ein Angreifer ist ein Akteur, der Hackerangriffe und Malware in dem selbstprüfenden Blockchain-Netzwerk 200 durchführt. Ein Angreifer kann zwar Parteien außerhalb des Blockchain-Konsortiums zugehörig sein, diese Akteure oder Aktivitäten können manchmal jedoch von böswilligen Peer-Knoten im selbstprüfenden Blockchain-Netzwerk 200 ausgehen. Angreifer versuchen oft, verschiedene Aspekte der Blockchain zu unterlaufen, indem sie ihre böswilligen Aktivitäten geheim halten. Allgemein gilt: Je länger die böswillige Aktivität im Verborgenen stattfindet, desto größer ist die Chance, dass der Angreifer sein gewünschtes Ziel erreicht. In Ausführungsformen können ASLR oder andere ähnliche Computersicherheitstechniken die den Prozessinformationen 212 (z.B. darunter ausführbarer Code, Stack, HEAP und/oder Bibliotheken) zugehörigen Adressräume zufällig anordnen und es einem Angreifer erschweren, bestimmte Adressräume vorherzusagen. Wenn ein Angreifer wie ein böswilliger Peer-Knoten 202 aus einer Gruppe von Peer-Knoten 202 die Adressräume der Prozessinformationen 212, die dem Peer-Knoten 202 zugehörig sind, vorhersagen könnte, könnte ein Angreifer (z.B. der böswillige Peer-Knoten 202) ermitteln, welche Prozessinformationen 212 für nichtgehackte Prozesse repräsentativ sind (z.B. Prozessinformationen, die nicht von Fehlern/Hackerangriffen oder böswilligen Aktivitäten betroffen sind), und ein gefälschtes Abbild erzeugen, das Abbilder (z.B. 220) nachahmt, die nicht darauf hinweisen, dass ein Hackerangriff stattgefunden hat. Indem Adressräume schwerer vorhersagbar gemacht werden, kann das selbstprüfende Blockchain-Netzwerk 200 somit Selbstprüfungsfunktionen durchführen und sicherstellen, dass jeder teilnehmende Peer-Knoten 202 den Ergebnissen traut, die der Selbstprüfung zugehörig sind. In Ausführungsformen kann das Abbildsammelmodul 204 auf die ASLR-Positionierung hingewiesen werden, indem es in das Laufzeit-Ladeprogramm eingebunden wird, das dem Peer-Knoten 202 zugehörig ist.
  • In Ausführungsformen kann der Peer-Knoten 202 die vom Abbildsammelmodul 204 gesammelten Prozessinformationen verwenden, um ein Abbild (z.B. das in 2B gezeigte Abbild 220) zu erzeugen, das repräsentativ für die verschiedenen Prozessinformationen (z.B. die in 2B gezeigten Prozessinformationen) ist, die von dem Abbildsammelmodul 204 gesammelt werden. Ein Abbild kann repräsentativ für die Prozessinformationen sein, die während der Lebensdauer des Peer-Knotens 202 gesammelt wurden, oder alternativ für die Prozessinformationen, die während eines bestimmten Zeitraums gesammelt wurden. In Ausführungsformen kann die Abbildrichtlinie 203 festlegen, wie oft die Prozessinformationen von jedem Peer-Knoten 202 gesammelt werden. Die Abbildrichtlinie 203 kann zum Beispiel die Bedingung bereitstellen, dass Prozessinformationen nach einer bestimmten Zeitspanne oder nachdem der Peer-Knoten 202 eine bestimmte Anzahl von Prozessinformationseinträgen gesammelt hat (z.B. ein Abbild wird nach 10 oder 100 verschiedenen Prozessinformationseinträgen erzeugt), gesammelt werden. Ein Abbild kann zwar auf verschiedene Weise erzeugt werden, einige beispielhafte Ausführungsformen für das Erzeugen eines Abbilds werden jedoch mit Bezug auf 2B erörtert.
  • 2B stellt beispielhafte Ausführungsformen bereit, die zeigen, wie das Abbildsammelmodul 204 ein Abbild (z.B. Abbild 220) gemäß Ausführungsformen der vorliegenden Offenbarung erzeugen kann. Wie in 2B gezeigt, kann das Abbildsammelmodul 204 die Prozessinformationen 212 von dem Prozessadressraum 210 sammeln. Der Prozessadressraum/die Prozessadressräume 210 können Adressräume und Prozessinformationen (z.B. Prozessinformationen 212) darstellen, die im Betriebssystemkernel des Peer-Knotens 202, außerhalb des Betriebssystemkernels des Peer-Knotens 202 oder in einer beliebigen Kombination davon gesammelt werden. Die Prozessinformationen 212 können sich allgemein auf Informationen und Daten beziehen, die beim Durchführen von Routine-Blockchain-Funktionen durch den Peer-Knoten 202 erzeugt wurden, und können jede Art von Daten/Informationen enthalten (z.B. abhängig von den Bedingungen der Abbildrichtlinie 203). Die Prozessinformationen 212 können zwar jede Art von Daten/Informationen enthalten, diese Daten/Informationen sind jedoch häufig von einer Art, die betroffen wäre, wenn ein Hackerangriff (z.B. Fehler) aufgetreten wäre. In Ausführungsformen kann das Abbild 220 unter Verwendung jeder Art von Prozessinformationen 212 wie hier erwogen erzeugt werden, oder es kann von weniger als allen verfügbaren Arten von Prozessinformationen 212 erzeugt werden. In einigen Ausführungsformen können die Prozessinformationen 212 zum Beispiel Arten von Prozessinformationen wie Code, Bibliotheken, Transaktionsmetadaten und Daten umfassen, die in anderen Speicherbereichen im Betriebssystem des Peer-Knotens 202 (z.B. HEAP) gespeichert sind, während in anderen Ausführungsformen das Abbildsammelmodul 204 das Abbild 220 erzeugen kann, indem es nur eine Art von Prozessinformationen 212 verwendet, z.B. eine bestimmte Art von Code (z.B. ausführbare Code-Segmente). In einigen Ausführungsformen kann sich Code sowohl auf ausführbare Code-Segmente (z.B. Code 0, Code 1, Code 2) und Daten-Code-Segmente beziehen und beides einschließen, oder die gesammelten Prozessinformationen 212 können in anderen Ausführungsformen entweder in ausführbaren Code-Segmenten oder Daten-Code-Segmenten enthalten sein. In Ausführungsformen kann die Abbildrichtlinie 203 dem Peer-Knoten 202 Bedingungen dafür bereitstellen, welche Daten/Informationen als Prozessinformationen 212 anzusehen sind und welche Daten/Informationen beim Erzeugen eines Abbilds unberücksichtigt bleiben sollen. Ohne diese Konsistenz würde sich jeder Peer-Knoten 202 im selbstprüfenden Blockchain-Netzwerk 200 auf seine eigene Definition von Prozessinformationen 212 verlassen, unabhängig von anderen Peers, und würde wahrscheinlich unterschiedliche Daten/Informationen in das Abbild 220 aufnehmen. Um dieses Beispiel fortzusetzen: Wenn jeder Peer-Knoten ein Abbild unter Verwendung unterschiedlicher Daten/Informationen erzeugt, würde jeder Peer-Knoten wahrscheinlich ein anderes Abbild erzeugen. Wenn jedes von einem Peer-Knoten 202 erzeugte Abbild anders ist, kann kein Konsens zwischen den erzeugten Abbildern festgestellt werden, und die Selbstprüfungsfunktion kann nicht durchgeführt werden.
  • In Ausführungsformen kann das Abbildsammelmodul 204 das Abbild 220 unter Verwendung einer oder mehrerer Hashing-Iterationen erzeugen. Fachleuten ist bekannt, dass sich Hashing allgemein auf das Anwenden einer Hash-Funktion auf eine Zeichenkette (z.B. Prozessinformationen 212) und das Umwandeln der Zeichenkette in einen kürzeren Wert oder einen Wert fester Länge beziehen kann, der für die ursprüngliche Zeichenkette repräsentativ ist. Wenn Code 0 und Code 1 im Prozessadressraum 210 in dem in 2B dargestellten Beispiel genau die gleiche Zeichenkette enthalten würden und sowohl Code 0 als auch Code 1 mit der gleichen Hash-Funktion gehasht würden, wären alle sich daraus ergebenden Hash-Prozessinformationen 214 identisch. Wenn Code 0 und Code 1 in diesem Fall jedoch um ein oder mehrere Zeichen voneinander abweichen würden, wären die beiden sich ergebenden Hash-Prozessinformationen 214 unterschiedlich. Das Abbildsammelmodul 204 kann so konfiguriert sein, dass es jede verfügbare Hash-Funktion oder Kombination von Hash-Funktionen verwendet.
  • In 2B kann das Abbildsammelmodul 204 so konfiguriert sein, dass es einen Merkle-Baum 216 und eine Merkle-Wurzel 218 erzeugt, indem es die Seiten der Prozessinformationen 214 Stück für Stück hasht. Das sich ergebende Abbild 220, das vom Abbildsammelmodul 204 erzeugt wird, kann zwar unterschiedlich komplex sein, das Abbild 220 sollte jedoch repräsentativ für alle gesammelten Prozessinformationen 212 sein. In einigen Ausführungsformen kann es sich daher bei dem Abbild 220 einfach um eine Merkle-Wurzel 218 handeln. In anderen Ausführungsformen kann das Abbild 220 eine Liste jeder gehashten Seite enthalten, die den erzeugten Merkle-Baum 216 oder einen Teilsatz des erzeugten Merkle-Baums 216 in einer bestimmten Reihenfolge aufweist. Das Abbild 220 zeigt wie in 2B dargestellt ein Abbild, das in einer bestimmten Reihenfolge angeordnet ist. Wie in 2B gezeigt, kann das Abbild 220 zum Beispiel eine Kombination von Komponenten enthalten, die in einer bestimmten Reihenfolge angeordnet sind. Das Abbild 220 kann mit der Merkle-Wurzel 218 beginnen, gefolgt von einzelnen gehashten Generationenseitenblöcken.
  • In einigen Ausführungsformen kann jedes Abbild 220 mit einem oder mehreren Teilen von Metadaten enden. Diese Metadaten können Daten/Informationen enthalten, die dem Erzeugen von Abbildern und/oder Prozessinformationen 212 zugehörig sind. In diesen Ausführungsformen können diese Metadaten Informationen darüber enthalten, wie das ursprüngliche Abbild erzeugt wurde. Diese Metadaten können zum Beispiel einen Zeitstempel enthalten, der angibt, wann das Abbild 220 erzeugt wurde, einen Zähler zum Unterscheiden von unterschiedlichen Abbildern, die von demselben Peer-Knoten erzeugt wurden, Informationen darüber, wie die verschiedenen Seiten von Prozessinformationen 212 angeordnet sind und wie viele verschiedene Teile von Prozessinformationen 212 ursprünglich vom Peer-Knoten 202 gesammelt wurden, bevor das Abbild 220 erzeugt wurde. In einigen Ausführungsformen können diese Metadaten vom Prüfmodul 206 und Hackerangriff-Lokalisierungsmodul 208 verwendet werden, um den Hackerangriff/Fehler zu ermitteln und zu lokalisieren. In Ausführungsformen kann die Abbildrichtlinie 203 jedem Peer-Knoten 202 Bedingungen in Verbindung damit bereitstellen, welche Hash-Funktion(en) verwendet werden sollte(n), um das Abbild 220 zu erzeugen, welche gehashten Komponenten im Abbild 220 verwendet werden sollten (z.B. Merkle-Wurzel 218 und/oder Merkle-Baum 216), ob es mehr als eine gehashte Komponente gibt, wie jede Komponente sequenziert werden sollte oder eine beliebige Kombination davon.
  • In Ausführungsformen können das Abbildsammelmodul 204 und das Prüfmodul 206 so konfiguriert sein, dass sie zusammenarbeiten, um Prüffunktionen durchzuführen. In Ausführungsformen kann das Abbildsammelmodul 204 durch Verwendung verschiedener Verschlüsselungsmodi sicherstellen, dass das erzeugte Abbild 220 vor Angreifern geschützt ist. Das Abbildsammelmodul 204 kann zum Beispiel einen zufälligen symmetrischen Schlüssel zum Verschlüsseln des Abbilds 220 verwenden. Durch Verschlüsseln des Abbilds 220 kann das Abbildsammelmodul 204 Angriffe verringern oder verhindern, dass ein Abbild eines gesunden Peer-Knotens (z.B. ein Peer-Knoten, der nicht gehackt wurde) gesehen wird und dass es Angreifern ermöglicht wird, ihre Aktivitäten zu verschleiern, indem ein Abbild erzeugt wird, bei dem es sich um eine Reproduktion des Abbilds des gesunden Knotens handelt. In Ausführungsformen kann das Abbildsammelmodul 204 so konfiguriert sein, dass es eine erste Nachricht erzeugt. In diesen Ausführungsformen kann das Abbildsammelmodul 204 die erste Nachricht so konfigurieren, dass sie das verschlüsselte Abbild und eine Signatur enthält, die angibt, welcher Peer-Knoten 202 unter allen Peer-Knoten im Blockchain-Netzwerk das Abbild (z.B. Abbild 220) erzeugt hat. Nach dem Erzeugen kann das Abbildsammelmodul 204 die erste Nachricht in der Blockchain festschreiben.
  • Wie hier erörtert, werden die Ausführungsformen zwar oft von der Ebene des Peer-Knotens (z.B. Peer-Knoten 202) aus betrachtet, jeder Peer-Knoten im Blockchain-Netzwerk (z.B. selbstprüfendes Blockchain-Netzwerk 200) führt jedoch ähnliche Maßnahmen durch. Jeder Peer-Knoten schreibt daher eine erste Nachricht in der Blockchain fest, die mindestens ein verschlüsseltes Abbild enthält, das repräsentativ für seine jeweiligen Prozessinformationen (z.B. Prozessinformationen 212) ist, sowie eine für den Peer-Knoten spezifische Signatur, die zur Identifizierung verwendet werden kann. Indem jeder Peer-Knoten 202 seine jeweiligen ersten Nachrichten in der Blockchain festschreibt, kann das selbstprüfende Blockchain-Netzwerk 200 ein Protokoll der Abbilder führen, das angriffssicher ist und für eine spätere Verwendung genutzt werden kann.
  • Nachdem jede erste Nachricht von jedem Peer-Knoten im selbstprüfenden Blockchain-Netzwerk 200 in der Blockchain festgeschrieben ist, erzeugt das Abbildsammelmodul 204 jedes Peer-Knotens 202 eine zweite Nachricht. In Ausführungsformen kann die zweite Nachricht die Signatur des bestimmten Peer-Knotens und den Verschlüsselungsschlüssel (z.B. der zufällige symmetrische Schlüssel) enthalten, der zum Verschlüsseln des Abbilds (z.B. Abbild 220) in der ersten Nachricht verwendet wurde. In Ausführungsformen schreibt jeder Peer-Knoten 202 anschließend diese zweite Nachricht in der Blockchain fest. Diese Konfiguration, bei der zuerst die erste Nachricht in der Blockchain festgeschrieben wird, stellt sicher, dass es eine Aufzeichnung der Abbilder gibt, die nicht verändert werden und erst entschlüsselt werden kann, nachdem die zweite Nachricht jedes Peer-Knotens festgeschrieben wurde. Eine solche Konfiguration stellt sicher, dass Peer-Knoten und/oder Angreifer ihre ursprünglichen Abbilder nicht ändern können, um ihre Hackerangriffe/Fehler oder böswilligen Aktivitäten vor dem selbstprüfenden Blockchain-Netzwerk 200 zu verschleiern.
  • In Ausführungsformen ist zwar jeder Peer-Knoten 202 so konfiguriert, dass es ein Prüfmodul 206 hat, häufig muss jedoch nur auf einen Peer-Knoten zugegriffen werden, um Prüfungsfunktionen durchzuführen. In Ausführungsformen kann das Prüfmodul 206 so konfiguriert sein, dass es die verschlüsselten Abbilder von der ersten Nachricht sammelt, die jedem Peer-Knoten (z.B. Peer-Knoten 202) im selbstprüfenden Blockchain-Netzwerk 200 zugehörig ist. In einigen Ausführungsformen kann das Prüfmodul 206 so konfiguriert sein, dass es überprüft, ob jedes Abbild von einem vertrauenswürdigen Peer-Knoten erzeugt wurde. In diesen Ausführungsformen kann das Prüfmodul 206 die identifizierende Signatur der Peers überprüfen. Wenn das Prüfmodul 206 nicht überprüft wird, wird die Überprüfungsanforderung in einigen Ausführungsformen zwar erneut gesendet, in anderen Ausführungsformen kann das Prüfmodul 206 jedoch so konfiguriert sein, dass es eine Alarmnachricht auslöst, die dem Rest des selbstprüfenden Blockchain-Netzwerks 200 mitteilt, dass ein Peer-Knoten ohne Genehmigung am Blockchain-Netzwerk teilgenommen hat. Sobald jeder Peer-Knoten im selbstprüfenden Blockchain-Netzwerk 200 überprüft wurde, kann das Prüfmodul 206 so konfiguriert sein, dass es jeden zufälligen symmetrischen Schlüssel entweder von jedem Abbildsammelmodul 204 des einzelnen Peer-Knotens sammelt, das zum Verschlüsseln jedes Abbilds verwendet wird, oder dass es jeden zufälligen symmetrischen Schlüssel von der zweiten Nachricht sammelt. Wenn das Prüfmodul 206 in Ausführungsformen jedes Abbild (z.B. aus dem Satz der ersten Nachrichten) unter Verwendung der gesammelten Schlüssel entschlüsselt hat, kann das Prüfmodul 206 jedes erzeugte Abbild des Peer-Knotens 202 analysieren. In diesen Ausführungsformen kann das Prüfmodul 206 jedes Abbild und die zugehörigen Metadaten analysieren, um in der Sammlung der Abbilder zu ermitteln, ob es ein Konsensabbild gibt. Ein Konsensabbild kann erkannt werden, wenn eine Population von Abbildern genau dasselbe Abbild aufweist. In Ausführungsformen kann die Abbildrichtlinie 203 weiterhin enthalten, was als Konsensabbild zu betrachten ist. Die Abbildrichtlinie 203 kann zum Beispiel ein Konsensabbild entweder als einfache Mehrheit oder als Supermehrheit identischer Abbilder identifizieren, die von verschiedenen Peers erzeugt werden. Wenn das Prüfmodul 206 in Ausführungsformen feststellt, dass ein oder mehrere Abbilder nicht mit dem Konsensabbild übereinstimmen, werden diese Abbilder an das Hackerangriff-Lokalisierungsmodul 208 gesendet.
  • In 2C ist ein Beispiel für das Hackerangriff-Lokalisierungsmodul 208 gemäß Ausführungsformen der vorliegenden Offenbarung dargestellt. In Ausführungsformen kann das Hackerangriff-Lokalisierungsmodul 208 so konfiguriert sein, dass es das Konsensabbild 222 mit dem ermittelten nichtübereinstimmenden Abbild 226 vergleicht. In diesen Ausführungsformen kann das Hackerangriff-Lokalisierungsmodul 208 das Konsensabbild 222 und das nichtübereinstimmende Abbild 226 erweitern und die entsprechenden Merkle-Bäume neu konfigurieren, die jedem Abbild zugehörig sind (z.B. Konsens-Merkle-Baum 224 und nichtübereinstimmender Merkle-Baum 228). In Ausführungsformen kann das Hackerangriff-Lokalisierungsmodul 208 den Konsens-Merkle-Baum 224 und nichtübereinstimmenden Merkle-Baum 228 vergleichen und ermitteln, welche Hashes (z.B. Blätter/Zweige des Merkle-Baums) unterschiedlich sind. Wenn ein Hash im nichtübereinstimmenden Merkle-Baum 228 gleich ist wie ein Hash im Konsens-Merkle-Baum 224, gibt es keinen Hinweis darauf, dass ein Hackerangriff/Fehler aufgetreten ist. Wenn sich ein Hash des nichtübereinstimmenden Merkle-Baums 228 von einem entsprechenden Hash des Konsens-Merkle-Baums 224 unterscheidet, deutet dies darauf hin, dass es einen Unterschied bei den Prozessen gibt, die in diesem bestimmten Peer-Knoten durchgeführt wurden. Wenn ein Hackerangriff/Fehler ermittelt und lokalisiert wurde, kann in Ausführungsformen ein Bericht erzeugt werden, der den Hackerangriff/Fehler und den Ort angibt, an dem der Hackerangriff aufgetreten ist. In einigen Ausführungsformen kann dieser Bericht zwar nur an den Peer-Knoten gesendet werden, bei dem der Hackerangriff festgestellt wurde, in anderen Ausführungsformen kann der Bericht jedoch an einen oder mehrere andere Peer-Knoten im selbstprüfenden Blockchain-Netzwerk gesendet werden (z.B. Berichte, in denen viele Hackerangriffe/Fehler in den Prozessinformationen eines einzelnen Peer-Knotens angegeben sind).
  • Mit Bezug nunmehr auf 3 ist ein Ablaufplan dargestellt, der ein beispielhaftes Verfahren 300 zum Selbstprüfen eines Blockchain-Netzwerks gemäß Ausführungsformen der vorliegenden Offenbarung zeigt. In einigen Ausführungsformen kann das Verfahren 300 von einem oder mehreren Peer-Knoten im Blockchain-Netzwerk (z.B. Blockchain-Netzwerk 200) durchgeführt werden.
  • In einigen Ausführungsformen beginnt das Verfahren 300 bei Operation 302, wo der Prozessor Prozessinformationen von einem Peer-Knoten im Blockchain-Netzwerk sammelt. Das Verfahren 300 geht weiter zu Operation 304, wo der Prozessor ein Abbild von den Prozessinformationen des Peer-Knotens erstellt. Das Verfahren 300 geht weiter zu Operation 306, wo der Prozessor das Abbild des Peer-Knotens mit einem Konsensabbild vergleicht, um einen oder mehrere Hackerangriffe/Fehler zu erkennen. Das Verfahren 300 geht zu Operation 308 weiter, wo der Prozessor ermittelt, ob der Peer-Knoten gehackt wurde.
  • In einigen Ausführungsformen kann das Verfahren 300 wie dargestellt nach der Operation 308 enden.
  • In einigen Ausführungsformen gibt es wie nachstehend erörtert eine oder mehrere Operationen des Verfahrens 300 mit Operationen/Schritten, die aus Gründen der Kürze nicht dargestellt sind und die der Prozessor weiterhin durchführt. In einigen Ausführungsformen kann der Prozessor daher unter Verwendung des Abbilds ermitteln, wo der Fehler des beeinträchtigten Peers in den Prozessinformationen auftritt. In einigen Ausführungsformen kann das Erzeugen des Abbilds von den Prozessinformationen aufweisen, dass der Prozessor die Prozessinformationen von dem Peer-Knoten hasht, um einen Merkle-Baum zu erzeugen. Der Prozessor kann den Merkle-Baum erzeugen. Der Prozessor kann den Merkle-Baum so konfigurieren, dass er das Abbild des Peer-Knotens erstellt.
  • In einigen Ausführungsformen kann der Prozessor das Abbild verschlüsseln, um ein verschlüsseltes Abbild zu erstellen. Der Prozessor kann eine erste Nachricht erzeugen. Die erste Nachricht kann das verschlüsselte Abbild und eine Signatur enthalten. Die Signatur kann den Peer-Knoten identifizieren, der dem Abbild zugehörig ist. Der Prozessor kann die erste Nachricht in der Blockchain festschreiben.
  • In einigen Ausführungsformen kann der Prozessor eine zweite Nachricht erzeugen. Die zweite Nachricht kann einen oder mehrere Schlüssel zum Entschlüsseln des verschlüsselten Abbilds enthalten, um das Abbild neu zu erstellen. Der Prozessor kann die zweite Nachricht in der Blockchain festschreiben.
  • In einigen Ausführungsformen kann der Prozessor die der ersten Nachricht zugehörige Signatur des Peer-Knotens überprüfen. Der Prozessor kann den einen oder mehrere Schlüssel aus der zweiten Nachricht sammeln. Der Prozessor kann die verschlüsselten Abbilder der ersten Nachricht mit dem einen oder mehreren Schlüsseln von der zweiten Nachricht entschlüsseln.
  • In einigen Ausführungsformen kann das Vergleichen des Abbilds mit dem Abbildkonsens, um den Fehler zu erkennen, Vergleichen des Prozesses zum Festlegen des Abbildkonsenses umfassen. Das Festlegen des Abbildkonsenses kann Ermitteln einer Gruppe von Peer-Knoten mit einem identischen Abbild umfassen.
  • In einigen Ausführungsformen kann der Prozessor den Abbildkonsens analysieren. Der Prozessor kann die Prozessinformationen ermitteln, die dem Abbild zugehörig sind, das nicht genau mit dem Abbildkonsens übereinstimmt. Der Prozessor kann einen Bericht erzeugen. Der Bericht kann enthalten, wo sich der Fehler in den Prozessinformationen befindet.
  • Die vorliegende Offenbarung enthält zwar eine ausführliche Beschreibung von Cloud-Computing, es versteht sich jedoch, dass die Umsetzung der hier dargelegten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist. Stattdessen können Ausführungsformen der vorliegenden Offenbarung gemeinsam mit beliebigen Arten von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
  • Cloud-Computing ist ein Modell zum Liefern eines Dienstes, der einen problemlosen, bedarfsorientierten Netzwerkzugriff auf einen gemeinsamen Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Speicher, Anwendungen, virtuelle Maschinen und Dienste) ermöglicht, die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle enthalten.
  • Bei den Eigenschaften handelt es sich um die Folgenden:
    • On-Demand Self-Service (bedarfsorientierte Selbstbedienung): Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher bereitstellen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
    • Broad Network Access (breiter Netzzugriff): Über ein Netzwerk sind Funktionen verfügbar, auf die durch Standardmechanismen zugegriffen wird, die die Verwendung durch heterogene schlanke oder leistungsintensive Client-Plattformen unterstützen (z.B. Mobiltelefone, Laptops und PDAs).
    • Ressource Pooling (Ressourcen-Bündelung): Die Datenverarbeitungsressourcen des Anbieters werden gebündelt, um mehreren Nutzern unter Verwendung eines Mehrmietermodells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Teilunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Teil der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Teil auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
    • Rapid Elasticity (schnelle Anpassungsfähigkeit): Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
    • Measured Service (messbarer Dienst): Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Inanspruchnahme von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz bereitgestellt wird.
  • Es gibt folgende Dienstmodelle:
    • Software as a Service (Saas) (Software als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine schlanke Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende eMail) von verschiedenen Client-Einheiten aus zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Einstellungen der Anwendungskonfiguration.
    • Platform as a Service (Paas) (Plattform als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Werkzeugen erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen der Hosting-Umgebung der Anwendung.
    • Infrastructure as a Service (laas) (Infrastruktur als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
  • Es gibt folgende Einsatzmodelle:
    • Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
    • Community Cloud (Benutzergemeinschafts-Cloud): Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Anliegen hat (z.B. Aufgabe, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder fremden Räumen befinden.
    • Public Cloud (öffentliche Cloud): Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Branchengruppe zur Verfügung gestellt und gehört einer Organisation, die Cloud-Dienste verkauft.
    • Hybrid Cloud (hybride Cloud): Die Cloud-Infrastruktur besteht aus zwei oder mehr Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Entitäten bleiben, aber durch eine standardisierte oder herstellereigene Technologie miteinander verbunden sind, die eine Übertragbarkeit von Daten und Anwendungen ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
    • Eine Cloud-Computing-Umgebung ist dienstorientiert und schwerpunktmäßig auf Statusunabhängigkeit, geringe Kopplung, Modularität und semantische Interoperabilität ausgerichtet. Der Kern der Cloud-Computing ist eine Infrastruktur, die ein Netzwerk aus miteinander verbundenen Knoten enthält.
  • 4A zeigt eine Cloud-Computing-Umgebung 410. Wie gezeigt, weist die Cloud-Computing-Umgebung 410 einen oder mehrere Cloud-Computing-Knoten 400 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der persönliche digitale Assistent (PDA) oder das Mobiltelefon 400A, der Desktop-Computer 400B, der Laptop-Computer 400C und/oder das Kraftfahrzeug-Computersystem 400N Daten austauschen können. Die Knoten 400 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken wie private, benutzergemeinschaftliche, öffentliche oder hybride Clouds wie oben beschrieben oder in einer Kombination davon in Gruppen angeordnet sein (nicht dargestellt).
  • Dies ermöglicht es der Cloud-Computing-Umgebung 410, Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es versteht sich, dass die in 4A gezeigten Arten von Datenverarbeitungseinheiten 400A bis N nur veranschaulichend sein sollen und die Datenverarbeitungsknoten 400 und die Cloud-Computing-Umgebung 410 mit jeder Art von computergestützter Einheit über jede Art von Netzwerk und/oder netzwerkadressierbarer Verbindung Daten austauschen kann (z.B. über einen Web-Browser).
  • 4B zeigt einen Satz funktionaler Abstraktionsschichten, die von der Cloud-Computing-Umgebung 410 (4A) bereitgestellt werden. Es versteht sich im Voraus, dass die in 4B dargestellten Komponenten, Schichten und Funktionen nur veranschaulichend sein sollen und Ausführungsformen der Offenbarung nicht darauf beschränkt sind. Wie nachstehend dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt.
  • Die Hardware- und Software-Schicht 415 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: die Großrechner 402; die Server 404 auf Grundlage der RISC-Architektur (RISC = Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz), die Server 406; die Blade-Server 408; die Speichereinheiten 411; sowie die Netzwerke und Netzwerkkomponenten 412. In einigen Ausführungsformen enthalten die Software-Komponenten die Netzwerkanwendungs-Serversoftware 414 und die Datenbank-Software 416.
  • Die Virtualisierungsschicht 420 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Entitäten bereitgestellt werden können: virtuelle Server 422; virtuelle Speicher 424; virtuelle Netzwerke 426; darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 428; und virtuelle Clients 430.
  • In einem Beispiel kann die Verwaltungsschicht 440 die nachfolgend beschriebenen Funktionen bereitstellen. Die Ressourcenbereitstellung 442 ermöglicht eine dynamische Bereitstellung von Datenverarbeitungsressourcen und anderen Ressourcen, die verwendet werden, um Aufgaben in der Cloud-Computing-Umgebung durchzuführen. Messen und Preisfindung 444 stellen Kostenverfolgung beim Verwenden von Ressourcen in der Cloud-Computing-Umgebung sowie Abrechnung oder Rechnungsstellung für die Inanspruchnahme dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware umfassen. Die Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 446 stellt Nutzern und Systemadministratoren den Zugang zur Cloud-Computing-Umgebung bereit. Die Verwaltung der Dienstgüte 448 stellt Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, sodass die erforderliche Dienstgüte erreicht wird. Die Planung und Erfüllung der Dienstgütevereinbarung (Service Level Agreement, SLA) 450 stellt eine Vorabeinteilung und eine Beschaffung von Cloud-Computing-Ressourcen bereit, deren künftiger Bedarf auf der Grundlage einer Dienstgütevereinbarung vorausgesehen wird.
  • Die Arbeitslastschicht 460 stellt Beispiele für Funktionalitäten bereit, für die die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 462; Software-Entwicklung und Lebenszyklusverwaltung 464; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 466; Datenanalyseverarbeitung 468; Transaktionsverarbeitung 470; und Selbstprüfung 472.
  • 5 zeigt ein Übersichts-Blockschaubild eines beispielhaften Computersystems 501, das zum Implementieren eines oder mehrerer der hier beschriebenen Verfahren, Tools und Module sowie der damit verbundenen Funktionen (z.B. Verwenden von einem oder mehreren Prozessorschaltkreisen oder Computerprozessoren des Computers) gemäß Ausführungsformen der vorliegenden Offenbarung verwendet wird. In einigen Ausführungsformen können die wichtigsten Komponenten des Computersystems 501 eine oder mehrere CPUs 502, ein Speicherteilsystem 504, eine Terminalschnittstelle 512, eine Speicherschnittstelle 516, eine E/A(Eingabe/Ausgabe)-Einheitenschnittstelle 514 und eine Netzwerkschnittstelle 518 umfassen, die alle direkt oder indirekt zum Austauschen von Daten zwischen den Komponenten über einen Speicherbus 503, einen E/A-Bus 508 und eine E/A-Busschnittstelleneinheit 510 zum Zwecke der Datenübertragung verbunden sind.
  • Das Computersystem 501 kann eine oder mehrere programmierbare Universal-Zentraleinheiten (CPUs) 502A, 502B, 502C und 502D enthalten, die hier allgemein als CPU 502 bezeichnet werden. In einigen Ausführungsformen kann das Computersystem 501 mehrere Prozessoren enthalten, die für relativ große Systeme die Regel sind; in anderen Ausführungsformen kann es sich bei dem Computersystem 501 jedoch alternativ um ein einzelnes CPU-System handeln. Jede CPU 502 kann Anweisungen ausführen, die in dem Speicherteilsystem 504 gespeichert sind, und kann eine oder mehrere Ebenen eines integrierten Caches enthalten.
  • Der Systemspeicher 504 kann durch ein Computersystem lesbare Medien in Form von flüchtigen Speichern, z.B. Direktzugriffsspeicher (RAM) 522 und/oder Cache 524, enthalten. Das Computersystem 501 kann ferner weitere wechselbare/nichtwechselbare, flüchtige/nichtflüchtige Speichermedien eines Computersystems enthalten. Nur beispielhaft kann das Speichersystem 526 bereitgestellt werden, um ein nichtwechselbares, nichtflüchtiges magnetisches Medium wie eine „Festplatte“ auszulesen und zu beschreiben. Obwohl nicht dargestellt, können ein Laufwerk für magnetische Speicherplatten zum Auslesen und Beschreiben einer wechselbaren, nichtflüchtigen magnetischen Speicherplatte (z.B. „Diskette“) und ein Laufwerk für optische Speicherplatten zum Auslesen oder Beschreiben einer wechselbaren, nichtflüchtigen optischen Speicherplatte wie einer CD-ROM, DVD-ROM und andere optische Medien bereitgestellt werden. Der Speicher 504 kann darüber hinaus einen Flash-Speicher enthalten, z.B. einen Flash-Speicherstick oder ein Flash-Laufwerk. Die Speichereinheiten können über eine oder mehrere Datenmedien-Schnittstellen mit dem Speicherbus 503 verbunden sein. Der Speicher 504 kann mindestens ein Programmprodukt mit einem (z.B. mindestens einem) Satz von Programmmodulen enthalten, die so konfiguriert sind, dass sie die Funktionen verschiedener Ausführungsformen ausführen.
  • Ein oder mehrere Programme/Dienstprogramme 528 mit mindestens einem Satz von Programmmodulen 530 können im Speicher 504 gespeichert werden. Die Programme/Dienstprogramme 528 können einen Hypervisor (auch als virtueller Maschinenmonitor bezeichnet) ein oder mehrere Betriebssysteme, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten umfassen. Jedes der Betriebssysteme, ein oder mehrere Anwendungsprogramme, weitere Programmmodule und Programmdaten oder eine Kombination daraus können jeweils eine Implementierung einer Netzwerkumgebung enthalten. Die Programme 528 und/oder Programmmodule 530 führen im Allgemeinen die Funktionen oder Methodiken verschiedener Ausführungsformen aus.
  • Der Speicherbus 503 ist in 5 zwar als einzelne Busstruktur dargestellt, die einen direkten Datenübertragungspfad zwischen den CPUs 502, dem Speicherteilsystem 504 und der E/A-Busschnittstelle 510 bereitstellt, der Speicherbus 503 kann in einigen Ausführungsformen jedoch mehrere verschiedene Busse oder Datenübertragungspfade umfassen, die in verschiedenen Formen wie Punkt-zu-Punkt-Verbindungen in hierarchischen, sternförmigen oder Netzkonfigurationen, mehreren hierarchischen Busse, parallelen und redundanten Pfaden oder jeder anderen geeigneten Art von Konfiguration angeordnet sein können. Die E/A-Busschnittstelle 510 und der E/A-Bus 508 sind zwar jeweils als einzelne Einheiten dargestellt, das Computersystem 501 kann in einigen Ausführungsformen jedoch mehrere E/A-Busschnittstelleneinheiten 510, mehrere E/A-Busse 508 oder beides enthalten. Es werden weiterhin zwar mehrere E/A-Schnittstelleneinheiten gezeigt, die den E/A-Bus 508 von den verschiedenen Datenübertragungspfaden trennen, die zu den verschiedenen E/A-Einheiten führen, in anderen Ausführungsformen können einige oder alle E/A-Einheiten direkt mit einem oder mehreren E/A-Systembussen verbunden sein.
  • In einigen Ausführungsformen kann es sich bei dem Computersystem 501 um ein Mehrbenutzer-Großrechnersystem, ein Einzelbenutzersystem oder einen Server-Computer oder eine ähnliche Einheit handeln, das/der/die kaum eine oder keine direkte Benutzerschnittstelle hat, jedoch Anforderungen von anderen Computersystemen (Clients) empfängt. In einigen Ausführungsformen kann das Computersystem 501 weiterhin als Desktop-Computer, tragbarer Computer, Laptop- oder Notebook-Computer, Tablet-Computer, Taschencomputer, Telefon, Smartphone, Netzwerk-Switch oder Router oder jede andere geeignete Art von elektronischer Einheit implementiert werden.
  • Es sei darauf hingewiesen, dass 5 dazu dient, die repräsentativen wichtigsten Komponenten eines beispielhaften Computersystems 501 darzustellen. In einigen Ausführungsformen können einzelne Komponenten jedoch eine größere oder geringere Komplexität aufweisen als in 5 dargestellt, andere oder zusätzliche Komponenten als die in 5 gezeigten können vorhanden sein, und Anzahl, Art und Konfiguration dieser Komponenten können variieren.
  • Wie hier näher erläutert, ist vorgesehen, dass einige oder alle Operationen einiger der Ausführungsformen der hier beschriebenen Verfahren in alternativer Reihenfolge oder überhaupt nicht durchgeführt werden können; außerdem können mehrere Operationen gleichzeitig oder als Bestandteil eines größeren Prozesses erfolgen.
  • Bei der vorliegenden Offenbarung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jedem möglichen technischen Detaillierungsgrad der Integration handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) umfassen, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert ist/sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Offenbarung auszuführen.
  • Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. einen Lichtwellenleiter durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
  • Hier beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Router, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
  • Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Offenbarung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o. ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Offenbarung durchzuführen.
  • Aspekte der vorliegenden Offenbarung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
  • Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, einen Herstellungsartikel aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder angegebenen Funktion/Schritts umsetzen.
  • Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte umsetzen.
  • Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit als ein Schritt ausgeführt, gleichzeitig ausgeführt, im Wesentlich gleichzeitig ausgeführt, ganz oder teilweise zeitlich überlappend ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
  • Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zwecke der Veranschaulichung vorgestellt, sollen jedoch nicht erschöpfend oder auf die Ausführungsformen beschränkt sein. Für Fachleute ist offensichtlich, dass viele Änderungen und Abwandlungen möglich sind, ohne vom Anwendungsbereich der beschriebenen Ausführungsformen abzuweichen. Die hier verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber Technologien auf dem Markt bestmöglich zu erläutern oder es Fachleuten zu ermöglichen, die hier beschriebenen Ausführungsformen zu verstehen.
  • Die vorliegende Offenbarung wurde zwar in Form spezifischer Ausführungsformen beschrieben, es wird jedoch davon ausgegangen, dass Änderungen und Modifikationen davon für den Fachmann offensichtlich sind. Daher sollen die folgenden Ansprüche so ausgelegt werden, dass sie alle diese Änderungen und Modifikationen umfassen, die unter den eigentlichen Anwendungsbereich der Offenbarung fallen.

Claims (20)

  1. Verfahren für eine selbstprüfende Blockchain, wobei das Verfahren umfasst: Sammeln von Prozessinformationen, die einem Peer-Knoten zugehörig sind, durch einen Prozessor; Erzeugen eines Abbilds der Prozessinformationen; und Vergleichen des Abbilds des Peer-Knotens mit einem Abbildkonsens, um einen Fehler zu erkennen, wobei der Fehler darauf hinweist, dass der Peer-Knoten beeinträchtigt wurde.
  2. Verfahren nach Anspruch 1, das weiterhin umfasst: Ermitteln unter Verwendung des Abbilds, wo der Fehler des beeinträchtigten Peers in den Prozessinformationen auftritt.
  3. Verfahren nach Anspruch 1, wobei das Erzeugen des Abbilds der Prozessinformationen weiterhin umfasst: Hashen der Prozessinformationen vom Peer-Knoten, um einen Merkle-Baum zu erzeugen; Erzeugen des Merkle-Baums; und Konfigurieren des Merkle-Baums, um das Abbild des Peer-Knotens zu erstellen.
  4. Verfahren nach Anspruch 1, das weiterhin umfasst Verschlüsseln des Abbilds, um ein verschlüsseltes Abbild zu erstellen; Erzeugen einer ersten Nachricht, wobei die erste Nachricht das verschlüsselte Abbild und eine Signatur enthält, wobei die Signatur den Peer-Knoten identifiziert, der dem Abbild zugehörig ist; und Festschreiben der ersten Nachricht in der Blockchain.
  5. Verfahren nach Anspruch 4, das weiterhin umfasst: Erzeugen einer zweiten Nachricht, wobei die zweite Nachricht einen oder mehrere Schlüssel zum Entschlüsseln des verschlüsselten Abbilds enthält, um das Abbild neu zu erstellen; und Festschreiben der zweiten Nachricht in der Blockchain.
  6. Verfahren nach Anspruch 5, das weiterhin umfasst: Überprüfen der Signatur des Peer-Knotens, die der ersten Nachricht zugehörig ist; Sammeln des einen oder mehrerer Schlüssel aus der zweiten Nachricht; und Entschlüsseln der verschlüsselten Abbilder der ersten Nachricht mit dem einen oder mehreren Schlüsseln von der zweiten Nachricht.
  7. Verfahren nach Anspruch 1, wobei das Vergleichen des Abbilds mit dem Abbildkonsens zum Erkennen des Fehlers weiterhin umfasst: Festlegen des Abbildkonsenses, wobei das Festlegen des Abbildkonsenses Ermitteln einer Gruppe von Peer-Knoten mit einem identischen Abbild umfasst.
  8. Verfahren nach Anspruch 7, das weiterhin umfasst: Analysieren des Abbildkonsenses; Ermitteln von Prozessinformationen, die dem Abbild zugehörig sind, das nicht genau mit dem Abbildkonsens übereinstimmt; und Erzeugen eines Berichts, wobei der Bericht enthält, wo sich der Fehler in den Prozessinformationen befindet.
  9. System für eine selbstprüfende Blockchain, wobei das System aufweist: einen Speicher; und einen Prozessor, der mit dem Speicher Daten austauscht, wobei der Prozessor so konfiguriert ist, dass er Operationen durchführt, die aufweisen: Sammeln von Prozessinformationen, die einem Peer-Knoten zugehörig sind; Erzeugen eines Abbilds der Prozessinformationen; und Vergleichen des Abbilds des Peer-Knotens mit einem Abbildkonsens, um einen Fehler zu erkennen, wobei der Fehler darauf hinweist, dass der Peer-Knoten beeinträchtigt wurde.
  10. System nach Anspruch 9, wobei der Prozessor weiterhin so konfiguriert ist, dass er Operationen durchführt, die umfassen: Ermitteln unter Verwendung des Abbilds, wo der Fehler des beeinträchtigten Peers in den Prozessinformationen auftritt.
  11. System nach Anspruch 9, wobei das Erzeugen des Abbilds der Prozessinformationen weiterhin umfasst: Hashen der Prozessinformationen vom Peer-Knoten, um einen Merkle-Baum zu erzeugen; Erzeugen des Merkle-Baums; und Konfigurieren des Merkle-Baums, um das Abbild des Peer-Knotens zu erstellen.
  12. System nach Anspruch 9, wobei der Prozessor weiterhin so konfiguriert ist, dass er Operationen durchführt, die umfassen: Verschlüsseln des Abbilds, um ein verschlüsseltes Abbild zu erstellen; Erzeugen einer ersten Nachricht, wobei die erste Nachricht das verschlüsselte Abbild und eine Signatur enthält, wobei die Signatur den Peer-Knoten identifiziert, der dem Abbild zugehörig ist; und Festschreiben der ersten Nachricht in der Blockchain.
  13. System nach Anspruch 12, wobei der Prozessor weiterhin so konfiguriert ist, dass er Operationen durchführt, die umfassen: Erzeugen einer zweiten Nachricht, wobei die zweite Nachricht einen oder mehrere Schlüssel zum Entschlüsseln des verschlüsselten Abbilds enthält, um das Abbild neu zu erstellen; und Festschreiben der zweiten Nachricht in der Blockchain.
  14. System nach Anspruch 13, wobei der Prozessor weiterhin so konfiguriert ist, dass er Operationen durchführt, die umfassen: Überprüfen der Signatur des Peer-Knotens, die der ersten Nachricht zugehörig ist; Sammeln des einen oder mehrerer Schlüssel aus der zweiten Nachricht; und Entschlüsseln der verschlüsselten Abbilder der ersten Nachricht mit dem einen oder mehreren Schlüsseln von der zweiten Nachricht.
  15. System nach Anspruch 9, wobei das Vergleichen des Abbilds mit dem Abbildkonsens zum Erkennen des Fehlers weiterhin umfasst: Festlegen des Abbildkonsenses, wobei das Festlegen des Abbildkonsenses Ermitteln einer Gruppe von Peer-Knoten mit einem identischen Abbild umfasst.
  16. System nach Anspruch 15, wobei der Prozessor weiterhin so konfiguriert ist, dass er Operationen durchführt, die umfassen: Analysieren des Abbildkonsenses; Ermitteln von Prozessinformationen, die dem Abbild zugehörig sind, das nicht genau mit dem Abbildkonsens übereinstimmt; und Erzeugen eines Berichts, wobei der Bericht enthält, wo sich der Fehler in den Prozessinformationen befindet.
  17. Computerprogrammprodukt für eine selbstprüfende Blockchain, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium mit darauf enthaltenen Programmanweisungen aufweist, wobei die Programmanweisungen von einem Prozessor ausführbar sind, um die Prozessoren zu veranlassen, eine Funktion durchzuführen, wobei die Funktion umfasst: Sammeln von Prozessinformationen, die einem Peer-Knoten zugehörig sind; Erzeugen eines Abbilds der Prozessinformationen; und Vergleichen des Abbilds des Peer-Knotens mit einem Abbildkonsens, um einen Fehler zu erkennen, wobei der Fehler darauf hinweist, dass der Peer-Knoten beeinträchtigt wurde.
  18. Computerprogrammprodukt nach Anspruch 17, wobei die Funktion weiterhin umfasst: Ermitteln unter Verwendung des Abbilds, wo der Fehler des beeinträchtigten Peers in den Prozessinformationen aufgetreten ist.
  19. Computerprogrammprodukt nach Anspruch 17, wobei die Funktion weiterhin umfasst: Verschlüsseln des Abbilds, um ein verschlüsseltes Abbild zu erstellen; Erzeugen einer ersten Nachricht, wobei die erste Nachricht das verschlüsselte Abbild und eine Signatur enthält, wobei die Signatur den Peer-Knoten identifiziert, der dem Abbild zugehörig ist; und Festschreiben der ersten Nachricht in der Blockchain.
  20. Computerprogrammprodukt nach Anspruch 19, wobei die Funktion weiterhin umfasst: Erzeugen einer zweiten Nachricht, wobei die zweite Nachricht einen oder mehrere Schlüssel zum Entschlüsseln des verschlüsselten Abbilds enthält, um das Abbild neu zu erstellen; und Festschreiben der zweiten Nachricht in der Blockchain.
DE112021005862.2T 2020-12-02 2021-11-02 Selbstprüfende blockchain Pending DE112021005862T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/109,465 2020-12-02
US17/109,465 US11575499B2 (en) 2020-12-02 2020-12-02 Self auditing blockchain
PCT/CN2021/128076 WO2022116761A1 (en) 2020-12-02 2021-11-02 Self auditing blockchain

Publications (1)

Publication Number Publication Date
DE112021005862T5 true DE112021005862T5 (de) 2023-08-24

Family

ID=81751844

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021005862.2T Pending DE112021005862T5 (de) 2020-12-02 2021-11-02 Selbstprüfende blockchain

Country Status (6)

Country Link
US (1) US11575499B2 (de)
JP (1) JP2023551124A (de)
CN (1) CN116583833A (de)
DE (1) DE112021005862T5 (de)
GB (1) GB2616790A (de)
WO (1) WO2022116761A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11575499B2 (en) 2020-12-02 2023-02-07 International Business Machines Corporation Self auditing blockchain
US11985143B2 (en) * 2021-04-19 2024-05-14 Mitsubishi Electric Research Laboratories, Inc. Blockchain-based accountable distributed computing system

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10120756B2 (en) * 2011-08-17 2018-11-06 International Business Machines Corporation Audit object generation in a dispersed storage network
US20160283920A1 (en) 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
GB2559640A (en) * 2017-01-27 2018-08-15 Zensar Tech Limited A system and method for evaluating the feasibility of introducing a new node in a blockchain infrastructure
US10764259B2 (en) 2017-02-07 2020-09-01 Microsoft Technology Licensing, Llc Transaction processing for consortium blockchain network
US10581621B2 (en) 2017-05-18 2020-03-03 International Business Machines Corporation Enhanced chaincode analytics provenance in a blockchain
US11502828B2 (en) 2017-11-15 2022-11-15 International Business Machines Corporation Authenticating chaincode to chaincode invocations of a blockchain
US11468046B2 (en) * 2018-01-17 2022-10-11 Geeq Corporation Blockchain methods, nodes, systems and products
US11251937B2 (en) * 2018-01-21 2022-02-15 CipherTrace, Inc. Distributed security mechanism for blockchains and distributed ledgers
EP3522088B1 (de) 2018-02-05 2022-03-16 Nokia Technologies Oy Sicherung des blockkettenzugangs durch ein gateway
US20190303541A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Auditing smart contracts configured to manage and document software audits
US10986097B2 (en) * 2018-04-30 2021-04-20 Bank Of America Corporation System for using a distributed ledger to manage user entitlements to computing resources
CN109359084A (zh) 2018-08-27 2019-02-19 深圳壹账通智能科技有限公司 区块链信息处理中异常诊断方法、装置、设备及存储介质
WO2020062131A1 (zh) 2018-09-29 2020-04-02 北京连云决科技有限公司 一种基于区块链技术的容器云管理系统
US20200119904A1 (en) * 2018-10-15 2020-04-16 Ca, Inc. Tamper-proof privileged user access system logs
CN111277553B (zh) 2018-12-05 2022-05-24 阿里巴巴集团控股有限公司 一种基于区块链网络的可信节点确定方法和装置
CN109634810A (zh) 2018-12-10 2019-04-16 广东亿迅科技有限公司 基于Fabric的区块链业务平台和运行方法
US11329825B2 (en) * 2018-12-17 2022-05-10 Insights Network System and method for authenticating user identity
CN109684880A (zh) 2019-01-07 2019-04-26 江西金格科技股份有限公司 一种基于区块链的网页数据保护方法
CN110135178A (zh) 2019-04-11 2019-08-16 贝克链区块链技术有限公司 区块链验证中的零延迟账本访问技术
US11580240B2 (en) * 2020-03-24 2023-02-14 Kyndryl, Inc. Protecting sensitive data
CN111464393B (zh) 2020-03-31 2023-08-18 腾讯科技（深圳）有限公司 一种区块链运行状态的监测方法、装置及存储介质
US20210314139A1 (en) * 2020-04-01 2021-10-07 International Business Machines Corporation Noisy transaction for protection of data
US11620272B2 (en) * 2020-10-14 2023-04-04 Intertrust Technologies Corporation Trusted ledger management systems and methods
US11575499B2 (en) 2020-12-02 2023-02-07 International Business Machines Corporation Self auditing blockchain

Also Published As

Publication number Publication date
US11575499B2 (en) 2023-02-07
JP2023551124A (ja) 2023-12-07
GB202309844D0 (en) 2023-08-16
US20220173885A1 (en) 2022-06-02
WO2022116761A1 (en) 2022-06-09
GB2616790A (en) 2023-09-20
CN116583833A (zh) 2023-08-11

Similar Documents

Publication Publication Date Title
US11741083B2 (en) Cross-shard private atomic commit
DE112015004500B4 (de) Automatisierte Verwaltung von vertraulichen Daten in Cloud-Umgebungen
DE112017005040T5 (de) Betriebssystem und Verfahren auf Container-Grundlage
DE102019123253A1 (de) System und einrichtung für datenvertraulichkeit im distributed ledger
DE112020005289B4 (de) Teilweise sortierte blockchain
DE102021123128A1 (de) Mittels blockchains realisiertes datenmigrationsprüfprotokoll
DE112018003077T5 (de) Ein cluster von sicheren ausführungsplattformen
DE112020005075B4 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
DE112012002741T5 (de) Identitäts- und Berechtigungsprüfungsverfahren für die Sicherheit einer Cloud-Datenverarbeitungsplattform
DE112021001413T5 (de) Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE102016100494A1 (de) Sichere Identitätsauthentifizierung in einer elektronischen Transaktion
DE112021004344T5 (de) Konsensdienst für Blockchain-Netzwerke
DE102016204698A1 (de) Verbessern des Erkennens von Steganographie am Perimeter
DE112021000688T5 (de) Indexstruktur für blockchain-ledger
DE102021122557A1 (de) Konformitätsmechanismen in blockchain-netzwerken
DE112021005862T5 (de) Selbstprüfende blockchain
DE102016105062A1 (de) Nähengestützte Berechtigungsprüfung für einheitenübergreifend verteilte Daten
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
DE112021003971T5 (de) Nachhaltige token für eine lieferkette mit datenschutzerhaltendem protokoll
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
DE112020002343T5 (de) Verteilung von Sicherheitsberechtigungsnachweisen
DE112022000906T5 (de) Trennen von blockchain-daten
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence