Wie würde sich das Bitcoin-Protokoll auswirken, wenn Knoten nur die Blöcke speichern würden, die ihnen wichtig sind?

Im Moment speichern vollständige Clients des Bitcoin-Netzwerks jeden jemals generierten Block (während „dünne“ Clients stattdessen auf einen Knoten angewiesen sind, der dies tut). Dies erhöht die erstmalige Initialisierung für den Client erheblich und hat unter anderem auch erhebliche Auswirkungen auf den Netzwerk-Overhead. Wie würde sich das Netzwerk auswirken, wenn Knoten stattdessen nur die Header der meisten Blöcke in der Blockchain speichern würden, bis sie den eigentlichen Block „benötigten“?

Diese Situationen sind ziemlich häufig, wie zum Beispiel:

  • Verifizieren der Gültigkeit jedes neuen Blocks, wenn er gefunden und an das Netzwerk übertragen wird
  • Jedes Mal, wenn der Client Bitcoins sendet oder empfängt
  • usw.

so dass Clients im Allgemeinen immer noch alle gesendeten Blöcke herunterladen würden, wenn sie online waren. Sie könnten jedoch:

  • Löschen Sie Blöcke, die ihnen "egal" sind, wenn der Speicherplatz begrenzt ist
  • Beginnen Sie im typischen Fall mit dem Senden und Empfangen von Bitcoins, nachdem Sie nur die wenigen relevantesten Blöcke (und natürlich alle Header) heruntergeladen haben.
  • usw.

Beachten Sie, dass normalerweise mehrere Unternehmen in die fortgesetzte Verfügbarkeit eines bestimmten Blocks „investiert“ sind, wie z. B. der ursprüngliche Miner, der möchte, dass seine verdienten 50 BTC gültig bleiben, und jeder, der Bitcoins aus Transaktionen in diesem Block erhalten hat. Eine faszinierende Konsequenz dieses Szenarios wäre jedoch, dass Bergleute dazu angeregt werden, so viele Transaktionen wie möglich in ihre Blöcke aufzunehmen (derzeit kann man minen, ohne irgendwelche Transaktionen einzubeziehen, wenn man dies wünscht). Was wären die anderen Auswirkungen auf Funktionalität und Sicherheit?

Bearbeiten: Ich suche hier nach einer besseren Antwort als "Ich denke, es würde das Netzwerk destabilisieren" - ich möchte einige geschätzte Auswirkungen auf die Blockverfügbarkeit, den Netzwerk-Overhead nach oben oder unten sehen, sobald die geringere Menge an Downloads mit Re- späteres Herunterladen usw. Einige Statistiken darüber, wie voneinander abhängige Blöcke allein sind, würden einen langen Weg zu einer soliden Antwort beitragen.

Bearbeiten 2: Im Moment geht dieses Kopfgeld in ein paar Stunden an Shadders. Aber wenn jemand detailliertere Informationen zu den Informationen hätte, um die ich in meiner ersten Bearbeitung gebeten habe, könnte er sie definitiv schnüffeln. Irgendwelche Abnehmer?

Dies ist relevant: gist.github.com/1059233
Für diejenigen, die zu faul zum Klicken sind ^ Gavin erwägt die Verwendung dieser Technik, um das Starterlebnis im normalen Client zu verbessern.

Antworten (3)

Derzeit wird an der Machbarkeitsstudie gearbeitet, um dieses Problem zu lösen. Im Wesentlichen durch die Erstellung von Hub-Knoten, die viele tausend Verbindungen verarbeiten können. Diese Hub-Knoten sind tatsächlich ein Proxy, der von einem echten Satoshi-Bitcoin-Daemon unterstützt wird. Dies wird Standard-Bitcoin-Knoten von vielen der Verbindungen befreien, die von diesen „egoistischen“ Knoten verbraucht werden, und es ihnen ermöglichen, so weiterzuarbeiten, wie sie es jetzt tun. Mining-Pools werden einen starken Anreiz haben, Hub-Knoten zu betreiben, da dies die Verbreitung ihrer generierten Blöcke beschleunigt und sicherstellt, dass sie die besten Chancen haben, so schnell wie möglich neue Blöcke zu erhalten.

Ich denke, wenn dies umfangreich würde, würde dies das gesamte Netzwerk destabilisieren. Da das niemand will, wird es nicht umfangreich.

Das Wichtigste, was der Client tut, ist zu entscheiden, was die aktuell gültige Blockchain ist. Angenommen, ich sehe zwei konkurrierende Hash-Ketten im Netzwerk. Woher weiß ich, welchem ​​ich folgen soll? Die Antwort ist, zuerst sicherzustellen, dass beide Ketten gültig sind – eine ungültige Blockchain kann niemals gewinnen. Wie kann ich die Hash-Kette validieren, wenn ich nicht sicherstellen kann, dass jede Transaktionseingabe darin gültig die Ausgabe einer vorherigen Transaktion beansprucht? Wie kann ich das ohne eine vollständige Transaktionstabelle tun?

Angenommen, ich sehe eine Transaktion, die behauptet, jemand habe mir 50 Bitcoins geschickt. Wie kann ich feststellen, dass diese 50 Bitcoins tatsächlich gültig sind? Nun, ich muss sicherstellen, dass jede Eingabe in dieser Transaktion gültig eine Ausgabe aus einer vorherigen Transaktion beansprucht. Wie kann ich das tun, wenn ich nicht über den vollständigen Transaktionssatz verfüge?

Mit anderen Worten, ein Kunde kann nicht feststellen, ob er Geld erhalten hat, wenn er keinen Zugriff auf eine Karte aller nicht beanspruchten Transaktionsausgaben hat, die nach Transaktions-ID indexiert sind.

Es sollte angemerkt werden, dass die Hauptverwendung für solche „egoistischen Clients“ in eingebetteten Geräten liegt, wo nicht nur Speicher, sondern auch Netzwerk- und CPU-Ressourcen hoch im Kurs stehen. Die aktuellen Android-Clients sind alle "egoistisch" und werden es wahrscheinlich noch einige Zeit bleiben. Da die Leute, die Bitcoin auf ihrem Telefon ausführen, mit ziemlicher Sicherheit einen vollständigen Blockchain-Knoten zu Hause haben, werden sie wahrscheinlich keine signifikante Quelle von Netzwerkproblemen sein.
Ich denke, zum Zwecke der Analyse des Bitcoin-Netzwerks können Sie es so behandeln, als ob diese Clients nicht existieren. Sie bringen dem Netzwerk also keinen Nutzen (obwohl sie ihren Benutzern und der Währung insgesamt Vorteile bringen), richten aber keinen Schaden an. Sie sind „egoistisch“, aber ihre Bedürfnisse sind auch ziemlich gering. Sie sind absolut sicher, wenn sie einen "bekannten vertrauenswürdigen" Knoten haben, mit dem sie sich verbinden können.
Das Problem entsteht, wenn diese "egoistischen" Knoten eine solche Mehrheit werden, dass Leute hinter Firewalls usw., die auf 8 Verbindungen beschränkt sind, keinen nicht-egoistischen Client finden können, mit dem sie sich verbinden können. Solche Clients können sicherlich addnodeeinen oder mehrere der Fallbacks verwenden, aber das ist bestenfalls ein schäbiger Workaround.
Hoffentlich wird es bis dahin genug Leute geben, die "großzügige" Knoten betreiben, um den Durchhang auszugleichen. (Ich betreibe mehrere solcher Knoten, die jeweils über 1.500 Verbindungen handhaben können. Die verkehrsreichsten sehen selten mehr als 300.) Jeder hat ein Interesse daran, das Netzwerk stabil und zuverlässig zu halten.
Mit BitcoinJ können Sie solche Clients erstellen. „Wie kann ich die Hash-Kette validieren, wenn ich nicht sicherstellen kann, dass jede Transaktionseingabe darin gültig die Ausgabe einer vorherigen Transaktion beansprucht? Wie kann ich das ohne eine vollständige Transaktionstabelle tun?“ Da BitcoinJ sich mit einem vertrauenswürdigen Knoten verbindet, weiß es, dass empfangene Blöcke validiert wurden, um nur Eingaben zu enthalten, für die es Ausgaben gibt.
Solange der Schwierigkeitsgrad auf einem anständigen Niveau bleibt, ist die Überprüfung der kumulativen Schwierigkeit einer Blockchain anhand ihrer Kopfzeilen ein verdammt guter Indikator dafür, wo man anfangen soll. Was die Validierung von Blöcken oder Transaktionen betrifft, müssten Sie ihre „Abhängigkeiten“ durchgehen. Ich suche hier nach einer besseren Antwort als "Ich denke, es würde das Netzwerk destabilisieren" - ich möchte einige geschätzte Auswirkungen auf die Blockverfügbarkeit, den Netzwerk-Overhead nach oben oder unten sehen, sobald die geringere Downloadmenge später erneut heruntergeladen wird , etc.
Das heißt, einige Statistiken darüber, wie voneinander abhängige Blöcke allein sind, würden einen großen Beitrag zu einer soliden Antwort leisten.

Ist es möglich, dass es in Zukunft ein Geschäft mit Archivdienstleistungen gibt? Vielleicht müssen Leute, die ein sehr altes Bitcoin ausgeben möchten, das älter als x Jahre ist, ein paar Minuten länger warten, damit die Archivserver es nachschlagen. Ich verwende die Analogie des heutigen Bankwesens. Meine Bank hat 90 Tage Online-Aktivität. Wenn ich etwas Älteres will, muss ich es anfordern und warten.