DE102019216744A1

DE102019216744A1 - Granulare Speicherverwaltung für einen Distributed Ledger

Info

Publication number: DE102019216744A1
Application number: DE102019216744.6A
Authority: DE
Inventors: Alexander PODDEY; Fredrik Winzer
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2019-10-30
Filing date: 2019-10-30
Publication date: 2021-05-06
Also published as: CN112751906B; CN112751906A

Abstract

Verfahren (100) zum Betreiben eines Netzwerks (1) mit einer Vielzahl computerimplementierter Knoten (2), wobei dieses Netzwerk (1) dazu ausgebildet ist, einen über das Netzwerk (1) verteilten und/oder replizierten Speicher (3) sowie die Ausführung von Transaktionen (4) mit Inhalten dieses Speichers (3) zu implementieren, wobei• einer ersten Teilmenge (21) der Knoten (2) die Aufgabe zugewiesen wird (110), einen für das Netzwerk (1) als Ganzes gültigen Konsens über die Reihenfolge (41) zu ermitteln, in der anstehende Transaktionen (4) ausgeführt werden; und• einer zweiten Teilmenge (22) der Knoten (2) die Aufgabe zugewiesen wird (130), einen für das Netzwerk (1) als Ganzes gültigen Konsens darüber zu ermitteln, welche Speicherstellen (31) innerhalb des Speichers (3) zu welcher Zeit für den Zugriff durch weitere Transaktionen (4) zur Verfügung stehen (31a) bzw. für den Zugriff durch bereits für die Ausführung geplante Transaktionen (4) reserviert sind (31b).

Description

Die vorliegende Erfindung betrifft die Koordination paralleler Zugriffe auf einen Speicher in einem Distributed Ledger mit dem Ziel, Transaktionen, die diesen Distributed Ledger nutzen, insgesamt schneller abarbeiten zu können.
Stand der Technik
Ein Distributed Ledger ist ein dezentraler Datenspeicher, der über eine Vielzahl computerimplementierter Knoten in einem Netzwerk verteilt ist und repliziert wird. Die Knoten bilden nach einem vorgegebenen Prozedere einen gemeinsamen Konsens bezüglich Transaktionen, mit denen auf der Basis von Inhalten des Datenspeichers Arbeitsergebnisse gebildet werden, und über die Hinterlegung dieser Arbeitsergebnisse in dem Speicher. Durch den Konsensmechanismus können die Speicherinhalte insbesondere vor nachträglicher Verfälschung geschützt werden. Daher eignet sich ein Distributed Ledger beispielsweise zur manipulationssicheren Speicherung einer Buchführung über das Eigentum an Einheiten einer Kryptowährung, wie etwa Bitcoin oder Ether, oder anderer beweiserheblicher Daten.
Damit eine insgesamt anstehende Menge an Transaktionen möglichst schnell ausgeführt wird, ist es gewünscht, dass möglichst viele Transaktionen parallel ausgeführt werden. Ein begrenzender Faktor hierfür ist, dass Speicherbereiche, mit denen eine Transaktion gerade arbeitet, nicht durch andere Transaktionen verändert werden dürfen. Ansonsten werden die Berechnungsergebnisse falsch und nicht reproduzierbar.
In einem anschaulichen Beispiel soll eine erste Transaktion einen Wert um 5 inkrementieren, und eine zweite Transaktion soll den gleichen Wert um 10 inkrementieren. Werden ausgehend von einem Wert 20 beide Transaktionen gleichzeitig ausgeführt, liefert die erste Transaktion als Ergebnis 25 (20+5), die zweite Transaktion liefert als Ergebnis 30 (20+10), und der zeitlich später erhaltene Wert ist maßgeblich. Das Ergebnis hängt also von der möglicherweise zufälligen Reihenfolge ab, in der die beiden Transaktionen auf der Hardware jeweils fertig werden. Beide möglichen Ergebnisse sind falsch; richtig wäre 35 (20+5+10).
Offenbarung der Erfindung
Im Rahmen der Erfindung wurde ein Verfahren zum Betreiben eines Netzwerks mit einer Vielzahl computerimplementierter Knoten entwickelt. Das Netzwerk ist dazu ausgebildet, einen über das Netzwerk verteilten und/oder replizierten Speicher sowie die Ausführung von Transaktionen mit Inhalten dieses Speichers zu implementieren.
Unter einer „Transaktion“ wird insbesondere ein abgrenzbarer Vorgang verstanden, der mit der Eingabe mindestens eines Inhalts aus dem Speicher beginnt, anschließend eine Verarbeitung dieses Inhalts (sowie optional weiterer Informationen aus beliebigen Quellen) zu einem Ergebnis beinhaltet und mit der Ausgabe dieses Ergebnisses zwecks Hinterlegung in dem Speicher endet. Dabei wird unter „abgrenzbar“ insbesondere beispielsweise verstanden, dass eine aus welchen Gründen auch immer unvollständig ausgeführte Transaktion „zurückgerollt“ werden kann, d.h., dass die Auswirkungen der unvollständig ausgeführten Transaktion auf den Speicher rückstandsfrei wieder beseitigt werden können.
Einer ersten Teilmenge der Knoten wird die Aufgabe zugewiesen, einen für das Netzwerk als Ganzes gültigen Konsens über die Reihenfolge zu ermitteln, in der anstehende Transaktionen ausgeführt werden. Einer zweiten Teilmenge der Knoten wird die Aufgabe zugewiesen, einen für das Netzwerk als Ganzes gültigen Konsens darüber zu ermitteln, welche Speicherstellen innerhalb des Speichers zu welcher Zeit für den Zugriff durch weitere Transaktionen zur Verfügung stehen bzw. für den Zugriff durch bereits für die Ausführung geplante Transaktionen reserviert sind. Dabei können die erste und die zweite Teilmenge sich optional auch überschneiden oder gar deckungsgleich sein.
Im Unterschied zum bisherigen Stand der Technik wird der Speicher hier wesentlich granularer verwaltet. Wenn der Speicher bislang als ein einziger monolithischer Block verwaltet wurde, wie es beispielsweise in der Bitcoin-Blockchain der Fall war, konnte zu jedem Zeitpunkt immer nur eine einzige Transaktion zur Ausführung geplant werden, die für die Dauer ihrer Ausführung exklusiven Zugriff auf den Speicher hatte. Für die vergleichsweise einfachen Transaktionen zur Dokumentation der Eigentumsverhältnisse an Bitcoins war dies ausreichend. Beginnend mit dem Ethereum-Netzwerk wurde jedoch die Funktionalität von Distributed Ledger-Netzwerken um die automatisierte Ausführung von „smart contracts“ erweitert, die beispielsweise das Eintreten vorher festgelegter vertraglicher Bedingungen prüfen und daraufhin automatisch Aktionen einleiten. So kann etwa ein „smart contract“ für das gemeinsame Ansparen eines Geldbetrages mittels Crowdfunding überprüfen, ob die Zielsumme erreicht ist oder aber die Frist hierfür fruchtlos verstrichen ist. Im ersteren Fall kann dann beispielsweise der Erwerb des gemeinsam zu finanzierenden Gegenstandes angestoßen werden; im letzteren Fall können alle Beteiligten automatisch ihr Geld zurückerhalten.
Je mächtiger die Funktionalität ist, die im Rahmen von „smart contracts“ bereitgestellt wird, desto länger brauchen diese Funktionen zur Ausführung. Daher ist es wünschenswert, mehrere Transaktionen parallel ausführen zu können. Ein Ansatz hierfür ist, den Speicher in sogenannte „Splitter“ (englisch „shards“) aufzuteilen, die unabhängig voneinander verwaltet werden, so wie beispielsweise die funktionalen Zuständigkeiten innerhalb von Gerichten und Behörden häufig nach Anfangsbuchstaben der Nachnamen der betroffenen Bürger aufgeteilt sind (etwa A bis K, L bis N und O bis Z). Die Reservierung für den Zugriff durch zur Ausführung geplante Transaktionen betrifft dann immer nur diejenigen „shards“, in denen die konkreten Inhalte gespeichert sind, auf die der Zugriff benötigt wird.
Dabei sind jedoch die „shards“ noch vergleichsweise große Einheiten, die eine Vielzahl von Speicherstellen umfassen. Eine weitere deutliche Verkleinerung der „shards“ stößt an die praktische Grenze, dass für die Konsensbildung über die Fortschreibung des Inhalts des Speichers dann wesentlich mehr Knoten benötigt würden: Fällt die Anzahl der für die Fortschreibung des Inhalts eines „shards“ zuständigen Knoten unter eine kritische Grenze, wird es für einen Angreifer möglicherweise praktikabel, mehr als 51 % des Stimmengewichts dieser Knoten in Form von Rechenzeit, Kryptowährung oder einer anderen maßgeblichen Ressource aufzubringen. Er hat dann die Gelegenheit, die Daten in diesem „shard“ nach eigenem Ermessen zu ändern.
Im Vergleich hierzu wird nun mit der granularen Buchführung, welche Speicherstellen innerhalb des Speichers zu welcher Zeit zur Verfügung stehen bzw. reserviert sind, zunächst einmal ein wesentlich höherer Verwaltungsaufwand in Kauf genommen. Im Austausch dafür ist die besagte granulare Buchführung aber nicht mehr zwangsläufig mit der Nebenwirkung gekoppelt, dass das für den Konsens über den Inhalt einer konkreten Speicherstelle zuständige „Komitee“ an Knoten drastisch verkleinert wird und im Interesse der Sicherheit mit neuen Knoten „aufgefüllt“ werden muss.
Damit können insgesamt in einem Netzwerk mit einer vorgegebenen Anzahl von Knoten, und somit mit vorgegebenen Hardwareressourcen, mehr Transaktionen für die gleichzeitige Ausführung geplant werden. Wenn eine vorgegebene Menge an Transaktionen insgesamt für die Ausführung ansteht, eröffnen sich viel mehr Möglichkeiten, Transaktionen für die gleichzeitige Ausführung miteinander zu kombinieren. So können beispielsweise eine erste Transaktion, die Zugriff auf eine erste Speicherstelle benötigt, und eine zweite Transaktion, die Zugriff auf eine zweite Speicherstelle benötigt, auch dann gleichzeitig ausgeführt werden, wenn beide Speicherstellen im gleichen „shard“ liegen. Diese erweiterten Möglichkeiten erhöhen die Wahrscheinlichkeit, dass die gegebene Menge an Transaktionen zumindest teilweise parallelisiert abgearbeitet werden kann.
Daher wird die gegebene Menge an Transaktionen schneller abgearbeitet. Weiterhin ist es weniger wahrscheinlich, dass Situationen, in denen die Ausführung bestimmter Transaktionen deutlich länger dauert als ursprünglich geplant, eine große Anzahl anderer anstehender Transaktionen von der Ausführung ausschließen. Dies könnte die Abarbeitung der insgesamt anstehenden Menge an Transaktionen empfindlich lähmen. Dies wiederum bedeutet, dass es praktikabler wird, in „smart contracts“ auch komplexe Routinen einzusetzen, deren Ausführungsdauer im Vorhinein schwer vorherzusehen ist. Hierzu zählen beispielsweise Algorithmen, die einen gesuchten Wert iterativ berechnen und ein Abbruchkriterium beinhalten, das ein Konvergieren der Iterationen beispielsweise über ein Ausbleiben größerer Änderungen prüft.
Bei der Suche nach Kombinationen von Transaktionen, die parallel ausführbar sind, kann eine beliebige Strategie verfolgt werden. Beispielsweise kann eine große Anzahl Möglichkeiten, bestimmte Transaktionen in bestimmten Zeitbereichen auszuführen, eine nach der anderen daraufhin überprüft werden, ob die jeweils benötigten Speicherstellen verfügbar sind.
Daher wird in einer besonders vorteilhaften Ausgestaltung mindestens eine Kombination aus einer anstehenden Transaktion und einem für die Ausführung dieser Transaktion beabsichtigten Zeitbereich dahingehend validiert, ob die benötigten Speicherzugriffe möglich sind. Dass ein Zeitbereich an Stelle eines bloßen Zeitpunkts für die Ausführung eingeplant wird, trägt der Tatsache Rechnung, dass die Ausführung komplexer Transaktionen auch länger dauern kann.
Zu diesem Zweck wird ermittelt, auf welche Speicherstellen die Transaktion Zugriff benötigt. Es wird geprüft, ob diese Speicherstellen in dem beabsichtigten Zeitbereich für den Zugriff durch die anstehende Transaktion zur Verfügung stehen. Wenn alle benötigten Speicherstellen zur Verfügung stehen, wird die Ausführung der Transaktion in dem beabsichtigten Zeitbereich akzeptiert. Wenn hingegen mindestens eine Speicherstelle nicht zur Verfügung steht, wird die Ausführung der Transaktion in dem beabsichtigten Zeitbereich abgelehnt.
Speicherstellen, auf die eine Transaktion Zugriff benötigt, können beispielsweise aus einer Analyse der in der Transaktion enthaltenen Instruktionen ermittelt werden. So ist beispielsweise für jede Instruktion bekannt, ob sie Operanden hat, die einen Zugriff auf Speicherinhalte auslösen. Die entsprechenden Operanden können dann näher analysiert werden. Wenn beispielsweise ein Wert von einer Speicherstelle gelesen wird, deren Adresse mit einer Zeigerarithmetik berechnet wird, dann kann die Berechnung dieser Adresse nachvollzogen und so die benötigte Speicherstelle ermittelt werden.
In einer weiteren besonders vorteilhaften Ausgestaltung sind in der Transaktion Speicherinhalte deklariert, auf die die Transaktion Zugriff benötigt. Speicherstellen, an denen diese Speicherinhalte abgelegt sind, können dann als Speicherstellen, auf die die Transaktion Zugriff benötigt, ermittelt werden. Beispielsweise kann eine Transaktion, analog zu einem Funktionsaufruf, Argumente erwarten, die auf bestimmte Variablen im Speicher verweisen. Der Programmcode der Transaktion kann auch beispielsweise eine Deklaration enthalten, dass explizit bestimmte Variablen aus dem Speicher für den Gebrauch durch die Transaktion „importiert“ werden. Der Programmierer einer Transaktion hat ein eigenes Interesse daran, die benötigten Variablen und sonstigen Inhalte aus dem Speicher möglichst vollständig vorab zu deklarieren. Zugriffe auf weitere Inhalte, die bei einer Vorabplanung des Zeitbereichs für die Ausführung der Transaktion nicht berücksichtigt wurden, scheitern in diesem geplanten Zeitbereich möglicherweise daran, dass der Zugriff auf die entsprechenden Speicherstellen bereits für andere Transaktionen reserviert ist. Die Transaktion muss dann möglicherweise abgebrochen und zurückgerollt werden.
Wenn eine Transaktion bei der besagten Validierung für die Ausführung in einem beabsichtigen Zeitbereich akzeptiert wird, wird sie in einer weiteren besonders vorteilhaften Ausgestaltung für diesen Zeitbereich zur Ausführung geplant. Die von dieser Transaktion benötigten Speicherstellen werden dann für den Zugriff durch diese Transaktion reserviert. Die Planung einer Transaktion in dieser Weise steckt dann den Rahmen für die Planung weiterer Transaktionen im gleichen Zeitraum enger, denn die reservierten Speicherstellen können in der Regel nicht gleichzeitig mehrfach vergeben werden. Auf der anderen Seite schreitet die Planung einer Menge von insgesamt anstehenden Transaktionen sukzessive schneller voran, wenn die zunehmenden Reservierungen von immer mehr Speicherstellen die Planung von immer mehr potentiellen Transaktionen von vornherein ausschließen. Sobald festgestellt wird, dass auch nur eine von der potentiellen Transaktion benötigte Speicherstelle nicht verfügbar ist, kann die Prüfung, ob die Transaktion zur Ausführung geplant werden kann, mit negativem Ergebnis abgebrochen werden.
Die Ausführungsdauer eines beliebigen Computerprogramms, das in einer Turing-vollständigen Sprache geschrieben ist, ist nicht zuverlässig vorherzusagen. Dieses Problem ist in der Informatik als „halting problem“ bekannt. Eine Reservierung von Speicherstellen ist daher im Allgemeinen nur „open end“ möglich, d.h. für unbestimmte Dauer, bis die Speicherstellen nach Abschluss der Transaktion wieder freigegeben werden. Bei der Ausführung von Transaktionen in Blockchain-Netzwerken kann jedoch Planungssicherheit geschaffen werden, indem der Transaktion ein festes Ressourcenbudget zugewiesen wird, das beispielsweise in Rechenaufwand oder Kryptowährung angegeben werden kann.
So hat beispielsweise im Kontext von „smart contracts“ auf der Ethereum-Blockchain jede einzelne der Instruktionen, aus denen Transaktionen zusammengesetzt sind, einen ihrem Rechenzeitbedarf entsprechenden Preis in „gas“. Wenn eine Transaktion ausgeführt wird, wird ihr ein festes Budget von „gas“ zugeteilt, das ihr Absender maximal zu bezahlen bereit ist. Wenn die Transaktion erfolgreich beendet wird und noch „gas“ übrig ist, erhält der Absender der Transaktion dieses zurück. Kommt die Transaktion jedoch nicht mit dem „gas“ aus, wird sie abgebrochen und zurückgerollt, d.h. ungeschehen gemacht. Das verbrauchte „gas“ ist dann aus Sicht des Absenders der Transaktion verloren.
Dieser Mechanismus stellt sicher, dass zu jeder Transaktion angegeben werden kann, wie lange die Transaktion maximal läuft, und zwar auch dann, wenn der Ressourcenhunger der Transaktion von den Eingaben abhängt, die sie erhält. Dies kann ausgenutzt werden, um die Reservierung von Speicherstellen zeitlich zu begrenzen. Innerhalb eines Planungshorizonts, für den die Ausführung von Transaktionen geplant wird, kann dann also der Zugriff auf ein und dieselbe Speicherstelle zuerst einer ersten Transaktion und später einer zweiten Transaktion zugewiesen werden. Der Planungshorizont kann beispielsweise in einem Blockchain-Netzwerk einen oder auch mehrere Blöcke umfassen.
Daher wird in einer besonders vorteilhaften Ausgestaltung eine maximale Zeitdauer, für die die von der Transaktion benötigten Speicherstellen reserviert werden, anhand eines der Transaktion zugewiesenen Ressourcenbudgets, nach dessen Verbrauch die Transaktion abgebrochen und zurückgerollt wird, ermittelt. Dies schließt nicht aus, dass die Speicherstellen vorzeitig wieder freigegeben werden, wenn die Transaktion früher als geplant abgeschlossen ist.
Die Reihenfolge, in der anstehende Transaktionen validiert und auf dieser Basis für die Ausführung geplant werden, kann nach beliebigen Kriterien gewählt werden, die für den Betrieb des Netzwerks als Ganzes relevant sind. Die Transaktionen können also insbesondere nach beliebigen Kriterien priorisiert werden. Wenn beispielsweise für die Ausführung einer Transaktion eine Bezahlung in Kryptowährung verlangt wird, kann sich die Priorität einer Transaktion beispielsweise nach dem Geldbetrag richten, den der Absender der Transaktion für die Ausführung zu zahlen bereit ist. So hat etwa im Ethereum-Netzwerk der Absender einer Transaktion als Stellschraube für die Priorisierung einer Transaktion den Preis in der Hand, den er für jede Einheit an verbrauchtem „gas“ zu bezahlen bereit ist. Die Priorität einer Transaktion kann aber auch beispielsweise eine Komponente beinhalten, die von der bereits verbrachten Wartezeit in der Warteschlange der zur Ausführung anstehenden Transaktionen abhängt.
In einer weiteren besonders vorteilhaften Ausgestaltung wird mindestens ein Kandidaten-Zeitplan für die Ausführung einer Mehrzahl von Transaktionen aufgestellt. Dieser Kandidaten-Zeitplan wird validiert, indem alle in dem Kandidaten-Zeitplan enthaltenen Transaktionen validiert werden. Der Kandidaten-Zeitplan wird als Ganzes akzeptiert, wenn alle validierten Transaktionen akzeptiert werden. Wird hingegen mindestens eine validierte Transaktion abgelehnt, wird der Kandidaten-Zeitplan als Ganzes abgelehnt. Aus den akzeptierten Kandidaten-Zeitplänen wird ein Zeitplan, der nach Maßgabe eines vorgegebenen Optimalitätskriteriums am besten bewertet wird, ausgewählt.
Auf diese Weise wird die vergleichsweise schnelle Prüfung, ob ein Zeitplan überhaupt realisierbar ist, der möglicherweise aufwändigeren Prüfung des Optimalitätskriteriums vorgeschaltet. Analog zur Validierung einzelner Transaktionen reicht dann ein eine einzige Nicht-Verfügbarkeit einer benötigten Speicherstelle aus, um bereits den kompletten Kandidaten-Zeitplan verwerfen zu können.
In einer weiteren besonders vorteilhaften Ausgestaltung werden anstehende Transaktionen aus einem Pool auf Zeitschlitze verteilt, in die ein Planungshorizont für die Ausführung von Transaktionen unterteilt ist. Auf diese Weise kann die Suche nach Zeitbereichen innerhalb des Planungshorizonts, in denen die Ausführung bestimmter Transaktionen möglich ist, diskretisiert und somit beschleunigt werden. Beispielsweise kann in Antwort darauf, dass eine von einer Transaktion benötigte Speicherstelle in einem Wunsch-Zeitbereich nicht verfügbar ist, sukzessive geprüft werden, ob diese Speicherstelle in einem späteren Zeitbereich innerhalb des Planungshorizonts wieder frei und die Ausführung der Transaktion somit möglich ist.
Das hier beschriebene Konzept der Parallelisierung lässt sich des Weiteren auch innerhalb einer Transaktion anwenden, um deren Ausführung zu beschleunigen und damit auch die Zeitdauer zu minimieren, für die die von dieser Transaktion benötigten Speicherstellen reserviert sind. In einer weiteren besonders vorteilhaften Ausgestaltung werden bei der Ausführung mindestens einer Transaktion mindestens zwei Instruktionen, die keinen Zugriff auf die gleichen Speicherstellen benötigen, parallel ausgeführt. Wenn beispielsweise ein Verarbeitungsschritt zwei verschiedene Eingaben aus zwei verschiedenen Quellen benötigt, dann können diese beiden Eingaben gleichzeitig beschafft werden, um dann den Verarbeitungsschritt auszuführen.
In einer weiteren besonders vorteilhaften Ausgestaltung wird einer dritten Teilmenge der Knoten die Aufgabe zugewiesen, einen für das Netzwerk als Ganzes gültigen Konsens über Ergebnisse der Ausführung von Transaktionen zu ermitteln. Die Ausführung mindestens einer Transaktion oder in einer Transaktion enthaltenen Instruktion wird an eine oder mehrere Verarbeitungseinheiten delegiert. Dabei kann die dritte Teilmenge der Knoten sich mit den zuvor erwähnten ersten und zweiten Teilmengen der Knoten überschneiden oder auch mit der ersten und/oder zweiten Teilmenge deckungsgleich sein.
Das Delegieren an die Verarbeitungseinheiten kann insbesondere durch mindestens einen Knoten der dritten Teilmenge erfolgen. Die Knoten der dritten Teilmenge können also, nachdem über die Belegungszustände von Speicherstellen und über die sich hieraus ergebende Choreographie der nächsten Transaktionen entschieden wurde, für die weitere konkrete Ausführung der geplanten Transaktionen insgesamt zuständig sein. Alternativ können die Transaktionen auch durch Knoten der ersten und/oder zweiten Teilmenge delegiert werden. Die Knoten der dritten Teilmenge können dann beispielsweise lediglich für den Konsens über die bei der Ausführung der Transaktionen erhaltenen Ergebnisse zuständig sein.
Wenn Transaktionen und/oder Instruktionen von Knoten der dritten Teilmenge an Verarbeitungseinheiten delegiert werden, muss die jeweilige Verarbeitungseinheit nicht von den Knoten der dritten Teilmenge separat sein. Beispielsweise können die Knoten der dritten Teilmenge eine unterschiedliche Ausstattung an Hardware haben. So kann etwa ein erster Knoten mehrere Grafikprozessoren (GPUs) beinhalten, während ein zweiter Knoten mehr CPU-Kerne beinhaltet. Die Knoten der dritten Teilmenge können sich dann untereinander dahingehend verständigen, dass GPU-lastige Transaktionen an den ersten Knoten und CPU-lastige Transaktionen an den zweiten Knoten delegiert werden. Ressourcen, die nicht überall in dem Netzwerk verfügbar sind, können somit effektiv geteilt werden.
Die Verarbeitungseinheiten können aber auch beispielsweise dedizierte GPU- oder CPU-Farmen sein, die im Übrigen nicht die Funktionalität eines Knotens in dem Netzwerk haben. Auf diese Weise lässt sich beispielsweise die Verarbeitung sensibler Daten von der Konnektivität zu dem Peer-to-Peer-Netzwerk der Knoten abschirmen.
Das Delegieren von Transaktionen und/oder Instruktionen an spezialisierte Verarbeitungseinheiten kann insbesondere beispielsweise dann vorteilhaft sein, wenn diese Transaktionen Matrix- und/oder Tensor-Operationen insbesondere aus dem Bereich der linearen Algebra (etwa Lösen linearer Gleichungssysteme) oder die Nutzung (Inferenz) trainierter neuronaler Netzwerke, beispielsweise zur Ermittlung einer Klassifikation und/oder eines Regressionswerts auf der Basis sensorisch erfasster physikalischer Messdaten, umfassen.
Vorteilhaft umfasst mindestens eine Verarbeitungseinheit mindestens einen Grafikprozessor, GPU, eine feldprogrammierbare Gatteranordnung, FPGA, eine vertrauenswürdige Ausführungseinheit, TEE, und/oder eine sichere Enklave mit verschlüsseltem Speicher. Diesen Verarbeitungseinheiten ist gemein, dass sie auf die Ausführung ganz bestimmter Aufgaben spezialisiert sind. Es ist daher besonders wirtschaftlich, diese Typen von Verarbeitungseinheiten innerhalb eines größeren Netzwerks zu teilen.
Das Delegieren von Transaktionen an Verarbeitungseinheiten entspringt, wie auch die granulare Verwaltung des Speichers, dem Wunsch, in einem verteilten Netzwerk mit einer Vielzahl von Knoten, welches die Datenhaltung in dem Speicher verwaltet, zunehmend komplexere Transaktionen auszuführen. Beide Neuerungen ergänzen sich synergistisch miteinander und arbeiten somit Hand in Hand auf die Verwirklichung des besagten Wunsches hin: Die granularere Verwaltung des Speichers sorgt dafür, dass anstehende Transaktionen mit einer größeren Wahrscheinlichkeit parallel ausgeführt werden können. Das Delegieren an Verarbeitungseinheiten spart Aufwand für das Vielfache Vorhalten ein und derselben Hardwareressourcen (etwa GPU oder FPGA) und beschleunigt die Ausführung bestimmter Typen von Transaktionen. Dies wiederum führt dazu, dass von den Transaktionen benötigte Speicherstellen schneller wieder freigegeben werden können. Indem dies nun wiederum die Wahrscheinlichkeit erhöht, dass anstehende Transaktionen parallel ausgeführt werden können, schließt sich der Kreis.
Das Delegieren von Transaktionen an spezialisierte Verarbeitungseinheiten ist aber auch unabhängig von der granulareren Speicherverwaltung vorteilhaft. Der Vorteil des geringeren Hardwareaufwandes für spezialisierte Verarbeitungseinheiten ist nicht daran gebunden, dass Transaktionen in dem Netzwerk gemeinsam auf bestimmte Speicherstellen zugreifen.
Daher bezieht sich die Erfindung ganz allgemein auf ein Verfahren zum Betreiben eines Netzwerks mit einer Vielzahl computerimplementierter Knoten.
Das Netzwerk ist dazu ausgebildet, einen über das Netzwerk verteilten und/oder replizierten Speicher sowie die Ausführung von Transaktionen mit Inhalten dieses Speichers zu implementieren. In diesem Netzwerk wird einer Teilmenge der Knoten die Aufgabe zugewiesen, einen für das Netzwerk als Ganzes gültigen Konsens über Ergebnisse der Ausführung von Transaktionen zu ermitteln, wobei die Ausführung mindestens einer Transaktion und/oder Instruktion, beispielsweise durch mindestens einen Knoten der Teilmenge, an eine oder mehrere Verarbeitungseinheiten delegiert wird. Einer weiteren Teilmenge der Knoten, die sich optional mit der vorgenannten Teilmenge überlappen oder hierzu auch deckungsgleich sein kann, wird die Aufgabe zugewiesen, einen für das Netzwerk als Ganzes gültigen Konsens über die Fortschreibung des Speichers auf der Basis der bei der Ausführung von Transaktionen erhaltenen Ergebnisse zu ermitteln. Wiederum einer Teilmenge der Knoten kann die Aufgabe zugewiesen werden, einen für das Netzwerk als Ganzes gültigen Konsens über die Reihenfolge zu ermitteln, in der anstehende Transaktionen ausgeführt werden.
Die Verfahren können insbesondere ganz oder teilweise computerimplementiert sein. Daher bezieht sich die Erfindung auch auf ein Computerprogramm mit maschinenlesbaren Anweisungen, die, wenn sie auf einem oder mehreren Computern ausgeführt werden, den oder die Computer dazu veranlassen, eines der beschriebenen Verfahren auszuführen. In diesem Sinne sind auch Steuergeräte für Fahrzeuge und Embedded-Systeme für technische Geräte, die ebenfalls in der Lage sind, maschinenlesbare Anweisungen auszuführen, als Computer anzusehen.
Ebenso bezieht sich die Erfindung auch auf einen maschinenlesbaren Datenträger und/oder auf ein Downloadprodukt mit dem Computerprogramm. Ein Downloadprodukt ist ein über ein Datennetzwerk übertragbares, d.h. von einem Benutzer des Datennetzwerks downloadbares, digitales Produkt, das beispielsweise in einem Online-Shop zum sofortigen Download feilgeboten werden kann.
Weiterhin kann ein Computer mit dem Computerprogramm, mit dem maschinenlesbaren Datenträger bzw. mit dem Downloadprodukt ausgerüstet sein.
Weitere, die Erfindung verbessernde Maßnahmen werden nachstehend gemeinsam mit der Beschreibung der bevorzugten Ausführungsbeispiele der Erfindung anhand von Figuren näher dargestellt.
Figurenliste
Es zeigt:

1 Ausführungsbeispiel des Verfahrens 100 zum Betreiben des Netzwerks 1;
2 Beispielhafte Unterteilung der Knoten 2 des Netzwerks 1 in Teilmengen 21-23 zur Bildung verschiedener Konsense;
3 Beispielhafter Ablauf 200 von Transaktionen 4 in einem Netzwerk 1, das nach dem Verfahren 100 betrieben wird.

1 zeigt ein Ausführungsbeispiel des Verfahrens 100 zum Betreiben eines Netzwerks 1 mit einer Vielzahl computerimplementierter Knoten 2. Das Netzwerk 1 ist in 2 näher dargestellt und dazu ausgebildet, einen über das Netzwerk 1 verteilten und/oder replizierten Speicher 3 sowie die Ausführung von Transaktionen 4 mit Inhalten dieses Speichers 3 zu implementieren.
In Schritt 110 wird einer ersten Teilmenge 21 der Knoten 2 die Aufgabe zugewiesen, einen für das Netzwerk 1 als Ganzes gültigen Konsens über die Reihenfolge 41 zu ermitteln, in der anstehende Transaktionen 4 ausgeführt werden.
In Schritt 130 wird einer zweiten Teilmenge 22 der Knoten 2 die Aufgabe zugewiesen, einen für das Netzwerk 1 als Ganzes gültigen Konsens darüber zu ermitteln, welche Speicherstellen 31 innerhalb des Speichers 3 zu welcher Zeit für den Zugriff durch weitere Transaktionen 4 zur Verfügung stehen (Zustand 31a) bzw. für den Zugriff durch bereits für die Ausführung geplante Transaktionen 4 reserviert sind (Zustand 31b).
In Schritt 140 werden bei der Ausführung mindestens einer Transaktion 4 mindestens zwei Instruktionen 4b, die keinen Zugriff auf die gleichen Speicherstellen 31 benötigen, parallel ausgeführt.
In Schritt 150 wird einer dritten Teilmenge 23 der Knoten 2 die Aufgabe zugewiesen, einen für das Netzwerk 1 als Ganzes gültigen Konsens über Ergebnisse 7 der Ausführung von Transaktionen 4 zu ermitteln. In Schritt 160 wird die Ausführung mindestens einer Transaktion 4 und/oder Instruktion 4b an eine oder mehrere Verarbeitungseinheiten 8 delegiert. Diese Verarbeitungseinheiten 8 spielen ihre Ergebnisse 7 an den Schritt 150 zurück.
Innerhalb des Kastens 110 sind beispielhaft verschiedene Ausgestaltungen dahingehend eingezeichnet, wie der gesuchte Konsens über die Reihenfolge 41, in der die anstehenden Transaktionen 4 auszuführen sind, ermittelt werden kann.
Gemäß Block 111 kann eine Kombination aus einer anstehenden Transaktion 4 und einem für die Ausführung dieser Transaktion 4 beabsichtigten Zeitbereich 4a validiert werden. Zu diesem Zweck wird gemäß Block 112 ermittelt, auf welche Speicherstellen 31 die Transaktion 4 Zugriff benötigt. Gemäß Block 113 wird geprüft, ob die benötigten Speicherstellen 31 in dem beabsichtigten Zeitbereich 4a für den Zugriff durch die anstehende Transaktion zur Verfügung stehen.
Wenn alle Speicherstellen 31 zur Verfügung stehen (Wahrheitswert 1), wird gemäß Block 114 die Ausführung der Transaktion 4 in dem beabsichtigten Zeitbereich 4a akzeptiert. Die Transaktion 4 kann dann gemäß Block 116 für den Zeitbereich 4a zur Ausführung geplant werden, und die benötigten Speicherstellen können gemäß Block 133 für den Zugriff durch diese Transaktion 4 reserviert werden.
Steht hingegen mindestens eine Speicherstelle 31 nicht zur Verfügung (Wahrheitswert 0), wird gemäß Block 115 die Ausführung der Transaktion 4 in dem beabsichtigten Zeitbereich 4a abgelehnt.
Die Validierung 111 einer einzelnen Transaktion 4, deren Ausführung in einem Zeitbereich 4a beabsichtigt ist, wird bei der Validierung 120 eines gemäß Block 117 aufgestellten Kandidaten-Zeitplans 42 gemäß Block 118 für alle in dem Kandidaten-Zeitplan 42 enthaltenen Transaktionen 4 als Subroutine aufgerufen. Jede Transaktion 4 ist hierbei gemäß Kandidaten-Zeitplan 42 mit einem beabsichtigten Zeitbereich 4a für die Ausführung verbunden. Die Validierung 111 meldet zurück, ob die jeweilige Transaktion gemäß Block 114 akzeptiert oder gemäß Block 115 abgelehnt wurde.
Das Ergebnis wird in Block 119 überprüft. Wenn alle gemäß Block 118 validierten Transaktionen 4 akzeptiert werden (Wahrheitswert 1), wird der Kandidaten-Zeitplan 42 gemäß Block 119 als Ganzes akzeptiert. Wird hingegen mindestens eine validierte Transaktion abgelehnt (Wahrheitswert 0), wird der Kandidaten-Zeitplan 42 als Ganzes abgelehnt.
Die Validierung 120 eines Kandidaten-Zeitplans 42 wird wiederum gemäß Block 122 für viele gemäß Block 121 aufgestellte Kandidaten-Zeitpläne 42 als Subroutine aufgerufen. Für jeden Kandidaten-Zeitplan 42 wird durch die Validierung 120 jeweils zurückgemeldet, ob dieser Kandidaten-Zeitplan 42 gemäß Block 119a akzeptiert oder gemäß Block 119b abgelehnt wurde. Gemäß Block 123 wird aus den akzeptierten Kandidaten-Zeitplänen 42' ein Zeitplan 42*, der nach Maßgabe eines vorgegebenen Optimalitätskriteriums 5 am besten bewertet wird, ausgewählt. Gemäß Block 124 werden die in diesem Zeitplan 42* enthaltenen Transaktionen 4 nach Maßgabe dieses Zeitplans 42* für die Ausführung geplant.
Allgemein können im Rahmen der hier beschriebenen Planung gemäß Block 125 anstehende Transaktionen 4 aus einem Pool innerhalb eines Planungshorizonts 6 auf Zeitschlitze 61-64 verteilt werden, in die der Planungshorizont unterteilt ist.
Wie zuvor bereits erläutert, wirkt die Konsensbildung über die Reihenfolge 41 der Ausführung anstehender Transaktionen 4 mit der Konsensbildung über den Belegungszustand von Speicherstellen 31 zusammen. Die bereits vorhandenen Reservierungen von Speicherstellen 31 beeinflussen, welche Transaktionen 4 noch zusätzlich geplant werden können, und die Planung weiterer Transaktionen 4 kann wiederum neue Reservierungen erzeugen.
Innerhalb des Kastens 130 sind beispielhaft verschiedene Möglichkeiten eingezeichnet, wie ermittelt werden kann, auf welche Speicherstellen 31 die Ausführung einer Transaktion 4 einen Zugriff benötigt.
Gemäß Block 131 können aus einer Analyse der in der Transaktion 4 enthaltenen Instruktionen 4b Speicherstellen 31, auf die die Transaktion Zugriff benötigt, ermittelt werden.
Gemäß Block 132 können diejenigen Speicherstellen 31 als benötigt identifiziert werden, an denen Speicherinhalte (etwa Variablen) hinterlegt sind, die in der Transaktion 4 als für die Ausführung der Transaktion 4 benötigt deklariert sind.
Gemäß Block 133 können Reservierungen von Speicherstellen 31 bei der Planung der Ausführung von Transaktionen (etwa gemäß Block 116) explizit angefordert werden.
Gemäß Block 134 kann die maximale Zeitdauer der Reservierung anhand eines der Transaktion 4 zugewiesenen Ressourcenbudgets, nach dessen Verbrauch die Transaktion 4 abgebrochen und zurückgerollt wird, ermittelt werden.
2 zeigt ein stark vereinfachtes Beispiel eines Netzwerks 1 mit einer Vielzahl von Knoten 2. Der in Speicherstellen 31 unterteilte Speicher 3 ist über alle Knoten 2 repliziert und synchronisiert. Einige der Knoten 2 haben darüber hinaus auch noch Verarbeitungseinheiten 8, die auf die Ausführung spezieller Arten von Transaktionen spezialisiert sind.
In dem in 2 gezeigten Beispiel überlappen sich die erste Teilmenge 21 der Knoten 2, die für den Konsens über die Reihenfolge 41 der Ausführung anstehender Transaktionen 4 zuständig sind, und die zweite Teilmenge 22 der Knoten 2, die für den Konsens über die Reservierungszustände 31a, 31b von Speicherstellen 31 zuständig sind. Die dritte Teilmenge 23 der Knoten 2, die für den Konsens über die Ergebnisse 7 der Ausführung von Transaktionen zuständig sind, überlappt sich in dem hier gezeigten Beispiel mit keiner der beiden anderen Teilmengen 21 und 22. Solche Überlappungen sind jedoch ebenfalls zulässig.
3 zeigt einen beispielhaften Ablauf 200 von Transaktionen in einem Netzwerk 1, der aus der Nutzung des Verfahrens 100 resultiert. In diesem Beispiel seien die beiden Teilmengen 21 und 22 der Knoten 2 identisch und die darin enthaltenen Knoten 2 „Speicherknoten“ 2' genannt.
In Schritt 210 des Ablaufs 200 nehmen die Speicherknoten 2' zur Ausführung anstehende Transaktionen 4 entgegen. Die anstehenden Transaktionen 4 können unmittelbar von Benutzern 9 des Netzwerks 1 geliefert werden, aber auch beispielsweise von einem übergeordneten Prozess 10, der seinerseits die anstehenden Transaktionen 4 von Benutzern 9 entgegennimmt. Dieser Prozess 10 kann beispielsweise die anstehenden Transaktionen 4 auf mehrere „shards“ des Netzwerks 1 verteilen. Diese Verteilung kann alternativ oder auch in Kombination wiederum auf der Basis eines Konsenses erfolgen.
In Schritt 220 bilden die Speicherknoten 2' einen Konsens über die Reihenfolge 41 der auszuführenden Transaktionen 4. In Schritt 225 werden die jeweils benötigten Speicherstellen 31, bei denen es sich beispielsweise um mikroskopische physische Speicherzellen handeln kann, in den belegten Zustand 31b versetzt.
Bei der Ausführung einer jeden Transaktion 4 aus der Reihenfolge 41 werden nun die Instruktionen 4b in diesen Transaktionen 4 nacheinander ausgeführt. Dabei gibt es möglicherweise mehrere Zyklen 230 aus Lesen, Verarbeiten und Schreiben von Daten.
Gemäß Block 231 führen die Speicherknoten 2' die Leseoperationen gemäß den Instruktionen 4b aus und gewinnen die in den Speicherstellen 31 abgelegten Daten D. Gemäß Block 232 werden die gemäß den Instruktionen 4b vorgesehenen Berechnungsoperationen mit diesen Daten D von den Speicherknoten an Verarbeitungseinheiten 8 delegiert. Gemäß Block 233 wird über die von den Verarbeitungseinheiten 8 zurückgemeldeten Ergebnisse 7 ein Konsens gebildet und an die Speicherknoten 2' zurückgespielt.
In Block 234 wird nun geprüft, ob die Transaktion 4 atomar (= vollständig oder gar nicht) ausgeführt werden soll. Wenn dies der Fall ist (Wahrheitswert 1), werden die Ergebnisse 7 gemäß Block 235 in einem Zwischenspeicher 11 abgelegt. Soll die Transaktion hingegen nicht atomar ausgeführt werden (Wahrheitswert 0), werden die Ergebnisse 7 gemäß Block 236 in den Speicherstellen 31, für die sie bestimmt sind, abgelegt. Optional können die entsprechenden Speicherstellen 31 gemäß Block 237 wieder freigegeben werden (Zustand 31a), sofern der Zugriff hierauf von der Transaktion 4 nicht länger benötigt wird.
Wenn alle Zyklen 230 abgeschlossen sind, wird gemäß Schritt 240 wiederum geprüft, ob die Transaktion 4 atomar ausgeführt werden soll. Wenn ja (Wahrheitswert 1), werden gemäß Block 241 alle Ergebnisse 7 aus dem Zwischenspeicher 11 in die Speicherstellen 31, für die sie bestimmt sind, übergeben.
Gemäß Block 242 werden alle Speicherstellen 31, die durch die Transaktion 4 in den belegten Zustand 31b versetzt wurden, wieder in den freien Zustand 31a versetzt.

Claims

Verfahren (100) zum Betreiben eines Netzwerks (1) mit einer Vielzahl computerimplementierter Knoten (2), wobei dieses Netzwerk (1) dazu ausgebildet ist, einen über das Netzwerk (1) verteilten und/oder replizierten Speicher (3) sowie die Ausführung von Transaktionen (4) mit Inhalten dieses Speichers (3) zu implementieren, wobei • einer ersten Teilmenge (21) der Knoten (2) die Aufgabe zugewiesen wird (110), einen für das Netzwerk (1) als Ganzes gültigen Konsens über die Reihenfolge (41) zu ermitteln, in der anstehende Transaktionen (4) ausgeführt werden; und • einer zweiten Teilmenge (22) der Knoten (2) die Aufgabe zugewiesen wird (130), einen für das Netzwerk (1) als Ganzes gültigen Konsens darüber zu ermitteln, welche Speicherstellen (31) innerhalb des Speichers (3) zu welcher Zeit für den Zugriff durch weitere Transaktionen (4) zur Verfügung stehen (31a) bzw. für den Zugriff durch bereits für die Ausführung geplante Transaktionen (4) reserviert sind (31b).
Verfahren (100) nach Anspruch 1, wobei mindestens eine Kombination aus einer anstehenden Transaktion (4) und einem für die Ausführung dieser Transaktion (4) beabsichtigten Zeitbereich (4a) validiert wird (111), indem • ermittelt wird (112), auf welche Speicherstellen (31) die Transaktion (4) Zugriff benötigt; • geprüft wird (113), ob diese Speicherstellen (31) in dem beabsichtigten Zeitbereich (4a) für den Zugriff durch die anstehende Transaktion (4) zur Verfügung stehen (31a); • wenn alle Speicherstellen (31) zur Verfügung stehen, die Ausführung der Transaktion (4) in dem beabsichtigten Zeitbereich (4a) akzeptiert wird (114), und • wenn mindestens eine Speicherstelle (31) nicht zur Verfügung steht, die Ausführung der Transaktion (4) in dem beabsichtigten Zeitbereich (4a) abgelehnt wird (115).
Verfahren (100) nach Anspruch 2, wobei aus einer Analyse der in der Transaktion (4) enthaltenen Instruktionen (4b) Speicherstellen (31), auf die die Transaktion (4) Zugriff benötigt, ermittelt werden (131).
Verfahren (100) nach einem der Ansprüche 2 bis 3, wobei in der Transaktion (4) Speicherinhalte deklariert sind, auf die die Transaktion (4) Zugriff benötigt, und wobei Speicherstellen (31), an denen diese Speicherinhalte abgelegt sind, als Speicherstellen (31), auf die die Transaktion (4) Zugriff benötigt, ermittelt werden (132).
Verfahren (100) nach einem der Ansprüche 2 bis 4, wobei eine für die Ausführung in einem beabsichtigten Zeitbereich (4a) akzeptierte Transaktion (4) für diesen Zeitbereich (4a) zur Ausführung geplant (116) und die von dieser Transaktion (4) benötigten Speicherstellen (31) für den Zugriff durch diese Transaktion (4) reserviert werden (133).
Verfahren (100) nach Anspruch 5, wobei eine maximale Zeitdauer, für die die von der Transaktion (4) benötigten Speicherstellen (31) reserviert werden, anhand eines der Transaktion (4) zugewiesenen Ressourcenbudgets, nach dessen Verbrauch die Transaktion (4) abgebrochen und zurückgerollt wird, ermittelt werden (134).
Verfahren (100) nach einem der Ansprüche 2 bis 6, wobei mindestens ein Kandidaten-Zeitplan (42) für die Ausführung einer Mehrzahl von Transaktionen (4) aufgestellt wird (117) und wobei der Kandidaten-Zeitplan (42) validiert wird (120), indem • alle in dem Kandidaten-Zeitplan (42) enthaltenen Transaktionen (4) validiert werden (118, 111), • der Kandidaten-Zeitplan (42) als Ganzes akzeptiert wird (119a), wenn alle validierten Transaktionen (4) akzeptiert werden (119), und • der Kandidaten-Zeitplan (42) als Ganzes abgelehnt wird (119b), wenn mindestens eine validierte Transaktion (4) abgelehnt wird.
Verfahren (100) nach Anspruch 7, wobei • eine Mehrzahl von Kandidaten-Zeitplänen (42) aufgestellt wird (121), • jeder dieser Kandidaten-Zeitpläne (42) validiert wird (122, 120) und • aus den akzeptierten Kandidaten-Zeitplänen (42') ein Zeitplan (42*), der nach Maßgabe eines vorgegebenen Optimalitätskriteriums (5) am besten bewertet wird, ausgewählt wird (123) und • die in diesem Zeitplan (42*) enthaltenen Transaktionen (4) nach Maßgabe dieses Zeitplans (42*) für die Ausführung geplant werden (124).
Verfahren (100) nach einem der Ansprüche 1 bis 8, wobei anstehende Transaktionen (4) aus einem Pool auf Zeitschlitze (61-64) verteilt werden (125), in die ein Planungshorizont (6) für die Ausführung von Transaktionen (4) unterteilt ist.
Verfahren (100) nach einem der Ansprüche 1 bis 9, wobei bei der Ausführung mindestens einer Transaktion (4) mindestens zwei Instruktionen (4b), die keinen Zugriff auf die gleichen Speicherstellen (31) benötigen, parallel ausgeführt werden (140).
Verfahren (100) nach einem der Ansprüche 1 bis 10, wobei • einer dritten Teilmenge (23) der Knoten (2) die Aufgabe zugewiesen wird (150), einen für das Netzwerk (1) als Ganzes gültigen Konsens über Ergebnisse (7) der Ausführung von Transaktionen (4) zu ermitteln und • die Ausführung mindestens einer Transaktion (4) oder in einer Transaktion (4) enthaltenen Instruktion (4b) an eine oder mehrere Verarbeitungseinheiten (8) delegiert wird (160).
Verfahren (100) nach Anspruch 11, wobei mindestens eine Verarbeitungseinheit (8) mindestens einen Grafikprozessor, GPU, eine feldprogrammierbare Gatteranordnung, FPGA, eine vertrauenswürdige Ausführungseinheit, TEE, und/oder eine sichere Enklave mit verschlüsseltem Speicher, umfasst.
Computerprogramm, enthaltend maschinenlesbare Anweisungen, die, wenn sie auf einem oder mehreren Computern ausgeführt werden, den oder die Computer dazu veranlassen, ein Verfahren (100) nach einem der Ansprüche 1 bis 12 auszuführen.
Maschinenlesbarer Datenträger und/oder Downloadprodukt mit dem Computerprogramm nach Anspruch 13.
Ein oder mehrere Computer, ausgerüstet mit dem Computerprogramm nach Anspruch 13, und/oder mit dem maschinenlesbaren Datenträger und/oder Downloadprodukt nach Anspruch 14.