Initialement publié en anglais par StarkWare le 11 novembre, 2020

Paiement trustless pour les smarts contracts évolutifs

Nous avons récemment lancé VeeDo 0.1 sur le Mainnet, et il est alimenté par un modèle économique que nous appelons le modèle de distributeur automatique. Nous pensons que ce modèle commercial peut être utilisé à bon escient dans l'espace blockchain. Il permet de payer en toute confiance des services rendus par des smarts contracts évolutifs : des smarts contracts qui servent de front-end pour des fonctionnalités de couche 2 (L2) fonctionnant dans le cloud.

La nécessité de faire évoluer les blockchains, c'est-à-dire de déplacer le calcul et le stockage off-chain, vers le cloud, est bien comprise, d'où le grand intérêt pour les solutions L2. En dehors de l'espace blockchain, SaaS est le modèle commercial dominant pour les services basés sur le cloud. Malheureusement, SaaS n'est pas suffisant pour l'écosystème blockchain, qui privilégie les services ayant les propriétés suivantes :

Trustless

L'objectif est de minimiser les hypothèses de confiance pour tous les participants.

Utilisateurs : ils n'ont pas besoin de faire confiance à leurs fournisseurs de services pour exécuter le service, effectuer les calculs correctement, etc. Les fournisseurs de services : ils n'ont pas besoin de faire confiance à leurs utilisateurs (par exemple, pour effectuer un paiement périodique).

Permissionless

Rendre des services sans accorder explicitement la permission (par exemple, en approuvant les détails de la carte de crédit).

Censure-Résistance

Censure explicite : empêcher certains utilisateurs d'accéder à un service. Censure implicite : déformation du résultat du service en faveur du fournisseur de services en nuage ou de ses clients.

Transactionnel

Fournir des services au niveau d'une transaction unique, sans engagement ou relation à long terme.

Nous pensons que le modèle de distributeur automatique soutient la fourniture de services informatiques sans confiance par des solutions L2 sur des blockchains.

Supposons qu'Alice ait besoin d'effectuer un calcul C sur Ethereum, mais qu'il soit impossible de le faire on-chain en raison des dépenses élevées en essence. Nous décrivons un modèle qui permet à Alice d'externaliser le calcul à un service off-chain Le modèle garantit à Alice qu'elle obtiendra le résultat correct pour le calcul demandé ou qu'elle récupérera son argent.

1. Alice envoie une demande d'exécution d'un calcul C au contrat du distributeur automatique, en payant à l'avance le montant requis au contrat.

2. Le service off-chain voit la demande de calcul et décide de la traiter ou non, en fonction du montant payé.

3. Le service off-chain soumet (a) au contrat Verifier : une preuve attestant de la validité du résultat ; (b) au contrat Vending Machine : le résultat du calcul.

4. Si le Verifier a accepté la preuve, le Vending Machine envoie le paiement à l'adresse Ethereum du service off-chain.

5. Si aucun résultat valide n'a été soumis au distributeur automatique dans un délai prédéfini, Alice récupère son paiement.

VeeDo, notre service VDF (Verifiable Delay Function) basé sur STARK, nous a présenté un cas d'utilisation intéressant, et nous a aidé à cristalliser le modèle de distributeur automatique. Dans VeeDo, Alice veut calculer la valeur d'une fonction de délai df() sur une entrée (x,t), afin d'utiliser df(x,t) dans son propre smart contract. Par exemple, elle peut servir de source d'aléa robuste et sans confiance. Effectuer ce calcul sur L1 est d'un coût prohibitif, en termes de gaz. Bob peut aider Alice, en effectuant le calcul off-chain et en présentant son résultat, y, on-chain. Le modèle de distributeur automatique permet à Alice de consommer le service VeeDo et de le payer en toute confiance. Il permet à Bob de recevoir le paiement en toute confiance, réduisant ainsi son risque commercial.

Alice alimente le smart contract VeeDo sur Ethereum avec le paiement requis, et avec ses entrées (x,t). Bob suit l'état du smart contract. Dès qu'il voit qu'un paiement a été effectué, il calcule (x,t) dans le nuage, et calcule la preuve STARK attestant de l'exactitude de df(x,t). Il soumet à la fois la preuve STARK et df(x,t) au smart contract VeeDo. Si la preuve est vérifiée, df(x,t) est stocké, et le smart contract VeeDo transfère le paiement d'Alice à Bob.

Passons en revue certains défis et opportunités que nous voyons sur la route.

Le modèle de distributeur automatique comprend le smart contract fonctionnant sur L1, et un service fonctionnant sur L2.

L1, du moins sur Ethereum, est déjà bien décentralisé. L2 n'est pas encore correctement décentralisé. La solution est évidemment d'améliorer la décentralisation des services L2. Comme de nombreux autres acteurs de l'écosystème, nous considérons qu'il s'agit d'un processus progressif, qui aboutira à un grand nombre de fournisseurs de services L2 sans autorisation. Nous pensons que le modèle de distributeur automatique se prête à la présence de plusieurs fournisseurs de services dans le nuage, tous en concurrence pour servir les utilisateurs, ce qui favorise la décentralisation de L2.

Cairo est notre cadre et notre langage pour produire des preuves STARK pour le calcul général (Turing-complet). Un smart contract Cairo Verifier est déjà déployé sur le Mainnet Ethereum (car il sert StarkEx 2.0, la dernière version du moteur d'évolutivité de StarkWare).

L'un des avantages pratiques de Cairo est de disposer d'un smart contract vérificateur unique qui peut vérifier les preuves de tout programme Cairo ; il n'est pas nécessaire de déployer un smart contract vérificateur distinct pour une application spécifique.

L'application du modèle de distributeur automatique au smart contract du vérificateur du Caire pourrait présenter un modèle commercial intéressant pour les entités produisant des preuves STARK dans le nuage. La tarification dépendrait de divers paramètres du programme du Caire (pensez au prix du gaz pour divers opcodes sur Ethereum). La preuve STARK peut inclure des attestations concernant ces paramètres ("Les transactions de l'app_1 incluses dans ce lot : 10 multiplications et 7 écritures"), permettant ainsi au service d'être rendu et consommé de manière transparente.

Un distributeur automatique du Caire peut aller plus loin : il peut offrir quelque chose d'exceptionnellement intéressant à la longue traîne des applications à faible bande passante. Cela peut être réalisé grâce au GPS (Generic Proof Service), qui fait partie de la pile logicielle du Cairo. Le GPS permet de regrouper les calculs de plusieurs applications indépendantes (par exemple, des lots séparés de transactions de dYdX, Immutable, DeversiFi) dans une seule preuve STARK. Le coût de vérification de cette preuve on-chain peut être supporté conjointement par ces applications. Précisons.

Les calculs effectués par une application sur L1, c'est-à-dire la blockchain elle-même, ont une certaine valeur économique v qui leur est associée (par exemple, les frais générés pour une transaction ou la sélection du gagnant d'une loterie). L'application ne peut pas durablement dépenser plus que v pour effectuer ce calcul. Il s'ensuit que de nombreux calculs de moindre valeur tomberont sous un seuil de viabilité économique L1. Dans le modèle du distributeur automatique, ce seuil est limité par le coût de génération d'une preuve STARK off-chain, plus le coût de vérification de cette preuve on-chain. Grâce au GPS, les coûts peuvent être amortis sur l'ensemble des applications dont les calculs sont agrégés dans la preuve. Par conséquent, c'est la valeur cumulée derrière ces calculs agrégés qui doit dépasser le seuil de viabilité. La nature sans confiance du distributeur automatique du Caire permettrait à ces applications de coordonner le paiement d'une manière équitable et efficace.

Pour conclure, abusons encore un peu de la métaphore du distributeur automatique. Ce que nous avons n'est rien d'autre qu'un acheteur (une application, ou un utilisateur) qui veut acheter une seule bouteille (calcul) du distributeur automatique, sans avoir à couvrir seul le coût d'un coûteux camion de livraison de fournitures (le coût de génération et de vérification d'une preuve de validité). Tout cela est possible grâce au GPS qui vient s'ajouter au Caire.

Le modèle Vending Machine permet le déploiement de services trustless pour des smart contracts évolutifs, c'est-à-dire des smart contracts alimentés par des services L2. En appliquant ce modèle à un smart contract Cairo Verifier, les avantages des services de mise à l'échelle L2 peuvent être apportés à la longue traîne des applications décentralisées.

Tom Brand & Uri Kolodny

Traduction faite par Valentin Negro

Initialement publié en anglais par StarkWare le 11 novembre, 2020

Paiement trustless pour les smarts contracts évolutifs

Nous avons récemment lancé VeeDo 0.1 sur le Mainnet, et il est alimenté par un modèle économique que nous appelons le modèle de distributeur automatique. Nous pensons que ce modèle commercial peut être utilisé à bon escient dans l'espace blockchain. Il permet de payer en toute confiance des services rendus par des smarts contracts évolutifs : des smarts contracts qui servent de front-end pour des fonctionnalités de couche 2 (L2) fonctionnant dans le cloud.

La nécessité de faire évoluer les blockchains, c'est-à-dire de déplacer le calcul et le stockage off-chain, vers le cloud, est bien comprise, d'où le grand intérêt pour les solutions L2. En dehors de l'espace blockchain, SaaS est le modèle commercial dominant pour les services basés sur le cloud. Malheureusement, SaaS n'est pas suffisant pour l'écosystème blockchain, qui privilégie les services ayant les propriétés suivantes :

Trustless

L'objectif est de minimiser les hypothèses de confiance pour tous les participants.

Utilisateurs : ils n'ont pas besoin de faire confiance à leurs fournisseurs de services pour exécuter le service, effectuer les calculs correctement, etc. Les fournisseurs de services : ils n'ont pas besoin de faire confiance à leurs utilisateurs (par exemple, pour effectuer un paiement périodique).

Permissionless

Rendre des services sans accorder explicitement la permission (par exemple, en approuvant les détails de la carte de crédit).

Censure-Résistance

Censure explicite : empêcher certains utilisateurs d'accéder à un service. Censure implicite : déformation du résultat du service en faveur du fournisseur de services en nuage ou de ses clients.

Transactionnel

Fournir des services au niveau d'une transaction unique, sans engagement ou relation à long terme.

Nous pensons que le modèle de distributeur automatique soutient la fourniture de services informatiques sans confiance par des solutions L2 sur des blockchains.

Supposons qu'Alice ait besoin d'effectuer un calcul C sur Ethereum, mais qu'il soit impossible de le faire on-chain en raison des dépenses élevées en essence. Nous décrivons un modèle qui permet à Alice d'externaliser le calcul à un service off-chain Le modèle garantit à Alice qu'elle obtiendra le résultat correct pour le calcul demandé ou qu'elle récupérera son argent.

1. Alice envoie une demande d'exécution d'un calcul C au contrat du distributeur automatique, en payant à l'avance le montant requis au contrat.

2. Le service off-chain voit la demande de calcul et décide de la traiter ou non, en fonction du montant payé.

3. Le service off-chain soumet (a) au contrat Verifier : une preuve attestant de la validité du résultat ; (b) au contrat Vending Machine : le résultat du calcul.

4. Si le Verifier a accepté la preuve, le Vending Machine envoie le paiement à l'adresse Ethereum du service off-chain.

5. Si aucun résultat valide n'a été soumis au distributeur automatique dans un délai prédéfini, Alice récupère son paiement.

VeeDo, notre service VDF (Verifiable Delay Function) basé sur STARK, nous a présenté un cas d'utilisation intéressant, et nous a aidé à cristalliser le modèle de distributeur automatique. Dans VeeDo, Alice veut calculer la valeur d'une fonction de délai df() sur une entrée (x,t), afin d'utiliser df(x,t) dans son propre smart contract. Par exemple, elle peut servir de source d'aléa robuste et sans confiance. Effectuer ce calcul sur L1 est d'un coût prohibitif, en termes de gaz. Bob peut aider Alice, en effectuant le calcul off-chain et en présentant son résultat, y, on-chain. Le modèle de distributeur automatique permet à Alice de consommer le service VeeDo et de le payer en toute confiance. Il permet à Bob de recevoir le paiement en toute confiance, réduisant ainsi son risque commercial.

Alice alimente le smart contract VeeDo sur Ethereum avec le paiement requis, et avec ses entrées (x,t). Bob suit l'état du smart contract. Dès qu'il voit qu'un paiement a été effectué, il calcule (x,t) dans le nuage, et calcule la preuve STARK attestant de l'exactitude de df(x,t). Il soumet à la fois la preuve STARK et df(x,t) au smart contract VeeDo. Si la preuve est vérifiée, df(x,t) est stocké, et le smart contract VeeDo transfère le paiement d'Alice à Bob.

Passons en revue certains défis et opportunités que nous voyons sur la route.

Le modèle de distributeur automatique comprend le smart contract fonctionnant sur L1, et un service fonctionnant sur L2.

L1, du moins sur Ethereum, est déjà bien décentralisé. L2 n'est pas encore correctement décentralisé. La solution est évidemment d'améliorer la décentralisation des services L2. Comme de nombreux autres acteurs de l'écosystème, nous considérons qu'il s'agit d'un processus progressif, qui aboutira à un grand nombre de fournisseurs de services L2 sans autorisation. Nous pensons que le modèle de distributeur automatique se prête à la présence de plusieurs fournisseurs de services dans le nuage, tous en concurrence pour servir les utilisateurs, ce qui favorise la décentralisation de L2.

Cairo est notre cadre et notre langage pour produire des preuves STARK pour le calcul général (Turing-complet). Un smart contract Cairo Verifier est déjà déployé sur le Mainnet Ethereum (car il sert StarkEx 2.0, la dernière version du moteur d'évolutivité de StarkWare).

L'un des avantages pratiques de Cairo est de disposer d'un smart contract vérificateur unique qui peut vérifier les preuves de tout programme Cairo ; il n'est pas nécessaire de déployer un smart contract vérificateur distinct pour une application spécifique.

L'application du modèle de distributeur automatique au smart contract du vérificateur du Caire pourrait présenter un modèle commercial intéressant pour les entités produisant des preuves STARK dans le nuage. La tarification dépendrait de divers paramètres du programme du Caire (pensez au prix du gaz pour divers opcodes sur Ethereum). La preuve STARK peut inclure des attestations concernant ces paramètres ("Les transactions de l'app_1 incluses dans ce lot : 10 multiplications et 7 écritures"), permettant ainsi au service d'être rendu et consommé de manière transparente.

Un distributeur automatique du Caire peut aller plus loin : il peut offrir quelque chose d'exceptionnellement intéressant à la longue traîne des applications à faible bande passante. Cela peut être réalisé grâce au GPS (Generic Proof Service), qui fait partie de la pile logicielle du Cairo. Le GPS permet de regrouper les calculs de plusieurs applications indépendantes (par exemple, des lots séparés de transactions de dYdX, Immutable, DeversiFi) dans une seule preuve STARK. Le coût de vérification de cette preuve on-chain peut être supporté conjointement par ces applications. Précisons.

Les calculs effectués par une application sur L1, c'est-à-dire la blockchain elle-même, ont une certaine valeur économique v qui leur est associée (par exemple, les frais générés pour une transaction ou la sélection du gagnant d'une loterie). L'application ne peut pas durablement dépenser plus que v pour effectuer ce calcul. Il s'ensuit que de nombreux calculs de moindre valeur tomberont sous un seuil de viabilité économique L1. Dans le modèle du distributeur automatique, ce seuil est limité par le coût de génération d'une preuve STARK off-chain, plus le coût de vérification de cette preuve on-chain. Grâce au GPS, les coûts peuvent être amortis sur l'ensemble des applications dont les calculs sont agrégés dans la preuve. Par conséquent, c'est la valeur cumulée derrière ces calculs agrégés qui doit dépasser le seuil de viabilité. La nature sans confiance du distributeur automatique du Caire permettrait à ces applications de coordonner le paiement d'une manière équitable et efficace.

Pour conclure, abusons encore un peu de la métaphore du distributeur automatique. Ce que nous avons n'est rien d'autre qu'un acheteur (une application, ou un utilisateur) qui veut acheter une seule bouteille (calcul) du distributeur automatique, sans avoir à couvrir seul le coût d'un coûteux camion de livraison de fournitures (le coût de génération et de vérification d'une preuve de validité). Tout cela est possible grâce au GPS qui vient s'ajouter au Caire.

Le modèle Vending Machine permet le déploiement de services trustless pour des smart contracts évolutifs, c'est-à-dire des smart contracts alimentés par des services L2. En appliquant ce modèle à un smart contract Cairo Verifier, les avantages des services de mise à l'échelle L2 peuvent être apportés à la longue traîne des applications décentralisées.

Tom Brand & Uri Kolodny

Traduction faite par Valentin Negro