Wie erstelle ich einen Multi-Signatur-Wallet-Vertrag?

Grundlegendes zur Multi-Signatur-Wallet-Architektur

1. Ein Multi-Signatur-Wallet-Vertrag basiert auf dem Prinzip, dass mehrere Inhaber privater Schlüssel eine Transaktion vor der Ausführung genehmigen müssen.

2. Ethereum-basierte Implementierungen verwenden typischerweise Solidity, um Schwellenwertlogik zu definieren, z. B. um zu verlangen, dass 3 von 5 Unterzeichnern eine Übertragung bestätigen.

3. Der Vertrag speichert eine feste Liste autorisierter Adressen und erzwingt die Signaturvalidierung durch kryptografische Prüfungen anhand von ECDSA-Signaturen.

4. Jeder vorgeschlagenen Transaktion wird eine eindeutige Kennung zugewiesen und in einer Zuordnung gespeichert, bis genügend gültige Signaturen gesammelt sind.

5. Die Ausführung wird erst fortgesetzt, nachdem die erforderliche Anzahl von Signaturen anhand des Nachrichten-Hashs und der Unterzeichner-Whitelist überprüft wurde.

Kernkomponenten der Vertragslogik

1. Das Eigentümer-Array enthält alle genehmigten externen Konten, die zum Signieren von Transaktionen berechtigt sind.

2. Eine Schwellenwertvariable definiert die Mindestanzahl an Genehmigungen, die für einen Vorgang erforderlich sind.

3. Die Transaktionswarteschlange verwaltet ausstehende Vorgänge mit Statusflags, die angeben, ob sie bestätigt oder abgelaufen sind.

4. Die Signaturüberprüfung basiert auf ecrecover , um Unterzeichneradressen aus kompakten Signaturen wiederherzustellen und sie mit der Eigentümerliste zu vergleichen.

5. Die Gelder werden direkt im Vertragssaldo gehalten, was ihn zu einer Depotadresse macht, die die Kontrolle nicht an externe Verträge delegiert, es sei denn, dies ist ausdrücklich gestattet.

Bereitstellungs- und Initialisierungsprozess

1. Während der Bereitstellung akzeptiert der Konstruktor ein Array von Eigentümeradressen und einen Schwellenwert als unveränderliche Parameter.

2. Der Vertrag gibt ein OwnershipInitialized- Ereignis aus, das alle ursprünglichen Eigentümer und den konfigurierten Schwellenwert auflistet.

3. Es wird keine Fallback-Funktion implementiert, es sei denn, der Vertrag unterstützt ausdrücklich den Empfang von ETH, ohne die Ausführungslogik auszulösen.

4. Der Bereitsteller muss sicherstellen, dass alle Eigentümeradressen vor der Aufnahme außerhalb der Kette überprüft werden, da keine On-Chain-Validierung der Adresslegitimität durchgeführt wird.

5. Die Gasschätzung während der Bereitstellung hängt aufgrund von Speicherschreibvorgängen im Konstruktor stark von der Anzahl der Erstbesitzer ab.

Transaktionsübermittlungs- und Bestätigungsablauf

1. Ein Antragsteller ruft „submitTransaction“ mit Zieladresse, Wert und codierten Aufrufdaten auf und generiert so eine neue Transaktions-ID.

2. Andere Besitzer rufen „confirmTransaction“ mit dieser ID auf und lösen so eine interne Signaturaggregation und Schwellenwertprüfung aus.

3. Sobald der Schwellenwert erreicht ist, führt der Vertrag den Aufruf per Aufruf mit Low-Level-Assembly oder der Syntax „address.call{value: amount}“ aus.

4. Zurückgesetzte externe Anrufe setzen den Bestätigungsstatus nicht zurück. Stattdessen geben sie ein Fehlerereignis aus, während die Signaturdatensätze erhalten bleiben.

5. Transaktionen können vom Antragsteller storniert werden, wenn sie nicht bestätigt werden. Bestätigte Transaktionen können jedoch nach der Genehmigung nicht zurückgezogen oder geändert werden.

Häufig gestellte Fragen

F: Kann ein Multi-Signatur-Wallet ERC-20-Token speichern? A: Ja. Der Vertrag kann ERC-20-Token erhalten, indem er Überweisungen an seine Adresse genehmigt oder Einzahlungsfunktionen nutzt, wenn der Token dies unterstützt. Es leitet Token nicht automatisch weiter, es sei denn, es ist dafür programmiert.

F: Ist es möglich, die Liste der Eigentümer nach der Bereitstellung zu ändern? A: Nur wenn der Vertrag eine Eigentümerverwaltungsfunktion wie addOwner oder removeOwner enthält, die wiederum eine Genehmigung durch mehrere Signaturen erfordert. Unveränderliche Bereitstellungen verhindern jegliche Änderungen.

F: Was passiert, wenn ein Besitzer seinen privaten Schlüssel verliert? A: Dieser Eigentümer wird durch den Signiervorgang nicht mehr funktionsfähig. Wenn die verbleibenden aktiven Unterzeichner immer noch den Schwellenwert erreichen, wird der Betrieb fortgesetzt. Andernfalls könnten die Gelder unzugänglich werden, es sei denn, Wiederherstellungsmechanismen wären vorprogrammiert.

F: Unterstützt der Vertrag zeitgebundene Transaktionen? A: Standard Gnosis Safe oder ähnliche Referenzimplementierungen enthalten Timelock-Module. Barebone-Versionen erzwingen keine Verzögerungen, es sei denn, sie werden explizit durch Modifikatoren hinzugefügt, die block.timestamp überprüfen oder Oracle-basierte Zeitstempel verwenden.