Текст книги "Блокчейн"

Теория игр и блокчейн

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

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

Эффективность стратегии неразрывно связана с понятием рационального поведения участников. Чтобы убедиться, что сотрудничество между участниками «игры» не всегда гарантировано, даже если это сообразуется с их общими интересами, рассмотрим известную «Дилемму заключенного». Она была представлена в 1950 году американскими математиками Мерилом Фладом и Мелвином Дрешером. В тюрьму почти одновременно и за одно и то же деяние попадают двое преступников. Небезосновательно предполагая возможный сговор между ними, полиция изолирует их друг от друга, а затем предлагает каждому одинаковые условия сотрудничества со следствием. Форма сотрудничества предполагает свидетельство одним заключенным против другого в обмен на немедленное освобождение. Также предполагается, что, если второй заключенный на сотрудничество с полицией не идет, он получает максимальный тюремный срок. В случае если оба отказываются сотрудничать, каждый получает минимальный срок. Если же имеет место взаимное обличение, то оба получают средний по длительности срок. Понятно, что, находясь в изоляции, заключенные не знают о решении друг друга. Какова же тогда в этом случае наиболее эффективная стратегия для каждого из заключенных?

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

Допустим, что в децентрализованной системе, хранящей цифровые активы, имеющие эквивалент денежной стоимости (например, криптовалюты), нашелся некий узел, который при помощи различных недобросовестных практик сумел навязать всей сети искусственную транзакцию, в результате которой стал обладателем огромного количества цифровых монет. Вопрос: кто выиграет от этой акции? Кто-то, возможно, подумает, что выигрывает злоумышленник, поскольку результатом его действий явилось прямое личное обогащение. Проиграли, безусловно, бывшие владельцы активов, которые потеряли их в результате атаки на сеть и на свои персональные счета. Остальные же участники системы не пострадали, оставшись при своих активах, до которых вредоносный узел не добрался. Однако это лишь поверхностные выводы. Своей атакой на сеть злоумышленник на самом деле совершил непоправимое – подорвал общее доверие к сети в целом. К ее концепции безопасности, криптографической неуязвимости, а также к протоколу формирования консенсуса. А это означает, что все ценностные активы, принадлежащие данной сети и имеющие монетарную или даже биржевую оценку, мгновенно утратят свою стоимость. Это касается в том числе и неправедно полученных активов самого злоумышленника. Что фактически превращает его действия из лично эффективных в общественно бесполезные. Сеть разрушается и прекращает свое существование. Победителей в данной ситуации нет, есть одни только проигравшие.

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

● Лояльные генералы, согласно приказу, вместе ведут свои армии в атаку на город – город взят, война выиграна. Очевидно, что это наилучший исход для Византии.

● Лояльные генералы, согласно приказу, одновременно отступают – город не взят, но все армии сохранены для будущих сражений. Данный исход можно считать промежуточным.

● Лояльные генералы атакуют, как и было приказано, однако генералы-предатели вместо атаки начинают отступать – в результате все армии уничтожены противником, а сама война Византией проиграна. Это наихудший из возможных вариантов.

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

Информация, которой обмениваются генералы, может носить различный характер. Это могут быть сведения о численности каждой из армий либо просто обозначение своего намерения – атаки или отступления. Важно то, что каждый из генералов (допустим, что их число равно n) передает всем остальным генералам свою информацию и получает от них назад n-1 наборов подобных же сведений. Но это еще не все. Получается, что каждый генерал обладает неким объемом информации, полученным от всех остальных генералов при прямом общении. И он может как ретранслировать полученную информацию всем генералам, так и получить себе подобные же наборы данных от других. То есть каждый генерал располагает не только той информацией, которую он получил напрямую от каждого из прочих генералов, но и имеет в распоряжении всю коммуникационную картину в формате «какой генерал какому генералу что сообщил». Однако мы должны принимать во внимание тот факт, что один или даже несколько генералов могут быть предателями и, соответственно, намеренно искажать передаваемую информацию. Тем не менее всегда есть возможность проверить, что каждый конкретный генерал сообщал другим генералам, и найти либо совпадения, либо расхождения в информации. На базе полученных данных можно выявить часть нелояльных генералов и оценить их долю в общей массе. Математически доказано, что в случае более 2/3 лояльных узлов система считается устойчивой и консенсус может быть достигнут. В противном случае система утрачивает работоспособность и как следствие доверие участников.

Принцип устойчивости к «византийской проблеме» – это классическая задача из «теории игр», которая является важным элементом безопасности при формировании консенсуса в блокчейн-проектах. Каждый узел в системе должен строго следовать ее правилам, прописанным в виде алгоритмической логики программного обеспечения узла. Однако почти все программное обеспечение в блокчейн-проектах поставляется в виде открытого кода, который каждый узел может при желании модифицировать таким образом, чтобы попытаться получить преференции, которые ему в обычной ситуации не полагались. Но даже если какие-то несанкционированные сетью изменения будут все же внесены отдельным узлом (или даже группой узлов), для успешности атаки необходимо, чтобы таких узлов было достаточно много. Иначе остальная сеть будет отвергать информацию от нарушителей, поскольку она не будет соответствовать общим правилам, которыми руководствуется большинство. В этом и состоит суть консенсуса, который применяется для управления в децентрализованных системах. Целостность системы нарушается, если количество «инакомыслящих» узлов начинает превышать критическую массу, после чего происходит разделение сети, которое называется «форк». Узлы, исповедующие разные правила консенсуса, образуют разные сети, которые с момента разделения начинают жить отдельной жизнью, становясь, по сути, различными проектами, хотя и со схожей технологией – по крайней мере, на первых порах. К понятию «форк» как важному явлению в блокчейн-индустрии мы еще вернемся.

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

Блоки и их структура

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

Идея хранить информацию в виде связных списков возникла достаточно давно – гораздо раньше, чем появились сами компьютерные технологии. А именно – более 4000 лет назад у индейской цивилизации инков и их предшественников примерно в III тысячелетии до нашей эры. Речь идет о способе сохранения информации в виде так называемых «кипу» – хитросплетений нитей, нанизанных на единую веревочную основу и связанных между собой в зависимости от контекста записываемой информации. Каждая нить могла иметь свой цветовой код, а также специальные узлы, форма и количество которых являлись важными маркерами, определяющими значения и типы хранимой информации. Прослеживая начало и конец каждой из нитей, можно было определить весь путь формирования цепочки данных – от базовой веревки и до окончания ответвления. Общее число нитей в одном кипу могло достигать 2500. При помощи кипу инки как правящий класс всего союза индейских племён Центральных Анд могли учитывать все необходимые подконтрольные им ресурсы – войска, запасы продовольствия, численность населения и объем взимаемых налогов.

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

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

Собственно, в своем классическом виде блокчейн представляет собой односвязный список, когда каждый следующий блок в системе ссылается на предыдущий. Вопрос в том, что значит «ссылается»: каким образом это технологически реализовано, а главное, зачем он вообще это делает? Ответ прост – для поддержания целостности базы данных. Блок состоит из двух основных частей – заголовка, содержащего служебную информацию, и списка транзакций для передачи цифровых активов между участниками системы или просто записи фактов. Все это – набор данных, который можно отобразить в виде хеша стандартной длины. Вычислив хеш данных заголовка, мы фиксируем состояние всего блока, и любое вмешательство в его целостность немедленно приведет к тотальному изменению общего хеша. А что, если каждый новый блок будет содержать хеш от данных предыдущего блока как один из элементов своего заголовка? Тогда получится, что, хешируя данные одного заголовка, мы автоматически включаем туда хеш заголовка предыдущего блока, и таким образом получается форма сцепления блоков. Нам известно, что любое малейшее изменение в прообразе меняет его хеш до неузнаваемости. Это означает, что если мы вмешаемся в любой бит данных любого из блоков в середине цепочки, это приведет к пересчету всех хешей последующих блоков. Другими словами, изменятся данные всей цепочки.

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

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

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

Важным элементом заголовка также является время создания блока. Оно записывается в виде числа, равного количеству секунд, прошедших с 1 января 1970 года – формат, принятый в многопользовательских и многозадачных операционных системах, таких, например, как Unix и совместимых с ней. Отдельно заметим, что число это достаточно велико, и через пару десятков лет должно произойти переполнение 32-битной ячейки памяти, обычно выделяемой для переменных, хранящих это значение в различном программном обеспечении. В случае если разработчики этих программ не внесут необходимые исправления, увеличив размер переменной, хранящей значения времени до 64 бит, то 19 января 2038 года по всему миру могут произойти массовые программные сбои. Произойдет это потому, что значения этого числа в силу специфики построения компьютерной архитектуры при выполнении программ будут интерпретироваться как имеющие отрицательные значения – со всеми вытекающими из этого алгоритмическими последствиями.

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

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

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