Titres Titres
En d’autres termes, tout ce que nous devons vraiment savoir sur un transfert de jeton ERC20 est de savoir s’il a réussi ou non. Toutes les autres informations sont déjà incluses dans la transaction.
Objections évidentes
C’est trop dur, de changer maintenant. Tous les dApps se briseraient.
C’est vrai. Beaucoup de choses se briseraient. Mais je suggère que nous pensons aux 50 prochaines années, pas aux cinq dernières.
C’est trop dur, tout le code client devrait être modifié.
C’est également vrai. Voir ma réponse précédente et voir ci-dessous où je fais un calcul rapide au dos de l’enveloppe sur l’espace que cela pourrait économiser.
Cela ralentit les requêtes.
C’est également vrai. Cela ralentirait les requêtes car le logiciel du nœud est hautement optimisé pour fournir des requêtes liées aux journaux.
Actuellement, une dApp envoie la transaction puis interroge le journal et, par conséquent, c’est pourquoi les informations redondantes sont probablement incluses. Vraisemblablement, cependant, le dApp était la source de la transaction, il dispose donc déjà des informations nécessaires pour reconstruire le journal complet.
Dans le cas d’un scrape hors chaîne après coup, les informations transactionnelles sont probablement déjà disponibles, car de nombreux scraps hors chaîne analyseront les blocs et analyseront les transactions avant d’analyser des journaux particuliers.
Avantages
La taille des données stockées par un nœud est réduite.
Même si cela ne passe pas au niveau du protocole en devenant une primitive native de cas particulier, l’observation nous amène à conclure que l’on pourrait réduire considérablement la taille des données sur le disque dur de la machine. Nous avons calculé une estimation ci-dessous en utilisant des calculs très approximatifs au dos de l’enveloppe.
Le nombre total d’octets transférés sur le fil est réduit de moitié.
La quantité d’espace « sur le fil » » est infinie – n’est-ce pas ? Que signifie même un trafic élevé ?
Cela signifie qu’il y a trop d’octets essayant de se frayer un chemin sur le fil. Ainsi, chaque petit geste compte, et cela pourrait réduire considérablement le nombre d’octets passant sur le fil.
Des données plus petites signifient que plus de « personnes ordinaires » peuvent exécuter des nœuds.
L’objectif de tout ce que je fais est de faciliter l’exécution d’un nœud local. L’une des principales plaintes concernant l’exécution d’un nœud est la quantité d’espace disque qu’il occupe. Cela réduirait ce montant et permettrait ainsi à plus de personnes d’exécuter plus de nœuds.
Combien d’espace cela peut-il économiser ?
Nous avons exécuté les commandes suivantes à partir de l’outil de ligne de commande TrueBlocks chifra:
chifra blocks 1756978-1757000 | grep input | cut -c1-26
Cela a produit un fichier (file.txt) avec des données d’environ 24 000 transactions extrayant uniquement les input des champs. Cela représente environ 200 blocs échantillonnés au hasard sur des blocs compris entre 3 000 000 et 13 000 000.
Ces données ressemblent à ceci :
"input": "0x",
"input": "0x18cbafe5"
"input": "0xc9807539"
"input": "0xab834bab"... plus 24,375 more rows...
Pas étonnant, mais assez intéressant.
Nous avons exécuté la commande suivante sur ce fichier de données et avons trouvé 1 578 codes différents à quatre octets dans les 24 379 enregistrements, dont 10 montrant plus de 100 transactions avec ce quatre octets.
cat file.txt | sort | uniq -c | sort -n
En utilisant le répertoire Ethereum à quatre octets, nous trouvons (pour les 10 fonctions apparaissant le plus fréquemment) ces informations :
Count Four-Byte Signature
------------------------------------------------------------------
105 0x23b872dd transferFrom(address,address,uint256)
111 0x202ee0ed submit(uint256,int256)
117 0x6ea056a9 sweep(address,uint256)
127 0xef343588 trade(uint256[8],address[4],...)
191 0x38ed1739 swapExactTokensForTokens(uint256,uint256...)
195 0x18cbafe5 swapExactTokensForETH(uint256,uint256,...)
352 0x7ff36ab5 swapExactETHForTokens(uint256,address[],...)
486 0x095ea7b3 approve(address,uint256)
7485 0xa9059cbb transfer(address,uint256)
10343 0x (straight up ETH transfer)
Ou, exprimé en pourcentages :
Percent Four-Byte Signature
------------------------------------------------------------------
0.54% 0x23b872dd transferFrom(address,address,uint256)
0.57% 0x202ee0ed submit(uint256,int256)
0.60% 0x6ea056a9 sweep(address,uint256)
0.65% 0xef343588 trade(uint256[8],address[4],...)
0.98% 0x38ed1739 swapExactTokensForTokens(uint256,uint256...)
1.00% 0x18cbafe5 swapExactTokensForETH(uint256,uint256,...)
1.80% 0x7ff36ab5 swapExactETHForTokens(uint256,address[],...)
2.49% 0x095ea7b3 approve(address,uint256)
38.36% 0xa9059cbb transfer(address,uint256)
53.01% 0x (straight up ETH transfer)
Alors 91% de toutes les transactions que nous avons échantillonnées étaient soit un transfert direct d’ETH, soit un transfert de jeton ERC20.
Salut de la main
Nous avons exécuté la commande suivante sur le même ensemble de blocs :
chifra blocks --raw 3000000-13000000:50000 | jq | grep size
et additionné le résultat pour trouver que les 200 blocs que nous avons échantillonnés occupent 5 132 592 octets (5 Mo) sur le disque dur. En étendant cela sur les 13 800 429 blocs au moment de la rédaction de cet article, nous obtenons une taille estimée pour les seuls blocs à 5,132,592 * 13,800,429 = 354,159,857,410 octets ou environ 350 GB pour les données de bloc uniquement.
Une supposition très approximative est qu’il y a autant de données de journal (qui ne sont pas stockées dans les blocs) qu’il y a de blocs, et si nous ajoutons 350 GB à 350 GB on a 700 GB qui est de l’ordre de grandeur de la taille de chaîne connue (2 To).
Alors, utilisons 350 GB comme la taille de seulement les journaux.
Extension 350 GB * .3836 * .1 (car nous pouvons réduire la taille d’un journal de transfert à 1/10 sa taille actuelle) nous obtenons 13.5 GB. C’est beaucoup ? Pas vraiment….
Nous pourrions si nous remplacions tous les transfer journaux avec un simple booléen indiquant le succès ou l’échec et a récupéré le reste des données de la transaction qui a engendré le transfert, réduisez la taille des données sur le disque dur d’environ 15 GB ou 1% du total (en supposant 1.5 TBau total).
Conclusion: Ne vaut pas l’effort !
TrueBlocks est totalement autofinancé à partir de nos fonds personnels et de quelques subventions telles que The Etheruem Foundation (2018), Consensys (2019), Moloch DAO (2021) et plus récemment Filecoin/IPFS (2021).
Si vous aimez cet article ou si vous souhaitez simplement soutenir notre travail, rendez-vous sur notre subvention GitCoin https://gitcoin.co/grants/184/trueblocks. Faites un don au prochain tour correspondant. Nous obtenons l’avantage supplémentaire d’une subvention de contrepartie plus importante. Même de petites quantités ont un grand impact.
Si vous préférez, n’hésitez pas à envoyer n’importe quel jeton à notre adresse publique Ethereum à trueblocks.eth ou 0xf503017d7baf7fbc0fff7492b751025c6a78179b.
Rejoignez Coinmonks Telegram Channel et Youtube Channel pour en savoir plus sur le trading et l’investissement crypto
