◊ Злоумышленник видит контракт наподобие 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 вычислительных шагов. Майнеры могли бы пресекать такие логические «бомбы», устанавливая максимально допустимое число вычислительных шагов для каждого контракта и считая шаги в том числе при выполнении одного контракта внутри другого. Но для этого майнерам пришлось бы запретить контракты, создающие другие контракты (поскольку создание и выполнение всех двадцати шести упомянутых контрактов можно было бы легко объединить в один контракт). Еще одна проблема кроется в том, что поле с адресом в сообщении – переменная, так что в целом нельзя предсказать, какие другие контракты будет вызывать данный контракт. Так мы приходим к удивительному заключению: полный по Тьюрингу язык неожиданно прост в использовании, а с его отсутствием все так же неожиданно становится сложнее, если не установить точно такие же элементы управления. Так почему бы просто не сделать протокол полным по Тьюрингу?

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

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

◊ 1: вей;

◊ 1012: сабо;

◊ 1015: финни;

◊ 1018: эфир.

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

Модель выпуска будет такой.

◊ Эфир будет выставлен на продажу по цене 1000–2000 единиц эфира за 1 BTC – эти средства пойдут на финансирование Ethereum и дальнейших разработок Ethereum. Такая модель уже успешно себя показала в Mastercoin и NXT. Первые покупатели получат большие скидки. Биткойны, приобретенные с продажи, полностью пойдут на зарплаты и премии разработчикам, а также на инвестиции в различные коммерческие и некоммерческие проекты в экосистеме Ethereum.