Ich denke, die große Diskrepanz besteht darin, dass die meisten Normies nicht wissen, was die UTXO-Setgröße ist, sie verstehen nur die "Blockgröße". Vereinfacht ausgedrückt wirkt sich die Größe der Blockchain (d. h. die Gesamtgröße aller Blöcke) nur auf die anfängliche Synchronisationszeit aus, wenn ein Knoten von Grund auf neu eingerichtet wird. Diese kann um maximal 4 MB pro Block wachsen (realistisch um die 2 MB). Theoretisch müssen Sie einen Knoten nur einmal in Ihrem Leben von Grund auf neu synchronisieren... Bei neuen Knoten können Sie die Synchronisierung überspringen, indem Sie ein UTXO-Set herunterladen und dann überprüfen, ob Ihr neuer Knoten den gleichen UTXO-Set-Hash wie einer Ihrer älteren Knoten hat. Sie müssen nicht alle Blöcke lagern, und das sollten Sie auch nicht, es sei denn, Sie haben einen ziemlich guten Grund. Die Optimierung der Blockchain-Größe reduziert also nicht wesentlich die Mindestressourcen, die für den Betrieb eines Knotens erforderlich sind. Im besten Fall reduziert es die Bandbreitennutzung leicht. Wenn Sie alle Blöcke speichern, sollten Sie aufgrund der aktuellen Konsensregel auf jeden Fall eine Erhöhung von 2 MB pro Block für die Planung Ihres Hardware-Upgrades einplanen. Wichtiger als die Blockchain-Größe ist es, was jeder speichern MUSS: Die UTXO-Set-Größe. Entwickler interessieren sich viel mehr für die Größe des UTXO-Sets, da es den Mindestspeicher bestimmt, der zum Ausführen eines vollständigen Knotens erforderlich ist. (Ein "Full Node" bedeutet, dass Sie alle Blöcke verifizieren, nicht unbedingt alle speichern.) Das UTXO-Set war früher etwa 4 GB groß. Aufgrund von Einschreibungen und BRC-20 ist es auf etwa 12 GB angewachsen. Das UTXO-Set speichert keine OP_RETURN Daten oder Signaturen. Wenn Sie möchten, dass Ihr Knoten auf kleinen Geräten reibungslos läuft, konzentrieren Sie sich auf die Minimierung der UTXO-Set-Größe, nicht auf die Blockchain-Größe. Und das ist der Grund, warum sich viele Entwickler nicht wirklich um OP_RETURN Grenzen kümmern.