Comment les portefeuilles Ethereum évoluent

Benedict Chan est responsable de la plateforme chez BitGo, une entreprise spécialisée dans la sécurité blockchain, et un fervent défenseur des technologies blockchain Bitcoin et Ethereum . Il a conçu et développé des API et des SDK utilisés dans plusieurs implémentations de portefeuilles Bitcoin multi-signatures.

Ici, Chan LOOKS les différences entre les portefeuilles multisig Ethereum et leurs homologues Bitcoin , ainsi que leur fonctionnement interne.

Les portefeuilles sont ONEune des applications les plus basiques de toute plateforme blockchain. Ils fournissent l'interface permettant aux utilisateurs d'interagir avec la blockchain. Certains portefeuilles, comme ONE proposé par Bitcoin CORE, se connectent directement à la blockchain via un nœud complet, tandis que d'autres s'appuient sur des services web pour y accéder.

À la base, un portefeuille sert les utilisateurs en recevant, en envoyant, en surveillant et en listant les transactions au sein d'une Cryptomonnaie. Les portefeuilles plus avancés permettent aux utilisateurs de bénéficier d'une sécurité renforcée ou d'effectuer un ensemble étendu d'actions sur la blockchain, augmentant ainsi leur valeur. C'est particulièrement vrai dans le cas de la blockchain Ethereum , où les utilisateurs doivent non seulement stocker de la valeur, mais aussi effectuer diverses activités via des contrats.

Contexte sur le multisig

Depuis leur introduction en 2013, les portefeuilles Bitcoin multi-signatures (multisig) sont utilisés pour assurer la redondance et la sécurité des utilisateurs lors de la gestion des fonds sur la blockchain. Les comptes multi-signatures nécessitent la signature de plusieurs clés pour transférer un jeton, à l'instar d'un coffre-fort physique où ONE clés sont nécessaires pour accéder à son contenu.

Le multisig rend le vol d'un portefeuille plus difficile pour les attaquants, car les clés peuvent être placées sur des machines distinctes. Grâce à cette sécurité supplémentaire, les utilisateurs peuvent stocker et utiliser leurs cryptomonnaies en toute tranquillité d'esprit, ou configurer des structures de portefeuille nécessitant plusieurs utilisateurs et approbations pour les transferts.

Évolution du Bitcoin à Ethereum

Le potentiel de la blockchain Ethereum, conjugué à la hausse rapide du cours de l'ether en 2016, a stimulé la demande des utilisateurs pour un portefeuille web multi-signatures. Mais contrairement à d'autres clones du Bitcoin comme le Litecoin, Ethereum est une blockchain unique, car elle a été conçue dès le départ sur un ensemble de règles de consensus totalement différent. Cela entraîne des différences significatives dans la mise en œuvre des portefeuilles multi-signatures Ethereum par rapport à leurs homologues Bitcoin .

Comptes et adressage

En Bitcoin, un portefeuille doit surveiller plusieurs transactions entrantes précédentes envoyées aux adresses dont il possède les clés (appelées « non dépensées »). Le total cumulé des valeurs non dépensées sur ces adresses représente le solde du portefeuille. En Ethereum, la notion de « non dépensées » n'existe pas ; chaque compte possède un solde, qui varie à chaque transaction.

Pour créer et signer une transaction, il n'est pas nécessaire de collecter et de conserver les sorties non dépensées précédentes : ONE suffit de mémoriser le dernier ID de séquence utilisé (afin d'éviter les doubles dépenses) et de l'incrémenter. De plus, le suivi des soldes (et non des non dépensés) allège la charge de travail des portefeuilles en matière de gestion de la monnaie. À cet égard, la création de transactions est plus simple sur Ethereum. Cela a un impact sur la Politique de confidentialité des utilisateurs, car les comptes sont désormais liés à une adresse unique, alors que les utilisateurs pourraient envoyer et recevoir des fonds simultanément sur plusieurs adresses en Bitcoin , ce qui rend les fonds moins traçables.

Frais miniers

En Bitcoin, les frais payés par les utilisateurs aux mineurs sont calculés en fonction de la taille de la transaction. En Ethereum, ils sont calculés en fonction du nombre d'opérations blockchain effectuées, multiplié par le prix que l'utilisateur est prêt à payer par unité de GAS (tarification interne pour l'exécution d'une transaction ou d'un contrat sur Ethereum). En termes simples, les frais sont liés au volume et à la complexité des opérations, ainsi qu'à l'espace occupé sur la blockchain.

Pour les utilisateurs techniquement avancés, il s'agit d'une méthode plus précise et plus équitable pour tarifer l'utilisation de la blockchain et les coûts de validation associés. Cependant, elle peut prêter à confusion pour les utilisateurs novices. Par exemple, l'envoi d'ethers à un contrat de financement participatif peut entraîner des frais différents (à la charge de l'expéditeur) que l'envoi de la même quantité d'ethers à un ami. Cela représente un défi intéressant pour les concepteurs d'interfaces utilisateur d'applications : communiquer ces différences et aider les utilisateurs à en comprendre le raisonnement.

Modèles de contrats multi-signatures

Contrairement à Bitcoin, Ethereum prend en charge les scripts avancés, mais ne prend pas encore en charge le concept de multisig natif ou P2SH (où ONEon peut payer le hachage d'un contrat et fournir le script plus tard).

L'approche de base pour sécuriser des fonds avec plusieurs signatures consiste à créer plusieurs adresses « à signature unique », puis à rédiger un contrat contrôlé par ces adresses pour stocker les fonds. Bien que cette approche soit plus complexe qu'avec Bitcoin, elle pourrait offrir davantage de flexibilité aux développeurs de portefeuilles.

Il existe deux approches principales pour rédiger un portefeuille de contrats qui nécessite plusieurs signatures pour sécuriser les fonds.

Il s’agit de l’approche la plus courante utilisée dans les portefeuilles tels queBrume ou ÉtherliTout d'abord, le contrat de portefeuille est déployé, enregistrant les « adresses de signature » ​​fournies. Pour envoyer des fonds à une adresse, le premier utilisateur, ou proposant, envoie une transaction contenant une Request de proposition au contrat. Cette Request possède un ID d'opération unique (hachage), dérivé du montant, de l'adresse de destination et des données à envoyer.

Ensuite, un autre utilisateur du contrat de portefeuille doit confirmer cet ID d'opération en envoyant une transaction de confirmation distincte au contrat. Les deux transactions doivent être publiées sur la chaîne avant que l'opération résultante (envoi de fonds) puisse être exécutée.

Bien que l'approche précédente soit sécurisée et adaptée à de nombreux scénarios, il est nécessaire de regrouper toutes les signatures dans une seule transaction, comme pour Bitcoin. Connue par certains comme la seconde évolution du multisig sur Ethereum, cette approche présente l'avantage de nécessiter moins d'espace sur la chaîne et d'être potentiellement plus rapide, car elle ne nécessite pas d'attente de plusieurs blocs.

Chaque transaction sur Ethereum ne peut avoir qu'un ONE expéditeur/signataire. Par conséquent, l'implémentation de cette fonctionnalité dans un contrat nécessite l'utilisation de l'opération d'assemblage « ecrecover ». Cette opération permet de vérifier l'adresse d'une signature dans le champ de données de la transaction. Le contrat multi-signatures est codé pour dériver un ID d'opération à partir du montant, de la destination, des données, ETC, et vérifier que cet ID est bien signé par la signature du champ de données. Un signataire peut ainsi être considéré comme provenant de l'expéditeur du message, les signatures des autres signataires étant validées dans le champ de données, le tout au sein d'une même transaction.

Implémentations de portefeuilles multisig

Les lecteurs plus techniques voudront peut-être étudier ces implémentations de contrats multi-signatures pour Ethereum:

Implémentation « multisig facile » de DappSys

Construite sur le framework contractuel Dappsys, cette implémentation multisig suit la première conception « exécuter puis confirmer ». Elle a récemment été présentée lors de la journée « dapp-a-day » précédant la conférence Devcon. Son principal avantage réside dans la conception modulaire du code pour les développeurs qui écrivent des portefeuilles dessus, ce qui permet une application facile à de nombreux autres scénarios que le stockage de valeur.

Améliorations futures

La communauté Ethereum dispose d'une solide base de développeurs, avec plusieurs projets et équipes qui devraient lancer des applications à NEAR ou moyen terme. Ces lancements stimuleront la demande et le support de nouvelles fonctionnalités pour les portefeuilles multi-signatures Ethereum :

Prise en charge des jetons ERC20

Bien qu'il existe actuellement des portefeuilles multi-signatures permettant de sécuriser l'ether, rares sont ceux permettant de sécuriser d'autres jetons en plus d' Ethereum, comme Digix DGD, Augur REP , etc. Ces contrats de jetons font partie intégrante de l'écosystème Ethereum et sont tous compatibles avec la norme commune ERC20.

La création d'un portefeuille prenant en charge cette norme signifie que les utilisateurs pourront bénéficier de la prise en charge de tous ces jetons intéressants à partir d'une seule application de portefeuille.

Prise en charge de davantage d'opérations/scénarios

À plus long terme, le nombre d'opérations qu'un portefeuille devra pouvoir effectuer augmentera également. Les contrats sur Ethereum nécessitent bien plus que de simples envois et réceptions.

Il est important pour le secteur non seulement de créer des normes d'interopérabilité pour les opérations de portefeuille actuelles, mais aussi d'établir des fonctions communes que ces portefeuilles pourraient prendre en charge. Celles-ci peuvent inclure l'achat, la vente, le verrouillage, le jalonnement, le vote, etc.

Évolution du portefeuille multisig avec EIP101 (Serenity)

La version Ethereum Serenity apportera probablement plusieurs fonctionnalités utiles qui amélioreront considérablement la simplicité et l'expérience utilisateur des portefeuilles multisig.

La première amélioration concerne la fonctionnalité « pay-to-script-hash », qui permettra de déployer et de créer le contrat de portefeuille uniquement lorsque le destinataire souhaite dépenser des fonds. Cela évitera aux utilisateurs d'avoir à effectuer un déploiement pour créer des portefeuilles. Plus important encore, cela supprimera également l'obligation pour les nouveaux utilisateurs de payer les frais de GAS à l'avance lors de la configuration d'un portefeuille multisig.

Cela permet également de distribuer plusieurs adresses HD sans dépenser le GAS nécessaire à leur déploiement initial, comme le font de nombreuses entreprises en Bitcoin pour collecter les paiements. Si cette méthode est bien mise en œuvre, elle pourrait réduire la réutilisation des adresses et renforcer la Politique de confidentialité.

Ensuite, les contrats pourront payer leurs propres frais. Actuellement, les frais de GAS/minage lors d'un retrait sont prélevés à l'adresse de signature qui envoie la transaction au contrat de portefeuille. Cela signifie que les utilisateurs doivent détenir des soldes à deux endroits : le contrat de portefeuille (sécurisé par multisig) et l'adresse de signature (pour payer les frais). Serenity permettra aux contrats de payer eux-mêmes leur GAS, évitant ainsi aux utilisateurs de gérer un compte de GAS pour effectuer des transactions.

Réflexions finales

En fin de compte, les utilisateurs ne choisiront pas leurs portefeuilles en fonction de la Cryptomonnaie qu'ils prennent en charge, mais des fonctionnalités qu'ils offrent. Chacun recherche l'application phare, et non la chaîne phare. C'est une période passionnante pour investir dans les Cryptomonnaie et observer l'évolution des portefeuilles qui contribuent à la construction de l'écosystème et le rendent accessible au grand public.

Image en cuirvia Shutterstock