…das, was Du da gerade geschrieben hast, hat mich aus den Socken gehauen. DAS hört sich mal richtig interessant an. Vor allem die fett markierten Teile.
Gibt es schon ein Whitepaper o.Ä.? Würde mich da nur all zu gerne näher reinlesen, und eine Idee bekommen, wie die Verifizierung gelöst wird.
Es gibt eine Vage idee und ein Whitepaper was unsere erste Idee in ihren Grundzügen beschreibt.
Natürlich muss das Whitepaper viel detaillierter werden und den Ansatz ausführlich Evaluieren, aber zunächst gilt herauszufinden ob der Ansatz überhaupt etwas taugt.
https://github.com/elastic-project/whitepaper/raw/master/whitepaper.pdfDie Idee ist quasi einen "State-Buffer" mitzuführen, welcher "während der Ausführung eines Programms" mit einer konstanten Rate gefüllt wird. Da SHA256 selber einen Stream aufnehmen kann, kann dieser Buffer quasi direkt in die SHA256 gepipt werden. Ist der Buffer "voll" so wird der resultierende Hash mit einem Targetwert verglichen: erfüllt er gewisse Kriterien z.B. eine gewisse Difficulty so gilt der "Beweis" als akzeptiert.
Das korrekte füllen des Buffers entspricht quasi dem korrekten Ausführen des Programms. Nachdem der Buffer voll ist und die Checks abgeschlossen sind, fängt alles wieder von vorne an; natürlich während das Programm weiter läuft. (ich glaube diese Programmabschlitte zwischen zwei Buffe-Full Events werden im Paper als 10ms Blocks bezeichnet, weil im Raum stand dass die Zeit zwischen zwei vollen Buffern eben 10ms betragen sollte).
Die Verifikation läuft analog dazu: Da der Buffer deterministisch gefüllt wird kann man genau sagen an welcher Stelle des Programms ein Buffer voll geworden ist, geleert wurde und mit der Füllung neu begonnen wurde. Alles was man zur Verifikation braucht ist die Grenze (z.B. als Index des x-ten Buffervorgangs) und den resultierenden Hashwert. So kann man nur durch das Ausführen isolierter kleiner "Teilbereiche" des Programms "stochastisch einigermaßen zuverlässige Verifikationen" erreichen.
Das was jetzt mal ganz vereinfacht erklärt; es gibt noch einige andere fancy countermeasures gegen einige triviale Angriffe ... im Paper steht es detaillierter.
Ich glaube es gibt noch einige Probleme: Was wenn jemand einen Teil des Programms identifiziert, für den er den Buffer schneller "vorhersagen" kann als wenn er den Teil des Programms ausführen müsste (hier wieder die Klassische Faster Algorithm Attacke). Somit könnte er diese "Proofs" signifikant schneller generieren als andere Miner, welche den Programmteil wirklich aufrichtig rechnen.
Die Faster Algorithm Attack ist allgegenwärtig und raubt uns den letzten Nerv ;-)
Wir sind uns ins der Community noch nicht einig ob es nur eine Form von DOS (man kann nur seine eigenen Aufgaben lösen und so sein eigenes Geld von sich selbst verdienen) ist oder ob es wirklich problematisch sein könnte (wenn man von anderen Geld verdient ohne sinnvoll zu arbeiten).
Es ist wirklich sehr schwierig, aber aus der Sicht der Informatik höchst interessant. Schade nur, dass wirklich Interessante Projekte oft nur im Schatten der Ganz-und-Glamor Coins stehen, die das Rad zum x-ten Mal neuerfinden.
Danke für die Ausführungen - ich bin selbst zwar kein Informatiker ("nur" Webentwickler), finde es aber ebenfalls wahnsinnig interessant. Ich werde mich da mal genauer reinlesen (danke fürs Whitepaper) und das Ganze weiter verfolgen.
Dem letzten Satz stimme ich vollkommen zu. Innovation und Genialität ist halt leider nicht das, was die Märkte treibt, sondern Unvernunft und Gier. Das Lösen komplexer Probleme scheffelt dem gierigen Mob halt nicht schnell genug die Taschen voll; die sehen lieber, wie Bobo the Clown™ auf Twitter wütet und versenken ihre Kohle da.
Aber das ist imho auch nicht, was wichtig ist. Langfristig werden gute Ansätze erkannt, aufgegriffen und weitergetragen. Das, was also wirklich einen Unterschied macht, wird auch auf die eine oder andere Art einen Einfluss haben. Und zwar auf eine wesentlich bessere Weise als ein Pump, der zwei Wochen geht, wenigen Leuten die Taschen füllt und danach ein zerstörtes Projekt mit Null verbliebenem Vertrauen und einen großen Scherbenhaufen hinterlässt.
Ich glaube zwar nicht, dass ich erfolgreich sein werde, aber über die Faster Algorithm Attack werde ich mir mal Gedanken machen. Möglicherweise kommt mir ja eine Idee, die in was Brauchbares umgewandelt werden kann.
