-
Stand der Technik
-
Die vorliegende Offenbarung bezieht sich auf Verfahren zum Bereitstellen einer Blockchain.
-
Mit einem Computer-Arbeitsnachweis beweist ein Nachweiserbringer anderen, sogenannten Verifizierern, dass ein gewisses Maß an Rechenaufwand erbracht wurde. Die Erbringung eines Computer-Arbeitsnachweises kann Lösen einer Computer-Rechenaufgabe umfassen, wobei die Computer-Rechenaufgabe derart konzipiert ist, dass in der Regel (d.h. z.B. im Durchschnitt über eine Vielzahl von Computer-Rechenaufgaben) ein gewisser Zeitaufwand und/oder Rechenaufwand erforderlich ist, um die Computer-Rechenaufgabe zu lösen.
-
Andererseits kann vorteilhafterweise die Computer-Rechenaufgabe derart konzipiert sein, dass eine gefundene Lösung leicht - d.h. z.B. in zu vernachlässigender Zeit und/oder bei zu vernachlässigendem (Computer-)Rechenaufwand - verifiziert werden kann. Dadurch kann leicht geprüft werden, ob der Computer-Arbeitsnachweis erbracht worden ist.
-
Computer-Arbeitsnachweise werden insbesondere für Blockchains verwendet. Durch eine Blockchain kann zum Beispiel (wie beim Bitcoin oder anderen Kryptowährungen) ein dezentraler Übereinstimmungsmechanismus implementiert werden, in dem eine Vielzahl von Schürfern (engl. miners) einen Wettbewerb austragen, um die Blockchain - gegen eine Belohnung - um einen Block erweitern zu dürfen. Die Erfolgswahrscheinlichkeit eines jeden Schürfers ist hierbei proportional zu dem investierten Zeitaufwand und/oder Rechenaufwand (im Verhältnis zum investierten Gesamtrechenaufwand aller weiteren Schürfer).
-
Die Bereitstellung von Blockchains mittels solcher Computer-Arbeitsnachweise führen jedoch zu einem sehr hohen Energieaufwand, der insofern als Energieverschwendung angesehen werden kann, dass der erbrachte Rechenaufwand zur Lösung von Problemen eingesetzt wird, deren Lösung an sich nicht von Interesse ist, sondern nur dazu dient, nachzuweisen, dass der Rechenaufwand erbracht wurde.
-
Es sind deshalb Herangehensweisen zur Bereitstellung einer Blockchain wünschenswert, bei der die für Arbeitsnachweise erbrachte Rechenleistung einem, über die Bereitstellung der Blockchain hinausgehenden, nützlichen (insbesondere technischen) Zweck dient.
-
Offenbarung der Erfindung
-
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Bereitstellen einer Blockchain bereitgestellt, das das Erzeugen, durch einen Nachweiserbringer, eines Blocks für die Blockchain, das Konfigurieren, durch den Nachweiserbringer, eines Software-Testwerkzeugs abhängig von dem erzeugten Block, das Ermitteln, durch den Nachweiserbringer, einer Abdeckung und/oder eines Programmierfehlers in einer Software mittels des konfigurierten Software-Testwerkzeugs und das Veröffentlichen, durch den Nachweiserbringer, der Abdeckung und/oder eines Programmierfehlers als Arbeitsnachweis für den erzeugten Block aufweist.
-
Mit dem oben beschriebenen Verfahren wird ein Computer-Arbeitsnachweis für eine Blockchain erbracht, der - abgesehen von der Bereitstellung der Blockchain selbst - dazu genutzt wird kann, eine Software und insbesondere deren Sicherheit zu verbessern. Die Software kann zum Beispiel dafür ausgelegt sein, ein technisches System zu steuern, zu regeln und/oder zu überwachen. Durch Verbesserung der Software kann somit auch das technische System und dessen Sicherheit verbessert werden. Das technische System kann zum Beispiel eine elektronische Steuereinheit z.B. eines Fahrzeugs sein. In einem anderen Beispiel kann das technische System zum Beispiel ein Computer und die Software dessen Betriebssystem (z.B. Unix/Linux) sein.
-
Die für das Erbringen des Computer-Arbeitsnachweises zu lösende Computer-Rechenaufgabe besteht darin, eine (z.B. noch nicht bekannte) Abdeckung der Software und/oder einen Programmierfehler in der Software zu finden. Für eine hinreichend komplexe Software - ein Kriterium, das in der Praxis leicht zu erfüllen ist - kann das Problem der Abdeckungs- und/oder Programmierfehlerentdeckung nur mit einem gewissen Rechenaufwand gelöst werden. Das Software-Testwerkzeug kann zum Beispiel Fuzzing mit Softwareabdeckungsfeedback durch statische Instrumentierung verwenden. Andererseits kann ein Verifizierer leicht - d.h. z.B. in zu vernachlässigender Zeit und/oder bei zu vernachlässigendem (Computer-)Rechenaufwand - mittels derselben Block-abhängigen Konfiguration des Software-Testwerkzeugs, die der Nachweiserbringer verwendet hat, prüfen, ob die Abdeckung erreicht werden kann und/oder der Programmierfehler in der Software tatsächlich besteht. Hierzu muss der Verifizierer beispielsweise lediglich die erfolgreiche Fuzzing-Iteration ausführen (also die, die angeblich zu der Abdeckung bzw. dem Programmierfehler führt). Weiterhin kann der Verifizierer leicht prüfen, ob die Abdeckung und/oder der Programmierfehler in der Software im Vergleich zu bereits bekannten Abdeckungen und/oder Programmierfehlern neu ist. Somit ist die Abdeckkungs- und/oder Programmierfehlerentdeckung, die für die Entwicklung funktionierender und sicherer Software ohnehin wichtig ist, weiterhin geeignet zur Erbringung eines Computer-Arbeitsnachweises für eine Blockchain. Durch diese Kombination von Computer-Arbeitsnachweisen für Blockchains und Abdeckungs- und/oder Programmierfehlerentdeckung kann im Endeffekt Energie eingespart werden.
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zum Bereitstellen einer Blockchain, wie oben beschrieben.
-
Ausführungsbeispiel 2 ist das Verfahren nach Ausführungsbeispiel 1, ferner aufweisend Empfangen, durch einen Verifizierer, der/des von dem Nachweiserbringer veröffentlichen Abdeckung und/oder Programmierfehlers, Konfigurieren, durch den Verifizierer, des Software-Testwerkzeugs abhängig von dem erzeugten Block, Prüfen, durch den Verifizierer, ob er mittels des konfigurierten Software-Testwerkzeugs die Abdeckung der Software und/oder den Programmierfehler in der Software erreicht und Behandeln des Blocks als validierten Block der Blockchain durch den Verifizierer, wenn er die Abdeckung der Software und/oder den Programmierfehler in der Software mittels des konfigurierten Software-Testwerkzeugs erreicht.
-
Dies ergänzt die Tätigkeit des Nachweiserbringers, sodass die Blockchain sicher ist, da die gelieferten Arbeitsnachweise entsprechend überprüft werden.
-
Ausführungsbeispiel ist das Verfahren nach Ausführungsbeispiel 1 oder 2, wobei der Nachweiserbringer die Software und/oder den Software-Testwerkzeug und/oder die Konfiguration des Software-Testwerkzeugs so wählt, dass er die Abdeckung und/oder den Programmierfehler der Software mittels des konfigurierten Software-Testwerkzeugs innerhalb einer für die Nachweiserbringung vorgegebenen maximalen Anzahl von Testläufen mittels des konfigurierten Software-Testwerkzeugs ermittelt.
-
Der Nachweiserbringer muss also solange die Software, den Software-Testwerkzeug und/oder die Konfiguration des Software-Testwerkzeugs (soweit es für ihm die Nachweiserbringung bzw. die dafür vorgesehene Verifizierung ermöglicht) wählen bzw. wechseln, bis es ihm gelingt, innerhalb der vorgegebenen maximalen Anzahl eine neue (z.B. in einer der Software zugeordneten Dokumentation undokumentierte) Abdeckung oder einen Fehler zu finden. Dadurch wird sichergestellt, dass die Verifikation einfach ist, weil auch der Verifizierer höchstens die vorgegebene maximale Anzahl von Testläufen durchführen muss.
-
Ausführungsbeispiel 4 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 3, wobei der Nachweiserbringer eine Angabe des Software-Testwerkzeugs und/oder der Software zusammen mit dem Arbeitsnachweis veröffentlicht.
-
Damit ist es möglich, aus einem Pool von Software-Testwerkzeugen und/oder einem Pool von Software zu wählen und als Grundlage für den Arbeitsnachweis zu verwenden. Ein Pool von Software-Testwerkzeugen ermöglicht ein gründlicheres Testen der Software (insbesondere, falls eine maximale Anzahl von Testläufen vorgegeben ist) und ein Pool von Software ermöglicht es, zu testende Software nachzuliefern und somit im Laufe der Bereitstellung der Blockchain verschiedene Software, z.B. Computerprogramme für verschiedene Zwecke oder verschiedene Versionen von Computerprogrammen, zu testen.
-
Ausführungsbeispiel 5 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei das Konfigurieren des Software-Testwerkzeugs abhängig von dem erzeugten Block das Festlegen eines Seeds für einen Pseudo-Zufallszahlengenerator des Software-Testwerkzeugs abhängig von dem Block ist.
-
Ausführungsbeispiel 6 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 5, wobei das Konfigurieren des Software-Testwerkzeugs von einem Hashwert des Blocks abhängt.
-
Damit wird verhindert, dass rückgerechnet werden kann und beispielsweise der Nachweiserbringer den Block so verändert, dass das Software-Testwerkzeug einen dem Nachweiserbringer bekannte Abdeckung der Software oder einen dem Nachweiserbringer bekannten Fehler in der Software erreicht (z.B. wenn das Blockchain-Protokoll in dem Block eine Nonce zulässt oder durch Aufnahme einer entsprechenden Transaktion in den Block).
-
Ausführungsbeispiel 7 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 6, wobei das Software-Testwerkzeug ein Fuzzer ist.
-
Ein Fuzzer ermöglicht eine effektive Implementierung des obigen Verfahrens, da er zufällige Eingaben vorsieht, und somit die Eingaben, die er erzeugt, abhängig von dem Block konfigurierbar sind. Es können aber auch andere Software-Testwerkzeuge verwendet werden, bei denen von einer Konfiguration abhängt, ob sie eine bestimmte Abdeckung oder einen bestimmten Fehler finden.
-
Ausführungsbeispiel 8 ist eine Computeranordnung zum Bereitstellen einer Blockchain, die eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 7 durchzuführen.
-
Ausführungsbeispiel 9 ist ein Computerprogramm mit Befehlen, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, bewirken, dass die ein oder mehreren Prozessoren ein Verfahren nach einem der Ausführungsbeispiele 1 bis 7 durchführen.
-
Ausführungsbeispiel 10 ist ein computerlesbares Medium, das Befehle speichert, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, bewirken, dass die ein oder mehreren Prozessoren ein Verfahren nach einem der Ausführungsbeispiele 1 bis 7 durchführen.
-
In den Zeichnungen beziehen sich ähnliche Bezugszeichen im Allgemeinen auf dieselben Teile in den ganzen verschiedenen Ansichten. Die Zeichnungen sind nicht notwendigerweise maßstäblich, wobei die Betonung stattdessen im Allgemeinen auf die Darstellung der Prinzipien der Erfindung gelegt wird. In der folgenden Beschreibung werden verschiedene Aspekte mit Bezug auf die folgenden Zeichnungen beschrieben.
- 1 zeigt eine Architektur zur Bereitstellung einer Blockchain, d. h. einer Computeranordnung (z.B. in Form eines Computernetzwerks) zur Verwaltung und zum Betrieb einer Blockchain.
- 2 veranschaulicht einen Fuzzing-basierten Arbeitsnachweis durch einen Nachweiserbringer und dessen Verifikation durch einen Verifizierer.
- 3 zeigt ein Ablaufdiagramm, das ein Verfahren zum Bereitstellen einer Blockchain veranschaulicht.
-
Die folgende ausführliche Beschreibung bezieht sich auf die begleitenden Zeichnungen, die zur Erläuterung spezielle Details und Aspekte dieser Offenbarung zeigen, in denen die Erfindung ausgeführt werden kann. Andere Aspekte können verwendet werden und strukturelle, logische und elektrische Änderungen können durchgeführt werden, ohne vom Schutzbereich der Erfindung abzuweichen. Die verschiedenen Aspekte dieser Offenbarung schließen sich nicht notwendigerweise gegenseitig aus, da einige Aspekte dieser Offenbarung mit einem oder mehreren anderen Aspekten dieser Offenbarung kombiniert werden können, um neue Aspekte zu bilden.
-
Im Folgenden werden verschiedene Beispiele genauer beschrieben.
-
1 zeigt eine Architektur zur Bereitstellung einer Blockchain 101 d. h. eines Computernetzwerks 100 zur Verwaltung und zum Betrieb einer Blockchain 101.
-
Die Blockchain 101 wird verteilt durch Computer 102, die als Blockchain-Provider-Computer arbeiten und zusammen eine Blockchain-Provider-Anordnung 103 bereitstellen, gespeichert.
-
Endgeräte 104 können auf die Blockchain 101 zugreifen. Dazu sind die Endgeräte 104 und die Computer 102 über Kommunikationsverbindungen eines Kommunikationsnetzes wie dem Internet unter Verwendung eines geeigneten Kommunikationsprotokolls kommunikativ miteinander verbunden.
-
In dem Computernetzwerk 100 können Transaktionsanforderungsnachrichten ausgetauscht werden. Eine Transaktionsanforderungsnachricht kann als eine elektronische Nachricht verstanden werden, die zur Anforderung einer Transaktion verwendet wird. Eine Transaktionsanforderungsnachricht kann von einem Benutzergerät 104 (z. B. einem Benutzergerät, das von einem Benutzer betrieben wird) initiiert werden. Eine Transaktionsanforderungsnachricht kann auch von einem Computer 102 initiiert werden. In der Transaktionsanforderungsnachricht kann einen Empfänger und einen mit einer zugehörigen Transaktion verbundenen Wert, d. h. einen Transaktionswert, angeben. Der Wert kann beispielsweise ein Geldbetrag oder eine Anzahl von Token sein.
-
Die Blockchain-Provider-Anordnung 103 kann mehrere Computer 102 aufweisend (die auch als Blockchain-Provider-Computer bezeichnet werden), von denen jeder Komponenten zur Datenverarbeitung wie einen Prozessor und ein mit dem Prozessor gekoppeltes computerlesbares Medium enthält, wobei das computerlesbare Medium einen vom Prozessor ausführbaren Code zur Durchführung der hier beschriebenen Funktionalität enthält. Eine Datenverarbeitungsvorrichtung kann auch gleichzeitig als Blockchain-Provider-Computer 102 und als Benutzerendgerät 101 arbeiten.
-
Eine Blockchain 101 kann als eine verteilte Datenbank betrachtet werden, die eine kontinuierlich wachsende Liste von Aufzeichnungen führt, die gegen Manipulationen geschützt sind. Eine Blockchain weist eine Reihe von Blöcken mit Transaktionsdatensätzen (im Allgemeinen Interaktionsdatensätze) auf, wobei jeder Block einen Zeitstempel und einen Link zu einem vorherigen Block enthält. Beispielsweise kann jeder Block einen Hash des vorangegangenen Blocks enthalten oder an diesen angehängt werden. Mit anderen Worten: Transaktionsdatensätze in einer Blockchain werden als eine Reihe von Blöcken gespeichert, die eine Aufzeichnung einer Anzahl von Transaktionen enthalten, die in einem bestimmten Zeitraum stattgefunden haben. Ein neuer Block 105 wird von der Blockchain-Provider-Anordnung 103 an die Blockchain 101 angehängt, nachdem sie den Block 105 vervollständigt hat und der Block 105 validiert wurde. Eine Blockchain 101 kann beispielsweise dazu verwendet werden, Transaktionen einer Kryptowährung zu verifizieren und sicher zu protokollieren.
-
Ein Blockchain-Provider-Computer 102, der an der Bereitstellung der Blockchain 101 beteiligt ist, validiert einen Block 105, indem er für den Block einen (Computer-)Arbeitsnachweis erbringt.
-
Ein Computer-Arbeitsnachweis, wie er z.B. für Bitcoin verwendet wird, basiert auf kryptographischen Hash-Kollisionen. Hierbei hat der Nachweiserbringer (z.B. Blockchain-Provider-Computer 102) eine Nonce (d.h. eine vorläufige Zeichenkette, die kurzfristig mit der Absicht gewählt wurde, bald durch etwas Besseres ersetzt zu werden) zu finden und jeweils auf Basis der Nonce einen kryptographischen Hashwert zu berechnen, bis der kryptographische Hashwert ein vorbestimmtes Verifikationskriterium erfüllt. Das Verifikationskriterium kann zum Beispiel (wie beim Bitcoin oder anderen Kryptowährungen) genau dann erfüllt sein, wenn der kryptographische Hashwert eine vorbestimmte Anzahl von führenden Nullen aufweist. Durch einen solchen Mechanismus kann ein Computer-Arbeitsnachweis erbracht werden, wobei die Lösung einer solchen Computer-Rechenaufgabe (abgesehen von dem Nutzen für den dezentralen Übereinstimmungsmechanismus der Blockchain) keinen weiteren Nutzen hat. Je mehr Nachweiserbringer solche Computer-Arbeitsnachweise erbringen, desto mehr stehen diese im Wettbewerb um die begrenzte Ressource der Rechenkapazität. Wie bei Kryptowährungen bereits sichtbar kann das schnell zu einem Wettrüsten bei der Rechenleistung und weiterhin zu einer großen Menge an verschwendeter Energie führen.
-
Deshalb wird gemäß verschiedenen Ausführungsformen ein Arbeitsnachweis erbracht, der auf dem Testen von Software basiert. Ein verifizierbarer Arbeitsnachweis hat dann nicht nur lediglich den Zweck, zu zeigen, dass ein Block 105 gültig ist, sondern erfüllt gleichzeitig den Zweck, eine Software und insbesondere deren Sicherheit zu verbessern.
-
Eine Möglichkeit für ein Software-Testverfahren, dass hierfür verwendet werden kann, ist das Fuzzing (engl. füzzing oder fuzz testing). Dies ist eine automatisierte Technik zum Testen einer Software. Hierbei wird in einer Vielzahl von Fuzzing-Iterationen die Software mit ungültigen, unerwarteten und/oder zufälligen Eingangsdaten ausgeführt und dabei auf Ausnahmen (engl. exceptions) wie Abstürze, fehlgeschlagene eingebaute Code-Zusicherungen (engl. assertions), potenzielle Speicherlecks, etc. überwacht. Für Software, deren Eingangsdaten in einer vorbestimmten Datenstruktur vorliegen müssen, können Fuzzer (engl. fuzzers), die für diese vorbestimmte Datenstruktur ausgelegt sind, zum Einsatz kommen. Die vorbestimmte Datenstruktur ist zum Beispiel in einem Dateiformat und/oder Protokoll spezifiziert. Ein (effizienter) Fuzzer ist dafür ausgelegt, ungültige, unerwartete und/oder zufällige Eingangsdaten in der vorbestimmten Datenstruktur zu generieren, so dass eine Ausführung einer jeweiligen Fuzzing-Iteration der Software ohne Parse-Fehler auf Basis der Eingangsdaten gestartet werden kann. Durch Fuzzing kann insbesondere in komplexer Software (wie z.B. Software für die Steuerung, Regelung und/oder Überwachung eines technischen Systems) unerwartetes Verhalten wie z.B. unerwartete (Programm-)pfade und/oder Programmierfehler sowie Grenzfälle ermittelt werden. Durch ein derart erlangtes besseres Softwareverständnis können die Software und insbesondere deren Sicherheit verbessert werden.
-
Ein Fuzzer erzeugt beispielsweise halb-gültige Eingaben die „gültig genug“ sind, um nicht direkt vom Eingabeparser des zu testenden Programms zurückgewiesen zu werden, aber „ungültig genug“ sind, um unerwartete Verhaltensweisen und Grenzfälle aufzudecken, die im zu testenden Programm nicht richtig behandelt werden.
-
Ein Fuzzer generiert die Eingaben für einen aktuellen Testfall in der Regel auf der Grundlage echter Zufallszahlen, da solche Zufallszahlen sehr schnell erzeugt werden können. Bei der Verwendung mehrerer Fuzzing-Durchläufe (mit derselben Fuzzer, derselben zu testenden Software und derselben Konfiguration) stellt eine wirklich zufällig generierte Eingabe außerdem sicher, dass neue Pfade in einer Art Breitensuche gefunden werden können. Fuzzer wie AFL und LibFuzzer nutzen dies. Fuzzer können jedoch auch pseudozufällig generierte Eingaben verwenden.
-
Im Folgenden wird im Zusammenhang mit Fuzzing verwendete Terminologie beschrieben:
- • Fuzzing oder Fuzz-Testing ist der automatisierte Test-Prozess, zufällig generierte Eingaben an ein Zielprogramm (zu testendes Programm) zu senden und seine Reaktion zu beobachten.
- • Ein Fuzzer oder eine Fuzzing-Engine ist ein Programm, das automatisch Eingaben generiert. Sie ist also nicht mit der zu testenden Software verknüpft, und es wird auch keine Instrumentierung durchgeführt. Es hat jedoch die Fähigkeit, Code zu instrumentieren, Testfälle zu erzeugen und zu testende Programme auszuführen. Bekannte Beispiele sind afl und libfuzzer.
- • Ein Fuzz-Target ist ein Softwareprogramm oder eine Funktion, die durch Fuzzing getestet werden soll. Ein Hauptmerkmal eines Fuzz-Targets sollte sein, dass es potenziell nicht vertrauenswürdige Eingaben annimmt, die vom Fuzzer während des während des Fuzzing-Prozesses erzeugt wird.
- • Ein Fuzz-Test ist die kombinierte Version eines Fuzzers und eines Fuzz-Targets. Ein Fuzz-Target kann dann instrumentierter Code sein, bei dem ein Fuzzer mit seinen Eingaben verknüpft ist (d.h. diese liefert). Ein Fuzz-Test ist ausführbar. Ein Fuzzer kann auch mehrere Fuzz-Tests starten, beobachten und stoppen (normalerweise Hunderte oder Tausende pro Sekunde), jeder mit einer etwas anderen Eingabe, die vom Fuzzer erzeugt wird.
- • Ein Testfall ist eine bestimmte Eingabe und ein bestimmter Testdurchlauf aus einem Fuzz-Test. Normalerweise werden für die Reproduzierbarkeit interessante Läufe (Finden von neuen Codepfaden oder Abstürzen) gespeichert. Auf diese Weise kann ein bestimmter Testfall mit der entsprechenden Eingabe auch auf einem Fuzz-Target ausgeführt werden, das nicht mit einem Fuzzer verbunden ist, z.B. die Release-Version eines Programms.
-
Beim Fuzzing werden für ein zu testendes Computerprogramm Eingaben erzeugt. Je nach Eingabe wird ein bestimmter Ausführungspfad und damit eine bestimmte Abdeckung in dem Computerprogramm erreicht. Um einen Fuzzing-basierten Arbeitsnachweis für Blöcke einer Blockchain 101 zu implementieren, wird gemäß verschiedenen Ausführungsformen sichergestellt, dass das Finden einer neuen Abdeckung (und ggf. eines Fehlers, der dabei erreicht wird) verifizierbar von dem Block abhängt, sodass eine gefundene Abdeckung (bzw. Fehler) mit dem Block verknüpft ist. Dies erfolgt gemäß verschiedenen Ausführungsformen dadurch, dass eine Fuzzer-Konfiguration mit dem Block verknüpft wird, z.B. ein Seed eines Fuzzers aus dem Block deterministisch abgeleitet wird.
-
Dazu wird der Mechanismus für den Fuzzing-basierten Arbeitsnachweis derart ausgestaltet, dass ein Verifizierer (d.h. einer der Computer 102, der einen Arbeitsnachweis für einen Block verifiziert) effizient überprüfen kann, ob der Nachweiserbringer (d.h. einer der Computer 102, der einen Arbeitsnachweis für einen Block für dessen Validierung erbringt) tatsächlich den Block als Grundlage für das Finden der gefundenen Abdeckung mittels Fuzzing verwendet hat. Dazu wird die Verwendung echter Zufallszahlen in dem jeweiligen Fuzzer angepasst, um auf Seiten des Nachweiserbringers Reproduzierbarkeit zu ermöglichen, d.h. es werden ein oder mehrere Fuzzer bereitgestellt, die insbesondere in Hinblick auf die Erzeugung von Eingabedaten für ein zu testendes Programm deterministisch sind. Dies beinhaltet die Verwendung eines Pseudo-Zufallszahlengenerators für die Erzeugung neuer Eingabedaten (inklusive von Erzeugungsstrukturen wie Grammatiken) und Änderung (Mutation) von Eingabedaten für neue Testdurchläufe (inklusive Grey-Box-Fuzzing).
-
2 veranschaulicht einen Fuzzing-basierten Arbeitsnachweis durch einen Nachweiserbringer 201 und dessen Verifikation durch einen Verifizierer 202.
-
In 206 erzeugt der Nachweiserbringer 201 zunächst einen Block 105 für die Blockchain 101.
-
Um zu beweisen, dass er Rechenaufwand für den Block 105 erbracht hat, liefert der Nachweiserbringer 201 die Dokumentation einer Abdeckung oder eines Fehlers in einer spezifizierten Software und die Einstellungen des Fuzzers, mit dem er die Abdeckung oder den Fehler gefunden hat. Um den Arbeitsnachweis zu verifizieren, verifiziert der Verifizierer 202, dass die gefundene Abdeckung oder der gefundene Fehler in der Software erreicht werden kann bzw. vorhanden ist und dass die Abdeckung oder der Fehler unter Verwendung desselben Fuzzers (d.h. desselben Fuzzing-Programms) mit den angegebenen Einstellungen erreicht werden kann. Die Dokumentation eines Fehlers kann dann auch dazu verwendet werden, den Fehler in der Software zu beheben.
-
Zu diesem Zweck wird, z.B. von einer Instanz, die als Herausforderer (engl. challenger) auftritt, eine Datenbank mit einem Software-Pool 204 von zu testender Software (die ggf. fehlerhaft ist) bereitgestellt. Eine Software (z.B. ein Computerprogramm) aus dem Software-Pool 204 dient als Grundlage für den Arbeitsnachweis für den aktuellen (in 206 erzeugten) Block. Der Herausforderer definiert auch einen Pool von Fuzzern, aus dem der Nachweiserbringer 201 einen für den Arbeitsnachweis für den aktuellen Block verwendet. Der Herausforderer kann die Software und den Fuzzer für den aktuellen Block bestimmen.
-
In 207 lädt der Nachweiserbringer 201 die jeweilige Software und initialisiert (konfiguriert) den jeweiligen Fuzzer in Abhängigkeit des in 206 erzeugten Blocks. Neben der Konfiguration in Abhängigkeit des in 206 erzeugten Blocks kann der Nachweiserbringer noch (weitere) Einstellungen des Fuzzers vornehmen.
-
In 208 startet der Nachweiserbringer 201 einen Testdurchlauf mit einer bestimmten Eingabe (d.h. einen Testfall) für die Software mittels des so konfigurierten (und ggf. eingestellten) Fuzzers.
-
Findet der Nachweiserbringer 201 in dem Testdurchlauf keinen neue Fehler oder keine neue Abdeckung in der Software (d.h. ist eine entsprechende Prüfung in 209 negativ), so führt er einen neuen Testdurchlauf für die Software durch, wobei er in 210 mittels des Fuzzers neue Eingaben für die Software erzeugt (d.h. führt einen neuen Testfall durch).
-
Beispielsweise konfiguriert der Nachweiserbringer 201 den Fuzzer in 207 derart, dass der Block, z.B. der Hash des Blocks, einen Seed für den Fuzzer (oder einen anderen Parameter für den Fuzzer) festlegt. Zum Beispiel erzeugt der Fuzzer entsprechend dem Seed eine Folge von Eingabedaten für eine Folge von Testdurchläufen, die der Nachweiserbringer 201 nacheinander durchführt, bis er einen Testdurchlauf durchgeführt hat, bei dem er einen Fehler oder eine neue Abdeckung (d.h. z.B. einen in der Datenbank 203 noch nicht dokumentierten Ausführungspfad) gefunden hat. Findet er nach einer Maximalzahl von Testdurchläufen keine neue Abdeckung (z.B. keinen neuen Ausführungspfad) bzw. keinen neuen Fehler, so kann er vom Herausforderer einen neue Software oder auch einen anderen Fuzzer anfordern oder er ändert die Einstellungen des Fuzzers. Die Maximalzahl kann vorgegeben sein. Für den geringsten Aufwand für den Verifizierer ist die Maximalzahl eins (denn dann braucht der Verifizierer für die durch den Nachweiserbringer angegebene Einstellung des Fuzzers nur einen Testdurchlauf durchzuführen.) Wie (d.h. nach welcher Vorschrift) der Fuzzer abhängig von einem Block zu konfigurieren ist, kann durch ein Protokoll der Blockchain vorgegeben sein, dem sowohl der Nachweiserbringer 201 als auch der Verifizierer 202 folgen. Bestehen dabei Freiheitsgrade für die Konfiguration des Fuzzers abhängig von dem Block, bildet deren Festlegung Teil der Einstellung des Fuzzers und wird von dem Nachweiserbringer 201 mitveröffentlicht.
-
Die Fuzzer aus dem Fuzzing-Pool 205 werden derart ausgestaltet, dass sie abhängig von dem jeweiligen Block (z.B. Hash) Eingabedaten mittels eines Pseudo-Zufallszahlengenerators (PRNGs) erzeugen (z.B. eines aus dem Block abgeleiteten Seeds). Auf diese Weise wird gewährleistet, dass der Verifizierer 202 einen Testdurchlauf, für den der Nachweiserbringer angibt, einen Fehler oder neue Abdeckung gefunden zu haben, reproduzieren kann und damit den Arbeitsnachweis verifizieren kann.
-
Die Block-abhängige Konfiguration des Pseudo-Zufallszahlengenerators wird derart gewählt, dass es einfach ist, Zufallszahlen (bei gegebenem Block) zu erzeugen, aber dass es schwer ist, zurückzurechnen, also sodass sichergestellt ist, dass nicht durch etwas anderes als Fuzzing (z.B. Durchgehen durch den Code der Software) eine Abdeckung oder ein Fehler gefunden werden kann und auf den Inhalt eines Blocks rückgeschlossen werden kann, mit der der Fuzzer für den Block den Fehler oder die Abdeckung erreicht. Dies kann beispielsweise dadurch erreicht werden, dass ein kryptographischer Hash des Blocks als Seed für den Pseudo-Zufallszahlengenerator verwendet wird.
-
Von Testdurchlauf zu Testdurchlauf kann der Fuzzer die Eingabedaten mittels Grey-Box-Fuzzing verändern (mutieren). Um dabei Reproduzierbarkeit auf Seiten des Verifizierers 202 zu gewährleisten, werden gemäß verschiedenen Ausführungsformen die folgenden Operationen durch deterministische Versionen ersetzt: Auswahl des Teils der Eingabedaten, der mutiert werden soll, Auswahl der Mutation und die tatsächliche Mutation.
-
Der Software-Pool 204 enthält deterministische Software, die mittels Fuzzing getestet werden kann (d.h. nicht-deterministische Software ist ausgeschlossen, um die Reproduzierbarkeit auf Seiten des Verifizierers sicherzustellen).
-
Hat der Nachweiserbringer in 209 einen Fehler oder neue Abdeckung in der jeweiligen Software gefunden, veröffentlicht er den Fehler oder die Abdeckung zusammen einer der Angabe des Fuzzers (und ggf. Einstellungen des Fuzzers), falls mehrere zur Verfügung stehen. Dazu kann er in 215 eine Angabe der Abdeckung oder des Fehlers sowie der Einstellungen und des Fuzzers an den Block anhängen und den Block 211 veröffentlichen. Falls die Software nicht öffentlich festgelegt ist, kann er auch eine Angabe der Software mitveröffentlichen.
-
Der Verifizierer 202 kann den Arbeitsnachweis verifizieren, indem in 212 den Block beschafft und die verschiedenen Angaben ausliest, in 213 den angegebenen Fuzzer aus dem Fuzzer-Pool 205 beschafft und ihn mit der angegebenen Konfiguration konfiguriert und sich in 214 die jeweilige Software aus dem Software-Pool 204 beschafft und verifiziert, dass mit dem so konfigurierten Fuzzer die angegebene Abdeckung oder der angegebene Fehler in der Software erreicht werden kann. Bei erfolgreicher Verifikation in 214 kann der Verifizierer darauf schließen, dass der Nachweiserbringer 201 Rechenaufwand investiert hat, um die Abdeckung oder den Fehler zu finden.
-
Ein beliebiger Computer kann unter Verwendung des Blocks die Konfiguration des jeweiligen Fuzzers auf einfache Weise reproduzieren und so als Verifizierer arbeiten. Der Verifizierer 202 muss höchstens eine durch die Maximalzahl von Testläufen gegebene Zahl von Testläufen (Fuzzing-Iterationen) durchführen, während der Aufwand, eine neue Abdeckung oder einen neuen Fehler zu finden, zufällig ist (und evtl. das Testen mehrere verschiedener Computerprogramme erfordert, wenn innerhalb der Maximalzahl von Testläufen in einem Computerprogramm keine neue Abdeckung oder kein neuer Fehler gefunden wird). Deshalb ist das Verifizieren mit erheblich weniger Aufwand verbunden als das Finden einer neuen Abdeckung oder oder eines neuen Fehlers.
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 3 dargestellt.
-
3 zeigt ein Ablaufdiagramm 300, das ein Verfahren zum Bereitstellen einer Blockchain veranschaulicht.
-
Auf Seiten des Nachweiserbringers wird
- • in 301 ein Blocks für die Blockchain erzeugt,
- • in 302 ein Software-Testwerkzeug (d.h. eine Test-Tool, das sowohl Hardware-als auch Softwarekomponenten aufweisen kann, z.B. ein Test-Software-Werkzeug (oder-Tool) z.B. ein Fuzzer) abhängig von dem erzeugten Block konfiguriert,
- • in 303 eine Abdeckung und/oder ein Programmierfehler in einer Software mittels des konfigurierten Software-Testwerkzeugs ermittelt,
- • in 304 die Abdeckung und/oder der Programmierfehler als Arbeitsnachweis für den erzeugten Block veröffentlicht.
-
Auf Seiten des Verifizierers wird
- • in 305 die von dem Nachweiserbringer veröffentliche Abdeckung und/oder der von dem Nachweiserbringer veröffentliche Programmierfehler empfangen,
- • in 306 das Software-Testwerkzeug (dasselbe ggf. entsprechend einer vom Nachweiserbringer veröffentlichten Einstellung identisch eingestellte Software-Testwerkzeug) abhängig von dem erzeugten Block konfiguriert,
- • in 307 geprüft, ob der Verifizierer mittels des konfigurierten Software-Testwerkzeugs die Abdeckung und/oder den Programmierfehler in der Software erreicht
- • in 308 der Block als validierter Block der Blockchain behandelt, wenn er die Abdeckung und/oder den Programmierfehler in der Software mittels des konfigurierten Software-Testwerkzeugs erreicht.
-
Darüber hinaus kann der Nachweiserbringer oder der Verifizierer oder eine dritte Datenverarbeitungsvorrichtung bei einem gefundenen Programmierfehler in der Software eine Korrektur der Software veranlassen.
-
Gemäß verschiedenen Ausführungsformen muss die Abdeckung bzw. der Fehler eine neue Abdeckung bzw. ein neuer Fehler sein in dem Sinne, dass sie noch nicht bekannt sind, z.B. dem Herausforderer oder noch nicht dokument (z.B. in einer vom Herausforderer dem Programm zugeordneten und von ihm gelieferten Dokumentation) sind. Der Verifizierer (und ebenso der Nachweiserbringer) kann dies beim Verifizieren (bzw. der Nachweiserbringer beim Ermitteln) berücksichtigen. Wurde eine Abdeckung oder ein Fehler vom Nachweiserbringer als Nachweis veröffentlicht, ist sie bzw. er nicht mehr neu (und wird z.B. dokumentiert).
-
Die gefundene Abdeckung kann beispielsweise eine Liste von Programmblöcken, Funktionen, Zweigen, oder ein Ausführungspfad sein und vom Nachweiserbringer in dieser Form angegeben werden. Ein Ausführungspfad kann den Pfad von Programmmlock zu Programmmblock, Funktion zu Funktion etc. angeben. Ein Zweig ist durch zwei Programmmblöcke angebbar. Ist die Abdeckung eine Programmmblockabdeckung ist dies beispielsweise eine unsortierte Liste von Programmmblöcken, analog bei der Funktionsabdeckung eine unsortierte Liste erreichter Funktionen. Eine neue Funktionsabdeckung impliziert eine neue Programmmblockabdeckung, diese wiederum eine neue Zweigabdeckung und diese wiederum einen neuen Ausführungspfad (d.h. eine neue Pfadabdeckung).
-
Das Verfahren von 3 kann durch einen oder mehrere Computer mit einer oder mehreren Datenverarbeitungseinheiten durchgeführt werden. Der Begriff „Datenverarbeitungseinheit“ kann als irgendein Typ von Entität verstanden werden, die die Verarbeitung von Daten oder Signalen ermöglicht. Die Daten oder Signale können beispielsweise gemäß mindestens einer (d.h. einer oder mehr als einer) speziellen Funktion behandelt werden, die durch die Datenverarbeitungseinheit durchgeführt wird. Eine Datenverarbeitungseinheit kann eine analoge Schaltung, eine digitale Schaltung, eine Logikschaltung, einen Mikroprozessor, einen Mikrocontroller, eine Zentraleinheit (CPU), eine Graphikverarbeitungseinheit (GPU), einen Digitalsignalprozessor (DSP), eine integrierte Schaltung einer programmierbaren Gatteranordnung (FPGA) oder irgendeine Kombination davon umfassen oder aus dieser ausgebildet sein. Irgendeine andere Weise zum Implementieren der jeweiligen Funktionen, die hierin genauer beschrieben werden, kann auch als Datenverarbeitungseinheit oder Logikschaltungsanordnung verstanden werden. Es können ein oder mehrere der im Einzelnen hier beschriebenen Verfahrensschritte durch eine Datenverarbeitungseinheit durch eine oder mehrere spezielle Funktionen ausgeführt (z. B. implementiert) werden, die durch die Datenverarbeitungseinheit durchgeführt werden.
-
Die Herangehensweise von 3 dient, neben der Bereitstellung einer Blockchain, zum Testen eines Programms, beispielsweise einer Steuersoftware für eine Robotervorrichtung. Der Begriff „Robotervorrichtung“ kann als sich auf irgendein technisches System beziehend verstanden werden, wie z. B. eine computergesteuerte Maschine, ein Fahrzeug, ein Haushaltsgerät, ein Elektrowerkzeug, eine Fertigungsmaschine, einen persönlichen Assistenten oder ein Zugangssteuersystem. Die Steuersoftware kann auch für datenverarbeitende Systeme wie z.B. ein Navigationsgerät verwendet werden.
-
Obwohl spezielle Ausführungsformen hier dargestellt und beschrieben wurden, wird vom Fachmann auf dem Gebiet erkannt, dass die speziellen Ausführungsformen, die gezeigt und beschrieben sind, gegen eine Vielfalt von alternativen und/oder äquivalenten Implementierungen ausgetauscht werden können, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen. Diese Anmeldung soll irgendwelche Anpassungen oder Variationen der speziellen Ausführungsformen abdecken, die hier erörtert sind. Daher ist beabsichtigt, dass diese Erfindung nur durch die Ansprüche und die Äquivalente davon begrenzt ist.
