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.
Adicionar EIP: Esquema de codificação de comprimento de execução de calldata
Para EVM L1s (por exemplo, Tempo), a eficiência do calldata importa novamente. As L2s da OP stack comprimem automaticamente o calldata e repassam as economias para os usuários. Mas se você é um L1, precisará otimizar isso.
Explicação técnica (para os fãs de Fantasy Top):
No calldata do Ethereum, bytes zero custam 1/4 do preço de bytes não zero. Mas isso é meio arbitrário, porque o calldata ainda é transmitido e armazenado verbatim sem nem mesmo uma simples compressão RLE. Esse custo de 1/4 é para incentivar a compressão, mas ninguém está fazendo isso na verdade. Se houvesse até mesmo uma simples RLE implementada, bytes zero custariam 1/100 do custo de bytes não zero.
Então, para melhorar o alinhamento do Ethereum e polinizar de volta, pensei, por que não criar um novo EIP para isso. Isso também é por razões práticas, porque não quero mudar os padrões existentes de contratos inteligentes, como o ERC-7821, para incluir um modo otimizado de calldata só por causa disso. Uma otimização no nível da transação seria melhor (porque todo o calldata da transação se beneficiaria).
Existem duas maneiras de fazer isso:
- Implementar um esquema de compressão RLE no nível da transação (nível EIP).
- Implementar pré-compilações para compressão/descompressão de calldata (estilo RIP). O LibZip.cdCompress da Solady é bastante eficiente, mas por que não transformá-lo em pré-compilações?
De qualquer forma, precisaremos formalizar primeiro o esquema de codificação, e assim a necessidade de escrever isso.

Top
Classificação
Favoritos