📝 Почему я предпочитаю Wren для смарт-контрактов (перевод статьи @dantheman)
После публикации поста о Смарт-контрактах несколько человек оставили комментарии по поводу моего выбора языка программирования. Wren – это малоизвестный невероятно незрелый, игрушечный, практически не проверенный на практике язык программирования. Буквально на этой неделе я был вынужден отправить запрос на внесение изменений в программный код (pull request), чтобы исправить критическую ошибку, не позволяющую его использовать.
Теоретически, благодаря новаторскому развитию исключения необходимости детерминированного вычисления “газа” (прим. газ – единица измерения в Ethereum, которая позволяет понять, какой объем работы необходимо выполнить для определенных операций и устанавливает диапазон комиссионных сборов за проведение транзакций), может использоваться любой язык программирования. Существуют интерпретаторы JavaScript, функциональные возможности языков Lua и Python.
Песочница (Sandboxing) – это сложно
Первоочередным фактором при выборе языка программирования является удобство песочницы. Другими словами того, что скомпилированный код может храниться в контролируемом наборе ресурсов процессора и памяти. Следующим требованием является простота обеспечения взаимодействия с программным кодом C++ /ChainBase.
До выбора Wren был рассмотрен Duktape – быстрый встроенный движок JavaScript, который, как я думал, был весьма многообещающим. Я потратил немало времени, пытаясь реализовать полноценную песочницу в Duktape, но без особого успеха.
JavaScript – прекрасный язык программирования, но он не предназначен для быстродействия, хотя современные движки JavaScript удивительно хороши! Но чтобы получить такую скорость от JavaScript, требуется невероятно сложная Just-In-Time компиляция.
Дело в том, что большинство языков программирования недостаточно хорошо поддерживают песочницы. Их внедрение является слишком сложным и требует приложения гораздо больших усилий, чем необходимо. В течение многих лет я искал хороший способ реализации песочницы для JavaScript. Но традиционные подходы к реализации надежных решений песочницы предполагают, как минимум, родительские потоки и подчиненные процессы. Такие песочницы требуют больших затрат на установку и свертывание и делают взаимодействие с блокчейном более дорогостоящим.
Взаимодействие с блокчейном представляет сложность, поскольку объем кода, выполняемого в песочнице, чрезвычайно мал! Типовой контракт будет выполняться за миллисекунды, но большинство традиционных подходов к реализации песочницы с существующими библиотеками требуют значительных расходов на установку и свертывание.
Wren же, даже в его текущем незрелом состоянии, оказался невероятно быстрым и эффективным, при этом без необходимости использования Just-In-Time компиляции. Я уверен, что Wren с родным компилятором мог бы стать на порядок быстрее. Быстрее, чем Lua или JavaScript JIT благодаря самой структуре этого языка программирования.
Язык программирования, который я могу настроить
Wren не является конечным языком программирования, это всего лишь отправная точка. Это небольшая, хорошо организованная база исходного кода, которая может быть легко адаптирована для удовлетворения потребностей блокчейна. На самом деле, я, возможно, вырезал бы многие функциональные возможности Wren (например, Fibers), чтобы сделать его еще проще.
Попытка модификации высокопроизводительных библиотек Lua, JavaScript и Python была бы намного сложнее и более подвержена ошибкам.
C++ -подобный язык программирования
Я бы даже сказал, что конечный язык программирования будет простой подсистемой C/C++. Скриптовый язык программирования C/C++ может быть легко преобразован в машинный код, при этом обладая преимуществами запросто помещенного в “песочницу” интерпретатора. Ненадежные скрипты будут запущены интерпретатором, а разработчики смогут легко преобразовать любой широко используемый скрипт с надежным альтернативным машинным кодом.
Снятие возражений @anonymint
Когда на Steem была совершена DOS атака, хакер транслировал столько транзакций, сколько мог. Все они были признаны действительными и включены в блокчейн. Отказ в обслуживании (DOS) был поддержан протоколом блокчейн, а не сетевым протоколом.
@anonymint, похоже, считает, что я не до конца разобрался, как работает ГАЗ в Ethereum. Вот то, что я "знаю" с точки зрения основных принципов. Если пользователи платят только за то, что они используют и возвращают то, что не используют, то всем нодам необходимо согласовать возврат.
Если автор транзакции указал “точное” количество требуемого ГАЗа, то механизм проверки допустимости может просто использовать это число, но нам известно, что создатель транзакции не может знать заранее, сколько именно ГАЗа потребуется для проведения сделки. (Другие пользователи могут изменить состояние в период между подписанием сделки и выполнением транзакции в блоке).
Что касается Доказательства выполнения работы (The Proof of Work) для транзакций
Я бы рассчитывал временную сложность, требуемую для того, чтобы отправитель потратил 10X процессорного времени для выполнения POW также, как для механизма проверки допустимости, выполняющего сценарий на таком же оборудовании. Запуск типового сценария должен занимать не более 1 мс, так что типовой POW должен занимать не более 10 мс на обычном персональном компьютере, и с течением времени это не должно привести к увеличению временной сложности.
До тех пор, пока ASIC или GPU позволяют злоумышленнику произвести большее количество транзакций, это было бы бессмысленно. Цель POW – заставить злоумышленника потратить больше времени и средств, чем сервер. ASIC или GPU в состоянии произвести эти вычисления быстрее, чем сервер сможет выполнить сценарий, но даже при этом злоумышленник будет вынужден использовать значительно большее количество ресурсов для такой же атаки.
Можно возразить, что POW для транзакций вообще не является целесообразным, потому что протокол уже оценил предельные значения процессорного времени, пропускной способности и памяти взломщиков. Целью доказательства выполнения работы является защита отдельной ноды от вредоносного пира. Каждая нода может легко идентифицировать подключения (и блокчейн аккаунты), которые выполняют больше транзакций, чем может быть обеспечено.
Фактически, 99% времени ограничение предоставляемой пропускной способности будет вызывать сбои транзакций еще до того, как будет вызван сценарий с интенсивной вычислительной нагрузкой на центральный процессор. Таким образом, Proof-of-work является объективным средством "запроса" фактического времени Вашего сценария и определения итогового вознаграждения производителя блока, включающего Ваш скрипт.
Заключение
Подход, который я предлагаю для реализации смарт-контрактов в конечном итоге может параллельно поддерживать множество различных языков программирования. Выбор языка в большей степени связан со своевременным выходом на рынок минимально жизнеспособного продукта, чем с чем-то еще. Если платформа окажется успешной, то со временем появятся и другие языки.
Я твердо убежден, что разработчики могут легко адаптироваться к любому C/ C++ подобному языку программирования, и что смарт-контракты должны представлять собой относительно простые фрагменты кода, не использующие повторно крупные библиотеки существующего кода, даже если такие библиотеки уже есть. Если вы не используете существующие библиотеки кода, то выбор языка программирования не имеет особого значения, до тех пор, пока он в достаточной степени подобен другим используемым языкам.
Оригинальный пост и его обсуждение ЗДЕСЬ
Перевод осуществлен: @uuuhha
Критика, комментарии и предложения приветствуются.
