Comment créer un contrat de portefeuille multi-signatures ?

Comprendre l'architecture du portefeuille multi-signatures

1. Un contrat de portefeuille multi-signatures fonctionne sur le principe selon lequel plusieurs détenteurs de clés privées doivent approuver une transaction avant son exécution.

2. Les implémentations basées sur Ethereum utilisent généralement Solidity pour définir une logique de seuil, par exemple en exigeant que 3 signataires sur 5 confirment un transfert.

3. Le contrat stocke une liste fixe d'adresses autorisées et applique la validation des signatures via des contrôles cryptographiques par rapport aux signatures ECDSA.

4. Chaque transaction proposée se voit attribuer un identifiant unique et est stockée dans un mappage jusqu'à ce que suffisamment de signatures valides soient collectées.

5. L'exécution ne se poursuit qu'après vérification du nombre requis de signatures par rapport au hachage du message et à la liste blanche des signataires.

Composants essentiels de la logique contractuelle

1. Le tableau des propriétaires contient tous les comptes externes approuvés éligibles pour signer des transactions.

2. Une variable de seuil définit le nombre minimum d'approbations nécessaires pour toute opération.

3. La file d'attente des transactions maintient les opérations en attente avec des indicateurs d'état indiquant si elles sont confirmées ou expirées.

4. La vérification des signatures s'appuie sur ecrecover pour récupérer les adresses des signataires à partir des signatures compactes et les comparer à la liste des propriétaires.

5. Les fonds sont détenus directement dans le solde du contrat, ce qui en fait une adresse de garde qui ne délègue pas le contrôle à des contrats externes, sauf autorisation explicite.

Processus de déploiement et d'initialisation

1. Lors du déploiement, le constructeur accepte un tableau d'adresses de propriétaires et une valeur seuil comme paramètres immuables.

2. Le contrat émet un événement OwnershipInitialized répertoriant tous les propriétaires initiaux et le seuil configuré.

3. Aucune fonction de secours n'est implémentée à moins que le contrat ne prenne explicitement en charge la réception d'ETH sans déclencher la logique d'exécution.

4. Le déployeur doit s'assurer que toutes les adresses des propriétaires sont vérifiées hors chaîne avant leur inclusion, car la validation en chaîne de la légitimité des adresses n'est pas effectuée.

5. L'estimation du gaz pendant le déploiement dépend fortement du nombre de propriétaires initiaux en raison des écritures de stockage dans le constructeur.

Flux de soumission et de confirmation des transactions

1. Un proposant appelle submitTransaction avec l'adresse cible, la valeur et les données d'appel codées, générant un nouvel ID de transaction.

2. D'autres propriétaires invoquent confirmTransaction en utilisant cet ID, déclenchant l'agrégation de signatures internes et la vérification des seuils.

3. Une fois le seuil atteint, le contrat exécute l'appel via call avec une syntaxe d'assemblage de bas niveau ou d'adresse.call{value: montant}.

4. Les appels externes annulés n'annulent pas l'état de confirmation ; au lieu de cela, ils émettent un événement d'échec tout en préservant les enregistrements de signature.

5. Les transactions peuvent être annulées par le proposant si elles ne sont pas confirmées, mais les transactions confirmées ne peuvent pas être retirées ou modifiées après approbation.

Foire aux questions

Q : Un portefeuille multi-signature peut-il contenir des jetons ERC-20 ? R : Oui. Le contrat peut recevoir des jetons ERC-20 en approuvant les transferts à son adresse ou en utilisant les fonctions de dépôt si le jeton le prend en charge. Il ne transmet pas automatiquement les jetons à moins qu'il ne soit codé à cet effet.

Q : Est-il possible de modifier la liste des propriétaires après le déploiement ? R : Uniquement si le contrat inclut une fonction de gestion du propriétaire telle que addOwner ou RemoveOwner , qui nécessite elle-même une approbation multi-signature. Les déploiements immuables interdisent toute modification.

Q : Que se passe-t-il si un propriétaire perd sa clé privée ? R : Ce propriétaire devient non fonctionnel dans le processus de signature. Si les signataires actifs restants atteignent toujours le seuil, les opérations se poursuivent. Dans le cas contraire, les fonds pourraient devenir inaccessibles à moins que des mécanismes de recouvrement soient préprogrammés.

Q : Le contrat prend-il en charge les transactions à durée limitée ? R : Les implémentations de référence standard de Gnosis Safe ou similaires incluent des modules timelock. Les versions Barebones n'appliquent pas de délais à moins qu'elles ne soient explicitement ajoutées via des modificateurs vérifiant block.timestamp ou en utilisant des horodatages basés sur Oracle.