Article original de Shelven Zhou, chercheur en chef de Phala Network
conférence WASM 2022
Qu’est-ce que le calcul Off-Chain ?
Avant d’introduire les calculs off-chain, abordons d’abord le modèle de calcul on-chain adopté par la plupart des smart contracts existants.
Illustration 1. Exécution on-chain des transactions
L’illustration 1 montre le modèle d’exécution on-chain. L’exécution on-chain elle même est déterministe : la transaction est exécutée par tous les nœuds et il doivent d’accorder sur l’état final.
De tels exigences sur l’état implique des limitations : C’est cher et lent. Plus important, les opérations telles que les requêtes de réseau sont interdites dans la mesure où le résultat final peut être différent sur différents nœuds (les requêtes réseau pourraient échouer sur certains nœuds et réussir sur d’autres).
llustration 2. Exécution off-chain pour le blockhain.
L’exécution off-chain a d’abord été proposée pour satisfaire aux besoins des Oracles, par exemple, pour introduire des entrées off-chain comme le prix en temps réel du BTC sur certains exchanges durant l’exécution. À l’inverse de l’exécution on-chain, l’exécution off-chain est conduite par un nombre limité, voire un seul, worker (nœuds de réseau Phala/Khala). Cela optimise les performances et le coût. Maintenant, les nœuds n’ont besoin que de vérifier que les résultats de l’exécution sont véritablement produit par les workers (c’est un peu comme un rollup d’une seule transaction)
Ce modèle, malheureusement, a également des limitations. La confiance des workers off-chain est impliquée dans cette solution dans la mesure où les nœuds on-chain peuvent seulement savoir que les workers produisent les résultats mais par qu’ils utilisent la bonne entrée off-chain ni qu’ils produisent un résultat fidèle. C’est pourquoi une telle solution n’est habituellement utilisée que par les équipes de développement de la chaine qui hébergent leur propres workers.
Un pas vers une infrastructure off-chain sans tiers de confiance
La clé du problème énoncé plus haut, est de trouver un moyen de faire confiance aux workers off-chain, et il y a quelques candidats tels que les méthodes de calcul vérifiable, de ZKP (zero knowledge proof), ou les solutions fondées sur le matériel telles que les enclaves sécurisées.
Phala est un réseau de Cloud Computing décentralisé sans tiers de confiance dont les noeuds de mineurs sont tous des workers sécurisés qui utilisent les enclaves sécurisées. L’enclave sécurisée est habituellement implémentée comme un sous-système sécurisé dans les processeurs modernes et fournissent deux importantes garanties de sécurité : La confidentialité et l’intégrité de l’exécution. Ce la signifie que les opérateurs malintentionnés, même avec un accès physique, ne peuvent pas lire l’état dans la mémoire (étant donné qu’il est crypté par une puce dédiée), ni manipuler l’exécution du programme pour fournier de mauvais résultats. Avec ça, même les développeurs individuels peuvent louer leur propre worker off-chain auprès de la blockchain Phala et profiter des avantages.
Ceci nous conduit à concevoir un nouveau modèle d’exécution de contrat, par exemple, le Phat Contract (anciennement Fat Contract) qui est capable de réaliser des calculs off-chain. Il est à noter que nous avons délibérément fait le choix de ne pas simplement migrée l’EVM dans une enclave sécurisée étant donnée qu’il a été conçu pour les exécutions on-chain et donc difficile à étendre.
Fonctionnalités et Scénarios d’utilisation
Le Phat Contract est sensé être écrit avec Ink! de Parity. Du point de vue d’un développeur, il y a une petite différence lorsqu’on écrit des contrats Ink! et des Phat Contract, à l’exception des extensions que nous fournissons pour le Phat Contract. La principale différence est l’endroit où ils sont exécutés : Le contrat Ink! est exécuté par les noeuds Substrate et le Phat Contract dans le pRuntime (Runtime personnalisé par Phala) dans nos workers sécurisés off-chain. Evidemment, le Phat Contract profite de tous les bénéfices énoncés plus haut.
Illustration 3. Comparaison du Phat Contract avec les actuels Smart Contracts
Avec le Phat Contract, il est à présent possible d’implémenter les applications qui nécessitaient la création d’une nouvelle chainie avec un seul contrat.
Illustration 4. Les scenarios d’utilisation du Phat Conract
Le modèle du Phat Contract
La conception du principe du Phat Contract est simple : Tout en prenant en charge l’ancienne logique d’exécution en chaîne, il essai de fournir un environnement complet d’exécution off-chain avec confidentialité, haute performance, et des fonctions nécessaires telles que l’accès à internet et au stockage. Notre idée ici, est que seul une petite fraction de l’état (comme le solde de token et la possession de NFT) dans les Dapps nécessite de persister on-chain, c’est pourquoi nous encourageons les développeurs à implémenter la plupart de leur logique off-chain.
Illustration 5. Exemple d’un Phat Contract Ink!
Parler n’a pas beaucoup de valeur, laissez-moi vous montrer un peu de code. C’est le contrat Hello World de Ink!. Comme promis, vous pouvez le faire fonctionner dans Phala sans modification. Dans ce contrat, l’état (on-chain) du contrat est décrit par la variable value. Et en fonction de, si l’état sera changé, les fonctions suivantes sont divisées en deux classes, mutable (flip() function) et immutable (get() function). En correspondance, nous divisons les requêtes des utilisateurs à ces fonctions en Commands, qui sont envoyées en fonctions mutables et changeons l’état on-chain, et Query, qui sont envoyés aux fonctions immutables et laissons l’état on-chain inchangé.
Illustration 6. Exécution d’une commande dans le Phat Contract
Parmi elles, la Commande suit le chemin traditionnel de l’exécution off-chain, sauf qu’il est crypté et ne peut être décrypté que dans les enclaves sécurisées. Cela signifie que les Command, comme les transactions normales, doivent être publiées on-chain, mise dans un block, puis synchronisées avec les workers off-chain pour l’exécution. Cela peut représenter une limite de performance et doit donc être utilisé avec précautions.
- Exécution de Query dans le Phat Contract
d’un autre côté, et bien différent. D’abord, il est directement envoyé au Workers Sécurisés exactement comme une communication Client/Serveur, il est donc libérer des latences de transaction de la blockchain et des frais de transaction pour l’exécution (vous louez le worker au lieu de payer pour chaque instruction dans le traitement de Query). Puis, Query est sensé changer l’état local (off-chain). Nous lui donnons plus de puissance avec la possibilité d’écrire/lire le cache local et d’envoyer des requêtes HTTP. Cela signifie que vous pouvez directement utiliser tous les services web existants, incluant les flux de données, les APIs des bot Telegram/Discord, les stockages en ligne tels que AWS et plus encore.
En d’autres mots, lorsque vous écrivez des fonctions pour Query, c’est plus comme si vous écriviez un programme normal pour serveurs plutôt qu’un smart contract. Mais cette fois, votre prorgamme de serveur est exécuté sur un véritable Cloud Computing décentralisé et peut utiliser la blockchain comme source de confiance : Chaque Phat Contract vient avec une paire de clés dont la clé publique est publiée on-chain. Cette paire de clé prouve l’identité du programme et peut être utiliser pour signier n’importe quel message pour prouver qu’ils sont véritablement produits par un contrat certifié, et qu’on peut donc lui faire confiance. Cela permet des opérations d’attestation, qui sont la base des Oracles, de l’identité décentralisée, et d’autres applications intéressantes du web3.
Pourquoi ne pas vous salir les mains et essayer vous-même le Phat Contract ?