Я все еще в недоумении, что сообщество разработчиков 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.
Исправьте слишком глубокий стек и лимит размера байт-кода! Для разработчиков!