Blockchain - zeitlos!? (das ist kein Lob)

vorhergehende Artikel in: Rants
01.03.2020

Ich habe erst im letzten Jahr über meine Meinung zu Bitcoin, Ethereum, Iota und dem ganzen Rest geschrieben. Aus aktuellem Anlass nun ein Update...

Ich habe im letzten Artikel zu dem Thema geschrieben, dass ich mich nicht in der Tiefe mit dem Thema Langzeitarchivierung in der Blockchain beschäftigt habe. Neulich kam aber eine Information an mir vorbei, die darauf hinwies, dass das Jahr-2038-Problem bereits jetzt akut sei.

Das erinnerte mich wieder an diese für mich ungelöste Frage und ich habe zunächst nach Antworten für die klassische Variante mittels asymmetrischer Crypto gesucht.

Da man hier - im Gegensatz zu Blockchain - offene und transparente Antworten findet, konnte ich schnell die Quelle der Aussage dafür finden, dass diese Verfahren und insbesondere der X.509 Ansatz kein Jahr-2038-Problem haben können.

Wie sieht das aber nun in der Blockchain aus? Wenn mir vor der Beantwortung dieser Frage noch ein kurzer Exkurs gegönnt sei: Ich habe immer noch kein "Unternehmen" (lies Startup-Klitsche) gefunden, das offen und ehrlich erklärt, warum es die Blockchain-Technologie einsetzt und welches Problem damit gelöst werden soll. Und das Gefasel vom "ewigen, manipulationssicheren Transaktionslog" kann ich ehrlich gesagt nun bald nicht mehr hören: In Bitcoin - und wahrscheinlich auch in anderen Blockchain-Technologien ist es so, dass neue Blöcke nur in Minutenabständen erzeugt werden können. Durch die endliche Anzahl von Transaktionen in einem Block bedingt ergibt das eine Transaktionsrate von 5 pro Sekunde - Visa wickelt mehrere Zehntausende in der gleichen Zeitspanne ab. Wer also behauptet, er könne damit das Internet-of-Things sicherer machen, der lügt: Bei der Menge der Daten, die dort anfallen - und es werden ständig mehr - ist ein solches System völlig überfordert. Man könnte die Zeit zur Ereugung neuer Blöcke verkürzen; das wiederum würde unmittelbar bedeuten, dass das mathematische Rätsel, das Proof-of-work zugrunde liegt zu vereinfachen. Wenn das Rätsel aber einfacher wird, kann es schneller gelöst werden und damit sinkt natürlich die Sicherheit.

Solche Systeme sind auch ansonsten inhärent nicht zukunftssicher: keine Startup-Klitsche wird Garantien über die Zukunft abgeben: Sackt die Anzahl williger Miner durch einen beliebigen Anlass ab, muss die Schwierigkeit bei der Berechnung neuer Blöcke ebenfalls abgesenkt werden um die Frequenz der Erzeugung neuer Blöcke aufrechterhalten zu können - damit haben wir dasselbe Problem wie vorher, nun allerdings dadurch verschärft, dass mit weniger Minern die Wahrscheinlichkeit des Szenarios steigt, dass ein Akteur über 50% der Miningleistung auf sich vereint und damit die Blockkette beliebig manipulieren kann.

Aus allen diesen (und mehr) Gründen ist die Blockchain kein Mittel, Vertrauen zu generieren. Private Blockchains gleich gar nicht, denn dort weiß ich ja schon vorher, dass ein Akteur 100% der Miningleistung kontrolliert (daher das Wort privat ).

Zurück zum Jahr-2038-Problem: Eigentlich haben wir gerade erkannt, dass die Blockchain keine Basis für vertrauen sein kann und damit auch nicht für vertrauenswürdige Zeitstempel - aber sei's drum: Kann ein Block, der heute erzeugt wurde in 39 Jahren immer noch zuverlässig beweisen, dass er heute erzeugt wurde - mit anderen Worten: Kann ich seinen Zeitstempel und seine Entstehungszeit sicher validieren?

Wie sich herausstellt ist das in zweien der wichtigsten Systeme nicht möglich (Fairerweise sei hier angemerkt, dass man hier nicht mehr von Blockchain-Technologie sprechen kann, da jede Implementierung hier ihr eigenes Süppchen kocht): Bitcoin hat zwar kein Jahr-2038-Problem, dafür kommt das Problem des Bereichsüberlaufs später und Ethereum hat zwar einen Timestamp auf Blockebene, allerdings wird dieser durch den Miner gesetzt der den Block erzeugt und ist dabei keinen Checks unterworfen (Bitcoin versucht hier wenigstens, bestimmte Plausibilitätschecks zu fahren, die allerdings eine dermaßen grobe zeitliche Auflösung fahren, dass sie quasi nutzlos sind), so daß der Miner vollkommen absurde Zeiten in den Block einschreiben kann. Ein Beispiel für die Qualitätsansprüche unter denen, die Blockchain-Technologie verkaufen wollen ist dieses Paper - die Autoren schaffen es nicht einmal, die Nummer von RFCs korrekt zu übertragen...[4] Das ist übrigens auch unter einem weiteren Gesichtspunkt ein Argument gegen "Notar-Dienste" basierend auf Blockchain-Technologie: Es muss dabei eine Garantie für die Genauigkeit der Uhrzeit geben - etwas das bei der dezentralen Natur der Blockchain unmöglich ist.

Schön wäre es, wenn wenigstens die Existenz von diesbezüglichen Normen und RFCs unter denen bekannt wäre, die versuchen, diese Systeme an den Mann zu bringen...


Fußnoten

[4]

RFC 3161 wurde inzwischen durch RFC 5816aktualisiert - das ist wichtig, da vor einigen Wochen der Preis für das Knacken von SHA-1 auf unter 100000 Dollar gefallen ist - man beachte außerdem RFC 3628.

Artikel, die hierher verlinken

Die sozialen Medien des Web 1.0

15.09.2021

Na gut - das hier ist nicht wirklich und strenggenommen ein Linux-Thema. Es betrifft schon im eigentlichen Sinne alle Unixe und BSDs und was da noch so kreucht und fleucht und heutzutage kann man sogar einen Finger-Client für Windows selber bauen und Gopher-Browser gibts inzwischen auch für Windows...

Papers März 2021

10.04.2021

Etwas verspätet dieses Mal - aber wie auch schon im Februar - stelle ich hier wieder einige Papers vor.

Blind Signatures, Java, OpenSSL

18.04.2020

Nachdem ich kürzlich wieder einmal meine Meinung zu Blockchains aus Security-Sicht dargelegt habe, wollte ich einen der Aspekte auch praktisch ausprobieren:

Marketing-getriebene Krypto funktioniert nicht

13.04.2020

Ich übe hier hin und wieder Kritik an Blockchain-Themen. Man könnte meinen, dass ich ein Feind dieser Technologie bin

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Certstream, InfluxDB, Grafana und Netflix

    16.04.2019

    Nachdem ich vor kurzem über mein erstes Spielen mit dem certstream berichtete, habe ich weitere Experimente gemacht und die Daten zur besseren Auswertung in eine InfluxDB gepackt, um sie mit Grafana untersuchen zu können.

    Weiterlesen...

Neueste Artikel

  • Die sQLshell ist nun cloudnative!

    Die sQLshell hat eine weitere Integration erfahren - obwohl ich eigentlich selber nicht viel dazu tun musste: Es existiert ein Projekt/Produkt namens steampipe, dessen Slogan ist select * from cloud; - Im Prinzip eine Wrapperschicht um diverse (laut Eigenwerbung mehr als 140) (cloud) data sources.

    Weiterlesen...
  • LinkCollections 2024 III

    Nach der letzten losen Zusammenstellung (für mich) interessanter Links aus den Tiefen des Internet von 2024 folgt hier gleich die nächste:

    Weiterlesen...
  • Funktionen mit mehreren Rückgabewerten in Java

    Da ich seit nunmehr einem Jahr bei meinem neeun Arbeitgeber beschäftigt und damit seit ungefähr derselben Zeit für Geld mit Python arbeite, haben sich gewisse Antipathien gegenüber Python vertieft (ich kann mit typlosen Sprachen einfach nicht umgehen) - aber auch einige meiner Gründe, Python zu lieben sind ebenso stärker geworden. Einer davon ist der Fakt, dass eine Methode in Python mehr als einen Wert zurückgeben kann.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.