Stacks-wallet-web: Exposer la méthode pour signer des messages arbitraires

Créé le 9 mars 2021  ·  12Commentaires  ·  Source: blockstack/stacks-wallet-web

Il y aura des moments où une application devra signer un message arbitraire. Cette fonctionnalité existe dans les portefeuilles d'Eth, mais nous n'exposons pas actuellement de fonction pour le faire dans les applications de piles.

Il est suggéré que nous devrions faire un équivalent à https://eips.ethereum.org/EIPS/eip-712

de la discorde :

ok donc dans le monde Eth, il y a des tonnes de signatures de messages arbitraires, pour DeFi et DeX et ainsi de suite

Auparavant, vous signiez toujours un hachage de commande, mais ce n'est pas très lisible pour l'utilisateur. (La fenêtre contextuelle MetaMask vous montre juste une chaîne hexadécimale, vous n'avez aucune idée de ce que vous signez réellement.)

EIP712 a défini une structure (en json) qui permet de montrer en quoi consistait ce hachage de commande

vous voyez donc les champs réels qui ont servi à générer le hachage que vous signez

image

enhancement

Commentaire le plus utile

Il a été déterminé lors d'une conversation avec @MarvinJanssen et @GinaAbrams hier que l'application .BTC n'aura pas un besoin urgent de signature de message arbitraire à moins que deux choses ne se produisent de manière séquentielle :

  1. Nous ne sommes pas en mesure de déployer les correctifs Atlas sur le réseau principal dans les prochaines semaines.
  2. Il est incapable d'implémenter le mécanisme de rapport de fichier de zone dont il a besoin comme solution de contournement en utilisant un contrat intelligent Clarity personnalisé et la signature et la diffusion de transactions avec l'extension Stacks Wallet.

La route de signature de message arbitraire est essentiellement une solution de repli aux routes ci-dessus, qui sont préférables dans l'ordre indiqué. Cela impliquerait l'envoi de messages signés avec des données de fichier de zone à un serveur centralisé, ce qui épargnerait à l'utilisateur final le coût d'avoir à signer une transaction mais entraînerait également l'implication indésirable d'une partie centralisée.

@agraebe @diwakergupta Je vérifierai avec splat la semaine prochaine pour voir comment se déroulent les plans de déploiement d'Atlas afin que nous puissions fournir à @MarvinJanssen une mise à jour ici en ce qui concerne le calendrier et son impact sur ses options.

Il est heureux d'attendre une semaine ou deux pour voir si nous pouvons obtenir les correctifs en direct sur le réseau principal et lui épargner le travail de l'une ou l'autre des solutions de contournement.

Tous les 12 commentaires

Merci d'avoir posté ça ! Je pense qu'une telle fonctionnalité est cruciale.

Merci d'avoir posté ça ! Je pense qu'une telle fonctionnalité est cruciale.

Je suis d'accord, et je pense que beaucoup de membres de l'équipe seraient d'accord aussi 👍 Je vais travailler pour mettre à jour ce problème au fur et à mesure que nous en parlerons.

@MarvinJanssen Pensez- vous à indiquer le ou les cas d'utilisation que vous souhaitez créer à court terme avec cela pour aider à peser les priorités ?

@markmhx parle à court terme, il n'y a vraiment qu'une seule raison pour laquelle j'en ai besoin.

Je crée un composant côté serveur qui suit les URL de compartiment d'application utilisateur (pour les fichiers de zone). Afin de sécuriser cette API, l'utilisateur doit signer son URL de compartiment avec Connect. Le serveur résout ensuite le nom BNS signalé par l'utilisateur via le contrat BNS et utilise le principal correspondant pour vérifier la signature. J'ai essentiellement besoin de vérifier qu'un message spécifique provient bien d'un mandant qui possède un nom sur BNS. Si vous avez des solutions alternatives, faites le moi savoir. Mon plan de sauvegarde consistait à introduire un simple contrat Clarity et à demander à l'utilisateur de soumettre une preuve via un appel de contrat, mais cela en fait une solution de contournement pour une solution de contournement pour une solution de contournement ...

il y a 2 principaux autres cas d'utilisation que j'ai vus utiliser des signatures sur Eth :

  • prouvez que vous possédez une adresse et le site révélera des analyses que vous seul pouvez voir sur votre adresse (ce qui est bien)
  • voter (contrairement à uniswap par exemple, qui nécessite de payer des frais d'essence, synthetix ne nécessite qu'une signature par vote, ne vous coûte rien, ce qui semble juste pour le vote de gouvernance)

@psq yep à long terme, nous en avons besoin pour DeFi et DeX, et les plates-formes qui effectuent une correspondance côté serveur qui nécessitent des signatures d'utilisateurs. (Comme 0x Protocol et Wyvern sur Ethereum.)

Merci pour le contexte supplémentaire 🙏 que j'attribue à Jasper pour qu'il puisse concevoir.

Je vois que c'est dans la glacière @markmhx , cela signifie-t-il qu'il sera pris en compte dans un sprint ultérieur ? @MarvinJanssen attend des mises à jour 🙂

J'ai replacé ce problème dans le backlog Kanban .

Notez que nous ne travaillons plus sur des sprints de 2 semaines, mais plutôt sur une livraison incrémentielle des priorités, comme en témoigne le backlog de haut en bas.

Je suis totalement d'accord avec l'évaluation d'un système pour les structures de données typées signées, mais c'est une tâche d'ingénierie beaucoup plus importante que je ne pense pas que nous devrions entreprendre en premier. Le principal avantage des données structurées est de réaliser des transactions en chaîne sans frais avec une logique liée aux données de cette signature. Cependant, deux choses :

  • Les transactions sponsorisées font en sorte que tout appel de contrat peut être sans frais. Le seul inconvénient ici est que vous ne pouvez pas faire de signatures par lots
  • La spécification ETH est très liée à la façon dont ce format de données peut être codé RLP et utilisé dans l'EVM. Nous devrons faire beaucoup de travail pour déterminer comment cela pourrait fonctionner avec Clarity, puis nous pourrons en faire une spécification, puis nous pourrons l'ajouter au portefeuille

Les chaînes sont le cas d'utilisation le plus évident pour Stacks pour le moment. Cela permettrait le cas d'utilisation très courant de fournir un accès hors chaîne à un utilisateur qui peut prouver qu'il possède une adresse STX. Par exemple, une application Web qui offre des fonctionnalités spécifiques si vous possédez un NFT.

Pour être plus concret sur les cas d'utilisation :

  • Connectez-vous à l'application Web et prouvez que vous possédez une adresse STX

    • pas techniquement résolu par auth pour le moment, car il signe avec une clé différente de la pré-2.0, mais nous pouvons/devons changer cela

  • Partagez un message spécifique pour hors chaîne qui prouve que vous possédez une adresse STX

    • signer une chaîne, la version "facile" de ce problème

  • Approbations de jetons sans frais

    • résolu par post conditions

  • Vote DAO sans frais

    • résolus par des transactions sponsorisées

  • Vote DAO sans frais par lots, ou d'autres éléments complexes sans frais sur la chaîne

    • nécessite l'équivalent ERC712

Il a été déterminé lors d'une conversation avec @MarvinJanssen et @GinaAbrams hier que l'application .BTC n'aura pas un besoin urgent de signature de message arbitraire à moins que deux choses ne se produisent de manière séquentielle :

  1. Nous ne sommes pas en mesure de déployer les correctifs Atlas sur le réseau principal dans les prochaines semaines.
  2. Il est incapable d'implémenter le mécanisme de rapport de fichier de zone dont il a besoin comme solution de contournement en utilisant un contrat intelligent Clarity personnalisé et la signature et la diffusion de transactions avec l'extension Stacks Wallet.

La route de signature de message arbitraire est essentiellement une solution de repli aux routes ci-dessus, qui sont préférables dans l'ordre indiqué. Cela impliquerait l'envoi de messages signés avec des données de fichier de zone à un serveur centralisé, ce qui épargnerait à l'utilisateur final le coût d'avoir à signer une transaction mais entraînerait également l'implication indésirable d'une partie centralisée.

@agraebe @diwakergupta Je vérifierai avec splat la semaine prochaine pour voir comment se déroulent les plans de déploiement d'Atlas afin que nous puissions fournir à @MarvinJanssen une mise à jour ici en ce qui concerne le calendrier et son impact sur ses options.

Il est heureux d'attendre une semaine ou deux pour voir si nous pouvons obtenir les correctifs en direct sur le réseau principal et lui épargner le travail de l'une ou l'autre des solutions de contournement.

C'est une chose inestimable à avoir, l'utilisation de signatures de l'identité prouverait la propriété d'un nom et de beaucoup de choses, surtout en ce qui concerne les opérations hors chaîne, 100% pour cela

Cette page vous a été utile?
0 / 5 - 0 notes