Initialement publié en anglais par StarkWare le 11 janvier, 2022

Libérer la Richesse de Calcul des L2

Les dApps L2-natives peuvent désormais s'épanouir sans les traditionnelles restrictions de gas du L1.

Les développeurs de dApps ont toujours été confrontés à de fortes contraintes dues à la limite de gas de bloc d'Ethereum (L1). Cela limite non seulement la façon dont ces dApps fonctionnent, mais aussi ce que ces dApps sont capables de faire.

Le layer 2 (L2) offre aux développeurs de dApps un champ libre informatique, libre de ce plafond de verre. Nous pensons que la grande majorité des dApps seront L2-natives d'ici quelques années : elles auront été construites de A à Z sur le L2 pour bénéficier de ce degré de liberté informatique.

Examinons deux exemples de dApps populaires dont la conception est profondément façonnée par les contraintes liées au gas du L1 : les AMMs et les DEX aggregators.

Un Automated Market Maker (AMM) est essentiellement une exchange basée sur un order-book (carnet d’ordres). Au lieu de permettre aux utilisateurs de placer et de supprimer des limites, des stop loss, ou une variété d'autres types d'ordres, les AMMs L1 ne permettent que de simples échanges avec une pool de liquidité sous-jacente centrale - pour tenir compte du coût de calcul intense du L1.

Idéalement, les DEX aggregators doivent avoir accès à toutes les pools de liquidité possibles, même les plus petites, afin d'obtenir les meilleurs prix pour les utilisateurs. Cependant, en raison du coût de l'interrogation de nombreuses pools différentes, il n'est tout simplement pas intéressant d'effectuer des transactions sur le L1. Il est justifié d'accéder aux pools et de payer les frais de transaction associés uniquement lorsque les pools de liquidité ont une liquidité suffisamment importante. Dans le même ordre d'idées, les liquidations dans les prêts/emprunts (lending/borrowing) et autres dApps basées sur les garanties (collateral) pourraient être beaucoup plus précises si la différence entre le discount de liquidation et les frais de transaction était beaucoup plus faible.

La fonctionnalité et la conception limitées de nombreuses dApps L1 résultent directement du fait que les développeurs ont optimisé leur code pour respecter les contraintes de gas d'Ethereum. Pourquoi, me direz-vous, parlons-nous d'Ethereum ? Le code Solidity ne peut-il pas fonctionner sur plusieurs L1 et même quelques L2 ? En effet, mais parmi ceux-ci, Ethereum est l'environnement le plus coûteux (et, par conséquent, le plus sûr). Les dApps Solidity sont conçues pour "le lien le plus cher", c'est-à-dire Ethereum. Par conséquent, ils ne bénéficient pas de l'avantage informatique offert par les environnements d'exécution moins coûteux. Pour débloquer les fonctionnalités auxquelles on a renoncé en concevant une dApp pour l'environnement d'exécution le plus coûteux, le code de la dApp doit être adapté.

Les Validity Rollups (alias ZK-Rollups) permettent un calcul extrêmement bon marché. Contrairement à toute autre solution de scalabilité, le calcul L2 peut croître de manière exponentielle avec seulement un faible impact sur le montant du gas de vérification on-chain. En outre, un Validity Rollup traite les entrées des calculs - les "données témoins" - sans consommer de ressources L1 supplémentaires, ce qui permet de réaliser des calculs avec de nombreuses entrées.

Le codage natif des dApps sur le L2 en Cairo (un langage Turing-complete permettant de scale les dApps via des STARK proofs) ouvre un vaste champ de possibilités aux développeurs. Il leur permet d'utiliser d'importantes quantités de données - données de calcul et de témoignage - qu'ils ne pouvaient pas utiliser auparavant.

Explorons ces dApps L2-natives et leurs nouvelles capacités enrichies.

Avant d'être intégré à StarkEx, le Validity Rollup de StarkWare, dYdX fonctionnait comme une dApp L1 sur Ethereum. Il offrait à ses utilisateurs un effet de levier de x10 sur les actifs synthétiques et prenait en charge des positions avec un seul actif synthétique. La reconstruction de dYdX sur Cairo en tant que dApp L2-native fournit une plateforme DeFi nettement plus évolutive, moins chère et plus efficace :

• Mises à jour des prix de l’Oracle : Ces mises à jour comprennent généralement des dizaines de prix et de signatures provenant de diverses sources pour calculer une médiane. Un Validity Rollup permet un scaling exponentiel de la logique des prix d'oracle (vérification des signatures et calcul du prix médian) - sans communiquer ces données témoins au L1. Comparez cela à l'implémentation L1 de dYdX, où chaque mise à jour des prix d'oracle coûtait environ 300K de gas et était, par conséquent, limitée dans sa fréquence et la taille de l'ensemble des rapporteurs de prix.

• Effet de levier : Un flux de prix précis permet à dYdX d'estimer le risque d'une position en temps réel et d'offrir un effet de levier plus élevé aux utilisateurs. Grâce à l'amélioration des mises à jour des prix d'oracle, dYdX a augmenté l'effet de levier de x10 sur le L1 à x25 sur le L2.

• Marge croisée (cross-margin) : Avec dYdX sur le L2, les market makers peuvent placer des ordres long/short sur de nombreux actifs en utilisant le même collateral. Le règlement moyen sur le L2 de dYdX implique des positions sur plus de 10 actifs synthétiques différents ! En comparaison, avoir cette capacité de marge croisée sur le L1 aurait plus que doublé le coût du gas on-chain.

Les jeux actuels L1-native stockent généralement les ressources du jeu sur le L1 tout en implémentant l'ensemble de la logique du jeu dans une application off-chain de confiance. Ce modèle est le résultat direct des limitations de gas du L1. Grâce au calcul bon marché sur le L2, les développeurs de dApps de jeu L2-native peuvent désormais implémenter la logique de jeu dans un smart contract et manipuler les actifs du jeu en toute confiance, plutôt que de simplement les stocker. Faire entrer la logique de jeu dans le domaine du calcul sans confiance (trustless) est une étape importante vers un monde beaucoup plus riche de jeux basés sur la blockchain. Des jeux L2-natives sont déjà développés sur StarkNet, le réseau permissionless (sans permission) de StarkWare (par exemple, Dope Wars et Influence).

Mais quelle peut être la complexité réelle d'un jeu basé sur la blockchain ? Par exemple, la gestion des graphiques directement sur la blockchain semble impossible - ou l'est-elle ? Résoudre des équations différentielles et simuler un mouvement planaire dans un smart contract représente une étape importante vers ce qui, à l'avenir, pourrait être un moteur physique de blockchain. Les implications sont énormes. Imaginez un jeu multijoueur compétitif comme Counter-Strike. Si l'on pouvait simuler la logique du jeu on-chain, les nombreux piratages redoutés appartiendraient au passé et les joueurs pourraient profiter d'un jeu dont l'équité est prouvée.

L'Art Génératif utilise le calcul, le caractère aléatoire et d'autres données pour créer un art basé sur la blockchain. Plus la logique et le calcul sont complexes et plus l'artiste peut les utiliser en toute confiance, plus il existe d'options pour générer des œuvres d'art uniques et singulières. WhaleStreet DAO lance l'un des premiers projets d'art génératif sur StarkNet, en tirant parti des ressources de calcul illimitées de StarkNet.

Les Validity Rollups - StarkEx et StarkNet alimentés par Cairo, en particulier - fournissent un environnement dans lequel on peut développer et exploiter des dApps qui consomment beaucoup de calculs ou de données témoins. Avec tous les avantages de la technologie du grand livre distribué (distributed ledger technology), nous prévoyons un avenir extrêmement excitant pour les dApps L2-natives.

Que pouvez-vous créer avec une puissance de calcul générale soutenue par la composabilité, la fiabilité et la décentralisation ?

Traduction faite par HoVa.

Initialement publié en anglais par StarkWare le 11 janvier, 2022

Libérer la Richesse de Calcul des L2

Les dApps L2-natives peuvent désormais s'épanouir sans les traditionnelles restrictions de gas du L1.

Les développeurs de dApps ont toujours été confrontés à de fortes contraintes dues à la limite de gas de bloc d'Ethereum (L1). Cela limite non seulement la façon dont ces dApps fonctionnent, mais aussi ce que ces dApps sont capables de faire.

Le layer 2 (L2) offre aux développeurs de dApps un champ libre informatique, libre de ce plafond de verre. Nous pensons que la grande majorité des dApps seront L2-natives d'ici quelques années : elles auront été construites de A à Z sur le L2 pour bénéficier de ce degré de liberté informatique.

Examinons deux exemples de dApps populaires dont la conception est profondément façonnée par les contraintes liées au gas du L1 : les AMMs et les DEX aggregators.

Un Automated Market Maker (AMM) est essentiellement une exchange basée sur un order-book (carnet d’ordres). Au lieu de permettre aux utilisateurs de placer et de supprimer des limites, des stop loss, ou une variété d'autres types d'ordres, les AMMs L1 ne permettent que de simples échanges avec une pool de liquidité sous-jacente centrale - pour tenir compte du coût de calcul intense du L1.

Idéalement, les DEX aggregators doivent avoir accès à toutes les pools de liquidité possibles, même les plus petites, afin d'obtenir les meilleurs prix pour les utilisateurs. Cependant, en raison du coût de l'interrogation de nombreuses pools différentes, il n'est tout simplement pas intéressant d'effectuer des transactions sur le L1. Il est justifié d'accéder aux pools et de payer les frais de transaction associés uniquement lorsque les pools de liquidité ont une liquidité suffisamment importante. Dans le même ordre d'idées, les liquidations dans les prêts/emprunts (lending/borrowing) et autres dApps basées sur les garanties (collateral) pourraient être beaucoup plus précises si la différence entre le discount de liquidation et les frais de transaction était beaucoup plus faible.

La fonctionnalité et la conception limitées de nombreuses dApps L1 résultent directement du fait que les développeurs ont optimisé leur code pour respecter les contraintes de gas d'Ethereum. Pourquoi, me direz-vous, parlons-nous d'Ethereum ? Le code Solidity ne peut-il pas fonctionner sur plusieurs L1 et même quelques L2 ? En effet, mais parmi ceux-ci, Ethereum est l'environnement le plus coûteux (et, par conséquent, le plus sûr). Les dApps Solidity sont conçues pour "le lien le plus cher", c'est-à-dire Ethereum. Par conséquent, ils ne bénéficient pas de l'avantage informatique offert par les environnements d'exécution moins coûteux. Pour débloquer les fonctionnalités auxquelles on a renoncé en concevant une dApp pour l'environnement d'exécution le plus coûteux, le code de la dApp doit être adapté.

Les Validity Rollups (alias ZK-Rollups) permettent un calcul extrêmement bon marché. Contrairement à toute autre solution de scalabilité, le calcul L2 peut croître de manière exponentielle avec seulement un faible impact sur le montant du gas de vérification on-chain. En outre, un Validity Rollup traite les entrées des calculs - les "données témoins" - sans consommer de ressources L1 supplémentaires, ce qui permet de réaliser des calculs avec de nombreuses entrées.

Le codage natif des dApps sur le L2 en Cairo (un langage Turing-complete permettant de scale les dApps via des STARK proofs) ouvre un vaste champ de possibilités aux développeurs. Il leur permet d'utiliser d'importantes quantités de données - données de calcul et de témoignage - qu'ils ne pouvaient pas utiliser auparavant.

Explorons ces dApps L2-natives et leurs nouvelles capacités enrichies.

Avant d'être intégré à StarkEx, le Validity Rollup de StarkWare, dYdX fonctionnait comme une dApp L1 sur Ethereum. Il offrait à ses utilisateurs un effet de levier de x10 sur les actifs synthétiques et prenait en charge des positions avec un seul actif synthétique. La reconstruction de dYdX sur Cairo en tant que dApp L2-native fournit une plateforme DeFi nettement plus évolutive, moins chère et plus efficace :

• Mises à jour des prix de l’Oracle : Ces mises à jour comprennent généralement des dizaines de prix et de signatures provenant de diverses sources pour calculer une médiane. Un Validity Rollup permet un scaling exponentiel de la logique des prix d'oracle (vérification des signatures et calcul du prix médian) - sans communiquer ces données témoins au L1. Comparez cela à l'implémentation L1 de dYdX, où chaque mise à jour des prix d'oracle coûtait environ 300K de gas et était, par conséquent, limitée dans sa fréquence et la taille de l'ensemble des rapporteurs de prix.

• Effet de levier : Un flux de prix précis permet à dYdX d'estimer le risque d'une position en temps réel et d'offrir un effet de levier plus élevé aux utilisateurs. Grâce à l'amélioration des mises à jour des prix d'oracle, dYdX a augmenté l'effet de levier de x10 sur le L1 à x25 sur le L2.

• Marge croisée (cross-margin) : Avec dYdX sur le L2, les market makers peuvent placer des ordres long/short sur de nombreux actifs en utilisant le même collateral. Le règlement moyen sur le L2 de dYdX implique des positions sur plus de 10 actifs synthétiques différents ! En comparaison, avoir cette capacité de marge croisée sur le L1 aurait plus que doublé le coût du gas on-chain.

Les jeux actuels L1-native stockent généralement les ressources du jeu sur le L1 tout en implémentant l'ensemble de la logique du jeu dans une application off-chain de confiance. Ce modèle est le résultat direct des limitations de gas du L1. Grâce au calcul bon marché sur le L2, les développeurs de dApps de jeu L2-native peuvent désormais implémenter la logique de jeu dans un smart contract et manipuler les actifs du jeu en toute confiance, plutôt que de simplement les stocker. Faire entrer la logique de jeu dans le domaine du calcul sans confiance (trustless) est une étape importante vers un monde beaucoup plus riche de jeux basés sur la blockchain. Des jeux L2-natives sont déjà développés sur StarkNet, le réseau permissionless (sans permission) de StarkWare (par exemple, Dope Wars et Influence).

Mais quelle peut être la complexité réelle d'un jeu basé sur la blockchain ? Par exemple, la gestion des graphiques directement sur la blockchain semble impossible - ou l'est-elle ? Résoudre des équations différentielles et simuler un mouvement planaire dans un smart contract représente une étape importante vers ce qui, à l'avenir, pourrait être un moteur physique de blockchain. Les implications sont énormes. Imaginez un jeu multijoueur compétitif comme Counter-Strike. Si l'on pouvait simuler la logique du jeu on-chain, les nombreux piratages redoutés appartiendraient au passé et les joueurs pourraient profiter d'un jeu dont l'équité est prouvée.

L'Art Génératif utilise le calcul, le caractère aléatoire et d'autres données pour créer un art basé sur la blockchain. Plus la logique et le calcul sont complexes et plus l'artiste peut les utiliser en toute confiance, plus il existe d'options pour générer des œuvres d'art uniques et singulières. WhaleStreet DAO lance l'un des premiers projets d'art génératif sur StarkNet, en tirant parti des ressources de calcul illimitées de StarkNet.

Les Validity Rollups - StarkEx et StarkNet alimentés par Cairo, en particulier - fournissent un environnement dans lequel on peut développer et exploiter des dApps qui consomment beaucoup de calculs ou de données témoins. Avec tous les avantages de la technologie du grand livre distribué (distributed ledger technology), nous prévoyons un avenir extrêmement excitant pour les dApps L2-natives.

Que pouvez-vous créer avec une puissance de calcul générale soutenue par la composabilité, la fiabilité et la décentralisation ?

Traduction faite par HoVa.