Thread by @0xExomonk

[THREAD] Comme prévu ce soir c’est Banger interopérabilité des L1 sur @cosmos et ses smart contrats multi-chain. N'hésitez pas à lire entièrement le thread, il y a de l'inspiration pour les Builder 👀#BUIDL
En 2020, @CosmWasm s’impose comme LE module de SC sur Cosmos

CosmWasm est conçu et construit dès le départ pour être une solution multi-chains pour les smart-contracts. CosmWasm est écrit comme un module qui peut se connecter au SDK Cosmos.

Déployée sur les réseaux principaux de @mars_protocol, @terra_money (@anchor_protocol), @SecretNetwork, @JunoNetwork & récemment @osmosiszone pour permettre une nouvelle forme d'applications DeFi. Pendant ce temps, l'équipe principale de Cosmos SDK était occupée à améliorer l'IBC

Comme vous le savez, IBC est livré avec une seule application - ICS20 : Cela permet à quiconque de construire sans effort des transferts interopérables de tokens entre chaque blockchain construite sur le SDK Cosmos. Il y a selon moi beaucoup de potentiel pour l’IBC & Cosmos.👇

On peut parler des transferts d’NFT inter-chaînes, ou encore des "comptes inter-chain" (où un compte sur la chaîne A peut contrôler à distance un compte sur la chaîne B).

Et donc, pour ajouter un nouveau protocole, il faudrait ajouter une logique à toutes les blockchains impactées par ce protocole. Il ne suffit pas d'ajouter une API à une blockchain. Cependant, nous savons tous à quel point il peut être difficile de coordonner une MaJ blockchain.

Ici, toute personne construisant actuellement une blockchain à l'aide du SDK Cosmos peut ajouter rapidement et facilement la prise en charge des smart contracts CosmWasm à sa chaîne, sans ajuster la logique existante.

Les SC CosmWasm sont similaires en principe à Ethereum, mais il existe un certain nombre de différences dans les détails. Étant donné que la plupart des gens connaissent les Smart Contracts EVM sous Solidity, je vous présente les principales similitudes et différences :

Tout d'abord, le processus de déploiement+exécution se compose en 3 étapes au lieu de 2. Alors qu'Ethereum a été construit autour du concept de nombreux contrats uniques, la réalité semble montrer que la rédaction d'un Smart contract sans exploit / bug est plus difficile

On sait tous qu'actuellement, la majorité sont des simples copies de modèles standard comme OpenZepellin, où des pâles copier-coller de Git sans réelle plue-value.

Dans cet esprit, les SC CosmWasm se présentent donc en 3 étapes :
1. Upload Code - Download d’un code wasm optimisé, sans état ni adresse de contrat (exemple de contrat standard ERC20)

2. Instantiate Contract - Définition de l’état initial du contract (exemple avec la max supply des contracts ERC20)
3. Execute Contract - Exemple : Envoie des tokens, approval de différents contracts...

Tout comme Ethereum, l'instanciation et l'exécution des contrats sont mesurées et nécessitent des gas fees. Les différences majeures ici c’est que lorsque l’on envoi des tokens directement au SC CosmWasm, aucun code du smart contract n’est executé.

L'exactitude du code est primordiale dans les SC. Comme le code est public et qu'il n'y a pas d'"administrateur" pour réparer les choses, il ne doit y avoir aucun bug dans les chemins d'exécution qui puisse être exploité pour produire un comportement indésirable (ou non défini).

C’est un vrai fléau actuellement sur les Smart Contracts Ethereum. Le choix de CosmWasm est d’utiliser un langage Turing Complet comme Solidity, mais avec la sécurité comme objectif principal : Rust.

Cela inclut la limitation de la surface d'attaque possible, mais également de très fortes capacités de test unitaire intégrées pour éliminer facilement les bugs avant le déploiement. (On peut voir l’exemple des exploit de Reentrency sur les DAO Solidity : solidity-by-example.org/hacks/re-entra…)

Bien que la Learning Curve d’apprentissage CosmWasm est plus raide que pour Solidity, le module est construit de tel manière que les développeur de Smart Contracts n’aient plus à avoir recours à des Entreprises d’Audit de contracts De façon systématique

Et cela non plus pour des tests unitaires mais plutôt se concentrer sur la pertinence de la solution et éviter l’erreur humaine.

Pour les plus curieux, je vous laisse lire ce Banger sur les principales attaques et leçon qu’on a pu voir sur les SC Ethereum : docs.cosmwasm.com/docs/1.0/archi…

Pour résumer, les améliorations que CosmWasm apporte : Sécurité, Testing, Performance/Coût, Composition & Lock-In (Switch l’environnement du projet). j’aimerai parler pour finir ce thread des pouvoirs cachées de Cosmos SDK & CosmWasm :

[Authz and Fee Grant Modules] - Authz vous permet d'autoriser une adresse à effectuer une action spécifique en votre nom : je donne un exemple assez simple, mais avec plus d’imagination, il y a des choses incroyables à réaliser :

On pourrait autoriser une adresse différente à effectuer des transactions spécifique pour vous, sans se soucier que l’adresse puisse effectuer d’autres actions. Imaginons par exemple une automatisations très précises des rewards que vous récupérer sur toutes les LP-Farming Cosmos

Vous pourrez décider “Je veux regrouper tous mes rewards sur telle plateforme, en stablecoin $UST quotidiennement et les placer en lending sur @anchor_protocol, tout cela de manière sécurisé via les Smart Contracts CosmWasm. 👀👀👀

Le module Fee Grant est un complément à Authz. Ce module permet aux utilisateurs d'accorder à d'autres personnes une allocation à utiliser pour payer des gas fee. La beauté ici réside dans le fait que les fonds restent sous le contrôle du créateur de l'allocation.

CosmWasm a déjà fait ses preuves : on l’a vu notamment sur @anchor_protocol, mais le meilleur reste à venir. Thread assez dense, mais qui laisse entrevoir les possibilités qui arrivent sur Cosmos. Les meilleurs projets continuent de construire dans l’ombre, même quand tout va mal

Pour apporter une petite précision, ce genre de macro optimisation peut faire monter une APR à 100% à une APY à plus de 300% 👀