Comment rédiger un smart contract en WebAssembly sur le réseau Ontology ? Partie 1 : Rust

La technologie Ontology Wasm réduit le coût de migration des contrats intelligents dApp avec une logique commerciale complexe vers la blockchain, enrichissant ainsi considérablement l'écosystème dApp.

Actuellement Ontology Wasm prend en charge le développement simultané en Rust et en C++. Le langage Rust prend mieux en charge Wasm, et le bytecode généré est plus simple, ce qui peut encore réduire le coût des appels de contrat. Ainsi, comment utiliser Rust pour développer un contrat sur le réseau Ontology ?

Développement d'un contrat WASM avec Rust

Création de contrat

Cargo est un bon outil pour la création de projets et la gestion des packages lors du développement de programmes en Rust, qui aide les développeurs à mieux organiser l'interaction entre le code et les bibliothèques tierces. Pour créer un nouveau contrat Ontology Wasm, exécutez simplement la commande suivante :

La structure du projet qu'elle génère :

Le fichier Cargo.toml est utilisé pour configurer les informations de base du projet et les informations de la bibliothèque dépendante. La section [lib] dans le fichier doit être définie à crate-type = [“cdylib”]. Le fichier lib.rs est utilisé pour écrire la logique du contrat. De plus, vous devez ajouter les paramètres de dépendance dans la section [dependencies] du fichier de configuration Cargo.toml :

Avec cette dépendance, les développeurs peuvent appeler les interfaces interagissant avec la blockchain Ontology, ainsi que des outils tels que le paramètre de sérialisation.

Fonction d'entrée du contrat

Chaque programme a une fonction d'entrée, comme la fonction main que nous voyons généralement, mais un contrat n'a pas de fonction main. Lors du développement d'un contrat Wasm avec Rust, la fonction invoke est utilisée par défaut comme fonction d'entrée pour utiliser le contrat. Le nom de la fonction en Rust sera obscur lors de la compilation du code source Rust en bytecode qui peut être exécuté par la machine virtuelle. Pour empêcher le compilateur de générer du code superflu et réduire la taille du contrat, la fonction invoke ajoute l'annotation #[no_mangle].

Comment la fonction invoke reçoit-elle des paramètres pour exécuter une transaction ?

La bibliothèque ontio_std fournit la fonction runtime::input() pour obtenir les paramètres afin d'exécuter une transaction. Les développeurs peuvent utiliser ZeroCopySource pour désérialiser le tableau d'octets obtenu. Le premier tableau d'octets lu est le nom de la méthode invoke, suivi des paramètres de la méthode.

Comment le résultat de l'exécution du contrat est-il renvoyé ?

La fonction runtime::ret, fournie par la bibliothèque ontio_std, renvoie le résultat de l'exécution de la méthode.

La fonction invoke complète se présente comme suit :

Sérialisation et désérialisation des données du contrat

Lors du développement de contrats, les développeurs rencontrent toujours des problèmes de sérialisation et de désérialisation, en particulier sur la manière de stocker les types de données struct dans la base de données et comment désérialiser un tableau d'octets lu depuis la base de données pour obtenir le type de données struct.

La bibliothèque ontio_std fournit des interfaces de décodeur et d'encodeur pour la sérialisation et la désérialisation des données. Les champs de la structure struct implémentent également les interfaces de décodeur et d'encodeur, permettant ainsi de sérialiser et de désérialiser la structure. Les instances de la classe Sink sont nécessaires lors de la sérialisation de différents types de données. Une instance de la classe Sink a un champ de type set buf qui stocke les données de type octet, et toutes les données sérialisées sont conservées dans buf.

Pour les données de longueur fixe (par exemple : byte, u16, u32, u64, etc.), les données sont directement converties en tableau d'octets puis enregistrées dans buf ; pour les données de longueur variable, la longueur doit d'abord être sérialisée, suivie de Ddata (par exemple, des entiers non signés de taille inconnue, y compris u16, u32 ou u64, etc.).

La désérialisation est l'opposée directe. Pour chaque méthode de sérialisation, il existe une méthode de désérialisation correspondante. La désérialisation nécessite d'utiliser des instances de la classe Source. Cette instance de classe a deux champs buf et pos. Buf est utilisé pour stocker les données qui seront désérialisées, tandis que pos est utilisé pour garder la position actuelle de lecture. Lors de la lecture d'un type de données spécifique, si vous connaissez sa longueur, vous pouvez le lire directement ; pour les données de longueur inconnue, commencez par lire la longueur, puis lisez le contenu.

Accès et mise à jour des données sur la chaîne

Ontology-wasm-cdt-rust — a encapsulé le mode opérationnel de travail avec les données dans la chaîne, ce qui est pratique pour les développeurs afin de réaliser des opérations telles que l'ajout, la suppression, la modification et la demande de données dans la chaîne comme suit :

• database::get(key) — est utilisé pour demander des données de la chaîne, et key demande l'implémentation de l'interface AsRef ;
• database::put(key, value) — est utilisé pour stocker des données dans le réseau. Key demande l'exécution de l'interface AsRef, et value demande l'implémentation de l'interface Encoder ;
• database::delete(key) — est utilisé pour supprimer des données de la chaîne, et key demande l'implémentation de l'interface AsRef.

Test de contrat

Lorsque les méthodes de contrat sont mises en œuvre, nous avons besoin d'accéder aux données dans la chaîne et nous avons besoin d'une machine virtuelle appropriée pour exécuter le bytecode du contrat, il est donc généralement nécessaire de déployer le contrat dans la chaîne pour les tests. Cependant, cette méthode de test est problématique. Pour faciliter le test des contrats pour les développeurs, la bibliothèque ontio_std fournit un module de simulation pour les tests. Ce module assure la simulation des données dans la chaîne, facilitant ainsi le test unitaire des méthodes dans le contrat. Des exemples spécifiques peuvent être trouvés ici.

Débogage du contrat

console::debug(msg) affiche des informations de débogage lors du débogage du contrat. L'information msg sera enregistrée dans le fichier journal du nœud. Il est impératif de définir le niveau du fichier journal en mode débogage lorsque le nœud de test local d'Ontology est en cours d'exécution.

runtime::notify(msg) affiche les informations de débogage pertinentes lors du débogage du contrat. Cette méthode enregistrera les informations ajoutées dans la chaîne et pourra être demandée à partir de la chaîne à l'aide de la méthode getSmartCodeEvent.

Cet article a été traduit par l'équipe de Hashrate & Shares spécialement pour OntologyRussia. cliquer

Vous êtes développeur ? Rejoignez notre communauté technique sur Discord. De plus, jetez un coup d'œil à Centre des développeurs sur notre site, où vous pouvez trouver des outils pour développeurs, de la documentation et bien plus encore.

Ontology

• site Ontology
• GitHub / Discord
• Telegram Français / Russe
• Twitter / Reddit

Source : habr.com