Недавно я видел, как NEO рекламируется как Ethereum, но с поддержкой нескольких языков для смарт-контрактов.
Это действительно то, чего не хватает Эфириуму? Разве технически невозможно создать больше компиляторов для смарт-контрактов, генерирующих байт-код Ethereum? По-моему, уже есть три компилятора: Solidity, Serpent и LLL.
Все это напоминает мне ажиотаж вокруг .NET, когда было вполне возможно скомпилировать любой язык в JVM, но .NET по-прежнему рекламировался как независимый от языка. История повторяется? Или я что-то упускаю?
Спасибо.
Я попытаюсь ответить на техническую часть вопроса. У меня была такая же мысль о том, что история повторяется, или что авторы не знают, о чем они говорят, когда я увидел рекламу нескольких языков как особенность, присущую NEO, за исключением Ethereum.
Короткий ответ: нет, отсутствие языковой поддержки в Ethereum не является неотъемлемым свойством Ethereum.
Учитывая, что и NEO, и Ethereum являются полными по Тьюрингу, они, как было доказано, могут использоваться для реализации друг друга (термины, которые мы используем сейчас, по, возможно, очевидным причинам, не использовались в этой статье); то есть, даже если они не могут запускать одни и те же программы напрямую, виртуальная машина (ВМ) NEO может имитировать виртуальную машину Ethereum и наоборот, используя имитируемую машину для выполнения ввода с некоторыми оговорками.
Вышеизложенное предостережение косвенно относится к NEO и Ethereum. Первое предостережение заключается в том, что эмулируемая скорость выполнения будет ниже, чем у сопоставимой виртуальной машины; Измеряемый в инструкциях, собственный контракт Ethereum потребует меньше инструкций для выполнения (и, следовательно, будет стоить меньше газа), чем выполнение контракта, эмулирующего виртуальную машину NEO, выполняющую контракт NEO. Конечно, делать последнее глупо. Мы бы просто написали нативный код. Это приводит ко второму предостережению: не каждая инструкция виртуальной машины может быть эффективно эмулирована.другой ВМ. Например, на компьютерах без модулей с плавающей запятой выполнение математических вычислений с плавающей запятой требует больших вычислительных ресурсов, но все же это можно сделать. В Германии введение zkSNARKS в Ethereum в Метрополисе позволит реализовать в контрактах то, что раньше было невозможно. Еще одно предостережение заключается в том, что ввод/вывод (I/O) и периферийные устройства, доступные для виртуальных машин, не совпадают — в частности, виртуальная машина Ethereum в настоящее время не может напрямую взаимодействовать с виртуальной машиной NEO, и я ожидаю, что верно и обратное. Есть и другие предостережения, которые я пропущу (например, ограничения памяти из-за переноса), но приведенные выше, пожалуй, самые большие предостережения.
Возможно, что NEO имеет больший набор быстрых нативных операций, которые облегчают эффективную поддержку большего количества операций, но если это окажется полезным, я уверен, что кто-то предложит EIP для добавления поддержки инструкция. В то же время, если кто-то действительно хочет писать на определенном языке, можно также написать кросс-компилятор (или написать новый компилятор EVM и оптимизатор для интерфейса синтаксического анализа существующего компилятора) и добавить некоторую дополнительную поддержку для обработки блокчейна. /O, такие как определение текущего номера блока и управление состоянием.
При дальнейшем чтении выясняется, что у NEO есть некоторые функции ввода-вывода, которые являются частью его виртуальной машины, но не являются частью Ethereum — в частности, триггеры, которые вызывают запуск контрактов, такие как запуск в определенную дату или когда другая учетная запись достигает определенного баланса). В NEO это немного похоже на обратные вызовы, управляемые прерываниями; в Ethereum это можно сделать (без модификации EVM) с помощью внешнего опроса, такого как Ethereum Alarm Clock. Конечно, это не влияет на то, какие языки поддерживаются или поддерживаются.
Ричард Хоррокс
Алексг