Sortie de Wasmd 0.30

Sortie de fin d'année !

L'année 2022 a été mouvementée à bien des égards, à la fois bonnes et mauvaises, alors pourquoi ne pas la terminer avec une excellente version de Wasmd ?

Nous avons eu un grand nombre de demandes de fonctionnalités communautaires à examiner et à hiérarchiser, et nous sommes heureux d'annoncer qu'avec Wasmd v0.30, nous avons réussi à en obtenir beaucoup dans cette version de fin d'année.

Comme d'habitude, un grand merci à tous les contributeurs qui ont rendu cette version possible !

Présentation (TLDR)

Wasmd v0.30 contenait un certain nombre de modifications fortement demandées par la communauté, outre les corrections de bogues et améliorations habituelles, nous avons également fourni les éléments suivants :

• Intégration du module Authz
• Mise à niveau IBC vers v4.2.0 avec interchain-accounts v0.2.4
• Ajouter le guide du développeur et les meilleures pratiques
• Bump Go minimum à 1,19
• Stocker et instancier la proposition gouvernementale
• Autoriser les votes gouvernementaux à télécharger un bytecode wasm plus grand
• Introduire AcceptListStargateQuerier
• Obtenir des contrats par adresse de créateur
• Prise en charge de l'autorisation d'instanciation> autorisation de chaîne pour le magasin gov

Intégration du module Authz

Le module authz est un module Cosmos-SDK permettant d'accorder des autorisations à un compte différent (bénéficiaire) et d'exécuter des actions en chaîne au nom du compte d'origine (concédant).

Ceci est particulièrement utile pour protéger la clé de compte privée car elle n'est nécessaire que pour l'opération de subvention, mais la clé du bénéficiaire peut alors être utilisée. Cela peut également être utile pour faire correspondre les structures organisationnelles ou de processus où l'accès à la clé privée du concédant est limité.

Une autorisation accordée a beaucoup de pouvoir car elle est exécutée avec le compte du concédant. Par conséquent, certaines extensions authz existent dans d'autres modules qui limitent la portée des actions. Par exemple, en banque. L'autorisation, le montant total de jetons, est définie et peut être transférée.

Le module authz est livré avec une autorisation générique qui accepte un type de message. Cela fonctionne avec n'importe quel module Cosmos, y compris wasmd. Le problème est que les contrats wasm prennent normalement en charge un certain nombre d'opérations et qu'un contrôle d'accès précis ne serait pas possible.

L'extension d'autorisation wasmd a été conçue pour prendre en charge un niveau de contrôle d'accès plus fin. Des filtres peuvent être définis pour correspondre au message du contrat lors de l'exécution et de la migration. Wasmd est livré dans la première itération avec les filtres suivants :

AllowAllMessagesFilter - caractère générique pour correspondre à n'importe quel message de contrat

AcceptedMessageKeysFilter — les messages de contrat sont interprétés comme un objet json avec exactement une clé. Cette clé peut être définie dans une liste d'acceptation pour être acceptée. Par exemple, avec `retirer, délégué` défini, les messages `{"retirer": {}}` et `{"déléguer":{}}` sont autorisés mais `{"envoyé":{}}` n'est pas aussi la clé n'est pas dans la liste.

AcceptedMessagesFilter — ce filtre ne fait aucune hypothèse sur le message de contrat. Elles sont interprétées comme des données binaires pures et comparées. De petits changements dans le formatage comptent déjà. Par exemple, avec {"withdraw":{}}set contract message must be {"withdraw":{}}while {"withdraw":{} }serait rejeté (notez les espaces).

L'avantage de ce filtre, cependant, est qu'il contient également les données après la clé d'objet. Par exemple, {"vote":"yes"}ne peut pas être changé en{"vote":"no"}

Un autre élément de l'extension d'autorisation wasmd est les limites. Comme l'opération est exécutée dans le cadre du compte du concédant, il a un accès complet à leurs soldes bancaires. Le mandant a un certain intérêt à limiter cela et à garder le contrôle. Par exemple, une opération {"retirer":{}} peut ne pas avoir besoin d'accéder au solde alors que le {"déléguer":{}} le fait. Afin de prendre en charge les différents cas d'utilisation, nous avons les limites suivantes qui peuvent être définies avec les filtres :

MaxCallsLimit - définit combien de fois une subvention de contrat peut être utilisée, aucun transfert de jeton depuis le compte de concédant n'est autorisé.

MaxFundsLimit - définit un budget symbolique à dépenser, aucune limite sur le nombre d'appels.

CombinedLimit - définit un budget symbolique et le nombre d'exécutions pouvant être effectuées

Les limites sont mises à jour après chaque exécution de subvention. Lorsque la limite expire, l'autorisation prend fin et est supprimée.

Lecture complémentaire :

https://github.com/cosmos/cosmos-sdk/tree/main/x/authz

Mise à niveau IBC vers v4.2.0 avec interchain-accounts v0.2.4

Cette mise à niveau inclut la prise de contact du protocole IBC et le module middleware de frais, interchain-accounts v0.2.4, ainsi que la mise à jour du package ibctesting.

Lecture complémentaire :

https://github.com/CosmWasm/wasmd/issues/960

https://github.com/cosmos/ibc-go/blob/v4.2.0/CHANGELOG.md

https:///the-interchain-foundation/moving-relayer-incentives-on-chain-fee-middleware-fee-grant-and-budget-modules-b6a13eced375

Ajoutez le guide du développeur et les meilleures pratiques.

Les directives de codage ont été mises à jour pour permettre aux nouveaux arrivants ainsi qu'aux développeurs plus expérimentés de se trouver et de s'orienter plus facilement. Les meilleures pratiques ont également été ajoutées, et le nouveau guide mis à jour peut être trouvé ici :

Bump Go minimum à 1,19

Pour suivre le cosmos-SDK, la version Go minimale a été portée à 1.19, ce qui évite également les problèmes de consensus sur une chaîne mixte Go 1.18/19.

Lecture complémentaire :

https://github.com/CosmWasm/wasmd/issues/1041

Stocker et instancier la proposition gouvernementale

Dans les versions antérieures, télécharger wasm (magasin) et instancier le contrat nécessitaient 2 propositions gouvernementales distinctes.

Il existe maintenant un nouveau type de proposition gouvernementale qui permet d'exécuter les deux étapes comme une seule.

Nous avons donc maintenant moins de frais généraux organisationnels et de dépendance à la création de propositions. (Comme le magasin devait être planifié et exécuté avant l'instanciation)

Lecture complémentaire :

https://github.com/CosmWasm/wasmd/issues/785

Autoriser les votes gouvernementaux à télécharger un bytecode wasm plus grand.

Nous avions l'habitude de limiter la taille de wasm à 800 Ko, ce qui était raisonnable pour la plupart des contrats, car il pouvait être indésirable d'augmenter la limite globale de la chaîne ; il a été proposé que les contrats gouvernementaux puissent remplir cette fonction et autoriser des tailles de wasm allant jusqu'à 4 Mo en même temps que le Tx normal reste à 800 Ko.

Lecture complémentaire :

Présenter la liste d'acceptation Stargate Querier

Les requêtes Stargate sont un puissant point d'extension générique pour interroger l'état du système via le format protobuf générique "Stargate". Avec cette chaîne, des données agnostiques peuvent être interrogées par un contrat, comme un pool de liquidités.

Cette fonctionnalité a causé beaucoup de problèmes dans le passé lorsque le retour de l'État n'était pas déterministe et, par conséquent, rompait le consensus. Nous avons ajouté cette liste d'acceptation pour permettre à chaque chaîne de configurer facilement sa propre liste blanche sans maintenir de nombreux forks et introduire potentiellement des bogues. Osmosis a bifurqué pour permettre cela pour leurs modules personnalisés, et d'autres chaînes voulaient des fonctionnalités similaires.

La liste d'acceptation, cependant, est un moyen pour les architectes de chaîne de rajouter la prise en charge des requêtes Stargate individuelles qu'ils souhaitent maintenir et prendre en charge (à leurs risques et périls). Maintenant, la liste d'acceptation par défaut est vide et vous devez définir une variable dans le code Go de la chaîne pour ajouter tous les types de requête que vous souhaitez activer.

Lecture complémentaire :

https://github.com/CosmWasm/wasmd/issues/904

Obtenir des contrats par adresse de créateur

Dans les versions précédentes, nous avions une requête pour obtenir toutes les instances de contrat pour un code-id. Un cas d'utilisation courant consiste à me donner toutes les instances de contrat qui ont été créées par l'adresse x.

À partir de cette version, cela est désormais pris en charge et permet une meilleure UX

Lecture complémentaire :

https://github.com/CosmWasm/wasmd/issues/998

Prise en charge de l'autorisation d'instanciation> autorisation de chaîne pour le magasin gov

Il s'agit également de créer une instance sur des chaînes autorisées.

Dans les versions antérieures, un code wasm de magasin et une mise à jour de la configuration des paramètres d'instanciation du code étaient nécessaires ; maintenant, avec cette version, la proposition de gouvernement du magasin peut déjà définir la bonne autorisation d'instanciation.

Cela améliore le flux de travail gouvernemental et enregistre une proposition

Lecture complémentaire :

https://github.com/CosmWasm/wasmd/issues/1020

Être impliqué

Aimez ce que vous voyez? Faites-le savoir au monde entier sur Twitter ou rejoignez la discussion sur Discord. Et n'oubliez pas de nous suivre sur le support pour être informé des prochaines cohortes de la CosmWasm Academy, ou visitezhttp://academy.cosmwasm.com, où vous pouvez améliorer vos compétences.

Et n'hésitez pas à consulter notre dernier appel communautaire de l'année, où de nombreuses annonces intéressantes seront faites le mardi 20 décembre à 18 h CET pour plus d'informations et un espace pour poser des questions.

Ordre du jour : https://github.com/CosmWasm/cosmwasm/issues/1548