Я все еще недоумеваю, что сообщество разработчиков Ethereum Core не приоритизирует решение самой часто упоминаемой проблемы разработчиков EVM согласно опросу Solidity Lang.
1. Слишком глубокий стек: да, это немного проблема навыков Solidity, но просто добавьте диапазон опкодов SWAP/DUP17-32 и закончите с этим. Вы сожжете некоторые опкоды. Это нормально, они предназначены для использования. У вас будет еще одно несоответствие в стиле PUSH0, это тоже нормально, это не идеально, но это нормально.
2. Уберите лимит в 24КБ. Мне не важно, что вы сделаете, сделайте это 32КБ, 48КБ, 128КБ, 256КБ, 512КБ, сделайте все сразу, поэтапно, оцените это или нет, но сделайте что-то! Прямо сейчас, а не в следующем году!
Если вы масштабируете L1, обеспечение возможности писать контракты без глупых ошибок - это P0.
Если система не может обрабатывать дополнительные 8КБ на байт-код, что является параметром, установленным 10 лет назад, то у вас нет шансов действительно масштабировать L1.
Исправьте слишком глубокий стек и лимит размера байт-кода! Для разработчиков!
1. Слишком глубокий стек: да, это немного проблема навыков Solidity, но просто добавьте диапазон опкодов SWAP/DUP17-32 и закончите с этим. Вы сожжете некоторые опкоды. Это нормально, они предназначены для использования. У вас будет еще одно несоответствие в стиле PUSH0, это тоже нормально, это не идеально, но это нормально.
2. Уберите лимит в 24КБ. Мне не важно, что вы сделаете, сделайте это 32КБ, 48КБ, 128КБ, 256КБ, 512КБ, сделайте все сразу, поэтапно, оцените это или нет, но сделайте что-то! Прямо сейчас, а не в следующем году!
Если вы масштабируете L1, обеспечение возможности писать контракты без глупых ошибок - это P0.
Если система не может обрабатывать дополнительные 8КБ на байт-код, что является параметром, установленным 10 лет назад, то у вас нет шансов действительно масштабировать L1.
Исправьте слишком глубокий стек и лимит размера байт-кода! Для разработчиков!