Come noi di @Alchemy abbiamo sviluppato e lanciato il conto smart più efficiente in termini di gas nella storia dei conti smart. 🕶️ Tutto partendo da un'idea di circa 3 anni fa. Non sapevo allora che questo avrebbe portato a far risparmiare agli utenti enormi somme di denaro.

A maggio 2023, c'era questa frenesia su Twitter riguardo ai proxy (ad es. ERC1967, cloni, ecc.) Le persone avevano variabili immutabili, ma volevano i proxy. Questo era impossibile da fare-- ma alcuni di noi hanno accettato la sfida. Il problema non era l'EVM, però. Era il modo in cui pensavamo ai proxy.

Così l'abbiamo costruito: sono spuntate più versioni. Sia il mio che quello di @wighawag seguivano lo stesso concetto: potevamo semplicemente aggiungere gli immutabili copiando la fetta di memoria designata alla fine del bytecode restituito al momento della costruzione. Il codice vero e proprio era piuttosto breve e dolce.

(Puoi vedere la mia vecchia implementazione che ho costruito per divertimento 3 anni fa qui ahah: )

C'erano anche due modi per accedere agli argomenti immutabili durante l'esecuzione. Il primo - il mio modo, era semplicemente leggere il bytecode del proxy a partire da un offset costante. Semplice! Basta caricare gli immutabili in memoria e decodificarli secondo lo schema che hai impostato.

Il secondo era molto più complesso, ma leggermente più efficiente in termini di gas, e davvero interessante. L'idea era di aggiungere gli immutabili a ogni chiamata che il proxy delegava. Questo portava a un accesso immutabile più economico a costo di complessità e di un costo base del gas più elevato.

È interessante notare che Solady (la libreria che usiamo ora, non usare la mia piccola demo in produzione heh), inizialmente ha scelto il secondo approccio! Ma ora, ci siamo tutti concentrati sulla semplicità, non conosco alcun immutabile che aggiunga calldata in produzione, e Solady opta per lo stesso approccio che ho usato.

Quindi, come si collega questo ai conti? Il caso d'uso più basilare e comune degli smart account prevede che siano "possessi" da un altro firmatario. Tipicamente, lo faresti inizializzando lo smart account con l'indirizzo del proprietario. Ma mio fratello on-chain, c'è un modo migliore.

Probabilmente l'hai già capito: basta aggiungere l'indirizzo del firmatario al bytecode del proxy. Semplice. Poi, saltiamo completamente l'inizializzazione. Facile. E l'impl sa esattamente dove si trova quel proprietario nel bytecode (ancora meglio, Solady si occupa di questo per noi).

E voilà, il conto smart più potente mai costruito è ora, inoltre, più economico di uno swap su Uniswap. Cosa possiamo imparare da tutto ciò?

1. Insegui sempre la tua curiosità Potrebbe non esserci mai stato un account intelligente che utilizza questa tecnologia se non avessimo perseguito l'idea dei clone-con-argomenti-immutabili anni fa, solo perché l'abbiamo trovata interessante.

2. C'è quasi sempre una soluzione semplice Quando non puoi evitare la complessità, suddividi la complessità in parti più piccole e semplici. Dovresti essere in grado di spiegare tutto il tuo codice a qualcuno che è nuovo nel codice sorgente. Se non puoi, la tua soluzione è quasi certamente troppo complessa.

3. In realtà, non c'è nulla che ti fermi. Se hai un'idea su come migliorare qualcosa, fallo. Non c'è nulla che ti fermi. Ho pensato che potesse funzionare, l'ho provato e ha funzionato. Sei capace di cose incredibili se solo smettessi di trattenerti, anon.

Il tuo stack è già troppo profondo? Spero che questo thread sia stato in qualche modo interessante. Se l'hai trovato carino, sii un amico e colpisci il tuo ragazzo con un like in modo che io possa raggiungere più di 5 persone con i miei post qui. Inoltre, i parametri di 😸 riferimento Non siamo solo economici sul dispiegamento.