Agregar EIP: esquema de codificación de longitud de ejecución de datos de llamada Para EVM L1 (por ejemplo, Tempo), la eficiencia de los datos de llamada vuelve a ser importante. Las baterías L2 de la pila OP comprimen automáticamente los datos de llamadas y reenvían los ahorros a los usuarios. Pero si eres un L1, tendrás que optimizarlo. Explicación técnica (para los fans de Fantasy Top): En los datos de llamadas de Ethereum, los cero bytes son 1/4 del precio de los bytes distintos de cero. Pero esto es un poco arbitrario, porque los datos de llamadas todavía se transmiten y almacenan textualmente sin siquiera una simple compresión RLE. Ese costo de 1/4 es incentivar la compresión, pero nadie lo está haciendo en realidad. Si se implementa incluso un RLE simple, cero bytes costaría 1/100 del costo de bytes distintos de cero. Entonces, para mejorar la alineación de Ethereum y la polinización cruzada, pensé, ¿por qué no hacer un nuevo EIP para esto? Esto también es por razones prácticas, porque no quiero cambiar los estándares de contratos inteligentes existentes, como ERC-7821, para incluir un modo optimizado para datos de llamadas solo para eso. Una optimización en el nivel txn sería mejor (porque todos los datos de llamadas txn se beneficiarán). Hay dos formas de hacerlo: - Implementar un esquema de compresión RLE de nivel txn (nivel EIP). - Implementar precompilaciones para la compresión/descompresión de calldata (estilo RIP). LibZip.cdCompress de Solady es bastante eficiente, pero ¿por qué no convertirlo en precompilaciones? De cualquier manera, primero tendremos que formalizar el esquema de codificación y, por lo tanto, la necesidad de escribir esto.