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.

fantasia estúpida top qn… é a publicação mais alta da semana? ou é a média? ou algum score de janela de tempo deslizante? de alguma forma, vou publicar esta semana. no pior cenário, vou publicar fotos de comida.