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