Warum wird derzeit nicht schon an einen Rückschnitt gedacht?

Ich verstehe, dass Bitcoin in mehreren Bedeutungen skaliert ( Skalierbarkeit ), und Beschneiden ist ein wichtiges Konzept davon ( SE-Frage ). Ich verstehe auch, dass eine "Simplified Payment Verification" (SPV) dem Peer, von dem er die Blockchain bezieht, sehr vertrauen muss.

Ein sehr konservatives Pruning (z. B. Transaktionen älter als sechs Monate und verbraucht) würde nicht viel schaden, insbesondere wenn es nur eine Konfigurationsoption für bitcoin-qt wäre. Auf diese Weise ist der Standardwert der vollständige Knoten, aber es ist einfach, einen "kleinen Knoten" zu haben.

Aber ich sehe es sowieso nicht so bald kommen. Gibt es einen Grund? Ist es im Moment so wichtig, Full Nodes zu haben, dass die Entwickler sagen "entweder alles oder nichts"? Oder ist der Entwicklungsaufwand der Flaschenhals? IMHO ist ein großes Netzwerk von Nicht-SPV-Knoten wichtiger als ein kleines Netzwerk von vollständigen Knoten.

Bearbeiten: Lassen Sie es uns konkreter sagen: Gibt es ein großes Sicherheitsproblem, wenn Sie nicht die vollständige Transaktionshistorie der Welt bis zum Genesis-Block zurück haben?

Antworten (2)

Pruning wird in Betracht gezogen, tatsächlich wurde es beim Entwerfen des 0.8-Datenbankformats berücksichtigt. Die nicht verbrauchten Transaktionsausgaben (die die einzigen wesentlichen Daten sind, die für die Validierung erforderlich sind) werden bereits in einer separaten Datenbank gespeichert, sodass das technische Entfernen alter Blöcke durchaus möglich ist. Wahrscheinlich sind einige kleine Änderungen erforderlich, um sicherzustellen, dass der Code nicht beschädigt wird, wenn nicht mehr vorhandene Blockdaten angefordert werden, aber das ist einfach.

Der Grund, warum es nicht implementiert wird, liegt in der Auswirkung auf das Netzwerk als Ganzes. Wenn eine große Anzahl von Knoten damit beginnt, alte Blockdaten zu entfernen, wird es für neue Knoten, die starten, schwieriger, die zu überprüfenden historischen Daten zu finden. Dies ist an sich kein Problem - ich gehe davon aus, dass genügend Kopien verbleiben werden, dass dies kein echtes Problem ist -, aber wir brauchen einen Erkennungsmechanismus, damit Knoten nicht willkürlich Peers ausprobieren müssen, bis sie zufällig einen erreichen, der die benötigten Blöcke enthält . Tatsächlich wird auf der Bitcoin-Development-Mailingliste über dieses Recht diskutiert .

EDIT: Pruning wurde in Bitcoin Core 0.11 implementiert und ist seit 0.12 voll funktionsfähig.

Das aktuell zu lösende Problem liegt also auf der Netzwerkebene! Nodes haben Find Nodes - mit bestimmten Informationen! DHT klingt für mich sehr vielversprechend, um dieses Problem zu lösen.
Zusatzfrage: Stellen Sie sich vor, wir würden wirklich die historischen Daten verlieren. Würde es Bitcoin stoppen? Oder wäre ein, hm, „Konsens über das Vermögen, obwohl wir nicht wissen, wie wir hierher gekommen sind“.
Vermutlich wäre die Wartung von Knoten, die einen vollständigen Verlauf bieten, teurer als die Wartung von Knoten, die beschnitten wurden. Was ist der Anreiz für jeden, Knoten mit vollständiger Historie auszuführen?
Was ist der Anreiz, überhaupt jemandes Full Node für andere zugänglich zu machen?

AFAIK, alle Transaktionsausgaben werden aus der Datenbank gelöscht, wenn sie ausgegeben werden. Allerdings nicht aus der Bock-Datenbank, aber es macht einfach nicht viel Sinn, es aus der Block-Datenbank zu entfernen, da es die Leistung des Knotens nur verschlechtern würde.

Und Sie können aus ganz offensichtlichen Gründen nicht verbrauchte Ausgaben löschen, egal wie alt sie sind.

Ich glaube, du missverstehst die Frage vielleicht. Es ist sinnvoll, einige/alle Transaktionen aus der Client-Kopie der Blockchain (dh „Blockdatenbank“) zu entfernen, da dies viel Speicherplatz für die Clients sparen würde. Das Protokoll lässt speziell diese teilweise gelöschten Clients (SPV-Clients) zu, deshalb verwendet das Protokoll einen Merkle-Stamm der Transaktionen und keine einfache Liste der Transaktionen. Aber SPV ist zu diesem Zeitpunkt nicht Teil des Standardclients und diese Frage dreht sich wirklich darum, warum das keine Priorität zu sein scheint.
Nun, wenn man bedenkt, dass die gesamte Blockchain jetzt kaum 8 GB groß ist, haben wir offensichtlich ein anderes Verständnis davon, was viel Speicherplatz ist. Wenn Sie Transaktionen aus Ihrer Datenbank entfernen, können Sie außerdem keine Blöcke mehr bedienen, sodass Sie nicht mehr als tatsächlicher Knoten fungieren können.
Dass 8 GB nicht viel Blockplatz für aktuelle Desktops und Laptops sind, ist vielleicht keine schlechte Antwort. (Ich stimme dem etwas zu. Obwohl es wirklich das Herunterladen und Überprüfen ist, das die meisten Probleme zu verursachen scheint, nicht der Speicherplatz selbst.) Mein Kommentar war eher, dass Ihre Antwort etwas nicht gefragtes ansprach, dh das Löschen aus den Nachschlagedatenbanken, wenn die Frage war ziemlich spezifisch über die Blockchain selbst und SPV-Clients. (Außerdem könnte jemand, der einen Laptop mit einer einzelnen 128-GB-SSD verwendet, Ihrer Einschätzung widersprechen, dass 8 GB nicht viel sind.)
Oh, ich dachte, SPV-Clients interessieren sich sogar nur für die Header und ihre Transaktionen, im Gegensatz zu einem Pruning-Knoten, der alle nicht ausgegebenen Transaktionen enthält.
@Gigi: Ja, wenn Sie alte ausgegebene Transaktionen wegwerfen, würde die Welt sie vergessen, wenn sich wirklich alle Knoten so verhalten. Aber was gilt als "nicht in der Lage, als Knoten zu fungieren"?
Zumindest nach meinem Verständnis bedeutet SPV nur, dass der Kunde Transaktionsdetails "on demand" anfordern kann, anstatt sie alle im Voraus herunterzuladen und zu überprüfen. Ein SPV-Kunde kann nur seine eigenen Transaktionen behalten, aber er könnte wirklich jede Teilmenge behalten.
@Borph, mit "nicht in der Lage, als Knoten zu fungieren" meinte ich, dass das Hauptmerkmal eines Bitcoin-Knotens darin besteht, Blöcke für das P2P-Netzwerk bereitzustellen - vollständige Blöcke und alle, beginnend mit # 1. Ich verstehe, dass Sie theoretisch nur Teilblöcke bedienen können (wodurch die ausgegebene Transaktion übersprungen wird), aber das Problem ist, dass das aktuelle Protokoll dies nicht unterstützt. Und wenn Sie das Protokoll ändern und dann sicherstellen möchten, dass alle Knoten aktualisiert werden, bevor Sie beginnen, sie nur mit Teilblöcken zu bedienen ... nun, das wird sicherlich eine Weile dauern; Juni 2025 wäre meine grobe Schätzung :)
Warum wird derzeit nicht schon an einen Rückschnitt gedacht?
AntwortenHierDatenschutz-Bestimmungen1y, 0v