Итак, важным моментом в вашем вопросе является то, почему новая виртуальная машина, а не виртуальная машина Java. хорошо, давайте вместо этого выберем виртуальную машину Java, что мы получим? :

1 - сложный и объемный байткод => как его хранить, в блокчейне за что стоит? (Зная, что один Java-метод может иметь размер до 64 КБ), таким образом, такая виртуальная машина или язык не экономят место.

2 - бесполезные функции и проблемы с безопасностью : доступ к сети, поток ввода-вывода, файл W/R ... => каждая из этих функций подразумевает большие проблемы с безопасностью. подумайте об этом, вы можете написать код, который пингует (от смерти) другую машину или получает доступ к защищенным файлам, или даже крадет закрытые ключи майнера. Даже в песочнице может возникнуть ошибка, а функция «запись/чтение» файла может нарушить безопасность всей системы. поэтому нам нужно избавиться от всех этих функций, что является сложной задачей для лицензированной виртуальной машины. Мы должны помнить, что виртуальная машина Blockchain должна быть изолирована без возможности связи с внешней средой.

3- если у вас есть JVM, вы должны использовать Java или другой язык JVM, которые не адаптированы к контексту блокчейна ( отсутствие детерминизма, доступ к памяти и оборудованию, более высокая задержка выполнения, операции с плавающей запятой и т . д .). Представьте, что у вас есть байт-код Java с функцией rand(), каким будет результат и как тогда достичь консенсуса?

4- Слабая устойчивость к DDos (как бы вы поставили газоподобную систему в сложную виртуальную машину типа Java VM?).

3 - JAVA VM является лицензированным продуктом Sun , поэтому вы не можете настроить его для интеграции в среду Ethereum (например, как бы вы рассчитали стоимость газа, чтобы избежать Dos-атак?)? чтобы решить эту проблему, вам нужно написать собственную виртуальную машину Java, что является сложной задачей: https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license .

Кроме того, вы можете проверить этот ответ о том, зачем создавать новый язык контрактов: в чем преимущество создания новых языков смарт-контрактов, таких как Solidity, вместо использования других языков?

Виталик Бутерин сделал презентацию об Ethereum для Hyperledger 28 апреля 2016 года и показал этот слайд:

Требования к ЭВМ

● Небольшой размер кода (чтобы очень много контрактов от многих пользователей можно было хранить на одном узле)

● Безопасность виртуальных машин разработана для запуска ненадежного кода от произвольных сторон.

● Несколько реализаций (для перекрестной проверки и уменьшения централизации разработчиков в общедоступной цепочке).

● Идеальный детерминизм (для консенсуса)

● Бесконечное сопротивление контура

• Само это должно быть выполнено совершенно детерминистически; тайм-ауты недопустимы

Третий пункт Виталик уточнил как централизацию разработчиков, наблюдаемую в Биткойне, где протоколом считается единая реализация.

В презентации не было времени для обсуждения оценки существующих виртуальных машин.

Смарт-контракты должны иметь абсолютно детерминированный результат, потому что они будут выполняться на нескольких машинах. Также необходимо было хранить состояние в блокчейне. Поскольку ни одна виртуальная машина не соответствовала этим требованиям, пришлось создать новую. EVM был создан для удовлетворения всех требований, обеспечивая при этом максимальную гибкость.