Разве 64-битная EVM не будет более эффективной в экосистеме Ethereum?

Как говорится в дизайне Ethereum Rationale :

Размер слова 32 байта — альтернатива — 4 или 8 байт слов, как в большинстве других архитектур, или неограниченный, как в биткойне. 4- или 8-байтовые слова слишком ограничены для хранения адресов и больших значений для криптографических вычислений, а неограниченные значения слишком сложны для создания модели безопасного газа. 32 байта идеально подходят, потому что этого достаточно для хранения 32-байтовых значений, обычных во многих криптографических реализациях, а также адресов (и предоставляет возможность упаковать адрес и значение в один индекс хранения в качестве оптимизации), но не настолько велики. как крайне неэффективный.

Но дело в том, что:

  • 256-битная реализация EVM помогает работать с адресами, и это правда. Но поскольку Ethereum не определяется как система криптовалюты, наиболее важной частью данных будут не адреса, а данные, используемые в смарт-контрактах .
  • Если большинство ЦП на рынке на самом деле сделаны с 64-битной архитектурой , а высокий процент данных, с которыми мы работаем в экосистеме Ethereum, примерно одинаков (64-битный, 32-битный, 16-битный, 8-битный. .). Как вы думаете, EVM на основе 64-битной архитектуры или что-то подобное не улучшит производительность всей системы?

Подумайте об этом, если вам нужно выполнить итерацию массива 32- или 64-битных данных, а блоки памяти EVM 256-битные, процессору требуется дополнительная работа для выполнения вычислений, и много времени теряется.

Если вы считаете, что это возможное улучшение, есть ли какие-либо открытые инициативы или EIP? Я ничего не видел.

Спасибо.

Ответы (2)

У вас будет несколько проблем

  • Если вы сохраните свое хранилище на 256 бит, к нему будет сложнее получить доступ. Вам нужно 4 x 64-битных слова для адресации слота хранения. Все операции должны будут преобразовать 256 бит в 64 бита. Ваш EVM будет довольно сложным для внедрения и аудита.

  • Если вы переключите хранилище на 64-битное, то ваш EVM будет более простым, но хранилище будет намного меньше, а коллизии гораздо более вероятны.

  • Вы не можете представлять адреса изначально. Адреса составляют 20 байт, и вам понадобятся 3 x 64-битных регистра.

  • Вам нужна обратная совместимость со старыми контрактами, и вам придется реализовать какой-то транслятор.

Процессор не является узким местом. Конечно, есть лучшие виртуальные машины (и есть исследования по замене ее на WASM), но текущая реализация делает свою работу правильно.

Более важным вопросом является ввод-вывод, каждая транзакция имеет несколько модификаций состояния Ethereum World. А в блоке около сотни транзакций, и каждые 15 секунд генерируется один блок.

Переход на 64-битную версию — чрезвычайно важное обновление Ethereum, и использование 256-битной машины было ошибкой. Исмаэль, сколько машинного кода ты написал? То, как вы говорите о регистрах, заставляет меня думать, что вы не понимаете машинный код. Использование 32-битной машины не повлияет на безопасность и снизит плату за газ из-за потраченного впустую места — больше, чем даже на 64-битной машине, потому что мы будем хранить меньше нулей. Тот факт, что boolтип тратит 255 бит, сводит меня с ума.
@rook Не нападай на человека, а на аргумент. Имея информацию, доступную сегодня, и потребности проекта, я бы выбрал 64-битную виртуальную машину, но 7 лет назад опыт был другим. Если вы чувствуете себя способным, напишите 64-битный EVM и предложите изменение в EF. Если она будет хорошей, она будет принята, вы получите любую работу, которую захотите, и заплатите соответственно. Говорить легко, написать то, что работает, намного сложнее.
-Мои извенения. Неважно, сколько регистров занимает переменная, потому что эти машины должны иметь код операции, который может выполнять несколько сравнений регистров. Делая все переменные 256-битными, вы в конечном итоге храните больше нулей, чем фактических данных, и это то, что мы видим. Я бы с удовольствием написал эту виртуальную машину, это не сложно, потому что в этом нет ничего нового. Первый EVM был совершенно новым, и это было трудно сделать, и я сочувствую этому. Но теперь, когда мы видим, что EVM хранит больше пустого места, чем реальных данных, у нас есть реальная проблема.
На самом деле, если им нужны инженеры для этого проекта, у меня есть отличное резюме. Итак, для этого случая - x86 имеет 8 регистров общего назначения, что означает, что в 64-битной системе можно загрузить два полных 256-битных ключа, а затем сравнение - это одна операция. EVM должен следовать этому шаблону, с кем мне нужно поговорить?
@rook Фонд Ethereum и другие организации имеют программы грантов, на которые может подать заявку каждый, ethereum.org/en/community/grants . Прежде чем подавать заявку, я бы предложил принять участие в некоторых форумах и поискать другие исследовательские интересы, такие как ethresear.ch .
@ishmael спасибо, ты очень ценишь это сообщество и добрый человек.

Конечно, сложно сказать наверняка, но моя интуиция подсказывает, что узкое место не в размере слов. Узким местом является целенаправленное введение 14-секундного времени блока. Время блока — это параметр, выбранный первоначальными разработчиками, чтобы заставить майнеров расходовать энергию в виде электричества. Даже если бы вы оптимизировали где-то в системе, эти 14 секунд не исчезли бы, поэтому оптимизация не проявилась бы.

Да, но с переходом на PoS и другие методологии консенсуса не так важно фиксированное время блока и более важные вещи, такие как эта реализация EVM. Вот почему я попросил об этом.
Значит, после того, как мы перейдем на PoS, останется гораздо больше места для улучшения архитектуры EVM?
Разве 64-битная EVM не будет более эффективной в экосистеме Ethereum?
СпросиСетьПолитика конфиденциальности1y, 0v