Conception des frais de carburant MOVE : comment les frais de carburant off-chain sont-ils calculés ?
La mesure des frais de carburant est un concept fondamental de nombreuses blockchains, qui définit le calcul abstrait de la quantité de ressources de calcul et de stockage nécessaires à l'exécution et au stockage des transactions sur la chaîne. Le plan de frais de carburant détermine le coût total consommé pour toutes les exécutions sur la chaîne, utilisé pour calculer les dépenses de frais de carburant pendant l'exécution des transactions.
processus
Pour une exécution efficace, le processus off-chain est :
définition des principes;
Préparer un cadre d'évaluation pour déterminer le prix de chaque exécution;
pour établir un système de mesure des frais de carburant et des frais de carburant sécurisé MOVE.
importer le cadre des frais de carburant en amont;
rend le cadre des frais de carburant conscient du stockage;
Affiner davantage le plan des frais de carburant.
principe
Les principes définis sont :
Le coût d'exploitation doit être directement lié aux ressources disponibles sur le réseau, telles que le CPU, la mémoire, le réseau, l'I/O de stockage et l'utilisation de l'espace, (. Lorsque les technologies et les processus sont améliorés, le coût du carburant requis doit également diminuer.
Les frais de carburant doivent être fixés par la gouvernance off-chain et peuvent être configurés sans couture.
Les frais de carburant peuvent prévenir les attaques par déni de service (DoS) sur l'ensemble des ressources fixes du réseau, et peuvent nécessiter un ajustement rapide en fonction de l'état du réseau par des propositions de gouvernance.
Le prix des frais de carburant reflète le désir d'accélérer la croissance et de maintenir la blockchain accessible à tous.
Encourager à faire de bons choix dans la conception - par exemple, privilégier la sécurité, la modularité, les assertions et d'autres événements.
) Calcul des frais de carburant
Lorsque les utilisateurs soumettent une transaction, ils doivent également spécifier deux montants dans la transaction :
Frais de carburant maximum: Mesuré en unités de frais de carburant. C'est le nombre maximum d'unités de frais de carburant que l'utilisateur est prêt à dépenser pour exécuter une transaction.
Coût unitaire du carburant : calculé en octal par unité de carburant, où 1 octal = 0.00000001 APT###=$10^{-8}$(. C'est le prix du coût du carburant que l'utilisateur est prêt à payer.
Pendant le processus d'exécution, des frais seront appliqués aux transactions :
Coût fixe, base fixe plus des frais supplémentaires pour les grosses transactions.
coût d'exécution, utilisé pour exécuter l'instruction MOVE.
Coût de lecture, utilisé pour lire des données à partir d'un stockage persistant.
coût d'écriture, utilisé pour écrire des données dans le stockage permanent.
Les frais de transaction finaux peuvent être calculés en multipliant la quantité totale de frais de carburant consommée ) par le prix unitaire des frais de carburant. Par exemple, si une transaction consomme 670 unités de frais de carburant et que l'utilisateur a spécifié un prix unitaire de frais de carburant de 100 Octa par unité dans la transaction, alors les frais de transaction finaux sont de 670 * 100 = 67000 Octa = 0.00067 APT.
Si une transaction épuisait les frais de carburant pendant son exécution, l'expéditeur sera facturé en fonction du montant maximal des frais de carburant, et toutes les modifications apportées par cette transaction seront annulées.
( Établir un plan de frais de carburant
1. Configuration de base
Le plan des frais de carburant comprend plusieurs éléments qui ne sont pas liés aux détails d'une opération unique, y compris la taille de la transaction et l'unité maximale des frais de carburant ) qui diffère de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction ###.
2. Taille des transactions
Pour la plupart des transactions, la taille des transactions peut être de l'ordre du kilooctet. Cependant, la publication du module MOVE peut facilement atteindre plusieurs kilooctets, tandis que le cadre fait environ 100 Ko. La taille de la plupart des modules utilisateurs se situe généralement entre 4 Ko et 40 Ko. À l'origine, nous avons fixé la valeur de la taille des transactions à 32 Ko, mais en fonction des réactions de la communauté, il a été demandé de fournir plus d'espace pour simplifier le développement d'applications, nous avons donc ajusté la taille des transactions à 64 Ko.
Des transactions à très grande échelle peuvent entraîner une augmentation des coûts de bande passante sur l'ensemble du réseau et peuvent avoir un impact négatif sur les performances. Si elle est exploitée, la mémoire tampon pourrait être incitée à ignorer les transactions plus volumineuses, donc notre approche consiste à trouver un équilibre entre la taille et l'accessibilité des transactions de grande taille.
3. Unité maximale des frais de carburant
L'unité maximale de frais de carburant dans le plan de frais de carburant définit le nombre maximal d'opérations qu'une transaction peut effectuer. Attention ! Ceci est différent de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction.
L'unité de frais de carburant maximale du plan de frais de carburant affecte directement la durée d'exécution d'une transaction. La définir trop haut peut entraîner des impacts de performance négatifs sur la blockchain. Par exemple, un utilisateur peut oublier d'inclure un incrément dans une boucle while, ce qui peut entraîner une boucle infinie, une erreur courante. Nous avons constaté que même après avoir effectué la plus grande mise à niveau de cadre, nous sommes toujours en dessous de l'unité de frais de carburant maximale du plan de frais de carburant ( fixée à 1 000 000) à 90 %.
4. Exécution
Pour évaluer le coût d'exécution, nous avons construit un cadre de référence et utilisé Valgrind pour analyser le MOVE VM lors de l'exécution de ce cadre. Sa sortie est un ensemble de code source commenté, qui nous indique combien d'instructions machines chaque ligne de code produit.
Avec l'aide de l'analyse ci-dessus, nous avons estimé grossièrement le coût relatif de toutes les instructions MOVE et des fonctions natives. Cependant, nous avons remarqué que cette méthode présente certains problèmes avec les fonctions en ligne : elles ne sont pas automatiquement incluses dans le compte de l'appelant. Nous avons également constaté que cela ne se produisait que lorsque nous analysions certaines instructions MOVE, et nous pouvions résoudre ce problème en additionnant les chiffres.
Ensuite, en considérant les exemples de codage qui renforcent la robustesse et la sécurité du système, l'équipe a déterminé le nombre final d'instructions machine exécutées. Ce chiffre a été pesé successivement contre l'unité de stockage et l'unité de coût de carburant maximale pour établir leur valeur actuelle dans le programme de coût de carburant.
5. Stockage
Chaque fois qu'un nœud accède à un élément d'état de grand livre ou à des données stockées dans le stockage persistant, il émet une lecture ou une écriture vers le périphérique de stockage. Le nombre total d'accès aux données par seconde dépend de la bande passante et de la capacité IOPS du périphérique de stockage. Tout comme les cycles CPU dans le calcul des frais de combustible, l'accès aux données représente la rareté instantanée à laquelle les utilisateurs de la blockchain font face sur le marché des frais en période de charge système; de plus, le coût d'occupation du disque pour l'écriture de données est permanent off-chain. L'équipe conçoit le plan de frais de stockage en tenant compte de ces coûts.
L'accès et le stockage de tout élément d'état entraînent des coûts liés à la structure de données de l'arbre de Merkle de validation de l'état entier de la blockchain. Ce coût est lié à la cardinalité des différents éléments d'état ($2^{256}$). Il existe également un coût qui est proportionnel à la taille de chaque élément. Pour manipuler un élément d'état, les frais s'élèvent à (, sauf pour les exceptions décrites dans la section suivante ):
Frais de stockage = item_fee + (byte_fee * bytes)
( lire, créer et écrire
Tout accès à un élément d'état appartient à l'une des trois catégories suivantes : lecture, création ou écriture. L'accès est facturé en fonction des frais de projet et des frais de bytes, comme indiqué dans l'équation ci-dessus.
L'opération de lecture est l'opération la plus courante, elle n'est limitée que par la rareté des ressources instantanées. Par conséquent, les frais de lecture sont calibrés en fonction des frais du projet de disque IOPS) et de la capacité de bande passante des spécifications matérielles de référence.
create ajoute un nouvel élément dans le stockage d'état. Par conséquent, create augmente la structure de données d'authentification, rendant tout plus coûteux, et donc le coût est le plus élevé. Les frais de création sont calibrés en fonction de l'espace disque de référence possédé par le réseau. Ainsi, remplir le disque avec l'élément ###item_fee( et le byte )byte_fee( nécessite des frais de carburant considérables.
Les opérations d'écriture mettent à jour les éléments existants dans le stockage d'état. Par conséquent, les opérations d'écriture ne génèrent pas de surcharge supplémentaire dans la structure de données d'authentification. Cependant, en modifiant les entrées existantes pour des octets plus grands, il est toujours possible de compromettre le disque. Par conséquent, nous facturons les mêmes frais pour les octets dans les éléments mis à jour que lors de leur création.
Il convient de noter que les coûts associés au stockage sont évalués par transaction : même si vous lisez/écrivez plusieurs fois la même ressource, vous ne devez payer qu'une seule fois.
Sur la base des considérations ci-dessus, nous avons défini 6 paramètres de frais de carburant, qui constituent des éléments du coût total des frais de carburant. Voir ci-dessous :
per_item_read: correction basée sur les IOPs
per_byte_read: calibration en fonction de la bande passante réelle
per_item_create:calibrer en fonction du projet total cible
per_byte_create: Calibrer en fonction de la taille totale cible - le premier 1 Ko inclus dans chaque élément
per_item_write: identique à per_item_read
per_byte_write: identique à per_byte_create
) coût unitaire stable des frais de carburant
Quel que soit le coût d'exécution des opérations en valeur marchande, que ce soit en APT ou en monnaie fiduciaire, chaque opération et transaction elle-même nécessite un coût unitaire fixe par rapport aux coûts de stockage et d'exécution. Un coût unitaire fixe des frais de carburant aide à maintenir le plan des frais de carburant constant et à découpler cela de la valeur du marché libre de l'APT. De plus, le choix correct du nombre de chiffres après la virgule pour le coût unitaire des frais de carburant aide à maintenir le plan des frais de carburant constant. En tenant compte de cela, l'équipe représente le coût unitaire des frais de carburant avec une précision d'environ 3 chiffres. Par conséquent, le coût des transactions de transfert est d'environ 700 unités de frais de carburant.
( Participation de la communauté
Même si nous avons investi beaucoup d'efforts dans le plan de frais de carburant, il est encore loin d'être parfait. En tant que projet communautaire, les membres de la communauté peuvent choisir :
Identifiez les points déraisonnables du plan de frais de carburant selon votre expérience.
2### exprimez vos préoccupations concernant le plan de frais de carburant et participez aux discussions communautaires.
3### votera sur les propositions de gouvernance liées aux frais de carburant.
) Comment ajuster le coût des frais de carburant ?
Le plan de frais de carburant est stocké en tant que configuration off-chain, mais peut être modifié par des propositions de gouvernance et il est possible d'ajouter de nouvelles instructions ou fonctionnalités natives de manière transparente.
Le programme de frais de carburant a été conçu pour être évolutif, permettant des mises à jour via des propositions de gouvernance. Avec l'amélioration continue du Move VM et l'intégration des retours des utilisateurs, les paramètres des frais de carburant peuvent être ajustés au fil du temps.
Parfois, la formule des frais de carburant peut nécessiter des modifications complexes qui dépassent la configuration off-chain. Ces formules de frais de carburant sont généralement codées en Rust et sont distinguées par des indicateurs de caractéristiques de frais de carburant off-chain. Pour mettre à jour ces formules, il est nécessaire de mettre à jour le logiciel des nœuds avec la nouvelle formule et de les distinguer par des indicateurs de caractéristiques de frais de carburant différents. Ensuite, le logiciel des nœuds doit être publié et largement adopté par les opérateurs de nœuds, et enfin, une proposition de gouvernance doit être publiée et approuvée pour utiliser la nouvelle version des frais de carburant.
) Travail futur
C'est le premier cadre de frais de carburant viable pour MOVE. Il nécessite de nombreuses modifications de la VM MOVE et du Core. Nous espérons que ce travail ouvrira la voie aux travaux futurs :
1) Réduire les coûts d'exécution, posséder un modèle de frais de carburant réel montre où le compilateur et la machine virtuelle sont efficaces, l'équipe peut améliorer la plupart d'entre eux pour réduire les coûts d'exécution.
2### Calcul des frais de carburant multi-dimensionnels, permettant aux utilisateurs de définir un budget séparé pour l'exécution et le stockage. De cette façon, les utilisateurs n'ont pas à payer des prix élevés pour des frais de carburant en raison d'un temps d'exécution trop long causé par une mauvaise écriture de code des applications. Cela permettra également de définir de manière plus précise le prix maximum des frais de carburant pour les transactions côté chaîne;
3### Atténuation de l'état encombré, il n'existe actuellement aucune méthode simple pour réduire l'ensemble des états, à part le contrat ) ou la suppression explicite de l'objet par l'utilisateur ). Faire payer les utilisateurs pour supprimer des données pourrait créer des opportunités d'arbitrage, les utilisateurs créant du stockage quand c'est bon marché et le supprimant quand c'est cher. Retarder la résolution de ce défi pourrait diminuer la motivation des développeurs à supprimer les données off-chain. L'équipe explore le concept de TTL (Time To Live) pour chaque projet, qui supprimera les objets d'état non visités lorsque le TTL expirera.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
4 J'aime
Récompense
4
4
Reposter
Partager
Commentaire
0/400
ImpermanentLossEnjoyer
· Il y a 15h
Qui peut supporter ce coût élevé du carburant ?
Voir l'originalRépondre0
rekt_but_resilient
· Il y a 15h
Même les chiens savent que le gas pour move est exorbitant.
Voir l'originalRépondre0
0xSleepDeprived
· Il y a 16h
move doit aussi tirer de l'argent, c'est difficile.
Voir l'originalRépondre0
EthSandwichHero
· Il y a 16h
C'est tout pour les frais de carburant ? l'univers de la cryptomonnaie, les nouveaux arrivants sont choqués.
Le mécanisme des frais de carburant de la langue MOVE : comment calculer avec précision le coût d'exécution off-chain.
Conception des frais de carburant MOVE : comment les frais de carburant off-chain sont-ils calculés ?
La mesure des frais de carburant est un concept fondamental de nombreuses blockchains, qui définit le calcul abstrait de la quantité de ressources de calcul et de stockage nécessaires à l'exécution et au stockage des transactions sur la chaîne. Le plan de frais de carburant détermine le coût total consommé pour toutes les exécutions sur la chaîne, utilisé pour calculer les dépenses de frais de carburant pendant l'exécution des transactions.
processus
Pour une exécution efficace, le processus off-chain est :
définition des principes;
Préparer un cadre d'évaluation pour déterminer le prix de chaque exécution;
pour établir un système de mesure des frais de carburant et des frais de carburant sécurisé MOVE.
importer le cadre des frais de carburant en amont;
rend le cadre des frais de carburant conscient du stockage;
Affiner davantage le plan des frais de carburant.
principe
Les principes définis sont :
Le coût d'exploitation doit être directement lié aux ressources disponibles sur le réseau, telles que le CPU, la mémoire, le réseau, l'I/O de stockage et l'utilisation de l'espace, (. Lorsque les technologies et les processus sont améliorés, le coût du carburant requis doit également diminuer.
Les frais de carburant doivent être fixés par la gouvernance off-chain et peuvent être configurés sans couture.
Les frais de carburant peuvent prévenir les attaques par déni de service (DoS) sur l'ensemble des ressources fixes du réseau, et peuvent nécessiter un ajustement rapide en fonction de l'état du réseau par des propositions de gouvernance.
Le prix des frais de carburant reflète le désir d'accélérer la croissance et de maintenir la blockchain accessible à tous.
Encourager à faire de bons choix dans la conception - par exemple, privilégier la sécurité, la modularité, les assertions et d'autres événements.
) Calcul des frais de carburant
Lorsque les utilisateurs soumettent une transaction, ils doivent également spécifier deux montants dans la transaction :
Frais de carburant maximum: Mesuré en unités de frais de carburant. C'est le nombre maximum d'unités de frais de carburant que l'utilisateur est prêt à dépenser pour exécuter une transaction.
Coût unitaire du carburant : calculé en octal par unité de carburant, où 1 octal = 0.00000001 APT###=$10^{-8}$(. C'est le prix du coût du carburant que l'utilisateur est prêt à payer.
Pendant le processus d'exécution, des frais seront appliqués aux transactions :
Coût fixe, base fixe plus des frais supplémentaires pour les grosses transactions.
coût d'exécution, utilisé pour exécuter l'instruction MOVE.
Coût de lecture, utilisé pour lire des données à partir d'un stockage persistant.
coût d'écriture, utilisé pour écrire des données dans le stockage permanent.
Les frais de transaction finaux peuvent être calculés en multipliant la quantité totale de frais de carburant consommée ) par le prix unitaire des frais de carburant. Par exemple, si une transaction consomme 670 unités de frais de carburant et que l'utilisateur a spécifié un prix unitaire de frais de carburant de 100 Octa par unité dans la transaction, alors les frais de transaction finaux sont de 670 * 100 = 67000 Octa = 0.00067 APT.
Si une transaction épuisait les frais de carburant pendant son exécution, l'expéditeur sera facturé en fonction du montant maximal des frais de carburant, et toutes les modifications apportées par cette transaction seront annulées.
( Établir un plan de frais de carburant
1. Configuration de base
Le plan des frais de carburant comprend plusieurs éléments qui ne sont pas liés aux détails d'une opération unique, y compris la taille de la transaction et l'unité maximale des frais de carburant ) qui diffère de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction ###.
2. Taille des transactions
Pour la plupart des transactions, la taille des transactions peut être de l'ordre du kilooctet. Cependant, la publication du module MOVE peut facilement atteindre plusieurs kilooctets, tandis que le cadre fait environ 100 Ko. La taille de la plupart des modules utilisateurs se situe généralement entre 4 Ko et 40 Ko. À l'origine, nous avons fixé la valeur de la taille des transactions à 32 Ko, mais en fonction des réactions de la communauté, il a été demandé de fournir plus d'espace pour simplifier le développement d'applications, nous avons donc ajusté la taille des transactions à 64 Ko.
Des transactions à très grande échelle peuvent entraîner une augmentation des coûts de bande passante sur l'ensemble du réseau et peuvent avoir un impact négatif sur les performances. Si elle est exploitée, la mémoire tampon pourrait être incitée à ignorer les transactions plus volumineuses, donc notre approche consiste à trouver un équilibre entre la taille et l'accessibilité des transactions de grande taille.
3. Unité maximale des frais de carburant
L'unité maximale de frais de carburant dans le plan de frais de carburant définit le nombre maximal d'opérations qu'une transaction peut effectuer. Attention ! Ceci est différent de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction.
L'unité de frais de carburant maximale du plan de frais de carburant affecte directement la durée d'exécution d'une transaction. La définir trop haut peut entraîner des impacts de performance négatifs sur la blockchain. Par exemple, un utilisateur peut oublier d'inclure un incrément dans une boucle while, ce qui peut entraîner une boucle infinie, une erreur courante. Nous avons constaté que même après avoir effectué la plus grande mise à niveau de cadre, nous sommes toujours en dessous de l'unité de frais de carburant maximale du plan de frais de carburant ( fixée à 1 000 000) à 90 %.
4. Exécution
Pour évaluer le coût d'exécution, nous avons construit un cadre de référence et utilisé Valgrind pour analyser le MOVE VM lors de l'exécution de ce cadre. Sa sortie est un ensemble de code source commenté, qui nous indique combien d'instructions machines chaque ligne de code produit.
Avec l'aide de l'analyse ci-dessus, nous avons estimé grossièrement le coût relatif de toutes les instructions MOVE et des fonctions natives. Cependant, nous avons remarqué que cette méthode présente certains problèmes avec les fonctions en ligne : elles ne sont pas automatiquement incluses dans le compte de l'appelant. Nous avons également constaté que cela ne se produisait que lorsque nous analysions certaines instructions MOVE, et nous pouvions résoudre ce problème en additionnant les chiffres.
Ensuite, en considérant les exemples de codage qui renforcent la robustesse et la sécurité du système, l'équipe a déterminé le nombre final d'instructions machine exécutées. Ce chiffre a été pesé successivement contre l'unité de stockage et l'unité de coût de carburant maximale pour établir leur valeur actuelle dans le programme de coût de carburant.
5. Stockage
Chaque fois qu'un nœud accède à un élément d'état de grand livre ou à des données stockées dans le stockage persistant, il émet une lecture ou une écriture vers le périphérique de stockage. Le nombre total d'accès aux données par seconde dépend de la bande passante et de la capacité IOPS du périphérique de stockage. Tout comme les cycles CPU dans le calcul des frais de combustible, l'accès aux données représente la rareté instantanée à laquelle les utilisateurs de la blockchain font face sur le marché des frais en période de charge système; de plus, le coût d'occupation du disque pour l'écriture de données est permanent off-chain. L'équipe conçoit le plan de frais de stockage en tenant compte de ces coûts.
L'accès et le stockage de tout élément d'état entraînent des coûts liés à la structure de données de l'arbre de Merkle de validation de l'état entier de la blockchain. Ce coût est lié à la cardinalité des différents éléments d'état ($2^{256}$). Il existe également un coût qui est proportionnel à la taille de chaque élément. Pour manipuler un élément d'état, les frais s'élèvent à (, sauf pour les exceptions décrites dans la section suivante ):
Frais de stockage = item_fee + (byte_fee * bytes)
( lire, créer et écrire
Tout accès à un élément d'état appartient à l'une des trois catégories suivantes : lecture, création ou écriture. L'accès est facturé en fonction des frais de projet et des frais de bytes, comme indiqué dans l'équation ci-dessus.
L'opération de lecture est l'opération la plus courante, elle n'est limitée que par la rareté des ressources instantanées. Par conséquent, les frais de lecture sont calibrés en fonction des frais du projet de disque IOPS) et de la capacité de bande passante des spécifications matérielles de référence.
create ajoute un nouvel élément dans le stockage d'état. Par conséquent, create augmente la structure de données d'authentification, rendant tout plus coûteux, et donc le coût est le plus élevé. Les frais de création sont calibrés en fonction de l'espace disque de référence possédé par le réseau. Ainsi, remplir le disque avec l'élément ###item_fee( et le byte )byte_fee( nécessite des frais de carburant considérables.
Les opérations d'écriture mettent à jour les éléments existants dans le stockage d'état. Par conséquent, les opérations d'écriture ne génèrent pas de surcharge supplémentaire dans la structure de données d'authentification. Cependant, en modifiant les entrées existantes pour des octets plus grands, il est toujours possible de compromettre le disque. Par conséquent, nous facturons les mêmes frais pour les octets dans les éléments mis à jour que lors de leur création.
Il convient de noter que les coûts associés au stockage sont évalués par transaction : même si vous lisez/écrivez plusieurs fois la même ressource, vous ne devez payer qu'une seule fois.
Sur la base des considérations ci-dessus, nous avons défini 6 paramètres de frais de carburant, qui constituent des éléments du coût total des frais de carburant. Voir ci-dessous :
per_item_read: correction basée sur les IOPs
per_byte_read: calibration en fonction de la bande passante réelle
per_item_create:calibrer en fonction du projet total cible
per_byte_create: Calibrer en fonction de la taille totale cible - le premier 1 Ko inclus dans chaque élément
per_item_write: identique à per_item_read
per_byte_write: identique à per_byte_create
) coût unitaire stable des frais de carburant
Quel que soit le coût d'exécution des opérations en valeur marchande, que ce soit en APT ou en monnaie fiduciaire, chaque opération et transaction elle-même nécessite un coût unitaire fixe par rapport aux coûts de stockage et d'exécution. Un coût unitaire fixe des frais de carburant aide à maintenir le plan des frais de carburant constant et à découpler cela de la valeur du marché libre de l'APT. De plus, le choix correct du nombre de chiffres après la virgule pour le coût unitaire des frais de carburant aide à maintenir le plan des frais de carburant constant. En tenant compte de cela, l'équipe représente le coût unitaire des frais de carburant avec une précision d'environ 3 chiffres. Par conséquent, le coût des transactions de transfert est d'environ 700 unités de frais de carburant.
( Participation de la communauté
Même si nous avons investi beaucoup d'efforts dans le plan de frais de carburant, il est encore loin d'être parfait. En tant que projet communautaire, les membres de la communauté peuvent choisir :
2### exprimez vos préoccupations concernant le plan de frais de carburant et participez aux discussions communautaires.
3### votera sur les propositions de gouvernance liées aux frais de carburant.
) Comment ajuster le coût des frais de carburant ?
Le plan de frais de carburant est stocké en tant que configuration off-chain, mais peut être modifié par des propositions de gouvernance et il est possible d'ajouter de nouvelles instructions ou fonctionnalités natives de manière transparente.
Le programme de frais de carburant a été conçu pour être évolutif, permettant des mises à jour via des propositions de gouvernance. Avec l'amélioration continue du Move VM et l'intégration des retours des utilisateurs, les paramètres des frais de carburant peuvent être ajustés au fil du temps.
Parfois, la formule des frais de carburant peut nécessiter des modifications complexes qui dépassent la configuration off-chain. Ces formules de frais de carburant sont généralement codées en Rust et sont distinguées par des indicateurs de caractéristiques de frais de carburant off-chain. Pour mettre à jour ces formules, il est nécessaire de mettre à jour le logiciel des nœuds avec la nouvelle formule et de les distinguer par des indicateurs de caractéristiques de frais de carburant différents. Ensuite, le logiciel des nœuds doit être publié et largement adopté par les opérateurs de nœuds, et enfin, une proposition de gouvernance doit être publiée et approuvée pour utiliser la nouvelle version des frais de carburant.
) Travail futur
C'est le premier cadre de frais de carburant viable pour MOVE. Il nécessite de nombreuses modifications de la VM MOVE et du Core. Nous espérons que ce travail ouvrira la voie aux travaux futurs :
1) Réduire les coûts d'exécution, posséder un modèle de frais de carburant réel montre où le compilateur et la machine virtuelle sont efficaces, l'équipe peut améliorer la plupart d'entre eux pour réduire les coûts d'exécution.
2### Calcul des frais de carburant multi-dimensionnels, permettant aux utilisateurs de définir un budget séparé pour l'exécution et le stockage. De cette façon, les utilisateurs n'ont pas à payer des prix élevés pour des frais de carburant en raison d'un temps d'exécution trop long causé par une mauvaise écriture de code des applications. Cela permettra également de définir de manière plus précise le prix maximum des frais de carburant pour les transactions côté chaîne;
3### Atténuation de l'état encombré, il n'existe actuellement aucune méthode simple pour réduire l'ensemble des états, à part le contrat ) ou la suppression explicite de l'objet par l'utilisateur ). Faire payer les utilisateurs pour supprimer des données pourrait créer des opportunités d'arbitrage, les utilisateurs créant du stockage quand c'est bon marché et le supprimant quand c'est cher. Retarder la résolution de ce défi pourrait diminuer la motivation des développeurs à supprimer les données off-chain. L'équipe explore le concept de TTL (Time To Live) pour chaque projet, qui supprimera les objets d'état non visités lorsque le TTL expirera.