- Une version alpha des smart contracts d’IOTA pour la communauté X-Team est sur le point d’être lancée.
- Dans un premier temps, les deux langages de programmation Rust et Go seront disponibles.
Comme le co-fondateur d’IOTA, Dominik Schiener, l’a annoncé hier via Discord, le lancement d’une version alpha du protocole ISCP (IOTA Smart Contracts Protocol) est imminent. Après que la Fondation IOTA ait déjà publié une première version pré-alpha en octobre de l’année dernière, la solution de deuxième couche tant attendue pourrait maintenant être bientôt disponible pour un groupe sélectionné de testeurs.
Comme pour les projets précédents, IOTA Foundation utilisera les « X teams », un groupe de membres de la communauté dévoués qui travaillent avec le personnel de IOTA Foundation à différents stades de développement, pour obtenir un premier retour d’information. Schiener a écrit via Discord:
Tous ceux qui veulent commencer à construire avec nous des smart contracts IOTA pour notre version Alpha, veuillez vous préparer. Les X Teams seront lancés très bientôt.
IOTA s’appuie sur Rust and Go
En octobre, la Fondation IOTA a dévoilé trois preuves de concepts (Proof of Concepts – PoC) élaborées pour démontrer « l’état de l’art de la mise en œuvre du protocole de smart contracts d’IOTA (ISCP) » Parallèlement, la fondation a également publié un ensemble d’outils permettant aux développeurs d’explorer les fonctionnalités du smart contracts d’IOTA.
La version alpha pour l’équipe X permettra désormais aux développeurs externes, au-delà de la Fondation IOTA, d’écrire des smart contracts pour la première fois. Comme l’a révélé Eric Hop, propriétaire principal des produits pour les smart contracts à la Fondation IOTA, les deux langages de programmation Rust et Go seront disponibles dès le lancement. « Nous travaillons sur la documentation », a ajouté M. Hop.
D’autres langages de programmation sont envisageables, mais nécessiteront une bibliothèque d’interface vers Wasm:
Ce n’est pas aussi simple qu’un langage supportant le Wasm. Vous devez toujours connecter ce langage spécifique à l’environnement de bac à sable du nœud Wasp. Pensez à fournir la bibliothèque d’interface pour ce langage. Nous avons actuellement les bibliothèques d’interface pour Rust and Go.
La conception de notre bibliothèque est telle qu’elle devrait être simple à créer sur d’autres langues, mais ces autres langues auront besoin d’une génération de code Wasm appropriée. C’est là que la plupart des langues manquent encore. Même l’implémentation de Go comporte quelques paquets qui ne sont pas encore traduits correctement.
Lorsqu’on lui a demandé si l’environnement du bac à sable sera « exactement » le même que celui des smart contracts sur le réseau principal, M. Hop a révélé qu’il sera possible de migrer le smart contract de testnet vers le réseau principal:
Oui. Une fois que nous pourrons fonctionner sur le réseau principal, les SCs que vous avez créés sur le réseau test fonctionneront simplement La conception de l’ISCP est très compartimentée. Les modules de consensus et de VM sont complètement indépendants de l’implémentation sous-jacente de Tangle. Ce qui signifie que la VM Wasm est également complètement indépendante du réseau sous-jacent.
Actuellement, nous utilisons le goshimmer parce qu’il nous fournit les conditions de base dont nous avons besoin (UTXO, jetons de couleur et signatures BLS). Mais une fois qu’ils seront disponibles dans Chrysalis, nous adapterons la couche réseau ISCP en conséquence et la ferons fonctionner.
