Was sind die Vorteile von Schnorr gegenüber ECDSA?

Ich verstehe, dass Schnorr-Signaturen eine Verbesserung gegenüber ECDSA bieten, da sie feste 64 Bytes anstelle des längeren ECDSA-Sig-Formats sind, aber ich sehe nicht, wie dies in irgendeiner Situation außer Multisig ein Vorteil gegenüber ECDSA ist.

Mit ECDSA können Transaktionen signiert und verifiziert werden, ohne dass der Pubkey des Unterzeichners in die Nachricht aufgenommen werden muss. Schnorr (wie im letzten BIP beschrieben) hat diesen Vorteil jedoch nicht, was bedeutet, dass für jede Transaktion, die nicht von einer Multisig-Adresse stammt, der erforderliche Speicherplatz zum Speichern aller für die Verifizierung erforderlichen Daten unter ECDSA (unter der Annahme einer 64 Byte-Schnorr-Sig mit einem komprimierten 33-Byte-Pubkey im Vergleich zu einer ~71-Byte-ECDSA-Sig ohne Pubkey).

Warum steht Schnorr in diesem Zusammenhang so im Fokus? Machen Multisig-Transaktionen genug von Bitcoins Last aus, dass Schnorr so bedeutend wäre? Und warum wurde wenig bis gar kein Fokus auf die Implementierung von Transaktionen ohne Speicherung von Pubkeys gelegt (was Ethereum die ganze Zeit getan hat)?

Antworten (1)

Ihre Frage scheint anzunehmen, dass das einzige Ziel darin besteht, die Transaktionsgröße auf der Kette zu minimieren. Die Reduzierung der Größe und der damit verbundenen Kosten ist sicherlich etwas, das verbessert werden kann, aber es ist bei weitem nicht das Einzige. Die Hauptvorteile des Schnorr-Vorschlags sind:

  • Besserer Datenschutz , indem verschiedene Multisig-Ausgabenrichtlinien in der Kette nicht unterscheidbar gemacht werden. In Kombination mit Taproot erstreckt sich dies auf so ziemlich alle kooperativen Vertragsausführungen (die zu einer einzigen Unterschrift in der Kette werden, unabhängig von der Komplexität oder Anzahl der Teilnehmer).
  • Ermöglichen einfacherer Protokolle auf höherer Ebene , z. B. Atomic Swaps, die von normalen Zahlungen nicht zu unterscheiden sind. Diese können verwendet werden, um effizientere Zahlungskanalkonstruktionen aufzubauen.
  • Verbesserte Überprüfungsgeschwindigkeit , indem die Stapelvalidierung aller Signaturen in einem Block auf einmal unterstützt wird (für einen Bruchteil der Geschwindigkeit der individuellen Validierung).
  • Umstellung auf eine nachweislich sichere Konstruktion , um möglicherweise in Zukunft einen Exploit gegen ECDSA zu verhindern.

Was Ihren konkreten Vorschlag betrifft, die Wiederherstellung öffentlicher Schlüssel zu verwenden, um die Veröffentlichung des öffentlichen Schlüssels in einer Ausgabe zu vermeiden, gibt es einige Argumente dagegen:

  • Die Wiederherstellung öffentlicher Schlüssel ist mit der Batch-Validierung nicht kompatibel, und wenn die Batch-Validierung ignoriert wird, ist sie (etwas) langsamer als die normale Validierung für sich selbst.
  • Es kann Patente geben, die sich auf die Wiederherstellung öffentlicher Schlüssel beziehen.
  • Die gleiche Größeneinsparung kann einfacher erreicht werden, indem Pay-to-Pubkey anstelle von Pay-to-Pubkeyhash verwendet wird (in Kombination mit Taproot erstreckt sich dieser Vorteil wiederum auf Skripte sowie Einzelschlüsselkonstruktionen).
  • Längerfristige Cross-Input-Signaturaggregation birgt viel größere potenzielle Größeneinsparungen, indem die Gesamtzahl der Signaturen pro Transaktion (nicht nur Transaktionseingabe) auf 1 reduziert wird. Cross-Input-Aggregation ist auch nicht mit der Wiederherstellung öffentlicher Schlüssel kompatibel, obwohl dies derzeit nicht enthalten ist im Schnorr-Vorschlag.

Beachten Sie auch, dass das Fehlen der Wiederherstellung öffentlicher Schlüssel nicht Schnorr eigen ist – es ist ein Ergebnis der Wahl von Schnorr mit Schlüsselpräfix. Es ist besser, es als Kompromiss zwischen 3 Eigenschaften zu sehen:

  1. Linearität : die Fähigkeit, gemeinsam eine Signatur für die Summe öffentlicher Schlüssel zu erzeugen (die Grundlage für alle Schnorr-Multisignaturkonstruktionen).
  2. Fehlende Schlüsselformbarkeit : Mit Schlüsselformbarkeit ist es möglich, eine Signatur für einen vorhandenen öffentlichen Schlüssel zu nehmen und sie in eine Signatur für einen verwandten Schlüssel umzuwandeln (z. B. einen im selben BIP32-Baum).
  3. Wiederherstellung öffentlicher Schlüssel : Die Fähigkeit, einen öffentlichen Schlüssel aus einer Signatur und einer Nachricht zu rekonstruieren.

Bei Schnorr mit Schlüsselpräfix fehlt die Wiederherstellung öffentlicher Schlüssel. Schnorr ohne Schlüsselpräfix leidet unter Schlüsselverformbarkeit. Der ECDSA fehlt die Linearität. Es scheint nicht möglich, ein Signaturschema zu konstruieren, das alle drei enthält.

Können Sie erklären, was Linearität im Zusammenhang mit ECDSA bedeutet?
ECDSA ist nicht linear. Schnorr ist: die Unterschriftsverifikationsgleichung ist sG = R + H(R,P,m)*P. Zwei Personen können sich ihr eigenes R1 und R2 ausdenken und dann Signaturen s1 und s2 erzeugen, die die Gleichung s1G = R1 + H(R1+R2,P,m)*P1 erfüllen, und dann s = s1 + addieren s2, das Ergebnis erfüllt sG = R + H(R,P,M)(P1+P2); dh es ist eine gültige Signatur für die Summe der Schlüssel. Eine solche Konstruktion ist nur möglich, weil die Gleichung in allen Unterzeichnervariablen linear ist: s = k + H(R,P,m)x (mit k = Nonce, x = privater Schlüssel). Für ECDSA ist es sk = m + rx. Die Multiplikation s*k bricht die Linearität.
@PieterWuille Weißt du zufällig, wie schnell Schnorr vs. ECDSA in Bezug auf Überprüfungen pro Sekunde ist? Albert Casademont sagt ( blog.cloudflare.com/… ), dass: rsa 2048 Bit 34423,4 Verifizierung/s und 256 Bit ecdsa (nistp256) 4500,6 Verifizierung/s. Was können wir hier (grob) von Schnorr erwarten?
@Martin Die einzelne (nicht Batch-) Schnorr-Überprüfung kommt der ECDSA in ihrer Leistung sehr nahe. Auf relativ neuer Hardware kann libsecp256k1 über 10000 Sigs/s verifizieren.
@PieterWuille Wie schnell ist es, einen Block mit nur Schnorr über einen Block mit nur ECDSA zu validieren?
Die Signaturvalidierung wird wahrscheinlich um den Faktor 2x schneller sein, aber die Blockvalidierung besteht nicht nur aus Signaturen, und die Details hängen stark von der Implementierung ab. Das Verhältnis zwischen Einzel- und Batch-Validierung war früher in libsecp256k1 größer, aber allgemeine Leistungsverbesserungen haben den Nutzen leicht verringert (indem die Einzelvalidierung mehr profitiert als die Batch-Validierung).
Was sind die Vorteile von Schnorr gegenüber ECDSA?
AntwortenHierDatenschutz-Bestimmungen1y, 0v