Problèmes clés pour les portefeuilles de nouvelle génération pour prendre en charge CashTokens et UTXO Smart Contracts
Il y a 1 mois
width=1280&format=pjpg&auto=webp&s=
Niveaux de portefeuilles de jetons
CashTokens sur BCH est une installation unique qui satisfait deux propositions de valeur à la fois :
Traditionnel "jetons" où les jetons fongibles ou non fongibles représentent des objets de valeur, et sont transférés et échangés sur une blockchain publique pour tirer parti de ses propriétés de sécurité sans autorisation
Calcul "jetons" où les informations sont transmises à la fois aux contrats en chaîne et aux entités hors chaîne pour des opérations plus complexes
Cependant
Gestion conventionnelle des jetons
Les portefeuilles traditionnels de gestion de jetons doivent avoir les caractéristiques suivantes :
Envoi en cours
Recevoir
Identification facile des ID de catégorie
Accès à l’historique et aux détails des transactions (pour les portefeuilles complets) ou au solde (pour les minimalistes)
Description détaillée des caractéristiques NFT (mutable, mintable.)
Capacité à gérer BCH en parallèle
Sauvegarde non dépositaire, par le biais de mots de départ ou autrement
Il peut également avoir en option les caractéristiques suivantes qui peuvent immédiatement apporter une grande amélioration à la qualité de vie :
Frappe, si une norme est convenue
Identification des jetons, peut-être via le protocole de métadonnées
Envoi de BCH en une seule sortie avec des jetons
Envoi de jetons aux protocoles de paiement (comme une version de BIP70 ou json-payment-protocol)
D’autres fonctionnalités avancées disponibles pour BCH telles que la fusion, le shuffle, la gestion des pièces sont souhaitables, mais peuvent ne pas être immédiatement nécessaires pour "Prêt à partir" Fonctionnalité.
Notez que même dans une configuration où ces fonctionnalités avancées sont disponibles pour le BCH natif, elles peuvent ne pas être disponibles pour les jetons fongibles en raison de la liquidité, de la demande ou des obstacles de maintenance générale, même si la mise en œuvre est théoriquement simple.
Jetons porteurs d’informations et contrats intelligents
Le principal avantage de CashTokens par rapport aux autres protocoles de jetons UTXO réside dans sa capacité à interagir en tant que support d’informations dans un contexte BCH expressif. Sans au moins un portefeuille compétent pour en profiter, cette fonctionnalité peut être retardée pendant très longtemps. Pour le faciliter, il faut, comme condition préalable, que le portefeuille soit capable de :
Contextes : Afficher différents contextes dans l’interface, selon le contrat traité. Plus à ce sujet ci-dessous
Interactions externes :Capacité à échanger des informations de manière interactive avec des entités externes non nodulaires. Un exemple externe ici est MetaMask, qui est capable d’interagir avec des pages Web ; un exemple BCH existant est Cashfusion, qui interagit avec le serveur Cashfusion. Les premiers portefeuilles voudront peut-être peser leur portée sur l’opportunité d’inclure la capacité d’interagir avec les serveurs en général
Dépenses de script: Avec un modèle et des informations de support suffisantes, passez un UTXO de manière personnalisée, peut-être avec des étapes d’interaction pour récupérer des informations supplémentaires
Découverte UTXO : À partir d’un modèle et d’une valeur de départ ou d’une sauvegarde privée, interrogez les serveurs à l’aide de critères de filtre personnalisés et récupérez les UTXO utilisables, ainsi que les éventuelles informations supplémentaires requises pour les utiliser. Ceci est important dans le contexte UTXO, car il n’y a pas de compte abstrait unique par utilisateur où tout va et vient. Pour certains contrats, la possibilité de découverte à partir de la valeur de départ peut ne pas être pratique, auquel cas des sauvegardes de portefeuille sécurisées doivent être spécifiées
Sauvegarde de l’historique des interactions: Les portefeuilles conventionnels convergent généralement vers la sauvegarde par des graines BIP39, à partir desquelles tout un historique P2PKH peut être récupéré directement à partir de la blockchain. Les portefeuilles de scripts interactifs n’ont pas un tel luxe – tout comme dans le cas des UTXO, les portefeuilles doivent soit sauvegarder directement leur historique, soit avoir des modèles dans lesquels des méthodes personnalisées de découverte à partir de la graine sont spécifiées
Nous pouvons faire mieux – un système de modèles indépendant du Web tel que Bitauth peut faciliter un système sans autorisation, de confiance une fois par cas d’utilisation, qui est beaucoup plus sécurisé
Ces capacités formeront une base de référence généralisée sur laquelle d’innombrables personnalisations sont possibles via des modèles, et la capacité des CashTokens à transférer des informations sera au cœur de bon nombre de ces contrats. Nous explorerons les primitives CashTokens dans les contrats personnalisés dans un autre article.
Sur les contextes
comme on le voit dans Electron-Cash-SLP. Il est cependant impossible pour une interface de prendre en compte tous les cas d’utilisation de script possibles, dont beaucoup nécessiteront des éléments d’entrée et de sortie personnalisés. Il est donc important que les portefeuilles acceptent différentes interfaces possibles, peut-être via la tabulation, spécifiées dans le contexte de chaque modèle.
Au plus élémentaire, un "universel" L’interface est concevable où les modèles spécifient tous les champs d’entrée de script nécessaires dans leurs exigences brutes telles que num/binary-strings/public key. et le portefeuille sérialise simplement les entrées à utiliser telles quelles dans Script. Cela peut cependant être très peu convivial pour l’utilisateur, en particulier pour les éléments qui proviennent d’une source externe, telle qu’un oracle, au lieu de l’utilisateur. D’un autre côté, il serait imprudent d’autoriser une interaction arbitraire et l’exécution de code avec un serveur distant, car toute vulnérabilité introduite par un modèle n’est plus contenue dans son contexte.
Sur les portefeuilles EVM comme MetaMask, les contextes sont généralement accordés en autorisant l’accès aux domaines Web. Le modèle EVM/MetaMask, cependant, souffre d’une grande confiance envers les propriétaires de noms de domaine, ainsi que d’autorisations opaques et peut-être illimitées accordées aux sites Web qui peuvent être modifiées de manière arbitraire. Nous affirmons qu’une confiance une fois par cas d’utilisation "modèle" modèle, similaire à la façon dont les utilisateurs font traditionnellement confiance aux logiciels téléchargés, est plus approprié pour nos besoins.
Un bon équilibre peut être trouvé pour un portefeuille basé sur un modèle, s’il respecte les règles suivantes :
Un modèle ne doit pas exécuter de code distant arbitraire. Les seules données pouvant être récupérées à partir d’un serveur distant sont des entrées directes dans le script Bitcoin Cash ou des parties (mutables) du script Bitcoin Cash lui-même. Tout code non-Script doit être local et nécessite une mise à jour explicite du modèle pour être modifié
Les contextes de modèles doivent être isolés. Les modèles ne doivent pas automatiquement transmettre des informations entre eux lors de l’exécution, sans l’autorisation explicite de l’utilisateur. Ils doivent chacun avoir leur chemin de dérivation de graine isolé, leur fichier de sauvegarde, leurs instructions d’interface, etc. Le portefeuille doit appliquer cela à la conception de bas niveau ; ne pas le faire entraînera un risque de contagion à partir d’un modèle malveillant que l’utilisateur a importé par inadvertance. Bien que ce risque de contagion puisse être acceptable dans un contexte occasionnel ou de petite communauté, il n’est pas extensible à des groupes d’utilisateurs et de développeurs plus larges et moins sophistiqués
Aucune autorisation persistante pour les interactions modifiables. Certaines interactions, telles que la récupération d’un morceau de Bitcoin Cash Script à partir de sources externes, sont "mutable" : ils ne remplissent pas simplement les entrées sur un script déjà approuvé, mais peuvent générer des contextes supplémentaires qui ne sont pas encore explicitement approuvés. Chacune de ces interactions doit être explicitement autorisée à chaque fois. Les développeurs qui souhaitent rationaliser l’expérience utilisateur doivent chercher à minimiser ces interactions et chercher à contenir tout leur script dans le modèle initial lui-même
