Dodaj EIP: Schemat kodowania długości uruchamiania calldata Dla EVM L1 (np. Tempo) efektywność calldata znów ma znaczenie. L2 OP stack automatycznie kompresuje calldata i przekazuje oszczędności z powrotem do użytkowników. Ale jeśli jesteś L1, będziesz musiał to zoptymalizować. Wyjaśnienie techniczne (dla fanów Fantasy Top): W Ethereum calldata, zera kosztują 1/4 ceny bajtów różniących się od zera. Ale to jest trochę arbitralne, ponieważ calldata jest nadal przesyłana i przechowywana dosłownie bez nawet prostej kompresji RLE. Ten koszt 1/4 ma na celu zachęcenie do kompresji, ale nikt tego nie robi. Gdyby nawet wprowadzono prostą kompresję RLE, zera kosztowałyby 1/100 kosztu bajtów różniących się od zera. Aby poprawić zgodność Ethereum i wspierać to z powrotem, pomyślałem, dlaczego nie stworzyć nowego EIP dla tego. To również z powodów praktycznych, ponieważ nie chcę zmieniać istniejących standardów inteligentnych kontraktów, takich jak ERC-7821, aby uwzględnić zoptymalizowany tryb calldata tylko dla tego. Optymalizacja na poziomie transakcji byłaby lepsza (ponieważ cała calldata transakcji skorzysta). Są dwa sposoby, aby to zrobić: - Wprowadzić schemat kompresji RLE na poziomie transakcji (na poziomie EIP). - Wprowadzić prekompilacje do kompresji / dekompresji calldata (styl RIP). LibZip.cdCompress Solady jest dość wydajny, ale dlaczego nie przekształcić tego w prekompilacje? W każdym razie, najpierw musimy sformalizować schemat kodowania, a zatem potrzeba napisania tego.

głupia fantazja na najwyższym poziomie… czy to najwyższy post w tygodniu? czy to średnia? czy może jakiś wynik z przesuwającego się okna czasowego? jakoś opublikuję w tym tygodniu. w najgorszym przypadku wrzucę zdjęcia jedzenia.