Tópicos populares
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Como nós da @Alchemy desenvolvemos e lançamos a conta inteligente mais eficiente em termos de gás na história das contas inteligentes. 🕶️
Tudo a partir de uma ideia de ~3 anos.
Mal sabia eu naquela época que isso acabaria economizando enormes quantias de dinheiro para os usuários.

Em maio de 2023, houve uma loucura no Twitter sobre proxies (por exemplo, ERC1967, clones, etc.)
As pessoas tinham variáveis imutáveis, mas queriam proxies. Isso era impossível de fazer -- mas alguns de nós aceitaram o desafio. O problema não era o EVM, no entanto.
Era a forma como pensávamos sobre proxies.
Então nós o construímos -- várias versões surgiram.
O meu e o @wighawag seguiam o mesmo conceito -- poderíamos simplesmente acrescentar os imutáveis copiando a fatia designada de memória no final do bytecode retornado na construção.
O código real era muito curto e doce.

(Você pode ver minha antiga implementação que construí por diversão há 3 anos aqui, lmao: )
Havia também duas maneiras de acessar os argumentos imutáveis em tempo de execução.
A primeira - do meu jeito, era apenas ler o bytecode do proxy a partir de um deslocamento constante. Simples!
Basta carregar os imutáveis na memória e decodificá-los de acordo com o esquema que você configurou.
O segundo era muito mais complexo, mas ligeiramente mais eficiente em termos de gás, e extremamente interessante.
A ideia era que você anexasse os imutáveis a cada chamada que o proxy delegasse. Levando a um acesso imutável mais barato à custa de complexidade e um custo base de gás mais alto.
Curiosamente, a Solady (a biblioteca que agora usamos, não use a minha pequena demonstração em produção heh), originalmente optou pela segunda abordagem!
Mas agora, todos nós convergimos para a simplicidade, não conheço nenhuma imutável que anexe calldata em produção, e a Solady opta pela mesma abordagem que eu usei.
Então, como isso se relaciona com contas?
O caso de uso mais básico e comum de contas inteligentes envolve elas serem "possuídas" por outro signatário.
Normalmente, você faria isso inicializando a conta inteligente com o endereço do proprietário.
Mas, meu irmão onchain, há uma maneira melhor.
Você provavelmente já percebeu isso -- nós apenas anexamos o endereço do signatário ao bytecode do proxy.
Simples.
Então, pulamos completamente a inicialização. Fácil. E a implementação sabe exatamente onde o proprietário está localizado no bytecode (ainda melhor, o Solady cuida disso para nós).
E voilà, a conta inteligente mais poderosa já construída é agora, também, mais barata do que uma troca no Uniswap.
Então, o que podemos aprender com isso?

1. Persiga sempre a sua curiosidade
Pode nunca ter existido uma conta inteligente que utilizasse esta tecnologia se não tivéssemos perseguido a ideia de clones-com-argumentos-imutáveis anos atrás -- apenas porque achámos interessante.
2. Quase sempre há uma solução simples
Quando não consegues evitar a complexidade, divide a complexidade em partes menores e mais simples. Deverias ser capaz de explicar todo o teu código a alguém que é novo na base de código.
Se não consegues, a tua solução é quase certamente demasiado complexa.
3. Na verdade, não há nada que o impeça.
Se você tem uma ideia de como melhorar algo, faça. Não há nada que o impeça. Eu pensei que isso poderia funcionar, tentei e funcionou.
Você é capaz de coisas incríveis se apenas parar de se segurar, anon.
Sua pilha ainda é muito profunda?
Espero que este tópico foi um pouco interessante.
Se você achou legal, seja um amigo ou acerte seu menino com um like para que eu possa alcançar mais de 5 pessoas com meus posts aqui.
Além disso, os parâmetros de 😸 referência
Não somos apenas baratos na implantação.
5,49K
Top
Classificação
Favoritos

