Eine Bitcoin-Soft-Fork-Idee, um die Blockchain zu komprimieren

Warum zwingen wir Miner nicht, die Höhe des TX-Merkle-Baums in die ersten beiden Bytes der 4-Byte-Block-Header-Version einzubetten?

Das wäre eine vernünftige Softfork, aber es müsste berücksichtigt werden, dass aufgrund von BIP65 die Blockversion (die eine vorzeichenbehaftete Ganzzahl ist) mindestens 4 sein muss, was sie auf 2^31-4 Werte beschränkt. Die Aufrechterhaltung der Kompatibilität mit BIP9 und möglicherweise BIP340, die bestimmten Bits in der Versionsnummer Bedeutung zuweisen, würde die Dinge weiter verkomplizieren.

Außerdem ist es schwierig, Miner davon zu überzeugen, in einer Änderung, die die Sache für sie kompliziert, Softforks vorzunehmen, was bedeutet, dass es ohne einen erfolgreichen Druck im UASF-Stil unwahrscheinlich ist, dass dies angenommen wird.

Es würde die Brute-Force-Schwäche des Blattknotens (CVE-2017-12842) beheben, die derzeit nur durch Standardregeln, aber nicht durch Konsensregeln behoben wird.

In der Tat! Ich denke, eine Konsensänderung, die stattdessen eine minimale Transaktionsgröße erzwingt, ist wahrscheinlich weitaus weniger invasiv.

Ähnlich wie bei der Beschreibung in BIP 141 können wir einen Knotentyp einführen, der weder ein beschnittener Knoten noch ein vollständiger vollständiger Knoten ist, aber für Transaktionen mit nicht verbrauchten Ausgaben txindex=1 hätte. Diese Knoten würden zuerst ganze Blöcke speichern. Wenn der nächste Block kommt, würden sie mit ihrem txindex den Block nachschlagen, die Transaktion finden und prüfen, ob alle Ausgaben ausgegeben werden. Wenn ja, würden sie die Transaktion aus dem Speicher dieses Blocks entfernen, aber nur ihren Hash behalten. Dies würde viel Platz sparen, da es mir scheint, dass die meisten Szenarien zum Abfragen eines txindex-fähigen Knotens gettransaction für Transaktionen mit nicht ausgegebenen Ausgaben verwenden würden?

Ich sehe nicht, wie diese Änderung mit dieser möglichen Betriebsweise zusammenhängt. Was auch immer Sie vorschlagen, zu dem sich Blöcke in ihrem Header verpflichten, es kann stattdessen einfach von Knoten erinnert werden, wenn sie einen Block zum ersten Mal validieren, ohne Konsensänderung. Wenn ein Knoten vor Ort selbst validiert hat, wie viele Transaktionen sich tatsächlich im Block befinden, wird er sich niemals von etwas anderem überzeugen.

Ich glaube auch nicht, dass dieser Modus irgendwelche Vorteile hat. Es teilt die Langsamkeit der Prä-UTXO-Modellvalidierung(*) mit der fehlenden Fähigkeit, vollständige Blöcke bereitzustellen (wie aktuell beschnittene Knoten), während es weitaus mehr Speicherplatz verbraucht (es müsste jede Transaktion vollständig halten, von der mindestens eine ungenutzt ist). Ausgabe, anstatt nur die nicht verbrauchten Ausgaben selbst zu behalten).

(*) Vor Bitcoin 0.8 gab es anstelle eines Blockchain + UTXO-Sets eine Blockchain + einen Index in dieser Kette für jede Transaktion + einen booleschen Wert für jede Ausgabe, ob sie ausgegeben wurde oder nicht. Dies war langsam, da es bedeutete, dass der Arbeitssatz (Daten, auf die der Code häufig zugreift) effektiv die gesamte Blockchain war (wobei für jede ausgegebene Eingabe viele zufällige Suchvorgänge durchgeführt wurden). In dem in 0.8 eingeführten UTXO-Modell wird das UTXO-Set unabhängig von der Blockchain gehalten (es enthält keine Zeiger in die Blockchain; es enthält eine Kopie aller UTXOs), was ein effizientes Caching nur der UTXOs ermöglicht und die Blockchain hübsch macht für den normalen Betrieb nicht erforderlich (außer das Bereitstellen von Blöcken an andere Peers oder das erneute Scannen). Dieses Modell ermöglichte auch das Pruning, da die Blockchain selbst nicht mehr zur Validierung verwendet wird.