пользователи парализовать майнеров и полные ноды, вводя их в бесконечный цикл? В программировании это известно как проблема остановки: невозможно определить, закончится ли когда-либо выполнение той или иной программы.
Как уже говорилось в разделе о состоянии перехода, мы решаем эту проблему требованием устанавливать для транзакции максимальное допустимое число шагов в вычислении, и, если этот лимит будет превышен, вычисление прервется, но комиссии по-прежнему будут выплачены. Это работает и с сообщениями. Чтобы пояснить причины такого решения, рассмотрим следующие примеры.
◊ Злоумышленник создает контракт с бесконечным циклом и затем пересылает майнеру транзакцию, активирующую этот контракт. Майнер, проводя транзакцию, попадает в бесконечный цикл и ждет, пока закончится газ, прикрепленный к этому контракту. И хотя с окончанием газа выполнение остановится на полпути, транзакция остается валидной и за каждый вычислительный шаг майнер будет взимать со злоумышленника комиссию.
◊ Злоумышленник создает цикл такой длины, чтобы за время, в течение которого майнер будет вычислять его до конца, было найдено еще несколько блоков и майнер не смог бы включить транзакцию в один из следующих блоков, чтобы получить комиссию. Однако злоумышленник должен будет задать значение 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 вычислительных шагов. Майнеры могли бы пресекать такие логические «бомбы», устанавливая максимально допустимое число вычислительных шагов для каждого контракта и считая шаги в том числе при выполнении одного контракта внутри другого. Но для этого майнерам пришлось бы запретить контракты, создающие другие контракты (поскольку создание и выполнение всех двадцати шести упомянутых контрактов можно было бы легко объединить в один контракт). Еще одна проблема кроется в том, что поле с адресом в сообщении – переменная, так что в целом нельзя предсказать, какие другие контракты будет вызывать данный контракт. Так мы приходим к удивительному заключению: полный по Тьюрингу язык неожиданно прост в использовании, а с его отсутствием все так же неожиданно становится сложнее, если не установить точно такие же элементы управления. Так почему бы просто не сделать протокол полным по Тьюрингу?
Валюта и выпуск
В сеть Ethereum встроена собственная валюта – эфир. Она была введена с двумя целями: обеспечить достаточный уровень ликвидности для эффективного обмена цифровыми активами и, что еще более важно, создать механизм оплаты комиссий за транзакции. Для удобства и во избежание будущих споров и дискуссий (как это сейчас происходит вокруг mBTC, uBTC и сатоши в биткойне) мы предварительно обозначили номиналы:
◊ 1: вей;
◊ 1012: сабо;
◊ 1015: финни;
◊ 1018: эфир.
Это своего рода расширенная версия «долларов» и «центов» или «биткойна» и «сатоши». Мы ожидаем, что «эфир» будет использоваться для обычных транзакций, «финни» – для микротранзакций, «сабо» и «вей» – для технических дискуссий о комиссиях и протоколе. Оставшиеся номиналы могут понадобиться позже, и пока их не стоит включать в клиент.
Модель выпуска будет такой.
◊ Эфир будет выставлен на продажу по цене 1000–2000 единиц эфира за 1 BTC – эти средства пойдут на финансирование Ethereum и дальнейших разработок Ethereum. Такая модель уже успешно себя показала в Mastercoin и NXT. Первые покупатели получат большие скидки. Биткойны, приобретенные с продажи, полностью пойдут на зарплаты и премии разработчикам, а также на инвестиции в различные коммерческие и некоммерческие проекты в экосистеме Ethereum.
◊ 0,099x от общего количества проданного эфира (60, 102, 216 ETH) будут выделены организации для поощрения ранних участников и оплаты ETH-расходов перед созданием первичного блока.
◊ 0,099x от общего количества проданного эфира будет сохранено в качестве долгосрочного резерва.
◊ 0,26x от общего количества проданного эфира будет распределено между майнерами за год, и так будет всегда.
Несмотря на линейный во времени выпуск валюты, показатель роста количества валюты, как и у биткойна, со временем стремится к нулю
При создании этой модели мы приняли два важных решения: во-первых, о наличии и размере собственного фонда; во-вторых, о постоянно растущем линейном предложении, в отличие от ограниченного предложения в биткойне. Фонд мы считаем необходимым по следующей причине: если его не создать и уменьшить линейную эмиссию до 0,217x для сохранения того же процента инфляции, то общее количество эфира будет на 16,5 % меньше и каждая единица будет обладать на 19,8 % большей стоимостью. Следовательно, при продаже будет раскуплено на 19,8 % больше эфира, и каждая единица будет иметь абсолютно ту же стоимость, что и раньше. Организация при этом получит 1,198x BTC, которые разделятся на изначальные BTC и дополнительные 1,198x. Таким образом, ситуация с отсутствием фонда приводит в точности к тому же, что и ситуация с фондом, с одним лишь важным отличием: организация получит только BTC и будет уже не так заинтересована в росте ценности эфира.
Непрерывный линейный рост валюты уменьшает риск того, что некоторые считают чрезмерной централизацией активов в Bitcoin, а также обеспечивает будущим
