Conception des frais de carburant de la langue MOVE : comment calculer la consommation off-chain
La mesure des frais de carburant est un concept fondamental de nombreuses blockchains, définissant le calcul abstrait de la quantité de ressources de calcul et de stockage nécessaires pour exécuter et stocker des transactions off-chain. Le plan de frais de carburant détermine le coût total consommé par toutes les exécutions off-chain, utilisé pour calculer les dépenses liées aux frais de carburant pendant l'exécution des transactions.
processus
Pour une exécution efficace, le processus off-chain est :
Définir les principes
Préparer le cadre d'évaluation, déterminer le prix de chaque exécution
Établir un système de mesure des frais de carburant et des frais de carburant sécurisés pour MOVE
Importer le cadre des frais de carburant en amont
Rendre 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 du réseau ( telles que CPU, mémoire, réseau, stockage I/O et utilisation de l'espace, etc. Après l'amélioration des technologies et des processus, le coût des frais de carburant devrait diminuer.
Les frais de carburant doivent être définis par la gouvernance off-chain et peuvent être configurés de manière transparente.
Les frais de carburant peuvent prévenir les attaques DoS sur les ressources fixes du réseau, et il peut être nécessaire de les ajuster rapidement par des propositions de gouvernance en fonction de l'état du réseau.
Le prix des frais de carburant reflète la vision d'une croissance accélérée et du maintien de la popularité de la blockchain.
Encourager à faire de bons choix dans la conception, tels que donner la priorité à la sécurité, à la modularité, aux assertions et à d'autres événements.
) Calcul des frais de carburant
Lorsqu'un utilisateur soumet une transaction, il doit spécifier deux quantités dans la transaction :
Quantité maximale de frais de carburant : Mesurée 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 la transaction.
Prix unitaire du carburant : Calculé en octal pour chaque unité de frais de carburant, 1 octal = 0.00000001 APT###=$10^{-8}$(. C'est le prix que l'utilisateur est prêt à payer pour les frais de carburant.
Au cours de l'exécution, une commission sera appliquée sur la transaction :
Coûts fixes, base fixe plus des frais supplémentaires pour les transactions importantes.
Coût d'exécution, utilisé pour exécuter l'instruction MOVE.
Coût de lecture, utilisé pour lire des données à partir du stockage persistant.
Coût d'écriture, utilisé pour écrire des données dans un stockage permanent.
Les frais de transaction finaux peuvent être calculés en multipliant le total des unités de frais de carburant consommées 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é, alors les frais de transaction finaux sont de 670 * 100 = 67000 Octa = 0.00067 APT.
Si les frais de carburant sont épuisés pendant l'exécution de la transaction, l'expéditeur sera facturé en fonction du montant maximum des frais de carburant, et toutes les modifications effectuées par la transaction seront annulées.
) établir un tableau de plan de frais de carburant
1. Configuration de base
Le plan de frais de carburant comprend plusieurs éléments qui ne sont pas liés aux détails d'une seule opération, y compris la taille de la transaction et l'unité maximale de frais de carburant ###, qui est différente de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction (.
2. Taille des transactions
La plupart des tailles de transaction peuvent être de l'ordre du kilo-octet. Cependant, la publication du module MOVE peut facilement atteindre plusieurs kilo-octets, 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. Initialement, la taille de la transaction était fixée à 32 Ko, mais en réponse aux demandes de la communauté pour plus d'espace afin de simplifier le développement d'applications, la taille de la transaction a été ajustée à 64 Ko.
Des transactions à très grande échelle peuvent entraîner une augmentation des coûts de bande passante du réseau, ce qui pourrait avoir un impact négatif sur les performances. En cas d'abus, la mémoire tampon sera incitée à ignorer les transactions de plus grande taille, c'est pourquoi notre approche consiste à trouver un équilibre entre la taille des transactions maximales et leur accessibilité.
3. Maximum frais de carburant unitaire
L'unité de frais de carburant maximale définie dans le plan de frais de carburant détermine combien d'opérations une transaction peut exécuter au maximum. Attention ! Ceci est différent de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction.
Le montant maximal des frais de carburant dans le plan de frais de carburant influence directement la durée d'exécution d'une transaction. Un réglage trop élevé peut avoir un impact négatif sur la performance de la blockchain. Par exemple, un utilisateur peut oublier d'inclure un incrément dans une boucle while, entraînant ainsi une boucle infinie, ce qui est une erreur courante. Même avec la mise à niveau maximale du cadre, cela reste inférieur à 90 % du montant maximal des frais de carburant du plan de frais de carburant fixé à 1 000 000).
4. Exécution
Pour évaluer le coût d'exécution, un cadre de référence a été construit et Valgrind a été utilisé pour analyser le MOVE VM lors de l'exécution de ce cadre. Sa sortie est un ensemble de code source annoté, indiquant combien d'instructions machine ont été générées par chaque ligne de code.
Avec l'aide de l'analyse ci-dessus, nous avons estimé de manière approximative le coût relatif de toutes les instructions MOVE et des fonctions natives. Cependant, cette méthode présente certains problèmes avec les fonctions en ligne : elles ne sont pas automatiquement incluses dans le comptage de l'appelant. Nous avons également constaté que cela ne se produit que lors de l'analyse de certaines instructions MOVE, et ce problème peut être résolu en additionnant les chiffres.
Ensuite, en tenant compte des exemples de codage visant à renforcer la robustesse et la sécurité du système, l'équipe a abouti au nombre final d'instructions machine exécutées. Ce chiffre est ensuite mis en balance avec l'unité de stockage et le maximum des frais de carburant afin de déterminer leur valeur actuelle dans le plan de frais de carburant.
5. Stockage
Chaque fois qu'un nœud accède à des éléments d'état ou des données stockés dans le stockage persistant, il émet des lectures ou des écritures vers le dispositif 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 dispositif de stockage. Similaire aux cycles CPU pour le calcul des frais de carburant, l'accès aux données est une rareté instantanée pour les utilisateurs de la blockchain, qui se fait par la compétition sur le marché des frais lors de la charge du système. De plus, le coût d'occupation du disque pour écrire des données est permanent sur la chaîne. L'équipe conçoit le plan de frais de carburant 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 associés à la structure de données liée à la 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 y a également un coût qui est proportionnel à la taille de chaque élément. Pour opérer sur un élément d'état, les frais s'élèvent à (, sauf dans les cas exceptionnels décrits dans la section suivante ):
Coût 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 par élément et des frais par octet, 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 de la capacité de bande passante des spécifications matérielles de référence et des frais de projet IOPS).
create ajoute un nouvel élément à la mémoire d'état. Ainsi, create augmente la structure de données d'authentification, rendant tout plus coûteux, 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. Par conséquent, remplir le disque avec l'élément ###item_fee( et les octets )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 n'engendrent pas de coûts supplémentaires dans la structure de données d'authentification. Cependant, en modifiant les éléments existants pour qu'ils occupent plus d'octets, il est 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 liés au stockage sont évalués par transaction : même si la même ressource est lue/écrite plusieurs fois, seule une seule frais est à payer.
Sur la base des considérations ci-dessus, nous avons défini 6 paramètres de frais de carburant, qui constituent une partie du coût total des frais de carburant. Voir ci-dessous :
per_item_read: correction basée sur les IOPs
per_byte_read: calibré 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 calculé en fonction de la valeur marchande de l'APT ou des devises fiat, 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. Le coût unitaire fixe des frais de carburant aide à maintenir le plan des frais de carburant constant et à découpler de la valeur du marché libre de l'APT. De plus, le choix précis du nombre de décimales pour le coût unitaire des frais de carburant contribue à 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 communautaire
Même si beaucoup d'efforts ont été consacrés au plan de frais de carburant, il n'est pas encore suffisamment perfectionné. En tant que projet communautaire, les membres de la communauté peuvent choisir :
Selon l'expérience, identifier les aspects irrationnels du plan de frais de carburant.
Exprimez vos préoccupations concernant le plan de frais de carburant et participez aux discussions de la communauté.
Voter sur les propositions de gouvernance liées aux frais de carburant
) Comment ajuster le coût des frais de carburant ?
Le plan des frais de carburant est stocké comme une configuration off-chain, mais peut être modifié par des propositions de gouvernance et de nouvelles instructions ou fonctions natives peuvent être ajoutées sans problème.
Le plan 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 de MOVE VM et l'intégration des retours des utilisateurs, les paramètres de 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 vont au-delà des configurations off-chain. Ces formules de frais de carburant sont généralement codées en Rust et sont distinguées par des drapeaux 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 drapeaux 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 pouvoir utiliser la nouvelle version des frais de carburant.
Travail de demain
C'est le premier cadre de frais de carburant viable pour MOVE. Cela nécessite de nombreuses modifications au MOVE VM et à Core. Nous espérons que ce travail ouvrira la voie à des travaux futurs :
1### réduire les coûts d'exécution, avoir 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 multidimensionnels, permettant aux utilisateurs de spécifier un budget séparé pour l'exécution et le stockage. Ainsi, les utilisateurs n'ont pas à payer des prix élevés en frais de carburant en raison d'un temps d'exécution prolongé causé par une mauvaise rédaction de code d'application. Cela permettra également une définition plus granulaire des prix des frais de carburant maximaux pour les transactions sur la chaîne.
3### atténuer l'état encombrant, il n'existe actuellement aucun moyen simple de réduire l'ensemble d'états, à part que le contrat ) ou l'utilisateur ) supprime explicitement des éléments. Le fait que les utilisateurs paient pour supprimer des données pourrait créer des opportunités d'arbitrage, les utilisateurs créant du stockage lorsque c'est bon marché, et le supprimant lorsque c'est cher. Reporter la résolution de ce défi pourrait réduire la motivation des développeurs à supprimer des données off-chain. L'équipe explore le concept de TTL pour chaque projet, un concept qui supprimera les éléments 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.
24 J'aime
Récompense
24
9
Partager
Commentaire
0/400
SatoshiLegend
· 07-18 12:03
La sécurité off-chain est fondamentale. Le calcul des frais de carburant est essentiellement une ré-abstractisation de la distribution des ressources.
Voir l'originalRépondre0
LayoffMiner
· 07-18 04:42
move pas familier, juste regarder l'image un plaisir
Voir l'originalRépondre0
ZkSnarker
· 07-18 00:42
techniquement juste de l'algèbre avec des étapes supplémentaires... pas mentir, il faut vraiment s'améliorer sur les abstractions de coût.
Voir l'originalRépondre0
wrekt_but_learning
· 07-16 22:19
Frais de carburant compliqués, je suis épuisé.
Voir l'originalRépondre0
LightningSentry
· 07-15 20:58
move encore se faire prendre pour des cons
Voir l'originalRépondre0
ZenZKPlayer
· 07-15 20:56
Cette frais de gas est un trou noir.
Voir l'originalRépondre0
InfraVibes
· 07-15 20:55
C'est un peu trop flashy, non ? Explique d'abord comment tu as calculé ça.
Conception des frais de carburant innovante du langage MOVE : comment déterminer le coût de calcul off-chain
Conception des frais de carburant de la langue MOVE : comment calculer la consommation off-chain
La mesure des frais de carburant est un concept fondamental de nombreuses blockchains, définissant le calcul abstrait de la quantité de ressources de calcul et de stockage nécessaires pour exécuter et stocker des transactions off-chain. Le plan de frais de carburant détermine le coût total consommé par toutes les exécutions off-chain, utilisé pour calculer les dépenses liées aux frais de carburant pendant l'exécution des transactions.
processus
Pour une exécution efficace, le processus off-chain est :
principe
Les principes définis sont :
Le coût d'exploitation doit être directement lié aux ressources disponibles du réseau ( telles que CPU, mémoire, réseau, stockage I/O et utilisation de l'espace, etc. Après l'amélioration des technologies et des processus, le coût des frais de carburant devrait diminuer.
Les frais de carburant doivent être définis par la gouvernance off-chain et peuvent être configurés de manière transparente.
Les frais de carburant peuvent prévenir les attaques DoS sur les ressources fixes du réseau, et il peut être nécessaire de les ajuster rapidement par des propositions de gouvernance en fonction de l'état du réseau.
Le prix des frais de carburant reflète la vision d'une croissance accélérée et du maintien de la popularité de la blockchain.
Encourager à faire de bons choix dans la conception, tels que donner la priorité à la sécurité, à la modularité, aux assertions et à d'autres événements.
) Calcul des frais de carburant
Lorsqu'un utilisateur soumet une transaction, il doit spécifier deux quantités dans la transaction :
Quantité maximale de frais de carburant : Mesurée 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 la transaction.
Prix unitaire du carburant : Calculé en octal pour chaque unité de frais de carburant, 1 octal = 0.00000001 APT###=$10^{-8}$(. C'est le prix que l'utilisateur est prêt à payer pour les frais de carburant.
Au cours de l'exécution, une commission sera appliquée sur la transaction :
Les frais de transaction finaux peuvent être calculés en multipliant le total des unités de frais de carburant consommées 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é, alors les frais de transaction finaux sont de 670 * 100 = 67000 Octa = 0.00067 APT.
Si les frais de carburant sont épuisés pendant l'exécution de la transaction, l'expéditeur sera facturé en fonction du montant maximum des frais de carburant, et toutes les modifications effectuées par la transaction seront annulées.
) établir un tableau de plan de frais de carburant
1. Configuration de base
Le plan de frais de carburant comprend plusieurs éléments qui ne sont pas liés aux détails d'une seule opération, y compris la taille de la transaction et l'unité maximale de frais de carburant ###, qui est différente de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction (.
2. Taille des transactions
La plupart des tailles de transaction peuvent être de l'ordre du kilo-octet. Cependant, la publication du module MOVE peut facilement atteindre plusieurs kilo-octets, 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. Initialement, la taille de la transaction était fixée à 32 Ko, mais en réponse aux demandes de la communauté pour plus d'espace afin de simplifier le développement d'applications, la taille de la transaction a été ajustée à 64 Ko.
Des transactions à très grande échelle peuvent entraîner une augmentation des coûts de bande passante du réseau, ce qui pourrait avoir un impact négatif sur les performances. En cas d'abus, la mémoire tampon sera incitée à ignorer les transactions de plus grande taille, c'est pourquoi notre approche consiste à trouver un équilibre entre la taille des transactions maximales et leur accessibilité.
3. Maximum frais de carburant unitaire
L'unité de frais de carburant maximale définie dans le plan de frais de carburant détermine combien d'opérations une transaction peut exécuter au maximum. Attention ! Ceci est différent de la quantité maximale de frais de carburant spécifiée par l'utilisateur dans la transaction.
Le montant maximal des frais de carburant dans le plan de frais de carburant influence directement la durée d'exécution d'une transaction. Un réglage trop élevé peut avoir un impact négatif sur la performance de la blockchain. Par exemple, un utilisateur peut oublier d'inclure un incrément dans une boucle while, entraînant ainsi une boucle infinie, ce qui est une erreur courante. Même avec la mise à niveau maximale du cadre, cela reste inférieur à 90 % du montant maximal des frais de carburant du plan de frais de carburant fixé à 1 000 000).
4. Exécution
Pour évaluer le coût d'exécution, un cadre de référence a été construit et Valgrind a été utilisé pour analyser le MOVE VM lors de l'exécution de ce cadre. Sa sortie est un ensemble de code source annoté, indiquant combien d'instructions machine ont été générées par chaque ligne de code.
Avec l'aide de l'analyse ci-dessus, nous avons estimé de manière approximative le coût relatif de toutes les instructions MOVE et des fonctions natives. Cependant, cette méthode présente certains problèmes avec les fonctions en ligne : elles ne sont pas automatiquement incluses dans le comptage de l'appelant. Nous avons également constaté que cela ne se produit que lors de l'analyse de certaines instructions MOVE, et ce problème peut être résolu en additionnant les chiffres.
Ensuite, en tenant compte des exemples de codage visant à renforcer la robustesse et la sécurité du système, l'équipe a abouti au nombre final d'instructions machine exécutées. Ce chiffre est ensuite mis en balance avec l'unité de stockage et le maximum des frais de carburant afin de déterminer leur valeur actuelle dans le plan de frais de carburant.
5. Stockage
Chaque fois qu'un nœud accède à des éléments d'état ou des données stockés dans le stockage persistant, il émet des lectures ou des écritures vers le dispositif 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 dispositif de stockage. Similaire aux cycles CPU pour le calcul des frais de carburant, l'accès aux données est une rareté instantanée pour les utilisateurs de la blockchain, qui se fait par la compétition sur le marché des frais lors de la charge du système. De plus, le coût d'occupation du disque pour écrire des données est permanent sur la chaîne. L'équipe conçoit le plan de frais de carburant 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 associés à la structure de données liée à la 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 y a également un coût qui est proportionnel à la taille de chaque élément. Pour opérer sur un élément d'état, les frais s'élèvent à (, sauf dans les cas exceptionnels décrits dans la section suivante ):
Coût 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 par élément et des frais par octet, 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 de la capacité de bande passante des spécifications matérielles de référence et des frais de projet IOPS).
create ajoute un nouvel élément à la mémoire d'état. Ainsi, create augmente la structure de données d'authentification, rendant tout plus coûteux, 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. Par conséquent, remplir le disque avec l'élément ###item_fee( et les octets )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 n'engendrent pas de coûts supplémentaires dans la structure de données d'authentification. Cependant, en modifiant les éléments existants pour qu'ils occupent plus d'octets, il est 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 liés au stockage sont évalués par transaction : même si la même ressource est lue/écrite plusieurs fois, seule une seule frais est à payer.
Sur la base des considérations ci-dessus, nous avons défini 6 paramètres de frais de carburant, qui constituent une partie du coût total des frais de carburant. Voir ci-dessous :
per_item_read: correction basée sur les IOPs per_byte_read: calibré 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 calculé en fonction de la valeur marchande de l'APT ou des devises fiat, 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. Le coût unitaire fixe des frais de carburant aide à maintenir le plan des frais de carburant constant et à découpler de la valeur du marché libre de l'APT. De plus, le choix précis du nombre de décimales pour le coût unitaire des frais de carburant contribue à 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 communautaire
Même si beaucoup d'efforts ont été consacrés au plan de frais de carburant, il n'est pas encore suffisamment perfectionné. En tant que projet communautaire, les membres de la communauté peuvent choisir :
) Comment ajuster le coût des frais de carburant ?
Le plan des frais de carburant est stocké comme une configuration off-chain, mais peut être modifié par des propositions de gouvernance et de nouvelles instructions ou fonctions natives peuvent être ajoutées sans problème.
Le plan 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 de MOVE VM et l'intégration des retours des utilisateurs, les paramètres de 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 vont au-delà des configurations off-chain. Ces formules de frais de carburant sont généralement codées en Rust et sont distinguées par des drapeaux 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 drapeaux 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 pouvoir utiliser la nouvelle version des frais de carburant.
Travail de demain
C'est le premier cadre de frais de carburant viable pour MOVE. Cela nécessite de nombreuses modifications au MOVE VM et à Core. Nous espérons que ce travail ouvrira la voie à des travaux futurs :
1### réduire les coûts d'exécution, avoir 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 multidimensionnels, permettant aux utilisateurs de spécifier un budget séparé pour l'exécution et le stockage. Ainsi, les utilisateurs n'ont pas à payer des prix élevés en frais de carburant en raison d'un temps d'exécution prolongé causé par une mauvaise rédaction de code d'application. Cela permettra également une définition plus granulaire des prix des frais de carburant maximaux pour les transactions sur la chaîne.
3### atténuer l'état encombrant, il n'existe actuellement aucun moyen simple de réduire l'ensemble d'états, à part que le contrat ) ou l'utilisateur ) supprime explicitement des éléments. Le fait que les utilisateurs paient pour supprimer des données pourrait créer des opportunités d'arbitrage, les utilisateurs créant du stockage lorsque c'est bon marché, et le supprimant lorsque c'est cher. Reporter la résolution de ce défi pourrait réduire la motivation des développeurs à supprimer des données off-chain. L'équipe explore le concept de TTL pour chaque projet, un concept qui supprimera les éléments d'état non visités lorsque le TTL expirera.