Comment nous, chez @Alchemy, avons développé et lancé le compte intelligent le plus économe en gaz de l'histoire des comptes intelligents. 🕶️ Tout cela à partir d'une idée vieille d'environ 3 ans. Je ne savais pas à l'époque que cela permettrait d'économiser d'énormes sommes d'argent aux utilisateurs.

En mai 2023, il y avait cette folie sur Twitter concernant les proxies (par exemple, ERC1967, clones, etc.) Les gens avaient des variables immuables, mais ils voulaient des proxies. C'était impossible à réaliser -- mais certains d'entre nous ont relevé le défi. Le problème n'était pas l'EVM cependant. C'était notre façon de penser les proxies.

Alors nous l’avons construit - plusieurs versions sont apparues. Le mien et le @wighawag suivaient tous les deux le même concept - nous pourrions simplement ajouter les immutables en copiant la tranche de mémoire désignée à la fin du bytecode renvoyé lors de la construction. Le code réel était assez court et doux.

(Vous pouvez voir mon ancienne implémentation que j'ai construite pour le plaisir il y a 3 ans ici lmao : )

Il y avait aussi deux façons d'accéder aux arguments immuables à l'exécution. La première - ma méthode - consistait simplement à lire le bytecode du proxy à partir d'un décalage constant. Simple ! Il suffit de charger les immuables en mémoire et de les décoder selon le schéma que vous avez mis en place.

Le second était beaucoup plus complexe, mais légèrement plus efficace en termes de gaz, et vraiment intéressant. L'idée était que vous ajouteriez les immuables à chaque appel que le proxy déléguait. Cela conduisait à un accès immuable moins coûteux au prix de la complexité et d'un coût de gaz de base plus élevé.

Fait intéressant, Solady (la bibliothèque que nous utilisons maintenant, ne pas utiliser ma petite démo en prod heh), a initialement opté pour la deuxième approche ! Mais maintenant, nous avons tous convergé vers la simplicité, je ne connais pas d'immuables ajoutant des calldata en prod, et Solady opte pour la même approche que j'ai utilisée.

Alors, comment cela se relie-t-il aux comptes ? Le cas d'utilisation le plus basique et courant des comptes intelligents implique qu'ils soient "possédés" par un autre signataire. Typiquement, vous feriez cela en initialisant le compte intelligent avec l'adresse du propriétaire. Mais mon frère onchain, il y a une meilleure façon.

Vous l'avez probablement déjà compris : il suffit d'ajouter l'adresse du signataire au bytecode du proxy. Simple. Ensuite, nous sautons complètement l'initialisation. Facile. Et l'impl sait exactement où se trouve ce propriétaire dans le bytecode (encore mieux, Solady s'occupe de cela pour nous).

Et voilà, le compte intelligent le plus puissant jamais construit est maintenant, en plus, moins cher qu'un échange Uniswap. Alors, que pouvons-nous en tirer ?

1. Poursuivez toujours votre curiosité Il n'y aurait peut-être jamais eu de compte intelligent utilisant cette technologie si nous n'avions pas poursuivi cette idée de clones avec des arguments immuables il y a des années - juste parce que nous l'avons trouvée intéressante.

2. Il y a presque toujours une solution simple Lorsque vous ne pouvez pas éviter la complexité, divisez la complexité en parties plus petites et plus simples. Vous devriez être capable d'expliquer tout votre code à quelqu'un de nouveau dans la base de code. Si vous ne le pouvez pas, votre solution est presque certainement trop complexe.

3. Il n'y a en fait rien qui vous empêche de le faire. Si vous avez une idée pour améliorer quelque chose, faites-le. Rien ne vous en empêche. J'ai pensé que cela pourrait fonctionner, je l'ai essayé, et ça a marché. Vous êtes capable de choses incroyables si vous cessiez de vous retenir, anonyme.

Votre pile est-elle déjà trop profonde ? J’espère que ce fil de discussion était quelque peu intéressant. Si vous l’avez trouvé chouette, soyez un ami et frappez votre garçon avec un like pour que je puisse atteindre plus de 5 personnes avec mes messages ici. Aussi, les benchmarks 😸 Nous ne sommes pas seulement bon marché sur le déploiement.