Das alte Standardtransaktionsformat umfasste 3 Typen: P2PUBKEY, P2PKH, P2SH. Nach Segwit Soft Fork haben wir 2 weitere Typen: P2WPKH und P2WSH.
Wenn wir die Kosten für die Ausgabe von Eingaben (in Bytes, die wir auf die Festplatte schreiben) für P2PUBKEY, P2PKH und P2WPKH vergleichen, erhalten wir die nächsten Werte:
Aus diesem Vergleich können wir schließen, dass P2PUBKEY am besten geeignet ist, um die Blockchain-Größe zu reduzieren. Wir können etwa 19 % der Ausgabengröße einsparen. Ich verstehe, dass P2PKH mehr Sicherheit bietet, falls wir die Adresse nicht wiederverwenden. Wenn wir die Adresse wiederverwenden, hat die Verwendung von P2PKH keine Vorteile. Die recht häufige Verwendung von Adressen können wir immer wieder beobachten. Für einen bestimmten Aufgabenbereich benötigen wir keine zusätzliche Sicherheit wie P2PKH. Warum haben wir in Segwit-Transaktionstypen nicht die Möglichkeit, P2WPUBKEY als Standardtransaktion zu verwenden? Diese Art von Transaktion hilft, die Größe der Blockchain zu reduzieren, falls ein Benutzer das Sicherheitsmodell „keine Wiederverwendung von Adressen“ nicht verwenden muss/möchte? 20 Bytes für jede Eingabe ist dies eine gute Gelegenheit, um die Größe der Blockchain zu sparen.
Außerdem habe ich diesen Thread gelesen https://bitcointalk.org/index.php?topic=6430.0 , was ist der Grund, warum Bitcoin-Core-Entwickler die Wiederherstellung öffentlicher Schlüssel nicht verwenden und 33 Bytes für jede Eingabe sparen möchten? Wenn sich die Bedenken auf die Leistung beziehen, können wir beobachten, wie das Ethereum funktioniert und etwa 1 Mio. tx pro Tag erreicht (das entspricht 1 Mio. Eingaben pro Tag in Bitcoin).
Wenn sich die Bedenken auf die Leistung beziehen, können wir beobachten, wie das Ethereum funktioniert und etwa 1 Mio. tx pro Tag erreicht (das entspricht 1 Mio. Eingaben pro Tag in Bitcoin).
Ethereum ist wirklich kein guter Vergleich, wenn man bedenkt, dass es unmöglich ist, einen vollständig validierenden archivierten Ethereum-Knoten zu synchronisieren.
Unabhängig davon geht es nicht nur um die "Leistung", sondern um das Risiko eines Denial-of-Service-Angriffs. Das Durchführen einer Pubkey-Wiederherstellung ist viel rechenintensiver als das Berechnen eines Hashs von etwas. Daher gibt es möglicherweise einen DoS-Angriff, bei dem ein Angreifer viele Transaktionen mit ungültigen Signaturen erstellt, an denen ein Knoten dann eine Pubkey-Wiederherstellung durchführen muss, nur um die Transaktion zu verwerfen, weil sie ungültig ist. Indem von einem Knoten verlangt wird, dass er viele Berechnungen für ungültige Transaktionen durchführt, kann er daran gehindert werden, eine Überprüfung der tatsächlichen Transaktionen durchzuführen, wodurch verhindert wird, dass der Knoten tatsächlich seine Aufgabe erfüllt.
Bei Schlüssel-Hashes ist dies ein geringeres Risiko, da der Angreifer den Pubkey kennen muss, um einen Knoten dazu zu bringen, beim Schritt der ungültigen Signatur zu brechen. Daher könnte ein Angreifer nicht einfach jede Ausgabe verwenden, die das gleiche Format hat (wie Sie es bei jeder Ausgabe mit Schlüsselwiederherstellung könnten), sondern muss bestimmte Ausgaben verwenden, von denen er die Pubkeys kennt, für die die Anzahl dieser Transaktionen begrenzt werden kann.
bitaps.com
Andreas Chow