Ardor и Конкуренты, ч. 7: Ethereum (Смарт контракты)

Перевод статьи с английского, источник https://www.nxter.org/ardor-vs-competition-pt-7-ethereum-smart-contracts/

Эта одна из серий статей, в которых сравнивается платформа Ardor с другими блокчейн проектами с аналогичными функциями или целями. Вы можете найти предыдущие статьи по следующим ссылкам:

На этой неделе я изучал платформу Ethereum, которую, возможно, не нуждается в представлении.

Для нескольких проектов, которые я рассматривал в серии данных статей, было довольно сложно найти подробную техническую информацию. В плане Ethereum всё совершенно наоборот: так много доступной информации, что трудно ее отфильтровать, чтобы получить статью разумного размера и не упустить важные идеи.

По этой причине я выбрал только два аспекта Ethereum для сравнения с Ardor. В этой части сравнивается смарт контракты Ethereum с смарт транзакциями Ardor, а в следующей статье будут сопоставлены подходы, которые обе платформы используют для управления раздуванием блокчейна. Есть еще много тем, которые я хотел бы затронуть, - планы перейти на Proof-of-Stake (Casper), стратегии платежного канала (Raiden и Plasma), партнерские отношения с крупными компаниями через Enterprise Ethereum Alliance и выборку запущенных проектов, но обсуждение даже нескольких этих тем с желаемым углубленным изучением является достаточно сложной задачей. Кроме того, две темы, которые я выбрал, представляют собой наиболее интересные сравнения двух платформ, на мой взгляд (но см. статью о платформах Ardor и Plasma, ссылки на которые указаны выше, для получения информации о Plasma).

Давайте далее поговорим о смарт контрактах.

Смарт контракты and “Rich Statefulness”

Дизайн Ethereum сочетает в себе элементы Bitcoin и Nxt и добавляет несколько новых функций. Подобно Bitcoin, Ethereum использует низкоуровневый язык сценариев для кодирования транзакций и хранит содержимое каждого блока в древовидной хеш - функции Merkle, чьи хеш – источники записываются в заголовках блоков (подробнее об этом в следующей статье). И, как и Nxt, Ethereum отслеживает текущее состояние балансов счетов и другие данные, связанные с аккаунтом, напрямую, а не использует Bitcoin модель вывода неиспользованных транзакций (UTXO).

Самые важные нововведения, которые Ethereum добавляет к этой комбинации, состоят из двух частей: способность хранить скрипты (контракты) в так называемых «контрактных аккаунтах», которые осуществляют транзакции автономно, а не контролируются пользователем; и возможность передавать данные аккаунта от одной транзакции к другой. Язык сценариев Ethereum также несколько более мощный, чем язык платформы Bitcoin, что позволяет контрактам включать циклы и ссылаться на другие контракты.

Объединив эти понятия, можно создать «смарт контракты» с отслеживанием состояния, которые являются битами кода и данных, которые находятся на контрактных аккаунтах и действуют как автономные агенты, перехватывая входные данные от пользователей и другие контракты, и осуществляя с ними транзакции в соответствии с определенными правилами в их контрактном кодексе. Модификатор «наблюдающий за состоянием» имеет решающее значение: поскольку смарт контракт может иметь собственное внутреннее состояние, одна транзакция может влиять на обработку последующих транзакций. Это значительный отход от модели Bitcoin, где сценарии транзакций выполняются только один раз и где понятие «состояние», доступное для скрипта, по существу ограничено тем, израсходован или нет данный вывод.

(Возможно, вы заметили, что я ничего не сказал о полноте по Тьюрингу. В зависимости от того, насколько вы педантичны, вы можете задаваться вопросом о том, является ли язык сценария Ethereum на самом деле полным по Тьюрингу. Как говорится в этом замечательном видео, определение полноты по Тьюрингу является отвлекающим аргументом. Гораздо важнее тот факт, что смарт контракты отслеживают состояние и могут взаимодействовать как друг с другом, так и с пользователями интересным образом).

Потенциальные применения смарт контрактов выходят далеко за рамки условий перевода денег с одного аккаунта на другой. Даже в оригинальном документе white paper (который, кстати сказать, отлично читается) предлагается несколько нефинансовых целей, включая хранение файлов, голосование, распределенные вычисления, управление децентрализованными организациями и децентрализованными рынками. С тех пор разработчики также нашли множество других приложений, таких как децентрализованная рассылка сообщений. И, конечно же, наиболее распространенное применение Ethereum до сих пор, исходя из подавляющего преимущества, заключалось в том, чтобы проводить продажи токенов для различных проектов.

“Смарт транзакции” платформы Ardor

Если этот список применений кажется знакомым, это может быть потому, что все, кроме одного, уже были реализованы в Nxt и Ardor как уже готовые «смарт транзакции». Смарт-транзакции Nxt (предшественник первоначальной платформы Ardor) - это биты функциональности «blockchain 2.0», которые разработчики Nxt и Ardor сделали доступными как часть самого протокола. Они позволяют разработчикам создавать блокчейн приложения без необходимости писать и тестировать свои собственные смарт контракты.

Для того, чтобы обычные пользователи (т. е. не-разработчики) могли также воспользоваться этой функциональностью, официальные кошельки Nxt и Ardor включают в себя несколько функций, созданных в результате смарт транзакций. К ним относятся:

Биржа активов ( Asset Exchange), где пользователи могут выпускать активы, торговать ими и выплачивать дивиденды держателям активов;
Денежная система ( Monetary System), в которой пользователи могут выпускать валюты и проводить различные виды краудфандинговых кампаний;
система обмена сообщениями ( messaging system), которая позволяет пользователям отправлять друг другу текстовые или зашифрованные сообщения;
система голосования ( voting system), которая позволяет пользователям проводить голосование исходя из аккаунта, баланса аккаунта, баланса активов или валютного баланса;
встроенная система перетасовки монет ( coin shuffler), которая может предоставить пользователям степень конфиденциальности, скрывая их истории транзакций;
децентрализованное хранилище данных ( data store), которое может непрерывно записывать хеш файла на блокчейн и, при необходимости, постоянно записывать сам файл, применяя специальные архивные ноды;
децентрализованная торговля ( decentralized marketplace), где пользователи могут покупать и продавать товары и услуги в пиринговых сетях;
новая Монетная Биржа (только для Ardor), где пользователи могут продавать монеты дочерней цепи напрямую друг другу; а также,
ряд дополнительных функций, таких как фазированные транзакции ( phased transactions), которые позволяют пользователям устанавливать ограничения на то, когда и каким образом выполняются другие транзакции, и свойства аккаунтов, которые могут использоваться для связывания случайных данных с аккаунтом.

Разумеется, это не единственные приложения, которые могут быть созданы с применением смарт транзакций, но они иллюстрируют степень того, что может быть достигнуто с их помощью. Все эти функции, а также еще несколько, будут доступны в Ignis, первой дочерней цепочки Ardor. У создателей других дочерних цепочек будет возможность реализовать как можно больше этих функций в соответствии с их проектами.

Я слышал о нескольких аналогиях для описания смарт-транзакций, но моим фаворитом является то, что они похожи на Legos, в то время как смарт-контракты похожи на clay: первые не обеспечивают такой же контроль над более тонкими деталями, но они быстрее и проще в использовании, чем последние, и их можно объединить, чтобы сформировать некоторые весьма впечатляющие конечные продукты.

Конечно, аналогия не идеальна. Сильный аргумент в пользу смарт контрактов заключается в том, что потенциально все цепочки бизнес - логики децентрализованного приложения (Dapp) можно записывать постоянно и неизменно на блокчейн, тогда как Dapp, построенный на основе комбинаций из смарт - транзакций, вероятно, включает некоторый внешний код. В последнем случае использование Dapp может потребовать некоторой степени уверенности в том, что разработчик не поменяет правила в более поздних версиях.

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

Меры предосторожности

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

К сожалению, катастрофические неудачи с использованием некачественных смарт-контрактов не являются редкостью. Хакерская атака, которая заморозила 100 миллионов долларов, хранящихся в кошельках Parity с использованием мультиподписей, и атака того же кошелька на сумму 30 миллионов долларов за несколько месяцев до этого, являются самыми свежими примерами, которые оказались в центре внимания, но они не являются первыми и почти наверняка последними. Для обзора некоторых распространенных уязвимых моментов и анализа нескольких реальных атак, в том числе печально известного взлома DAO, я настоятельно рекомендую этот отличный документ, написанный тремя исследователями из Университета Кальяри.

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

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

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

К счастью, есть определенные способы смягчить риск написания уязвимых смарт контрактов. Например, можно разработать смарт контракт, которым можно обновлять, делегируя ответственность второму контракту, обычно называемому «договор библиотеки», по адресу, который может быть изменен, чтобы позже указать на другой контракт библиотеки.

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

Другим очень перспективным подходом для обеспечения безопасности смарт контрактов является использование методов формальной проверки, заимствованных из математики. Я не очень разбираюсь в формальных методах, поэтому, пожалуйста, не воспринимайте слишком серьезно то, что я напишу здесь, но я знаю, что это проще всего выполнить (если это действительно выполнимо) с простыми программами, правильное функционирование которых может быть выражено как набор коротких, простых правил. В таких случаях можно с уверенностью утверждать, что программа не содержит ошибок. Даже простые методы, такие как циклизация и рекурсия, могут значительно усложнить анализ, поэтому лучше всего, чтобы тестируемая программа была как можно более простой.

Почему я так много говорю по этому поводу? Объединив эти все эти мысли, казалось бы, что лучший способ написания смарт контрактов может включать в себя: 1) сделать их как можно короче и максимально простыми; 2) делегировать основной бизнес-логики библиотечным контрактам, которые можно обновлять в случае необходимости; и 3) повторное использование библиотек, которые были тщательно проверены, чтобы свести к минимуму количество нового кода. Если второй из этих пунктов требует, чтобы пользователи в какой-то степени доверяли автору контракта, то, как это часто бывает, контракты, разработанные в соответствии с этими тремя принципами, начинают во многом напоминать смарт транзакции Ardor: бит стабильного, тщательно протестированного кода, который раскрывает наиболее часто используемые функции, которые разработчики могут компоновать в более сложные программы.

Выбор между Безопасностью и Гибкостью

Я не предполагаю, что смарт транзакции Ardor могут выполнить все, что могут сделать смарт контракты Ethereum, и я даже не могу утверждать, что комбинации смарт-транзакций всегда могут подражать смарт-контрактам. Я, однако, считаю, что существует естественная противоречие между гибкостью, которую предлагает платформа, и безопасностью кода, который разработчики неизбежно пишут для платформы.

С этой точки зрения, блокчейны платформы могут быть расположены на континууме гибкости и безопасности. Bitcoin связан с экстремумом «безопасности», язык скриптов которого преднамеренно ограничен, чтобы не допустить, чтобы пользователи блокировали свои монеты с уязвимыми сценариями (хотя это все еще возможно, конечно). Nxt и Ardor занимают позицию где-то ближе к середине спектра, ограничивая разработчиков набором предопределенных типов транзакций, но включая много функциональности в этих типах.

С другой стороны, смарт-контракты Ethereum занимают весь спектр. На Ethereum можно писать чрезвычайно простые, тривиально безопасные скрипты, а также можно писать более сложные скрипты, содержащие незначительные уязвимые моменты. Возможно, так же важно, чтобы пользователям было трудно различать эти случаи - и неразумно, в любом случае, ожидать, что они попытаются использовать их. Безопасное использование Ethereum означает, что вы избегаете конечной степени «гибкости», даже если это связано с тем, что вы получаете некоторое доверие между пользователями и разработчиками.

Наконец, стоит упомянуть, что Ardor предлагает новую функцию, ранее не доступную в Nxt, которая помогает ей приблизиться к конечной степени «гибкости» континуума: возможность комбинировать условия фазирования с использованием операторов Boolean AND, OR и NOT для достижения инстинктивного поведение, основанного на использовании смарт-контрактов.

Вкратце, фазированные транзакции позволяют пользователям определять базовую транзакцию на каком-либо событии, например, одобрение определенного количества конкретных аккаунтов (мультиподпись), голосование в зависимости от количества определенных активов на аккаунте, истечения определенного количества времени (timelock), или раскрытия ключа (например, hashlock). В Ardor комбинации этих типов фазирования могут кодировать более сложные условия, такие как «транзакция X действительна, если большинство держателей активов корпорации ABC одобряют ее в дату Y, если только на неё не наложено вето большинством голосов членов совета директоров ABC ".

Несомненно, можно объединить условия фазирования таким образом, чтобы можно было ожидать неожиданных результатов, возможно, включая кражу или потерю средств. Но преимущество перед смарт-контрактами в плане безопасности по-прежнему существует, я бы сказал, поскольку разработчики могут сосредоточиться на том, чтобы бизнес-логика транзакции была надежной, не беспокоясь о низкоуровневых ошибках в состоянии гонки. И, конечно же, недостаток, предлагающий меньшую гибкость, чем смарт-контракт, по-прежнему существует.

Заключение

Благодаря протоколу, определенному набором предварительно готовых смарт-транзакций вместо низкоуровневого языка сценариев, Ardor, вероятно, никогда не сможет предложить разработчикам широкий спектр возможностей, таких как на платформе Ethereum, по крайней мере, в тех случаях, когда все должно быть сделано в режиме on-chain для минимального доверия между сторонами. С другой стороны, при написании нетривиальных контрактов, которые следуют рекомендациям по безопасности, вполне может потребоваться дополнительное доверие между пользователями и разработчиками. И, конечно же, пользователи Ethereum в конечном итоге должны доверять авторам смарт контрактов, чтобы не совершать ошибок и тщательно изучить и протестировать их код, чтобы убедиться в этом.

Естественно, вы можете сказать то же самое и о любом программном обеспечении, в том числе о смарт-транзакциях Ardor, но есть ключевое различие: на Ethereum работает намного больше кода. Платформа Nxt была с открытым исходным кодом с момента её создания, предоставляя широкие возможности для экспертной оценки, и скоро будет открыт код Ardour, который основывается на кодовой базе Nxt. Более того, каждое новое изменение протокола было тщательно проверено в публичной тестовой сети до официального выпуска. То же самое должно быть справедливо в отношении каждого смарт контракта, но при написании большого количества кода кажется, что неизбежно появляется больше возможностей для ошибок, которые могут возникнуть в процессе производства.

В любом случае, я подозреваю, что степень, в которой наиболее успешные Dapps будут полагаться на неизменяемый код, остается открытым вопросом. Если доступ к неизменяемой базе данных и несколько простых операций над этими данными достаточны для большинства приложений, то смарт транзакции Ardor кажутся мне очевидным преимуществом по сравнению со смарт-контрактами. Если, напротив, понятие о том, что «код есть закон» оказывается существенным для жизнеспособности большинства Dapps, каждый Dapp требует, чтобы большая часть его уникального кода была записана на блокчейне, становясь беззащитным, то тогда подход Ethereum вероятно, лучше.

Я ожидаю, что будут реальные приложения, которые подходят для каждой платформы. Но я также задаюсь вопросом, станет ли в конечном итоге ясно, какой из двух подходов лучше всего справляется со значительным большинством приложений. Какой подход в конечном итоге «выиграет» мне не совсем понятно, но я подозреваю, что решающим фактором будут суждения пользователей о степени доверия, которое требует каждый случай. И поскольку вся привлекательность блокчейн технологии заключается в том, что она позволяет пользователям осуществлять транзакцию с минимальным доверием, я бы сказал, что результат будет вполне соответствующим.

Спасибо за прочтение! Если вам понравилась эта статья, не забудьте прочитать следующую часть серий статей, в которой сравниваются способы, которыми Ardor и Ethereum справляются с раздуванием блокчейн.

Перевод статьи с английского, источник https://www.nxter.org/ardor-vs-competition-pt-7-ethereum-smart-contracts/