DE112021004344T5 - Konsensdienst für Blockchain-Netzwerke - Google Patents

Konsensdienst für Blockchain-Netzwerke Download PDF

Info

Publication number
DE112021004344T5
DE112021004344T5 DE112021004344.7T DE112021004344T DE112021004344T5 DE 112021004344 T5 DE112021004344 T5 DE 112021004344T5 DE 112021004344 T DE112021004344 T DE 112021004344T DE 112021004344 T5 DE112021004344 T5 DE 112021004344T5
Authority
DE
Germany
Prior art keywords
key
tos
gateway
blockchain
ephemeral
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
DE112021004344.7T
Other languages
English (en)
Inventor
Yacov Manevich
Jason Karl YELLICK
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 DE112021004344T5 publication Critical patent/DE112021004344T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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/3297—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 time stamps, e.g. generation of time stamps
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Data Mining & Analysis (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)

Abstract

Ein durch einen Computer implementiertes Verfahren zum Herstellen eines Konsenses in einem Blockchain-Netzwerk, ein Gesamtsortierdienst für ein Blockchain-Netzwerk und ein Computerprogrammprodukt. Eine Ausführungsform kann Bereitstellen eines ersten Gesamtsortierdienst(TOS)-Gateways für eine Organisation in einem Blockchain-Netzwerk, Erzeugen eines symmetrischen Schlüssels am ersten TOS-Gateway, Aufteilen des symmetrischen Schlüssels, um eine Mehrzahl von Schlüsselanteilen zu erzeugen, und Verteilen mindestens eines Schlüsselanteils aus der Mehrzahl von Schlüsselanteilen an ein zweites TOS-Gateway im Blockchain-Netzwerk aufweisen. Das TOS-Gateway kann in einigen Ausführungsformen über einen Lese-/Schreibzugriff auf eine gemeinsam genutzte Nachrichtenwarteschlage verfügen, die jedem anderen TOS-Gateway im Blockchain-Netzwerk Nachrichten zur Verfügung stellt. Einige Ausführungsformen können ferner Wiederherstellen des symmetrischen Schlüssels aufweisen, indem einer der Schlüsselanteile vom zweiten Gateway im Blockchain-Netzwerk angefordert wird, sowie Wiederherstellen des symmetrischen Schlüssels unter Verwendung des einen Schlüsselanteils.

Description

  • HINTERGRUND
  • Die vorliegende Offenbarung bezieht sich auf Abschließen und Festschreiben von Transaktionen und insbesondere auf ein Ermöglichen eines Konsenses in dezentralen, verteilten Transaktionsverarbeitungssystemen.
  • Die Entwicklung des EDVAC-Systems im Jahr 1948 wird oft als der Beginn des Computerzeitalters bezeichnet. Seit dieser Zeit haben sich Computersysteme zu äußerst komplizierten Einheiten entwickelt. Die heutigen Computersysteme enthalten in der Regel eine Kombination aus hoch entwickelten Hardware- und Software-Komponenten, Anwendungsprogrammen, Betriebssystemen, Prozessoren, Bussen, Speichern, Eingabe/Ausgabe-Einheiten usw. Da Fortschritte in der Halbleiterverarbeitung und bei der Computerarchitektur die Leistungsfähigkeit immer weiter steigern, ist eine noch ausgereiftere Computer-Software entstanden, die die höhere Leistungsfähigkeit dieser Funktionen vorteilhaft nutzt, sodass es heute Computersysteme gibt, die weitaus leistungsstärker sind als noch vor ein paar Jahren.
  • Ein Bereich, in dem Datenverarbeitungssysteme erfolgreich eingesetzt werden, ist die Transaktionsverarbeitung. Historisch gesehen speichert und verwaltet eine zentrale Datenbank Transaktionsdaten in speziellen Datenbankprogrammen, die auf einem physischen System an einem Ort ausgeführt werden. Bei diesem Ort handelt es sich häufig um einen Zentralcomputer, z.B. einen Server-Computer oder einen Großrechner. Zentrale Datenbanken sind relativ einfach zu pflegen und zu verwalten, insbesondere im Hinblick auf die Sicherheit, da sie von einer einzigen Stelle aus kontrolliert werden.
  • KURZDARSTELLUNG
  • Gemäß Ausführungsformen der vorliegenden Offenbarung, ein durch einen Computer implementiertes Verfahren zum Herstellen eines Konsenses in einem Blockchain-Netzwerk. Eine Ausführungsform kann Bereitstellen eines ersten Gesamtsortierdienst(TOS)-Gateways (TOS = total ordering service) für eine Organisation in einem Blockchain-Netzwerk, Erzeugen eines symmetrischen Schlüssels am ersten TOS-Gateway, Aufteilen des symmetrischen Schlüssels, um eine Mehrzahl von Schlüsselanteilen zu erzeugen, und Verteilen mindestens eines Schlüsselanteils aus der Mehrzahl von Schlüsselanteilen an ein zweites TOS-Gateway im Blockchain-Netzwerk aufweisen. Das TOS-Gateway kann in einigen Ausführungsformen über einen Lese-/Schreibzugriff auf eine gemeinsam genutzte Nachrichtenwarteschlage verfügen, die jedem anderen TOS-Gateway im Blockchain-Netzwerk Nachrichten zur Verfügung stellt. Einige Ausführungsformen können ferner Wiederherstellen des symmetrischen Schlüssels aufweisen, indem einer der Schlüsselanteile vom zweiten Gateway im Blockchain-Netzwerk angefordert wird, sowie Wiederherstellen des symmetrischen Schlüssels unter Verwendung des einen Schlüsselanteils der Schlüsselanteile.
  • Gemäß Ausführungsformen der vorliegenden Offenbarung, ein Computerprogrammprodukt für einen vertrauenswürdigen Sortierdienst, der ein oder mehrere durch einen Computer lesbare Speichermedien und Programmanweisungen aufweist, die zusammen auf dem einen oder mehreren durch einen Computer lesbaren Speichermedien gespeichert sind. Die Programmanweisungen können Programmanweisungen zum Ausführen eines Gesamtsortierdienst-Gateways für jede Organisation in einem Blockchain-Netzwerk aufweisen, wobei jedes Gesamtsortierdienst-Gateway über einen Lese-/Schreibzugriff auf eine gemeinsam genutzte Nachrichtenwarteschlange verfügt, die Nachrichten an jede Organisation verteilt, sowie Identifizieren einer Gruppe von Organisationen innerhalb der Organisationen und Erzeugen eines Kanals, der die Gruppe von Organisationen umfasst, wobei die Gruppe von Organisationen autonom zusammenarbeitet. Die Programmanweisungen können weiterhin Programmanweisungen zum Erzeugen eines symmetrischen Schlüssels aufweisen, den nur die Gruppe von Organisationen kennt, sowie Aufteilen des symmetrischen Schlüssels in entsprechende Anteile, die einer Anzahl von Organisationen in der Gruppe von Organisationen zugehörig sind, und Speichern der Anteile, wobei der symmetrische Schlüssel als Ganzes nicht gespeichert wird.
  • Gemäß Ausführungsformen der vorliegenden Offenbarung ein Gesamtsortierdienst für ein Blockchain-Netzwerk. Eine Ausführungsform kann eine Mehrzahl von Gesamtsortierdienst(TOS)-Gateways aufweisen, die jeweils einer Mitgliedsorganisation aus einer Mehrzahl von Mitgliedsorganisationen in einem Blockchain-Netzwerk zugehörig sind, sowie eine gemeinsam genutzte Nachrichtenwarteschlange, die so ausgelegt ist, dass sie den symmetrischen Schlüssel an die Mehrzahl von TOS-Gateways in dem Blockchain-Netzwerk weiterverteilt. Die Mehrzahl von TOS-Gateways kann jeweils einen Prozessor aufweisen, der funktionsmäßig mit einem Speicher verbunden ist, wobei der Speicher Programmanweisungen enthält, um, wenn sie auf dem Prozessor ausgeführt werden, einen symmetrischen Schlüssel an einem ersten TOS-Gateway aus der Mehrzahl von TOS-Gateways zu erzeugen, den symmetrischen Schlüssel in eine Mehrzahl von Schlüsselanteilen aufzuteilen und mindestens einen Schlüsselanteil aus der Mehrzahl von Schlüsselteilen an ein zweites TOS-Gateway in dem Blockchain-Netzwerk zu verteilen.
  • Die vorstehende Kurzdarstellung ist nicht dazu gedacht, jede veranschaulichte Ausführungsform oder jede Implementierung der vorliegenden Offenbarung zu beschreiben.
  • Figurenliste
  • Die in der vorliegenden Anmeldung dargestellten 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.
    • 1 stellt ein Datenverarbeitungssystem gemäß einigen Ausführungsformen dar.
    • 2 stellt eine Cloud-Computing-Umgebung gemäß einigen Ausführungsformen dar.
    • 3 stellt Abstraktionsmodellschichten gemäß einigen Ausführungsformen dar.
    • 4 ist eine allgemeine Darstellung eines Blockchain-Systems gemäß einigen Ausführungsformen.
    • 5A stellt eine beispielhafte Konfiguration einer Blockchain-Architektur gemäß einigen Ausführungsformen dar.
    • 5B veranschaulicht einen Blockchain-Transaktionsablauf gemäß einigen Ausführungsformen.
    • 6A veranschaulicht einen Ablaufplan gemäß einigen Ausführungsformen.
    • 6B veranschaulicht einen weiteren Ablaufplan gemäß einigen Ausführungsformen.
    • 6C veranschaulicht gemäß einigen Ausführungsformen ein beispielhaftes System, das so konfiguriert ist, dass es eine oder mehrere hier beschriebene Operationen durchführt.
    • 6D veranschaulicht gemäß einigen Ausführungsformen ein weiteres beispielhaftes System, das so konfiguriert ist, dass es eine oder mehrere hier beschriebene Operationen durchführt.
    • 6E veranschaulicht gemäß einigen Ausführungsformen ein weiteres beispielhaftes System, das so konfiguriert ist, dass es einen Smart Contract (intelligenter Vertrag) verwendet.
    • 6F veranschaulicht gemäß einigen Ausführungsformen ein System, das eine Blockchain umfasst.
    • Die 7A und 7B veranschaulichen ein Verfahren zum Erzeugen eines Kanals gemäß einigen Ausführungsformen.
    • 8 veranschaulicht ein Verfahren zum Wiederherstellen eines symmetrischen Schlüssels durch ein Gesamtsortierdienst-Gateway (TOS-Gateway) gemäß einigen Ausführungsformen.
    • 9 ist ein Ablaufplan, der gemäß einigen Ausführungsformen ein Verfahren 900 zum Erweitern der Mitgliedschaft in einer Blockchain veranschaulicht.
    • Die 10A und 10B veranschaulichen ein Verfahren zum Rotieren von Schlüsseln gemäß einigen Ausführungsformen.
    • 11A veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess, bei dem ein neuer Block zu einem Distributed Ledger (verteiltes Kontenbuch) hinzugefügt wird.
    • 11B veranschaulicht gemäß beispielhaften Ausführungsformen den Inhalt eines neuen Datenblocks.
    • 11C veranschaulicht gemäß beispielhaften Ausführungsformen eine Blockchain für digitalen Inhalt.
    • 11D veranschaulicht gemäß beispielhaften Ausführungsformen einen Block, der die Struktur von Blöcken in der Blockchain darstellen kann.
    • 12A veranschaulicht gemäß beispielhaften Ausführungsformen eine beispielhafte Blockchain, die Daten zum maschinellen Lernen (künstliche Intelligenz) speichert.
    • 12B veranschaulicht gemäß beispielhaften Ausführungsformen eine beispielhafte quantensichere Blockchain.
  • Verschiedene Änderungen und andere Formen sind für die Erfindung möglich, die Besonderheiten der Erfindung sind jedoch beispielhaft in den Zeichnungen dargestellt und können ausführlich beschrieben werden. Es wird jedoch darauf hingewiesen, dass die Erfindung nicht auf die beschriebenen besonderen Ausführungsformen beschränkt werden soll. Hingegen ist beabsichtigt, dass alle Änderungen, Äquivalente und Alternativen, die Gedanken und Anwendungsbereich der Erfindung widerspiegeln, abgedeckt werden.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Aspekte der vorliegenden Offenbarung beziehen sich auf Abschließen und Festschreiben von Transaktionen; besondere Aspekte beziehen sich auf ein Ermöglichen eines Konsenses in dezentralen, verteilten Transaktionsverarbeitungssystemen. Die vorliegende Offenbarung ist zwar nicht zwingend auf diese Anwendungen beschränkt, verschiedene Aspekte der Offenbarung können jedoch durch eine Beschreibung verschiedener Beispiele in diesem Zusammenhang verstanden werden.
  • Eine dezentrale Datenbank bezieht sich im Allgemeinen auf ein verteiltes Speichersystem, in dem mehrere Knoten zusammenarbeiten, um die Daten zu speichern und/oder einen Zugriff auf die Daten bereitzustellen. Eine Blockchain stellt ein Beispiel einer dezentralen Datenbank dar, die im Allgemeinen eine unveränderliche „Append-only“-Datenstruktur (append-only = nur hinzufügen) umfasst, die einem Distributed Ledger ähnelt und in der Lage ist, Datensätze zwischen gegenseitig nichtvertrauenswürdigen Parteien zu verwalten. Diese gegenseitig nichtvertrauenswürdigen Parteien werden hier als Peers oder Peer-Knoten bezeichnet.
  • In einigen Ausführungsformen einer Blockchain verwaltet jeder Peer eine Kopie der Datensätze der verteilten Datenbank, und kein Peer alleine kann die Datensätze der verteilten Datenbank ändern, ohne dass darüber ein Konsens zwischen den Peers erzielt wird. In einigen Ausführungsformen einer Blockchain können die Peers ein Konsensprotokoll ausführen, um Blockchain-Transaktionen zu validieren, die Blockchain-Transaktionen in Blöcke zu gruppieren und eine Hash-Kette über die Blöcke zu erzeugen. Dieser Prozess kann zur Bildung eines Distributed Ledger führen, indem die Speichertransaktionen für die Konsistenz in eine Reihenfolge gebracht werden.
  • In Ausführungsformen einer öffentlichen oder genehmigungsfreien Blockchain kann jeder teilnehmen, ohne dass eine bestimmte Berechtigung erforderlich ist. Andererseits stellen Ausführungsformen einer genehmigungspflichtigen Blockchain ein System bereit, das Interaktionen zwischen einer Gruppe von berechtigten Entitäten sichern kann, die ein gemeinsames Ziel verfolgen, sich jedoch gegenseitig nicht vollständig vertrauen, z.B. Unternehmen, die Geldmittel, Waren, Informationen und Ähnliches austauschen.
  • Einige Ausführungsformen einer Blockchain können mit beliebiger, programmierbarer Logik arbeiten, die auf ein dezentrales Speicherschema wie „Smart Contracts“ und „Chaincodes“ zugeschnitten ist. In einigen dieser Ausführungsformen können spezielle Chaincodes für Verwaltungsfunktionen und Parameter zur Verfügung stehen, die als System-Chaincodes bezeichnet werden. Bei Smart Contracts handelt es sich um vertrauenswürdige verteilte Anwendungen, die die fälschungssicheren Eigenschaften der Blockchain und eine zugrunde liegende Vereinbarung zwischen den Knoten nutzen (häufig als Endorsement (Bestätigung) oder Endorsement Policy (Bestätigungsrichtlinie) bezeichnet).
  • Blockchain-Transaktionen können in einigen Ausführungsformen „bestätigt“ werden, bevor sie in der Blockchain festgeschrieben (committed) werden, während Transaktionen, die nicht „bestätigt“ sind, ignoriert werden können. Gemäß einigen Ausführungsformen ermöglicht eine Endorsement Policy 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, kann die Transaktion ausgeführt werden, um die Transaktion zu validieren. Nach dem Validieren kann eine Sortierphase für die Transaktionen beginnen, in der ein Konsensprotokoll verwendet wird, um eine geordnete Folge von bestätigten Transaktionen zu erstellen, die in Blöcken gruppiert sind.
  • In einigen Ausführungsformen einer Blockchain können Knoten als Datenübertragungsentitäten des Blockchain-Systems fungieren. Ein „Knoten“ kann in diesen Ausführungsformen eine logische Funktion in dem Sinne durchführen, dass mehrere Knoten unterschiedlichen Typs auf demselben physischen Server laufen können. Knoten können in Vertrauensbereichen gruppiert werden und logischen Entitäten zugehörig sein, die sie auf verschiedene Weise steuern. Die Knoten können auch verschiedene Typen umfassen, z.B. einen Client- oder sendenden Client-Knoten, der einen Transaktionsaufruf an einen Endorser (z.B. einen Peer) sendet, und Sortierknoten (ordering nodes), die Transaktionsvorschläge an einen Sortierdienst senden. Ein anderer Typ von Knoten ist ein Peer-Knoten, der vom Client gesendete Transaktionen empfangen, die Transaktionen festschreiben und einen Zustand und eine Kopie des Ledger der Blockchain-Transaktionen verwalten kann. Peer-Knoten können in einigen Ausführungsformen auch die Rolle eines Endorser übernehmen, was jedoch nicht zwingend erforderlich ist.
  • Der Sortierdienstknoten oder Sortierer (orderer) kann in einigen Ausführungsformen den Datenübertragungsdienst für alle Knoten durchführen und eine Zustellungsgarantie implementieren, z.B. eine Übertragung an alle Peer-Knoten im System, wenn Transaktionen festgeschrieben werden und ein aktueller Zustand (World State) der Blockchain geändert wird. In einigen Ausführungsformen kann dieser World State die ursprüngliche Blockchain-Transaktion umfassen, die in der Regel Steuer- und Einrichtungsinformationen aufweist.
  • Einige Benutzer der Blockchain-Technologie zögern jedoch unter Umständen, Sortierknoten zu hosten. Der Grund dafür kann sein, dass das Offenlegen eines Endpunktes für das öffentliche Internet ein inhärentes Sicherheitsrisiko darstellt und viele Benutzer nicht über die technischen Kenntnisse, die Schwerpunktlegung und die Ressourcen verfügen, um dieses Risiko zu bewältigen. Führungsgestützte Konsensprotokolle ohne Rotation können darüber hinaus zu einer ungleichmäßigen Verteilung der Netzwerkbandbreite führen. Dies wiederum kann zur Folge haben, dass einige Benutzer Rechenleistung, Festplatten-E/A und Netzwerkbandbreite für Transaktionen aufwenden, an denen sie nicht beteiligt sind. Wieder andere Benutzer könnten sich um die Einhaltung von Vorschriften, Dienstgütevereinbarungen usw. sorgen, insbesondere wenn eine bestimmte Blockchain-Implementierung keine finanziellen Anreize zum Ausführen von Sortierknoten enthält.
  • Umgekehrt können sich auch Herausforderungen beim Bilden von Blockchain-Netzwerken ergeben, bei denen der Konsensdienst von einem Dritten gehostet wird (z.B. von jemandem, der nicht an einem erheblichen Prozentsatz der in der Blockchain aufgezeichneten Transaktionen beteiligt ist). Wenn der Sortierdienst zum Beispiel von einem Dritten durchgeführt wird, kann dieser Dritte Zugriff auf den Blockchain-Inhalt haben, da der Sortierdienst die Blöcke im Wesentlichen selbst erzeugt, und da neu hinzugekommene Knoten die Blöcke analysieren müssen, um sich über den aktuellen Zustand der Blockchain zu informieren. Dies kann jedoch unerwünschte Nebenfolgen haben, wie zum Beispiel: (i) der Dritte kann möglicherweise alle Transaktionen aller Kanäle im Klartext (z.B. unverschlüsselt) einsehen und hat somit möglicherweise Zugriff auf vertrauliche und/oder sensible Informationen, (ii) die Parteien des Blockchain-Netzwerks sind möglicherweise auf die Zusammenarbeit mit dem Sortierdienst des Dritten angewiesen, wenn sie zu einem neuen Anbieter von Sortierdiensten wechseln möchten, da dies jedoch keine einfache Aufgabe ist, besteht die Gefahr einer ewigen Abhängigkeit von einem Anbieter.
  • Einige Ausführungsformen der Offenbarung können daher das Erzeugen von Blockchain-Netzwerken auch für Gemeinschaften von Organisationen ermöglichen, die keine Sortierdienstknoten hosten können. Zu diesen Blockchain-Netzwerken kann ein vertrauenswürdiger Gesamtsortierdienst (TSO) gehören, der in einigen Ausführungsformen verschlüsselte Transaktionsnutzdaten von einer Mehrzahl von Gesamtsortierdienst-Gateways (TSO-Gateways) empfangen und weiterleiten kann.
  • Datenverarbeitungssystem
  • 1 veranschaulicht gemäß einigen Ausführungsformen eine Ausführungsform eines Datenverarbeitungssystems (DVS) 100a. Das DVS 100a kann in dieser Ausführungsform als Personal Computer; Server-Computer; tragbarer Computer wie ein Laptop- oder Notebook-Computer, PDA (persönlicher digitaler Assistent), Tablet-Computer oder Smartphone; Prozessoren, die in größere Einheiten wie ein Auto, ein Flugzeug, ein Telefonkonferenzsystem, ein Gerät integriert sind; intelligente Einheiten oder jede andere geeignete Art von elektronischer Einheit implementiert sein. Darüber hinaus können auch andere oder zusätzliche als die in 1 gezeigten Komponenten vorhanden sein, und die Anzahl, Art und Konfiguration dieser Komponenten kann variieren. In 1 sind ferner nur die repräsentativen Hauptkomponenten des DVS 100a dargestellt, und einzelne Komponenten können komplexer sein als in 1 gezeigt.
  • Das Datenverarbeitungssystem 100a in 1 weist eine Mehrzahl von Zentraleinheiten 110a bis 110d auf (hier allgemein als Prozessor 110 oder CPU 110 bezeichnet), die über einen Systembus 122 mit einem Speicher 112, einer Massenspeicher-Schnittstelle 114, einer Terminal-/Anzeigeschnittstelle 116, einer Netzwerkschnittstelle 118 und einer Eingabe-/Ausgabeschnittstelle („E/A"-Schnittstelle) 120 verbunden sind. Die Massenspeicher-Schnittstelle 114 verbindet in dieser Ausführungsform den Systembus 122 mit einer oder mehreren Massenspeichereinheiten wie einer Direktzugriffsspeichereinheit 140, einer Universal-Serial-Bus-Speichereinheit („USB“) 141 oder einem lesbaren/beschreibbaren optischen Laufwerk 142. Die Netzwerkschnittstellen 118 ermöglichen es dem DVS 100a, über das Datenübertragungsmedium 106 mit einem anderen DVS 100b Daten auszutauschen. Der Speicher 112 enthält ferner ein Betriebssystem 124, eine Mehrzahl von Anwendungsprogrammen 126 und Programmdaten 128.
  • Bei der Ausführungsform des Datenverarbeitungssystems 100a in 3 handelt es sich um eine universelle Datenverarbeitungseinheit. Bei den Prozessoren 110 kann es sich daher um jede beliebige Einheit handeln, die in der Lage ist, im Speicher 112 gespeicherte Programmanweisungen auszuführen, wobei die Prozessoren selbst aus einem oder mehreren Mikroprozessoren und/oder integrierten Schaltungen bestehen können. In dieser Ausführungsform enthält das DVS 100a mehrere Prozessoren und/oder Verarbeitungskerne, wie es bei größeren, leistungsstärkeren Computersystemen üblich ist; in anderen Ausführungsformen können die Datenverarbeitungssysteme 100a jedoch ein einzelnes Prozessorsystem und/oder einen einzelnen Prozessor aufweisen, der so ausgestaltet ist, dass er ein Mehrprozessorsystem emuliert. Die Prozessoren 110 können des Weiteren mit einer Reihe von heterogenen Datenverarbeitungssystemen 100a implementiert werden, bei denen ein Hauptprozessor mit sekundären Prozessoren auf einem einzelnen Chip vorhanden ist. In einem weiteren veranschaulichenden Beispiel kann es sich bei dem Prozessor 110 um ein symmetrisches Mehrprozessorsystem mit mehreren Prozessoren desselben Typs handeln.
  • Beim Starten des Datenverarbeitungssystems 100a führen der oder die zugehörige(n) Prozessor(en) 110 zunächst die Programmanweisungen aus, aus denen das Betriebssystem 124 besteht, das die physischen und logischen Ressourcen des DVS 100a verwaltet. Zu diesen Ressourcen gehören der Speicher 112, die Massenspeicher-Schnittstelle 114, die Terminal-/Anzeigeschnittstelle 116, die Netzwerkschnittstelle 118 und der Systembus 122. Wie bei dem/den Prozessor(en) 110 können einige Ausführungsformen des DVS 100a mehrere Systemschnittstellen 114, 116, 118, 120 und Busse 122 verwenden, die ihrerseits jeweils ihre eigenen separaten, vollständig programmierten Mikroprozessoren enthalten können.
  • Anweisungen für das Betriebssystem, Anwendungen und/oder Programme (allgemein als „Programmcode“, „durch einen Computer verwendbarer Programmcode“ oder „durch einen Computer lesbarer Programmcode“ bezeichnet) können sich zunächst in den Massenspeichereinheiten 140, 141, 142 befinden, die über den Systembus 122 Daten mit den Prozessoren 110 austauschen. Der Programmcode in den verschiedenen Ausführungsformen kann auf verschiedenen physischen, durch einen Computer lesbaren Medien wie dem Systemspeicher 112 oder den Massenspeichereinheiten 140, 141, 142 ausgeführt sein. In dem veranschaulichenden Beispiel in 3 werden die Anweisungen in einer funktionalen Form eines permanenten Speichers in der Direktzugriffsspeichereinheit 140 gespeichert. Diese Anweisungen werden anschließend zum Ausführen durch den Prozessor 110 in den Speicher 112 geladen. Der Programmcode kann sich jedoch auch in einer funktionalen Form auf dem durch einen Computer lesbaren Medium 142 befinden, das selektiv entfernt werden und zum Ausführen durch den Prozessor 110 in das DVS 100a geladen oder dorthin übertragen werden kann.
  • Bei dem Systembus 122 kann es sich um eine beliebige Einheit handeln, die die Datenübertragung zwischen den Prozessoren 110, dem Speicher 112 und den Schnittstellen 114, 116, 118, 120 ermöglicht. Bei dem Systembus 122 handelt es sich in dieser Ausführungsform darüber hinaus zwar um eine relativ einfache, einzelne Busstruktur, die einen direkten Datenübertragungspfad bei dem Systembus 122 bereitstellt, andere Busstrukturen sind jedoch mit der vorliegenden Offenbarung vereinbar, darunter Punkt-zu-Punkt-Verbindungen in hierarchischen, sternförmigen oder Netzkonfigurationen, mehrere hierarchische Busse, parallele und redundante Pfade usw., ohne auf diese beschränkt zu sein.
  • Der Speicher 112 und die Massenspeichereinheiten 140, 141, 142 arbeiten zusammen, um das Betriebssystem 124, die Anwendungsprogramme 126 und die Programmdaten 128 zu speichern. In dieser Ausführungsform handelt es sich bei dem Speicher 112 um ein Halbleiterbauelement mit wahlfreiem Zugriff, das Daten und Programme speichern kann. 3 zeigt dieses Bauelement zwar konzeptionell als einzelne monolithische Entität, der Speicher 112 kann in einigen Ausführungsformen jedoch eine komplexere Anordnung wie eine Hierarchie von Caches und anderen Speichereinheiten aufweisen. Der Speicher 112 kann beispielsweise aus mehreren Ebenen von Caches bestehen, und diese Caches können weiter nach Funktionen unterteilt sein, sodass ein Cache Anweisungen enthält, während ein anderer Cache Nichtanweisungsdaten enthält, die von dem Prozessor oder den Prozessoren verwendet werden. Der Speicher 112 kann ferner verteilt und verschiedenen Prozessoren 110 oder Sätzen von Prozessoren 110 zugehörig sein, wie es von verschiedenen sogenannten NUMA-Computerarchitekturen (NUMA = Non-Uniform Memory Access) bekannt ist. Einige Ausführungsformen können darüber hinaus virtuelle Adressierungsmechanismen verwenden, die es dem DVS 100a ermöglichen, sich so zu verhalten, als hätte es Zugriff auf eine große, einzelne Speicherentität anstatt auf mehrere, kleinere Speichereinheiten wie den Speicher 112 und die Massenspeichereinheit 140, 141, 142.
  • Das Betriebssystem 124, die Anwendungsprogramme 126 und die Programmdaten 128 werden zwar als im Speicher 112 enthalten dargestellt, einige oder alle können sich jedoch physisch in verschiedenen Computersystemen befinden, und in einigen Ausführungsformen kann aus der Ferne auf sie zugegriffen werden, z.B. über das Datenübertragungsmedium 106. Während das Betriebssystem 124, die Anwendungsprogramme 126 und die Programmdaten 128 als im Speicher 112 enthalten dargestellt sind, sind diese Elemente nicht notwendigerweise alle gleichzeitig vollständig in derselben physischen Einheit enthalten und können sich sogar im virtuellen Speicher anderer DVS 100b befinden.
  • Die Systemschnittstellen 114, 116, 118, 120 unterstützen die Datenübertragung mit einer Vielfalt von Speicher- und E/A-Einheiten. Die Massenspeicher-Schnittstelle 114 unterstützt den Anschluss einer oder mehrerer Massenspeichereinheiten 140, 141, 142, bei denen es sich in der Regel um rotierende Magnetplattenspeichereinheiten, eine Halbleiterspeichereinheit (SSD), die Baugruppen für integrierte Schaltungen als Speicher verwendet, um Daten dauerhaft in der Regel unter Verwendung eines Flash-Speichers zu speichern, oder eine Kombination aus beiden handelt. Die Massenspeichereinheiten 140, 141, 142 können jedoch auch andere Einheiten aufweisen, darunter Anordnungen von Festplattenlaufwerken, die so konfiguriert sind, dass sie für einen Host als einzige große Speichereinheit erscheinen (allgemein als RAID-Anordnungen bezeichnet) und/oder Archivierungsspeichermedien wie Festplattenlaufwerke, Bänder (z.B. Mini-DV), beschreibbare Compact Disks (z.B. CD-R und CD-RW), Digital Versatile Disks (z.B. DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), Holografie-Speichersysteme, Blue Laser Disks, IBM Millipede-Einheiten usw.
  • Die Terminal-/Anzeigeschnittstelle 116 wird verwendet, um eine oder mehrere Anzeigeeinheiten wie den Monitor 180 mit dem Datenverarbeitungssystem 100a zu verbinden. Bei diesen Anzeigeeinheiten 180 kann es sich um nichtintelligente Terminals wie einen LED-Monitor oder um vollständig programmierbare Workstations handeln, die verwendet werden, um es IT-Administratoren und Kunden zu ermöglichen, mit dem DVS 100a Daten auszutauschen. Es ist jedoch zu beachten: obwohl die Anzeigenschnittstelle 116 bereitgestellt wird, um die Datenübertragung mit einer oder mehreren Anzeigen 180 zu unterstützen, benötigen die Computersysteme 100a nicht unbedingt eine Anzeige 180, da alle erforderlichen Interaktionen mit Kunden und anderen Prozessen über die Netzwerkschnittstelle 118 erfolgen können.
  • Bei dem Datenübertragungsmedium 106 kann es sich um ein beliebiges geeignetes Netzwerk oder eine Kombination von Netzwerken handeln, das jedes geeignete Protokoll unterstützt, das für die Übertragung von Daten und/oder Code zu/von mehreren DVS 100a, 100b geeignet ist. Bei der Netzwerkschnittstelle 118 kann es sich demzufolge um eine beliebige Einheit handeln, die diese Datenübertragung ermöglicht, unabhängig davon, ob die Netzwerkverbindung mit heutigen analogen und/oder digitalen Techniken oder über einen Netzwerkmechanismus der Zukunft hergestellt wird. Zu geeigneten Datenübertragungsmedien 106 gehören Netzwerke, die mit einer oder mehreren der Spezifikationen „InfiniBand“ oder IEEE (Institute of Electrical and Electronics Engineers) „Ethernet“ 802.3x implementiert sind; Mobilfunk-Übertragungsnetzwerke; drahtlose Netzwerke, die mit einer der Spezifikationen IEEE 802.11x, IEEE 802.16, General Packet Radio Service („GPRS“), FRS (Family Radio Service) oder Bluetooth implementiert sind; Ultrabreitband-Technologie („UWB“), wie sie in FCC 02-48 beschrieben ist, usw., ohne auf diese beschränkt zu sein. Für Fachleute ist offensichtlich, dass viele verschiedene Netzwerk- und Übertragungsprotokolle verwendet werden können, um das Datenübertragungsmedium 106 zu implementieren. Die Suite Transmission Control Protocol/Internet Protocol („TCP/IP“) enthält geeignete Netzwerk- und Übertragungsprotokolle.
  • Cloud Computing
  • 2 veranschaulicht gemäß einigen Ausführungsformen eine Cloud-Umgebung mit einem oder mehreren DVS 100a. 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 Erfindung gemeinsam mit beliebigen Arten von jetzt bekannter oder später entwickelter 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 Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort 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 Kundenkonten). 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 kundenspezifischen 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 des Cloud-Computing ist eine Infrastruktur, die ein Netzwerk aus miteinander verbundenen Knoten enthält.
  • Mit Bezug nunmehr auf 2 ist eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt, enthält die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der persönliche digitale Assistent (PDA) oder das Mobiltelefon 54A, der Desktop-Computer 54B, der Laptop-Computer 54C und/oder das Kraftfahrzeug-Computersystem 54N Daten austauschen können. Die Knoten 10 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 50, 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 FIG. gezeigten Arten von Datenverarbeitungseinheiten 54A bis N nur veranschaulichend sein sollen und die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 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).
  • Mit Bezug nunmehr auf 3 wird ein Satz funktionaler Abstraktionsschichten gezeigt, die von der Cloud-Computing-Umgebung 50 (2) bereitgestellt werden. Es versteht sich im Voraus, dass die in 2 dargestellten Komponenten, Schichten und Funktionen nur veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
  • Die Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: die Großrechner 61; die Server 62 auf Grundlage der RISC-Architektur (RISC = Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz), die Server 63; die Blade-Server 64; die Speichereinheiten 65; sowie die Netzwerke und Netzwerkkomponenten 66. In einigen Ausführungsformen enthalten die Software-Komponenten die Netzwerkanwendungs-Serversoftware 67 und die Datenbank-Software 68.
  • Die Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Entitäten bereitgestellt werden können: virtuelle Server 71; virtuelle Speicher 72; virtuelle Netzwerke 73; darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
  • In einem Beispiel kann die Verwaltungsschicht 80 die nachfolgend beschriebenen Funktionen bereitstellen. Die Ressourcenbereitstellung 81 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 82 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 83 stellt Nutzern und Systemadministratoren den Zugang zur Cloud-Computing-Umgebung bereit. Die Verwaltung der Dienstgüte 84 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) 85 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 90 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 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalyseverarbeitung 94; Transaktionsverarbeitung 95; und ein Sortierdienst 96.
  • Blockchain-System
  • 4 ist eine Übersichtsdarstellung eines Blockchain-Systems 400 gemäß einigen Ausführungsformen. In der Ausführungsform von 4 kann jede Mitgliedsorganisation (zur Veranschaulichung A, B und C) einer Gemeinschaft, die eine Blockchain nutzt, ein Gesamtsortierdienst-Gateway (TOS-Gateway) GA, GB, GC usw. ausführen, das wiederum als Cluster- oder Cloud-Dienst in den Mitgliedsorganisationen A, B, C der Gemeinschaft eingesetzt werden kann. Die TOS-Gateways GA, GB, GC usw. können jeweils über einen Lese-/Schreibzugriff auf einen Gesamtsortierdienst TSO verfügen, der von einem Drittanbieter verwaltet werden kann.
  • Der Gesamtsortierdienst TOS kann in einigen Ausführungsformen eine gemeinsam genutzte Nachrichtenwarteschlange 450 verwalten, die dazu verwendet werden kann, Nachrichten für alle Teilnehmer der Blockchain-Gemeinschaft zu veröffentlichen. Für einen Kanal, der sich über eine Teilmenge von Organisationen A, B usw. erstreckt, können die TOS-Gateways GA, GB usw. autonom zusammenarbeiten, um einen symmetrischen Schlüssel K zu erzeugen, der nur der Teilmenge von Organisationen A, B usw. bekannt ist, den gemeinsam genutzten Schlüssel aufteilen (d.h. symbolisch (KA, KB usw.) ← Split(K)), die Teile des symmetrischen Schlüssels und die Schlüsselanteile an die anderen TOS-Gateways verteilen und anschließend nur die Schlüsselanteile KA, KB usw. (nicht jedoch den symmetrischen Schlüssel K selbst) im nichtflüchtigen Speicher speichern. Der gemeinsam genutzte symmetrische Schlüssel K kann dagegen in einigen Ausführungsformen und Implementierungen nur in einem flüchtigen Speicher (z.B. RAM) gespeichert werden.
  • Die TOS-Gateways GA, GB, GC können anschließend Transaktionen von den internen Clients CA, CB, CC in den Mitgliedsorganisationen A, B, C der Gemeinschaft empfangen, diese Transaktionen mit dem gemeinsam genutzten symmetrischen Schlüssel K verschlüsseln, eine Gesamtsortierung der verschlüsselten Transaktionen durchführen, die vollständig sortierten Transaktionen entschlüsseln und Blöcke bilden, die Blöcke autonom mit ihren jeweiligen langfristigen privaten Blockchain-Schlüsseln signieren und die Blöcke in ihren Organisationen A, B, C übertragen. Die TOS-Gateways GA, GB, GC können in einigen Ausführungsformen die öffentlichen Zertifikate der anderen kennen und sie zur Überprüfung der Signatur verwenden (in einigen Ausführungsformen können alle Protokollnachrichten signiert werden). Wie in den 7 bis 10 näher erläutert, können die TOS-Gateways GA, GB, Gc in einigen Ausführungsformen und/oder Implementierungen diese Schlüssel darüber hinaus auch autonom rotieren, z.B. bei einer Neukonfiguration der Mitgliedschaft.
  • Der Gesamtsortierdienst TOS in der Ausführungsform von 4 benötigt die unverschlüsselten Transaktionsinformationen, die von internen Clients CA, CB, CC erzeugt werden, nicht und hat in der Regel auch keinen Zugriff darauf. Das heißt, einige Ausführungsformen der vorliegenden Offenbarung können die Vertraulichkeit der Gemeinschaften und Gemeinschaftsorganisationen A, B, C schützen, da der Gesamtsortierdienst TOS keine Informationen über die von ihm verarbeiteten Daten erfahren kann, auch wenn er von einem Dritten ausgeführt wird. Auf diese Weise muss die Organisation, die den Gesamtsortierdienst TOS bereitstellt, kein vertrauenswürdiges Gemeinschaftsmitglied sein, sondern kann stattdessen ein unabhängiger Dritter sein, z.B. ein Anbieter von Cloud-Computing-Diensten. Einige Ausführungsformen der Offenbarung können daher eine Blockchain mit einem delegierten Gesamtsortierdienst enthalten, der: (i) einen Gesamtsortierdienst ermöglicht, der von einem Dritten ausgeführt wird, und (ii) keine vertraulichen oder sonstigen Transaktionsinformationen an diesen Dritten offenlegt.
  • Der Dritte, der den Gesamtsortierdienst TOS in einigen Ausführungsformen ausführt, kann auch als dauerhafter Gesamtsortier-Nachrichtenübertragungsdienst verwendet werden. Dies ermöglicht vorzugsweise eingeschränkte TOS-Gateways GA, GB, GC, die nur die Fähigkeit bereitstellen, Nachrichten zu senden, Nachrichten in der gleichen Reihenfolge zu empfangen und dass die Nachrichten nicht gelöscht werden.
  • Ein weiteres Merkmal und ein Vorteil einiger Ausführungsformen besteht darin, dass sie einen relativ geringen Verwaltungsaufwand erfordern, da die Blockchain-Operationen völlig autonom durchgeführt werden können. Dies kann wiederum eine relativ reibungslose Blockchain-Erfahrung für die Gemeinschaftsmitglieder A, B, C usw. ermöglichen.
  • Der Gesamtsortierdienst TOS kann in einigen Ausführungsformen zusätzlich eine faire Ressourcenzuordnung unter den Mitgliedern der Blockchain-Gemeinschaft bereitstellen, da die Verarbeitung im Allgemeinen das Hochladen von Transaktionen und das Herunterladen von Transaktionen in die gemeinsam genutzte Nachrichtenwarteschlange 450 aufweist. Da das Herunterladen jedoch einfach eine Zusammenfassung des Hochladens ist, können die internen Clients CA, CB, CC von jeder Organisation A, B, C für das Hochladen von Transaktionen in den Gesamtsortierdienst TOS zahlen, und dieser berechnet implizit das Herunterladen durch alle Organisationen A, B, C.
  • Einige Ausführungsformen können auch eines oder mehrere der folgenden Sicherheitsmerkmale umfassen: (i) autonomer Betrieb, sodass das menschliche Element aus der Gleichung entfernt wird; (ii) Widerstandsfähigkeit gegen Absprachen zwischen dem Gesamtsortierdienst TOS und einem bösartigen Administrator, der Zugriff auf das Dateisystem seines lokalen TOS-Gateways hat; (iii) ein Schlüsselerstellungsprotokoll, das geändert werden kann, um zusätzlich zu dem regulären Schema ein quantenresistentes Schema zu verwenden und auf diese Weise eine vorwärts gerichtete Sicherheit im Fall von Quantencomputern zu erreichen; und (iv) verschiedene Schlüssel für verschiedene Kanäle, sodass nicht jede andere Organisation volles Vertrauen haben muss, um diese Schlüssel ordnungsgemäß zu schützen.
  • Distributed Ledger
  • In einigen Ausführungsformen kann es sich bei dem Distributed Ledger um eine sequenzierte, fälschungssichere Aufzeichnung aller Zustandswechsel einer Blockchain handeln. Zustandswechsel können sich aus Chaincode-Aufrufen (d.h. Transaktionen) ergeben, die von beteiligten Parteien (z.B. Client-Knoten, Sortierknoten, Endorser-Knoten, Peer-Knoten usw.) gesendet werden. Eine Transaktion wiederum kann dazu führen, dass ein Satz von Asset-Schlüssel-Wert-Paaren als ein oder mehrere Operanden im Distributed Ledger festgeschrieben werden, z.B. Erzeugen, Aktualisieren, Löschen und Ähnliches. Das Distributed Ledger kann eine Blockchain (auch als Chain bezeichnet) umfassen, die dazu verwendet wird, den unveränderlichen, sequenzierten Datensatz in Blöcken zu speichern. Das Distributed Ledger kann auch eine Zustandsdatenbank umfassen, in der ein aktueller Zustand der Blockchain festgehalten wird. Einige Ausführungsformen verwenden pro Kanal ein Distributed Ledger, es sind jedoch auch andere Ausführungsformen möglich. Jeder Peer-Knoten verwaltet in diesen Ausführungsformen eine Kopie des Distributed Ledger für jeden Kanal, dem er angehört.
  • Die Chain kann in einigen Ausführungsformen ein Transaktionsprotokoll aufweisen, das als Hash-verknüpfte Blöcke strukturiert sein kann, wobei jeder Block eine Sequenz von N Transaktionen enthält, wobei N gleich oder größer als eins ist. Der Blockkopf kann einen Hash der Transaktionen des Blocks sowie einen Hash des Kopfes des vorherigen Blocks umfassen. Auf diese Weise können alle Transaktionen im Ledger sequenziert und kryptografisch miteinander verknüpft werden. Es ist in diesen Ausführungsformen daher praktisch 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 (d.h. 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 kann in einigen Ausführungsformen die neuesten Werte für alle Schlüssel darstellen, 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 in einigen Ausführungsformen 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.
  • Blockchain-Architektur
  • 5A veranschaulicht eine Konfiguration 500 einer Blockchain-Architektur gemäß einigen Ausführungsformen. Die Blockchain-Architektur 500 kann in diesen Ausführungsformen bestimmte Blockchain-Elemente enthalten, so beispielsweise eine Gruppe von Blockchain-Knoten 502. Die Gruppe von Blockchain-Knoten 502 kann ihrerseits einen oder mehrere Mitgliedsknoten 504 bis 510 umfassen (diese vier Knoten sind nur beispielhaft dargestellt). Diese Mitgliedsknoten 504 bis 510 können an einer Reihe von Aktivitäten beteiligt sein, z.B. am Hinzufügen von Blockchain-Transaktionen und am Validierungsprozess (Konsens). Ein oder mehrere der Mitgliedsknoten 504 bis 510 können Transaktionen auf der Grundlage einer Endorsement Policy bestätigen und einen Sortierdienst für alle Blockchain-Knoten in der Architektur 500 bereitstellen. Ein Mitgliedsknoten 504 bis 510 kann eine Blockchain-Authentifizierung initiieren und versuchen, in ein unveränderliches Blockchain-Ledger zu schreiben, das in der Blockchain-Schicht 516 gespeichert ist, von der eine Kopie auch in der zugrunde liegenden physischen Infrastruktur 514 gespeichert sein kann.
  • In einigen Ausführungsformen kann die Blockchain-Architektur 500 eine oder mehrere Anwendungen 524 umfassen, die mit Anwendungsprogrammierschnittstellen (APIs) 522 verbunden sind, um auf gespeicherten Programm-/Anwendungscode 520 (z.B. Chaincode, Smart Contracts usw.) zuzugreifen und ihn auszuführen. Der gespeicherte Programm-/Anwendungscode 520 kann seinerseits nach einer von den Teilnehmern gewünschten individuellen Konfiguration erzeugt werden und seinen eigenen Zustand beibehalten, seine eigenen Assets steuern und externe Informationen empfangen. Der gespeicherte Programm-/Anwendungscode 520 kann als Transaktion implementiert und durch Anhängen an das Distributed Ledger auf allen Blockchain-Knoten 504 bis 510 implementiert werden.
  • Eine Blockchain-Basis oder -Plattform 512 kann verschiedene Schichten von Blockchain-Daten, Dienste (z.B. kryptografische 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. Eine Blockchain-Schicht 516 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 eine physische Infrastruktur 514 zu nutzen. Die kryptografischen Vertrauensdienste 518 können verwendet werden, um Transaktionen wie den Austausch von Assets zu überprüfen und Informationen vertraulich zu halten.
  • Die Konfiguration der Blockchain-Architektur von 5A kann den Programm-/ Anwendungscode 520 über eine oder mehrere von der Blockchain-Plattform 512 zur Verfügung gestellte Schnittstellen und bereitgestellte Dienste verarbeiten und ausführen. Der Programm-/Anwendungscode 520 kann Blockchain-Assets kontrollieren. Der Code 520 kann beispielsweise Daten speichern und übertragen und von den Mitgliedsknoten 504 bis 510 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 Erinnerungen, Aktualisierungen und/oder Mitteilungen aufgrund von Änderungen, Aktualisierungen 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 Dokumentattributinformationen 526 von einer oder mehreren Verarbeitungsentitäten (z.B. virtuelle Maschinen) verarbeitet werden, die in der Blockchain-Schicht 516 enthalten sind. Ein Ergebnis 528 kann eine Mehrzahl von verknüpften, gemeinsam genutzten Dokumenten enthalten. Die physische Infrastruktur 514 kann zum Abrufen der hier beschriebenen Daten oder Informationen verwendet werden.
  • In einigen Ausführungsformen kann der Smart Contract über eine hoch entwickelte 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 und erfüllt werden, 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) in einigen Ausführungsformen automatisch im gesamten verteilten Netzwerk von Blockchain-Peers durch ein oder mehrere Konsensprotokolle repliziert werden.
  • Der Smart Contract kann Daten im Format von Schlüssel-Wert-Paaren in die Blockchain schreiben. Darüber hinaus kann der Code des Smart Contract in einigen Ausführungsformen die in einer Blockchain gespeicherten Werte lesen und in Operationen der Anwendung verwenden. Der Code des Smart Contract kann in diesen Ausführungsformen die Ausgabe verschiedener logischer Operationen anschließend in die Blockchain schreiben. Der Code des Smart Contract kann in einigen Ausführungsformen dazu verwendet werden, eine temporäre Datenstruktur in einer virtuellen Maschine oder anderen Datenverarbeitungsplattformen zu erzeugen. Daten, die in diesen Ausführungsformen in die Blockchain geschriebenen werden, können öffentlich oder verschlüsselt sein und als vertraulich behandelt werden. Die temporären Daten, die vom Smart Contract verwendet/erzeugt werden, können von der bereitgestellten Ausführungsumgebung im Speicher gespeichert und dann gelöscht werden, sobald die für die Blockchain benötigten Daten identifiziert sind.
  • Der Chaincode kann in einigen Ausführungsformen die Code-Interpretation eines Smart Contract umfassen und zusätzliche Funktionen enthalten. In einigen Ausführungsformen kann der Chaincode als Programmcode in einem Datenverarbeitungsnetzwerk implementiert werden, wo er von den Chain-Validierern im Rahmen eines Konsensverfahrens ausgeführt und validiert wird. Der Chaincode kann einen Hash empfangen und aus der Blockchain einen Hash abrufen, 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, kann der Chaincode einen Autorisierungsschlüssel an den angeforderten Dienst senden. Der Chaincode kann Daten in die Blockchain schreiben, die den kryptografischen Einzelheiten zugehörig sind.
  • 5B veranschaulicht ein Beispiel für einen Blockchain-Transaktionsablauf 550 zwischen Knoten der Blockchain gemäß einigen Ausführungsformen. In diesen Ausführungsformen kann der Transaktionsablauf einen Transaktionsvorschlag 591 umfassen, der von einem Anwendungs-Client-Knoten 560 an einen bestätigenden Peer-Knoten 581 gesendet wird. Der bestätigende Peer 581 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 592 auf den Vorschlag kann anschließend zusammen mit einer Bestätigungssignatur (falls genehmigt) an den Client 560 zurückgesendet werden.
  • Als Reaktion darauf, kann der Client 560 die Bestätigungen in den Transaktionsnutzdaten 593 zusammenstellen und diese an einen Sortierdienstknoten 584 übertragen. Der Sortierdienstknoten 584 kann dann sortierte Transaktionen als Blöcke an alle Peers 581 bis 583 in einem Kanal ausgeben. Vor dem Festschreiben in der Blockchain kann jeder Peer 581 bis 583 die Transaktion validieren. So können die Peers in einigen Ausführungsformen beispielsweise die Endorsement Policy überprüfen, um sicherzustellen, dass die richtige Anzahl der angegebenen Peers die Ergebnisse signiert und die Signaturen anhand der Transaktionsnutzdaten 593 authentifiziert hat.
  • Weiterhin mit Bezug auf 5B kann der Client-Knoten 560 in einigen Ausführungsformen die Transaktion 591 initiieren, indem er eine Anforderung an den Peer-Knoten 581 erzeugt und sendet, der als Endorser fungieren kann. Der Client 560 kann eine Anwendung umfassen, die ein unterstütztes Software-Entwicklungskit (software development kit - SDK) nutzt, das eine verfügbare API verwenden kann, um einen Transaktionsvorschlag zu erzeugen. Bei dem Transaktionsvorschlag wiederum kann es sich um eine Anforderung handeln, eine Chaincode-Funktion aufzurufen, damit Daten gelesen und/oder in das Distributed Ledger geschrieben werden können (d.h., neue Schlüssel-Wert-Paare für die Assets schreiben). Das SDK kann als Shim dienen, um den Transaktionsvorschlag in ein geeignetes Architekturformat zu packen (z.B. Protokollpuffer über einen Fernprozeduraufruf (remote procedure call - RPC)) und die kryptografischen Berechtigungsnachweise des Clients zu verwenden, um eine eindeutige Signatur für den Transaktionsvorschlag zu erzeugen.
  • Als Reaktion darauf kann der bestätigende Peer-Knoten 281 prüfen: ob (a) der Transaktionsvorschlag korrekt formatiert ist; (b) die Transaktion nicht bereits in der Vergangenheit gesendet wurde (Schutz vor Wiederholungsangriffen); (c) die Signatur gültig ist und (d) der Sender (in dieser beispielhaften Ausführungsform der Client 560) ordnungsgemäß berechtigt ist, die vorgeschlagene Operation auf diesem Kanal durchzuführen. Der bestätigende Peer-Knoten 581 kann die Eingaben des Transaktionsvorschlags als Argumente für die aufgerufene Chaincode-Funktion verwenden. Der Chaincode kann dann auf der Grundlage einer Datenbank mit dem aktuellen Zustand ausgeführt werden, um Transaktionsergebnisse zu erzeugen, darunter ein Antwortwert, ein Lesesatz und ein Schreibsatz. In einigen Ausführungsformen wird das Ledger zu diesem Zeitpunkt nicht aktualisiert. Stattdessen können der Satz von Werten zusammen mit der Signatur des bestätigenden Peer-Knotens 581 als Antwort 592 auf den Vorschlag an das SDK des Clients 560 zurückgesendet werden, der die Nutzdaten für die Anwendung zur Nutzung parst.
  • Als Reaktion darauf kann die Anwendung des Clients 560 die Signaturen der bestätigenden Peers überprüfen/verifizieren und die Vorschlagsantworten vergleichen, um zu ermitteln, ob die Vorschlagsantwort dieselbe ist. Würde der Chaincode nur das Ledger abfragen, könnte die Anwendung die Antwort auf die Abfrage überprüfen und würde die Transaktion in der Regel nicht an den Sortierdienst 584 senden. Beabsichtigt die Client-Anwendung, die Transaktion zum Aktualisieren des Ledger an den Sortierdienst 584 zu senden, kann die Anwendung vor dem Senden ermitteln, ob die angegebene Endorsement Policy erfüllt ist (d.h., haben alle für die Transaktion erforderlichen Peer-Knoten die Transaktion bestätigt). 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 kann der Client 560 in der Operation 594 Bestätigungen zu einer Transaktion zusammenstellen und den Transaktionsvorschlag und die Antwort in einer Transaktionsnachricht an den Sortierdienst 584 senden. Die Transaktion kann die Lese-/Schreibsätze, die Signaturen der bestätigenden Peers und eine Kanal-ID enthalten. Der Sortierdienst 584 muss nicht den gesamten Inhalt einer Transaktion überprüfen, um seine Operation durchzuführen; stattdessen kann der Sortierdienst 584 einfach Transaktionen von allen Kanälen im Netzwerk empfangen, sie chronologisch nach Kanal sortieren und Blöcke von Transaktionen pro Kanal erzeugen.
  • Die Blöcke der Transaktion können vom Sortierdienst 584 an alle Peer-Knoten 581 bis 583 im Kanal übermittelt werden. Die Transaktionen im Block können validiert werden, 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 können als gültig oder ungültig gekennzeichnet werden. Darüber hinaus kann jeder Peer-Knoten 581 bis 583 in der Operation 595 den Block an die Chain des Kanals anfügen, und für jede gültige Transaktion werden die Schreibsätze in der aktuellen Zustandsdatenbank festgeschrieben. Ein Ereignis kann ausgelöst werden, 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.
  • Genehmigungspflichte Blockchains
  • 6A veranschaulicht gemäß einigen Ausführungsformen ein Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 602 eine Transaktion in der genehmigungspflichtigen Blockchain 604 beginnen. In diesem Beispiel kann es sich bei der Transaktion um Implementieren, Aufrufen oder Abfragen handeln, und sie kann über eine clientseitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können den Zugriff auf einen Regulierer 606, z.B. einen Prüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 608 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 606 als „Prüfer“ und des Blockchain-Benutzers 602 als „Client“. Ein Prüfer kann darauf beschränkt sein, nur das Ledger abzufragen, während ein Client berechtigt sein kann, bestimmte Arten von Chaincode zu implementieren, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 610 kann in einigen Ausführungsformen Chaincode und clientseitige Anwendungen schreiben. Der Blockchain-Entwickler 610 kann in diesen Ausführungsformen Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 612 in Chaincode zu integrieren, kann der Entwickler 610 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel kann sich der Blockchain-Benutzer 602 über einen Peer-Knoten 614 mit der genehmigungspflichtigen Blockchain 604 verbinden. Bevor der Peer-Knoten 614 mit den Transaktionen fortfährt, kann er die Anmelde- und Transaktionszertifikate des Benutzers von einer Zertifizierungsstelle 616 abrufen, die Benutzerrollen und -genehmigungen verwaltet. In einigen Ausführungsformen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 604 Transaktionen durchführen zu können. In anderen Ausführungsformen können die Benutzer der Blockchain mit anderen Techniken, z.B. über verteilte Vertrauensketten, authentifiziert werden. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 612 überprüfen. Um die Berechtigung des Benutzers zu bestätigen, kann der Chaincode eine Out-of-Band-Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 618 nutzen.
  • 6B veranschaulicht gemäß einigen Ausführungsformen ein weiteres Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 622 eine Transaktion an die genehmigungspflichtige Blockchain 624 senden. In diesem Beispiel kann es sich bei der Transaktion um Implementieren, Aufrufen oder Abfragen handeln, und sie kann über eine clientseitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können den Zugriff auf einen Regulierer 626, z.B. einen Prüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 628 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 626 als „Prüfer“ und des Blockchain-Benutzers 622 als „Client“. Ein Prüfer könnte darauf beschränkt sein, nur das Ledger abzufragen, während ein Client berechtigt sein könnte, bestimmte Arten von Chaincode zu implementieren, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 631 kann in diesen Ausführungsformen Chaincode und clientseitige Anwendungen schreiben. Der Blockchain-Entwickler 631 kann Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 632 in Chaincode zu integrieren, kann der Entwickler 631 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel verbindet sich der Blockchain-Benutzer 622 über einen Peer-Knoten 634 mit dem Netzwerk. Bevor der Peer-Knoten 634 mit den Transaktionen fortfährt, ruft er die Anmelde- und Transaktionszertifikate des Benutzers von der Zertifizierungsstelle 636 ab, die die Rollen und Genehmigungen der Benutzer verwaltet. In einigen Ausführungsformen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 624 Transaktionen durchführen zu können. In anderen Ausführungsformen können die Benutzer der Blockchain mit anderen Techniken, z.B. über verteilte Vertrauensketten, authentifiziert werden. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 632 überprüfen. Um die Berechtigung des Benutzers zu bestätigen, kann der Chaincode eine Out-of-Band-Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 638 nutzen.
  • 6C veranschaulicht gemäß einigen Ausführungsformen ein beispielhaftes System, das eine physische Infrastruktur 611 umfasst, die so konfiguriert ist, dass sie verschiedene Operationen durchführt. Mit Bezug auf 6C umfasst die physische Infrastruktur 611 ein Modul 688 und ein Modul 689. Das Modul 619 umfasst eine Blockchain 620 und einen Smart Contract 630 (der sich in der Blockchain 620 befinden kann), der jeden der in einer der beispielhaften Ausführungsformen enthaltenen operativen Schritte 678 (in Modul 688) ausführen kann. Die Schritte/Operationen 678 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen umfassen und können ausgegebene oder geschriebene Informationen darstellen, die in einen oder mehrere Smart Contracts 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Die physische Infrastruktur 611, das Modul 688 und das Modul 689 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 688 und das Modul 689 ein und dasselbe Modul sein.
  • 6D veranschaulicht gemäß einigen Ausführungsformen ein weiteres beispielhaftes System, das so konfiguriert ist, dass es verschiedene Operationen durchführt. Mit Bezug auf 6D umfasst das System ein Modul 692 und ein Modul 694. Das Modul 694 umfasst eine Blockchain 620 und einen Smart Contract 630 (der sich in der Blockchain 620 befinden kann), der jeden der in einer der beispielhaften Ausführungsformen enthaltenen operativen Schritte 678 (in Modul 692) ausführen kann. Die Schritte/Operationen 678 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen umfassen und können ausgegebene oder geschriebene Informationen darstellen, die in einen oder mehrere Smart Contracts 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Das physische Modul 692 und das Modul 694 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 692 und das Modul 694 ein und dasselbe Modul sein.
  • 6E veranschaulicht gemäß beispielhaften Ausführungsformen ein beispielhaftes System, das so konfiguriert ist, dass es eine Konfiguration eines Smart Contract zwischen Vertragsparteien und einem vermittelnden Server verwendet, der so konfiguriert ist, dass er die Bedingungen des Smart Contract in der Blockchain 620 umsetzt. Mit Bezug auf 6E kann die Konfiguration eine Datenübertragungssitzung, eine Asset-Übertragungssitzung oder einen Prozess oder eine Prozedur darstellen, die durch einen Smart Contract 630 gesteuert wird, der ausdrücklich eine oder mehrere Benutzereinheiten 652 und/oder 656 identifiziert. Die Ausführung, die Operationen und die Ergebnisse der Ausführung des Smart Contract können von einem Server 654 verwaltet werden. Der Inhalt des Smart Contract 630 kann digitale Signaturen von einer oder mehreren der Entitäten 652 und 656 erfordern, die an der Transaktion des Smart Contract beteiligt sind. Die Ergebnisse der Ausführung des Smart Contract können als Blockchain-Transaktion in eine Blockchain 620 geschrieben werden. Der Smart Contract 630 befindet sich in der Blockchain 620, die sich in einem oder mehreren Computern, Servern, Prozessoren, Speichern und/oder drahtlosen Datenübertragungseinheiten befinden kann.
  • 6F veranschaulicht gemäß einigen Ausführungsformen ein System 660, das eine Blockchain umfasst. Mit Bezug auf das Beispiel von 6D stellt ein Anwendungsprogrammierschnittstellen(API)-Gateway 662 eine gemeinsame Schnittstelle für den Zugriff auf eine Blockchain-Logik (z.B. Smart Contract 630 oder anderer Chaincode) und Daten (z.B. Distributed Ledger usw.) bereit. In diesem Beispiel ist das API-Gateway 662 eine gemeinsame Schnittstelle zum Durchführen von Transaktionen (Aufrufe, Abfragen usw.) in der Blockchain, indem eine oder mehrere Entitäten 652 und 656 mit einem Blockchain-Peer (d.h. einem Server 654) verbunden werden. In diesem Fall ist der Server 654 eine Peer-Komponente des Blockchain-Netzwerks, die eine Kopie des World State (allgemeiner Zustand) und ein Distributed Ledger enthält, das es den Clients 652 und 656 ermöglicht, Daten über den World State abzufragen und Transaktionen an das Blockchain-Netzwerk zu senden, wo die bestätigenden Peers die Smart Contracts 630 je nach Smart Contract 630 und Endorsement Policy ausführen werden.
  • Erzeugen eines Kanals
  • Die 7A und 7B (zusammen 7) veranschaulichen ein Verfahren 700 zum Erzeugen eines Kanals in einem Blockchain-Netzwerk gemäß einigen Ausführungsformen. In Operation 710 sendet ein Blockchain-Administrator eine Transaktionsnachricht (tx) zum Erzeugen eines Kanals an das TOS-Gateway GA. Das TOS-Gateway GA kann in Operation 720 reagieren, indem es eine Kanalinitialisierungsnachricht („CHAN INIT BEGIN“) für die gemeinsam genutzte Nachrichtenwarteschlange 450 veröffentlicht. Die TOS-Gateways GB, Gc, die den Organisationen B bzw. C zugehörig sind, können die Nachricht in Operation 730 vom Gesamtsortierdienst TOS empfangen. Als Reaktion darauf kann jedes empfangende TOS-Gateway GB, GC einen zufälligen, ephemeren, privaten Schlüssel und ein entsprechendes öffentliches Schlüsselpaar PB, PC in Operation 732 erzeugen und anschließend die öffentlichen Schlüssel PB, PC in Operation 734 für die gemeinsam genutzte Nachrichtenwarteschlange 450 veröffentlichen.
  • Als Nächstes kann das TOS-Gateway GA in Operation 740 einen zufälligen symmetrischen Schlüssel K für die Organisation A erzeugen und den erzeugen Schlüssel K in Operation 742 in „t“ Anteile aufteilen (drei Anteile in diesem Beispiel, ein Anteil für jedes TOS-Gateway GA, GB, GC usw. in der Blockchain). Das TOS-Gateway GA kann dann die Schlüsselanteile an die anderen TOS-Gateways verteilen. Dazu kann Verschlüsseln der aufgeteilten Schlüssel der anderen Gateways in Operation 744 gehören: PB(KB), PC(KC) usw. sowie Veröffentlichen der daraus sich ergebenden verschlüsselten Texte in Operation 746. Jedes andere TOS-Gateway GB, GC usw. kann seinen Schlüsselanteil (KB, KC usw.) in Operation 750 entschlüsseln und den entschlüsselten Schlüsselanteil zusammen mit seinem Teil des symmetrischen Schlüssels H(K) in Operation 752 in seinem lokalen permanenten Speicher speichern. Alternativ kann wie nachstehend ausführlich beschrieben jedes TOS-Gateway GA, GB, GC seinen eigenen Schlüsselanteil von dem symmetrischen Schlüssel erzeugen.
  • In Operation 760 kann jedes andere TOS-Gateway GB, GC eine Nachricht „CHAN INIT END“ veröffentlichen und dann seine ephemeren, privaten Schlüssel vergessen (d.h. löschen). Die TOS-Gateways GA, GB, GC können in Operation 762 ihre aufgeteilten Schlüssel KA, KB, KC in ihrem eigenen permanenten Speicher speichern und K(tx) in Operation 764 veröffentlichen. Auf diese Weise kann die veröffentlichte Transaktion (tx) das Erzeugen der Kanaltransaktion sein. Die vorangegangenen Operationen können den Verschlüsselungsschlüssel erzeugen, mit dem die Transaktion verschlüsselt wird. In einigen Ausführungsformen kann dieser Schlüssel verschlüsselt werden, um zu verhindern, dass der TOS seinen Inhalt einsehen kann, da er sensible Informationen enthalten kann, z.B. wer die Parteien im Kanal sind usw.
  • Ableiten des symmetrischen Schlüssels
  • In einigen Ausführungsformen kann der Verschlüsselungsschlüssel als Startwert für einen Schlüsselableitungsalgorithmus verwendet werden, der den Schlüssel bei jeder Anzahl von Nachrichten deterministisch ändert: { SHA 256 ( K |   | X |   | i ) } X ∈ { „ A “ , „ B “ , „ C “ }
    Figure DE112021004344T5_0001
    wobei „i“ ein Zähler ist, der periodisch erhöht werden kann, z.B. nach einer zuvor festgelegten Anzahl von Nachrichten (z.B. 232 Nachrichten, 296 Nachrichten), wöchentlich, monatlich, vierteljährlich usw. Die Anteile wiederum können je nach verwendetem Feld gleichmäßig zufällig verteilt werden. Ein Vorteil der Verwendung dieses Systems besteht darin, dass die verschiedenen TOS-Gateways GA, GB usw. möglicherweise nicht denselben Zählerwert verwenden und sich nicht darüber abstimmen müssen, wie sie die Zähler initialisieren. Ein weiterer Vorteil ist, dass dieses System die Reihenfolge der Schlüsselanteile unter den Blockchain-Mitgliedern automatisch rotieren kann (z.B. kann das TOS-Gateway GN den ersten Schlüsselanteil während des ersten Zählerzeitraums und den fünften Schlüsselanteil während des zweiten Zählerzeitraums haben usw.).
  • Wiederherstellen des symmetrischen Schlüssels
  • In einigen Ausführungsformen wird der symmetrische Schlüssel K eines Kanals nicht in einen nichtflüchtigen Speicher (z.B. eine Festplatte) geschrieben, sondern nur in einem flüchtigen Speicher (z.B. einem Direktzugriffsspeicher) gespeichert. 8 veranschaulicht ein Verfahren 800 zum Wiederherstellen eines symmetrischen Schlüssels durch das TOS-Gateway GA gemäß einigen Ausführungsformen. Um Nachrichten, die vom Gesamtsortierdienst empfangen wurden, zu entschlüsseln oder verschlüsseln, kann ein TOS-Gateway GA die geheimen Informationen entweder wiederherstellen, indem es genügend Schlüsselanteile von den entfernt angeordneten TOS-Gateways GB, GC usw. abruft, oder sie einfach von einem anderen TOS-Gateway GB, GC usw. empfangen, das sie zuvor wiederhergestellt hat. In einigen Ausführungsformen kann ein TOS-Gateway seinen eigenen Anteil nicht berechnen, ohne die Anteile der anderen Gateways zu kennen, da es nicht über ausreichende Informationen verfügt.
  • Um den symmetrischen Schlüssel von einem anderen TOS-Gateway zu erhalten, kann das TOS-Gateway GA zuerst in einem Rundlaufverfahren Kontakt zu den anderen TOS-Gateways GB, GC aufnehmen und sie in Operation 810 nach dem symmetrischen Schlüssel fragen. Wenn kein anderes TOS-Gateway GB, GC usw. den symmetrischen Schlüssel hat, beginnt das TOS-Gateway GA damit, ihn mithilfe der Schlüsselanteile KB, KC usw. von „t-1“ der TOS-Gateways GB, GC usw. wiederherzustellen, wobei „t“ vom Administrator des Blockchain-Netzwerks auf der Grundlage der Sicherheitsanforderungen des Netzwerks ausgewählt werden kann.
  • Die TOS-Gateways können jedoch in einigen Ausführungsformen keine Peer-to-Peer-IP-Verbindung teilen. Stattdessen können sie über die gemeinsam genutzte Nachrichtenwarteschlange 450 Daten austauschen, indem sie zunächst in den Operationen 820 bis 836 ein Protokoll zum Erzeugen eines ephemeren Schlüsselpaares über die gemeinsam genutzte Nachrichtenwarteschlange initiieren/ausführen, um einen symmetrischen Verschlüsselungsschlüssel zu erzeugen, der zum Verschlüsseln des Austauschs von K und/oder seiner Anteile verwendet wird. Genauer gesagt kann das TOS-Gateway GA in Operation 820 zuerst einen ephemeren, privaten Schlüssel α und sein öffentliches Gegenstück Pα erzeugen und eine Schlüsselaustauschnachricht (die unverschlüsselt sein kann) veröffentlichen. Im Allgemeinen ist das Schlüsselaustauschprotokoll in einigen Ausführungsformen so ausgelegt, dass es über ein unsicheres Medium funktioniert, um einen symmetrischen Verschlüsselungsschlüssel zu erzeugen. Einige Ausführungsformen für den Schlüsselaustausch können jedoch in Operation 822 auch eine Verschlüsselung in der gemeinsam genutzten Nachrichtenwarteschlange verwenden, die an ein anderes TOS-Gateway (z.B. TOS-Gateway GB) weitergeleitet wird, wobei der neue, ephemere, öffentliche Schlüssel (symbolisch {KEX_GB, Pα}) in der gemeinsam genutzten Nachrichtenwarteschlange 450 enthalten ist. Wenn das TOS-Gateway GA den ursprünglichen, zufälligen, symmetrischen Schlüssel K wiederherstellen möchte, kann es in Operation 822 an die Nachricht auch eine Schlüsselanforderung („KEY“) anhängen; auf ähnliche Weise kann das TOS-Gateway GA in Operation 822 ebenfalls eine Schlüsselanteilanforderung („SHR“) anhängen, wenn es einen Schlüsselanteil erhalten möchte.
  • Als Reaktion auf die Schlüsselaustauschnachricht kann das TOS-Gateway GB in Operation 830 einen ephemeren, privaten Schlüssel β und sein öffentliches Gegenstück Pβ erzeugen. Das TOS-Gateway GB kann anschließend in Operation 832 den ephemeren, symmetrischen Schlüssel (KEXAB) anhand von β und PA berechnen. Das TOS-Gateway GB kann dann in Operation 834 (unter Verwendung von KEXAB) den symmetrischen Schlüssel (d.h. {Pβ, KEXAB(K)}) verschlüsseln und als Reaktion auf eine „KEY“-Anforderung vom TOS-Gateway GA für die gemeinsam genutzte Nachrichtenwarteschlange veröffentlichen, oder es kann den Schlüsselanteil (d.h. {Pβ, KEXAB(KB)} des TOS-Gateways GB verschlüsseln und als Reaktion auf eine „SHR“-Anforderung vom TOS-Gateway GA für die gemeinsam genutzte Warteschlange veröffentlichen.
  • In Operation 840 kann das TOS-Gateway GB den ephemeren, privaten Schlüssel β vergessen. Das heißt, es kann den ephemeren, privaten Schlüssel aus seinem flüchtigen Speicher löschen, da es ihn nie in seinem nichtflüchtigen Speicher gespeichert hat. Das TOS-Gateway GA kann in Operation 850 den ursprünglichen, zufälligen, symmetrischen Schlüssel K entschlüsseln oder K anhand der Schlüsselfragmente KA, KB usw. wiederherstellen. In Operation 855 kann das TOS-Gateway GA dann ebenfalls seinen ephemeren, privaten Schlüssel α vergessen. Auf diese Weise bleibt der ursprüngliche, zufällige, symmetrische Schlüssel K auch dann geschützt, wenn eine Entität Zugriff auf die gemeinsam genutzte Nachrichtenwarteschlange 450 erhält.
  • Erweitern der Mitgliedschaft in der Gemeinschaft
  • 9 ist ein Ablaufplan, der gemäß einigen Ausführungsformen ein Verfahren 900 zum Erweitern der Mitgliedschaft in einer Blockchain veranschaulicht. In dieser Ausführungsform kann jedes Mal, wenn ein neues Mitglied/eine neue Organisation „D“ zu dem Kanal hinzukommt, das TOS-Gateway GD den gemeinsam genutzten Schlüssel K und seinen eigenen Schlüsselanteil KD erhalten. Das TOS-Gateway GD beginnt in Operation 910, indem es Kontakt zu „t“ der vorhandenen Kanalmitglieder A, B, C usw. unter Verwendung des mit Bezug auf 8 beschriebenen Protokolls aufnimmt, um den aktuellen symmetrischen Schlüssel K wiederherzustellen und ihn (nur) in seinem flüchtigen Speicher zu speichern, wobei „t“ eine Zahl ist, die ein Administrator für die Blockchain auf der Grundlage ihres Sicherheitsprofils ausgewählt hat. Das neue TOS-Gateway GD kann anschließend in Operation 920 mithilfe der vorstehend beschriebenen Verfahren seinen eigenen eindeutigen Schlüsselanteil KD berechnen, d.h. ein Anteil, der sich von allen anderen Schlüsselanteilen KA, KB, KC usw. unterscheidet, und KD in Operation 930 in seinem permanenten Speicher speichern. Alternativ kann eines der anderen TOS-Gateways den Schlüsselanteil KD berechnen und ihn zusammen mit dem gemeinsam genutzten symmetrischen Schlüssel übermitteln.
  • Wenn ein neues Mitglied D in der Kanalkonfiguration erkannt wird, können alle vorhandenen TOS-Gateways GA, GB, GC usw. auf ähnliche Weise mit dem neuen TOS-Gateway GD eine Sitzung zum Erzeugen eines ephemeren Schlüsselpaares durchführen, nach der das neue TOS-Gateway GD K und KD erhält.
  • Entfernen eines Mitglieds aus der Gemeinschaft
  • Wenn ein Mitglied von den Blockchain-Mitgliedern A, B, C und/oder dem Blockchain-IT-Administrator aus einem Kanal entfernt wird, kann der Gesamtsortierdienst TOS den Verschlüsselungsschlüssel K rotieren, sodass das entfernte Mitglied die Nachrichten in der gemeinsam genutzten Nachrichtenwarteschlange 450 nicht mehr entschlüsseln kann. Die 10A und 10B (zusammen 10) veranschaulichen ein solches Verfahren zum Rotieren der Schlüssel 1000 gemäß einigen Ausführungsformen. In diesem veranschaulichenden Beispiel wird nur zur Illustration angenommen, dass die Organisationen A und B die Organisation C aus dem Kanal entfernen möchten. In Operation 1010 sendet ein Blockchain-Administrator eine Kanalkonfigurationstransaktion (tx) an das TOS-Gateway GA, das in Operation 1020 darauf reagieren kann, indem es eine Kanalneukonfigurationsnachricht tx („CHAN RECONF A B BEGIN“) für den Gesamtsortierdienst TOS veröffentlicht.
  • Das TOS-Gateway GB kann die Kanalneukonfigurationsnachricht empfangen und in Operation 1030 darauf reagieren, indem es einen zufälligen, ephemeren, privaten Schlüssel β und einen entsprechenden öffentlichen Schlüssel Pβ erzeugt. Das TOS-Gateway GB kann dann in Operation 1035 den öffentlichen Schlüssel Pβ für den Gesamtsortierdienst TOS veröffentlichen.
  • Das TOS-Gateway GA kann darauf reagieren, indem es in Operation 1040 einen neuen, zufälligen, symmetrischen Schlüssel K1 erzeugt und ihn in Operation 1043 in n Anteile aufteilt (wobei n der verbleibenden Anzahl von Mitgliedern entspricht, in diesem Fall zwei). Das TOS-Gateway GA kann in Operation 1045 den/die Schlüsselanteil(e) mithilfe des ephemeren, öffentlichen Schlüssels des anderen TOS-Gateways GB (z.B. für GB: Pβ(K1 B), Pβ(K1), and K1(tx)) verschlüsseln und diese in Operation 1047 für den Gesamtsortierdienst TOS veröffentlichen. Das heißt, einige Ausführungsformen können zuerst den Schlüssel ändern und dann alle außer der entfernten Organisation dazu bringen, den neuen Schlüssel zu lernen. Diese Ausführungsformen müssen jedoch möglicherweise noch die Neukonfiguration auf die Blockchain selbst anwenden, sodass diese Ausführungsformen die Neukonfigurationstransaktion mit dem neuen Schlüssel verschlüsseln und dann senden können. Alternativ kann das TOS-Gateway GB seinen eigenen Schlüsselanteil mit dem neuen symmetrischen Schlüssel K1 unter Verwendung der vorstehend beschriebenen Verfahren berechnen.
  • Das TOS-Gateway GB kann seinen Schlüsselanteil K1 B, den neuen symmetrischen Schlüssel K1 und tx in Operation 1050 entschlüsseln. Das TOS-Gateway GB kann dann in Operation 1052 bestätigen, dass die Organisation C tatsächlich aus dem Kanal entfernt wurde, und wenn dies der Fall ist, speichert es K1 B in Operation 1054 in seinem permanenten Speicher und veröffentlicht in Operation 1056 eine Nachricht über das Ende der Kanalneukonfiguration („CHAN RECONF A B END“) für den Gesamtsortierdienst TOS.
  • Neukonfiguration der Mitgliedschaft in der Gemeinschaft
  • Um das erneute Hinzufügen entfernter Organisationen und/oder die Neukonfiguration von Kanälen (z.B. Erzeugen von Kanälen) zu unterstützen, kann jedes TOS-Gateway GA, GB usw. Schlüsselanteile KA, KB usw. entsprechend den Blockbereichen mit kontinuierlicher Mitgliedschaft speichern. In diesen Fällen können die vorherigen Schlüsselanteile im Blockbereich verwendet werden, wenn alle aktuellen und zukünftigen Mitglieder des Kanals das Beibehalten ihrer Schlüsselanteile bestätigen. In ähnlicher Weise müssen alle neu hinzugekommenen Organisationen die symmetrischen Schlüssel der Vergangenheit lernen.
  • Unbestreitbarkeit und Integritätsgarantien
  • Einige Ausführungsformen können die Unbestreitbarkeit unterstützen und Integritätsgarantien bereitstellen. Diese Ausführungsformen können für den Fall wünschenswert sein, dass sich der Gesamtsortierdient TOS nicht korrekt verhält oder nicht richtig funktioniert und die verschiedenen TOS-Gateways GA, GB usw. infolgedessen Nachrichten in unterschiedlicher Reihenfolge empfangen. In ähnlicher Weise können diese Ausführungsformen für den Fall wünschenswert sein, dass eine Mitgliedsorganisation A, B usw. fälschlicherweise angibt, dass der Gesamtsortierdienst TOS ihnen Nachrichten in einer anderen Reihenfolge gesendet habe als sie diese empfangen haben.
  • Um ein solcher Ereignis erkennen zu können, wenn es tatsächlich eingetreten ist, oder um eine falsche Behauptung zu widerlegen, kann jedes TOS-Gateway in einigen Ausführungsformen in regelmäßigen Abständen (z.B. alle B-Blöcke oder T-Zeiten) eine Nachricht veröffentlichen, die Folgendes enthalten kann: (i) Blockbereiche [i, j] für die Nachricht; und (ii) eine Merkle-Wurzel (z.B. ein Hash aller Hashes allerTransaktionen, die Teil eines Blocks in einem Blockchain-Netzwerk sind), wobei die Blöcke, die mit [i, j] indiziert sind, ihre Blätter sind. Erkennt ein TOS-Gateway GA, GB usw., dass es sich von der Mehrheit der anderen Netzwerkmitglieder abgespalten hat, kann das TOS-Gateway den Betrieb einstellen und bei der Bearbeitung von API-Aufrufen einen speziellen Fehler zurücksenden.
  • Blockverarbeitung
  • 11A veranschaulicht gemäß einigen Ausführungsformen einen Prozess 1100, bei dem ein neuer Datenblock 1130 zu einem Distributed Ledger 1120 hinzugefügt wird, und 11B veranschaulicht gemäß einigen Ausführungsformen den Inhalt eines neuen Datenblocks 1130 für eine Blockchain. Der neue Datenblock 1130 kann Dokumentverknüpfungsdaten enthalten.
  • Mit Bezug auf 11A können Clients (nicht dargestellt) Transaktionen an die Blockchain-Knoten 1111, 1112 und/oder 1113 senden. Clients können Anweisungen sein, die von einer beliebigen Quelle empfangen werden, um eine Aktivität in der Blockchain 1122 auszuführen. Bei den Clients kann es sich beispielsweise um Anwendungen handeln, die im Namen eines Anforderers, z.B. einer Einheit, einer Person oder einer Entität, handeln, um Transaktionen für die Blockchain vorzuschlagen. Die Mehrzahl von Blockchain-Peers (z.B. die Blockchain-Knoten 1111, 1112 und 1113) können einen Zustand des Blockchain-Netzwerks und eine Kopie des Distributed Ledger 1120 speichern. Im Blockchain-Netzwerk können verschiedene Arten von Blockchain-Knoten/Peers vorhanden sein, z.B. bestätigende Peers, die von Clients vorgeschlagene Transaktionen simulieren und bestätigen, und festschreibende Peers, die Bestätigungen überprüfen, Transaktionen validieren und diese im Distributed Ledger 1120 festschreiben. In einigen Ausführungsformen können die Blockchain-Knoten 1111, 1112 und 1113 die Rolle eines Endorser-Knotens, eines festschreibenden Knotens oder beider durchführen.
  • Das Distributed Ledger 1120 kann eine Blockchain umfassen, die unveränderliche, sequenzierte Datensätze in Blöcken speichert, und eine Zustandsdatenbank 1124 (aktueller World State), in der ein aktueller Zustand der Blockchain 1122 gespeichert ist. Pro Kanal kann ein Distributed Ledger 1120 vorhanden sein, und jeder Peer unterhält seine eigene Kopie des Distributed Ledger 1120 für jeden Kanal, dessen Mitglied er ist. Bei der Blockchain 1122 kann es sich um ein Transaktionsprotokoll handeln, das in Form von Hash-verknüpften Blöcken aufgebaut ist, wobei jeder Block eine Folge von N Transaktionen enthält. Blöcke können verschiedene Komponenten umfassen, wie z.B. in 11B dargestellt. Die Verknüpfung der Blöcke (in 11A durch Pfeile dargestellt) kann durch Hinzufügen eines Hash des Kopfes eines früheren Blocks in einen Blockkopf eines aktuellen Blocks erzeugt werden. Auf diese Weise können alle Transaktionen in der Blockchain 1122 sequenziert und kryptografisch miteinander verknüpft werden, um eine Manipulation der Blockchain-Daten zu verhindern, ohne die Hash-Verknüpfungen zu unterbrechen. Aufgrund der Verknüpfungen stellt der letzte Block in der Blockchain 1122 außerdem jede Transaktion, die vor ihm stattgefunden hat, dar. Die Blockchain 1122 kann in einem Peer-Dateisystem (lokaler oder angeschlossener Speicher) gespeichert werden, das eine Append-only-Blockchain-Arbeitslast unterstützt.
  • Der aktuelle Zustand der Blockchain 1122 und des Distributed Ledger 1120 kann in der Zustandsdatenbank 1124 gespeichert werden. In diesem Fall stellen die Daten des aktuellen Zustands die neuesten Werte für alle jemals im Chain-Transaktionsprotokoll der Blockchain 1122 enthaltenen Schlüssel dar. Chaincode-Aufrufe führen Transaktionen auf der Grundlage des aktuellen Zustands in der Zustandsdatenbank 1124 aus. Damit diese Chaincode-Interaktionen höchst effizient sind, können die aktuellen Werte aller Schlüssel in der Zustandsdatenbank 1124 gespeichert werden. Die Zustandsdatenbank 1124 kann eine indizierte Ansicht des Transaktionsprotokolls der Blockchain 1122 enthalten und kann daher jederzeit aus der Chain neu erzeugt werden. Die Zustandsdatenbank 1124 kann automatisch wiederhergestellt (oder bei Bedarf erzeugt) werden, wenn der Peer-Knoten gestartet wird und bevor Transaktionen angenommen werden.
  • Bestätigende Knoten empfangen Transaktionen von Clients und bestätigen die Transaktion auf der Grundlage simulierter Ergebnisse. Bestätigende Knoten enthalten Smart Contracts, die die Transaktionsvorschläge simulieren. Wenn ein bestätigender Knoten eine Transaktion bestätigt, erzeugt der bestätigende Knoten eine Transaktionsbestätigung, bei der es sich um eine signierte Antwort des bestätigenden Knotens an die Client-Anwendung handelt, die die Bestätigung der simulierten Transaktion anzeigt. Das Verfahren zum Bestätigen einer Transaktion hängt von einer Endorsement Policy ab, die im Chaincode festgelegt werden kann. Ein Beispiel für eine Endorsement Policy ist „die Mehrheit der bestätigenden Peers muss die Transaktion bestätigen“. Verschiedene Kanäle können unterschiedliche Endorsement Policys aufweisen. Bestätigte Transaktionen werden von der Client-Anwendung an den Sortierdienst 1110 weitergeleitet.
  • Der Sortierdienst 1110 lässt bestätigte Transaktionen zu, ordnet sie in einem Block an und übermittelt die Blöcke an die festschreibenden Peers. Beispielsweise kann der Sortierdienst 1110 einen neuen Block initiieren, wenn ein Schwellenwert an Transaktionen erreicht wurde, ein Zeitgeber abgelaufen ist oder eine andere Bedingung vorliegt. In dem Beispiel von 11A handelt es sich bei dem Blockchain-Knoten 1112 um einen festschreibenden Peer, der einen neuen Datenblock 1130 zum Speichern in der Blockchain 1122 empfangen hat. Der erste Block in der Blockchain kann als Genesis-Block bezeichnet werden, der Informationen über die Blockchain, ihre Mitglieder, die darin gespeicherten Daten usw. enthält.
  • Der Sortierdienst 1110 kann aus einer Gruppe von Sortierknoten zusammengesetzt sein. Der Sortierdienst 1110 kann in einigen Ausführungsformen keine Transaktionen und Smart Contracts verarbeiten und führt auch nicht das gemeinsam genutzte Ledger. Vielmehr kann der Sortierdienst 1110 in diesen Ausführungsformen die bestätigten Transaktionen zulassen und die Reihenfolge festlegen, in der diese Transaktionen im Distributed Ledger 1120 festgeschrieben werden. Die Architektur des Blockchain-Netzwerks kann so ausgelegt werden, dass die spezifische Implementierung des „Sortierens“ (z.B. Solo, Kafka, BFT usw.) zu einer integrierbaren Komponente wird.
  • Transaktionen können in einigen Ausführungsformen in einer konsistenten Reihenfolge in das Distributed Ledger 1120 geschrieben werden. Die Reihenfolge der Transaktionen kann in diesen Ausführungsformen festgelegt werden, um sicherzustellen, dass die Aktualisierungen der Zustandsdatenbank 1124 gültig sind, wenn sie im Netzwerk festgeschrieben werden. Im Gegensatz zu einem Blockchain-System für Kryptowährungen (z.B. Bitcoin usw.), bei dem das Sortieren durch das Lösen eines kryptografischen Rätsels oder durch Mining erfolgt, können die Parteien des Distributed Ledger 1120 in diesem Beispiel den Sortiermechanismus wählen, der am besten zu diesem Netzwerk passt.
  • Wenn der Sortierdienst 1110 in einigen Ausführungsformen einen neuen Datenblock 1130 initialisiert, kann der neue Datenblock 1130 an die festschreibenden Peers (z.B. die Blockchain-Knoten 1111, 1112 und 1113) übertragen werden. Daraufhin kann jeder festschreibende Peer die Transaktion im neuen Datenblock 1130 validieren, indem er sicherstellt, dass der Lese- und der Schreibsatz immer noch mit dem aktuellen World State in der Zustandsdatenbank 1124 übereinstimmen. Konkret heißt dies, dass der festschreibende Peer ermitteln kann, ob die gelesenen Daten, die vorhanden waren, als die Endorser die Transaktion simulierten, mit dem aktuellen World State in der Zustandsdatenbank 1124 identisch sind. Wenn der festschreibende Peer die Transaktion validiert, kann die Transaktion in die Blockchain 1122 im Distributed Ledger 1120 geschrieben werden, und die Zustandsdatenbank 1124 kann mit den Schreibdaten aus dem Lese-/Schreibsatz aktualisiert werden. Wenn eine Transaktion in einigen Ausführungsformen nicht erfolgreich ist (z.B. wenn der festschreibende Peer feststellt, dass der Lese-/Schreibsatz nicht mit dem aktuellen World State in der Zustandsdatenbank 1124 übereinstimmt), kann die in einem Block zusammengefasste Transaktion zwar immer noch in diesem Block enthalten sein, aber sie ist als ungültig gekennzeichnet, und die Zustandsdatenbank 1124 wird nicht aktualisiert.
  • Mit Bezug auf 11B kann in einigen Ausführungsformen ein neuer Datenblock 1130 (auch als Datenblock bezeichnet), der in der Blockchain 1122 des Distributed Ledger 1120 gespeichert wird, mehrere Datensegmente enthalten, z.B. einen Blockkopf 1140, Blockdaten 1150 und Block-Metadaten 1160. Es sei darauf hingewiesen, dass die verschiedenen dargestellten Blöcke und ihr Inhalt, z.B. der neue Datenblock 1130 und sein Inhalt, die in 11B gezeigt werden, lediglich Beispiele sind und den Anwendungsbereich der beispielhaften Ausführungsformen nicht einschränken sollen. Der neue Datenblock 1130 kann Transaktionsinformationen von N Transaktionen (z.B. 1, 10, 100, 200, 1.000, 2.000, 3.000 usw.) in den Blockdaten 1150 speichern. Der neue Datenblock 1130 kann auch eine Verknüpfung zu einem früheren Block (z.B. in der Blockchain 1122 in 11A) im Blockkopf 1140 enthalten. Der Blockkopf 1140 kann insbesondere einen Hash des Kopfes eines früheren Blocks enthalten. Der Blockkopf 1140 kann auch eine eindeutige Blocknummer, einen Hash der Blockdaten 1150 des neuen Datenblocks 1130 und Ähnliches umfassen. Die Blocknummer des neuen Datenblocks 1130 kann eindeutig sein und in verschiedenen Reihenfolgen zugewiesen werden, z.B. in einer inkrementellen/sequenziellen Reihenfolge, die bei null beginnt.
  • In den Blockdaten 1150 können Transaktionsinformationen jeder Transaktion gespeichert werden, die im neuen Datenblock 1130 aufgezeichnet werden. Die Transaktionsdaten können zum Beispiel enthalten: eine Art der Transaktion und/oder eine Version und/oder einen Zeitstempel und/oder eine Kanal-ID des Distributed Ledger 1120 und/oder eine Transaktions-ID und/oder eine Epoche und/oder die Sichtbarkeit von Nutzdaten und/oder einen Chaincode-Pfad (deploy tx) und/oder einen Chaincode-Namen und/oder eine Chaincode-Version und/oder eine Eingabe (Chaincode und Funktionen) und/oder eine Client-ID (Erzeuger-ID) wie einen öffentlichen Schlüssel und ein Zertifikat und/oder eine Signatur des Clients und/oder die Identitäten von Endorsers und/oder Endorser-Signaturen und/oder einen Vorschlags-Hash und/oder Chaincode-Ereignisse und/oder einen Antwortstatus und/oder einen Namensbereich und/oder einen Lesesatz (Liste der von der Transaktion gelesenen Schlüssel und Versionen usw.) und/oder einen Schreibsatz (Liste der Schlüssel und Werte usw.) und/oder einen Anfangsschlüssel, und/odereinen Endschlüssel und/oder eine Schlüsselliste, und/oder eine Zusammenfassung der Merkle-Baum-Abfrage und/oder Ähnliches. Die Transaktionsdaten können für jede der N Transaktionen gespeichert werden.
  • In einigen Ausführungsformen können in den Blockdaten 1150 auch neue Daten 1162 gespeichert werden, wodurch der hash-verknüpften Kette von Blöcken in der Blockchain 1122 zusätzliche Informationen hinzugefügt werden. Die zusätzlichen Informationen können einen oder mehrere der hier beschriebenen oder dargestellten Schritte, Merkmale, Prozesse und/oder Maßnahmen umfassen. Entsprechend können die neuen Daten 1162 in einem unveränderlichen Protokoll von Blöcken im Distributed Ledger 1120 gespeichert werden. Einige der Vorteile des Speicherns dieser neuen Daten 1162 werden in den verschiedenen hier offenbarten und dargestellten Ausführungsformen deutlich. In 11B sind die neuen Daten 1162 zwar in den Blockdaten 1150 dargestellt, sie könnten sich in einigen Ausführungsformen aber auch im Blockkopf 1140 oder in den Block-Metadaten 1160 befinden. Die neuen Daten 1162 können auch einen Dokumentverbundschlüssel enthalten, der für ein Verknüpfen der Dokumente in einer Organisation verwendet wird.
  • In den Block-Metadaten 1160 können mehrere Felder mit Metadaten gespeichert werden (z.B. als Byte-Anordnung usw.). Die Metadatenfelder können eine Signatur beim Erzeugen eines Blocks, einen Verweis auf einen letzten Konfigurationsblock, ein Transaktionsfilter, das gültige und ungültige Transaktionen im Block identifiziert, den letzten verbliebenen Offset eines Sortierdienstes, der den Block sortiert hat, und Ähnliches umfassen. Die Signatur, der letzte Konfigurationsblock und die Metadaten des Sortierers können vom Sortierdienst 1110 hinzugefügt werden. In der Zwischenzeit kann ein Festschreibender (Committer) des Blocks (z.B. der Blockchain-Knoten 1112) auf der Grundlage einer Endorsement Policy, der Überprüfung von Lese-/Schreibsätzen usw. Angaben zur Gültigkeit/Ungültigkeit hinzufügen. Das Transaktionsfilter kann eine Byte-Anordnung mit einer Größe umfassen, die der Anzahl von Transaktionen in den Blockdaten 1150 entspricht, sowie einen Validierungscode, der kennzeichnet, ob eine Transaktion gültig oder ungültig war.
  • 11C veranschaulicht gemäß einigen Ausführungsformen eine Ausführungsform einer Blockchain 1170 für digitalen Inhalt. Der digitale Inhalt kann eine oder mehrere Dateien und zugehörige Informationen enthalten. Die Dateien können Transaktionsdaten, Medien, Bilder, Video, Audio, Text, Links, Grafiken, Animationen, Webseiten, Dokumente oder andere Formen mit digitalem Inhalt umfassen. Die unveränderlichen Append-only-Aspekte einiger Ausführungsformen der Blockchain können wünschenswert sein, um als Schutz für die Integrität, Gültigkeit und Echtheit des digitalen Inhalts zu dienen, sodass sie sich für Gerichtsverfahren eignen, in denen Zulässigkeitsregeln angewandt werden, oder für andere Situationen, in denen Beweise in Betracht gezogen werden oder in denen die Darstellung und Verwendung digitaler Informationen anderweitig von Interesse sind. In diesem Fall kann der digitale Inhalt als digitaler Nachweis bezeichnet werden.
  • Die Blockchain kann in diesen Ausführungsformen auf verschiedene Weise gebildet werden. In einer Ausführungsform kann der digitale Inhalt in der Blockchain enthalten sein, und die Blockchain selbst kann darauf zugreifen. Beispielsweise kann jeder Block der Blockchain einen Hash-Wert von Verweisinformationen (z.B. Kopf, Wert usw.) zusammen mit dem zugehörigen digitalen Inhalt speichern. Der Hash-Wert und der zugehörige digitale Inhalt können dann gemeinsam verschlüsselt werden. Auf den digitalen Inhalt jedes Blocks kann somit zugegriffen werden, indem jeder Block in der Blockchain entschlüsselt wird, und der Hash-Wert jedes Blocks kann als Grundlage für einen Verweis auf einen vorherigen Block verwendet werden. Dies lässt sich wie folgt darstellen:
    Block 1 Block 2 ....... Block N
    Hash-Wert 1 Hash-Wert 2 Hash-Wert N
    Digitaler Inhalt 1 Digitaler Inhalt 2 Digitaler Inhalt N
  • In einer Ausführungsform kann der digitale Inhalt nicht in der Blockchain enthalten sein. So kann die Blockchain beispielsweise die verschlüsselten Hashes des Inhalts jedes Blocks ohne den digitalen Inhalt speichern. Der digitale Inhalt kann in Verbindung mit dem Hash-Wert der Originaldatei in einem anderen Speicherbereich oder an einer anderen Speicheradresse gespeichert werden. Bei dem anderen Speicherbereich kann es sich um dieselbe Speichereinheit handeln, die auch zum Speichern der Blockchain verwendet wird, oder um einen anderen Speicherbereich oder auch um eine gesonderte relationale Datenbank. Auf den digitalen Inhalt jedes Blocks kann durch Abrufen oder Abfragen des Hash-Wertes eines relevanten Blocks und anschließendes Suchen dieses Hash-Wertes im Speicherbereich, der in Übereinstimmung mit dem tatsächlichen digitalen Inhalt gespeichert ist, verwiesen oder zugegriffen werden. Diese Operation kann z.B. von einem Datenbank-Gatekeeper durchgeführt werden. Dies lässt sich wie folgt darstellen:
    Blockchain Speicherbereich
    Block 1 Hash-Wert Block 1 Hash-Wert ... Inhalt
    . .
    . .
    . .
    Block N Hash-Wert Block N Hash-Wert ... Inhalt
  • In der beispielhaften Ausführungsform von 7C umfasst die Blockchain 1170 eine Anzahl von Blöcken 11781, 11782, ... 1178N, die in einer geordneten Folge kryptografisch verknüpft sind, wobei N ≥ 1 ist. Bei der Verschlüsselung, die verwendet wird, um die Blöcke 11781, 11782, ... 1178N zu verknüpfen, kann es sich um eine beliebige Anzahl von verschlüsselten oder unverschlüsselten Hash-Funktionen handeln. In einer Ausführungsform werden die Blöcke 11781, 11782, ... 1178N einer Hash-Funktion unterzogen, die aus Eingaben, die auf den Informationen in den Blöcken beruhen, n-bit alphanumerische Ausgaben erzeugt (wobei n 256 oder eine andere Zahl ist). Zu Beispielen für eine solche Hash-Funktion gehören, ohne auf diese beschränkt zu sein: ein Algorithmus vom Typ SHA (SHA steht für Secured Hash Algorithm, sicherer Hash-Algorithmus), ein Merkle-Damgard-Algorithmus, ein HAIFA-Algorithmus, ein Merkle-Baum-Algorithmus, ein Nonce-gestützter Algorithmus und ein nichtkollisionsresistenter PRF-Algorithmus. In einer anderen Ausführungsform können die Blöcke 11781, 11782, ..., 1178N durch eine andere Funktion als eine Hash-Funktion kryptografisch verknüpft werden. Zur Veranschaulichung folgt eine Beschreibung mit Verweis auf eine Hash-Funktion, z.B. SHA-2.
  • Jeder der Blöcke 11781, 11782, ..., 1178N in der Blockchain kann einen Kopf, eine Version der Datei und einen Wert umfassen. Der Kopf und der Wert können für jeden Block unterschiedlich sein, was auf das Hashing in der Blockchain zurückzuführen ist. In einer Ausführungsform kann der Wert im Kopf enthalten sein. Wie im Folgenden ausführlicher beschrieben, kann die Version der Datei die Originaldatei oder eine andere Version der Originaldatei sein.
  • Der erste Block 11781 in der Blockchain wird als Genesis-Block bezeichnet und kann den Kopf 11721, die Originaldatei 11741 und einen Anfangswert 11761 umfassen. Das Hashing-Schema, das für den Genesis-Block und auch für alle folgenden Blöcke verwendet wird, kann unterschiedlich sein. Zum Beispiel können alle Informationen im ersten Block 11781 zusammen und auf einmal gehasht werden, oder jede Information oder ein Teil der Informationen im ersten Block 11781 kann separat gehasht werden, und dann kann ein Hash der separat gehashten Teile durchgeführt werden.
  • Der Kopf 11721 kann einen oder mehrere Anfangsparameter umfassen, die beispielsweise eine Versionsnummer, einen Zeitstempel, eine Nonce, Stamminformationen, einen Schwierigkeitsgrad, ein Konsensprotokoll, eine Dauer, ein Medienformat, eine Quelle, beschreibende Schlüsselwörter und/oder andere Informationen umfassen können, die der Originaldatei 11741 und/oder der Blockchain zugehörig sind. Der Kopf 11721 kann automatisch (z.B. durch eine Software zur Blockchain-Netzwerkverwaltung) oder manuell durch einen Blockchain-Teilnehmer erzeugt werden. Im Gegensatz zum Kopf in den anderen Blöcken 11782 bis 1178N in der Blockchain kann der Kopf 11721 im Genesis-Block nicht auf einen vorherigen Block verweisen, da es keinen vorherigen Block gibt.
  • Bei der Originaldatei 11741 im Genesis-Block kann es sich beispielsweise um Daten handeln, die von einer Einheit mit oder ohne Verarbeitung vor ihrer Aufnahme in die Blockchain erfasst wurden. Die Originaldatei 11741 kann über die Schnittstelle des Systems von der Einheit, der Medienquelle oder dem Knoten empfangen werden. Der Originaldatei 11741 können Metadaten zugehörig sein, die z.B. von einem Benutzer, der Einheit und/oder dem Systemprozessor entweder manuell oder automatisch erzeugt werden können. Die Metadaten können im ersten Block 11781 enthalten sein, der der Originaldatei 11741 zugehörig ist.
  • Der Wert 11761 im Genesis-Block kann ein Anfangswert sein, der auf der Grundlage eines oder mehrerer eindeutiger Attribute der Originaldatei 11741 erzeugt wird. In einer Ausführungsform können das eine oder die mehreren eindeutigen Attribute den Hash-Wert für die Originaldatei 11741, Metadaten für die Originaldatei 11741 und andere der Datei zugehörige Informationen umfassen. In einer Implementierung kann der Anfangswert 11761 auf den folgenden eindeutigen Attributen beruhen:
    1. 1) SHA-2 berechneter Hash-Wert für die Originaldatei
    2. 2) ID der ursprünglichen Einheit
    3. 3) Anfangszeitstempel für die Originaldatei
    4. 4) Anfänglicher Speicherort der Originaldatei
    5. 5) Blockchain-Netzwerk-Mitglieder-ID für Software zur aktuellen Kontrolle der Originaldatei und der zugehörigen Metadaten
  • Die anderen Blöcke 11782 bis 1178N in der Blockchain verfügen ebenfalls über Köpfe, Dateien und Werte. Im Gegensatz zum Kopf 11721 des ersten Blocks umfasst jedoch jeder der Köpfe 11722 bis 1172N in den anderen Blöcken den Hash-Wert eines unmittelbar vorhergehenden Blocks. Der Hash-Wert des unmittelbar vorhergehenden Blocks kann lediglich der Hash des Kopfes des vorherigen Blocks oder der Hash-Wert des gesamten vorherigen Blocks sein. Indem der Hash-Wert eines vorhergehenden Blocks in jeden der verbleibenden Blöcke integriert wird, kann eine Rückverfolgung vom N-ten Block zurück zum Genesis-Block (und der zugehörigen Originaldatei) Block für Block durchgeführt werden, wie durch die Pfeile 1180 angezeigt, um eine überprüfbare und unveränderliche Chain-of-Custody herzustellen.
  • Jeder der Köpfe 11722 bis 1172N in den anderen Blöcken kann auch andere Informationen enthalten, z.B. Versionsnummer, Zeitstempel, Nonce, Stamminformationen, Schwierigkeitsgrad, Konsensprotokoll und/oder andere Parameter oder Informationen, die den entsprechenden Dateien und/oder der Blockchain im Allgemeinen zugehörig sind.
  • Die Dateien 11742 bis 1174N in den anderen Blöcken können der Originaldatei entsprechen, oder es kann sich um eine geänderte Version der Originaldatei im Genesis-Block handeln, beispielsweise je nach Art der durchgeführten Verarbeitung. Die Art der durchgeführten Verarbeitung kann sich von Block zu Block unterscheiden. Das Verarbeiten kann z.B. jede Änderung einer Datei in einem vorhergehenden Block umfassen, unter anderem Redigieren von Informationen oder sonstiges Ändern des Inhalts, Entfernen von Informationen oder Hinzufügen oder Anhängen von Informationen in den Dateien.
  • Zusätzlich oder alternativ kann das Verarbeiten lediglich ein Kopieren der Datei aus einem vorhergehenden Block, Ändern eines Speicherortes der Datei, Analysieren der Datei aus einem oder mehreren vorhergehenden Blöcken, Verlagern der Datei von einem Speicherort zu einem anderen oder Durchführen von Maßnahmen in Bezug auf die Datei der Blockchain und/oder ihrer zugehörigen Metadaten umfassen. Ein Verarbeiten, das Analysieren einer Datei umfasst, kann zum Beispiel Anhängen, Einbeziehen oder anderweitiges Zuordnen verschiedener analytischer, statistischer oder anderer Informationen umfassen, die der Datei zugehörig sind.
  • Die Werte in jedem der anderen Blöcke 11762 bis 1176N sind eindeutige Werte, und aufgrund der durchgeführten Verarbeitung unterscheiden sie sich alle. So entspricht beispielsweise der Wert in einem beliebigen Block einer aktualisierten Version des Wertes im vorherigen Block. Die Aktualisierung spiegelt sich im Hash des Blocks wider, dem der Wert zugewiesen ist. Die Werte der Blöcke stellen somit einen Hinweis darauf bereit, welche Verarbeitung in den Blöcken durchgeführt wurde, und ermöglichen auch eine Rückverfolgung durch die Blockchain bis zur Originaldatei. Dieses Verfolgen bestätigt die Chain-of-Custody der Datei über die gesamte Blockchain.
  • Nehmen wir zum Beispiel den Fall, dass Teile der Datei in einem vorherigen Block redigiert, ausgeblendet oder verpixelt werden, um die Identität einer in der Datei gezeigten Person zu schützen. In diesem Fall umfasst der Block mit der redigierten Datei zugehörige Metadaten, z.B. wie das Redigieren durchgeführt wurde, wer das Redigieren durchgeführt hat, Zeitstempel, die angeben, wann die Redigierung(en) vorgenommen wurde(n), usw. Die Metadaten können gehasht werden, um den Wert zu bilden. Da sich die Metadaten des Blocks von den Informationen unterscheiden, die zum Bilden des Wertes im vorherigen Block gehasht wurden, unterscheiden sich die Werte voneinander und können beim Entschlüsseln wiederhergestellt werden.
  • In einer Ausführungsform kann der Wert eines vorherigen Blocks aktualisiert werden (z.B. kann ein neuer Hash-Wert berechnet werden), um den Wert eines aktuellen Blocks zu bilden, wenn einer oder mehrere der folgenden Fälle eintreten. In dieser beispielhaften Ausführungsform kann der neue Hash-Wert durch Hashing aller oder eines Teils der unten aufgeführten Informationen berechnet werden.
    1. a) Neuer SHA-2 berechneter Hash-Wert, wenn die Datei in irgendeiner Weise verarbeitet wurde (z.B. wenn die Datei redigiert, kopiert, geändert oder auf sie zugegriffen wurde oder eine andere Maßnahme durchgeführt wurde)
    2. b) Neuer Speicherort für die Datei
    3. c) Neue Metadaten identifiziert, die der Datei zugehörig sind
    4. d) Übertragung des Zugriffs auf oder der Kontrolle über die Datei von einem Blockchain-Teilnehmer auf einen anderen Blockchain-Teilnehmer
  • 11D veranschaulicht gemäß einigen Ausführungsformen eine Ausführungsform eines Blocks, die die Struktur der Blöcke in der Blockchain 1190 darstellen kann. Der Block, Blocki, kann einen Kopf 1172i, eine Datei 1174i und einen Wert 1176i umfassen.
  • Der Kopf 772i kann einen Hash-Wert eines vorherigen Blocks, Blocki-1, und zusätzliche Verweisinformationen umfassen, bei denen es sich z.B. um beliebige hier beschriebene Arten von Informationen (z.B. Kopf-Informationen mit Verweisen, Merkmalen, Parametern usw.) handeln kann. In einigen Ausführungsformen können alle Blöcke auf den Hash eines vorherigen Blocks verweisen, mit Ausnahme des Genesis-Blocks in einigen Ausführungsformen. Der Hash-Wert des vorherigen Blocks kann nur ein Hash des Kopfes im vorherigen Block sein oder ein Hash aller oder eines Teils der Informationen im vorherigen Block, einschließlich der Datei und der Metadaten.
  • Die Datei 1174i kann eine Mehrzahl von Daten, z.B. Daten 1, Daten 2, ..., Daten N in Folge umfassen. Die Daten sind mit den Metadaten 1, Metadaten 2, ..., Metadaten N versehen, die den Inhalt und/oder die den Daten zugehörigen Merkmale beschreiben. Die Metadaten für die einzelnen Daten können beispielsweise Informationen zur Angabe eines Zeitstempels für die Daten, zur Verarbeitung der Daten, Schlüsselwörter zur Angabe der in den Daten abgebildeten Personen oder anderer Inhalte und/oder andere Merkmale umfassen, die hilfreich sein können, um die Gültigkeit und den Inhalt der Datei insgesamt und insbesondere ihre Verwendung als digitalen Nachweis festzustellen, wie beispielsweise im Zusammenhang mit einer unten erörterten Ausführungsform beschrieben. Zusätzlich zu den Metadaten können alle Daten mit einem Verweis REF1, REF2, ..., REFN auf frühere Daten versehen werden, um Manipulationen, Lücken in der Datei und sequenzielle Verweise in der Datei zu vermeiden.
  • Sobald die Metadaten den Daten zugewiesen sind (z.B. durch einen Smart Contract), können die Metadaten in einigen Ausführungsformen nicht mehr geändert werden, ohne dass sich der Hash ändert, der zum Ungültigmachen leicht identifiziert werden kann. Die Metadaten erzeugen in diesen Ausführungsformen somit ein Datenprotokoll mit Informationen, auf die Teilnehmer der Blockchain zur Verwendung zugreifen können.
  • Der Wert 1176i kann in einigen Ausführungsformen ein Hash-Wert oder ein anderer Wert sein, der auf der Grundlage einer der zuvor beschriebenen Arten von Informationen berechnet wird. Beispielsweise kann für jeden gegebenen Block Blocki der Wert für diesen Block aktualisiert werden, um das für diesen Block durchgeführte Verarbeiten widerzuspiegeln, z.B. neuer Hash-Wert, neuer Speicherort, neue Metadaten für die zugehörige Datei, Übertragen der Kontrolle oder des Zugriffs, Kennung oder andere hinzuzufügende Maßnahme oder Informationen. Zwar ist der Wert in jedem Block getrennt von den Metadaten für die Daten der Datei und des Kopfes dargestellt, doch kann der Wert in einer anderen Ausführungsform ganz oder teilweise auf diesen Metadaten beruhen.
  • Sobald die Blockchain 1170 gebildet ist, kann die unveränderliche Chain-of-Custody in einigen Ausführungsformen zu jedem beliebigen Zeitpunkt für die Datei abgerufen werden, indem die Blockchain nach der Transaktionshistorie der Werte in den Blöcken abgefragt wird. Diese Abfrage- oder Verfolgungsprozedur kann mit einem Entschlüsseln des Wertes des Blocks beginnen, der am aktuellsten erfasst ist (z.B. der letzte (N-te) Block), und dann mit dem Entschlüsseln des Wertes der anderen Blöcke fortfahren, bis der Genesis-Block erreicht und die Originaldatei wiederhergestellt ist. Das Entschlüsseln kann auch Entschlüsseln der Köpfe und Dateien und zugehöriger Metadaten in jedem Block umfassen.
  • Das Entschlüsseln kann auf der Grundlage der Art des Verschlüsselns, die in jedem Block verwendet wurde, durchgeführt werden. Dies kann Verwenden von privaten Schlüsseln, öffentlichen Schlüsseln oder von Paaren aus öffentlichen und privaten Schlüsseln umfassen. Bei der asymmetrischen Verschlüsselung können Blockchain-Teilnehmer oder ein Prozessor im Netzwerk beispielsweise ein Paar aus öffentlichem und privatem Schlüssel mithilfe eines vorgegebenen Algorithmus erzeugen. Der öffentliche und der private Schlüssel können durch eine mathematische Beziehung miteinander verbunden sein. Der öffentliche Schlüssel kann öffentlich verteilt werden und als Adresse dienen, um Nachrichten von anderen Benutzern zu empfangen, z.B. eine IP-Adresse oder eine Privatadresse. Der private Schlüssel kann geheim gehalten und zum digitalen Signieren von Nachrichten verwendet werden, die an andere Blockchain-Teilnehmer gesendet werden. Die Signatur kann ihrerseits in der Nachricht enthalten sein, damit der Empfänger sie mit dem öffentlichen Schlüssel des Senders überprüfen kann. Auf diese Weise kann der Empfänger sicher sein, dass nur der Sender diese Nachricht gesendet haben kann.
  • In einigen Ausführungsformen kann das Erzeugen eines Schlüsselpaares vergleichbar mit dem Erzeugen eines Kontos in der Blockchain sein, ohne dass man sich jedoch irgendwo registrieren muss. In diesen Ausführungsformen kann jede Transaktion, die in der Blockchain ausgeführt wird, vom Sender mit seinem privaten Schlüssel digital signiert werden. Diese Signatur kann dazu beitragen, sicherstellen, dass nur der Inhaber des Kontos die Datei der Blockchain verfolgen und bearbeiten kann (sofern dies im Rahmen einer durch einen Smart Contract festgelegten Genehmigung liegt).
  • Die 12A und 12B veranschaulichen weitere Beispiele für Anwendungsfälle einer Blockchain, die hier einbezogen und verwendet werden können. 12A veranschaulicht insbesondere ein Beispiel 1200 für eine Blockchain 1210, in der Daten zum maschinellen Lernen (künstliche Intelligenz) gespeichert werden. Maschinelles Lernen stützt sich in der Regel auf beträchtliche Mengen historischer Daten (oder Trainingsdaten), um Prognosemodelle für genaue Vorhersagen zu neuen Daten zu erstellen. Software für maschinelles Lernen (z.B. neuronale Netzwerke usw.) kann oft Millionen von Datensätzen durchforsten, um nichtintuitive Muster zu erkennen.
  • In dem Beispiel von 12A erstellt und implementiert eine Host-Plattform 1220 ein Modell für maschinelles Lernen zum vorausschauenden Überwachen von Assets 1230. Bei der Host-Plattform 1220 kann es sich in diesem Fall um eine Cloud-Plattform, einen Industrieserver, einen Webserver, einen Personal Computer, eine Benutzereinheit oder Ähnliches handeln. Bei den Assets 1230 kann es sich um jede Art von Asset (z.B. Maschine oder Ausrüstung) handeln, beispielsweise Flugzeuge, Lokomotiven, Turbinen, medizinische Anlagen und Geräte, Öl- und Gasanlagen, Boote, Schiffe, Fahrzeuge und Ähnliches. Ein weiteres Beispiel für die Assets 1230 sind immaterielle Assets wie z.B. Aktien, Währungen, digitale Zahlungsmittel, Versicherungen oder Ähnliches.
  • Die Blockchain 1210 kann verwendet werden, um sowohl einen Trainingsprozess 1202 des Modells für maschinelles Lernen als auch einen Vorhersageprozess 1204 auf der Grundlage eines trainierten Modells für maschinelles Lernen erheblich zu verbessern. Anstatt dass ein Datenwissenschaftler/-ingenieur oder ein anderer Benutzer die Daten sammeln muss, können die historischen Daten in Schritt 1202 beispielsweise von den Assets 1230 selbst (oder einer zwischengeschalteten Einheit, nicht dargestellt) in der Blockchain 1210 gespeichert werden. Dies kann die Zeit, die die Host-Plattform 1220 für das Sammeln von Daten beim Trainieren von Vorhersagemodellen benötigt, erheblich verringern. Mit Smart Contracts können Daten beispielsweise direkt und zuverlässig von ihrem Ursprungsort in die Blockchain 1210 übertragen werden. Durch Verwenden der Blockchain 1210, um die Sicherheit von und das Eigentum an den gesammelten Daten zu gewährleisten, können Smart Contracts die Daten von den Assets direkt an die Personen senden, die die Daten für den Aufbau eines Modells für maschinelles Lernen verwenden. Dadurch ist es möglich, dass die Assets 1230 gemeinsam Daten nutzen.
  • Die gesammelten Daten können auf der Grundlage eines Konsensmechanismus in der Blockchain 1210 gespeichert werden. Der Konsensmechanismus kann (genehmigungspflichtige Knoten) einbeziehen, um sicherzustellen, dass die aufgezeichneten Daten überprüft und korrekt sind. Die aufgezeichneten Daten können mit einem Zeitstempel versehen, kryptografisch signiert und unveränderlich sein. Somit sind sie überprüfbar, transparent und sicher. Durch das Hinzufügen von loT-Einheiten, die direkt in die Blockchain schreiben, können in bestimmten Fällen (z.B. Lieferkette, Gesundheitswesen, Logistik usw.) sowohl die Häufigkeit als auch die Genauigkeit der aufgezeichneten Daten erhöht werden.
  • Darüber hinaus kann das Training des Modells für maschinelles Lernen mit den gesammelten Daten mehrere Durchgänge des Verfeinerns und Testens durch die Host-Plattform 1220 erfordern. Jeder Durchgang kann auf zusätzlichen Daten oder Daten beruhen, bei denen man bisher nicht davon ausging, dass sie das Wissen des Modells für maschinelles Lernen erweitern könnten. In Schritt 1202 können die verschiedenen Trainings- und Testschritte (und die zugehörigen Daten) von der Host-Plattform 1220 in der Blockchain 1210 gespeichert werden. Jede Verfeinerung des Modells für maschinelles Lernen (z.B. Änderungen bei den Variablen, Gewichten usw.) kann in der Blockchain 1210 gespeichert werden. Dies stellt einen überprüfbaren Nachweis dafür bereit, wie das Modell trainiert wurde und welche Daten zum Trainieren des Modells verwendet wurden. Wenn die Host-Plattform 1220 ein fertig trainiertes Modell erreicht hat, kann das resultierende Modell in der Blockchain 1210 gespeichert werden.
  • Nachdem das Modell trainiert wurde, kann es in einer Live-Umgebung implementiert werden, wo es auf der Grundlage der Ausführung des fertig trainierten Modells für maschinelles Lernen Vorhersagen/Entscheidungen treffen kann. In Schritt 1204 kann das Modell für maschinelles Lernen beispielsweise für die zustandsorientierte Instandhaltung (condition-based maintenance - CBM) eines Assets, z.B. eines Flugzeugs, einer Windturbine, einem Gerät im Gesundheitswesen und Ähnliches, verwendet werden. In diesem Beispiel können die vom Asset 1230 zurückgemeldeten Daten in das Modell für maschinelles Lernen eingegeben und für die Vorhersage von Ereignissen wie z.B. Ausfällen, Fehlercodes usw. verwendet werden. Festlegungen, die durch das Ausführen des Modells für maschinelles Lernen in der Host-Plattform 1220 getroffen werden, können in der Blockchain 1210 gespeichert werden, um einen prüfbaren/überprüfbaren Nachweis bereitzustellen. Bei einem nichteinschränkenden Beispiel kann das Modell für maschinelles Lernen einen zukünftigen Ausfall/Fehler eines Teils des Assets 1230 vorhersagen und eine Warnung oder eine Benachrichtigung zum Austauschen des Teils erzeugen. Die Daten, die dieser Entscheidung zugrunde liegen, können von der Host-Plattform 1220 in der Blockchain 1210 gespeichert werden. In einer Ausführungsform können die hier beschriebenen und/oder abgebildeten Funktionen und/oder Maßnahmen in der Blockchain 1210 oder in Bezug auf diese durchgeführt werden.
  • Neue Transaktionen für eine Blockchain können in einem neuen Block zusammengefasst und zu einem bestehenden Hash-Wert hinzugefügt werden. Dieser kann dann verschlüsselt werden, um einen neuen Hash für den neuen Block zu erzeugen. Dieser kann zu der nächsten Liste von Transaktionen hinzugefügt werden, wenn diese verschlüsselt sind, usw. Das Ergebnis ist eine Kette von Blöcken, von denen jeder die Hash-Werte aller vorhergehenden Blöcke enthält. Computer, die diese Blöcke speichern, vergleichen regelmäßig ihre Hash-Werte, um sicherzustellen, dass sie alle übereinstimmen. Stellt einer der Computer einen Fehler fest, verwirft er die Datensätze, die das Problem verursachen. Dieser Ansatz ist gut geeignet, um die Manipulationssicherheit der Blockchain zu gewährleisten, aber er ist nicht perfekt.
  • Eine Möglichkeit, wie ein unehrlicher Benutzer dieses System umgehen kann, besteht darin, dass dieser die Liste der Transaktionen zu seinen Gunsten verändert, jedoch so, dass der Hash unverändert bleibt. Dies kann durch eine Brute-Force-Methode geschehen, d.h. durch Ändern eines Datensatzes, Verschlüsseln des Ergebnisses und Prüfen, ob der Hash-Wert derselbe ist. Und wenn dies nicht der Fall ist, wird dies wieder und wieder versucht, bis ein übereinstimmender Hash gefunden wird. Die Sicherheit von Blockchains beruht auf der Überzeugung, dass gewöhnliche Computer diese Art von Brute-Force-Angriffen nur in Zeiträumen durchführen können, die völlig utopisch sind, wie etwa das Alter des Universums. Im Gegensatz dazu sind Quantencomputer bei einigen Arten von Problemen viel schneller (tausende Male schneller) und stellen daher eine viel größere Gefahr dar.
  • 12B zeigt ein Beispiel 1250 für eine quantensichere Blockchain 1252, die eine Quantenschlüsselverteilung (quantum key distribution - QKD) zum Schutz vor einem Quantencomputerangriff implementiert. In diesem Beispiel können die Benutzer der Blockchain die Identität der anderen Benutzer mit QKD überprüfen. Dabei können Informationen mithilfe von Quantenteilchen wie Photonen übertragen werden, die von einem Abhörer nicht kopiert werden können, ohne sie zu zerstören. Auf diese Weise können sich ein Sender und ein Empfänger in der Blockchain der Identität des jeweils anderen sicher sein.
  • In dem Beispiel von 12B gibt es die vier Benutzer 1254, 1256, 1258 und 1260. Jedes Benutzerpaar kann einen geheimen Schlüssel 1262 (d.h. eine QKD) untereinander nutzen. Da es in diesem Beispiel vier Knoten gibt, sind sechs Knotenpaare vorhanden, und daher werden sechs verschiedene geheime Schlüssel 1262 verwendet, darunter QKDAB, QKDAC, QKDAD, QKDBC, QKDBD und QKDCD. Jedes Paar kann eine QKD erzeugen, indem es Informationen mithilfe von Quantenteilchen wie Photonen überträgt, die von einem Abhörer nicht kopiert werden können, ohne sie zu zerstören. Auf diese Weise kann sich ein Benutzerpaar der Identität des jeweils anderen sicher sein.
  • Die Funktion der Blockchain 1252 kann auf den beiden Verfahren (i) Erzeugen von Transaktionen und (ii) Bilden von Blöcken beruhen, die die neuen Transaktionen zusammenfassen. Neue Transaktionen können ähnlich wie in einem herkömmlichen Blockchain-Netzwerk erzeugt werden. Jede Transaktion kann Informationen über einen Sender, einen Empfänger, einen Erzeugungszeitpunkt, einen zu überweisenden Betrag (oder Wert), eine Liste von Verweistransaktionen, die belegen, dass der Absender über die nötigen Mittel für die Operation verfügt, und Ähnliches enthalten. Dieser Transaktionsdatensatz wird dann an alle anderen Knoten gesendet, wo er in einen Pool von unbestätigten Transaktionen aufgenommen wird. Hier können zwei Parteien (d.h. ein Paar der Benutzer 1254 bis 1260) die Transaktion durch Bereitstellen ihres gemeinsam genutzten geheimen Schlüssels 1262 (QKD) authentifizieren. Diese Quantensignatur kann an jede Transaktion angehängt werden, wodurch sie schwer zu fälschen ist. Jeder Knoten prüft seine Einträge anhand einer lokalen Kopie der Blockchain 1252, um zu überprüfen, ob jede Transaktion über ausreichende Mittel verfügt. Die Transaktionen sind jedoch noch nicht bestätigt.
  • Anstatt einen herkömmlichen Mining-Prozess bei den Blöcken durchzuführen, können die Blöcke dezentral mithilfe eines Übertragungsprotokolls erzeugt werden. Nach einer vorher festgelegten Zeitspanne (z.B. Sekunden, Minuten, Stunden usw.) kann das Netzwerk das Übertragungsprotokoll auf jede unbestätigte Transaktion anwenden, um so eine byzantinische Einigung (Konsens) über eine korrekte Version der Transaktion zu erzielen. So kann jeder Knoten beispielsweise einen privaten Wert (Transaktionsdaten des jeweiligen Knotens) besitzen. In einem ersten Durchgang übermitteln die Knoten sich gegenseitig ihre privaten Werte. In den folgenden Durchgängen übertragen die Knoten die Informationen, die sie im vorherigen Durchgang von anderen Knoten empfangen haben. In diesem Fall sind ehrliche Knoten in der Lage, einen kompletten Satz von Transaktionen in einem neuen Block zu erzeugen. Dieser neue Block kann der Blockchain 1252 hinzugefügt werden. In einer Ausführungsform können die hier beschriebenen und/oder abgebildeten Funktionen und/oder Maßnahmen in der Blockchain 1252 oder in Bezug auf diese durchgeführt werden.
  • Computerprogrammprodukt
  • Bei der vorliegenden Erfindung 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 Erfindung 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 Erfindung 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 Erfindung durchzuführen.
  • Aspekte der vorliegenden Erfindung sind hier unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder bzw. Schaltbilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder bzw. Schaltbilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern bzw. Schaltbildern 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 bzw. Schaltbilder 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 Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
  • Die Ablaufpläne und die Blockschaubilder bzw. Schaltbilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern bzw. Schaltbildern 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 bzw. Schaltbilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern bzw. Schaltbildern 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.
  • Allgemeines
  • Aspekte der vorliegenden Erfindung wurden hier unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder bzw. Schaltbilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern bzw. Schaltbildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können. Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen darüber hinaus die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern bzw. Schaltbildern 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 im Wesentlichen gleichzeitig 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 bzw. Schaltbilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern bzw. Schaltbildern 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.
  • Eine in dieser Beschreibung verwendete bestimmte Programmnomenklatur wurde nur aus Gründen der Zweckmäßigkeit verwendet, daher sollte die Erfindung nicht darauf beschränkt sein, nur in einer bestimmten Anwendung verwendet zu werden, die durch diese Nomenklatur bezeichnet und/oder impliziert wird. Die Routinen, die zum Implementieren der Ausführungsformen der Erfindung ausgeführt werden, unabhängig davon, ob sie als Teil eines Betriebssystems oder einer spezifischen Anwendung, Komponente, eines Programms, Moduls, Objekts oder einer Anweisungssequenz implementiert sind, könnten beispielsweise als „Programm“, „Anweisung“, „Server“ oder andere sinnvolle Nomenklatur bezeichnet werden. In derTat können auch andere Hardware- und/oder Software-Umgebungen verwendet werden, ohne vom Anwendungsbereich der Erfindung abzuweichen.
  • Daher sollen die hier beschriebenen Ausführungsformen in jeder Hinsicht als veranschaulichend und nichteinschränkend betrachtet werden und zum Festlegen des Anwendungsbereichs der Erfindung auf die beigefügten Ansprüche Bezug nehmen.

Claims (20)

  1. Durch einen Computer implementiertes Verfahren zum Herstellen eines Konsenses in einem Blockchain-Netzwerk, wobei das Verfahren umfasst: Bereitstellen eines ersten Gesamtsortierdienst(TOS)-Gateways für eine Organisation in einem Blockchain-Netzwerk, wobei das TOS-Gateway über einen Lese-/ Schreibzugriff auf eine gemeinsam genutzte Nachrichtenwarteschlange verfügt, die jedem anderen TOS-Gateway in dem Blockchain-Netzwerk Nachrichten zur Verfügung stellt; Erzeugen eines symmetrischen Schlüssels am ersten TOS-Gateway; Aufteilen des symmetrischen Schlüssels, um eine Mehrzahl von Schlüsselanteilen zu erzeugen; und Verteilen von mindestens einem Schlüsselanteil der Mehrzahl von Schlüsselanteilen an ein zweites TOS-Gateway im Blockchain-Netzwerk.
  2. Durch einen Computer implementiertes Verfahren nach Anspruch 1, wobei der symmetrische Schlüssel nur einer Mehrzahl von TOS-Gateways im Blockchain-Netzwerk bekannt ist.
  3. Durch einen Computer implementiertes Verfahren nach Anspruch 1, das weiterhin umfasst: Speichern von mindestens einem der Mehrzahl von Schlüsselanteilen im permanenten Speicher; und Speichern des symmetrischen Schlüssels nur im flüchtigen Speicher.
  4. Durch einen Computer implementiertes Verfahren nach Anspruch 1, das weiterhin umfasst: Empfangen von Transaktionsnutzdaten am ersten TOS-Gateway; Verschlüsseln der Transaktion unter Verwendung des symmetrischen Schlüssels; und Veröffentlichen der verschlüsselten Transaktion für die gemeinsam genutzte Nachrichtenwarteschlange.
  5. Durch einen Computer implementiertes Verfahren nach Anspruch 4, das weiterhin umfasst: Bilden eines oder mehrerer Blöcke, die der Transaktion zugehörig sind; und autonomes Signieren des einen oder mehrerer Blöcke mit einem Blockchain-Schlüssel.
  6. Durch einen Computer implementiertes Verfahren nach Anspruch 5, wobei eine Entität, die die gemeinsam genutzte Nachrichtenwarteschlange verwaltet, nicht in der Lage ist, die Transaktionsnutzdaten zu lesen.
  7. Durch einen Computer implementiertes Verfahren nach Anspruch 5, das Anhängen des einen oder der mehreren signierten Blöcke an eine Blockchain umfasst, die dem Blockchain-Netzwerk zugehörig ist.
  8. Durch einen Computer implementiertes Verfahren nach Anspruch 1, das weiterhin Wiederherstellen des symmetrischen Schlüssels umfasst, wobei das Verfahren umfasst: Anfordern eines der Schlüsselanteile vom zweiten Gateway im Blockchain-Netzwerk; und Wiederherstellen des symmetrischen Schlüssels unter Verwendung des einen Schlüsselanteils.
  9. Durch einen Computer implementiertes Verfahren nach Anspruch 8, wobei das Anfordern des einen Schlüsselanteils vom zweiten Gateway umfasst: Erzeugen eines ephemeren Schlüsselpaares am ersten TOS-Gateway, wobei das ephemere Schlüsselpaar einen ephemeren, privaten Schlüssel und ein ephemeres, öffentliches Gegenstück aufweist; Veröffentlichen des ephemeren, öffentlichen Gegenstücks für die gemeinsam genutzte Warteschlange; Empfangen eines ephemeren, symmetrischen Schlüssels vom zweiten TOS-Gateway über die gemeinsam genutzte Warteschlange, wobei der ephemere, symmetrische Schlüssel teilweise unter Verwendung des ephemeren, öffentlichen Gegenstücks des ersten TOS-Gateways erzeugt wird; Empfangen des einen Schlüsselanteils vom zweiten TOS-Gateway über die gemeinsam genutzte Warteschlange, wobei der eine Schlüsselanteil unter Verwendung des ephemeren, symmetrischen Schlüssels verschlüsselt wird; Entschlüsseln des einen Schlüsselanteils unter Verwendung des ephemeren, symmetrischen Schlüssels; und Vergessen des ephemeren Schlüsselpaares.
  10. Durch einen Computer implementiertes Verfahren nach Anspruch 1, das weiterhin Empfangen einer Anforderung für den symmetrischen Schlüssel am ersten TOS-Gateway vom zweiten TOS-Gateway über die gemeinsam genutzte Warteschlange aufweist; und als Reaktion darauf: Empfangen eines ephemeren, öffentlichen Gegenstücks vom zweiten TOS-Gateway; Erzeugen eines ephemeren Schlüsselpaares, wobei das ephemere Schlüsselpaar einen ephemeren, privaten Schlüssel und ein ephemeres, öffentliches Gegenstück für das erste TOS-Gateway aufweist; Erzeugen eines ephemeren, symmetrischen Schlüssels; Verschlüsseln des ephemeren, symmetrischen Schlüssels unter Verwendung des ephemeren, öffentlichen Gegenstücks vom zweiten TOS-Gateway; Verschlüsseln eines gemeinsam genutzten Schlüssels unter Verwendung des symmetrischen Schlüssels; und Veröffentlichen des verschlüsselten gemeinsam genutzten Schlüssels für die gemeinsam genutzte Warteschlange.
  11. Durch einen Computer implementiertes Verfahren nach Anspruch 9, wobei das TOS-Gateway ein neues TOS-Gateway im Blockchain-Netzwerk ist.
  12. Durch einen Computer implementiertes Verfahren nach Anspruch 1, das weiterhin Rotieren des symmetrischen Schlüssels umfasst, wobei das Verfahren umfasst: Empfangen einer Kanalneukonfigurationsnachricht am ersten TOS-Gateway; Erzeugen eines ephemeren Schlüsselpaares am ersten TOS-Gateway, wobei das ephemere Schlüsselpaar einen ephemeren, privaten Schlüssel und ein ephemeres, öffentliches Gegenstück aufweist; Veröffentlichen des ephemeren, öffentlichen Gegenstücks für die gemeinsam genutzte Warteschlange; Empfangen einer Schlüsselaufteilung vom zweiten TOS-Gateway über die gemeinsam genutzte Warteschlange, wobei die Schlüsselaufteilung unter Verwendung des ephemeren, öffentlichen Gegenstücks verschlüsselt wird; und Entschlüsseln der Schlüsselaufteilung unter Verwendung des ephemeren, privaten Schlüssels.
  13. Durch einen Computer implementiertes Verfahren nach Anspruch 12, wobei die Kanalneukonfigurationsnachricht als Reaktion auf eine TOS-Gateway-Entfernungsaktion erfolgt.
  14. Computerprogrammprodukt für einen vertrauenswürdigen Sortierdienst, wobei das Computerprogrammprodukt aufweist: ein oder mehrere durch einen Computer lesbare Speichermedien und Programmanweisungen, die gemeinsam auf dem einen oder den mehreren durch einen Computer lesbaren Speichermedien gespeichert sind, wobei die Programmanweisungen umfassen: Ausführen eines Gesamtsortierdienst-Gateways für jede Organisation in einem Blockchain-Netzwerk, wobei jedes Gesamtsortierdienst-Gateway über einen Lese-/Schreibzugriff auf eine gemeinsam genutzte Nachrichtenwarteschlange verfügt, die Nachrichten an jede Organisation verteilt; Identifizieren einer Gruppe von Organisationen innerhalb der Organisationen; und Erzeugen eines Kanals, der die Gruppe von Organisationen umfasst, wobei die Gruppe von Organisationen autonom zusammenarbeitet.
  15. Computerprogrammprodukt nach Anspruch 14, das weiterhin Programmanweisungen aufweist, um: einen symmetrischen Schlüssel zu erzeugen, der nur der Gruppe von Organisationen bekannt ist; den symmetrischen Schlüssel in entsprechende Anteile aufzuteilen, die einer Anzahl von Organisationen in der Gruppe von Organisationen zugehörig sind; und die Anteile, nicht jedoch den symmetrischen Schlüssel als Ganzes zu speichern.
  16. Computerprogrammprodukt nach Anspruch 15, das weiterhin Programmanweisungen aufweist, um: eine Transaktion durch ein Gesamtsortierdienst-Gateway von mindestens einer Organisation in der Gruppe von Organisationen zu empfangen; die Transaktion mit dem symmetrischen Schlüssel zu verschlüsseln; einen oder mehrere Blöcke, die der Transaktion zugehörig sind, zu bilden; den einen oder die mehreren Blöcke autonom mit dem entsprechenden Anteil zu signieren; und den einen oder die mehreren signierten Blöcke an die Gruppe von Organisationen weiterzuleiten.
  17. Computerprogrammprodukt nach Anspruch 16, wobei jedes Gesamtsortierdienst-Gateway für jede der Organisationen in der Gruppe von Organisationen ein oder mehrere Zertifikate kennt, die anderen Organisationen in der Gruppe von Organisationen zugehörig sind.
  18. Gesamtsortierdienst für ein Blockchain-Netzwerk, der aufweist: eine Mehrzahl von Gesamtsortierdienst(TOS)-Gateways, die jeweils einer aus einer Mehrzahl von Mitgliedsorganisationen in einem Blockchain-Netzwerk zugehörig sind, wobei die Mehrzahl von TOS-Gateways jeweils einen Prozessor aufweist, der funktionsmäßig mit einem Speicher verbunden ist, wobei der Speicher Programmanweisungen enthält, um, wenn sie auf dem Prozessor ausgeführt werden: einen symmetrischen Schlüssel an einem ersten TOS-Gateway aus der Mehrzahl von TOS-Gateways zu erzeugen; den symmetrischen Schlüssel in eine Mehrzahl von Schlüsselanteilen aufzuteilen; und mindestens einen Schlüsselanteil aus der Mehrzahl von Schlüsselanteilen an ein zweites TOS-Gateway im Blockchain-Netzwerk zu verteilen; eine gemeinsam genutzte Nachrichtenwarteschlange so auszulegen, dass sie den symmetrischen Schlüssel an die Mehrzahl von TOS-Gateways im Blockchain-Netzwerk weiterverteilt.
  19. Blockchain-Netzwerk nach Anspruch 18, wobei: die Mehrzahl der TOS-Gateways weiterhin Programmweisungen enthält, um: Transaktionsnutzdaten zu empfangen; die Transaktionsnutzdaten unter Verwendung des symmetrischen Schlüssels zu verschlüsseln; und die verschlüsselten Transaktionsnutzdaten für die gemeinsam genutzte Nachrichtenwarteschlange zu veröffentlichen; und die gemeinsam genutzte Nachrichtenwarteschlange weiter so auszulegen, dass sie die verschlüsselten Transaktionsnutzdaten an die Mehrzahl von TOS-Gateways im Blockchain-Netzwerk weiterverteilt, wobei die gemeinsam genutzte Nachrichtenwarteschlange nicht in der Lage ist, die Transaktionsnutzdaten zu lesen.
  20. Blockchain-Netzwerk nach Anspruch 19, wobei die Mehrzahl von TOS-Gateways weiterhin Programmanweisungen enthält, um: einen der Schlüsselanteile im permanenten Speicher zu speichern; und den symmetrischen Schlüssel nur im flüchtigen Speicher zu speichern.
DE112021004344.7T 2020-09-29 2021-07-15 Konsensdienst für Blockchain-Netzwerke Pending DE112021004344T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/035,814 2020-09-29
US17/035,814 US11736456B2 (en) 2020-09-29 2020-09-29 Consensus service for blockchain networks
PCT/CN2021/106480 WO2022068318A1 (en) 2020-09-29 2021-07-15 Consensus service for blockchain networks

Publications (1)

Publication Number Publication Date
DE112021004344T5 true DE112021004344T5 (de) 2023-06-15

Family

ID=80821877

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021004344.7T Pending DE112021004344T5 (de) 2020-09-29 2021-07-15 Konsensdienst für Blockchain-Netzwerke

Country Status (6)

Country Link
US (1) US11736456B2 (de)
JP (1) JP2023542317A (de)
CN (1) CN116249999A (de)
DE (1) DE112021004344T5 (de)
GB (1) GB2614841B (de)
WO (1) WO2022068318A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020235942A1 (ko) * 2019-05-21 2020-11-26 웰스트리에스지 유한회사 (영업소) 분실된 개인 키를 복원하는 시스템
US11095431B2 (en) * 2019-12-13 2021-08-17 DLT Global, Inc. Blockchain transaction manager
US11736456B2 (en) * 2020-09-29 2023-08-22 International Business Machines Corporation Consensus service for blockchain networks
US20220166616A1 (en) * 2020-11-24 2022-05-26 International Business Machines Corporation Key reclamation in blockchain network via oprf
US20230229321A1 (en) * 2022-01-04 2023-07-20 Bank Of America Corporation System and method for improving memory resource allocations in database blocks using blockchain
CN117278289A (zh) * 2023-09-28 2023-12-22 贵州大学 基于区块链、加密技术和博弈论的分布式位置缓存协作方法
CN117113199A (zh) * 2023-10-23 2023-11-24 浙江星汉信息技术股份有限公司 一种基于人工智能的档案安全管理系统及方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199206A (ja) * 2007-02-09 2008-08-28 Fuji Electric Holdings Co Ltd 電子マネーシステム、その決済端末、プログラム
US20150163206A1 (en) * 2013-12-11 2015-06-11 Intralinks, Inc. Customizable secure data exchange environment
EP3326323B1 (de) * 2015-07-17 2021-05-12 Robert Bosch GmbH Verfahren und system für die authentifizierung gemeinsamer schlüssel und nachrichten über ein unsicheres gemeinsames kommunikationsmedium
CN107438061B (zh) 2016-05-27 2020-03-03 北京京东尚科信息技术有限公司 一种kafka客户端鉴权的方法和装置
KR102017758B1 (ko) * 2016-07-11 2019-10-21 한국전자통신연구원 의료 기기, 게이트웨이 기기 및 이를 이용한 프로토콜 보안 방법
US11438147B2 (en) * 2016-09-30 2022-09-06 Intel Corporation Technologies for multiple device authentication in a heterogeneous network
CN106775497A (zh) 2017-01-19 2017-05-31 郑志超 基于区块链的分布式存储方法及设备
US10803022B2 (en) 2017-09-08 2020-10-13 ULedger, Inc. Systems and methods of providing immutable records
US11556521B2 (en) * 2017-09-29 2023-01-17 Oracle International Corporation System and method for providing an interface for a blockchain cloud service
US10701046B1 (en) * 2017-10-24 2020-06-30 Verisign, Inc. Symmetric-key infrastructure
US11296864B2 (en) 2018-05-16 2022-04-05 International Business Machines Corporation Identifying faults in a blockchain ordering service
US10985907B2 (en) 2018-05-16 2021-04-20 International Business Machines Corporation Identifying faults in a blockchain ordering service
CN108876370B (zh) 2018-06-12 2021-12-17 北京航空航天大学 一种异构多链架构下跨区块链共享开放数据的体系架构
SG11202102264QA (en) * 2018-09-11 2021-04-29 Visa Int Service Ass System, method, and computer program product for fraud management with a shared hash map
US11736457B2 (en) * 2018-11-13 2023-08-22 Splitbyte Inc. Systems and methods for managing data based on secret sharing
US11316668B2 (en) 2018-11-16 2022-04-26 Safetech Bv Methods and systems for cryptographic private key management for secure multiparty storage and transfer of information
MX2019004671A (es) 2018-11-27 2019-08-21 Alibaba Group Holding Ltd Gestion de claves asimetricas en redes de cadena de bloques de consorcio.
CN109413202B (zh) 2018-11-29 2021-07-09 北京京东尚科信息技术有限公司 区块链交易信息的排序系统及方法
CN109803004B (zh) 2019-01-03 2021-06-01 深圳壹账通智能科技有限公司 区块链智能合约管理方法与装置、电子设备、存储介质
US11509459B2 (en) * 2019-05-10 2022-11-22 Conduent Business Services, Llc Secure and robust decentralized ledger based data management
US11296879B2 (en) * 2019-10-04 2022-04-05 Atakama LLC Encrypted search
US11082220B1 (en) * 2019-10-17 2021-08-03 EMC IP Holding Company LLC Securing recovery data distributed amongst multiple cloud-based storage services
US11251944B2 (en) * 2020-02-21 2022-02-15 Nutanix, Inc. Secure storage and usage of cryptography keys
CN111445328A (zh) 2020-03-16 2020-07-24 西安交通大学 一种跨链网关交互系统和方法以及供应链数据管理方法
US11736456B2 (en) * 2020-09-29 2023-08-22 International Business Machines Corporation Consensus service for blockchain networks
US11418329B1 (en) * 2021-05-28 2022-08-16 Garantir LLC Shared secret implementation of proxied cryptographic keys
US11496327B1 (en) * 2021-07-07 2022-11-08 Ava Labs, Inc. Secure and trustworthy bridge for transferring assets across different networks

Also Published As

Publication number Publication date
GB2614841B (en) 2023-12-13
US20220103532A1 (en) 2022-03-31
WO2022068318A1 (en) 2022-04-07
GB2614841A (en) 2023-07-19
US11736456B2 (en) 2023-08-22
CN116249999A (zh) 2023-06-09
JP2023542317A (ja) 2023-10-06
GB202305433D0 (en) 2023-05-31

Similar Documents

Publication Publication Date Title
DE112021004344T5 (de) Konsensdienst für Blockchain-Netzwerke
DE112020005289B4 (de) Teilweise sortierte blockchain
DE112020005075B4 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE102019123253A1 (de) System und einrichtung für datenvertraulichkeit im distributed ledger
DE112021001413T5 (de) Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit
DE102021123128A1 (de) Mittels blockchains realisiertes datenmigrationsprüfprotokoll
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
DE112021003971T5 (de) Nachhaltige token für eine lieferkette mit datenschutzerhaltendem protokoll
DE102021109950A1 (de) Systeme und verfahren zur berechnung von validierungsverlusten für modelle im dezentralen maschinenlernen
DE112021000688T5 (de) Indexstruktur für blockchain-ledger
US20210297264A1 (en) Enabling consensus in distributed transaction processing systems
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
US11455403B2 (en) Privacy-preserving document sharing
DE102021122557A1 (de) Konformitätsmechanismen in blockchain-netzwerken
US11354425B2 (en) Privacy-preserving document sharing
DE112022000906T5 (de) Trennen von blockchain-daten
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf
DE112021005862T5 (de) Selbstprüfende blockchain
US20220179869A1 (en) Coexistence mediator for facilitating blockchain transactions
US20210227022A1 (en) Media obfuscation
US20210117919A1 (en) Last-mile deliver coordination
DE112021005837T5 (de) Dezentrale sendeverschlüsselung und schlüsselerzeugungseinrichtung

Legal Events

Date Code Title Description
R012 Request for examination validly filed