Commits des UTXO-Satzes im Block-Header würden sicherere Lightweight-Clients ermöglichen und die Anzahl der Blöcke begrenzen, die beim Initial Blockchain Download heruntergeladen und validiert werden müssen, was für die Langlebigkeit und Skalierbarkeit von Bitcoin von entscheidender Bedeutung ist, aber mir wurde gesagt UTXO-Commits sind eine technisch sehr anspruchsvolle Änderung im Design von Bitcoin.
Was sind die wichtigsten technischen Herausforderungen bei der Umsetzung der UTXO-Verpflichtungen und welche Lösungen werden dafür vorgeschlagen?
Der Hauptengpass bei der Festlegung auf einen UTXO-Merkle-Root ist, dass die Erstellung und Überprüfung I/O- und CPU-lastig ist. Bis heute ist das serialisierte UTXO-Set etwa 1 GB groß und enthält fast 34000000 Einträge , und es wächst weiter. Dies bedeutet, dass eine naive Implementierung mindestens diese Datenmenge pro Block plus die Zwischenknoten hashen müsste, um einen Merkle-Baum zu erstellen. Dies ist O(n)-Komplexität und wird im Allgemeinen als schlechte Leistung angesehen. Es ist möglich, Caching-Optimierungen zu verwenden, aber das würde mehr RAM verbrauchen.
Eine mögliche Alternative sind UTXO-Unterschiede, die jeder Block einführt. Es funktioniert durch Festschreiben eines Merkle-Roots mit allen UTXOs, die im aktuellen Block ausgegeben wurden, und eines weiteren Roots, das alle hinzugefügten UTXOs auflistet. Für einen SPV-Kunden könnte dies als Betrugsnachweis dienen, wenn es möglich ist zu zeigen, dass eine bestimmte Ausgabe für eine bestimmte Höhe ausgegeben wurde (obwohl es bereits möglich ist, dies mit gewöhnlichen Transaktionen zu zeigen).
Zusammenfassend lässt sich also sagen, dass vollständige UTXO-Merkle-Root-Commitments wirklich nützlich sind, aber aufgrund schlechter Skalierung nicht verwendet werden können.
gettxoutsetinforpc-Befehl ausprobieren, um eine sehr grobe Vorstellung zu bekommen (der hash_serialized ist der Hash der Daten, kein UTXO-Merkle-Baum).
Zauberer von Ozzie
Amin