Больше денег: что такое Ethereum и как блокчейн меняет мир

Крайне важное свойство EVM – полнота по Тьюрингу, подразумевающая, что EVM-код может реализовать любое мыслимое вычисление, включая бесконечные циклы. Код EVM допускает два способа написать бесконечный цикл. Во-первых, можно использовать инструкцию JUMP, позволяющую отпрыгнуть в предыдущее место кода, а также инструкцию JUMPI для прыжка при выполнении некоторого условия, допускающую выражения вроде x < 27: x = x × 2. Во-вторых, контракты могут обращаться к другим контрактам, что потенциально может привести к зацикливанию через рекурсию. Здесь возникает закономерный вопрос: могут ли недобросовестные пользователи парализовать майнеров и полные ноды, вводя их в бесконечный цикл? В программировании это известно как проблема остановки: невозможно определить, закончится ли когда-либо выполнение той или иной программы.

Как уже говорилось в разделе о состоянии перехода, мы решаем эту проблему требованием устанавливать для транзакции максимальное допустимое число шагов в вычислении, и, если этот лимит будет превышен, вычисление прервется, но комиссии по-прежнему будут выплачены. Это работает и с сообщениями. Чтобы пояснить причины такого решения, рассмотрим следующие примеры.

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

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

◊ Злоумышленник видит контракт наподобие send(A,contract.storage[A]); contract.storage[A] = 0 и пересылает транзакцию с количеством газа, достаточным только для выполнения первого шага, но не для второго (то есть забирает деньги, но не позволяет балансу упасть до нуля). Автор контракта не должен волноваться о возможности таких атак, ведь если вычисление прерывается на полпути, произведенные изменения откатываются.

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

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

Также добавим, что отсутствие полноты по Тьюрингу – не такое уж сильное ограничение. Из всех рассмотренных нами примеров контрактов только один содержал цикл – и даже его можно было удалить, 26 раз повторив одну его строчку. Учитывая серьезность последствий полноты по Тьюрингу и ограниченность ее преимуществ, почему бы просто не использовать неполный по Тьюрингу язык? Дело в том, что в реальности отсутствие полноты по Тьюрингу не решает все эти проблемы. Рассмотрим следующий контракт:

C0: call(C1); call(C1);

C1: call(C2); call(C2);

C2: call(C3); call(C3);

…

C49: call(C50); call(C50);

C50: (запустить один шаг программы и записать изменения в хранилище)

Перешлем кому-нибудь транзакцию с таким контрактом. Для 51 транзакции нашему контракту понадобится 250 вычислительных шагов. Майнеры могли бы пресекать такие логические «бомбы», устанавливая максимально допустимое число вычислительных шагов для каждого контракта и считая шаги в том числе при выполнении одного контракта внутри другого. Но для этого майнерам пришлось бы запретить контракты, создающие другие контракты (поскольку создание и выполнение всех двадцати шести упомянутых контрактов можно было бы легко объединить в один контракт). Еще одна проблема кроется в том, что поле с адресом в сообщении – переменная, так что в целом нельзя предсказать, какие другие контракты будет вызывать данный контракт. Так мы приходим к удивительному заключению: полный по Тьюрингу язык неожиданно прост в использовании, а с его отсутствием все так же неожиданно становится сложнее, если не установить точно такие же элементы управления. Так почему бы просто не сделать протокол полным по Тьюрингу?

Валюта и выпуск