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

ПРОЧИЕ ИДЕИ И РАЗМЫШЛЕНИЯ

Введение модифицированного GHOST

Протокол GHOST (greedy heaviest оbserved subtree, «протокол с поглощением наиболее тяжелой ветви») был предложен Йонатаном Сомполински и Авивом Зохаром в декабре 2013 года. Его необходимость связана с недостаточной защитой блокчейнов с быстрым временем подтверждения транзакции из-за высокого уровня «залежалости» блоков, связанной с тем, что для распространения по сети им нужно некоторое время. Допустим, если майнер А находит блок, а затем майнер B находит другой блок с таким же порядковым номером до того, как до него дойдет информация о находке майнера A, блок майнера B остается ненужным и не поможет обезопасить сеть. Также существует проблема централизации: если A – майнинг-пул с 30 % мощности всей сети, а у B только 10 % мощности всей сети, A рискует найти залежалый блок с вероятностью 70 % (поскольку в остальных 30 % случаев A будет находить последний блок и тут же получать данные о майнинге), а у B этот риск возрастает уже до 90 %. Таким образом, если интервал между блоками достаточно короткий, залежалых блоков будет много и майнер А будет успешнее просто благодаря своим размерам. При сочетании этих двух эффектов в блокчейнах, быстро производящих блоки, с большой вероятностью один майнинг-пул, обладающий достаточно большим процентом хеш-мощности сети, де-факто захватит контроль над процессом майнинга.

Как описали Сомполински и Зохар, GHOST решает первую проблему – потерю безопасности сети – включением залежалых блоков в вычисление, определяющее, какая цепочка самая «длинная»: в расчет идут не только родительский блок и дальнейшие предки блока, но и залежалые потомки предка блока (на жаргоне Ethereum – анклы, то есть «дяди»). Все вместе они участвуют в вычислении того, за каким блоком стоит большее значение proof of work. Чтобы решить вторую проблему и предотвратить централизацию, мы выйдем за рамки протокола Сомполински и Зохара и введем выплаты за залежалые блоки: такой блок получит 87,5 % от того, что получил бы, если бы попал в блокчейн, а «племянник», включающий залежалый блок, получит 12,5 %. Однако комиссии за транзакцию анклы не получат.

Ethereum реализует упрощенную версию GHOST, которая опускается всего на семь уровней. Она работает следующим образом.

◊ В блоке должен быть указан родитель, а также 0 или более анклов.

◊ Анкл, включенный в блок B, должен обладать следующими свойствами:

◊ он должен быть прямым потомком предка k-го поколения B, где 2 <= k <= 7;

◊ это не может быть предок B;

◊ анкл должен быть валидным заголовком блока, но не обязательно должен быть ранее верифицированным или даже валидным блоком;

◊ анкл должен отличаться от всех анклов, включенных в предыдущие блоки, и всех анклов, включенных в тот же блок (двойное включение невозможно).

◊ За каждого анкла U в блоке B майнер блока B получает дополнительные 3,125 % к своему coinbase-вознаграждению, а майнер блока U получает 93,75 % от стандартного coinbase-вознаграждения.

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

Комиссии

Поскольку участники сети загружают транзакции в блокчейн и проверяют валидность каждой из них, необходим некий регуляторный механизм, и обычно это – комиссии. По стандарту, который когда-то задал Bitcoin, выбор размера комиссии остается за отправителем. Предполагается, что минимальные значения будут устанавливаться динамически за счет решений майнеров. Bitcoin-сообщество широко одобрило такой подход как «рыночный», где стоимость определяется спросом и предложением. Но важно понимать, что проведение транзакций – не рынок, как бы ни хотелось видеть в майнере продавца, предоставляющего отправителю услугу за определенную плату. В реальности каждая транзакция, включенная майнером в блок, должна быть проведена всеми нодами сети, так что по большей части транзакцию осуществляет третья сторона, а не майнер. Здесь возникает риск трагедии общих ресурсов.

Однако при некоторых небрежных упрощениях этот недостаток удивительным образом самоустраняется. Происходит это следующим образом. Предположим, что…

1. Транзакция состоит из k операций и предлагает майнеру, который включит ее в блокчейн, комиссию kR, где R задается отправителем. Майнер заранее примерно представляет, какими будут R и k.

2. Себестоимость проведения операций для каждой ноды равна C (то есть все ноды одинаково эффективны).

3. Есть N майнящих нод c одинаковыми вычислительными мощностями (то есть одна нода – это 1 / N от всей мощности).

4. Нет полных нод, которые не задействованы в майнинге.

Майнер захочет включить в блок только те транзакции, комиссия с которых превысит себестоимость их проведения. Таким образом, предполагаемое вознаграждение составит kR / N, поскольку вероятность нахождения блока для майнера будет равняться 1 / N, а себестоимость проведения транзакции – kC. Следовательно, майнеры будут включать в блок такие транзакции, для которых kR / N > kC или же R > NC. Заметим, что R – устанавливаемая отправителем комиссия за одну операцию транзакции, так что это нижняя граница выгоды, которую он получит от этой транзакции, а NC – себестоимость проведения операции для всей сети. Соответственно, майнерам выгодно включать в блок только такие транзакции, где общая утилитарная выгода превышает себестоимость.

Однако у этой модели есть серьезные расхождения с реальностью.

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

2. Существуют полные ноды, которые не занимаются майнингом.

3. На практике вычислительные мощности майнеров могут распределяться крайне неравномерно.

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

По первой причине майнерам выгоднее включать в блок поменьше транзакций, а вторая причина увеличивает NC, так что эти два действия хотя бы частично уравновешивают друг друга. Как именно? Пункты 3 и 4 представляют большую проблему, и для ее устранения мы просто вводим плавающий лимит: ни один блок не может иметь больше операций, чем BLK_LIMIT_FACTOR, умноженный на долгосрочное экспоненциально изменяющееся среднее значение. Вот как это выглядит:

blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR – 1) +

floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR и EMA_FACTOR – константы, на данный момент составляющие 65 536 и 1,5 соответственно, но эти значения, скорее всего, изменятся после более глубокого анализа.

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

Вычисление и полнота по Тьюрингу

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

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

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

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

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

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

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

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