Wenn Schnorr-Signaturen Teil von Bitcoin sind, wird es möglich sein, jeden Block mit nur einer Signaturvalidierung zu validieren?

In einem kürzlich gehaltenen Vortrag sprach Pieter Wuille über die Beschleunigung der Überprüfung bei der Verwendung von Schnorr-Signaturen und verschiedene Algorithmen zur Überprüfung mehrerer Signaturen.

Wäre es wirklich möglich, einen einzigen Block zu verifizieren, indem man die Schlüssel und Signaturen aller Transaktionen aggregiert? (Theoretisch noch mehr Transaktionen über mehrere Blöcke)

Ich gehe davon aus, dass dies bedeutet, dass das alte ECDSA-Schema nicht mehr verwendet wird. Wenn wir abwärtskompatibel wären, könnten wir dies wahrscheinlich nur für Transaktionen tun, die Schorr-Signaturen verwenden, während die anderen einzeln verifiziert werden müssten.

(Abgesehen von der Politik drastischer Protokolländerungen) Könnten wir nicht sogar mehr Platz sparen, wenn wir den Blockheader so anpassen, dass er eine aggregierte Schnorre-Signatur für den Block enthält und alle Schnorr-Signaturen der einzelnen Transaktionen innerhalb dieses Blocks weglassen?

Habe ich etwas vergessen? Der Vortrag gab nicht viele Details, sondern erwähnte nur die Idee.

Antworten (1)

Ja, eine Validierung pro Block, aber keine Signatur pro Block.

Um Verwirrung zu beseitigen, es gibt hier 3 verschiedene Technologien:

  • (1) Nicht-interaktive Aggregation ist die Fähigkeit eines Dritten (der keine privaten Schlüssel besitzt), mehrere Signaturen, jede mit ihrer eigenen Nachricht und ihrem eigenen öffentlichen Schlüssel, zu einer einzigen Signatur zu kombinieren, die von jemandem verifiziert werden kann, der alles weiß Nachrichten und öffentliche Schlüssel.
  • (2) interaktive Aggregation ist dasselbe, aber wenn die Unterzeichner sich der Aggregation bewusst sein müssen und miteinander kommunizieren müssen, um gemeinsam eine einzige Signatur zu erzeugen.
  • (3) Batch-Validierung ist die Fähigkeit eines Verifizierers zu überprüfen, ob mehrere (Pubkey, Nachricht, Signatur) Tupel alle gültig sind oder nicht, schneller als die Überprüfung der einzelnen Signaturen. Wenn eines oder mehrere der Tupel ungültig sind, erfährt der Verifizierer in diesem Fall nicht, welche.

Schnorr-Signaturen (und alle anderen bekannten auf diskreten Logarithmen basierenden Signaturschemata) unterstützen (2) und (3), aber nicht (1).

Das Fehlen von (1) bedeutet, dass es keine einzige Signatur für einen ganzen Block (*) geben kann, da der Miner, der den Block konstruiert, ein Dritter ist, der nicht an der Signaturerstellung beteiligt ist.

Aufgrund von (2) ist das Beste, worauf wir hoffen können (solange wir auf DL-basierte Signaturen beschränkt sind), eine Signatur pro Transaktion. Selbst das erfordert eine eingangsübergreifende Aggregation, die über die Implementierung von On-Chain-Schnorr-Signaturen hinaus kompliziert ist (siehe zum Beispiel diesen Beitrag ).

Aufgrund von (3) ist es jedoch richtig, dass es pro Block eine einzige Validierung geben kann , jedoch keine einzige Signatur pro Block. Die Beschleunigung, die durch Batch-Validierung möglich ist, wird tatsächlich nicht trivial. Jede der 4 Zeilen ist eine Optimierungstechnik, die derzeit in libsecp256k1 implementiert ist, die basierend auf der Größe des Problems und den Speicherbeschränkungen die beste auswählt.

Beschleunigung der Batch-Validierung

(*) Es gibt eine Form der nicht interaktiven "halben Aggregation" für DL-basierte Signaturen, bei der N Signaturen nicht interaktiv zu einer einzigen Signatur der Größe (1+N)/2 Originalsignaturen kombiniert werden können. Dies könnte für Blöcke verwendet werden, obwohl die Gewinne nicht so groß sind und es Komplexitäten bei der blockweiten Aggregation gibt, die es weniger interessant machen.

Ich denke, ich muss die Details noch einmal nachlesen, aber war die Idee des Plain-Public-Key-Modells und der Konstruktion von Musig nicht genau das, was eine nicht-interaktive Aggregation möglich machen würde? Oder hätte ich nach Musiksignaturen fragen sollen? Ich dachte, musig ist genau das Schema, das derzeit verwendet werden soll, wenn Leute über schnorr sprechen. Noch nicht richtig ankreuzen, da ich noch offene Fragen habe (was wohl meine Schuld ist)
MuSig ermöglicht eine nicht-interaktive Einrichtung - das Signieren ist immer noch interaktiv.
Und MuSig ist nur eines der Dinge, die Wallet verwenden kann, wenn eine Schnorr-Validierung in der Kette vorhanden ist (weil die Signaturen, die aus der MuSig-Signatur stammen, mit einem Schnorr-Verifizierer kompatibel sind). Es gibt (interaktive Setup-) Konstruktionen, mit denen Sie beispielsweise k-aus-n mit einem einzigen Schlüssel oder sogar beliebigen Und / Oder-Kombinationen von Teilnehmern erstellen können.
"Es gibt eine Form der nicht interaktiven "halben Aggregation" für DL-basierte Signaturen, bei der N Signaturen nicht interaktiv zu einer einzigen Signatur der Größe (1 + N) / 2 Originalsignaturen kombiniert werden können." -- Könnte dies nicht für O(log(N)) Iterationen iteriert werden?
@Martin Schwarz Was meinst du mit iteriert? Die Konstruktion (für Schnorr) besteht darin, dass Sie (R1,s1), ..., (Rn,sn) zu (R1,...,Rn,s) kombinieren, wobei s = H(L,1)*s1 + . .. + H(L,n)*sn und L = H(R1,...Rn,P1,...,Pn,m1,...,mn), und Pi sind die Pubkeys und mi sind die Nachrichten .
Ach, ich verstehe. Okay, das geht nicht.
Gerade heute gesehen – sehr schöne Figur, warum nicht in den Bip-Schnorr einbauen?
Wenn Schnorr-Signaturen Teil von Bitcoin sind, wird es möglich sein, jeden Block mit nur einer Signaturvalidierung zu validieren?
AntwortenHierDatenschutz-Bestimmungen1y, 0v