DE112020005289T5 - Teilweise sortierte blockchain - Google Patents

Teilweise sortierte blockchain Download PDF

Info

Publication number
DE112020005289T5
DE112020005289T5 DE112020005289.3T DE112020005289T DE112020005289T5 DE 112020005289 T5 DE112020005289 T5 DE 112020005289T5 DE 112020005289 T DE112020005289 T DE 112020005289T DE 112020005289 T5 DE112020005289 T5 DE 112020005289T5
Authority
DE
Germany
Prior art keywords
blocks
blockchain
block
epoch
transactions
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.)
Granted
Application number
DE112020005289.3T
Other languages
English (en)
Other versions
DE112020005289B4 (de
Inventor
Krishnasuri Narayanam
Ken Kumar
Dayama Pankaj Satyanarayan
Akshar Kaul
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 DE112020005289T5 publication Critical patent/DE112020005289T5/de
Application granted granted Critical
Publication of DE112020005289B4 publication Critical patent/DE112020005289B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • 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
    • 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
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4418—Suspend and resume; Hibernate and awake
    • 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/12—Applying verification of the received information
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Medicines Containing Material From Animals Or Micro-Organisms (AREA)
  • Non-Alcoholic Beverages (AREA)

Abstract

Eine beispielhafte Operation kann Empfangen von Blöcken einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten und/oder Identifizieren von zwei oder mehr Blöcken von den empfangenen Blöcken, die zu einem selben Zeitabschnitt in der Blockchain gehören, und/oder Validieren der zwei oder mehr identifizierten Blöcke parallel durch gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke und/oder als Reaktion auf das Validieren der zwei oder mehr identifizierten Blöcke Speichern der zwei oder mehr identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers umfassen.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Anwendung bezieht sich allgemein auf Speichern von Daten in einer Blockchain und insbesondere auf ein Blockchain-Ledger, in dem nichtabhängige Blöcke in Zeitabschnitten (slots) statt in einer linearen Abfolge angeordnet sind, wodurch ein verbesserter Datenzugriff auf Blockdaten ermöglicht wird.
  • HINTERGRUND
  • Eine zentrale Datenbank speichert und verwaltet Daten in einer einzelnen Datenbank (z.B. einem Datenbankserver) an einem Ort. Bei diesem Ort handelt es sich häufig um einen Zentralcomputer, z.B. eine Desktop-Zentraleinheit (central processing unit - CPU), eine Server-CPU oder einen Großrechner. Auf Informationen, die in einer zentralen Datenbank gespeichert sind, kann in der Regel von mehreren verschiedenen Orten aus zugegriffen werden. In der zentralen Datenbank können gleichzeitig mehrere Benutzer oder Client-Workstations arbeiten, z.B. auf der Grundlage einer Client/Server-Konfiguration. Eine zentrale Datenbank ist insbesondere hinsichtlich ihrer Sicherheit einfach zu verwalten, zu pflegen und zu überwachen, da sie sich an einem einzigen Ort befindet. In einer zentralen Datenbank wird die Datenredundanz minimiert, da ein einzelner Speicherplatz für alle Daten auch bedeutet, dass ein gegebener Datensatz nur einen primären Datensatz hat.
  • Eine zentrale Datenbank weist jedoch erhebliche Nachteile auf. Eine zentrale Datenbank weist beispielsweise einen Single Point of Failure (einzelner Ausfallpunkt) auf, wenn keine Überlegungen zur Fehlertoleranz angestellt werden. Bei einem Hardwareausfall (z.B. Hardware-, Firmware- und/oder Softwarefehler) gehen daher alle Daten in der Datenbank verloren, und die Arbeit aller Benutzer wird unterbrochen. Darüber hinaus sind zentrale Datenbanken in hohem Maße von der Verbindung mit einem Netzwerk abhängig. Je langsamer die Verbindung ist, desto mehr erhöht sich demnach die Zeit, die für jeden Datenbankzugriff benötigt wird. Ein weiterer Nachteil ist das Auftreten von Engpässen, wenn eine zentrale Datenbank aufgrund der Tatsache, dass es nur einen einzigen Ort gibt, einen hohen Datenverkehr aufweist. Außerdem stellt eine zentrale Datenbank einen begrenzten Datenzugriff bereit, da die Daten in der Datenbank nur einmal vorhanden sind.
  • In jüngster Zeit wenden sich Unternehmen der Blockchain als Mittel zum sicheren Speichern von Daten zu, die nicht durch eine zentrale Entität eingeschränkt wird und von mehreren Orten aus zugänglich ist. In einem Blockchain-Netzwerk sind Peers für ein gemeinsames Verwalten und Speichern von Daten in der Blockchain verantwortlich. Eine Blockchain bietet Datenredundanz, keine zentrale Instanz, mehrere Zugangsknoten und Ähnliches. Eine herkömmliche Blockchain speichert Datenblöcke in einer linearen Abfolge von Blöcken, wobei jeder Block mit dem unmittelbar vorhergehenden Block über einen Hash verknüpft ist usw. Die Verknüpfung ergibt sich dadurch, dass der Block einen Hash des unmittelbar vorhergehenden Blocks speichert. Diese Verknüpfungen bilden eine fortlaufende Kette von Blöcken, die als Blockchain bezeichnet wird.
  • Die Validierung (manchmal auch als Konsensprotokoll bezeichnet) ist ein grundlegender Aspekt der Blockchain, da sie sicherstellt, dass ein Blockchain-Peer einen korrekten Zustand der Blockchain aufweist. In einer genehmigungspflichtigen (permissioned) Blockchain kann ein Blockchain-Peer den Zustand der Blockchain validieren, indem er die Hash-Verknüpfungen zwischen den Blöcken überprüft. Dazu muss der Blockchain-Peer eine Hash-Validierung jeder Verknüpfung in der linearen Kette von Blöcken durchführen. Blockchains können auf Tausende oder gar Millionen von Blöcken anwachsen. Der Validierungsprozess kann daher viel Zeit und Ressourcen in Anspruch nehmen. Somit ist eine Lösung erforderlich, die diese Nachteile und Einschränkungen beseitigt.
  • KURZDARSTELLUNG
  • Im Hinblick auf eine erste Ausführungsform stellt die vorliegende Erfindung eine Vorrichtung bereit, die aufweist: eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie Blöcke einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten empfängt; und einen Prozessor, der so konfiguriert ist, dass er zwei oder mehr Blöcke von den empfangenen Blöcken identifiziert, die zu einem selben Zeitabschnitt in der Blockchain gehören, die zwei oder mehr identifizierten Blöcke parallel durch gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke validiert und als Reaktion auf das Validieren der zwei oder mehr identifizierten Blöcke die zwei oder mehr identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers speichert.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der die zwei oder mehr identifizierten Blöcke, die zu demselben Zeitabschnitt gehören, nicht voneinander abhängige Blöcke sind.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der der Prozessor so konfiguriert ist, dass er die zwei oder mehr identifizierten Blöcke gleichzeitig parallel auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers ausführt.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der der Prozessor weiterhin so konfiguriert ist, dass er das lokale Blockchain-Ledger für einen Bootprozess und/oder einen Wiederherstellungsprozess initialisiert.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der der Prozessor weiterhin so konfiguriert ist, dass er zwei oder mehr andere Blöcke in der Blockchain identifiziert, die zu einem unmittelbar vorhergehenden Zeitabschnitt gehören.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der der Prozessor weiterhin so konfiguriert ist, dass er die zwei oder mehr Blöcke, die zu dem unmittelbar vorhergehenden Zeitabschnitt gehören, parallel zu den zwei oder mehr identifizierten Blöcken, die zu demselben Zeitabschnitt gehören, validiert, wenn die zwei oder mehr anderen Blöcke nicht von den zwei oder mehr identifizierten Blöcken abhängig sind.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der der Prozessor so konfiguriert ist, dass er auf der Grundlage von in den empfangenen Blöcken gespeicherten Hash-Werten erkennt, welche der empfangenen Blöcke zu demselben Zeitabschnitt gehören.
  • Die vorliegende Erfindung stellt vorzugsweise eine Vorrichtung bereit, bei der der Prozessor feststellt, dass ein Block zu einem aktuellen Zeitabschnitt gehört, wenn ein unmittelbar vorhergehender Hash-Wert des Blocks eine Funktion von Hashes mehrerer Blöcke ist, die in einem unmittelbar vorhergehenden Zeitabschnitt in der Blockchain gespeichert sind.
  • Im Hinblick auf einen anderen Aspekt stellt die vorliegende Erfindung ein Verfahren bereit, das Empfangen von Blöcken einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten und/oder Identifizieren von mindestens zwei Blöcken von den empfangenen Blöcken, die zu einem gleichen Zeitabschnitt in der Blockchain gehören, und/oder paralleles Validieren der mindestens zwei identifizierten Blöcke durch gleichzeitiges Ausführen der mindestens zwei identifizierten Blöcke und/oder als Reaktion auf das Validieren der mindestens zwei identifizierten Blöcke Speichern der mindestens zwei identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers umfasst.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, bei dem die zwei oder mehr identifizierten Blöcke, die zu demselben Zeitabschnitt gehören, nicht voneinander abhängige Blöcke sind.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, bei der das Validieren gleichzeitig paralleles Ausführen der zwei oder mehr identifizierten Blöcke auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers aufweist.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, das weiterhin Initialisieren des lokalen Blockchain-Ledger während eines Bootprozesses und/oder eines Wiederherstellungsprozesses aufweist.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, das weiterhin Identifizieren von zwei oder mehr anderen Blöcken in der Blockchain aufweist, die zu einem unmittelbar vorhergehenden Zeitabschnitt gehören.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, das weiterhin Validieren der zwei oder mehr anderen Blöcke, die zu dem unmittelbar vorhergehenden Zeitabschnitt gehören, parallel zu den zwei oder mehr identifizierten Blöcken, die zu demselben Zeitabschnitt gehören, aufweist, wenn die zwei oder mehr anderen Blöcke nicht von den zwei oder mehr identifizierten Blöcken abhängig sind.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, bei dem das Identifizieren Erkennen aufweist, welche der empfangen Blöcke auf der Grundlage von in den empfangenen Blöcken gespeicherten Hash-Werten zum selben Zeitabschnitt gehören.
  • Die vorliegende Erfindung stellt vorzugsweise ein Verfahren bereit, bei dem das Identifizieren ein Feststellen aufweist, dass ein Block in einen aktuellen Zeitabschnitt gehört, wenn ein unmittelbar vorhergehender Hash-Wert des Blocks eine Funktion von Hashes mehrerer Blöcke ist, die in einem unmittelbar vorhergehenden Zeitabschnitt in der Blockchain gespeichert sind.
  • Im Hinblick auf einen anderen Aspekt stellt die vorliegende Erfindung ein nichtflüchtiges, durch einen Computer lesbares Medium bereit, das Anweisungen aufweist, die, wenn sie von einem Prozessor gelesen werden, den Prozessor veranlassen, ein Empfangen von Blöcken einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten und/oder ein Identifizieren von mindestens zwei Blöcken von den empfangenen Blöcken, die zu einem selben Zeitabschnitt in der Blockchain gehören, und/oder ein Validieren der mindestens zwei identifizierten Blöcke parallel durch gleichzeitiges Ausführen der mindestens zwei identifizierten Blöcke und/oder als Reaktion auf das Validieren der mindestens zwei identifizierten Blöcke ein Speichern der mindestens zwei identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers durchzuführen.
  • Die vorliegende Erfindung stellt vorzugsweise ein nichtflüchtiges, durch einen Computer lesbares Medium bereit, bei dem die zwei oder mehr identifizierten Blöcke, die zu demselben Zeitabschnitt gehören, nicht voneinander abhängige Blöcke sind.
  • Die vorliegende Erfindung stellt vorzugsweise ein nichtflüchtiges, durch einen Computer lesbares Medium bereit, bei der das Validieren gleichzeitig paralleles Ausführen der zwei oder mehr identifizierten Blöcke auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers aufweist.
  • Die vorliegende Erfindung stellt vorzugsweise ein nichtflüchtiges, durch einen Computer lesbares Medium bereit, wobei das Verfahren weiterhin Initialisieren des lokalen Blockchain-Ledger während eines Bootprozesses und/oder eines Wiederherstellungsprozesses aufweist.
  • Figurenliste
    • 1A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein Blockchain-Netzwerk veranschaulicht.
    • 1B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein teilweise sortiertes Blockchain-Ledger veranschaulicht.
    • 2A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine Konfiguration einer Blockchain-Architektur veranschaulicht.
    • 2B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Blockchain-Transaktionsablauf veranschaulicht.
    • 3A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein genehmigungspflichtiges Blockchain-Netzwerk veranschaulicht.
    • 3B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein weiteres genehmigungspflichtiges Blockchain-Netzwerk veranschaulicht.
    • 3C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein genehmigungsfreies (permissionsless) Blockchain-Netzwerk veranschaulicht.
    • 4A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum parallelen Validieren von Blöcken während einer Peer-Operation veranschaulicht.
    • 4B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Überspringen von Blöcken während einer Abfrageabrufoperation veranschaulicht.
    • 4C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Zuordnen von Transaktionen zu DAGs zum Ermitteln paralleler Verarbeitungsoptionen veranschaulicht.
    • 4D ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum selektiven Validieren von Blöcken beim Speichern einer neuen Transaktion veranschaulicht.
    • 4E ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum teilweisen Sortieren verschlüsselter Datenblöcke veranschaulicht.
    • 5 ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein Verfahren zum parallelen Validieren von Blöcken veranschaulicht.
    • 6A ist eine Darstellung, die ein Beispielsystem veranschaulicht, das so konfiguriert ist, dass es gemäß beispielhaften Ausführungsformen eine oder mehrere hier beschriebene Operationen durchführt.
    • 6B ist eine Darstellung, die ein weiteres Beispielsystem veranschaulicht, das so konfiguriert ist, dass es gemäß beispielhaften Ausführungsformen eine oder mehrere hier beschriebene Operationen durchführt.
    • 6C ist eine Darstellung, die ein weiteres Beispielsystem veranschaulicht, das so konfiguriert ist, dass es gemäß beispielhaften Ausführungsformen einen Smart Contract verwendet.
    • 6D ist eine Darstellung, die ein weiteres Beispielsystem veranschaulicht, das so konfiguriert ist, dass es gemäß beispielhaften Ausführungsformen eine Blockchain verwendet.
    • 7A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess veranschaulicht, bei dem ein neuer Block zu einem Distributed Ledger (verteiltes Kontenbuch) hinzugefügt wird.
    • 7B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen den Inhalt eines neuen Datenblocks veranschaulicht.
    • 7C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine Blockchain für digitalen Inhalt veranschaulicht.
    • 7D ist eine Darstellung, die einen Block veranschaulicht, der gemäß beispielhaften Ausführungsformen die Struktur von Blöcken in der Blockchain darstellen kann.
    • 8A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine beispielhafte Blockchain veranschaulicht, die Daten zum maschinellen Lernen (künstliche Intelligenz) speichert.
    • 8B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine beispielhafte quantensichere Blockchain veranschaulicht.
    • 9 ist eine Darstellung, die ein Beispielsystem veranschaulicht, das eine oder mehrere der beispielhaften Ausführungsformen unterstützt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Es versteht sich, dass die unmittelbaren Komponenten, die in den Figuren hier allgemein beschrieben und veranschaulicht sind, in vielen verschiedenen Konfigurationen angeordnet und ausgeführt sein können. Die folgende ausführliche Beschreibung der Ausführungsformen mindestens eines Verfahrens, einer Vorrichtung, eines nichtflüchtigen, durch einen Computer lesbaren Mediums und eines Systems, wie in den beigefügten Figuren dargestellt, soll daher den Anwendungsbereich der beanspruchten Anmeldung nicht einschränken, sondern stellt lediglich ausgewählte Ausführungsformen dar.
  • Die in dieser Beschreibung dargelegten unmittelbaren Merkmale, Strukturen oder Eigenschaften können in jeder geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert oder entfernt werden. Die Ausdrücke „beispielhafte Ausführungsformen“, „einige Ausführungsformen“ oder andere ähnliche Begriffe in dieser Beschreibung beziehen sich darauf, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform enthalten sein kann. Daher beziehen sich die Ausdrücke „beispielhafte Ausführungsformen“, „in einigen Ausführungsformen“, „in anderen Ausführungsformen“ oder ähnliche Begriffe in dieser Beschreibung nicht unbedingt alle auf dieselbe Gruppe von Ausführungsformen, und die beschriebenen Merkmale, Strukturen oder Eigenschaften können in geeigneter Weise in einer oder mehreren Ausführungsformen kombiniert oder entfernt werden. Weiterhin kann in den Darstellungen jede Verbindung zwischen Elementen eine einseitige und/oder zweiseitige Datenübertragung ermöglichen, auch wenn die dargestellte Verbindung ein einseitiger oder zweiseitiger Pfeil ist. Ferner kann jede in den Zeichnungen dargestellte Einheit eine andere Einheit sein. Wenn zum Beispiel eine mobile Einheit gezeigt wird, die Informationen sendet, könnte auch eine drahtgebundene Einheit verwendet werden, um die Informationen zu senden.
  • Auch wenn in der Beschreibung der Ausführungsformen der Begriff „Nachricht“ verwendet wird, kann die Anwendung auf viele Arten von Netzwerken und Daten angewendet werden. Bestimmte Arten von Verbindungen, Nachrichten und Signalübertragungen können darüber hinaus zwar in beispielhaften Ausführungsformen dargestellt werden, die Anwendung ist jedoch nicht auf eine bestimmte Art von Verbindung, Nachricht und Signalübertragung beschränkt.
  • Beispielhafte Ausführungsformen stellen Verfahren, Systeme, Komponenten, nichtflüchtige, durch einen Computer lesbare Medien, Einheiten und/oder Netzwerke für ein teilweise sortiertes Blockchain-Ledger bereit, in dem Blöcke in Zeitabschnitten statt in einer linearen Abfolge angeordnet sind.
  • In einer Ausführungsform verwendet die Anwendung eine dezentrale Datenbank (z.B. eine Blockchain), bei der es sich um ein verteiltes Speichersystem handelt, das mehrere Knoten umfasst, die untereinander Daten austauschen. Die dezentrale Datenbank umfasst eine unveränderliche „Append-only“-Datenstruktur (append-only = nur hinzufügen), die einem Distributed Ledger ähnelt und in der Lage ist, Datensätze zwischen gegenseitig nichtvertrauenswürdigen Parteien zu verwalten. Die nichtvertrauenswürdigen Parteien werden hier als Peers oder Peer-Knoten bezeichnet. Jeder Peer verwaltet eine Kopie der Datenbanksätze, und kein Peer alleine kann die Datenbanksätze ändern, ohne dass darüber ein Konsens zwischen den verteilten Peers erzielt wird. Die Peers können beispielsweise ein Konsensprotokoll ausführen, um Blockchain-Speichertransaktionen zu validieren, die Speichertransaktionen in Blöcke zu gruppieren und eine Hash-Kette über die Blöcke zu erzeugen. Dieser Prozess führt zur Bildung des Ledger, indem die Speichertransaktionen so in eine Reihenfolge gebracht werden, wie es für die Konsistenz erforderlich ist. In verschiedenen Ausführungsformen kann eine genehmigungspflichtige und/oder eine genehmigungsfreie Blockchain verwendet werden. Bei einer öffentlichen oder genehmigungsfreien Blockchain kann jeder teilnehmen, ohne dass eine bestimmte Identität erforderlich ist. Öffentliche Blockchains können native Kryptowährungen umfassen und verwenden einen Konsens auf der Grundlage verschiedener Protokolle wie z.B. Proof-of-Work (PoW). Andererseits stellt eine genehmigungspflichtige Blockchain-Datenbank sichere Interaktionen zwischen einer Gruppe von Entitäten bereit, die ein gemeinsames Ziel verfolgen, sich jedoch gegenseitig nicht vollständig vertrauen, z.B. Unternehmen, die Geldmittel, Waren, Informationen und Ähnliches austauschen.
  • Die vorliegende Anwendung kann eine Blockchain verwenden, die eine beliebige, programmierbare Logik ausführt, die auf ein dezentrales Schema zur Datenspeicherung zugeschnitten ist und als „Smart Contracts“ (intelligente Verträge) oder „Chaincodes“ bezeichnet wird. In einigen Fällen können spezielle Chaincodes für Verwaltungsfunktionen und Parameter zur Verfügung stehen, die als System-Chaincode bezeichnet werden. Die Anwendung kann weiterhin Smart Contracts verwenden, bei denen es sich um vertrauenswürdige verteilte Anwendungen handelt, die fälschungssichere Eigenschaften der Blockchain-Datenbank und eine zugrunde liegende Vereinbarung zwischen den Knoten nutzen, die als Endorsement (Bestätigung) oder Endorsement Policy (Bestätigungsrichtlinie) bezeichnet wird. Blockchain-Transaktionen, die dieser Anwendung zugehörig sind, können „bestätigt“ werden, bevor sie in der Blockchain festgeschrieben (committed) werden, während nichtbestätigte Transaktionen ignoriert werden. Eine Endorsement Policy ermöglicht einem Chaincode, Endorser (Bestätiger) für eine Transaktion in Form eines Satzes von Peer-Knoten anzugeben, die für die Bestätigung notwendig sind. Wenn ein Client die Transaktion an die in der Endorsement Policy angegebenen Peers sendet, wird die Transaktion ausgeführt, um die Transaktion zu validieren. Nach dem Validieren beginnt eine Sortierphase für die Transaktionen, in der ein Konsensprotokoll verwendet wird, um eine geordnete Folge von bestätigten Transaktionen zu erstellen, die in Blöcken gruppiert sind.
  • Die vorliegende Anwendung kann Knoten verwenden, bei denen es sich um die Datenübertragungsentitäten des Blockchain-Systems handelt. Ein „Knoten“ kann eine logische Funktion in dem Sinne durchführen, dass mehrere Knoten unterschiedlichen Typs auf demselben physischen Server laufen können. Knoten werden in Vertrauensbereichen gruppiert und sind logischen Entitäten zugehörig, die sie auf verschiedene Weise steuern. Die Knoten können verschiedene Typen umfassen, z.B. einen Client- oder sendenden Client-Knoten, der einen Transaktionsaufruf an einen Endorser (z.B. einen Peer) sendet und Transaktionsvorschläge an einen Sortierdienst (ordering service) (z.B. einen Sortierknoten (ordering node)) übermittelt. 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. Peers können auch die Rolle eines Endorser übernehmen, was jedoch nicht zwingend erforderlich ist. Ein Sortierdienstknoten oder Sortierer (orderer) ist ein Knoten, der den Datenübertragungsdienst für alle Knoten durchführt und eine Zustellungsgarantie implementiert, 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, was ein anderer Name für die anfängliche Blockchain-Transaktion ist, die normalerweise Steuerungs- und Einrichtungsinformationen umfasst.
  • Die vorliegende Anwendung kann ein Ledger verwenden, bei dem es sich um eine sequenzierte, fälschungssichere Aufzeichnung aller Zustandswechsel einer Blockchain handelt. Zustandswechsel können sich aus Chaincode-Aufrufen (d.h. Transaktionen) ergeben, die von beteiligten Parteien (z.B. Client-Knoten, Sortierknoten, Endorser-Knoten, Peer-Knoten usw.) gesendet werden. Jede teilnehmende Partei (z.B. ein Peer-Knoten) kann eine Kopie des Ledger unterhalten. Eine Transaktion kann dazu führen, dass ein Satz von Vermögenswert-Schlüssel-Wert-Paaren als ein oder mehrere Operanden im Ledger festgeschrieben werden, z.B. Erzeugen, Aktualisieren, Löschen und Ähnliches. Das Ledger umfasst eine Blockchain (auch als Chain bezeichnet), in der ein unveränderlicher, sequenzierter Datensatz in Blöcken gespeichert wird. Das Ledger umfasst auch eine Zustandsdatenbank, in der ein aktueller Zustand der Blockchain festgehalten wird.
  • Die vorliegende Anwendung kann eine Chain verwenden, bei der es sich um ein Transaktionsprotokoll handelt, das als Hash-verknüpfte Blöcke strukturiert ist, wobei jeder Block eine Sequenz von N Transaktionen enthält, wobei N gleich oder größer als eins ist. Der Blockkopf umfasst einen Hash der Transaktionen des Blocks sowie einen Hash des Kopfes des vorherigen Blocks. Auf diese Weise können alle Transaktionen im Ledger sequenziert und kryptografisch miteinander verknüpft werden. Es ist daher nicht möglich, die Ledger-Daten zu manipulieren, ohne die Hash-Verknüpfungen zu beschädigen. Ein Hash eines zuletzt hinzugefügten Blockchain-Blocks stellt jede Transaktion in der Chain dar, die vor ihm stattgefunden hat, wodurch sichergestellt werden kann, dass sich alle Peer-Knoten in einem einheitlichen und vertrauenswürdigen Zustand befinden. Die Chain kann in einem Peer-Knoten-Dateisystem gespeichert werden (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 stellt die neuesten Werte für alle Schlüssel dar, die im Transaktionsprotokoll der Chain enthalten sind. Da der aktuelle Zustand die neuesten Schlüsselwerte darstellt, die einem Kanal bekannt sind, wird er manchmal auch als „World State“ bezeichnet. Chaincode-Aufrufe führen mit den Daten des aktuellen Zustands des Ledger Transaktionen aus. Damit diese Chaincode-Interaktionen effizient sind, können die aktuellen Werte der Schlüssel in einer Zustandsdatenbank gespeichert werden. Die Zustandsdatenbank kann einfach eine indizierte Ansicht des Transaktionsprotokolls der Chain sein, daher kann sie jederzeit anhand der Chain neu erzeugt werden. Die Zustandsdatenbank kann automatisch wiederhergestellt (oder bei Bedarf erzeugt) werden, wenn der Peer-Knoten gestartet wird und bevor Transaktionen angenommen werden.
  • Blockchain-Frameworks wie Hyperledger Fabric stellen eine genehmigungspflichte Distributed-Ledger-Technologie (DLT) für Unternehmen bereit. Die genehmigungspflichtige Blockchain unterscheidet sich von einer öffentlichen Blockchain dadurch, dass der Zugriff auf eine genehmigungspflichtige Blockchain auf Mitglieder der Blockchain beschränkt ist. Hyperledger Fabric ist für die Einführung einer neuen Architektur zum Speichern von Blockchain-Transaktionen im Ledger bekannt, die als „Execute-Order-Validate“ (Ausführen-Sortieren-Validieren) bezeichnet wird. Es handelt sich mittlerweile um eine universelle Blockchain-Architektur, die sowohl in der Industrie als auch im öffentlichen Bereich eingesetzt wird.
  • Eines der Schlüsselelemente eines Execute-Order-Validate-Blockchain-Netzwerks ist ein Sortierdienst (ordering service) (hier auch als Sortierknoten (ordering node) bezeichnet). Die Rolle des Sortierers besteht darin, Blöcke, die in geordneter Weise ausgeführt wurden, den Blockchain-Peers zum Speichern in ihren jeweiligen Ledgers bereitzustellen. Sortierer stellen einen gemeinsam genutzten Datenübertragungskanal für Clients und Peers bereit und bieten einen Übertragungsdienst für Transaktionen mit Nachrichten an. Die Sortierer stellen ferner sicher, dass die Transaktionen genau sortiert werden (d.h., jede Transaktion kommt genau vor oder nach einer anderen Transaktion).
  • Wenn ein Sortierer genügend Transaktionen empfangen und die Transaktionen sortiert hat, erzeugt der Sortierer einen Block und überträgt den Block an die am Blockchain-Netzwerk teilnehmenden Blockchain-Peers. Jeder Block enthält einen Hash des unmittelbar vorhergehenden Blocks in der Blockchain. Auf diese Weise wird eine Verknüpfung zwischen den beiden Blöcken hergestellt. Dieser Prozess wird kontinuierlich wiederholt, wenn neue Blöcke erzeugt werden. Das Ergebnis ist eine lineare, sequenzielle Reihenfolge von Blöcken. Die Größe der Blöcke ist jedoch begrenzt. Darüber hinaus erfordert das Validieren solcher Blöcke, dass jeder Hash in der linearen Abfolge von Blöcken validiert wird. Dies kann dazu führen, dass während eines Validierungsprozesses Hunderte, Tausende oder gar Millionen von Hashes überprüft werden.
  • Die beispielhaften Ausführungsformen führen einen neuen Sortierprozess für Blöcke in einem Blockchain-Ledger ein, der als teilweise sortierte Transaktionen oder teilweise sortierte Blöcke bezeichnet wird. In Blöcken können Hunderte oder Tausende von Transaktionen gespeichert werden. Allerdings sind nicht alle Blöcke voneinander abhängig. Ein neuer Block ist beispielsweise nicht unbedingt von einem unmittelbar vorhergehenden Block abhängig. Das hier beschriebene System macht sich diese Nichtabhängigkeit zunutze und führt die Verwendung von Zeitabschnitten im Blockchain-Ledger ein. Zeitabschnitte können vom Sortierdienst genutzt werden, um mehrere Blöcke parallel zueinander und in Folge in Bezug auf andere Zeitabschnitte zu speichern. In einem Zeitabschnitt können beispielsweise zwei oder mehr Blöcke gespeichert werden, und jeder der zwei oder mehr Blöcke kann eine Hash-Verknüpfung zu einem vorherigen Zeitabschnitt enthalten. In diesem Beispiel kann jeder der zwei oder mehr Blöcke im aktuellen Zeitabschnitt eine Hash-Funktion enthalten, die auf einer Kombination von Blöcken in einem vorherigen Zeitabschnitt beruht, anstatt eine Hash-Verknüpfung zu einem Block (z.B. einem unmittelbar vorhergehenden Block) zu enthalten.
  • Zu den Vorteilen einer teilweise sortierten Blockchain (und der darin enthaltenen Transaktionen) gehört die Möglichkeit, Blöcke parallel zu validieren/auszuführen. Bei einer herkömmlichen Blockchain erfolgt das Validieren in einer linearen Abfolge, bei der jeder Block-Hash in einer sequenziellen Reihenfolge überprüft wird. Das Ergebnis ist eine kontinuierliche Folge von Hash-Überprüfungen, die linear durchgeführt werden. Im Gegensatz dazu ermöglicht die teilweise sortierte Blockchain, dass mehrerer Blöcke (z.B. Blöcke im selben Zeitabschnitt usw.) parallel ausgeführt/validiert werden. Dadurch kann der Zeitaufwand für das Validieren der Blockchain erheblich verringert werden. Zu den weiteren Vorteilen der teilweise sortierten Blockchain gehören eine schnellere Wiederherstellung bzw. ein schnelleres Booten der Peers, eine schnellere Verarbeitung von Abfragen, eine selektive Validierung von Blöcken zur Verbesserung des Transaktionsdurchsatzes, die Anwendung verschiedener Verfahren auf der Grundlage eines DAG durch eine Gruppe von Peers einer beliebigen Organisation zur Verbesserung des Transaktionsdurchsatzes und der Antwortzeiten auf Abfragen, das Sortieren verschlüsselter Transaktionsblöcke und Ähnliches.
  • 1A zeigt ein Blockchain-Netzwerk 100, das gemäß beispielhaften Ausführungsformen ein Execute-Order-Validate-Framework befolgt. Mit Bezug auf 1A umfasst das Blockchain-Netzwerk 100 eine Mehrzahl von Blockchain-Peers 121, 122, 123 und 124, die eine verteilte Kopie eines Blockchain-Ledger (Blockchain 110) speichern. Clients (nicht dargestellt) können über die Blockchain-Peers 121 bis 124 Transaktionen zum Speichern in der Blockchain 110 vorschlagen. Bevor Transaktionen in der Blockchain 110 festgeschrieben (comitted) werden, können die Transaktionen von einem oder mehreren bestätigenden Peers ausgeführt werden. Jeder der Blockchain-Peers 121 bis 124 kann als Endorser fungieren.
  • Erfolgreich ausgeführte Transaktionen können dann dem Sortierknoten 120 (z.B. durch den Client usw.) bereitgestellt werden. Der Sortierknoten 120 empfängt Transaktionen, sortiert sie auf der Grundlage von Zeitstempeln und speichert die sortierten Transaktionen in Blöcken. Wenn genügend Transaktionen empfangen wurden oder ein vorgegebenes Zeitlimit abgelaufen ist, kann ein neuer Block mit sortierten Transaktionen abgetrennt und zum Speichern an die Blockchain-Peers 121 bis 124 gesendet werden. Vor dem Speichern kann jeder der Blockchain-Peers 121 bis 124 die Transaktionen noch einmal validieren, bevor die Blöcke in ihrer jeweiligen Kopie der Blockchain 110 gespeichert werden. Der Sortierknoten 120 kann jedoch auch teilweise sortierte Blöcke/Transaktionen wie in 1B dargestellt erzeugen, anstatt die Blöcke in einer linearen Abfolge anzuordnen.
  • 1B zeigt insbesondere ein Beispiel für ein teilweise sortiertes Blockchain-Ledger 110 gemäß beispielhaften Ausführungsformen. Wie ersichtlich ist, sind nicht alle Transaktionen voneinander abhängig, und Transaktionen sind auch nicht in einem aktuellen Block immer von jedem vorherigen Block in der Blockchain abhängig. Beim teilweisen Sortieren wird auf dieses Konzept zurückgegriffen und ein Mechanismus bereitgestellt, bei dem nichtabhängige Blöcke (Blöcke, die keine voneinander abhängige Transaktionen aufweisen) im gleichen Zeitabschnitt im Blockchain-Ledger gespeichert werden können. Um zu verhindern, dass ein Zeitabschnitt zu groß wird, kann der Sortierknoten 120 eine maximale Größe des Zeitabschnitts, eine Begrenzungszeit und/oder Ähnliches implementieren.
  • Gemäß verschiedenen Ausführungsformen kann der Sortierknoten 120 die Transaktionen so anordnen, dass sie so lange wie möglich (oder bis zum Erreichen einer maximalen Größe des Zeitabschnitts oder einer Begrenzungszeit) keine Abhängigkeiten zwischen Blöcken aufweisen. In den beispielhaften Ausführungsformen wird darüber hinaus das Konzept von Zeitabschnitten im Blockchain-Ledger eingeführt. Bei einem Zeitabschnitt handelt es sich im Wesentlichen um eine Gruppe von Blöcken, die parallel im Blockchain-Ledger (das in der Regel linear-sequenziell ist) angeordnet werden können. Der parallel angeordnete Zeitabschnitt kann vertikal (parallel) verlaufen, während die verschiedenen Zeitabschnitte des Ledger im Gegensatz zu einer herkömmlichen linearen Abfolge von Blöcken horizontal (sequenziell nacheinander) verlaufen. Aus zeitlichen Gründen wird davon ausgegangen, dass die Blöcke im selben Zeitabschnitt gleich sind. Das System kann dieses Konzept einführen, da keiner der Blöcke voneinander abhängige Transaktionen enthält, sodass die Zeitunterschiede zwischen verschiedenen Blöcken im selben Zeitabschnitt nicht mehr kritisch sind.
  • 1B veranschaulicht ein Beispiel von vier Zeitabschnitten 111, 112, 113 und 114 der jeweiligen Blöcke 115. Es ist nicht erforderlich, dass ein Zeitabschnitt mehr als einen Block umfasst. Mit anderen Worten: Ein Zeitabschnitt kann nur einen einzigen Block oder zwei oder mehr Blöcke enthalten. Außerdem kann die Anzahl der Blöcke in jedem Zeitabschnitt 111 bis 114 durch eine Größe des Zeitabschnitts, eine vom Sortierknoten 120 überwachte Begrenzungszeit und Ähnliches begrenzt werden.
  • Für Transaktionen im selben Zeitabschnitt können die Transaktionen verschiedene Eigenschaften haben, die vom Sortierknoten 120 identifiziert und implementiert werden. Beispielsweise kann eine Transaktion in einem Block (z.B. Block 9) des Zeitabschnitts 112 von den Transaktionen in demselben Block (z.B. Block 9) oder von den Transaktionen in Blöcken (z.B. Block 8) eines vorherigen Zeitabschnitts 111 (oder anderer Zeitabschnitte) abhängig sein. Eine Transaktion in einem Block kann jedoch nicht von den Transaktionen anderer Blöcke im selben Zeitabschnitt abhängig sein. Block 9 kann daher keine Transaktionen haben, die von den Blöcken 10, 11 oder 12 abhängig sind und umgekehrt. Wenn ein neuer Block eine Transaktion enthält, die von einer Transaktion in einem Block des aktuellen Zeitabschnitts abhängig ist, erzeugt der Sortierknoten 120 einen neuen Zeitabschnitt. Wenn der Sortierknoten 112 beispielsweise beim Erzeugen des Zeitabschnitts 112 eine Transaktion empfängt, die von Block 10 abhängig ist, kann der Sortierknoten Block 13 erzeugen und gleichzeitig auch den Zeitabschnitt 113 erzeugen.
  • Der vorherige Hash-Wert, der in jedem Block gespeichert wird, ist indessen anders als in einer herkömmlichen linearen sequenziellen Blockchain. In dem Beispiel von 1B wird eine Funktion 116 verwendet, um den vorherigen Hash-Wert zu erzeugen. Jeder der Blöcke im selben Zeitabschnitt kann zum Beispiel denselben vorherigen Hash-Wert speichern. Bei dem vorherigen Hash-Wert kann es sich darüber hinaus um einen Wert handeln, der auf der Grundlage einer Kombination von Hash-Werten/Blöcken von einem unmittelbar vorhergehenden Zeitabschnitt erzeugt wurde. Die Blöcke 13, 14 und 15 gehören beispielsweise zum selben Zeitabschnitt 113 (auch als Zeitabschnitt i bezeichnet). In diesem Fall kann jeder der Blöcke 13, 14 und 15 einen vorherigen Hash-Wert speichern, der auf einer Kombination von Hashes der Blöcke 9, 10, 11 und 12, die zu einem unmittelbar vorhergehenden Zeitabschnitt 112 gehören, und auf einem vorherigen Hash-Wert 116 der Blöcke 9, 10, 11 und 12 beruht. Auf diese Weise wird sichergestellt, dass der sequenzielle Charakter der Zeitabschnitte erhalten bleibt, während gleichzeitig Parallelität zwischen den Blöcken im selben Zeitabschnitt ermöglicht wird.
  • Gemäß verschiedenen Ausführungsformen ist der vorherige Hash-Wert eines neuen Blocks im Zeitabschnitt (i) eine Funktion (Fn) der Hashes der Blöcke in einem vorherigen Zeitabschnitt (i-1). Zu Beispielen für die Funktion Fn gehören ein XOR von Hashes von Blöcken in einem vorherigen Zeitabschnitt. Ein weiteres Beispiel besteht darin, dass die Funktion Fn ein zusammengesetzter Hash-Wert von Blöcken im vorherigen Zeitabschnitt ist. Ein zusammengesetzter Hash kann zum Beispiel ein sekundärer Hash des Schlüssels als Funktion der Hashes von Blöcken im vorherigen Zeitabschnitt sein.
  • In dem Beispiel von 1B sind die Blöcke 9 bis 12 nicht voneinander abhängig und gehören daher zum selben Zeitabschnitt 112. Block 13 verstößt indessen gegen die Nichtabhängigkeitsanforderungen, da mindestens eine der Transaktionen in Block 13 von Transaktionen in einem der Blöcke 9 bis 12 abhängig ist. Der Sortierknoten 120 erzeugt daher einen neuen Zeitabschnitt 113, und Block 13 wird zu dem Zeitabschnitt 13 hinzugefügt. Der vorherige Hash-Wert für den Block 13 ist darüber hinaus eine Funktion 116, die auf den Blöcken im vorherigen Zeitabschnitt 112 beruht. Die übrigen Blöcke 14 und 15 sind indessen nicht von den Transaktionen in Block 13 oder nicht voneinander abhängig. Die Blöcke 14 und 15 werden daher zu dem Zeitabschnitt 113 hinzugefügt. Indessen verstößt entweder Block 16 gegen die Abhängigkeitsanforderungen oder Block 16 wird nach einem Parameter zum Begrenzen des Zeitabschnitts empfangen.
  • Damit die Rechenkosten nicht in die Höhe schießen, kann der Sortierknoten 120 beispielsweise eine Anforderung an die Größe des Zeitabschnitts und/oder eine Begrenzungszeitanforderung implementieren. Die Anforderung an die Größe des Zeitabschnitts begrenzt die Anzahl von Blöcken (oder Transaktionen), die in einem Zeitabschnitt vorhanden sein kann. Wenn die Anzahl der Blöcke in dem Zeitabschnitt den Parameter der zugewiesenen Größe des Zeitabschnitts erreicht, trennt der Sortierknoten 120 einen neuen Zeitabschnitt ab und platziert einen nächsten Block in dem neuen Zeitabschnitt. In einem weiteren Beispiel ist der Parameter der Begrenzungszeit die maximale zugewiesene Zeit, in der der Sortierknoten 120 Blöcke zum aktuellen Zeitabschnitt hinzufügen kann. Der Parameter der Begrenzungszeit kann vom Sortierknoten 120 überwacht werden, der einen Zeitgeber startet, wenn ein neuer Zeitabschnitt erzeugt wird. In diesem Fall fügt der Sortierknoten 120 dem Zeitabschnitt so lange Blöcke hinzu, bis der Zeitgeber abläuft/beendet ist. Wenn der Sortierknoten 120 einen neuen Zeitabschnitt beginnt, startet der Sortierknoten 120 die Zeit neu. In dem Beispiel von 1B wird davon ausgegangen, dass beim Erzeugen des Zeitabschnitts 113 ein Zeitgeber abgelaufen ist und dass Block 16 nach dem Ablaufen des Zeitgebers erzeugt wurde. Block 16 wird daher einem neuen Zeitabschnitt 114 hinzugefügt.
  • Der Sortierknoten 120 kann einen Zeitabschnitt-Lesesatz und einen Zeitabschnitt-Schreibsatz speichern, die Schlüssel enthalten, die von den Transaktionen in den Blöcken gelesen oder geschrieben wurden, die zum aktuellen Zeitabschnitt gehören. Indem die Größe des Zeitabschnitts begrenzt wird, werden die vom Sortierknoten 120 zum Speichern dieser Sätze in Anspruch genommene Ressourcen begrenzt. In einigen Ausführungsformen kann ein neuer Zeitabschnitt auch erzeugt werden, wenn der Sortierknoten 120 eine neue Transaktion empfängt, die von einer Transaktion in einem vorherigen Block des aktuellen Zeitabschnitts abhängig ist. In diesem Fall werden die vom Sortierer in Anspruch genommenen Ressourcen automatisch zurückgesetzt. Die Größenbegrenzung eines Zeitabschnitts stellt sicher, dass der Sortierer nicht überfordert wird, wenn keine neue Transaktion eintrifft, die von einer Transaktion in einem vorherigen Block des aktuellen Zeitabschnitts abhängig ist. Die tatsächliche Größe des Zeitabschnitts kann abhängig von den beim Sortierer zur Verfügung stehenden Ressourcen festgelegt werden. Wenn die Größe eines Zeitabschnitts nicht begrenzt ist, kann die Hash-Validierung des vorherigen Blocks darüber hinaus sehr lange dauern, da darauf gewartet werden muss, dass viele unmittelbar vorhergehende Blöcke empfangen werden. Aufgrund der begrenzten Anzahl von Prozessoren, die jeder Peer besitzt, können nicht alle Blöcke in einem Zeitabschnitt parallel validiert werden.
  • Indem in einem anderen Beispiel die Zeitdauer, während der ein Zeitabschnitt offen ist, begrenzt wird, werden die vom Sortierknoten 120 zum Speichern dieser Sätze in Anspruch genommenen Ressourcen begrenzt. Die Begrenzung der Zeitdauer, während der ein Zeitabschnitt offen ist, stellt ebenfalls sicher, dass der Sortierknoten 120 nicht überfordert wird, wenn keine neue Transaktion eintrifft, die von einer Transaktion in einem vorherigen Block des aktuellen Zeitabschnitts abhängig ist. Die tatsächliche Zeitdauer, während der ein Zeitabschnitt offen ist, kann abhängig von den beim Sortierer zur Verfügung stehenden Ressourcen festgelegt werden. Wenn die Zeitdauer, während der ein Zeitabschnitt offen ist, nicht begrenzt ist, weisen die Transaktionen, die zu Beginn/früher in dem Zeitabschnitt enthalten sind, eine hohe Latenzzeit auf.
  • Bei diesen Beispielen kann ein neuer Zeitabschnitt für die folgenden drei Szenarien erzeugt werden. Ein neuer Zeitabschnitt kann zum Beispiel erzeugt werden, wenn der Sortierknoten 120 eine neue Transaktion empfängt, die von einer Transaktion in einem vorherigen Block des aktuellen Zeitabschnitts abhängig ist. In einem anderen Beispiel kann der Sortierknoten 120 einen neuen Zeitabschnitt erzeugen, wenn die Größe eines Zeitabschnitts erreicht ist. In einem anderen Beispiel kann der Sortierknoten 120 einen neuen Zeitabschnitt erzeugen, wenn eine Begrenzungszeit erreicht ist.
  • Die Blockchain-Peers 121 bis 124 können indessen die Blöcke vom Sortierknoten 120 empfangen, nachdem die Blöcke erzeugt wurden. In diesem Fall können die Blockchain-Peers 121 bis 124 die Blöcke nacheinander empfangen. Aus diesem Grund sind die Zeitabschnitte/ist die teilweise Sortierung der Blöcke im Blockchain-Ledger 110 nicht sofort ersichtlich. Wenn ein Blockchain-Peer (z.B. 121 bis 124) einen neuen übertragenen Block vom Sortierknoten 120 empfängt, kann der Blockchain-Peer prüfen, ob der Block in einen aktuellen Zeitabschnitt gehört, indem er prüft, ob ein vorheriger Hash-Wert in dem neuen Block eine Funktion von Hashes von Blöcken ist, die sich in einem vorherigen Zeitabschnitt befinden.
  • Wenn der vorherige Hash keine Funktion von Hashes des vorherigen Zeitabschnitts ist, kann der Blockchain-Peer prüfen, ob der neue Block zum nächsten Zeitabschnitt gehört. Wenn der neue Block in diesem Fall zum nächsten Zeitabschnitt gehört, sollte der vorherige Hash-Wert im neuen Block eine Funktion der Hashes der Blöcke im aktuellen Zeitabschnitt sein. Wenn der Hash-Wert erfolgreich überprüft werden kann, inkrementiert der Blockchain-Peer den aktuellen Zeitabschnitt-Zeiger und erzeugt einen neuen Zeitabschnitt im Blockchain-Ledger. Stimmt der Hash-Wert nicht überein, muss der Blockchain-Peer noch einige Blöcke im aktuellen Zeitabschnitt empfangen, von denen die Transaktionen in diesem Block potenziell abhängig sein können. Aufgrund der Redundanz in einem Blockchain-Netzwerk wird ferner davon ausgegangen, dass jeder Block von allen Peers empfangen wird. Der Blockchain-Peer kann den Block in einem Puffer speichern und in regelmäßigen Abständen überprüfen, ob er zum aktuellen Zeitabschnitt gehört.
  • Um die Transaktionsabhängigkeiten zu verfolgen, kann der Sortierknoten 120 einen Hash-Satz verwenden, um die Schlüssel der Transaktionen für jeden Block in einem Zeitabschnitt zu verfolgen. In diesem Beispiel könnte eine Transaktion zu einem Block hinzugefügt werden, wenn sie nur von Transaktionen abhängig ist, die in diesem Block oder in den Blöcken des vorherigen Zeitabschnitts/der vorherigen Zeitabschnitte vorhanden sind. Wenn indessen eine Transaktion nicht zu einem aktuellen Zeitabschnitt hinzugefügt werden kann, kann der Sortierknoten 120 entweder entscheiden, einen neuen Zeitabschnitt zu erzeugen und die Transaktion dort einzufügen, oder die Transaktion zurückhalten und andere Transaktionen verarbeiten, die zu dem aktuellen Zeitabschnitt hinzugefügt werden können. In diesem Fall kann der Sortierknoten 120 Maßnahmen ergreifen, um sicherzustellen, dass die zurückgehaltenen Transaktionen nicht blockiert werden (z.B. Begrenzung der Wartezeit, bevor eine Transaktion in einen Block aufgenommen wird).
  • Der Sortierknoten 120 kann für jeden Schlüssel separate Metadaten darüber speichern, welche Transaktionen (in welchem Block) gelesen und geändert werden. Dieses Verfahren ist hinsichtlich des Speicherbedarfs zwar teuer, die Metadaten können jedoch für genehmigungspflichtige Plattformen von Vorteil sein, bei denen die Peers dem Sortierknoten 120 vertrauen. Wenn ein Peer dem Blockchain-Netzwerk 100 beitritt, beginnt er, Blöcke zu empfangen. Im aktuellen Szenario muss ein Peer alle vorherigen Blöcke anfordern, bevor er Transaktionen vom aktuell empfangen Block validieren kann. In den beispielhaften Ausführungsformen kann ein Blockchain-Peer jedoch aufgrund des teilweisen Sortierens nur die Blöcke anfordern, von denen die Transaktionen im aktuellen Block abhängig sind.
  • Der vom Sortierknoten 120 erzeugte Hash-Satz kann einen Satz aller Schlüssel enthalten, die von den Transaktionen in den Blöcken gelesen oder geschrieben wurden, die zum aktuellen Zeitabschnitt gehören. Der Sortierknoten 120 kann diesen Satz in verschiedenen Datenstrukturen beispielsweise über den Hash-Satz oder über eine verknüpfte Liste oder über Anordnungen usw. speichern. In einigen Ausführungsformen kann der Sortierknoten 120 zwei Sätze speichern, darunter einen Zeitabschnitt-Lesesatz und einen Zeitabschnitt-Schreibsatz. Der Zeitabschnitt-Lesesatz kann Schlüssel enthalten, die von den Transaktionen gelesen wurden, die zu den Blöcken im aktuellen Zeitabschnitt gehören. Der Zeitabschnitt-Schreibsatz kann Schlüssel enthalten, auf die die Transaktionen, die zu den Blöcken im aktuellen Zeitabschnitt gehören, geschrieben haben. Wenn eine neue Transaktion eintrifft, kann der Sortierknoten 120 den Lese-/Schreibsatz mit dem Zeitabschnitt-Lesesatz und dem Zeitabschnitt-Schreibsatz vergleichen. Auf der Grundlage dieses Vergleichs kann der Sortierknoten 120 entscheiden, ob die Transaktion in dem Block platziert werden kann, der zu dem aktuellen Zeitabschnitt gehört, oder ob ein neuer Zeitabschnitt benötigt wird.
  • In einem weiteren Beispiel kann der Sortierknoten 120 ein gesteuertes azyklisches Diagramm (directed acyclic graph, DAG) der von den Clients gesendeten Transaktionen erzeugen. In diesem Beispiel können Transaktionen, die zu derselben verbundenen Komponente gehören, im selben Block oder in verschiedenen Blöcken über verschiedene Zeitabschnitte platziert werden. Darüber hinaus können Transaktionen, die zu verschiedenen Komponenten gehören, in demselben Zeitabschnitt (jedoch in verschiedenen Blöcken im selben Zeitabschnitt) platziert werden.
  • Die beispielhaften Ausführungsformen stellen erhebliche Vorteile gegenüber einer herkömmlichen linear sortierten Blockchain bereit. Die beispielhaften Ausführungsformen beschreiben zum Beispiel einen Sortierknoten, der ein teilweises Sortieren zwischen Transaktionen der Blockchain implementiert. Der Sortierknoten kann die Abhängigkeiten zwischen den Schlüsseln verschiedener Transaktionen identifizieren, die in einem Zeitraum eintreffen, und verschiedene Blöcke erzeugen und sie zusammen sortieren (z.B. ein Zeitabschnitt im Blockchain-Ledger), was gleichzeitig von einem beliebigen Peer ausgeführt werden kann. Der vorherige Hash eines Blocks umfasst eine Funktion von Hashes von Blöcken im vorherigen Zeitabschnitt (z.B. ein exklusives ODER der Hashes, zusammengesetzter Hash usw.). In einigen Ausführungsformen ist die Anzahl der Blöcke in einem Zeitabschnitt durch die maximal zulässige Anzahl von Blöcken in einem Zeitabschnitt oder durch eine Zeitüberschreitung begrenzt, nach der keine weiteren Blöcke zu den aktuellen Zeitabschnitten hinzugefügt werden können. In einigen Ausführungsformen stellt der Sortierknoten sicher, dass keine Transaktion blockiert wird, und sorgt gleichzeitig dafür, dass die Anzahl von Blöcken, die in einen Zeitabschnitt passen, maximiert wird.
  • 2A zeigt gemäß beispielhaften Ausführungsformen eine Konfiguration einer Blockchain-Architektur 200. Mit Bezug auf 2A kann die Blockchain-Architektur 200 bestimmte Blockchain-Elemente umfassen, zum Beispiel eine Gruppe von Blockchain-Knoten 202. Die Blockchain-Knoten 202 können einen oder mehrere Knoten 204 bis 210 umfassen (diese vier Knoten sind nur beispielhaft dargestellt). Diese Knoten sind an einer Reihe von Aktivitäten beteiligt, z.B. am Hinzufügen von Blockchain-Transaktionen und am Validierungsprozess (Konsens). Ein oder mehrere Blockchain-Knoten 204 bis 210 können Transaktionen auf der Grundlage einer Endorsement Policy bestätigen und einen Sortierdienst für alle Blockchain-Knoten in der Architektur 200 bereitstellen. Ein Blockchain-Knoten kann eine Blockchain-Authentifizierung initiieren und versuchen, in ein unveränderliches Blockchain-Ledger zu schreiben, das in der Blockchain-Schicht 216 gespeichert ist, von der eine Kopie auch in der zugrunde liegenden physischen Infrastruktur 214 gespeichert sein kann. Die Blockchain-Konfiguration kann eine oder mehrere Anwendungen 224 umfassen, die mit Anwendungsprogrammierschnittstellen (APIs) 222 verbunden sind, um auf gespeicherten Programm-/Anwendungscode 220 (z.B. Chaincode, Smart Contracts usw.) zuzugreifen und diesen auszuführen, der entsprechend einer von den Teilnehmern gewünschten individuellen Konfiguration erzeugt werden kann und der seinen eigenen Zustand aufrechterhalten, seine eigenen Vermögenswerte kontrollieren und externe Informationen empfangen kann. Dies kann als Transaktion implementiert und durch Anhängen an das Distributed Ledger auf allen Blockchain-Knoten 204 bis 210 implementiert werden.
  • Die Blockchain-Basis oder -Plattform 212 kann verschiedene Schichten von Blockchain-Daten, Diensten (z.B. kryptographische Vertrauensdienste, virtuelle Ausführungsumgebung usw.) und die zugrunde liegende physische Computerinfrastruktur umfassen, die dazu verwendet werden kann, neue Transaktionen zu empfangen und zu speichern und Auditoren, die auf Dateneinträge zugreifen wollen, den Zugriff bereitzustellen. Die Blockchain-Schicht 216 kann eine Schnittstelle zur Verfügung stellen, die den Zugriff auf die virtuelle Ausführungsumgebung bereitstellt, die erforderlich ist, um den Programmcode zu verarbeiten und die physische Infrastruktur 214 zu nutzen. Die kryptografischen Vertrauensdienste 218 können verwendet werden, um Transaktionen wie den Austausch von Vermögenswerten zu überprüfen und Informationen vertraulich zu halten.
  • Die Konfiguration der Blockchain-Architektur von 2A kann Programm-/Anwendungscode 220 über eine oder mehrere von der Blockchain-Plattform 212 zur Verfügung gestellte Schnittstellen und bereitgestellte Dienste verarbeiten und ausführen. Der Code 220 kann Vermögenswerte in der Blockchain kontrollieren. Der Code 220 kann beispielsweise Daten speichern und übertragen und von den Knoten 204 bis 210 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 die Lesedaten 226 von einer oder mehreren in der Blockchain-Schicht 216 enthaltenen Verarbeitungsentitäten (z.B. virtuellen Maschinen) verarbeitet werden, um Verarbeitungsergebnisse zu erzeugen, die in die Blockchain geschrieben werden und die die Schreibdaten 228 enthalten. Die physische Infrastruktur 214 kann zum Abrufen der hier beschriebenen Daten oder Informationen verwendet werden.
  • Ein Smart Contract kann über eine hochentwickelte Anwendung und Programmiersprache erzeugt und dann in einen Block in der Blockchain geschrieben werden. Der Smart Contract kann einen ausführbaren Code enthalten, der in einer Blockchain (z.B. einem verteilten Netzwerk von Blockchain-Peers) registriert, gespeichert und/oder repliziert wird. Eine Transaktion ist eine Ausführung des Codes des Smart Contract, die als Reaktion auf Bedingungen, die dem Smart Contract zugehörig sind, durchgeführt werden kann. Das Ausführen des Smart Contract kann (eine) vertrauenswürdige Änderung(en) eines Zustands eines digitalen Blockchain-Ledger auslösen. Die durch das Ausführen des Smart Contract verursachte(n) Änderung(en) des Blockchain-Ledger kann (können) automatisch im gesamten verteilten Netzwerk von Blockchain-Peers durch ein oder mehrere Konsensprotokolle repliziert werden.
  • Der Smart Contract kann Daten im Format von Schlüssel-Wert-Paaren in die Blockchain schreiben. Darüber hinaus kann der Code des Smart Contract die in einer Blockchain gespeicherten Werte lesen und in Operationen der Anwendung verwenden. Der Code des Smart Contract kann die Ausgabe verschiedener logischer Operationen in die Blockchain schreiben. Der Code kann dazu verwendet werden, eine temporäre Datenstruktur in einer virtuellen Maschine oder einer anderen Datenverarbeitungsplattform zu erzeugen. Daten, die in die Blockchain geschriebenen werden, können öffentlich sein und/oder verschlüsselt und als vertraulich behandelt werden. Die temporären Daten, die vom Smart Contract verwendet/erzeugt werden, werden von der bereitgestellten Ausführungsumgebung im Speicher gespeichert und dann gelöscht, sobald die für die Blockchain benötigten Daten identifiziert sind.
  • Ein Chaincode kann die Code-Interpretation eines Smart Contract umfassen und zusätzliche Funktionen enthalten. Wie hier beschrieben, kann es sich bei dem Chaincode um einen Programmcode handeln, der in einem Datenverarbeitungsnetzwerk implementiert wird, wo er von den Chain-Validierern im Rahmen eines Konsensverfahrens ausgeführt und validiert wird. Der Chaincode empfängt einen Hash und ruft aus der Blockchain einen Hash ab, der der Datenvorlage zugehörig ist, die durch die Verwendung eines zuvor gespeicherten Merkmalsextraktors erzeugt wurde. Stimmen die Hashes der Hash-Kennung und der aus den gespeicherten Kennungsvorlagedaten erzeugte Hash überein, sendet der Chaincode einen Autorisierungsschlüssel an den angeforderten Dienst. Der Chaincode kann Daten in die Blockchain schreiben, die den kryptografischen Einzelheiten zugehörig sind.
  • 2B zeigt ein Beispiel für einen Blockchain-Transaktionsablauf 250 zwischen Knoten der Blockchain gemäß einer beispielhaften Ausführungsform. Mit Bezug auf 2B kann der Transaktionsablauf einen Transaktionsvorschlag 291 umfassen, der von einem Anwendungs-Client-Knoten 260 an einen bestätigenden Peer-Knoten 281 gesendet wird. Der bestätigende Peer 281 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 292 auf den Vorschlag wird zusammen mit einer Bestätigungssignatur (falls genehmigt) an den Client 260 zurückgesendet. Der Client 260 stellt die Bestätigungen in den Transaktionsnutzdaten 293 zusammen und übertragt diese an einen Sortierdienstknoten 284. Der Sortierdienstknoten 284 gibt dann die sortierten Transaktionen als Blöcke an alle Peers 281 bis 283 in einem Kanal aus. Vor dem Festschreiben in der Blockchain kann jeder Peer 281 bis 283 die Transaktion validieren. So können die Peers beispielsweise die Endorsement Policy überprüfen, um sicherzustellen, dass die richtige Anzahl der angegebenen Peers die Ergebnisse signiert und die Signaturen anhand der Transaktionsnutzdaten 293 authentifiziert hat.
  • Mit erneutem Bezug auf 2B initiiert der Client-Knoten 260 die Transaktion 291, indem er eine Anforderung an den Peer-Knoten 281 erzeugt und sendet, bei dem es sich um einen Endorser handelt. Der Client 260 kann eine Anwendung umfassen, die ein unterstütztes Software-Entwicklungskit (software development kit - SDK) nutzt, das eine verfügbare API verwendet, um einen Transaktionsvorschlag zu erzeugen. Bei dem Vorschlag handelt es sich um eine Anforderung, eine Chaincode-Funktion aufzurufen, damit Daten gelesen und/oder in das Ledger geschrieben werden können (d.h., neue Schlüssel-Wert-Paare für die Vermögenswerte 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) dass der Sender (im Beispiel der Client 260) ordnungsgemäß autorisiert ist, die vorgeschlagene Operation auf diesem Kanal durchzuführen. Der bestätigende Peer-Knoten 281 kann die Eingaben des Transaktionsvorschlags als Argumente für die aufgerufene Chaincode-Funktion verwenden. Der Chaincode wird dann auf der Grundlage einer aktuellen Zustandsdatenbank ausgeführt, um Transaktionsergebnisse zu erzeugen, darunter ein Antwortwert, ein Lesesatz und ein Schreibsatz. Das Ledger wird zu diesem Zeitpunkt jedoch nicht aktualisiert. In Schritt 292 werden der Satz von Werten zusammen mit der Signatur des bestätigenden Peer-Knotens 281 als Antwort 292 auf den Vorschlag an das SDK des Clients 260 zurückgesendet, der die Nutzdaten für die Anwendung zur Nutzung parst.
  • Als Reaktion darauf überprüft/verifiziert die Anwendung des Clients 260 die Signaturen der bestätigenden Peers und vergleicht die Vorschlagsantworten, um zu ermitteln, ob die Vorschlagsantwort dieselbe ist. Würde der Chaincode nur das Ledger abfragen, würde die Anwendung die Antwort auf die Abfrage überprüfen und die Transaktion in der Regel nicht an den Sortierdienstknoten 284 senden. Beabsichtigt die Client-Anwendung, die Transaktion zum Aktualisieren des Ledger an den Sortierknotendienst 284 zu senden, entscheidet die Anwendung vor dem Senden, 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 stellt der Client 260 in Schritt 293 Bestätigungen zu einer Transaktion zusammen und sendet den Transaktionsvorschlag und die Antwort in einer Transaktionsnachricht an den Sortierknoten 284. Die Transaktion kann Lese-/Schreibsätze, die Signaturen der bestätigenden Peers und eine Kanal-ID enthalten. Der Sortierknoten 284 muss nicht den gesamten Inhalt einer Transaktion überprüfen, um seine Operation durchzuführen; stattdessen kann der Sortierknoten 284 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 werden vom Sortierknoten 284 an alle Peer-Knoten 281 bis 283 im Kanal übermittelt. Die Transaktionen 294 im Block werden validiert, um sicherzustellen, dass die Endorsement Policy erfüllt ist und dass keine Änderungen am Zustand des Ledger für die Variablen des Lesesatzes vorgenommen wurden, seit der Lesesatz durch das Ausführen der Transaktion erzeugt wurde. Transaktionen im Block werden als gültig oder ungültig gekennzeichnet. Darüber hinaus fügt jeder Peer-Knoten 281 bis 283 in Schritt 295 den Block an die Chain des Kanals an, und für jede gültige Transaktion werden die Schreibsätze in der aktuellen Zustandsdatenbank festgeschrieben. Es wird ein Ereignis ausgelöst, um die Client-Anwendung darüber zu informieren, dass die Transaktion (der Aufruf) unveränderlich an die Chain angehängt wurde, und um mitzuteilen, ob die Transaktion für gültig oder ungültig erklärt wurde.
  • 3A veranschaulicht ein Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk 300, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 302 eine Transaktion in der genehmigungspflichtigen Blockchain 304 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 306, z.B. einen Auditor, bereitstellen. Ein Blockchain-Netzwerkbetreiber 308 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 306 als „Auditor" und des Blockchain-Benutzers 302 als „Client“. Ein Auditor 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 310 kann Chaincode und clientseitige Anwendungen schreiben. Der Blockchain-Entwickler 310 kann Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 312 in Chaincode zu integrieren, kann der Entwickler 310 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel verbindet sich der Blockchain-Benutzer 302 über einen Peer-Knoten 314 mit der genehmigungspflichtigen Blockchain 304. Bevor der Peer-Knoten 314 mit den Transaktionen fortfährt, ruft er die Anmelde- und Transaktionszertifikate des Benutzers von einer Zertifizierungsstelle 316 ab, die Benutzerrollen und -genehmigungen verwaltet. In einigen Fällen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 304 Transaktionen durchführen zu können. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 312 ü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 318 nutzen.
  • 3B veranschaulicht ein weiteres Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk 320, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 322 eine Transaktion an die genehmigungspflichtige Blockchain 324 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 326, z.B. einen Auditor, bereitstellen. Ein Blockchain-Netzwerkbetreiber 328 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 326 als „Auditor“ und des Blockchain-Benutzers 322 als „Client“. Ein Auditor 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 330 schreibt Chaincode und clientseitige Anwendungen. Der Blockchain-Entwickler 330 kann Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 332 in Chaincode zu integrieren, kann der Entwickler 330 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel verbindet sich der Blockchain-Benutzer 322 über einen Peer-Knoten 334 mit dem Netzwerk. Bevor der Peer-Knoten 334 mit den Transaktionen fortfährt, ruft er die Anmelde- und Transaktionszertifikate des Benutzers von der Zertifizierungsstelle 336 ab. In einigen Fällen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 324 Transaktionen durchführen zu können. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 332 ü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 338 nutzen.
  • In einigen Ausführungsformen kann es sich bei der vorliegenden Blockchain um eine genehmigungsfreie Blockchain handeln. Im Gegensatz zu genehmigungspflichtigen Blockchains, für die eine Genehmigung zum Beitritt erforderlich ist, kann einer genehmigungsfreien Blockchain jeder beitreten. Um einer genehmigungsfreien Blockchain beizutreten, kann ein Benutzer beispielsweise eine persönliche Adresse erzeugen und beginnen, mit dem Netzwerk zu interagieren, indem er Transaktionen sendet und damit Einträge in das Ledger hinzufügt. Darüber hinaus haben alle Parteien die Möglichkeit, einen Knoten im System auszuführen und die Mining-Protokolle zum Überprüfen von Transaktionen zu verwenden.
  • 3C veranschaulicht einen Prozess 350 einer Transaktion, die von einer genehmigungsfreien Blockchain 352 verarbeitet wird und eine Mehrzahl von Knoten 354 umfasst. Ein Sender 356 möchte eine Zahlung oder ein beliebiges anderes werthaltiges Gut (z.B. eine Urkunde, medizinische Dokumente, einen Vertrag, eine Ware, eine Dienstleistung oder beliebige andere Vermögenswerte, die in einen digitalen Datensatz eingebunden werden können) über die genehmigungsfreie Blockchain 352 an einen Empfänger 358 senden. In einer Ausführungsform können sowohl die Sendeeinheit 356 als auch die Empfängereinheit 358 über digitale Brieftaschen (wallets) (die der Blockchain 352 zugehörig sind) verfügen, die Steuerungen der Benutzerschnittstelle und eine Anzeige der Transaktionsparameter bereitstellen. Daraufhin wird die Transaktion über die Blockchain 352 an die Knoten 354 übertragen. Je nach den Netzwerkparametern der Blockchain 352 überprüfen die Knoten 360 die Transaktion auf der Grundlage von Regeln (die vordefiniert oder dynamisch zugeordnet werden können), die von den Erzeugern der genehmigungsfreien Blockchain 352 aufgestellt wurden. Dies kann z.B. Überprüfen der Identität der beteiligten Parteien umfassen usw. Die Transaktion kann sofort überprüft werden oder in eine Warteschlange mit anderen Transaktionen gestellt werden, und die Knoten 354 ermitteln auf der Grundlage eines Satzes von Netzwerkregeln, ob die Transaktionen gültig sind.
  • In der Struktur 362 werden gültige Transaktionen zu einem Block zusammengefasst und mit einer Sperre (Hash) gesichert. Dieser Prozess kann durch Mining-Knoten unter den Knoten 354 durchgeführt werden. Mining-Knoten können zusätzliche Software speziell für das Mining und Erzeugen von Blöcken für die genehmigungsfreie Blockchain 352 verwenden. Jeder Block kann durch einen Hash (z.B. Bitzahl 256 usw.) identifiziert werden, der mit einem vom Netzwerk vereinbarten Algorithmus erzeugt wird. Jeder Block kann einen Kopf, einen Zeiger oder einen Verweis auf einen Hash des Kopfes des vorherigen Blocks in der Chain und eine Gruppe gültiger Transaktionen umfassen. Der Verweis auf den Hash des vorherigen Blocks ist dem Erzeugen der sicheren, unabhängigen Chain von Blöcken zugehörig.
  • Bevor Blöcke zur Blockchain hinzugefügt werden können, müssen die Blöcke validiert werden. Das Validieren der genehmigungsfreien Blockchain 352 kann ein Proof-of-Work (PoW) umfassen, bei der es sich um eine Lösung eines Rätsels handelt, das aus dem Kopf des Blocks abgeleitet wird. Zwar ist dies im Beispiel von 3C nicht dargestellt, doch ist ein weiterer Prozess zum Überprüfen eines Blocks der Proof-of-Stake. Im Gegensatz zum Proof-of-Work, bei dem der Algorithmus Miner belohnt, die mathematische Probleme lösen, wird beim Proof-of-Stake der Erzeuger eines neuen Blocks auf deterministische Weise ausgewählt, abhängig von seinem Vermögen, das auch als „Stake“ definiert ist. Anschließend wird ein ähnlicher Nachweis von dem ausgewählten Knoten durchgeführt.
  • Beim Mining 364 versuchen Knoten, den Block zu lösen, indem sie schrittweise Änderungen an einer Variablen vornehmen, bis die Lösung ein netzwerkweites Ziel erfüllt. Auf diese Weise wird der PoW erzeugt und stellt auf diese Weise richtige Antworten sicher. Mit anderen Worten: eine potenzielle Lösung muss nachweisen, dass zum Lösen des Problems Datenverarbeitungsressourcen eingesetzt wurden. Bei einigen Arten von genehmigungsfreien Blockchains können Miner für ein korrektes Mining eines Blocks mit etwas von Wert (z.B. Münzen usw.) belohnt werden.
  • In diesem Fall macht der PoW-Prozess zusammen mit dem Chaining von Blöcken Änderungen an der Blockchain extrem schwierig, da ein Angreifer alle nachfolgenden Blöcke ändern muss, damit die Änderungen an einem Block akzeptiert werden. Außerdem nimmt mit dem Mining neuer Blöcke die Schwierigkeit zu, einen Block zu verändern, und die Zahl der nachfolgenden Blöcke steigt. Bei der Verteilung 366 wird der erfolgreich validierte Block über die genehmigungsfreie Blockchain 352 verteilt, und alle Knoten 354 fügen den Block zu einer Mehrheits-Chain hinzu, bei der es sich um das auditierbare Ledger der genehmigungsfreien Blockchain 352 handelt. Außerdem wird der Wert in der vom Sender 356 gesendeten Transaktion in der digitalen Brieftasche der Empfängereinheit 358 hinterlegt oder in anderer Weise an sie übertragen.
  • 4A veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess 400A zum parallelen Validieren von Blöcken während einer Peer-Operation. Mit Bezug auf 4A kann ein Blockchain-Peer 420 während eines Boot- oder Wiederherstellungsprozesses gleichzeitig eine Mehrzahl von Blöcken 411 bis 414 abrufen, wenn er sein lokales Blockchain-Ledger 422 einschließlich einer Blockchain 424 und einer Zustandsdatenbank 426 wiederherstellt.
  • In den bestehenden Blockchain-Protokollen muss ein Blockchain-Peer beim Neustart standardmäßig viele Anwendungen starten und gleichzeitig die verschiedenen Blöcke der Blockchain nacheinander ausführen. Dies führt zu einer längeren Bootzeit, da die Blöcke sequenziell ausgeführt werden. In den beispielhaften Ausführungsformen kann der Blockchain-Peer 420 jedoch die Blöcke 411 bis 414 parallel ausführen, wodurch die zum Ausführen der Blockvalidierung für die gesamte Blockchain 410 erforderliche Zeit eingespart wird. Aufgrund des teilweisen Sortierens der Transaktionen in Zeitabschnitten steht die parallele Validierung mehrerer Blöcke zur Verfügung. Dies führt zu einer schnelleren Wiederherstellung von ausgefallenen Peers und/oder neuen Peers, die zum ersten Mal booten.
  • Der Blockchain-Peer 420 kann zum Beispiel mehrere physische Kerne verwenden, um den Wiederherstellungsprozess zu beschleunigen. Wenn der Blockchain-Peer 420 den Wiederherstellungsprozess beginnt, empfängt er über ein Klatschprotokoll (gossip protocol) Blöcke von einem anderen Peer (nicht dargestellt). Daraufhin kann der Blockchain-Peer 420 die Blöcke 411 bis 414 identifizieren, die zum selben Zeitabschnitt gehören. Diese zum selben Zeitabschnitt gehörenden Blöcke 411 bis 414 können mithilfe mehrerer Threads (die möglicherweise auf mehreren physischen Kernen in dem Blockchain-Peer 420 ausgeführt werden) gleichzeitig wiederhergestellt werden. Diese Parallelität zwischen den Blöcken verbessert die Wiederherstellungszeit im Vergleich zu aktuellen Systemen, die Blöcke in einer linearen Abfolge ausführen müssen.
  • Der Blockchain-Peer 420 kann zum Beispiel während des Prozesses 400A Blöcke von einem benachbarten Peer sammeln. Der Sammelprozess kann während eines Bootvorgangs oder Neustarts durchgeführt werden. Der Blockchain-Peer 420 kann auch sein lokales Ledger 422 initialisieren. Der Blockchain-Peer 420 kann die Blöcke 411 bis 414 gleichzeitig abrufen und die Blöcke 411 bis 414 gleichzeitig mithilfe verschiedener Kerne/Prozessoren unabhängig voneinander validieren (ohne zusätzliche Verarbeitung). Der Blockchain-Peer 420 kann die Zustandsdatenbank 426 parallel über die verschiedenen Kerne des Blockchain-Peers 420 aktualisieren. Dies führt zu einer Verkürzung der Wiederherstellungs-/Bootzeit des Peers. Bei teilweise in der Blockchain 410 sortierten Transaktionen ist es möglich, mehrere Blöcke, die zum selben Zeitabschnitt gehören, parallel ohne zusätzliche Verarbeitung zu validieren.
  • 4B veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess 400B zum Überspringen der Validierung von Blöcken während einer Abfrageabrufoperation. Mit Bezug auf 4B empfängt der Blockchain-Peer 420 eine Abfrage für eine in Block 415 gespeicherte Transaktion. Die Abfrage kann von einem Client 430 empfangen werden usw. Daraufhin kann der Blockchain-Peer 415 den Block 415 und vorherige Blöcke in der Blockchain 410 validieren. Anstatt jedoch alle Blöcke zu validieren, wie es in einem herkömmlichen Blockchain-Ledger geschieht, kann der Blockchain-Peer 420 Blöcke überspringen, die nicht von Block 415 abhängig sind und sie aus dem Validierungsprozess entfernen.
  • In den bestehenden Blockchain-Protokollen muss ein Peer-Knoten standardmäßig alle vorherigen Blöcke eines aktuellen Blocks validieren, bevor er auf die Abfragen zu den Schlüsseln des aktuellen Blocks antwortet. Dies führt zu einer längeren Antwortzeit auf die Abfrage, da die Blöcke sequenziell validiert werden. Die Schlüssel des aktuellen Blocks sind möglicherweise nicht vom vorherigen Block abhängig. Trotzdem müssen die vorherigen Blöcke in der Chain validiert werden, bevor auf die Abfrage geantwortet wird. Im Gegensatz dazu muss der Blockchain-Peer 420 im Prozess 400B nicht alle Vorgängerblöcke ausführen, bevor er auf eine Abfrage antwortet, wodurch die für die Antwort auf die Abfrage benötigte Zeit verkürzt wird. Der Blockchain-Peer 420 kann zum Beispiel Blöcke in einem Zeitabschnitt (i) überspringen, der den Block 415 der Abfrage enthält. Der Blockchain-Peer 420 kann ferner andere Blöcke (z.B. Zeitabschnitt (i-1)) überspringen, wenn diese Blöcke keine von Block 415 abhängige Transaktionen enthalten. Dieses Überspringen kann fortgesetzt werden, bis ein Block von Block 415 abhängig ist.
  • Der Blockchain-Peer 420 kann zum Beispiel eine Abfrage für eine Transaktion empfangen, die in Block 415 des Zeitabschnitts (i) gespeichert ist. Andere Blöcke im gleichen Zeitabschnitt (i) wie der aktuelle Block warten möglicherweise noch auf eine Validierung (oder wurden vom Blockchain-Peer 420 noch überhaupt nicht empfangen). Der Blockchain-Peer 420 kann diese Blöcke jedoch überspringen und nur den aktuellen Block validieren (ohne sich um die Validierung der anderen Blöcke im selben Zeitabschnitt zu kümmern), bevor er auf die Abfrage antwortet. Der Blockchain-Peer kann daher einen nächsten Block in der Chain vor dem Block 415 identifizieren und die restlichen Blöcke dazwischen überspringen. Dies führt zu einer schnelleren/verbesserten Antwortzeit auf Abfragen. Die Zustandsdatenbank 426 wird darüber hinaus nach der Validierung des aktuellen Blocks aktualisiert und eine Abfrageantwort wird bereitgestellt. Nachdem die übrigen Blöcke im selben Zeitabschnitt validiert wurden, wird die Zustandsdatenbank 426 entsprechend aktualisiert. Diese Aktualisierungen haben jedoch keine Auswirkungen auf die Abfrageantwort.
  • 4C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess 400C zum Zuordnen von Transaktionen zu DAGs zum Ermitteln paralleler Verarbeitungsoptionen veranschaulicht. Eine Organisation kann mehrere Peers in einem Blockchain-Netzwerk ausführen. In bestehenden Blockchain-Protokollen schreiben alle Peers in einer Organisation standardmäßig alle gültigen Transaktionen in der Zustandsdatenbank fest, indem sie die Transaktionen in jedem Block unabhängig und sequenziell ausführen. In einigen Ausführungsformen muss möglicherweise nur ein Anker-Peer-Knoten die Transaktionen in jedem Block sofort validieren, sodass die Durchlaufzeit der Transaktionen nicht beeinträchtigt wird. Andere Peers in jeder Organisation können die Blöcke zwischenspeichern und die Transaktionen nach Möglichkeit parallel ausführen. Die beispielhaften Ausführungsformen stellen einen Mechanismus bereit, mit dem Transaktionen unterteilt und parallel unter Verwendung mehrerer Blockchain-Peers einer Organisation auf der Grundlage des Konzepts teilweise sortierter Transaktionen ausgeführt werden können.
  • Mit Bezug auf den Prozess 400C in 4C kann der Blockchain-Peer 420 insbesondere die DAG-Strukturen 442, 444 und 446 aus den Transaktionen erzeugen, die in Blöcken in benachbarten Zeitabschnitten vorhanden sind, um die Parallelität auch über die Zeitabschnitte hinweg weiter zu nutzen. In dem Beispiel von 4C sind drei Blöcke im selben Zeitabschnitt angeordnet (Blöcke A, B und C). Eines der Merkmale von teilweise sortierten Transaktionen besteht darin, dass zwei Blöcke in einem selben Zeitabschnitt keine voneinander abhängigen Transaktionen enthalten können. Jeder Block kann jedoch abhängige Transaktionen enthalten. Jeder der Blöcke A, B und C kann zum Beispiel eine Reihe voneinander abhängigen Transaktionen enthalten. Der Blockchain-Peer 420 kann diese internen Abhängigkeiten mithilfe des DAG grafisch darstellen. In der DAG-Struktur stellen die Knoten Transaktionen dar, und die Verknüpfungen stellen Abhängigkeiten zwischen den Transaktionen dar. Der Blockchain-Peer 420 (oder ein anderer Dienst) kann darüber hinaus die parallel zu verarbeitenden Transaktionen auf der Grundlage der DAG-Strukturen 442, 444 und 446 aufteilen/unterteilen, sodass keine zwei voneinander abhängige Transaktionen gleichzeitig über mehrere Peers derselben Organisation ausgeführt werden.
  • Der Sortierknoten zum Beispiel kann dem Anker-Peer unter einer Mehrzahl von Peers einer Organisation jeden Block bereitstellen. In 4C stellen Blockchain-Peers 420 den Ankerknoten dar. Der Blockchain-Peer 420 kann jeden Block, den er empfängt, an alle anderen Blockchain-Peers (nicht dargestellt) in der Organisation senden. Der Blockchain-Peer kann darüber hinaus die Transaktionen eines Blocks in der richtigen Reihenfolge validieren (sodass für den Client keine Verzögerung mit Blick auf den Zustand der Transaktionsausführung entsteht). Diese Validierung kann auf der parallelen Validierung von Blöcken beruhen, die wie im Beispiel von 4A zum selben Zeitabschnitt gehören.
  • Andere Peers in der Organisation können die Blöcke ferner zwischenspeichern, bevor sie sie validieren, um zu ermitteln, ob eine parallele Validierung unter den Transaktionen möglich ist. Diese Peers können die Blöcke im Zeitabschnitt-i zwischenspeichern, um zu ermitteln, ob die Transaktionen in diesen Blöcken parallel zu den Transaktionen von den späteren Zeitabschnitten bis zum Zeitabschnitt-i ausgeführt werden können. Ein Peer kann ein DAG aus jedem Block vom Zeitabschnitt-i und einen Block vom Zeitabschnitt-(i+1) erzeugen, um zu ermitteln, ob dieser Block vom Zeitabschnitt-(i+1) zusammen mit den Blöcken vom Zeitabschnitt-1 validiert werden kann. Wenn es keine Abhängigkeiten gibt, kann ein Block vom Zeitabschnitt-(i+1) parallel zu den Blöcken im Zeitabschnitt-(i) ausgeführt werden. In diesem Fall besteht das Ziel darin, einen verbesserten Transaktionsdurchsatz zu erreichen. Und verschiedene Peers in derselben Organisation können diese unterschiedlichen Kombinationen von Parallelität auf DAG-Grundlage implementieren. Da verschiedene Peers wie in diesem Beispiel beschrieben unterschiedliche Parallelisierungsgrade implementieren, ist ein und derselbe Peer möglicherweise nicht in der Lage, die Abfrageantwort für verschiedene Abfragen schnellstmöglich zu berechnen. Und die eingehenden Abfragen können von jedem Peer einer Organisation beantwortet werden, der in der Lage ist, die Antwort auf die Abfrage schneller zu berechnen. Zu diesem Zweck kann der Blockchain-Peer 420 aus jedem Block A, B und C ein DAG erzeugen, um zu ermitteln, ob Transaktionen der drei Blöcke parallel ausgeführt werden können oder ob sie voneinander abhängig sind. In dem DAG 442 werden die voneinander abhängigen Transaktionen aus Block A gezeigt. Ebenso werden in dem DAG 444 und 446 Transaktionen gezeigt, die in den Blöcken B bzw. C voneinander abhängig sind.
  • In diesem Beispiel trägt ein DAG dazu bei, die Transaktionen in Gruppen aufzuteilen, sodass es keine Abhängigkeiten zwischen Transaktionen aus verschiedenen Gruppen gibt und somit eine Gruppe von Transaktionen parallel zu einer anderen Gruppe von Transaktionen validiert werden kann. Der Zweck der Validierung von Transaktionen mithilfe einer Analyse auf DAG-Grundlage besteht darin, die Transaktionen parallel zu validieren und so einen höheren Transaktionsdurchsatz zu erreichen.
  • 4D veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess 400D zum selektiven Validieren von Blöcken beim Speichern einer neuen Transaktion. In bestehenden Blockchain-Protokollen muss ein Peer-Knoten standardmäßig alle vorherigen Blöcke eines aktuellen Blocks validieren, bevor er Transaktionen des aktuellen Blocks validieren kann. Dies führt zu einem geringen Transaktionsdurchsatz. Die Schlüssel im vorherigen Block können insbesondere für einen Peer, der den aktuellen Block ausführt, nicht von Interesse sein (z.B. enthält der vorherige Block Transaktionen, die sich auf einen anderen Smart Contract im selben Netzwerk beziehen usw.). In den beispielhaften Ausführungsformen muss der Blockchain-Peer 420 möglicherweise nicht alle Vorgängerblöcke validieren, bevor er eine Transaktion im aktuellen Block validiert, was zu einem höheren Transaktionsdurchsatz führt.
  • Im Prozess 400D von 4D kann der Blockchain-Peer 420 die Details der vorherigen Transaktionen (zusammen mit ihren Blocknummern), von denen die aktuelle Transaktion abhängig ist, von einem Sortierknoten erhalten, was aufgrund der für den Sortierknoten verfügbaren Metadaten (z.B. Hash-Satz usw.) möglich ist. Der Blockchain-Peer 420 kann selektiv nur die abhängigen Vorgängertransaktionen der aktuellen Transaktion validieren, bevor er die aktuelle Transaktion validiert (und nicht auf die Validierung der anderen Transaktionen in den vorherigen Blöcken wartet). Dies führt zu einem verbesserten Transaktionsdurchsatz.
  • Wie mit Bezug auf 1B beschrieben, kann ein Sortierknoten eine Liste von Transaktionen enthalten (zusammen mit dem Block, in dem jede dieser Transaktionen vorhanden ist), die ein bestimmtes Schlüssel-Wert-Paar aktualisieren (z.B. die regelmäßige Aktualisierung des Zinssatzes (ROI)). Diese Metadaten werden im Sortierknoten gespeichert. Die Metadaten können eine Kennung jedes Schlüssels und seiner Abhängigkeiten enthalten. In diesem Fall kennt der Blockchain-Peer 420 die Schlüssel der Lese-/Schreibsätze einer Transaktion. Der Peer sucht daher die Metadaten (d.h., die selektiven Transaktionen und die Blöcke, die einen bestimmten Schlüssel aktualisieren) für jeden dieser Schlüssel beim Sortierknoten. In dem Beispiel von 4D empfängt der Blockchain-Peer 420 eine Transaktion für den Block 37. Auf der Grundlage des Hash-Satzes des Sortierknotens ermittelt der Blockchain-Peer 420 die Abhängigkeiten der Schlüssel der Transaktion von Block 37, die in den Blöcken 27, 17 und 16 enthalten sind. Anstatt alle Blöcke zu validieren, kann der Blockchain-Peer 420 daher selektiv nur die Blöcke 29, 17 und 16 validieren, die von der Transaktion in Block 37 abhängig sind.
  • In dem Beispiel von 4D kann der Blockchain-Peer 420 die Details der Vorgängertransaktionen (zusammen mit den Blocknummern, zu denen diese Transaktionen gehören) einer Transaktion im aktuellen Block aus den vom Sortierknoten gespeicherten Metadaten abrufen. Verschiedene Transaktionen in einem Block (oder zwischen Blöcken) können auf verschiedene Smart Contracts beruhen. Daher sind nicht alle Transaktionen miteinander verbunden.
  • In dem Beispiel von 4D kann der Blockchain-Peer 420 nur selektive Blöcke verarbeiten, die die abhängigen Transaktionen der aktuellen Transaktion in Block 37 enthalten. In diesem Fall werden auch die nichtabhängigen Transaktionen der aktuellen Transaktionen in diesen ausgewählten Blöcken nicht validiert. Damit entfällt die Notwendigkeit, die Transaktionsvalidierung aller Vorgängerblöcke der aktuellen Blöcke abzuschließen, was den Transaktionsdurchsatz erheblich verbessert.
  • 4E veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess 400E zum teilweisen Sortieren verschlüsselter Datenblöcke. In diesem Beispiel ist ein Sortierknoten 450 in der Lage, ein teilweises Sortieren von Blöcken zu implementieren, selbst wenn die Transaktionen verschlüsselt sind (und somit Abhängigkeiten verborgen sind). Aus Gründen des Datenschutzes könnten die Transaktionen beispielsweise zusammen mit den Lese-/Schreibsätzen verschlüsselt sein. Damit der Sortierknoten 450 die Transaktionen in Zeitabschnitten anordnen kann, kann jeder verschlüsselten Transaktion ein Schlüssel zugehörig sein. In diesem Fall können die Schlüssel von einem Transaktionssender wie einem Client, einem Peer oder Ähnlichem zugewiesen werden. Transaktionen, die einander zugehörig sind, können mit demselben Schlüssel gesendet werden. In dem Beispiel von 4E handelt es sich bei den Schlüsseln um „Qualität“, „Zahlung“ und „Versand“.
  • In diesem Beispiel sind die Schlüssel Transaktionen zugehörig und können unterschiedliche Schlüsselnamen enthalten. Transaktionen mit denselben Schlüsseln können voneinander abhängig sein. Transaktionen mit unterschiedlichen Schlüsseln sollten jedoch nicht voneinander abhängig sein. Die Lese-/Schreibsätze für eine Transaktion mit dem Qualitätsschlüssel sollten sich beispielsweise von den Lese-/Schreibsätzen für eine Transaktion mit dem ihr zugewiesenen Transportschlüssel unterscheiden. Gemäß verschiedenen Ausführungsformen kann der Sortierknoten 450 diese Schlüssel verwenden, um die Transaktionen im Falle verschlüsselter Transaktionen in Zeitabschnitten anzuordnen und die Vorteile der Parallelität zu nutzen. Der Sortierknoten 450 weist insbesondere Blöcke von Transaktionen mit dem Qualitätsschlüssel einem Cluster 452, Blöcke von Transaktionen mit dem Zahlungsschlüssel einem Cluster 454 und Blöcke von Transaktionen mit dem Versandschlüssel einem Cluster 456 zu. In diesem Fall sind alle Transaktionen verschlüsselt, der Sortierknoten kennt jedoch die Schlüsselcluster für jeden Block.
  • Gemäß verschiedenen Ausführungsformen kann der Sortierknoten 450 die Blöcke in Zeitabschnitten in einer Blockchain 460 anordnen. Insbesondere kann jeweils ein Block aus den Clustern 442, 444 und 446 parallel in demselben Zeitabschnitt angeordnet werden. Daher kann die maximale Anzahl von Blöcken in einem Zeitabschnitt der Anzahl der Schlüsselcluster entsprechen. In diesem Fall sind die Blöcke mit den Kennungen 462 versehen, die den Schlüssel der darin gespeicherten Transaktionen darstellen. Auf diese Weise können auch verschlüsselte Transaktionen in Zeitabschnitten angeordnet werden. Die Schlüssel werden auf Transaktionsbasis vom Sender der Transaktion zugewiesen. Der Sortierknoten 450 verwendet diese Schlüssel, um zu entscheiden, in welchen Zeitabschnitt ein Block von Transaktionen mit demselben Schlüssel fallen soll.
  • 5 veranschaulicht gemäß beispielhaften Ausführungsformen ein Verfahren 500 zum parallelen Validieren von Blöcken während einer Peer-Operation. Das Verfahren 500 kann beispielsweise während einer Peer-Wiederherstellungsoperation, einer Peer-Start-/Bootoperation oder Ähnlichem durchgeführt werden. Mit Bezug auf 5 kann das Verfahren in Schritt 510 Empfangen von Blöcken einer Blockchain von einem benachbarten Blockchain-Peer umfassen. Die Blöcke können zum Beispiel von einem Blockchain-Peer während eines Bootprozesses, eines Wiederherstellungsprozesses, eines Validierungsprozesses oder Ähnlichem empfangen werden. Die benachbarten Peers können demselben Blockchain-Netzwerk angehören wie der Peer, der die Blöcke empfängt. Wenn der Blockchain-Peer eine Wiederherstellungs- oder Bootoperation durchführt, kann das Verfahren in einigen Ausführungsformen weiterhin Initialisieren eines lokalen Blockchain-Ledger während eines Boot- und/oder Wiederherstellungsprozesses umfassen.
  • In Schritt 520 kann das Verfahren Identifizieren von zwei oder mehr Blöcken unter den empfangenen Blöcken umfassen, die zu einem gleichen Zeitabschnitt in der Blockchain gehören. Beispielsweise können die zwei oder mehr Blöcke nur Transaktionen enthalten, die nicht von den Transaktionen in den anderen Blöcken im Zeitabschnitt abhängig sind. Beispielsweise können ein erster und ein zweiter Block als nichtabhängige Blöcke betrachtet werden, wenn keine der Transaktionen im ersten Block von den Transaktionen im zweiten Block abhängig ist und umgekehrt. Es ist jedoch möglich, dass die Transaktionen im ersten Block von anderen Transaktionen im ersten Block abhängig sind. Ebenso können Transaktionen im zweiten Block von anderen Transaktionen im zweiten Block abhängig sein. Die Transaktionen weisen jedoch möglicherweise keine Abhängigkeiten zwischen den Blöcken auf.
  • In einigen Ausführungsformen kann das Identifizieren ein Erkennen auf der Grundlage der in den empfangenen Blöcken gespeicherten Hash-Werte umfassen, welche der empfangen Blöcke zum selben Zeitabschnitt gehören. In einigen Ausführungsformen kann das Identifizieren ein Feststellen umfassen, dass ein Block zu einem aktuellen Zeitabschnitt gehört, wenn ein unmittelbar vorhergehender Hash-Wert des Blocks eine Funktion von Hashes mehrerer Blöcke ist, die in einem unmittelbar vorhergehenden Zeitabschnitt in der Blockchain gespeichert sind.
  • In Schritt 530 kann das Verfahren paralleles Validieren der zwei oder mehr identifizierten Blöcke durch gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke umfassen. Darüber hinaus kann das Verfahren in Schritt 540 als Reaktion auf das Validieren der zwei oder mehr identifizierten Blöcke Speichern der zwei oder mehr identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers umfassen. Gemäß verschiedenen Ausführungsformen kann das Validieren gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke parallel (zeitlich überlappend) auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers umfassen.
  • In einigen Ausführungsformen kann das Verfahren weiterhin Identifizieren von zwei oder mehr anderen Blöcken in der Blockchain umfassen, die zu einem unmittelbar vorhergehenden Zeitabschnitt gehören. In diesem Beispiel kann das Verfahren weiterhin Validieren der zwei oder mehr anderen Blöcke, die zu dem unmittelbar vorhergehenden Zeitabschnitt gehören, parallel zu den zwei oder mehr identifizierten Blöcken, die zu demselben Zeitabschnitt gehören, umfassen, wenn die zwei oder mehr anderen Blöcke nicht von den zwei oder mehr identifizierten Blöcken abhängig sind.
  • 6A veranschaulicht ein Beispielsystem 600, das eine physische Infrastruktur 610 umfasst, die so konfiguriert ist, dass sie verschiedene Operationen gemäß beispielhaften Ausführungsformen durchführt. Mit Bezug auf 6A umfasst die physische Infrastruktur 610 ein Modul 612 und ein Modul 614. Das Modul 614 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 608 (in Modul 612) ausführen kann. Die Schritte/Operationen 608 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 610, das Modul 612 und das Modul 614 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 612 und das Modul 614 ein und dasselbe Modul sein.
  • 6B zeigt ein weiteres Beispielsystem 640, das so konfiguriert ist, dass es verschiedene Operationen gemäß beispielhaften Ausführungsformen durchführt. Mit Bezug auf 6B umfasst das System 640 ein Modul 612 und ein Modul 614. Das Modul 614 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 608 (in Modul 612) ausführen kann. Die Schritte/Operationen 608 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 610, das Modul 612 und das Modul 614 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 612 und das Modul 614 ein und dasselbe Modul sein.
  • 6C veranschaulicht ein Beispielsystem, 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 gemäß beispielhaften Ausführungsformen umsetzt. Mit Bezug auf 6C kann die Konfiguration 650 eine Datenübertragungssitzung, eine Vermögenswert-Ü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.
  • 6D veranschaulicht ein System 660, das eine Blockchain gemäß beispielhaften Ausführungsformen 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 aktuellen Zustands (World State) und ein Distributed Ledger enthält, das es den Clients 652 und 656 ermöglicht, Daten über den aktuellen Zustand 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.
  • Die vorstehenden Ausführungsformen können in Hardware, in einem von einem Prozessor ausgeführten Computerprogramm, in Firmware oder in einer Kombination der vorstehend Genannten implementiert werden. Ein Computerprogramm kann auf einem durch einen Computer lesbaren Medium wie beispielsweise einem Speichermedium ausgeführt werden. Ein Computerprogramm kann sich beispielsweise in einem Direktzugriffsspeicher („RAM“), einem Flash-Speicher, einem Nur-Lese-Speicher („ROM“), einem löschbaren programmierbaren Nur-Lese-Speicher („EPROM“), einem elektrisch löschbaren programmierbaren Nur-Lese-Speicher („EEPROM“), in Registern, auf einer Festplatte, auf einer Wechselplatte, in einem Compact-Disc-Nur-Lese-Speicher („CD-ROM“) oder auf jeder anderen in der Technik bekannten Form von Speichermedium befinden.
  • Ein beispielhaftes Speichermedium kann mit dem Prozessor verbunden werden, sodass der Prozessor Informationen aus dem Speichermedium lesen und in das Speichermedium schreiben kann. Alternativ kann das Speichermedium in den Prozessor integriert sein. Der Prozessor und das Speichermedium können sich in einer anwendungsspezifischen integrierten Schaltung („ASIC“) befinden. Alternativ können der Prozessor und das Speichermedium als einzelne Komponenten vorliegen.
  • 7A veranschaulicht einen Prozess 700, bei dem gemäß beispielhaften Ausführungsformen ein neuer Block zu einem Distributed Ledger 720 hinzugefügt wird, und 7B veranschaulicht gemäß beispielhaften Ausführungsformen den Inhalt einer neuen Datenblockstruktur 730 für eine Blockchain. Mit Bezug auf 7A können Clients (nicht dargestellt) Transaktionen an die Blockchain-Knoten 711, 712 und/oder 713 senden. Clients können Anweisungen sein, die von einer beliebigen Quelle empfangen werden, um eine Aktivität in der Blockchain 720 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 711, 712 und 713) können einen Zustand des Blockchain-Netzwerks und eine Kopie des Distributed Ledger 720 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 Leder 720 festschreiben. In diesem Beispiel können die Blockchain-Knoten 711, 712 und 713 die Rolle eines Endorser-Knotens, eines festschreibenden Knotens oder beider durchführen.
  • Das Distributed Ledger 720 umfasst eine Blockchain, die unveränderliche, sequenzierte Datensätze in Blöcken speichert, und eine Zustandsdatenbank 724 (aktueller Zustand), in der ein aktueller Zustand der Blockchain 722 gespeichert ist. Pro Kanal kann ein Distributed Ledger 720 vorhanden sein, und jeder Peer unterhält seine eigene Kopie des Distributed Ledger 720 für jeden Kanal, dessen Mitglied er ist. Die Blockchain 722 ist ein Transaktionsprotokoll, 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 7B dargestellt. Die Verknüpfung der Blöcke (in 7A 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 werden alle Transaktionen in der Blockchain 722 sequenziert und kryptografisch miteinander verknüpft, 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 722 außerdem jede Transaktion, die vor ihm stattgefunden hat, dar. Die Blockchain 722 kann in einem Peer-Dateisystem (lokaler oder angeschlossener Speicher) gespeichert werden, das eine Append-only-Blockchain-Arbeitslast unterstützt.
  • Der aktuelle Zustand der Blockchain 722 und des Distributed Ledger 722 kann in der Zustandsdatenbank 724 gespeichert werden. In diesem Fall stellen die Daten des aktuellen Zustands die neuesten Werte für alle jemals im Chain-Transaktionsprotokoll der Blockchain 722 enthaltenen Schlüssel dar. Chaincode-Aufrufe führen Transaktionen auf der Grundlage des aktuellen Zustands in der Zustandsdatenbank 724 aus. Damit diese Chaincode-Interaktionen höchst effizient sind, werden die aktuellen Werte aller Schlüssel in der Zustandsdatenbank 724 gespeichert. Die Zustandsdatenbank 724 kann eine indizierte Ansicht des Transaktionsprotokolls der Blockchain 722 enthalten, und kann daher jederzeit aus der Chain neu erzeugt werden. Die Zustandsdatenbank 724 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, erzeugen die bestätigenden 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 Policies aufweisen. Bestätigte Transaktionen werden von der Client-Anwendung an den Sortierdienst 710 weitergeleitet.
  • Der Sortierdienst 710 nimmt bestätigte Transaktionen an, ordnet sie in einem Block an und übermittelt die Blöcke an die festschreibenden Peers. Beispielsweise kann der Sortierdienst 710 einen neuen Block initiieren, wenn ein Schwellenwert an Transaktionen erreicht wurde, ein Zeitgeber abgelaufen ist oder eine andere Bedingung vorliegt. In dem Beispiel von 7A handelt es sich bei dem Blockchain-Knoten 712 um einen festschreibenden Peer, der einen neuen Datenblock 730 zum Speichern in der Blockchain 720 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 710 kann aus einer Gruppe von Sortierern zusammengesetzt sein. Der Sortierdienst 710 verarbeitet keine Transaktionen und Smart Contracts und führt auch nicht das gemeinsam genutzte Ledger. Vielmehr kann der Sortierdienst 710 die bestätigten Transaktionen annehmen, und er legt die Reihenfolge fest, in der diese Transaktionen im Distributed Ledger 720 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 werden in einer konsistenten Reihenfolge in das Distributed Ledger 720 geschrieben. Die Reihenfolge der Transaktionen wird festgelegt, um sicherzustellen, dass die Aktualisierungen der Zustandsdatenbank 724 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 720 in diesem Beispiel den Sortiermechanismus wählen, der am besten zu diesem Netzwerk passt.
  • Wenn der Sortierdienst 710 einen neuen Datenblock 730 initialisiert, kann der neue Datenblock 730 an die festschreibenden Peers (z.B. die Blockchain-Knoten 711, 712 und 713) übertragen werden. Daraufhin überprüft jeder festschreibende Peer die Transaktion im neuen Datenblock 730, indem er sicherstellt, dass der Lese- und der Schreibsatz immer noch mit dem aktuellen Zustand (World State) in der Zustandsdatenbank 724 ü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 Zustand in der Zustandsdatenbank 724 identisch sind. Wenn der festschreibende Peer die Transaktion validiert, wird die Transaktion in die Blockchain 722 im Distributed Ledger 720 geschrieben, und die Zustandsdatenbank 724 wird mit den Schreibdaten aus dem Lese-Schreib-Satz aktualisiert. Wenn eine Transaktion nicht erfolgreich ist, d.h., wenn der festschreibende Peer feststellt, dass der Lese-Schreib-Satz nicht mit dem aktuellen Zustand (World State) in der Zustandsdatenbank 724 übereinstimmt, ist die in einem Block zusammengefasste Transaktion zwar immer noch in diesem Block enthalten, aber sie ist als ungültig gekennzeichnet, und die Zustandsdatenbank 724 wird nicht aktualisiert.
  • Mit Bezug auf 7B kann ein neuer Datenblock 730 (auch als Datenblock bezeichnet), der in der Blockchain 722 des Distributed Ledger 720 gespeichert wird, mehrere Datensegmente enthalten, z.B. einen Blockkopf 740, Blockdaten 750 und Block-Metadaten 760. Es sei darauf hingewiesen, dass die verschiedenen dargestellten Blöcke und ihr Inhalt, z.B. der neue Datenblock 730 und sein Inhalt, die in 7B gezeigt werden, lediglich Beispiele sind und den Anwendungsbereich der beispielhaften Ausführungsformen nicht einschränken sollen. Der neue Datenblock 730 kann Transaktionsinformationen von N Transaktionen (z.B. 1, 10, 100, 500, 1000, 2000, 3000 usw.) in den Blockdaten 750 speichern.
  • Gemäß verschiedenen Ausführungsformen kann der neue Datenblock 730 eine Verknüpfung zu einem vorherigen Zeitabschnitt in der Blockchain im Blockkopf 740 enthalten. Der Blockkopf 740 kann insbesondere eine Hash-Funktion 742 eines vorherigen Zeitabschnitts von Blöcken enthalten. In einigen Ausführungsformen kann die Hash-Funktion 742 ein XOR von Hashes eines Satzes von Blöcken (oder Hashes von Dokumenten im Satz von Blöcken) enthalten, die in dem unmittelbar vorhergehenden Zeitabschnitt enthalten sind. In einem weiteren Beispiel kann die Hash-Funktion 742 einen zusammengesetzten Hash von Hashes eines Satzes von Blöcken (oder Hashes von Dokumenten im Satz von Blöcken) enthalten, die in einem vorherigen Zeitabschnitt enthalten sind.
  • Der Blockkopf 740 kann auch eine eindeutige Blocknummer, einen Hash der Blockdaten 750 des neuen Datenblocks 730 und Ähnliches umfassen. Die Blocknummer des neuen Datenblocks 730 kann eindeutig sein und in verschiedenen Reihenfolgen zugewiesen werden, z.B. in einer inkrementellen/sequenziellen Reihenfolge, die bei Null beginnt.
  • In den Blockdaten 750 können Transaktionsinformationen jeder Transaktion gespeichert werden, die im neuen Datenblock 730 aufgezeichnet werden. Die Transaktionsdaten können zum Beispiel eine Art der Transaktion, eine Version, einen Zeitstempel, eine Kanal-ID des Distributed Ledger 720, eine Transaktions-ID, eine Epoche, die Sichtbarkeit von Nutzdaten, einen Chaincode-Pfad (tx implementieren), einen Chaincode-Namen, eine Chaincode-Version, eine Eingabe (Chaincode und Funktionen), eine Client-ID (Erzeuger-ID) wie einen öffentlichen Schlüssel und ein Zertifikat, eine Signatur des Clients, die Identitäten von Endorsers, Endorser-Signaturen, einen Vorschlags-Hash, Chaincode-Ereignisse, einen Antwortstatus, einen Namensbereich, einen Lesesatz (Liste der von der Transaktion gelesenen Schlüssel und Versionen usw.), einen Schreibsatz (Liste der Schlüssel und Werte usw.), einen Anfangsschlüssel, einen Endschlüssel, eine Schlüsselliste, eine Zusammenfassung der Merkle-Baum-Abfrage und/oder Ähnliches enthalten. Die Transaktionsdaten können für jede der N Transaktionen gespeichert werden.
  • In den Block-Metadaten 760 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 710 hinzugefügt werden. In der Zwischenzeit kann ein Festschreibender des Blocks (z.B. der Blockchain-Knoten 712) 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 750 entspricht, sowie einen Validierungscode, der kennzeichnet, ob eine Transaktion gültig oder ungültig war. In einigen Ausführungsformen, die in 7B allerdings nicht dargestellt sind, können die Block-Metadaten 760 Metadaten der empfohlenen Smart Contracts speichern.
  • 7C veranschaulicht eine Ausführungsform einer Blockchain 770 für digitalen Inhalt gemäß den hier beschriebenen Ausführungsformen. Der digitale Inhalt kann eine oder mehrere Dateien und zugehörige Informationen enthalten. Die Dateien können Medien, Bilder, Video, Audio, Text, Links, Grafiken, Animationen, Webseiten, Dokumente oder andere Formen mit digitalem Inhalt umfassen. Die unveränderlichen Append-only-Aspekte der Blockchain dienen als Schutz für die Integrität, Gültigkeit und Echtheit des digitalen Inhalts, 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 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-Werts eines relevanten Blocks und anschließendes Suchen dieses Hash-Werts im Speicherbereich, der in Übereinstimmung mit den 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 770 eine Anzahl von Blöcken 7781, 7782, ... 778N, die in einer geordneten Folge kryptografisch verknüpft sind, wobei N ≥ 1 ist. Bei der Verschlüsselung, die verwendet wird, um die Blöcke 7781, 7782, ... 778N 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 7781, 7782, ... 778N 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ört, 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 7781, 7782, ..., 778N 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 7781, 7782, ..., 778N in der Blockchain umfasst einen Kopf, eine Version der Datei und einen Wert. Der Kopf und der Wert sind für jeden Block unterschiedlich, 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 7781 in der Blockchain wird als Genesis-Block bezeichnet und umfasst den Kopf 7721, die Originaldatei 7741 und einen Anfangswert 7761. 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 7781 zusammen und auf einmal gehasht werden, oder jede Information oder ein Teil der Informationen im ersten Block 7781 kann separat gehasht werden, und dann kann ein Hash der separat gehashten Teile durchgeführt werden.
  • Der Kopf 7721 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 7741 und/oder der Blockchain zugehörig sind. Der Kopf 7721 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 7782 bis 778N in der Blockchain verweist der Kopf 7721 im Genesis-Block nicht auf einen vorherigen Block, da es keinen vorherigen Block gibt.
  • Bei der Originaldatei 7741 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 7741 wird über die Schnittstelle des Systems von der Einheit, der Medienquelle oder dem Knoten empfangen. Der Originaldatei 7741 sind Metadaten zugehörig, 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 7781 enthalten sein, der der Originaldatei 7741 zugehörig ist.
  • Der Wert 7761 im Genesis-Block ist ein Anfangswert, der auf der Grundlage eines oder mehrerer eindeutiger Attribute der Originaldatei 7741 erzeugt wird. In einer Ausführungsform können das eine oder die mehreren eindeutigen Attribute den Hash-Wert für die Originaldatei 7741, Metadaten für die Originaldatei 7741 und andere der Datei zugehörige Informationen umfassen. In einer Implementierung kann der Anfangswert 7761 auf den folgenden eindeutigen Attributen beruhen:
    • 1) SHA-2 berechneter Hash-Wert für die Originaldatei
    • 2) ID der ursprünglichen Einheit
    • 3) Anfangszeitstempel für die Originaldatei
    • 4) Anfänglicher Speicherort der Originaldatei
    • 5) Blockchain-Netzwerk-Mitglieder-ID für Software zur aktuellen Kontrolle der Originaldatei und der zugehörigen Metadaten
  • Die anderen Blöcke 7782 bis 778N in der Blockchain verfügen ebenfalls über Köpfe, Dateien und Werte. Im Gegensatz zum ersten Block 7721 umfasst jedoch jeder der Köpfe 7722 bis 772N 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 780 angezeigt, um eine überprüfbare und unveränderliche Chain-of-Custody herzustellen.
  • Jeder der Köpfe 7722 bis 772N 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 7742 bis 774N 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 7762 bis 776N 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 wurden, 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.
    • 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)
    • b) Neuer Speicherort für die Datei
    • c) Neue Metadaten identifiziert, die der Datei zugehörig sind
    • d) Übertragung des Zugriffs auf oder der Kontrolle über die Datei von einem Blockchain-Teilnehmer auf einen anderen Blockchain-Teilnehmer
  • 7D zeigt eine Ausführungsform eines Blocks, die gemäß einer Ausführungsform die Struktur der Blöcke in der Blockchain 790 darstellen kann. Der Block Blocki umfasst einen Kopf 772i, eine Datei 774i und einen Wert 776i.
  • Der Kopf 772i umfasst einen Hash-Wert eines vorherigen Blocks Blocki-1 und zusätzliche Verweisinformationen, bei denen es sich z.B. um beliebige hier beschriebene Arten von Informationen (z.B. Kopf-Informationen mit Verweisen, Merkmalen, Parametern usw.) handeln kann. Alle Blöcke verweisen auf den Hash eines vorherigen Blocks, außer natürlich des Genesis-Blocks. 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 774i umfasst eine Mehrzahl von Daten, z.B. Daten 1, Daten 2, ..., Daten N in Folge. Die Daten sind mit den Metadaten 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 beschriebenen Ausführungsform beschrieben. Zusätzlich zu den Metadaten können alle Daten mit einem Verweis REF1, REF2, ..., REFN auf früheren 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 nicht mehr geändert werden, ohne dass sich der Hash ändert, der zum Invalidieren leicht identifiziert werden kann. Die Metadaten erzeugen somit ein Datenprotokoll mit Informationen, auf die Teilnehmer der Blockchain zur Verwendung zugreifen können.
  • Der Wert 776i ist ein Hash-Wert oder ein anderer Wert, 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 770 gebildet ist, kann die unveränderliche Chain-of-Custody 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 wird auf der Grundlage der Art des Verschlüsselns, die in jedem Block verwendet wurde, durchgeführt. 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 sind miteinander durch eine mathematische Beziehung verbunden. 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 wird geheim gehalten und zum digitalen Signieren von Nachrichten verwendet, die an andere Blockchain-Teilnehmer gesendet werden. Die Signatur ist in der Nachricht enthalten, 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.
  • Das Erzeugen eines Schlüsselpaares ist vergleichbar mit dem Erzeugen eines Kontos in der Blockchain, ohne dass man sich jedoch irgendwo registrieren muss. Außerdem wird jede Transaktion, die in der Blockchain ausgeführt wird, vom Sender mit seinem privaten Schlüssel digital signiert. Diese Signatur stellt sicher, 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 8A und 8B veranschaulichen weitere Beispiele für Anwendungsfälle einer Blockchain, die hier einbezogen und verwendet werden können. 8A veranschaulicht insbesondere ein Beispiel 800 für eine Blockchain 810, in der Daten zum maschinellen Lernen (künstliche Intelligenz) gespeichert werden. Maschinelles Lernen stützt sich 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 8A erstellt und implementiert eine Host-Plattform 820 ein Modell für maschinelles Lernen zum vorausschauenden Überwachen von Vermögenswerten 830. Bei der Host-Plattform 820 kann es sich in diesem Fall um eine Cloud-Plattform, einen Industrieserver, einen Webserver, einen Personal Computer, eine Benutzereinheit oder Ähnliches handeln. Bei den Vermögenswerten 830 kann es sich um jede Art von Vermögenswert (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 Vermögenswerte 830 sind immaterielle Vermögenswerte wie z.B. Aktien, Währungen, digitale Zahlungsmittel, Versicherungen oder Ähnliches.
  • Die Blockchain 810 kann verwendet werden, um sowohl einen Trainingsprozess 802 des Modells für maschinelles Lernen als auch einen Vorhersageprozess 804 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 802 beispielsweise von den Vermögenswerten 830 selbst (oder einer zwischengeschalteten Einheit, nicht dargestellt) in der Blockchain 810 gespeichert werden. Dies kann die Zeit, die die Host-Plattform 820 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 810 übertragen werden. Durch Verwenden der Blockchain 810, um die Sicherheit von und das Eigentum an den gesammelten Daten zu gewährleisten, können Smart Contracts die Daten von den Vermögenswerten 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 Vermögenswerte 830 gemeinsam Daten nutzen.
  • Die gesammelten Daten können auf der Grundlage eines Konsensmechanismus in der Blockchain 810 gespeichert werden. Der Konsensmechanismus bezieht (genehmigungspflichtige Knoten) ein, um sicherzustellen, dass die aufgezeichneten Daten überprüft und korrekt sind. Die aufgezeichneten Daten werden mit einem Zeitstempel versehen, kryptografisch signiert und sind unveränderbar. 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 820 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 802 können die verschiedenen Trainings- und Testschritte (und die zugehörigen Daten) von der Host-Plattform 820 in der Blockchain 810 gespeichert werden. Jede Verfeinerung des Modells für maschinelles Lernen (z.B. Änderungen bei den Variablen, Gewichten usw.) kann in der Blockchain 810 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 820 ein fertig trainiertes Modell erreicht hat, kann das resultierende Modell in der Blockchain 810 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 804 kann das Modell für maschinelles Lernen beispielsweise für die zustandsorientierte Instandhaltung (condition-based maintenance - CBM) eines Vermögenswerts, z.B. eines Flugzeugs, einer Windturbine, einem Gerät im Gesundheitswesen und Ähnliches, verwendet werden. In diesem Beispiel können die vom Vermögenswert 830 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 820 getroffen werden, können in der Blockchain 810 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 Vermögenswerts 830 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 820 in der Blockchain 810 gespeichert werden. In einer Ausführungsform können die hier beschriebenen und/oder abgebildeten Funktionen und/oder Maßnahmen in der Blockchain 810 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 wird dann verschlüsselt, um einen neuen Hash für den neuen Block zu erzeugen. Dieser wird der nächsten Liste von Transaktionen hinzugefügt, 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 viel schneller (Tausende Male schneller) und stellen daher eine viel größere Gefahr dar.
  • 8B zeigt ein Beispiel 850 für eine quantensichere Blockchain 852, 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 werden Informationen mithilfe von Quantenteilchen wie Photonen übertragen, 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 8B gibt es die vier Benutzer 854, 856, 858 und 860. Jedes Benutzerpaar kann einen geheimen Schlüssel 862 (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 862 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 852 beruht auf den beiden Verfahren (i) Erzeugen von Transaktionen und (ii) Bilden von Blöcken, 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 authentifizieren zwei Parteien (d.h. ein Paar der Benutzer 854 bis 860) die Transaktion durch Bereitstellen ihres gemeinsam genutzten geheimen Schlüssels 862 (QKD). Diese Quantensignatur kann an jede Transaktion angehängt werden, wodurch sie äußerst schwer zu fälschen ist. Jeder Knoten prüft seine Einträge anhand einer lokalen Kopie der Blockchain 852, 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 852 hinzugefügt werden. In einer Ausführungsform können die hier beschriebenen und/oder abgebildeten Funktionen und/oder Maßnahmen in der Blockchain 852 oder in Bezug auf diese durchgeführt werden.
  • 9 veranschaulicht ein Beispielsystem 900, das eine oder mehrere der hier beschriebenen und/oder abgebildeten Ausführungsformen unterstützt. Das System 900 weist ein Computersystem/einen Server 902 auf, das/der mit zahlreichen anderen universellen oder speziellen Datenverarbeitungssystem-Umgebungen oder Konfigurationen funktionsfähig ist. Beispiele für bekannte Datenverarbeitungssysteme, Umgebungen und/oder Konfigurationen, die für die Nutzung mit dem Computersystem/Server 902 geeignet sein können, sind unter anderem, ohne auf diese beschränkt zu sein, PersonalComputer-Systeme, Server-Computer-Systeme, schlanke Clients, leistungsintensive Clients, Hand- oder Laptop-Einheiten, Mehrprozessorsysteme, Systeme auf der Grundlage von Mikroprozessoren, Beistellgeräte, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Großrechnersysteme und verteilte Cloud-Computing-Umgebungen, die jedes beliebige der vorstehend genannten Systeme oder Einheiten und Ähnliches enthalten.
  • Das Computersystem/der Server 902 kann im allgemeinen Kontext von durch ein Computersystem ausführbaren Anweisungen beschrieben werden, z.B. Programmmodule, die von einem Computersystem ausgeführt werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. enthalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server 902 kann in verteilten Cloud-Computing-Umgebungen eingesetzt werden, wo die Aufgaben von entfernt angeordneten Verarbeitungseinheiten durchgeführt werden, die über ein Datenübertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernt angeordneten Computersystem-Speichermedien befinden, darunter Speichereinheiten mit Arbeitsspeichern.
  • Wie in 9 gezeigt, wird das Computersystem 902 im Cloud-Computing-Knoten 900 in Form einer universellen Datenverarbeitungseinheit dargestellt. Bei den Komponenten des Computersystems/Servers 902 kann es sich - ohne auf diese beschränkt zu sein - um einen oder mehrere Prozessoren oder Verarbeitungseinheiten 904, einen Systemspeicher 906 und einen Bus handeln, der verschiedene Systemkomponenten, darunter den Systemspeicher 906, mit dem Prozessor 904 verbindet.
  • Der Bus stellt eine oder mehrere von beliebigen mehreren Arten von Busstrukturen dar, darunter einen Speicherbus oder eine Speichersteuereinheit, einen Peripheriebus, eine AGP-Schnittstelle (Accelerated Graphics Port) und einen Prozessor oder lokalen Bus, der eine beliebige aus einer Vielfalt von Busarchitekturen nutzt. Beispielsweise und nicht einschränkend enthalten solche Architekturen einen Industry-Standard-Architecture(ISA)-Bus, einen Micro-Channel-Architecture(MCA)-Bus, einen Enhanced-ISA(EISA)-Bus, einen lokalen Video-Electronics-Standards-Association(VESA)-Bus und einen Peripheral-Component-Interconnects(PCI)-Bus.
  • Das Computersystem/der Server 902 umfasst in der Regel eine Vielfalt von durch einen Computer lesbaren Medien. Bei diesen Medien kann es sich um beliebige verfügbare Medien handeln, auf die das Computersystem/der Server 902 zugreifen kann, darunter flüchtige und nichtflüchtige Medien, wechselbare und nichtwechselbare Medien. In einer Ausführungsform implementiert der Systemspeicher 906 die Ablaufpläne der anderen Figuren. Der Systemspeicher 906 kann vom Computersystem lesbare Medien in Form von flüchtigen Speichern, z.B. Direktzugriffsspeicher (RAM) 910 und/oder Cache 912, enthalten. Das Computersystem/der Server 902 kann ferner weitere wechselbare/nichtwechselbare, flüchtige/nichtflüchtige Computersystem-Speichermedien enthalten. Nur beispielhaft kann das Speichersystem 914 bereitgestellt werden, um ein nichtwechselbares, nichtflüchtiges magnetisches Medium auszulesen und zu beschreiben (nicht dargestellt und üblicherweise als „Festplatte“ bezeichnet). Obwohl nicht dargestellt, können ein Laufwerk für magnetische Speicherplatten zum Auslesen und Beschreiben einer wechselbaren, nichtflüchtigen magnetischen Speicherplatte (z.B. „Diskette“) und ein Laufwerk für optische Speicherplatten zum Auslesen oder Beschreiben einer wechselbaren, nichtflüchtigen optischen Speicherplatte wie einem CD-ROM, DVD-ROM und andere optische Medien bereitgestellt werden. In solchen Fällen kann jedes über eine oder mehrere Datenmedien-Schnittstellen mit dem Bus verbunden sein. Wie nachstehend weiter dargestellt und beschrieben, kann der Speicher 906 mindestens ein Programmprodukt mit einem (z.B. mindestens einem) Satz von Programmmodulen enthalten, die so konfiguriert sind, dass sie die Funktionen verschiedener Ausführungsformen der Anwendung ausführen.
  • Das Programm/Dienstprogramm 916 mit (mindestens) einem Satz von Programmmodulen 918 kann beispielsweise und nicht einschränkend im Speicher 906 gespeichert sein, ebenso ein Betriebssystem, ein oder mehrere Anwendungsprogramme, weitere Programmmodule und Programmdaten. Das Betriebssystem, ein oder mehrere Anwendungsprogramme, weitere Programmmodule und Programmdaten oder eine Kombination daraus können jeweils eine Implementierung einer Netzwerkumgebung enthalten. Die Programmmodule 918 führen im Allgemeinen die Funktionen und/oder Methodiken verschiedener Ausführungsformen der hier beschriebenen Anwendung aus.
  • Für den Fachmann ist ersichtlich, dass Aspekte der vorliegenden Anwendung als System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Aspekte der vorliegenden Anwendung können daher die Form einer kompletten Hardware-Ausführung, einer kompletten Software-Ausführung (darunter Firmware, residente Software, Mikrocode usw.) oder eine Ausführungsform haben, bei der Hardware- und Software-Aspekte kombiniert sind, die allgemein hier als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Aspekte der vorliegenden Anwendung können des Weiteren die Form eines Computerprogrammprodukts haben, das in einem oder mehreren durch einen Computer lesbaren Medien ausgeführt ist, die über einen darin enthaltenen, durch einen Computer lesbaren Programmcode verfügen.
  • Das Computersystem/der Server 902 kann auch mit einer oder mehreren externen Einheiten 920, z.B. einer Tastatur, einer Zeigeeinheit, einer Anzeige 922 usw., Daten austauschen; sowie mit einer oder mehreren Einheiten, die einen Benutzer in die Lage versetzen, mit dem Computersystem/Server 902 zu interagieren; und/oder beliebigen Einheiten (z.B. Netzwerkkarte, Modem usw.), die das Computersystem/den Server 902 in die Lage versetzen, mit einer oder mehreren Datenverarbeitungseinheiten Daten auszutauschen. Eine solche Datenübertragung kann über die E/A-Schnittstellen 924 erfolgen. Überdies kann das Computersystem/der Server 902 mit einem oder mehreren Netzwerken, z.B. einem lokalen Netzwerk (LAN), einem allgemeinen Weitverkehrsnetzwerk (WAN) und/oder einem öffentlichen Netzwerk (z.B. das Internet), über den Netzwerkadapter 926 Daten austauschen. Wie dargestellt, tauscht der Netzwerkadapter 926 mit den anderen Komponenten des Computersystems/Servers 902 über einen Bus Daten aus. Es versteht sich, sonstige Hardware- und/oder Softwarekomponenten in Verbindung mit dem Computersystem/Server 902 verwendet werden können, auch wenn sie nicht dargestellt sind. Beispiele sind unter anderem, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, Anordnungen externer Festplattenlaufwerke, RAID-Systeme, Bandlaufwerke und Speichersysteme für die Datenarchivierung usw.
  • Obwohl eine beispielhafte Ausführungsform mindestens eines Systems, Verfahrens und nichtflüchtigen, durch einen Computer lesbaren Mediums in den beiliegenden Zeichnungen veranschaulicht und in der vorstehenden ausführlichen Beschreibung beschrieben wurde, versteht sich, dass die Anmeldung nicht auf die offenbarten Ausführungsformen beschränkt ist, sondern dass zahlreichen neue Anordnungen, Änderungen und Ersetzungen möglich sind, wie sie in den folgenden Ansprüchen dargelegt und definiert sind. Die Fähigkeiten des Systems der verschiedenen Figuren können beispielsweise durch ein(e) oder mehrere der hierin beschriebenen Module oder Komponenten oder in einer verteilten Architektur ausgeführt werden und können einen Sender, einen Empfänger oder ein Paar von beiden beinhalten. Die von den einzelnen Modulen ausgeführte Funktionalität kann beispielsweise ganz oder teilweise von einem oder mehreren dieser Module ausgeführt werden. Darüber hinaus kann die hierin beschriebene Funktionalität zu verschiedenen Zeiten und in Bezug auf verschiedene Ereignisse innerhalb oder außerhalb der Module oder Komponenten ausgeführt werden. Die zwischen verschiedenen Modulen gesendeten Informationen können ferner zwischen den Modulen übertragen werden durch: ein Datennetzwerk und/oder das Internet und/oder ein Sprachnetzwerk und/oder ein Internet-Protokoll-Netzwerk und/oder eine drahtlose Einheit und/oder eine drahtgebundene Einheit und/oder über eine Mehrzahl von Protokollen. Die von einem der Module gesendeten oder empfangenen Nachrichten können des Weiteren direkt und/oder über eines oder mehrere der anderen Module gesendet oder empfangen werden.
  • Für einen Fachmann ist offensichtlich, dass ein „System“ als Personal Computer, Server, Konsole, persönlicher digitaler Assistent (PDA), Mobiltelefon, Tablet-Datenverarbeitungseinheit, Smartphone oder eine andere geeignete Datenverarbeitungseinheit oder eine Kombination von Einheiten ausgeführt werden kann. Die Darstellung der oben beschriebenen Funktionen als von einem „System“ ausgeführt soll den Umfang der vorliegenden Anwendung in keiner Weise einschränken, sondern ein Beispiel für viele Ausführungsformen darstellen. Tatsächlich können die hierin offenbarten Verfahren, Systeme und Vorrichtungen in lokalisierter und verteilter Form im Einklang mit der Datenverarbeitungstechnologie implementiert werden.
  • Es ist zu beachten, dass einige der in dieser Beschreibung vorgestellten Systemeigenschaften als Module vorgestellt wurden, um ihre Implementierungsunabhängigkeit besonders hervorzuheben. Ein Modul kann beispielsweise als Hardware-Schaltung implementiert werden, die kundenspezifische VLSI-Schaltungen (VLSI = Very Large Scale Integration) oder Gate-Anordnungen, handelsübliche Halbleiter wie Logikchips, Transistoren oder andere einzelne Komponenten aufweist. Ein Modul kann auch in programmierbaren Hardware-Einheiten wie vor Ort programmierbaren Gate-Anordnungen, programmierbaren Logikanordnungen, programmierbaren Logikeinheiten, Grafikverarbeitungseinheiten oder Ähnlichem implementiert werden.
  • Ein Modul kann auch zumindest teilweise in Software implementiert werden, um von verschiedenen Arten von Prozessoren ausgeführt zu werden. Eine identifizierte Einheit von ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen aufweisen, die beispielsweise als Objekt, Verfahren oder Funktion aufgebaut sein können. Die ausführbaren Dateien eines identifizierten Moduls müssen sich jedoch nicht physisch an der gleichen Stelle befinden, sondern können unterschiedliche Anweisungen aufweisen, die an verschiedenen Stellen gespeichert sind, die, nachdem sie logisch verbunden werden, das Modul aufweisen und den angegebenen Zweck für das Modul erfüllen. Darüber hinaus können Module auf einem durch einen Computer lesbaren Medium gespeichert werden, bei dem es sich beispielsweise um eine Festplatte, eine Flash-Einheit, ein Direktzugriffsspeicher (RAM), ein Band oder ein anderes solches Medium zum Speichern von Daten handeln kann.
  • Tatsächlich kann ein Modul aus ausführbarem Code eine einzelne Anweisung oder viele Anweisungen enthalten und sogar über mehrere verschiedene Code-Segmente, zwischen verschiedenen Programmen und über mehrere Speichereinheiten verteilt sein. Ebenso können Betriebsdaten identifiziert und hier in Modulen dargestellt werden und in jeder geeigneten Form ausgeführt und in jeder geeigneten Art von Datenstruktur aufgebaut sein. Die Betriebsdaten können als ein einzelner Datensatz erfasst oder über verschiedene Orte verteilt sein, darunter verschiedene Speichereinheiten, und zumindest teilweise nur als elektronische Signale in einem System oder Netzwerk vorliegen.
  • Es versteht sich, dass die Komponenten der Anmeldung, wie sie in den Figuren hier allgemein beschrieben und veranschaulicht sind, in vielen verschiedenen Konfigurationen angeordnet und ausgelegt sein können. Die ausführliche Beschreibung der Ausführungsformen soll daher den Umfang der beanspruchten Anwendung nicht einschränken, sondern stellt lediglich ausgewählte Ausführungsformen der Anwendung dar.
  • Für einen Fachmann ist leicht verständlich, dass das vorstehend Genannte mit Schritten in einer anderen Reihenfolge und/oder mit Hardware-Elementen in Konfigurationen durchgeführt werden kann, die sich von den offenbarten Schritten unterscheiden. Obwohl die Anmeldung auf Grundlage dieser bevorzugten Ausführungsformen beschrieben wurde, ist es für Fachleute offensichtlich, dass bestimmte Änderungen, Variationen und andere Ausbildungen möglich sind.
  • Zwar wurden bevorzugte Ausführungsformen der vorliegenden Anwendung beschrieben, jedoch ist zu verstehen, dass die beschriebenen Ausführungsformen nur veranschaulichend sind und der Anwendungsbereich der Anwendung ausschließlich durch die beigefügten Ansprüche zu definieren ist, wenn dabei eine umfassende Bandbreite von Äquivalenten und Änderungen (z.B. Protokolle, Hardware-Einheiten, Software-Plattformen usw.) berücksichtigt werden.

Claims (20)

  1. Vorrichtung, die aufweist: eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie Blöcke einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten empfängt; und einen Prozessor, der so konfiguriert ist, dass er zwei oder mehr Blöcke von den empfangenen Blöcken identifiziert, die zu einem selben Zeitabschnitt in der Blockchain gehören, die zwei oder mehr identifizierten Blöcke parallel durch gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke validiert und als Reaktion auf das Validieren der zwei oder mehr identifizierten Blöcke die zwei oder mehr identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers speichert.
  2. Vorrichtung nach Anspruch 1, bei dem die zwei oder mehr identifizierten Blöcke, die zu demselben Zeitabschnitt gehören, nicht voneinander abhängige Blöcke sind.
  3. Vorrichtung nach Anspruch 1, bei der der Prozessor so konfiguriert ist, dass er die zwei oder mehr identifizierten Blöcke gleichzeitig parallel auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers ausführt.
  4. Vorrichtung nach Anspruch 1, bei der der Prozessor weiterhin so konfiguriert ist, dass er das lokale Blockchain-Ledger für einen Bootprozess und/oder einen Wiederherstellungsprozess initialisiert.
  5. Vorrichtung nach Anspruch 1, bei der der Prozessor weiterhin so konfiguriert ist, dass er zwei oder mehr andere Blöcke in der Blockchain identifiziert, die zu einem unmittelbar vorhergehenden Zeitabschnitt gehören.
  6. Vorrichtung nach Anspruch 5, bei der der Prozessor weiterhin so konfiguriert ist, dass er die zwei oder mehr Blöcke, die zu dem unmittelbar vorhergehenden Zeitabschnitt gehören, parallel zu den zwei oder mehr identifizierten Blöcken, die zu demselben Zeitabschnitt gehören, validiert, wenn die zwei oder mehr anderen Blöcke nicht von den zwei oder mehr identifizierten Blöcken abhängig sind.
  7. Vorrichtung nach Anspruch 1, bei der der Prozessor so konfiguriert ist, dass er auf der Grundlage von in den empfangenen Blöcken gespeicherten Hash-Werten erkennt, welche der empfangenen Blöcke zu demselben Zeitabschnitt gehören.
  8. Vorrichtung nach Anspruch 1, bei der der Prozessor feststellt, dass ein Block zu einem aktuellen Zeitabschnitt gehört, wenn ein unmittelbar vorhergehender Hash-Wert des Blocks eine Funktion von Hashes mehrerer Blöcke ist, die in einem unmittelbar vorhergehenden Zeitabschnitt in der Blockchain gespeichert sind.
  9. Verfahren, das aufweist: Empfangen von Blöcken einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten; Identifizieren von zwei oder mehr Blöcken unter den empfangenen Blöcken, die zu einem gleichen Zeitabschnitt in der Blockchain gehören; paralleles Validieren der zwei oder mehr identifizierten Blöcke durch gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke; und als Reaktion auf das Validieren der zwei oder mehr identifizierten Blöcke Speichern der zwei oder mehr identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers.
  10. Verfahren nach Anspruch 9, bei dem die zwei oder mehr identifizierten Blöcke, die zu demselben Zeitabschnitt gehören, nicht voneinander abhängige Blöcke sind.
  11. Verfahren nach Anspruch 9, bei dem das Validieren gleichzeitiges paralleles Ausführen der zwei oder mehr identifizierten Blöcke auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers aufweist.
  12. Verfahren nach Anspruch 9, das weiterhin Initialisieren des lokalen Blockchain-Ledger während eines Bootprozesses und/oder eines Wiederherstellungsprozesses aufweist.
  13. Verfahren nach Anspruch 9, das weiterhin Identifizieren von zwei oder mehr anderen Blöcken in der Blockchain aufweist, die zu einem unmittelbar vorhergehenden Zeitabschnitt gehören.
  14. Verfahren nach Anspruch 13, das weiterhin Validieren der zwei oder mehr anderen Blöcke, die zu dem unmittelbar vorhergehenden Zeitabschnitt gehören, parallel zu den zwei oder mehr identifizierten Blöcken, die zu demselben Zeitabschnitt gehören, aufweist, wenn die zwei oder mehr anderen Blöcke nicht von den zwei oder mehr identifizierten Blöcken abhängig sind.
  15. Verfahren nach Anspruch 9, bei dem das Identifizieren ein Erkennen auf der Grundlage von in den empfangenen Blöcken gespeicherten Hash-Werten aufweist, welche der empfangenen Blöcke zu demselben Zeitabschnitt gehören.
  16. Verfahren nach Anspruch 9, bei der das Identifizieren ein Feststellen aufweist, dass ein Block zu einem aktuellen Zeitabschnitt gehört, wenn ein unmittelbar vorhergehender Hash-Wert des Blocks eine Funktion von Hashes mehrerer Blöcke ist, die in einem unmittelbar vorhergehenden Zeitabschnitt in der Blockchain gespeichert sind.
  17. Nichtflüchtiges, durch einen Computer lesbares Medium, das Anweisungen aufweist, die, wenn sie von einem Prozessor gelesen werden, den Prozessor veranlassen, ein Verfahren durchzuführen, das aufweist: Empfangen von Blöcken einer Blockchain von einem benachbarten Blockchain-Peer und/oder einem Sortierdienstknoten; Identifizieren von zwei oder mehr Blöcken unter den empfangenen Blöcken, die zu einem gleichen Zeitabschnitt in der Blockchain gehören; paralleles Validieren der zwei oder mehr identifizierten Blöcke durch gleichzeitiges Ausführen der zwei oder mehr identifizierten Blöcke; und als Reaktion auf das Validieren der zwei oder mehr identifizierten Blöcke Speichern der zwei oder mehr identifizierten Blöcke in einem lokalen Blockchain-Ledger eines Blockchain-Peers.
  18. Nichtflüchtiges, durch einen Computer lesbares Medium, bei dem die zwei oder mehr identifizierten Blöcke, die zu demselben Zeitabschnitt gehören, nicht voneinander abhängige Blöcke sind.
  19. Nichtflüchtiges, durch einen Computer lesbares Medium nach Anspruch 17, bei dem das Validieren gleichzeitiges paralleles Ausführen der zwei oder mehr identifizierten Blöcke auf zwei oder mehr unabhängigen Prozessorkernen des Blockchain-Peers aufweist.
  20. Nichtflüchtiges, durch einen Computer lesbares Medium nach Anspruch 17, wobei das Verfahren weiterhin Initialisieren des lokalen Blockchain-Ledger während eines Bootprozesses und/oder eines Wiederherstellungsprozesses aufweist.
DE112020005289.3T 2019-12-23 2020-12-15 Teilweise sortierte blockchain Active DE112020005289B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/726,198 2019-12-23
US16/726,198 US11387979B2 (en) 2019-12-23 2019-12-23 Partially-ordered blockchain
PCT/IB2020/061961 WO2021130607A1 (en) 2019-12-23 2020-12-15 Partially-ordered blockchain

Publications (2)

Publication Number Publication Date
DE112020005289T5 true DE112020005289T5 (de) 2022-09-01
DE112020005289B4 DE112020005289B4 (de) 2024-03-28

Family

ID=76438961

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020005289.3T Active DE112020005289B4 (de) 2019-12-23 2020-12-15 Teilweise sortierte blockchain

Country Status (8)

Country Link
US (1) US11387979B2 (de)
JP (1) JP2023506634A (de)
KR (1) KR20220044306A (de)
CN (1) CN115210741B (de)
AU (1) AU2020414467B2 (de)
DE (1) DE112020005289B4 (de)
GB (1) GB2606111A (de)
WO (1) WO2021130607A1 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11392467B2 (en) * 2019-04-17 2022-07-19 Microsoft Technology Licensing, Llc Failover between decentralized identity stores
US11387979B2 (en) * 2019-12-23 2022-07-12 International Business Machines Corporation Partially-ordered blockchain
JP7348878B2 (ja) * 2020-04-22 2023-09-21 株式会社日立製作所 分散台帳管理方法、分散台帳システム、およびノード
US11949788B1 (en) * 2020-11-21 2024-04-02 CodeNotary Inc. System and method to shorten cryptographic proofs
US11373170B1 (en) * 2021-04-20 2022-06-28 Dmg Blockchain Solutions, Inc. Custom mempool protocol associated with processing of cryptographic events
US11936794B2 (en) * 2021-09-16 2024-03-19 Masterard International Incorporated Method and system for parallel processing of smart contracts in permissioned blockchains
US11849039B2 (en) * 2021-11-29 2023-12-19 Circle Internet Financial Limited Parallel block processing in blockchains
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
CN115225529B (zh) * 2022-06-13 2024-03-01 广州大学 一种支持多类别区块链系统的高仿真平台
US20240061801A1 (en) * 2022-08-16 2024-02-22 Chain Reaction Ltd. Cryptocurrency miner and multicast read
US20240062170A1 (en) * 2022-08-22 2024-02-22 Chain Reaction Ltd. Cryptocurrency miner and job distribution
US11924351B1 (en) * 2023-02-09 2024-03-05 Hong Kong Applied Science and Technology Research Institute Company Limited Optimizing data transactions and verification on a blockchain network

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5014268A (en) * 1989-01-11 1991-05-07 Alcatel Na, Inc. Parallel time slot interchanger matrix and switch block module for use therewith
US20160374442A1 (en) * 2015-06-26 2016-12-29 Huizhou Jincheng Creative Technology Co., Ltd. New-type Non-contact information data shielding and anti-theft card sleeve device and Manufacturing Method thereof
US10255108B2 (en) 2016-01-26 2019-04-09 International Business Machines Corporation Parallel execution of blockchain transactions
US10114980B2 (en) 2016-07-21 2018-10-30 Acronis International Gmbh System and method for verifying data integrity using a blockchain network
US20180158034A1 (en) 2016-12-07 2018-06-07 International Business Machines Corporation Dynamic reordering of blockchain transactions to optimize performance and scalability
CN106530088B (zh) 2016-12-19 2023-11-17 杜伯仁 基于区块链安全节点对证券产品进行交易的方法
US11216874B2 (en) * 2017-03-09 2022-01-04 Jpmorgan Chase Bank, N.A. Method and system for aggregating foreign exchange measures
US10560270B2 (en) 2017-05-03 2020-02-11 International Business Machines Corporation Optimal data storage configuration in a blockchain
EP3669282B1 (de) * 2017-09-20 2022-11-02 Samsung Electronics Co., Ltd. Verfahren und vorrichtung zur verwaltung einer dienstanforderung in einem blockchain-netzwerk
EP3468095A1 (de) 2017-10-06 2019-04-10 Siemens Aktiengesellschaft Transaktionsauswahlvorrichtung zur auswahl von blockchain-transaktionen
GB201717499D0 (en) * 2017-10-24 2017-12-06 Copa Fin Ltd Data storage and verification
AU2019200933B1 (en) * 2017-10-27 2019-05-23 Digital Asset (Switzerland) GmbH Computer system and method for distributed privacy-preserving shared execution of one or more processes
US11257073B2 (en) * 2018-01-31 2022-02-22 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment
CN108990002A (zh) 2018-06-27 2018-12-11 柳州市蓝海数链科技有限公司 一种区块链数据处理方法、装置、终端及存储介质
CN109242681B (zh) 2018-08-21 2020-11-20 京东数字科技控股有限公司 资产数据的存储方法、装置、设备及系统
US11521202B2 (en) * 2018-08-30 2022-12-06 International Business Machines Corporation Distributed computing and storage network implementing high integrity, high bandwidth, low latency, secure processing
US11379828B2 (en) * 2018-08-30 2022-07-05 International Business Machines Corporation Distributed computing and storage network implementing high integrity, high bandwidth, low latency, secure processing
JP7012730B2 (ja) 2018-12-28 2022-01-28 アドバンスド ニュー テクノロジーズ カンパニー リミテッド スマートコントラクトホワイトリストに基づくブロックチェーンネットワークにおけるトランザクションの並列実行
US11387979B2 (en) * 2019-12-23 2022-07-12 International Business Machines Corporation Partially-ordered blockchain
US11223487B2 (en) * 2020-03-19 2022-01-11 Jinan University Method and system for secure blockchain-based vehicular digital forensics
US11882222B2 (en) * 2020-07-23 2024-01-23 The Toronto-Dominion Bank Multidirectional synchronization of confidential data using distributed ledgers

Also Published As

Publication number Publication date
DE112020005289B4 (de) 2024-03-28
WO2021130607A1 (en) 2021-07-01
WO2021130607A8 (en) 2022-07-28
US20210194672A1 (en) 2021-06-24
GB202210344D0 (en) 2022-08-31
AU2020414467B2 (en) 2023-11-16
CN115210741A (zh) 2022-10-18
US11387979B2 (en) 2022-07-12
AU2020414467A1 (en) 2022-03-17
CN115210741B (zh) 2023-06-16
GB2606111A (en) 2022-10-26
KR20220044306A (ko) 2022-04-07
JP2023506634A (ja) 2023-02-17

Similar Documents

Publication Publication Date Title
DE112020005289B4 (de) Teilweise sortierte blockchain
DE112020005075B4 (de) Effiziente schwellenwertspeicherung von datenobjekten
US11093495B2 (en) SQL processing engine for blockchain ledger
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE112020005794T5 (de) Dynamische rechtevergabe und durchsetzung für transportprozess
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
DE112021000688T5 (de) Indexstruktur für blockchain-ledger
DE112021004344T5 (de) Konsensdienst für Blockchain-Netzwerke
DE112021001413T5 (de) Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
US20200382283A1 (en) Blockchain verification using non-consecutive blocks
US11455403B2 (en) Privacy-preserving document sharing
DE112022000906T5 (de) Trennen von blockchain-daten
US11343313B1 (en) Fault tolerant periodic leader rotation for blockchain
DE112021003971T5 (de) Nachhaltige token für eine lieferkette mit datenschutzerhaltendem protokoll
US20200389518A1 (en) Secure data dissemination
US11354425B2 (en) Privacy-preserving document sharing
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf
DE112021000219T5 (de) Konfliktfreie versionssteuerung
US11683185B2 (en) Entity certification management
DE112021005625T5 (de) Automatisiertes zusammenführen von dlt-netzwerken
DE112021004120T5 (de) Schwellenwertverschlüsselung für sendeinhalt
US11563558B2 (en) Behavior driven graph expansion
US20210232540A1 (en) Document storage and verification

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence
R016 Response to examination communication
R018 Grant decision by examination section/examining division