DE112021002053T5 - Verrauschte Transaktion zum Schutz von Daten - Google Patents

Verrauschte Transaktion zum Schutz von Daten Download PDF

Info

Publication number
DE112021002053T5
DE112021002053T5 DE112021002053.6T DE112021002053T DE112021002053T5 DE 112021002053 T5 DE112021002053 T5 DE 112021002053T5 DE 112021002053 T DE112021002053 T DE 112021002053T DE 112021002053 T5 DE112021002053 T5 DE 112021002053T5
Authority
DE
Germany
Prior art keywords
blockchain
noisy
request
data
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112021002053.6T
Other languages
English (en)
Inventor
Qi Zhang
Petr Novotny
Lei Yu
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 DE112021002053T5 publication Critical patent/DE112021002053T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16—Obfuscation or hiding, e.g. involving white box

Abstract

Ein beispielhafte Operation kann Erzeugen einer Blockchain-Anforderung, die Daten für eine Blockchain aufweist, und/oder Erzeugen eines Markierungswerts, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist, und/oder Speichern des Markierungswerts in der Blockchain-Anforderung und/oder Übertragen der Blockchain-Anforderung an einen oder mehrere Blockchain-Peers umfassen.

Description

  • 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.
  • KURZDARSTELLUNG
  • Eine beispielhafte Ausführungsform stellt eine Vorrichtung bereit, die einen Prozessor umfasst, der so konfiguriert ist, dass er eine Blockchain-Anforderung erzeugt, die Daten für eine Blockchain aufweist, und/oder einen Markierungswert (tag value) erzeugt, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte (noisy) Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte (non-noisy) Anforderung, die nichtverrauschte Daten aufweist, und/oder den Markierungswert in der Blockchain-Anforderung speichert, und/oder eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie die Blockchain-Anforderung an einen oder mehrere Blockchain-Peers überträgt.
  • Eine weitere beispielhafte Ausführungsform stellt ein Verfahren bereit, das Erzeugen einer Blockchain-Anforderung, die Daten für eine Blockchain aufweist, und/oder Erzeugen eines Markierungswerts, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist, und/oder Speichern des Markierungswerts in der Blockchain-Anforderung und/oder Übertragen der Blockchain-Anforderung an einen oder mehrere Blockchain-Peers umfasst.
  • Eine weitere beispielhafte Ausführungsform stellt ein nichtflüchtiges, durch einen Computer lesbares Medium bereit, das Anweisungen aufweist, die, wenn sie von einem Prozessor gelesen werden, den Prozessor veranlassen, Erzeugen einer Blockchain-Anforderung, die Daten für eine Blockchain aufweist, und/oder Erzeugen eines Markierungswerts, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist, und/oder Speichern des Markierungswerts in der Blockchain-Anforderung und/oder Übertragen der Blockchain-Anforderung an einen oder mehrere Blockchain-Peers durchzuführen.
  • Figurenliste
    • 1A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine Datenverarbeitungsumgebung zum Senden einer verrauschten Transaktion veranschaulicht.
    • 1B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Empfehlen einer verrauschten Transaktion veranschaulicht.
    • 2A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine beispielhafte Konfiguration einer Blockchain-Architektur veranschaulicht.
    • 2B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Blockchain-Transaktionsablauf zwischen Knoten veranschaulicht.
    • 3A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein genehmigungspflichtiges (permissioned) 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 Senden eines Vorschlags für eine verrauschte Transaktion an Blockchain-Peers veranschaulicht.
    • 4B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen den Inhalt eines Vorschlags für eine verrauschte Transaktion veranschaulicht.
    • 5A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein Verfahren zum Verarbeiten einer Blockchain-Transaktion auf einer Grundlage einer Markierung veranschaulicht.
    • 5B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein Verfahren zum Speichern einer Blockchain-Transaktion mit einer Markierung 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 (intelligenter Vertrag) 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 Dateninhalt 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, Komponenten, nichtflüchtige, durch einen Computer lesbare Medien, Einheiten und/oder Netzwerke bereit, die die Vertraulichkeit und den differenziellen Datenschutz eines Blockchain-Ledger schützen, indem sie absichtlich verrauschte Transaktionen (Blockchain-Inhalt) in ein Blockchain-Netzwerk einfügen.
  • 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.
  • Blockchain-Systeme speichern Daten in einem unveränderlichen Ledger, stellen einen verteilten und dezentralen Zugriff auf das unveränderliche Ledger durch nichtvertrauenswürdige Teilnehmer bereit, legen Konsensanforderungen für eine Zustimmung zwischen den nichtvertrauenswürdigen Teilnehmern fest, sodass keine Entität das unveränderliche Ledger ohne die Zustimmung anderer ändern kann, rufen Smart Contracts (intelligente Verträge) auf und Ähnliches. Eine Blockchain wird von einem Netzwerk von Teilnehmern gebildet, die zustimmen, einen Block (mit darin gespeicherten Daten) zum unveränderlichen Ledger hinzuzufügen. Bevor der Block hinzugefügt wird, wird er mit einem vorherigen Block im unveränderlichen Ledger verknüpft, wodurch eine Kette gebildet wird. Dieser unveränderliche und unbestechliche Charakter der Blockchain macht sie sicher vor gefälschten Informationen und unbefugten Zugriffen. Der dezentrale Charakter verleiht ihr auch die einzigartige Eigenschaft, vertrauenslos zu sein, da die Parteien kein Vertrauen aufbauen müssen, bevor sie sicher Transaktionen durchführen können.
  • 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“ der „Chaincodes“ bezeichnet wird. In einigen Fällen können spezielle Chaincodes für Verwaltungsfunktionen und Parameter zur Verfügung stehen, die als System-Chaincode bezeichnet werden. 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 (hier auch als Blockchain-Anforderungen bezeichnet), 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.
  • Ein Blockchain-Ledger ist ein vertrauenswürdiges Speichersystem, denn sobald die Daten dem Ledger hinzugefügt wurden, ist es sehr schwierig, sie zu ändern oder zu manipulieren. In einem genehmigungspflichtigen Blockchain-Netzwerk wird eine Transaktion als gültig angesehen, wenn eine (normalerweise erforderliche) Mindestanzahl von Endorser-Peers (z.B. durch eine Endorsement Policy festgelegt) einen Konsens über die Transaktion erreicht, indem die Transaktion auf der Grundlage eines aktuellen Zustands des Ledger simuliert und eine zur Transaktion hinzugefügte Client-Signatur überprüft wird. Wenn die Client-Signatur gültig und die Simulation erfolgreich ist, bestätigt (signiert) der Endorser-Knoten die Transaktion und sendet eine erfolgreiche Bestätigungsantwort zurück. Anschließend wird ein Transaktionsvorschlag an einen Sortierdienst weitergeleitet, der die bestätigte Transaktion zu einem Block hinzufügt und den Block an die Blockchain-Peers des Netzwerks zum Festschreiben überträgt.
  • Die Vertraulichkeit von Daten in der Blockchain zu wahren, kann schwierig sein. Ein System, das nicht zu einem Blockchain-Kanal gehört, sollte nicht in der Lage sein, das Ledger/den Zustand des Blockchain-Kanals zu interpretieren. Angreifer (z.B. Hacker, nichtberechtigte Systeme usw.) können jedoch versuchen, ein Blockchain-Ledger zu stehlen, indem sie einen nichtberechtigten, der Blockchain zugehörigen Kanal abhören. Angreifer von außerhalb der Blockchain können sich daher Zugang zum Inhalt des Blockchain-Ledger verschaffen, indem sie sich in den Kanal setzen. Angriffe können auch von innerhalb des Blockchain-Kanals erfolgen. Die Mitglieder der Blockchain sind in der Regel verpflichtet, das Ledger und den Zustand zu teilen. Um diese Ledger-Daten zu schützen, verschlüsseln die Mitglieder die Daten häufig, was mit einem erheblichen Aufwand verbunden sein kann. Darüber hinaus können sensible Daten aufgrund der Transaktionsmuster der Mitglieder offengelegt werden.
  • Zu den Vorteilen der beispielhaften Ausführungsformen gehört, dass Angreifer daran gehindert werden, das Blockchain-Ledger zu interpretieren, und dass die Vertraulichkeit der Daten gewahrt bleibt, indem verrauschte Daten (falsche Daten) in die Blockchain eingefügt werden. Ein Client, ein Smart Contract, ein Agent usw. kann zum Beispiel eine verrauschte Transaktion einfügen, die wie eine typische Blockchain-Transaktion verarbeitet wird, jedoch mit einer eindeutigen Kennung versehen ist, die angibt, dass es sich um eine verrauschte Transaktion handelt. Anhand der eindeutigen Kennung können die verrauschten Transaktionsdaten von den Mitgliedern/Teilnehmern der Blockchain, die an der verrauschten Transaktion beteiligt sind, erkannt und ignoriert werden. Andere Blockchain-Benutzer und nichtberechtigte Benutzer, die die eindeutige Kennung nicht kennen, können die verrauschte Transaktion jedoch wie üblich verarbeiten und ihre Kopie des Blockchain-Ledger fälschlicherweise aktualisieren, wodurch ein verschleierter Zustand erzeugt wird, der die Vertraulichkeit der an der verrauschten Transaktion beteiligten Clients schützt. Dies hat zur Folge, dass nichtberechtigte Benutzer nicht in der Lage sind, das Ledger in Bezug auf die Transaktionshistorie dieser Clients richtig zu interpretieren. Der Zustand des Blockchain-Ledger kann somit beibehalten werden, ohne dass ein erheblicher Leistungs- und Verwaltungsaufwand für die Blockchain-Peers entsteht.
  • Eine verrauschte Transaktion kann nur vom Erzeuger der verrauschten Transaktion (z.B. Client, Peer usw.) und allen Zugriffsmechanismen/Teilnehmern der Blockchain verstanden werden, die die verrauschte Transaktion kennen. Clients und/oder Blockchain-Peers können gemeinsam Schlüssel verwalten und nutzen, die zum Verschlüsseln/Entschlüsseln einer Markierung verwendet werden können. Die Markierung kann ein Wert sein, der angibt, ob es sich bei einer Transaktion um verrauschte oder echte Daten (nichtverrauscht) handelt. Die Markierung zum Beispiel einen booleschen Wert enthalten, wobei ein Wert verrauscht und der andere Wert nichtverrauscht angibt; die Ausführungsformen sind jedoch nicht darauf beschränkt. Die Markierung so verschlüsselt werden, dass sie nur für die Clients/Blockchain-Peers verständlich ist, die an der verrauschten Transaktion beteiligt sind und den Entschlüsselungsschlüssel besitzen. Die Markierung kann in diesem Fall mit einem öffentlichen Schlüssel verschlüsselt werden, und die teilnehmenden Clients und Peers können den entsprechenden privaten Schlüssel gemeinsam nutzen, der in der Lage ist, die Markierung erfolgreich zu entschlüsseln und zu lesen, um zu ermitteln, ob die Transaktion verrauscht ist.
  • Bei dem Schlüssel kann es sich um einen Verschlüsselungsschlüssel handeln, der von den Teilnehmern gemeinsam genutzt wird. Die Teilnehmer können beispielsweise ein Schema zur gemeinsamen Nutzung von Schlüsseln wie eine dezentrale Public-Key-Infrastruktur (PKI), Peer-to-Peer (P2P) oder Ähnliches implementieren. Peers und Clients, die den Schlüssel kennen, können durch Entschlüsseln des Markierungswerts erkennen, dass es sich um eine verrauschte Transaktion handelt. Peers und Clients, die den Schlüssel nicht erhalten, können die Markierung jedoch nicht entschlüsseln, um zu ermitteln, ob es sich um eine verrauschte Transaktion handelt, und behandeln die Transaktion als normal. Der nichtinformierte Peer oder Client aktualisiert daher die Blockchain und die Zustandsdatenbank fälschlicherweise. In einigen Ausführungsformen kann das Blockchain-Netzwerk mehrere Schlüssel zum Verschlüsseln von Markierungswerten verwenden. In diesem Fall kann der Client und/oder der Blockchain-Peer, der die Transaktion erzeugt, auch eine Schlüsselkennung zu der Transaktion hinzufügen, um zu ermitteln, welcher gemeinsam genutzte geheime Schlüssel zum Verschlüsseln des Markierungswerts verwendet wird.
  • Eine verrauschte Transaktion (hier auch als verrauschte Blockchain-Anforderung bezeichnet) kann gemeinsam von einer Gruppe der Clients erzeugt werden, die Daten in der World-State-Datenbank haben, die von der verrauschten Transaktion betroffen sind. In diesem Fall wird die verrauschte Transaktion von der Client-Gruppe als Rauschen verstanden, nicht jedoch von anderen, nichtverbundenen Clients. Wenn demnach nichtverbundene Clients auf die verrauschte Transaktion zurückblicken (z.B. in der Zukunft), erscheint die verrauschte Transaktion als normale/typische Transaktion. Im Allgemeinen wird die verrauschte Transaktion nur von der Teilmenge der Clients, die die verrauschte Transaktion erzeugt hat, als Rauschen verstanden. Auf diese Weise können Clients Transaktionsmuster unkenntlich machen, darunter die Häufigkeit von Transaktionen, den Inhalt von Transaktionen usw., um den Datenschutz in der Blockchain zu gewährleisten. Darüber hinaus kann jede Transaktion (ob verrauscht oder nichtverrauscht) einen Markierungswert enthalten, der verschleiert wird und nur von Clients mit Zugang zu den gemeinsam genutzten geheimen Informationen kenntlich gemacht werden kann.
  • Eine verrauschte Transaktion kann zum Beispiel zusätzliche Versanddatensätze und -termine hinzufügen, um ein Versandmuster zu verbergen. In diesem Beispiel werden neue Schlüsselwerte, die diese zusätzlichen verrauschten Versanddatensätze widerspiegeln, von nichtinformierten Peers zum Blockchain-Ledger (World-State-Datenbank) hinzugefügt und von nichtinformierten Clients eingesehen. Bei einem weiteren Beispiel kann eine verrauschte Transaktion zusätzliche Verkaufsaktivitäten zwischen einem Käufer und einem Verkäufer hinzufügen, um eine vertragliche Geschäftsbeziehung zu verschleiern. In diesem Fall wird die zusätzliche Verkaufsaktivität von nichtinformierten Peers zum Blockchain-Ledger (World-State-Datenbank) hinzugefügt. Es sind noch viele andere Szenarien denkbar, und diese Beispiele sind nicht als Einschränkung gedacht.
  • Die Verwendung von verrauschten Transaktionen kann den Datenschutz der Transaktionen selbst gewährleisten, da ein Angreifer nicht weiß, ob es sich bei einer bestimmten Transaktion um gültige Daten oder um verrauschte Daten handelt. Bei einem weiteren Beispiel kann der Benutzerdatenschutz durch die Verwendung von verrauschten Transaktionen gewährleistet werden, sodass ein Angreifer nicht ermitteln kann, ob ein Transaktionsmuster zu einem bestimmten Benutzer gehört. In einigen Ausführungsformen können verrauschte Transaktionen nach dem Zufallsprinzip erzeugt werden. Bei einem weiteren Beispiel können verrauschte Transaktionen auf der Grundlage von in der Blockchain gespeicherten historischen Transaktionsdaten erzeugt werden. Mit anderen Worten, ein Smart Contract, Agent, Client usw. kann Verhaltensmuster in der Blockchain überwachen und erkennen und auf der Grundlage dieser Verhaltensmuster verrauschte Transaktionen einfügen. Das Verhaltensmuster kann verwendet werden, um eine „glaubwürdige“ verrauschte Transaktion zu erkennen. Bei einem weiteren Beispiel kann das Verhaltensmuster dazu verwendet werden, um ein neues Verhaltensmuster mit der verrauschten Transaktion zu erzeugen.
  • Die beispielhaften Ausführungsformen stellen einen einfachen Ansatz bereit, um den Inhalt der Blockchain mithilfe des differenziellen Datenschutzes zu schützen. Verrauschte Transaktionen und Benutzer können in das Blockchain-System integriert werden, um zu verhindern, dass ein Angreifer datenschutzrelevantes Wissen von der Blockchain gewinnt. Die teilnehmenden Mitglieder-Peers können eine eindeutige Markierung verwenden, um zu ermitteln, ob es sich bei einer Transaktion um eine verrauschte Transaktion oder echte/aktive Daten handelt. Die verrauschten Informationen in der verrauschten Transaktion können darüber hinaus so organisiert sein, dass sie die Richtigkeit der normalen Blockchain-Operationen (z.B. Bestätigung, Konsens, Lese-/ Schreibsätze usw.) nicht beeinträchtigen.
  • 1A veranschaulicht eine Datenverarbeitungsumgebung 100A zum Senden einer verrauschten Transaktion gemäß beispielhaften Ausführungsformen. Mit Bezug auf 1A führen ein Client 121 und ein Client 122 Transaktionen miteinander durch (z.B. Überweisung von Geldbeträgen, Daten des Internet der Dinge (Internet of Things, loT) usw.). Die Transaktionen können von einem Netzwerk von Blockchain-Peers 111, 112, 113, 114 und 115 verarbeitet werden. Die Transaktionsdaten können zum Beispiel von Endorser-Knoten unter den Blockchain-Peers bestätigt, in einen Block hinzugefügt/sortiert und in einer Blockchain 110 aufgezeichnet werden. Bei einer typischen Blockchain-Transaktion (im Folgenden einfach als Transaktion bezeichnet) wird davon ausgegangen, dass es sich bei den Transaktionsdaten um aktive Daten handelt. In den beispielhaften Ausführungsformen kann eine Transaktion jedoch auch eine verrauschte Transaktion sein, die falsche Daten enthält.
  • Ein Smart Contract, ein Client, ein Agent usw. kann nach dem Zufallsprinzip eine verrauschte Transaktion zwischen dem Client 121 und dem Client 122 erzeugen. Die Zufälligkeit kann eine Garantie für einen differenziellen Datenschutz umfassen. Bei einem weiteren Beispiel (in 1B dargestellt) kann der Smart Contract, der Client, der Agent usw. historische Ledger-Daten analysieren und eine verrauschte Transaktion empfehlen. Ein Vorschlag für eine verrauschte Transkation kann daher von dem Client 121, dem Client 122, einem Blockchain-Peer oder Ähnlichem gesendet und von dem in 1A dargestellten Blockchain-Netzwerk von Peers verarbeitet werden. In diesem Beispiel kennen alle Blockchain-Peers außer dem Blockchain-Peer 113 einen Verschlüsselungsschlüssel, der zum Verschleiern einer verrauschten Transaktion verwendet wird. Zu einem Transaktionsvorschlag kann zum Beispiel ein Markierungswert hinzugefügt und mit dem Verschlüsselungsschlüssel verschlüsselt werden. Bei dem Markierungswert handelt es sich um einen Teil der verschlüsselten Informationen in einer Blockchain-Transaktion. Ein und dieselbe Markierung kann für verschiedene Blockchain-Clients unterschiedliche Bedeutungen haben, je nachdem, ob ein Client diese Markierung entschlüsseln kann oder nicht. Wenn ein Client die Markierung entschlüsseln kann, kann er anhand des entschlüsselten Markierungswerts erkennen, ob es sich um eine verrauschte Transaktion handelt. Wenn ein Client die Markierung nicht entschlüsseln kann, muss er diese Transaktion als eine nichtverrauschte Transaktion behandeln.
  • In diesem Fall können die Transaktionsdaten vom Blockchain-Netzwerk normal verarbeitet werden (Bestätigung, Konsens usw.) und zu einem Block hinzugefügt werden, der an jeden der Blockchain-Peers 111 bis 115 zum Speichern gesendet wird. Die verrauschte Transaktion wird jedoch nicht in der World-State-Datenbank in dem Blockchain-Ledger gespeichert/aufgezeichnet und hat keine Auswirkungen auf den Blockchain-Zustand. Die Blockchain-Peers 111, 112, 114 und 115 können die verrauschte Transaktion erkennen und ignorieren, indem sie die World-State-Datenbank nicht aktualisieren, wenn sie den neuen Block im Blockchain-Ledger aktualisieren/festschreiben. Der Blockchain-Peer 113 ist jedoch nicht in der Lage, die verrauschte Transaktion zu erkennen, da er den Markierungswert nicht entschlüsseln kann. Der Blockchain-Peer 113 verarbeitet daher die verrauschte Transaktion als normal und aktualisiert seine lokale Kopie der World-State-Datenbank in dem Blockchain-Ledger fälschlicherweise, wodurch der Zustand der Blockchain für die Transaktionen, an denen die Clients der verrauschten Transaktion beteiligt sind, verschleiert wird.
  • 1B veranschaulicht einen Prozess 100B zum Empfehlen einer verrauschten Transaktion gemäß beispielhaften Ausführungsformen. Mit Bezug auf 1B kann ein Smart Contract 140 in dem Blockchain-Ledger 110 gespeicherte historische Transaktionsdaten analysieren und auf der Grundlage der historischen Transaktionsdaten im Blockchain-Ledger 110 eine verrauschte Transaktion 142 empfehlen. Es sei darauf hingewiesen, dass andere Entitäten anstelle des Smart Contract 140 verrauschte Transaktionen empfehlen können, darunter Clients, Agenten und Ähnliche, ohne auf diese beschränkt zu sein.
  • In diesem Beispiel kann der Smart Contract 140 die historischen Client-Daten 131, 132, 133 und Ähnliche analysieren. In diesem Fall kann der Smart Contract 140 die historischen Client-Daten 131, 132 und 133 analysieren und eine verrauschte Transaktion zwischen dem Client A und dem Client B empfehlen. Auf der Grundlage der historischen Daten 131, 132 und 133 kann der Smart Contract 140 die Häufigkeiten eines Clients mit jedem anderen Client im System in einem bestimmten Zeitraum ableiten. Anhand der historischen Daten 131, 132 und 133 kann zum Beispiel eine Häufigkeitsverteilung ermittelt werden. Die Häufigkeitsverteilung kann ein Transaktionsmuster der Clients A und B enthalten. Der Smart Contract 140 kann entscheiden, wie diese Häufigkeitsverteilung mit zufälligem Rauschen mit einer differenziellen Datenschutzgarantie gestört werden kann. Die Störung der Häufigkeitsverteilung kann durch Hinzufügen von verrauschten Transaktionen mit anderen Clients im System oder durch Hinzufügen von falschen Transaktionen zwischen den Clients A und B erreicht werden. Wie mit Bezug auf die 4A und 4B weiter beschrieben, kann allen Transaktionen eine eindeutige Markierung hinzugefügt werden, um verrauschte Transaktionen gegenüber aktiven/echten Transaktionen zu erkennen/unterscheiden.
  • Nachdem eine vorgeschlagene/empfohlene verrauschte Transaktion 142 festgelegt wurde, können der Smart Contract 140 und/oder der Blockchain-Peer einem oder mehreren der in 1A dargestellten Clients 121 und 122 die vorgeschlagene verrauschte Transaktion 142 bereitstellen. In diesem Fall können sowohl der Client 121 als auch der Client 122 einer verrauschten Transaktion, an der sie beteiligt sind, zustimmen und die verrauschte Transaktion sogar an die Blockchain senden, indem sie die Transaktion an einen oder mehrere Endorser-Peers senden. Zwar ist der Client, der die verrauschte Transaktion an die Blockchain sendet, in 1A nicht dargestellt, er kann jedoch ein verrauschter Client sein, da er nicht aktiv an der Blockchain teilnimmt, aber als tatsächliche Entität identifiziert werden kann.
  • 2A veranschaulicht eine Konfiguration 200 einer Blockchain-Architektur gemäß beispielhaften Ausführungsformen. Mit Bezug auf 2A kann die Blockchain-Architektur 200 bestimmte Blockchain-Elemente enthalten, so beispielsweise 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. Bei 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. Der Smart Contract (oder der Chaincode, der die Logik des Smart Contract ausführt) kann zum Beispiel die Blockchain-Daten 226 lesen, die von einer oder mehreren Verarbeitungsentitäten (z.B. virtuelle Maschinen) verarbeitet werden können, die in der Blockchain-Schicht 216 enthalten sind, um im Rahmen eines komplexen Dienstszenarios die Ergebnisse 228 einschließlich Warnungen zu erzeugen, die Haftung festzulegen und Ähnliches. 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 einen oder mehrere Blöcke in der 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 (z.B. die Logik) eines Smart Contract enthalten. Der Chaincode kann zum Beispiel eine standardmäßige und implementierbare Version der Logik im Smart Contract 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 kann einen Hash empfangen und aus der Blockchain einen Hash abrufen, der der Datenvorlage zugehörig ist, die durch die Verwendung eines zuvor gespeicherten Merkmalsextraktors erzeugt wurde. Stimmen die Hashes der Hash-Kennung und der aus den gespeicherten Kennungsvorlagedaten erzeugte Hash überein, 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 veranschaulicht 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 Client-Knoten 260 umfassen, der einen Transaktionsvorschlag 291 an einen bestätigenden Peer-Knoten 281 übermittelt. 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. In diesem Fall kann der bestätigende Peer 281 ermitteln, ob der Transaktionsvorschlag bestätigt wird. 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.
  • Die Peers 281 bis 283 können darüber hinaus vor dem Festschreiben jeder Transaktion in der Blockchain einen Markierungswert (der verschlüsselt sein kann) überprüfen, der in der Transaktion enthalten ist, um zu ermitteln, ob es sich bei der Transaktion um eine tatsächliche/echte Transaktion oder eine verrauschte Transaktion mit falschen Daten handelt. Wenn die Markierung angibt, dass die Transaktion verrauscht ist, können die Peers 281 bis 283 festlegen, dass die Transaktion falsch ist und die Transaktion ignorieren. Wenn die Markierung jedoch anzeigt, dass die Transaktion nichtverrauscht ist (d.h., es handelt sich um tatsächliche Daten, die in der Blockchain gespeichert werden), können die Peers 281 bis 283 die Daten in ihrer lokalen Kopie der World-State-Datenbank speichern.
  • Mit erneutem Bezug auf 2B initiiert der Client-Knoten 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äß berechtigt 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 Datenbank mit dem aktuellen Zustand ausgeführt, um Transaktionsergebnisse zu erzeugen, darunter ein Antwortwert, ein Lesesatz und ein Schreibsatz. Das Ledger wird zu diesem Zeitpunkt jedoch nicht aktualisiert. In 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 einem Transaktionsvorschlag zusammen und sendet den Transaktionsvorschlag und die Antwort in einer Transaktionsnachricht an den Sortierknoten 284. Die Transaktion kann die 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 werden vom Sortierknoten 284 an alle Peer-Knoten 281 bis 283 im Kanal übermittelt. Der Datenabschnitt im Block kann validiert werden, um sicherzustellen, dass eine Endorsement Policy erfüllt wird 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. Darüber hinaus kann in Schritt 294 ein Markierungswert entschlüsselt und überprüft werden, um sicherzustellen, dass es sich bei den Transaktionsdaten um nichtverrauschte Transaktionsdaten handelt. 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 Datenbank mit dem aktuellen Zustand festgeschrieben, solange es sich bei der Transaktion nicht um eine nichtverrauschte Transaktion handelt. Ein Ereignis kann ausgelöst werden, um die Client-Anwendung darüber zu informieren, dass die Transaktion (der Aufruf) unveränderlich an die Chain angehängt wurde, und um mitzuteilen, ob die Transaktion für gültig oder ungültig erklärt wurde.
  • 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 einen Prozess 400A zum Senden eines Vorschlags für eine verrauschte Transaktion 440 an Blockchain-Peers gemäß beispielhaften Ausführungsformen, und 4B veranschaulicht den Inhalt eines Transaktionsvorschlags 440 gemäß beispielhaften Ausführungsformen. Mit Bezug auf 4A kann eine verrauschte Transaktion wie im Beispiel von 2B beschrieben von einem Client 402 an einen oder mehrere Endorser-Knoten (nicht dargestellt) übertragen werden. Bei ordnungsgemäßer Bestätigung kann der Client 402 den Transaktionsvorschlag 440 auf der Grundlage der Bestätigungen an einen Sortierdienst (z.B. den Sortierknoten 410) des Blockchain-Netzwerks senden. Als Reaktion darauf kann der Sortierknoten 410 den Transaktionsvorschlag 440 mit anderen Transaktionsvorschlägen verbinden, die Vorschläge für eine nichtverrauschte Transaktion und/oder Vorschläge für eine verrauschte Transaktion enthalten können, und einen neuen Block 450 erzeugen, der zu einem verteilten Blockchain-Ledger des Blockchain-Netzwerks hinzugefügt wird. Sobald der Block 450 erzeugt ist, kann der Sortierknoten 410 den Block 450 an die Blockchain-Peers des Blockchain-Netzwerks zum Validieren und Festschreiben in ihre entsprechenden Blockchain-Ledgers übertragen.
  • In dem Beispiel von 4A sind zwei Blockchain-Peers 420 und 430 dargestellt, die jeweils ihre eigene Version des Blockchain-Ledger (Blockchain-Ledger 422 und Blockchain-Ledger 432) speichern. In diesem Beispiel handelt es sich bei dem Blockchain-Peer 420 um einen berechtigten Teilnehmer des Blockchain-Netzwerks, der einen gemeinsam genutzten geheimen Schlüssel enthält, den die Clients und/oder Blockchain-Peers gemeinsam nutzen, die die verrauschten Daten senden. Der Blockchain-Peer 430 ist indessen ein nichtberechtigter Peer, der einen Kanal des Blockchain-Netzwerks abhört. In diesem Fall verfügt der Blockchain-Peer 430 nicht über einen entsprechenden gemeinsam genutzten geheimen Schlüssel.
  • Jeder Blockchain-Peer 420 und 430 kann den Block 450 empfangen und seine jeweiligen Blockchain-Ledgers 422 und 432 auf der Grundlage der einzelnen Transaktionen im Block 450 einschließlich des Transaktionsvorschlags 440 aktualisieren. Der Inhalt des Transaktionsvorschlags 440 kann einen Markierungswert 446 enthalten, der angibt, ob es sich bei dem Transaktionsvorschlag 440 um eine verrauschte Transaktion (falsche Daten) oder um eine echte Transaktion handelt. In diesem Fall zeigt der Markierungswert 446 an, dass es sich um eine falsche/verrauschte Transaktion handelt. Es sei darauf hingewiesen, dass auch nichtverrauschte Transaktionen, die gültige/aktive Daten enthalten, einen Markierungswert enthalten, der angibt, dass die Transaktion nichtverrauscht (gültig, aktiv usw.) ist.
  • Der Markierungswert 446 kann mit einem gemeinsam genutzten Verschlüsselungsschlüssel verschlüsselt werden, den der Blockchain-Peer 420 kennt, nicht jedoch der nichtberechtigte Peer 430. Der Blockchain-Peer 420 kann erkennen, dass es sich bei dem Vorschlag für eine verrauschte Transaktion 440 um eine verrauschte Transaktion handelt, indem er den Markierungswert 446 entschlüsselt und einen booleschen Indikator (oder einen anderen Markierungswert) identifiziert. Der Blockchain-Peer 420 kann somit die Zustandsänderungen im Blockchain-Ledger im Vorschlag für eine verrauschte Transaktion 440 überspringen oder auf andere Weise ignorieren. Der nichtberechtigte Peer 430 ist indessen nicht in der Lage, diesen Markierungswert 446 zu entschlüsseln und kann nicht feststellen, dass es sich bei dem Transaktionsvorschlag 440 um Rauschen handelt. Der nichtberechtigte Peer 430 verarbeitet den Vorschlag für eine verrauschte Transaktion 440 daher als typische Transaktion und aktualisiert das Blockchain-Ledger 432 entsprechend.
  • In 4A verfügt der Blockchain-Peer 420 über seine eigene Kopie des Blockchain-Ledger (Ledger 422), die korrekt ist (d.h. nichtverschleierter Zustand), da der Vorschlag für eine verrauschte Transaktion 440 ignoriert wird und nicht zu einer World-State-Datenbank im Blockchain-Ledger 422 hinzugefügt wird. Das Blockchain-Ledger 432 des Blockchain-Peers 430 befindet sich indessen in einem verschleierten Zustand, da der Inhalt des Vorschlags für eine verrauschte Transaktion 440 zu seinem Ledger 432 hinzugefügt wurde (z.B. aktualisierte Schlüssel-Wert-Paare in einer Zustandsdatenbank 460). Auf diese Weise werden die Transaktionsmuster der Clients, die an der verrauschten Transaktion beteiligt sind, verschleiert und geschützt.
  • 4B veranschaulicht ein Beispiel des Inhalts eines mit Bezug auf 4A beschriebenen Transaktionsvorschlags 440. Der Transaktionsvorschlag 440 kann zusammen mit anderen Transaktionsvorschlägen in Block 450 gespeichert werden. Nach der Verarbeitung können die Transaktionsvorschläge verwendet werden, um Schlüssel-Wert-Paare zu aktualisieren, die im World-State 460 gespeichert sind, der einen aktuellen Wert aller Schlüssel-Wert-Paare in der Blockchain speichert. Wie in 4B dargestellt, enthält der Transaktionsvorschlag 440 dieselben Komponenten wie eine normale Blockchain-Transaktion, wobei der Unterschied darin besteht, dass es einen Markierungswert 446 gibt, der verschlüsselt sein kann und der angibt, ob es sich um eine verrauschte Transaktion handelt, und dass es eine Schlüsselkennung 447 gibt, die einen Verschlüsselungsschlüssel angibt, der zum Verschlüsseln des Markierungswerts 446 verwendet wird. Da das Transaktionsformat gleich bleibt, weiß eine nichtberechtigte Partei nicht, dass verrauschte Daten möglich sind.
  • Der Transaktionsvorschlag 440 kann zum Beispiel einen Kopf 441 enthalten, der wesentliche Metadaten über die Transaktion wie den Namen des Chaincodes und seine Version erfasst, sowie eine Signatur 442, die eine kryptografische Signatur des Clients 402 enthält, der den Transaktionsvorschlag 440 erzeugt und gesendet hat. Der Transaktionsvorschlag 440 enthält ferner die Bestätigungen 445, die eine Liste der signierten Transaktionsantworten von jedem erforderlichen Endorser enthalten, um eine Endorsement Policy zu erfüllen.
  • Der Transaktionsvorschlag 440 enthält darüber hinaus einen Vorschlag 443 mit Eingabeparametern für einen Smart Contract sowie eine Antwort 444, die Lese-/ Schreibsätze der Endorser-Knoten enthält. In diesem Beispiel handelt es sich bei dem Transaktionsvorschlag 440 um eine verrauschte Transaktion. Der Vorschlag 443 enthält daher verrauschte/falsche Daten. Der Vorschlag 443 kann verrauschte Eingabeparameter codieren, die einem Smart Contract/Chaincode bereitgestellt werden, der die vorgeschlagene verrauschte Aktualisierung des Blockchain-Ledger erzeugt. Wenn die Logik eines Smart Contract ausgeführt wird, stellt der Vorschlag 443 die verrauschten Eingabeparameter (z.B. Schlüssel-Wert-Paare usw.) bereit, die verwendet werden, um den neuen World State in Bezug auf den aktuellen World State festzustellen. Der Transaktionsvorschlag 440 enthält darüber hinaus eine falsche Antwort 444, die die Vorher- und Nachherwerte des World State als Lese-/Schreibsätze mit verrauschten Daten erfasst. Die Antwort 444 ist die Ausgabe des Smart Contract auf der Grundlage der verrauschten Eingabe von dem Vorschlag 443.
  • 5A veranschaulicht ein Verfahren 500 zum Verarbeiten einer Blockchain-Transaktion auf der Grundlage einer Markierung gemäß beispielhaften Ausführungsformen. Als ein nichteinschränkendes Beispiel kann das Verfahren 500 von einer Client-Anwendung, einem Smart Contract in einem Blockchain-Peer, einem Agentensystem der Blockchain und Ähnlichem ausgeführt werden. Mit Bezug auf 5A kann das Verfahren in Schritt 502 Erzeugen einer Blockchain-Anforderung umfassen, die Daten für eine Blockchain aufweist. Die Blockchain-Anforderung kann zum Beispiel eine Blockchain-Transaktion enthalten, die so konfiguriert ist, dass sie einen Chaincode aufruft. Die Blockchain-Anforderung kann Schlüsselwerte enthalten, die im Blockchain-Ledger geändert werden sollen.
  • In einigen Ausführungsformen kann das Erzeugen ein Erzeugen einer verrauschten Blockchain-Anforderung umfassen, die falsche Daten für die Blockchain aufweist, und das Erzeugen weist ein Erzeugen eines Markierungswerts auf, der angibt, dass die Blockchain-Anforderung verrauscht ist. In diesem Beispiel können die falschen Daten falsche Schlüsselwerte für die Blockchain enthalten, und der Markierungswert weist einen booleschen Wert auf. In einigen Ausführungsformen kann das Erzeugen ein Erzeugen einer nichtverrauschten Blockchain-Anforderung umfassen, die aktive Daten für die Blockchain aufweist, und das Erzeugen weist ein Erzeugen einen Markierungswert auf, der angibt, dass es sich bei der Blockchain-Anforderung um aktive Daten handelt.
  • In Schritt 504 kann das Verfahren Erzeugen eines Markierungswerts umfassen, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist. Der Markierungswert kann zum Beispiel einen booleschen Wert enthalten, bei dem „wahr“ verrauscht und „falsch“ nichtverrauscht oder umgekehrt bedeutet. In einigen Ausführungsformen kann das Verfahren weiterhin Verschleiern des Markierungswerts auf der Grundlage eines geheimen Schlüssels sowie Speichern eines Schlüsselkennungswerts in der Blockchain-Anforderung umfassen, der den zum Verschleiern des Markierungswerts verwendeten geheimen Schlüssel identifiziert. Die Schlüsselkennung kann zum Beispiel unterscheiden, welcher Verschlüsselungsschlüssel verwendet wird, wenn mehrere Verschlüsselungsschlüssel im Blockchain-Netzwerk verwendet werden. In einigen Ausführungsformen kann der geheime Schlüssel einen öffentlichen Schlüssel eines symmetrischen öffentlichen und privaten Schlüsselpaars enthalten, und der private Schlüssel wird von Blockchain-Peers gemeinsam genutzt, die Mitglieder der Blockchain sind.
  • In Schritt 506 kann das Verfahren Speichern des Markierungswerts in der Blockchain-Anforderung umfassen, und in Schritt 508 kann das Verfahren Übertragen der Blockchain-Anforderung an einen oder mehrere Blockchain-Peers umfassen. In einigen Ausführungsformen kann das Verfahren weiterhin Empfangen von Signaturen und Lese-/ Schreibsätzen in Bezug auf die verrauschte Blockchain-Anforderung von Endorser-Peers der Blockchain und Speichern der Signaturen und Lese-/Schreibsätze in der verrauschten Blockchain-Anforderung umfassen. In einigen Ausführungsformen kann das Erzeugen ein Erzeugen einer verrauschten Blockchain-Anforderung auf der Grundlage eines historischen Verhaltensmusters eines Clients in der Blockchain umfassen.
  • 5B veranschaulicht ein Verfahren 510 zum Speichern einer Blockchain-Transaktion mit einer Markierung gemäß beispielhaften Ausführungsformen. Mit Bezug auf 5B kann das Verfahren in Schritt 512 Empfangen einer Blockchain-Anforderung umfassen, die einen Markierungswert aufweist, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist. Bei der Blockchain-Anforderung kann es sich zum Beispiel um eine verrauschte Blockchain-Anforderung handeln, die falsche Daten für eine Blockchain aufweist, und der Markierungswert kann einen Markierungswert enthalten, der angibt, dass die Blockchain-Anforderung verrauscht ist. In einigen Ausführungsformen können die falschen Daten falsche Schlüsselwerte für die Blockchain enthalten, und der Markierungswert kann einen Hash-Wert enthalten, dem die Erzeuger der verrauschten Blockchain-Anforderung zuvor zugestimmt haben.
  • In Schritt 514 kann das Verfahren Überprüfen umfassen, dass die Blockchain-Anforderung von genügend Blockchain-Peers bestätigt wurde, um eine zuvor festgelegte Policy zu erfüllen. Das Überprüfen kann zum Beispiel Überprüfen von Signaturen und Lese-/ Schreibsätzen in Bezug auf die verrauschte Blockchain-Anforderung von Endorser-Peers der verrauschten Blockchain-Anforderung umfassen. Als Reaktion auf ein positives Prüfergebnis kann das Verfahren in Schritt 516 Speichern der Blockchain-Anforderung umfassen, die den Markierungswert in einem Datenblock in einer Hash-verknüpften Kette von Datenblöcken enthält.
  • In einigen Ausführungsformen kann der Markierungswert einen verschleierten Markierungswert enthalten, der auf der Grundlage eines geheimen Schlüssels verschleiert wurde, und der Prozessor ist weiterhin so konfiguriert, dass er einen Schlüsselkennungswert des geheimen Speichers in dem Datenblock speichert. In einigen Ausführungsformen kann der geheime Schlüssel einen öffentlichen Schlüssel eines symmetrischen öffentlichen und privaten Schlüsselpaars enthalten, und der private Schlüssel wird von Blockchain-Clients in einem Blockchain-Netzwerk gemeinsam genutzt, das die verrauschte Blockchain-Anforderung erzeugt hat, nicht jedoch von anderen Blockchain-Clients in dem Blockchain-Netzwerk. In einigen Ausführungsformen kann es sich bei der Blockchain-Anforderung um eine nichtverrauschte Blockchain-Anforderung handeln, die aktive Daten für die Blockchain aufweist, und der Markierungswert kann einen Wert enthalten, der angibt, dass die Blockchain-Anforderung für Blockchain-Clients, die die Blockchain-Anforderung erzeugt haben, nicht verrauscht ist.
  • 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 veranschaulicht 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 World State und ein Distributed Ledger enthält, das es den Clients 652 und 656 ermöglicht, Daten über den World State abzufragen und Transaktionen an das Blockchain-Netzwerk zu senden, wo die bestätigenden Peers die Smart Contracts 630 je nach Smart Contract 630 und Endorsement Policy ausführen werden.
  • 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 World State), 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 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 World State 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-/Schreibsatz aktualisiert. Wenn eine Transaktion nicht erfolgreich ist, d.h., wenn der festschreibende Peer feststellt, dass der Lese-/Schreibsatz nicht mit dem aktuellen 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 (Blockdatenabschnitt) 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. In einem herkömmlichen Block kann der Datenabschnitt Transaktionsinformationen von N Transaktionen (z.B. 1, 10, 100, 500, 1000, 2000, 3000 usw.) in den Blockdaten 750 speichern.
  • Der neue Datenblock 730 kann eine Verknüpfung zu einem früheren Block (z.B. in der Blockchain 722 in 7A) im Blockkopf 740 enthalten. Der Blockkopf 740 kann insbesondere einen Hash des Kopfes eines früheren Blocks enthalten. 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 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 angibt, ob eine Transaktion gültig oder ungültig war.
  • 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 Inhaltes, 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 dem tatsächlichen digitalen Inhalt gespeichert ist, verwiesen oder zugegriffen werden. Diese Operation kann z.B. von einem Datenbank-Gatekeeper durchgeführt werden. Dies lässt sich wie folgt darstellen:
    Blockchain Speicherbereich
    Block 1 Hash-Wert Block 1 Hash-Wert ... Inhalt
    Block N Hash-Wert Block N Hash-Wert ... Inhalt
  • In der beispielhaften Ausführungsform von 7C umfasst die Blockchain 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ören, ohne auf diese beschränkt zu sein, ein Algorithmus vom Typ SHA (SHA steht für Secured Hash Algorithm, sicherer Hash-Algorithmus), ein Merkle-Damgard-Algorithmus, ein HAIFA-Algorithmus, ein Merkle-Baum-Algorithmus, ein Nonce-gestützten 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.
    1. a) Neuer SHA-2 berechneter Hash-Wert, wenn die Datei in irgendeiner Weise verarbeitet wurde (z.B. wenn die Datei redigiert, kopiert, geändert oder auf sie zugegriffen wurde oder eine andere Maßnahme durchgeführt wurde)
    2. b) Neuer Speicherort für die Datei
    3. c) Neue Metadaten identifiziert, die der Datei zugehörig sind
    4. d) Übertragung des Zugriffs auf oder der Kontrolle über die Datei von einem Blockchain-Teilnehmer auf einen anderen Blockchain-Teilnehmer
  • 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 Metadaten 1, Metadaten 2, ..., Metadaten N bezeichnet, 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 Ungültigmachen 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. Zu Beispielen zählen, 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 enthalten. 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 dergleichen 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 (21)

  1. Vorrichtung, die aufweist: einen Prozessor, der so konfiguriert ist, dass er eine Blockchain-Anforderung erzeugt, die Daten für eine Blockchain aufweist, einen Markierungswert erzeugt, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist, und den Markierungswert in der Blockchain-Anforderung speichert; und eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie die Blockchain-Anforderung an einen oder mehrere Blockchain-Peers überträgt.
  2. Vorrichtung nach Anspruch 1, wobei der Prozessor so konfiguriert ist, dass er eine verrauschte Blockchain-Anforderung erzeugt, die falsche Daten für die Blockchain aufweist, und einen Markierungswert erzeugt, der angibt, dass die Blockchain-Anforderung verrauscht ist.
  3. Vorrichtung nach Anspruch 2, wobei die falschen Daten falsche Schlüsselwerte für das Blockchain-Ledger aufweisen und der Markierungswert einen Hash-Wert aufweist, dem die Erzeuger der Blockchain-Anforderung zuvor zugestimmt haben.
  4. Vorrichtung nach Anspruch 2, wobei der Prozessor weiterhin so konfiguriert ist, dass er Signaturen und Lese-/Schreibsätze in Bezug auf die verrauschte Blockchain-Anforderung von Endorser-Peers der Blockchain empfängt und die Signaturen und Lese-/Schreibsätze in der verrauschten Blockchain-Anforderung speichert.
  5. Vorrichtung nach Anspruch 1, wobei der Prozessor so konfiguriert ist, dass er eine verrauschte Blockchain-Anforderung auf der Grundlage eines historischen Verhaltensmusters mehrerer Clients in der Blockchain erzeugt.
  6. Vorrichtung nach Anspruch 1, wobei der Prozessor weiterhin so konfiguriert ist, dass er den Markierungswert auf der Grundlage eines geheimen Schlüssels vor dem Übertragen der Blockchain-Anforderung verschleiert.
  7. Vorrichtung nach Anspruch 6, wobei der geheime Schlüssel einen öffentlichen Schlüssel eines symmetrischen öffentlichen und privaten Schlüsselpaars aufweist, und der private Schlüssel von Blockchain-Clients in einem Blockchain-Netzwerk gemeinsam genutzt wird, das die verrauschte Blockchain-Anforderung erzeugt hat, nicht jedoch von anderen Blockchain-Clients in dem Blockchain-Netzwerk.
  8. Vorrichtung, die aufweist: eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie eine Blockchain-Anforderung empfängt, die einen Markierungswert aufweist, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist; und einen Prozessor, der so konfiguriert ist, dass er überprüft, ob die Blockchain-Anforderung von genügend Blockchain-Peers bestätigt wurde, um eine zuvor festgelegte Policy zu erfüllen, und als Reaktion auf ein positives Prüfergebnis die Blockchain-Anforderung, die den Markierungswert enthält, in einem Datenblock in einer Hash-verknüpften Kette von Datenblöcken speichert.
  9. Vorrichtung nach Anspruch 8, wobei es sich bei der Blockchain-Anforderung um eine verrauschte Blockchain-Anforderung handelt, die falsche Daten für eine Blockchain aufweist, und der Markierungswert angibt, dass die Blockchain-Anforderung verrauscht ist.
  10. Vorrichtung nach Anspruch 9, wobei die falschen Daten falsche Schlüsselwerte für die Blockchain aufweisen und der Markierungswert einen Hash-Wert aufweist, dem die Erzeuger der verrauschten Blockchain-Anforderung zuvor zugestimmt haben.
  11. Vorrichtung nach Anspruch 9, wobei der Prozessor so konfiguriert ist, dass er Signaturen und Lese-/Schreibsätze in Bezug auf die verrauschte Blockchain-Anforderung von Endorser-Peers der verrauschten Blockchain-Anforderung empfängt und die Signaturen und Lese-/Schreibsätze im Datenblock speichert.
  12. Vorrichtung nach Anspruch 8, wobei der Markierungswert einen verschleierten Markierungswert aufweist, der auf der Grundlage eines geheimen Schlüssels verschleiert wurde.
  13. Vorrichtung nach Anspruch 12, wobei der geheime Schlüssel einen öffentlichen Schlüssel eines symmetrischen öffentlichen und privaten Schlüsselpaars aufweist und der private Schlüssel von Blockchain-Clients in einem Blockchain-Netzwerk gemeinsam genutzt wird, das die verrauschte Blockchain-Anforderung erzeugt hat, nicht jedoch von anderen Blockchain-Clients in dem Blockchain-Netzwerk.
  14. Vorrichtung nach Anspruch 8, wobei es sich bei der Blockchain-Anforderung um eine nichtverrauschte Blockchain-Anforderung handelt, die aktive Daten für die Blockchain aufweist, und der Markierungswert angibt, dass die Blockchain-Anforderung nichtverrauscht ist.
  15. Verfahren, das aufweist: Erzeugen einer Blockchain-Anforderung, die Daten für eine Blockchain aufweist; Erzeugen eines Markierungswerts, der angibt, ob es sich bei der Blockchain-Anforderung um eine verrauschte Anforderung handelt, die falsche Daten aufweist, oder um eine nichtverrauschte Anforderung, die nichtverrauschte Daten aufweist; Speichern des Markierungswerts in der Blockchain-Anforderung; und Übertragen der Blockchain-Anforderung an einen oder mehrere Blockchain-Peers.
  16. Verfahren nach Anspruch 15, wobei das Erzeugen ein Erzeugen einer verrauschten Blockchain-Anforderung aufweist, die falsche Daten für die Blockchain aufweist, und der Markierungswert angibt, dass die Blockchain-Anforderung verrauscht ist.
  17. Verfahren nach Anspruch 16, wobei die falschen Daten falsche Schlüsselwerte für die Blockchain aufweisen und der Markierungswert einen Hash-Wert aufweist, dem die Erzeuger der verrauschten Blockchain-Anforderung zuvor zugestimmt haben.
  18. Verfahren nach Anspruch 16, wobei das Verfahren weiterhin Empfangen von Signaturen und Lese-/Schreibsätzen in Bezug auf die verrauschte Blockchain-Anforderung von Endorser-Peers der Blockchain und Speichern der Signaturen und Lese-/Schreibsätze in der verrauschten Blockchain-Anforderung aufweist.
  19. Verfahren nach Anspruch 15, wobei das Erzeugen ein Erzeugen einer verrauschten Blockchain-Anforderung auf der Grundlage eines historischen Verhaltensmusters mehrerer Clients in der Blockchain aufweist.
  20. Verfahren nach Anspruch 15, wobei das Erzeugen weiterhin Verschleiern des Markierungswerts auf der Grundlage eines geheimen Schlüssels vor dem Übertragen der Blockchain-Anforderung aufweist.
  21. Computerprogramm, das einen Programmcode aufweist, der geeignet ist, um die Verfahrensschritte der Ansprüche 15 bis 20 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
DE112021002053.6T 2020-04-01 2021-03-26 Verrauschte Transaktion zum Schutz von Daten Pending DE112021002053T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/837,386 US20210314139A1 (en) 2020-04-01 2020-04-01 Noisy transaction for protection of data
US16/837,386 2020-04-01
PCT/CN2021/083261 WO2021197227A1 (en) 2020-04-01 2021-03-26 Noisy transaction for protection of data

Publications (1)

Publication Number Publication Date
DE112021002053T5 true DE112021002053T5 (de) 2023-04-13

Family

ID=77922168

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021002053.6T Pending DE112021002053T5 (de) 2020-04-01 2021-03-26 Verrauschte Transaktion zum Schutz von Daten

Country Status (8)

Country Link
US (1) US20210314139A1 (de)
JP (1) JP2023520632A (de)
KR (1) KR20220148854A (de)
CN (1) CN115943411A (de)
AU (1) AU2021246718A1 (de)
DE (1) DE112021002053T5 (de)
GB (1) GB2609156A (de)
WO (1) WO2021197227A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10887090B2 (en) * 2017-09-22 2021-01-05 Nec Corporation Scalable byzantine fault-tolerant protocol with partial tee support
US11575499B2 (en) * 2020-12-02 2023-02-07 International Business Machines Corporation Self auditing blockchain
US11930043B1 (en) * 2023-02-28 2024-03-12 Blockaid Ltd Techniques for digital wallet integration and for scanning transactions using integrated modules

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9904793B2 (en) * 2015-03-23 2018-02-27 Intel Corporation Systems, methods, and apparatus to provide private information retrieval
US10216672B2 (en) * 2015-12-29 2019-02-26 International Business Machines Corporation System and method for preventing time out in input/output systems
US11816642B2 (en) * 2017-03-20 2023-11-14 Steven Victor Wasserman Blockchain digital currency: systems and methods for use in enterprise blockchain banking
CN109064325B (zh) * 2018-06-25 2020-07-24 浙江超脑时空科技有限公司 一种基于区块链的智能合约实现方法和装置
US11164180B1 (en) * 2018-08-06 2021-11-02 United Services Automobile Association (Usaa) Privacy preservation in private consensus networks
CN110046990A (zh) * 2018-11-05 2019-07-23 阿里巴巴集团控股有限公司 基于区块链的数据处理方法、装置和服务器
CN109934709A (zh) * 2018-11-05 2019-06-25 阿里巴巴集团控股有限公司 基于区块链的数据处理方法、装置和服务器
CN110415117A (zh) * 2019-06-28 2019-11-05 阿里巴巴集团控股有限公司 基于区块链的交易处理方法、装置和电子设备
US11222011B2 (en) * 2019-06-28 2022-01-11 Advanced New Technologies Co., Ltd. Blockchain-based transaction processing
CN110516469B (zh) * 2019-07-31 2023-05-26 苏州白杨软件有限公司 一种基于区块链的共享大数据应用场景中的防黑客方法
US11456855B2 (en) * 2019-10-17 2022-09-27 Arm Limited Obfuscating data at-transit
US11397728B2 (en) * 2020-03-30 2022-07-26 Oracle lnternational Corporation Distributed and blockchain-based ledgers for data cloud services

Also Published As

Publication number Publication date
CN115943411A (zh) 2023-04-07
KR20220148854A (ko) 2022-11-07
JP2023520632A (ja) 2023-05-18
WO2021197227A1 (en) 2021-10-07
US20210314139A1 (en) 2021-10-07
AU2021246718A1 (en) 2022-09-15
GB2609156A (en) 2023-01-25
GB202216191D0 (en) 2022-12-14

Similar Documents

Publication Publication Date Title
DE112020005289B4 (de) Teilweise sortierte blockchain
DE112020005075B4 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
AU2021210206B2 (en) Index structure for blockchain ledger
US11838400B2 (en) Image encoding for blockchain
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
US11379472B2 (en) Schema-based pruning of blockchain data
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
US11455403B2 (en) Privacy-preserving document sharing
US11949794B2 (en) Data anonymization of blockchain-based processing pipeline
US11354425B2 (en) Privacy-preserving document sharing
US20210320797A1 (en) Prevention of majority attacks
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf
DE112022000906T5 (de) Trennen von blockchain-daten
US20220276996A1 (en) Assessment node and token assessment container
DE112021000219T5 (de) Konfliktfreie versionssteuerung
US11310311B2 (en) Media obfuscation
US11683185B2 (en) Entity certification management
US20210174292A1 (en) Anonymization of partners
US20230208640A1 (en) Selective audit process for privacy-preserving blockchain
DE112021004120T5 (de) Schwellenwertverschlüsselung für sendeinhalt
US11526467B2 (en) Document storage and verification
US11876890B2 (en) Anonymization of partners
US20210232539A1 (en) Document storage and verification

Legal Events

Date Code Title Description
R012 Request for examination validly filed