Maîtriser le Web 3.0 avec Waves #3

Module #3 Introduction aux Smart Contracts et Smart Accounts

Hey,

Bienvenue au module 3 de “Maîtriser le Web 3.0 avec Waves”.

Dans ce module nous allons parler des smart contracts, comment ils fonctionnent et comment les implémenter dans notre application Web 3.0 décentralisée, le “Coupon Bazzar”.

Sujets abordés dans ce module :

• Introduction aux Smart Contracts
• Smart Contracts dans Waves et Smart Accounts
• Problèmes de Sécurité et signatures multiples (Multi-signature) Smart Accounts
• Smart Accounts et Applications Décentralisées (dApps)
• Practique: “Coupon Bazaar”

Let’s go!

Traditionnellement les contrats représentent des accords entre plusieurs participants (parties), ces accords sont valides et confirmés par des entités officielles tierce ou gouvernementales. Les entités tierce sont des participants clés pour la validation des conditions des contrats, les conditions environnementales et les événements qui pourraient influencer l’exécution de l’accord des contrats.

Malgré le terme similaire, les smart contracts ne sont pas des contrats dans le sens “accords entre parties”. Un smart contract est un code source ou un programme qui peut être exécuté dans un environnement distribué comme le réseau Blockchain. Tous les résultats d’opération et les codes d’exécution sont stockés sur la Blockchaine.

Dans cette définition, smart contract n’est donc pas un contrat entre plusieurs parties, c’est un protocole de coopération entre utilisateurs, également entre utilisateur et ordinateur ou même entre ordinateur et ordinateur selon les règles décrites dans le code source du smart contract en question.

Smart contract langage de programmation pour ordinateur. C’est un ensemble d’instructions qui inclue différentes vérifications et validations, la lecture et l’écriture de données, des opérations avec des actifs numériques (digital assets) par exemple : transférer, créer, détruire, geler etc. N’oubliez pas que la technologie principale du Web 3.0 est la Blockchain, ou plus généralement la technologie de registres distribués (DLT Distribited Ledger Technology).

Un Smart Contract est exécuté sur des centaines de machines de manière simultanée.

De ce fait, le Smart Contracts a plusieurs fonctionnalités intéressantes :

• Pas d’intermédiaire
• Stockage sécurisé pour les actifs numériques (digital assets)
• Le code fait loi
• Sauvegarde par défault
• Evite les erreurs manuelles
• Exécution en tout confiance
• Exécution autonome

Certain d’entre vous ont peut être déjà entendu parler des contrats Ricardian, une innovation des années 90.

C’est une forme digitale des contrats traditionnels. Les contrats Ricardian ont deux parties : les termes compréhensibles par les humains et les composants compréhensibles par les machines. Des signatures digitales et des opérations automatisées sont ainsi utilisées. Mais malgré qu’ils soient de type digitale les contrats Ricardian ne sont pas des smart contracts, ce sont des contrats de type traditionnels. Ils ont un pouvoir légale alors que les smart contracts non.

Les smart contracts Ricardian sont la meilleur combinaison.

Différents DLT (Registres Distribués) ont différentes approches des smart contacts.

Les Smart Contracts Waves sont représenté par deux types différents : Les Smart Accounts et les Smart Assets. Nous verrons les Smart Assets plus tard dans la formation.

Chaque compte Waves peut être converti en Smart Account en y attachant un script de compte spécial. Les script de compte sont des codes de programmation écrit en langage RIDE qui contiennent un ensemble de conditions pour autoriser ou décliner différents type de transactions sortantes.

Techniquement la création et le déploiement des smart contracts waves ont plusieurs étapes :

Le code RIDE, la compilation, la génération de la transaction set script, la validation par une node, récupération de la liste des transactions non confirmées entre les nodes (UTX Pool) et l’insertion de la transaction avec le script dans le nouveau bloque.

Si nous analysons de manière plus approfondie il y a même encore plus d’étapes :

• L’IDE Waves valide le code RIDE
• Le code RIDE est compilé au format base64
• La transaction “set script” est utilisée pour envoyer le code compilé à la node Blockchain
• Désérialisation du code, vérification de la syntaxe, des noms et des variables, des fonctions
• Calcul du coût et vérification des signatures
• Après vérification et validation par la première node la transaction set script en envoyé sur le pool UTX inter-nodes
• Toutes les autres nodes vérifient les étapes de désérialisation et du calcul de coût réalisées
• La Miner-node effectue également les étapes de désérialisation et du calcul de coût avant la validation du nouveau bloque et son insertion dans la Blockchain.
• Après avoir reçu le nouveau bloque, toutes les nodes exécutent les étapes de désérialisation et du calcul de coût
• Maintenant le script est exécuté sur toutes les nodes et participe à la validation de toutes les transactions sortantes venant de ce du compte (smart account) auquel il a été attaché.

Un Smart script autorise ou décline toutes ou certaines transactions sortantes sur la base de conditions définies dans le script attaché au compte. Cette logique dépend de plusieurs sources de données : données du compte, données de la transaction, état et données de la Blockchain.

Quelle est la différence entre un compte par défaut et un compte “smart” (Smart account) ?

Un compte par défaut a un seul propriétaire pouvant utiliser sa clé privé et sa seed pour signer les transactions sortantes. N’importe quel autre utilisateur ne peut utiliser sa signature digitale pour signer les transaction d’un compte qui ne lui appartient pas. Bon ne peut pas signer les transactions d’Alice et vice versa.

Mais Alice peut attacher un script à sont compte et le transformer de compte par défaut à smart account. Pour cela Alice doit d’abord signer une transaction de type set script.

Quand un compte par défaut devient un smart account, n’importe qui peut signer toutes ou certaines des transactions sortantes selon la logique implémentée dans le script attaché.

Parlons des problèmes de sécurité !

Les scripts de comptes (Account script) doivent vérifier les conditions et autoriser les différents types de transactions sortantes et utilisateurs pouvant signer ces transactions. C’est un moment crucial ! C’est le moment le plus populaire pour les vulnérabilités et failles de sécurité.

RAPPEL : Nous construisons une place de marché Web 3.0 décentralisée de vente de coupon de réductions — “Coupon Bazaar”.

Les utilisateurs cherchent des coupons de réductions pour des produits et services et ils peuvent les acheter à petit prix sur cette place de marché virtuelle.

Chaque coupon est un actif digital qui représente une réduction spéciale venant du fournisseur.

“Coupon Bazaar” est une place de marché. Elle fournie recherche, vérification, opérations de paiements et service de livraison entre fournisseurs et acheteurs.

Nous allons donc implémenter les fonctionnalités pour les Fournisseurs :

• Enregistrement des fournisseurs
• Gestion des produits et services
• Confirmation des achats

… puis les fonctionnalités pour les Clients :

• Recherche de “coupon”
• Achat avec des cryptocurrencies

Pour travailler avec un stockage de données décentralisé en utilisant les data transactions nous devons autoriser l’utilisation de data transaction pour les fournisseurs et décliner toutes les autres transactions hormis set script transaction. Set script transaction est nécessaire pour nous permettre de mettre à jour plus tard le script du smart account. Soyez attentif à la vulnérabilité actuelle : Actuellement, n’importe quel utilisateur peut signer une transaction sortante.

N’importe qui peut changer le script de ce compte et donc retirer l’ensemble des actifs/fonds.

Afin d’autorise le changement de script du compte uniquement par son propriétaire, nous devons utiliser la fonction sigVerify. En utilisant cette fonction nous pouvons vérifier que la signature, depuis le tableau de signatures appelé “proof”, appartient bien au propriété du compte dApp.

Nous pouvons utiliser la fonction sigVerify avec un matcher à l’intérieur de la fonction verify(). sigVerify renvoi une valeur boolean TRUE quand le propriétaire du compte dApp signe la transaction, FALSE autrement.

Regardons un exemple classique d’utilisation d’un smart account afin d’augmenter la sécurité du stockage de données des actifs numériques (digital assets), Multi-signature account (multi- sig).

Par exemple, nos fournisseurs sont de petites entreprises composées de plusieurs fondateur/créateurs et administrateurs (3 dans notre cas). Pour retirer les fonds depuis un compte multisig, au moins 2 comptes parmi les 3 doivent signer la transaction sortante de type Transfer.

Ce compte multisig protège aussi les boutiques en ligne des hacks si on des 3 propriétaires se fait pirater sa clé privée ou si sa seed est compromise.

Pour implémenter un compte multi-signatures avec au moins deux signatures nous devons déclarer les clés publiques valides des signataires. Les participants peuvent signer les transactions dans n’importe quel ordre donc nous devons vérifier les différentes combinaisons possibles.

Pour signer une transaction plusieurs fois nous devons passer l’objet javascript de la transaction plusieurs fois à la même fonction. Par exemple dans notre cas la fonction de Transfer.

Parlons des applications décentralisées !

Dans notre application Web 3.0, le fournisseur doit confirmer les achats. Voyons comment automatiser cela.

Grace aux smart contract, nous sommes en mesure de créer des applications Web 3.0 décentralisées.

«Les applications décentralisées (dApps) sont des applications qui s’exécutent sur un réseau d’ordinateurs P2P plutôt que sur un seul ordinateur. Les dApps, existent depuis l’avènement des réseaux P2P. Il s’agit d’un type de logiciel conçu pour exister sur Internet d’une manière qui ne soit contrôlée par aucune entité. Les applications décentralisées n’ont pas nécessairement besoin de s’exécuter sur un réseau Blockchain. BitTorrent, Popcorn Time, BitMessage, Tor, sont tous des dApp classiques fonctionnant sur un réseau P2P, mais pas sur une Blockchain (qui est un type spécifique de réseau P2P).

Mais dans notre définition: les dApps sont des sites Web «blockchain enabled» c’est à dire utilisant la Blockchain et où le smart contract leur permet de se connecter à à celle ci. Le moyen le plus simple de comprendre cela est de comprendre le fonctionnement des sites Web traditionnels, du type de notre dApp «Coupon Bazaar» mais intégré à Waves blockchain et utilisant l’extension du navigateur Waves Keeper.

Afin de faciliter le processus de développement de dApp pour les développeurs, le langage de smart contract RIDE de Waves propose deux types de fonctions:

@Verifier et @Callable.

Nous connaissons déjà @Verifier.

Les fonctions @Callable peuvent être appelées par des utilisateurs depuis l’extérieurs. À la suite de l’exécution, de nouvelles informations peuvent être insérées ou mises à jour dans le stockage de données clé-valeur du compte dApp ou (et) des fonds peuvent être transférés depuis la balance d’actifs du compte dApp vers le compte “appelant” ou vers d’autres adresses selon la logique implémentée dans la script du compte dApp.

Dans notre cas, dApp et smart contract sont la même entité.

Les utilisateurs peuvent appeler des fonctions @Calable et ce processus s’appelle “invocation”. La transaction générée appropriée est invokeTransaction. Nous pouvons utiliser certaines informations venant des paramètres invokeTransaction dans le script du smart contract, par exemple les informations de paiement: montant et devise de paiement (token).

Dans notre Coupon Bazar, nous allons utiliser la fonction d’achat pour les achats des clients et la confirmation de l’achat des coupons par les fournisseurs.

Le prix de l’article doit être inscrit dans le stockage clé-valeur (key: item_A_coupon_price) du compte dApp.

Nous pouvons extraire le prix en utilisant la fonction getInteger().

Le client doit payer le montant exact pour acheter le coupon, sinon le smart contract génère une erreur avec une description de celle ci.

Comme vous pouvez le constater, l’achat sera automatiquement confirmé après l’exécution de la fonction d’achat.

Tous les enregistrements sont insérés dans le stockage clé-valeur du compte dApp. Ces données sont écrites par la fonction WriteSet. Le csmart contract peut lire et réécrire ces données lors de son exécution.

Pour appeler la fonction @Callable — purchase(), nous devons utiliser le nouveau type de transaction et son enveloppe en JavaScript — invokeScript().

Nous pouvons utiliser n’importe quel paramètre clé-valeur dans le tableau args et les détails du paiement. Pour spécifier quelle fonction sera exécutée, nous devons utiliser le nom de la fonction @Callable et spécifier une adresse publique de compte dApp (ou un alias).

Il s’agit donc des aspects fondamentaux des smart contracts et de leur implémentation dans Waves.

Nous vous souhaitons bonne chance avec le «Code Challenge»!

Enjoy!

Sujets abordés dans ce module :

• Introduction aux Smart Contracts
• Smart Contracts dans Waves et Smart Accounts
• Problèmes de Sécurité et signatures multiples (Multi-signature) Smart Accounts
• Smart Accounts et Applications Décentralisées (dApps)
• Practique: “Coupon Bazaar”