Die partielle Signierung ermöglicht es mehreren Parteien, dieselbe Transaktion zu unterschiedlichen Zeiten oder auf verschiedenen Geräten zu signieren. Ein Koordinator erstellt die Nachricht, jeder erforderliche Signer signiert die exakt serialisierten Nachrichtenbytes, und der Koordinator verifiziert und führt die Signaturen vor dem Absenden zusammen.
Signaturen autorisieren Bytes, nicht die Absicht
Wenn Sie den Fee Payer, den Blockhash, die Reihenfolge der Anweisungen, die Kontenliste oder beliebige instruction data ändern, entsteht eine andere Nachricht, und alle bereits gesammelten Signaturen werden ungültig.
Ablauf der partiellen Signierung
- Einigen Sie sich auf die Anweisungen der Transaktion und darauf, wer die Fee bezahlt.
- Legen Sie die Lebensdauer der Transaktion und den Fee Payer fest.
- Serialisieren Sie die Nachricht nur einmal. Behandeln Sie diese Bytes als unveränderlich.
- Verteilen Sie die Nachrichtenbytes und eine für Menschen lesbare Zusammenfassung an jeden Signer.
- Sammeln Sie jede Ed25519-Signatur und verifizieren Sie sie anhand derselben Nachrichtenbytes.
- Ordnen Sie die Signaturen den jeweils erforderlichen Signer-Adressen zu.
- Prüfen Sie, ob jede erforderliche Signatur vorhanden und gültig ist, und senden Sie die Transaktion dann ab.
Vollständiges Beispiel
Der Fee Payer und der SOL-Sender unten signieren unabhängig voneinander. Der Koordinator verifiziert beide Signaturen, führt sie zusammen und sendet die fertige Transaktion ab.
Das Beispiel verwendet rohe Ed25519-Signierung, um die Grenze zwischen dem Koordinator und jedem Signer explizit zu machen. Eine Wallet, ein Hardwaregerät, ein Custody- Dienst oder ein Offline-Signer kann jedes lokale keypair ersetzen, solange er dieselben Nachrichtenbytes signiert.
Die Nachricht vor dem Signieren fixieren
Jede Signatur deckt die serialisierte Transaktionsnachricht ab. Die Nachricht enthält Folgendes:
- den Fee Payer
- den aktuellen Blockhash oder den Durable Nonce
- jede Programm- und Kontenadresse
- Signer- und Schreibberechtigungen der Konten
- Reihenfolge der Anweisungen und instruction data
Erstellen Sie zuerst diese Felder, serialisieren Sie die Nachricht nur einmal und verteilen Sie dieses Byte- Array an jeden Signer. Es ist sinnvoll, zu jeder Signieranfrage einen Digest der Nachricht zu speichern, damit der Koordinator eine Signatur ablehnen kann, die für eine andere Nachricht zurückgegeben wurde.
Deserialisieren Sie eine Nachricht nicht, um sie zu ändern, und erwarten Sie nicht, dass zuvor gesammelte Signaturen gültig bleiben. Selbst eine scheinbar betriebliche Änderung, etwa das Ersetzen eines abgelaufenen Blockhashs oder das Ändern des Fee Payers, erfordert, dass jeder Signer erneut signiert.
Den Fee Payer abstimmen
Der Fee Payer ist immer ein erforderlicher Signer und muss festgelegt werden, bevor die Nachricht fixiert wird. Stellen Sie sicher, dass das Konto genügend SOL für die Basis-Fee und eine etwaige priority fee enthält. Wenn ein Sponsor oder Backend die Fee bezahlt, tragen Sie diese Adresse in die Nachricht ein, bevor Sie die Signatur des Nutzers einholen; wird der Sponsor später hinzugefügt, ändern sich die signierten Bytes.
Der Koordinator sollte prüfen, ob eine eingehende Signatur zu einer Adresse gehört, die als erforderlicher Signer aufgeführt ist. Akzeptieren Sie niemals einen beliebigen öffentlichen Schlüssel, um ihn an die Transaktion anzuhängen.
Die Lebensdauer der Transaktion verwalten
Eine Transaktion mit aktuellem Blockhash ist nur gültig, solange ihr Blockhash in der Warteschlange der aktuellen Blockhashes der
Validatoren verbleibt. Bevor Sie einen Signierablauf mit mehreren Parteien starten,
schätzen Sie ab, ob alle Signer vor lastValidBlockHeight antworten können.
Läuft der Blockhash ab, erstellen Sie eine neue Nachricht mit einem frischen Blockhash und sammeln alle Signaturen erneut. Für Workflows, die länger dauern oder Offline- Signer einbeziehen, verwenden Sie einen Durable Nonce. Ein Durable Nonce umgeht das Zeitfenster des aktuellen Blockhashs, aber wenn dieser Nonce vorgerückt oder anderweitig verbraucht wird, wird die ausstehende Transaktion trotzdem ungültig.
Vor dem Absenden verifizieren
Für jede zurückgegebene Signatur:
- Verifizieren Sie die Signatur anhand der fixierten Nachrichtenbytes und des öffentlichen Schlüssels des erwarteten Signers.
- Ordnen Sie sie dem slot dieses Signers im Signatur-Array der Transaktion zu.
- Prüfen Sie, ob die zusammengesetzte Transaktion gültige Signaturen für jeden erforderlichen Signer enthält.
- Senden Sie die serialisierte Transaktion ab, ohne ihre Nachricht neu zu erstellen.
Bestätigen Sie nach dem Absenden anhand derselben Lebensdauerinformationen, die in der signierten Nachricht enthalten waren. Meldet die Bestätigung einen abgelaufenen Blockhash oder einen verbrauchten Nonce, versuchen Sie es nicht erneut mit einer geänderten Transaktion; starten Sie den Signierablauf neu.
Is this page helpful?