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

Каждый язык программирования предназначен для конкретной операционной среды и целевых задач; и эти ограничения определяют почти все проектные решения о том, какие функции поддерживать, а какие исключить.

Некоторое время назад я потратил довольно много времени на создание кросс-компилятора Go -> EVM. Мне удалось запустить несколько тривиальных программ, и это определенно было очень весело, но довольно скоро я начал сталкиваться с ограничениями EVM, которые противоречат основным предположениям, лежащим в основе Go:

• Каждой горутине требуется не менее 64 КБ памяти. Тривиально низкая для любого приличного оборудования в настоящее время, но непомерно высокая и дорогая для EVM.
• Go полагается на диспетчер памяти на уровне операционной системы. Это означает, что для запуска программ Go на EVM нам потребуется разработать диспетчер микропамяти поверх EVM, который может поддерживать операции, необходимые для Go. Я разработал POC-версию алгоритма Buddy Memory Allocation , но она основана на том факте, что память ограничена и фиксирована, и в ней выделяются произвольные фрагменты. С другой стороны, EVM является «бесконечным» и взимает плату за максимальное выделенное смещение. Таким образом, все обычные алгоритмы распределения памяти пострадают, поскольку они предполагают, что затраты памяти постоянны, тогда как EVM является позиционным и даже экспоненциальным.
• Go — это язык со сборщиком мусора, поэтому при каждом выделении памяти также должны поддерживаться счетчики ссылок, которые должны хорошо работать с распределителем памяти. Опять же не невозможно решить, но связанный с ним код операции и нелинейные затраты памяти делают это очень дорогим.
• Даже если проблемы с памятью будут решены, вам все равно нужно найти решения для примитивов синхронизации, прерываний операционной системы и других конструкций хранения, которые мы склонны считать само собой разумеющимися, но которых нет у EVM.

Эти проблемы были основными причинами, по которым я решил не продолжать портировать Go на EVM, но они действительно подчеркивают, что современные языки основаны на бесчисленных функциях, поддерживаемых базовыми операционными системами, которые сами основаны на предположениях о том, что представляет собой базовое оборудование. способности и связанные с этим расходы.

В этом аспекте EVM сильно отличается от зверя, поэтому применение одних и тех же предположений приводит к крайне неоптимальному выполнению кода. Поэтому было принято решение разработать язык, специально адаптированный для среды выполнения EVM. Это действительно, вероятно, намного больше работы, чем перенос существующего синтаксиса языка (!), Но это также приводит к созданию пригодной для использования среды по сравнению со всеми видами «задокументированных ограничений», которые, хотя что-то является допустимым кодом Go, вы не можете использовать это потому что "xyz".

Обратите внимание: вполне может быть, что первоначальный дизайн EVM плох и будет расширен, модернизирован или даже полностью заменен, когда кто-то придумает гораздо лучшее решение для работы. Но это возможность будущего, тогда как Solidity — это текущая потребность.

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

1. Компилятор должен иметь возможность выводить код, оптимизированный для размера кода (в то время как многие другие языки стремятся оптимизировать эффективность вычислений).

2. Оптимизация для обеспечения безопасности и возможности аудита.

Также возможны другие организационные/социальные преимущества использования нового языка, такие как

3. Гораздо большая гибкость решений по дизайну вашего компилятора (никто не будет пытаться использовать существующий код в вашем новом компиляторе и жаловаться, что он не работает)

См. другой ответ @Péter Szilágyi для примера попытки использовать язык Go для кросс-компиляции в байт-код EVM.

Справка: Виталик отвечает о том, зачем новый язык в АМА

Есть несколько проблем. Во-первых, существующие компиляторы C++ и другие компиляторы имеют тенденцию выводить код, который на самом деле не оптимизирован для компактного размера кода; например. даже самая простая программа выдает файл длиннее 4кб. Это нормально для компьютеров, где хранение стоит дешево, но ужасно для блокчейнов, где хранение дорого. Поэтому требуются специализированные компиляторы

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

Я не уверен, будет ли мой ответ легко слиться с ответом @ Péter Szilágyi , поэтому я делаю его отдельным.