Ajouter EIP : Schéma d'encodage par longueur d'exécution de calldata Pour les EVM L1 (par exemple, Tempo), l'efficacité du calldata est à nouveau importante. Les L2 de la pile OP compressent automatiquement le calldata et renvoient les économies aux utilisateurs. Mais si vous êtes un L1, vous devrez optimiser cela. Explication technique (pour les fans de Fantasy Top) : Dans le calldata d'Ethereum, les octets nuls coûtent 1/4 du prix des octets non nuls. Mais c'est un peu arbitraire, car le calldata est toujours transmis et stocké tel quel sans même une simple compression RLE. Ce coût de 1/4 est destiné à inciter à la compression, mais personne ne le fait réellement. S'il y avait même une simple RLE mise en œuvre, les octets nuls coûteraient 1/100 du coût des octets non nuls. Donc, pour améliorer l'alignement d'Ethereum et polliniser en retour, j'ai pensé, pourquoi ne pas créer un nouvel EIP pour cela. C'est aussi pour des raisons pratiques, car je ne veux pas changer les normes de contrat intelligent existantes telles que l'ERC-7821 pour inclure un mode optimisé pour le calldata juste pour cela. Une optimisation au niveau de la transaction serait mieux (car l'ensemble du calldata de la transaction en bénéficierait). Il y a deux façons de le faire : - Mettre en œuvre un schéma de compression RLE au niveau de la transaction (niveau EIP). - Mettre en œuvre des précompilations pour la compression / décompression du calldata (style RIP). La LibZip.cdCompress de Solady est assez efficace, mais pourquoi ne pas en faire des précompilations ? Quoi qu'il en soit, nous devrons d'abord formaliser le schéma d'encodage, et donc la nécessité d'écrire cela.

fantaisie stupide top qn… est-ce le post le plus élevé de la semaine ? ou est-ce la moyenne ? ou un score sur une fenêtre temporelle glissante ? je vais de toute façon poster cette semaine. dans le pire des cas, je posterai des photos de nourriture.