Warum speichert nicht jeder Knoten nur einen Teil der Blockchain?
Wenn Sie beispielsweise 100 Knoten hätten, würde jeder Knoten 10 % der Blockchain speichern. Dies würde zu einer erheblichen Überschneidung jedes Aspekts der Blockchain führen, und wenn Knoten kommen und gehen, würde die gemeinsame Nutzung der Blockchain erhöht oder verringert.
Ist es unmöglich? Wenn ja warum? Ich bin daran interessiert, dies als Projekt zu verfolgen, weil ich denke, dass es viele Skalierbarkeits-/Dezentralisierungsprobleme von Bitcoin lösen könnte.
Nehmen wir nach meinem Verständnis der Blockchain an, dass ein bestimmter Knoten am Genesis-Block beginnt. Nehmen wir an, ein anderer Knoten speichert 1 % der Blockchain nach dem Genesis-Block. Könnten nicht mehrere Knoten Block-Hashes für ihre gemeinsamen 9 % mit einer Rate von einmal alle 10 Minuten überprüfen? Es würde nicht wirklich so viele Daten verbrauchen – Sie könnten die 9 % der Blockchain auf einen bestimmten Wert hashen, einen öffentlichen Schlüssel erzeugen und sehen, ob die anderen Knoten einen privaten Schlüssel mit diesem öffentlichen Schlüssel abgleichen können.
Eine verwandte Frage: Ist das das, was Electrum tut? Oder speichert Electrum einfach die gesamte Blockchain auf mehreren Servern, mit denen Sie sich verbinden können?
Warum speichert nicht jeder Knoten nur einen Teil der Blockchain?
Dies wurde bereits früher vorgeschlagen und ist mit Bitcoin möglich, aber es ist nicht klar, wie es ausgeführt werden würde. Die Blöcke sind kein wichtiger Teil eines laufenden Knotens, für die meisten Leute können Sie sie wegwerfen, sobald Sie sie in Ihre UTXO-Datenbank verarbeitet haben.
Das Problem entsteht, wenn entschieden wird, welche Teile gespeichert werden sollen, und anderen Personen im Netzwerk signalisiert wird, dass Sie eine bestimmte Teilmenge von Blöcken haben. Sie können keine Liste von Hashes ankündigen, da dies massiv und ineffizient wäre (viele Megabyte für jeden Peer), und eine deterministische Zufallsauswahl zu treffen, ist äußerst problematisch. Die Auswahl von Blockbereichen ist nicht ideal, da die Größen nicht konsistent sind. 1.000 Blöcke am Anfang der Kette sind Server, die um Größenordnungen kleiner sind als diejenigen an der Spitze. In einer naiven Implementierung von Zufallsauswahlen müssen Peers, die versuchen, sich mit dem Netzwerk zu synchronisieren, möglicherweise Tausende von Verbindungen herstellen, um einen einzelnen Peer zu finden, der einen bestimmten Block hat, was offensichtlich nicht machbar ist.
Nehmen wir nach meinem Verständnis der Blockchain an, dass ein bestimmter Knoten am Genesis-Block beginnt. Nehmen wir an, ein anderer Knoten speichert 1 % der Blockchain nach dem Genesis-Block. Könnten nicht mehrere Knoten Block-Hashes für ihre gemeinsamen 9 % mit einer Rate von einmal alle 10 Minuten überprüfen? Es würde nicht wirklich so viele Daten verbrauchen – Sie könnten die 9 % der Blockchain auf einen bestimmten Wert hashen, einen öffentlichen Schlüssel erzeugen und sehen, ob die anderen Knoten einen privaten Schlüssel mit diesem öffentlichen Schlüssel abgleichen können.
Dies ist nicht notwendig und sehr anfällig für Sybil-Angriffe. Sie müssen Blöcke nicht überprüfen, sobald Sie sie gesehen haben. Beschnittene Knoten funktionieren heute so, nur dass sie jeden Block wegwerfen und absolut nichts mehr speichern, als sie für wund angegeben sind. Sie geben nicht bekannt, welche Blöcke sie haben, weil es dafür keinen Mechanismus gibt.
Vielleicht möchten Sie sich darüber informieren, wie der Autoprune-Patch funktioniert, und sich ein besseres Bild von den Bedrohungsmodellen machen, die hier angegangen werden müssen. Sie haben einige der Vorgänge leicht verpasst, beachten Sie, dass das Pruning für Nodes Nodes nicht wie im Whitepaper beschrieben funktioniert, das UTXO ist ein neues Konzept, das in der Ära 0.8.0 von Bitcoin Core hinzugefügt wurde.
Eine verwandte Frage: Ist das das, was Electrum tut?
Überhaupt nicht, Electrum-Server sind ein vollständiger Knoten und ein extrem starker adressbasierter Index, der die Speichergröße fast verdoppelt. Der Client ist leicht, aber der Server ist es definitiv nicht. Es gibt keine vernünftige Möglichkeit, diese Indizes fragmentiert zu verwalten, obwohl Sie Adressen in mehrere Pools aufteilen und hoffen könnten, dass die Leute genug von jedem Shard verwalten, damit Clients Abonnements für alle ihre Adressen anfordern können. Idealerweise würden Systeme entworfen, die keine vollständigen Indizes benötigen, da es immer unhandlicher wird, mit ihnen zu arbeiten.
So etwas wurde in v0.11.0 im Bitcoin Core-Client implementiert und veröffentlicht. Es heißt Pruning und Sie können jetzt mit der Option -prune angeben, wie viele Blockchain-Daten Sie speichern möchten.
-prune=N: where N is the number of MB to allot for raw block & undo data
Dies funktioniert in Bezug auf das Wallet noch nicht, sodass Sie beim Pruning das Wallet im Core-Client nicht verwenden können. Es stoppt auch die Weiterleitung, obwohl sie an Möglichkeiten arbeiten, dies zu integrieren, damit Knoten weiterhin Blöcke weiterleiten können.
Dies bedeutet jedoch nicht, dass Nodes einen anderen Teil der Blockchain speichern.
Beachten Sie, dass ein neuer Knoten im Pruning-Modus weiterhin alle Blöcke herunterladen und sich durch alle Blöcke arbeiten wird, aber nicht alle alten Blöcke behalten wird.
Soweit ich weiß, wird dies aktualisiert, um die Verwendung der Brieftasche in Zukunft im Pruning-Modus zu unterstützen. BEARBEITEN: Anscheinend unterstützt der Master-Zweig des Bitcoin-Kerns bereits die Verwendung der Brieftasche im Pruning-Modus.
BT
Claris
BT
BT