Comment mettre en œuvre des transactions sans gaz ? — KryptoMind | de Kryptomind Pvt Ltd. | Coinmons | juin 2022

Dans le monde Ethereum, le gaz est crucial. Pour prendre un exemple, c’est le carburant qui lui permet de fonctionner, tout comme une voiture a besoin de carburant pour fonctionner. Par définition, le terme « gaz » fait référence à l’unité utilisée pour quantifier la quantité de calculs nécessaires pour effectuer une opération particulière.

Chaque transaction Ethereum a un coût car elles ont toutes besoin de ressources informatiques pour se terminer. La monnaie native d’Ethereum, ETH, est utilisée pour payer les frais d’essence. De plus, le prix du gaz est généralement exprimé en unités Gwei, qui sont elles-mêmes une dénomination d’ETH. Un Gwei équivaut à 0,000000001 ETH (ou 109 ETH).

Par exemple, vous diriez souvent que votre gaz coûte 1 Gwei plutôt qu’il coûte 0,000000001 ETH. Gwei, qui signifie Giga-Wei et équivaut à 1 000 000 000 Wei (1 Wei = 1018 ETH), est une unité de mesure. L’unité la plus basse d’ETH s’appelle Wei et porte le nom de Wei Dai, le créateur de b-money.

• Les mineurs d’Ethereum reçoivent des frais de gaz pour leurs efforts de protection du réseau et de confirmation des transactions.
• Les frais de gaz empêchent également les utilisateurs frauduleux d’inonder le réseau de transactions et de l’engorger.

L’algorithme utilisé pour déterminer les coûts du gaz Ethereum est dynamique. Ils fluctuent donc. Le réseau Ethereum est fréquemment critiqué pour ses frais élevés et ses mauvaises performances. Par exemple, le coût de transaction moyen sur le réseau Ethereum est souvent supérieur à la blockchain Bitcoin. Les utilisateurs du réseau Ethereum qui souhaitent terminer une transaction plus rapidement peuvent simplement payer plus. Les utilisateurs peuvent choisir des périodes où le trafic réseau a été relativement faible pour réduire les coûts de gaz. Ils peuvent également réduire leur pourboire s’ils ne craignent pas une vitesse de transaction plus lente.

Cela soulève la question de savoir si ces coûts de gaz peuvent ou non être éliminés.

Oui, nous pouvons le faire, grâce à la méta-transaction.

Qu’est-ce que c’est?

Une méta-transaction est une transaction Ethereum standard qui inclut la transaction réelle. Il n’y a pas besoin d’implication de gaz ou de blockchain car la transaction réelle est signée par un utilisateur et transmise à un opérateur ou quelque chose de similaire. L’opérateur soumet cette transaction signée à la blockchain tout en prenant en charge les coûts associés. Le contrat intelligent de transfert vérifie la signature valide de la transaction réelle avant de l’exécuter.

Limitations sur Ethereum

Une couche de gouvernance cruciale existe dans le contexte des transferts de jetons ERC-20 : l’interaction entre approbation et transfertDe, qui permet aux jetons d’être transférés entre des comptes détenus en externe (EOA) et utilisés dans d’autres contrats dans des conditions spécifiques à l’application en supprimant msg. l’expéditeur en tant que mécanisme de définition du contrôle d’accès aux jetons, est sans doute l’une des principales raisons du succès des jetons ERC-20.

Néanmoins, cette solution est limitée par le fait que la fonction d’approbation ERC-20 est spécifiée en termes de msg.sender. Un EOA doit mener l’activité initiale de l’utilisateur en utilisant des jetons ERC-20. Si l’utilisateur veut s’engager

avec un smart contract, deux transactions sont nécessaires (approveand l’appel du smart contract, qui appellera en interne transferFrom). Les utilisateurs doivent posséder des ETH pour couvrir les dépenses de gaz de transaction, même dans le cas d’utilisation le plus élémentaire consistant à payer une autre personne.

Comment pouvons-nous résoudre ce problème ?

Pour résoudre ce problème, nous pouvons ajouter un nouveau permis de fonction au contrat de jeton ERC-20 qui permet aux utilisateurs de modifier le mappage d’allocation à l’aide d’un message signé (via des signatures secp256k1) plutôt que d’utiliser msg.sender. En d’autres termes, en soumettant un message que le compte a signé, la méthode du permis peut être utilisée pour modifier l’allocation ERC-20 d’un compte (voir IERC20.allocation). Le compte du détenteur de jetons n’a pas besoin d’effectuer de transaction et n’est donc pas nécessaire de conserver d’ETH car il ne repose pas sur IERC20.approve.

Les données signées sont organisées conformément à EIP-712, qui est déjà largement utilisé par les principaux fournisseurs de RPC et de portefeuilles pour une expérience utilisateur améliorée.

Exemple: Notre exemple de contrat intelligent désigné par Forwarder.sol implémente le séparateur de domaine EIP-712 (_domainSeparatorV4) qui est utilisé dans le cadre du schéma d’encodage, et l’étape finale de l’encodage pour obtenir le résumé du message qui est ensuite signé via ECDSA (_hashTypedDataV4) .

Un contrat intelligent pour un transfert de méta-transaction extensible sur Ethereum

Le contrat intelligent Forwarder.sol étend l’EIP-2770 et comprend les fonctions principales suivantes :

vérifier : vérifie la signature en fonction des données structurées saisies.

/*** @dev Verifies the signature based on typed structured data.* See https://eips.ethereum.org/EIPS/eip-712*/function verify(ForwardRequest calldata req, bytes calldata signature) public view returns (bool) {address signer = _hashTypedDataV4(keccak256(abi.encode(_TYPEHASH,req.from,req.to,req.value,req.gas,req.nonce,keccak256(req.data)))).recover(signature);return _nonces[req.from] == req.nonce && signer == req.from;}execute: Executes the meta-transaction via a low-level call./*** @dev Main function; executes the meta-transaction via a low-level call.*/function execute(ForwardRequest calldata req, bytes calldata signature) public payable whenNotPaused() returns (bool, bytes memory) {require(_senderWhitelist[msg.sender], "AwlForwarder: sender of meta-transaction is not whitelisted");require(verify(req, signature), "AwlForwarder: signature does not match request");_nonces[req.from] = req.nonce + 1;// solhint-disable-next-line avoid-low-level-calls(bool success, bytes memory returndata) = req.to.call{gas: req.gas, value: req.value}(abi.encodePacked(req.data, req.from));if (!success) {// solhint-disable-next-line no-inline-assemblyassembly {returndatacopy(0, 0, returndatasize())revert(0, returndatasize())}}/*** @dev Validates that the relayer/forwarder EOA has sent enough gas for the call.* See https://ronan.eth.link/blog/ethereum-gas-dangers/.*/assert(gasleft() > req.gas / 63);emit MetaTransactionExecuted(req.from, req.to, req.data);return (success, returndata);}

Nous suivons une cartographie nonce sur la chaîne pour fournir une prévention de relecture. En outre, le transitaire empêche quiconque de publier des transactions à des fins potentiellement néfastes. La fonction d’exécution du contrat intelligent sol est protégée par une liste blanche. De plus, le contrat intelligent est Ownable, qui offre un mécanisme de contrôle d’accès rudimentaire dans lequel un EOA (un propriétaire) est autorisé à accéder de manière exclusive à certaines fonctionnalités (par exemple, addSenderToWhitelist, removeSenderFromWhitelist, killForwarder, pause, unpause). De plus, l’exécution de la fonction de contrat intelligent est Pause, ce qui signifie qu’elle intègre un mécanisme d’arrêt d’urgence que le propriétaire peut activer. Enfin, une opération d’autodestruction est construite en tant que sauvegarde d’urgence à l’aide de la fonction killForwarder.

Remarque 1 : Il est de la plus haute importance que les EOA de la liste blanche vérifient soigneusement les données d’appel codées (signées par l’utilisateur) avant d’envoyer la transaction.

Nouveau dans le commerce ? Essayez des bots de trading de crypto ou copiez le trading

Remarque 2 : calldata est l’endroit où les données des appels externes aux fonctions sont stockées. Les fonctions peuvent être appelées en interne, par exemple depuis le contrat, ou en externe lorsque la visibilité d’une fonction est externe. Lorsqu’un tel appel externe se produit, les données de cet appel sont stockées dans calldata.

Note 3 : Pour les fonctions addSenderToWhitelist et killForwarder nous n’implémentons pas de politique stricte dédiée pour ne jamais autoriser l’adresse zéro 0x00000000000000000000000000000000000000. La raison en est que premièrement, les fonctions sont protégées en étant Ownable, et deuxièmement, on peut affirmer que des adresses comme 0x000000000000000000000000000000000001 sont tout aussi dangereuses, mais nous ne faisons rien à ce sujet.