Глава 19

Выбор хронологии транзакций

Пусть компьютеры голосуют своими ногами

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

Метафора

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

Цель

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

Главная задача

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

Идея

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

Примечание

Консенсус – это синоним соглашения между независимыми отдельными лицами. Распределенный консенсус – это соглашение между членами полностью распределенной пиринговой системы.

Ситуации, в которых большая группа независимо действующих отдельных лиц решает общую задачу, можно охарактеризовать с помощью следующих условий [14]:

1. Группа отдельных лиц действует в одинаковой среде.

2. Существует задача, требующая принятия коллективного решения.

3. Все отдельные лица независимо друг от друга стремятся достичь единой цели.

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

5. Отдельные лица используют одинаковые критерии для оценки поставленной задачи и процесса ее решения на основе изменения текущей среды.

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

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

2. Задача, требующая решения, – это коллективный выбор единой хронологии транзакций.

3. Все узлы стремятся увеличить до максимума свой индивидуальный доход, полученный как поощрение за добавление новых корректных блоков в структуру данных блокчейна.

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

Здесь пропущен пятый пункт: критерий, который все узлы используют для принятия решения на основе изменения среды. Процесс выбора хронологии данных транзакций основан на том, как новые блоки добавляются в структуру данных блокчейна и как данные защищаются от изменений. Благодаря процедуре подтверждения выполненной работы добавление нового блока связано со значительными издержками на вычисления, а попытки изменить хронологию транзакций приводят к еще большим накладным расходам на вычисления. Таким образом, объем суммарных вычислительных затрат на создание хронологии данных выглядит вполне естественным критерием для выбора правильной хронологии в том случае, когда существует несколько конфликтующих версий. Если все узлы системы применяют одинаковый критерий для выбора хронологии транзакций, то все узлы в итоге приходят к соглашению по единой одинаковой для всех версии хронологии. Совместно выбранную версию хронологии транзакций часто называют заслуживающей доверия цепочкой или хронологией (authoritative chain or history).

Как это работает

Идея выбора хронологии транзакций по объему вычислительных затрат на ее создание приводит к следующим двум критериям:

• критерий самой длинной цепочки (longest-chain-criterion) [26];

• критерий самой затратной цепочки (heaviest-chain-criterion) [39, 27].

Критерий самой длинной цепочки

Критерий самой длинной цепочки (longest-chain-criterion) основан на предположении, что структура данных блокчейна, состоящая из наибольшего количества блоков, представляет максимальный суммарный объем вычислений. Чтобы лучше понять этот критерий, рассмотрим исходную ситуацию, в которой все узлы распределенной системы поддерживают и согласовывают одинаковую версию структуры данных блокчейна, как показано на рис. 19.1, где схематически изображена структура данных блокчейна, для упрощения показанная без большинства подробностей. Каждый прямоугольник представляет один блок, идентифицируемый по укороченному хэш-значению. Стрелка, направленная от одного прямоугольника к другому, обозначает хэш-ссылку, связывающую заголовок блока с предшествующим заголовком. В этой исходной ситуации все узлы согласны с единой хронологией данных транзакций и стараются увеличить существующую цепочку на один блок, который ссылается на блок A397 как на предшествующий.

Рис. 19.1 Исходная структура данных блокчейна в распределенной системе

Создание нового блока – это состязание между всеми узлами, потому что этот процесс требует решения специальной хэш-головоломки для этого блока. На рис. 19.2 показана структура данных блокчейна, которую поддерживает большинство узлов, после того как один узел решил хэш-головоломку нового блока и разослал его всем партнерам. В результате те узлы, которые поддерживают структуру данных блокчейна в виде, показанном на рис. 19.2, стараются расширить ее с помощью нового блока, ссылающегося на блок AB12 как на предшествующий. С точки зрения большинства существует только одна версия структуры данных блокчейна, состоящая из трех блоков. Но рассылка нового блока по сети требует времени, и с этим сталкиваются все типы конкурентов. Из-за задержки при передаче сообщений некоторые узлы (они в меньшинстве) еще не получили блока AB12. Поэтому они продолжают попытки наращивания цепочки, изображенной на рис. 19.1. В конце концов, один из этих узлов успешно решает хэш-головоломку для нового блока, получает хэш-значение DD01 и передает блок партнерам. Таким образом, большинство узлов получает и блок AB12, и блок DD01. В итоге большинство узлов поддерживает структуру данных блокчейна, показанную на рис. 19.3, в которой имеются две ветви на вершине общего ствола. В этой ситуации критерий самой длинной цепочки не позволяет получить недвусмысленный результат, так как обе цепочки (AB12 → A397 → 33FF и DD01 → A397 → 33FF) имеют одинаковую длину.

Рис. 19.2 Результат добавления нового блока в существующую структуру данных блокчейна

В ситуации, показанной на рис. 19.3, узлам предоставлена свобода выбора ветви, по которой произойдет наращивание цепочки.

Рис. 19.3 Структура данных блокчейна после доставки «опоздавшего» блока

Некоторые узлы могут продолжать попытки поиска нового блока, ссылающегося на блок AB12 как на предшествующий, в то время как другие узлы пытаются найти новый блок, ссылающийся на блок DD01 как на предшествующий. Неожиданно большинство блоков получает два новых блока BB11 и CCC1, и оба этих блока ссылаются на AB12 как на предшествующий блок. Это может произойти из-за того, что два узла завершили процедуру подтверждения выполненной работы для своих блоков приблизительно в одно и то же время. Включение этих двух новых блоков в структуру данных блокчейна приводит к тому, что структура содержит три цепочки (ветви цепочки), как показано на рис. 19.4. Одна цепочка состоит из трех блоков, две другие – из четырех.

По критерию самой длинной цепочки несомненно удаляется самая короткая цепочка, то есть DD01 → A397 → 33FF. Но этот критерий не дает окончательного недвусмысленного результата, поскольку остаются две цепочки одинаковой длины. И снова некоторые узлы пытаются найти новый блок, который ссылается на BB11 как на предшествующий блок, тогда как другие узлы стремятся найти новый блок, ссылающийся на предшествующий блок CCC1.

Рано или поздно приходит блок, ссылающийся на BB11 как на предшествующий блок, и структура данных принимает вид, показанный на рис. 19.5. В структуре данных блокчейна на рис. 19.5 содержится несколько конфликтующих версий хронологии транзакций, но критерий самой длинной цепочки позволяет получить единственный недвусмысленный результат, а именно цепочку, состоящую из блоков 0101 → BB11 → AB12 → A397 → 33FF. Большинство узлов, а в конечном итоге и все узлы системы, будет стараться расширить именно эту ветвь и искать новый блок, который ссылается на блок 0101 как на предшествующий.

Рис. 19.4 Структура данных блокчейна, после того как два узла почти одновременно завершили процедуру подтверждения выполненной работы

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

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

Примечание

По внешней форме структуру данных блокчейна часто называют древовидной структурой данных. Самый первый, следовательно, самый старый блок в этой структуре – это единственный блок, который не имеет предшественников, поэтому его часто называют корнем древовидной структуры данных. Блок, не имеющий последующих блоков, называют листом (leaf). Упорядоченная последовательность блоков от корня к листу называется путем (path).

Критерий самой затратной цепочки

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

Для каждого пути фактические затраты на вычисления могут быть измерены посредством суммирования уровней сложности для всех блоков, принадлежащих конкретному пути. Это значение можно вычислить, воспользовавшись тем, что заголовок блока содержит уровень сложности соответствующей хэш-головоломки. Суммарный уровень сложности пути часто называют его весом (weight). На рис. 19.6 изображена та же структура данных блокчейна, что и на рис. 19.5, но здесь также показаны значения уровней сложности для каждого блока структуры. Самая длинная цепочка (путь от корня 33FF до листа 0101) имеет вес 5, в то время как вторая по длине цепочка (путь от корня 33FF до листа CCC1) имеет вес 6. Таким образом, структура данных блокчейна на рис. 19.6 отображает ситуацию, когда критерий самой длинной цепочки заставляет узлы выбрать цепочку, затраты на вычисления которой не являются максимальными.

В итоге блокчейн-системы, динамически определяющие уровни сложности, не применяют критерия самой длинной цепочки. Вместо этого они используют критерий самой затратной цепочки (heaviest-chain-criterion): выбирается та хронология данных транзакций, которая характеризуется наивысшим суммарным уровнем вычислительных затрат в цепочке. В том случае, когда уровень сложности одинаков для всех блоков, самый длинный путь совпадает с самым затратным путем, поэтому оба критерия дают одинаковый результат.

Рис. 19.6 Схема структуры данных блокчейна с указанием уровней сложности для блоков

Следствия выбора единственной цепочки

Следствия выбора конкретной цепочки из нескольких конфликтующих версий и утверждения ее в качестве единственной корректной цепочки перечислены ниже:

• появление блоков-«сирот»;

• отмена поощрений;

• уточнение права владения;

• повторная обработка транзакций;

• увеличение размера общего ствола;

• сохранение общей целостности;

• устойчивость против сторонних манипуляций.

Блоки-«сироты»

Структура данных блокчейна, наращиваемая коллективными усилиями, выглядит как дерево, ветви которого представляют конфликтующие версии хронологии транзакций. Применение какого-либо критерия выбора в действительности означает выбор одного пути в этом дереве и объявление его единственной корректной версией хронологии данных транзакций. Все блоки в древовидной структуре данных, которые не являются частью корректного пути, отбрасываются узлами и называются блоками-сиротами [27]. Например, в результате применения критерия самой длинной цепочки в ситуации, изображенной на рис. 19.4, блок DD01 становится блоком-сиротой, а в схеме на рис. 19.5 блоки DD01 и CCC1 не являются частью самой длинной цепочки и отбрасываются. После применения критерия самой затратной цепочки в ситуации на рис. 19.6 блоки 0101, BB11 и DD01 не принадлежат выбранной корректной цепочке, следовательно, исключаются из работы.

Отмена поощрений

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

Уточнение права владения

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

Повторная обработка транзакций

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

Увеличение размера общего ствола

Применение какого-либо критерия выбора не всегда дает недвусмысленный результат. Например, в ситуациях, подобных показанным на рис. 19.3 и 19.4, имеется более одной самой длинной цепочки. Здесь структура данных блокчейна содержит два пути одинаковой длины, ответвляющихся от общего ствола. На рис. 19.3 общий ствол состоит только из двух блоков, образующих короткую цепочку A397 → 33FF. На рис. 19.4 общий ствол включает уже три блока, то есть цепочку AB12 → A397 → 33FF, в которую включен общий ствол из предыдущего состояния. Таким образом, даже если критерий выбора дает неоднозначный результат, конфликтующие версии хронологии транзакций «вырастают» из менее двусмысленного общего ствола. Чем глубже вы исследуете ствол блокчейн-системы, тем менее спорными выглядят решения о принятии или непринятии того или иного блока как части самой длинной цепочки.

Сохранение общей целостности

Рассмотрим ситуацию на рис. 19.4, где критерий самой длинной цепочки не дает недвусмысленного результата. На рис. 19.5 можно видеть, что следующий блок, добавляемый в структуру данных блокчейна, определяет, станет ли блок BB11 или CCC1 частью самой длинной цепочки или будет отброшен. Но кто принимает решение о том, что следующий блок, добавляемый в структуру, показанную на рис. 19.4, ссылается именно на блок BB11 как на предшествующий, следовательно, исключает блок CCC1? Неожиданный и, возможно, разочаровывающий ответ: это абсолютно случайный выбор. В ситуации на рис. 19.4 узлам предоставляется полная свобода выбора наращиваемой ветви. Некоторые узлы попытаются найти новый блок, ссылающийся на BB11 как на предшествующий блок, другие узлы стараются создать новый блок со ссылкой на предшествующий блок CCC1. Кто из них первым найдет новый блок, зависит от решения хэш-головоломки, требующего конечного, но неопределенного интервала времени. Узел, первым решивший хэш-головоломку нового блока, определяет, какая из конфликтующих ветвей будет наращиваться и какие блоки будут исключены. Таким образом, для процесса роста древовидной структуры данных блокчейна характерно случайное поведение, определяемое состязанием в скорости решения хэш-головоломок и непредсказуемыми перемещениями сообщений, передаваемых по сети. Следующий блок, время появления которого зависит от случайного интервала времени, необходимого для решения соответствующей хэш-головоломки, определяет, какой путь будет увеличен и какой блок будет исключен.

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

• тем раньше по времени он добавлен;

• тем больше времени прошло с момента его включения в структуру данных блокчейна;

• тем больше суммарных усилий было затрачено на добавление последующих блоков;

• тем меньше он подвержен воздействию случайных изменений в блоках, принадлежащих самой длинной цепочке;

• тем меньше вероятность его удаления;

• тем больше обосновано его включение в структуру узлами системы;

• тем более прочно он закреплен в общей хронологии узлов.

Тот факт, что достоверность, связанная с включением блоков в утвержденную корректную цепочку, зависит от прошедшего времени и от количества блоков, добавленных на текущий момент, называется сохранением общей целостности (eventually consistency).

Устойчивость против сторонних манипуляций

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

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

Опасности для схемы голосования

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

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

Примечание

Атака 51 процента – это попытка собрать или установить контроль над большинством голосов в процессе коллективного принятия решений.

Важная роль хэш-головоломок

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

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

Почему это работает

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

Перспектива

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

Резюме

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

• Выбор правильной версии хронологии транзакций – это задача коллективного принятия решения.

• Распределенное согласование – это соглашение между членами полностью распределенной пиринговой системы в процессе коллективного принятия решения поставленной задачи.

• Процесс коллективного принятия решения в блокчейн-системе обладает следующими характеристиками:

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

– задача, требующая решения, – это коллективный выбор единой хронологии транзакций всеми узлами;

– все узлы стремятся увеличить до максимума свой индивидуальный доход, полученный как поощрение за добавление новых корректных блоков в структуру данных блокчейна;

– чтобы достичь своих целей, узлы посылают новые блоки всем партнерам для проверки и приема. В результате каждый узел оставляет индивидуальные отпечатки в среде, которые совместно обслуживают структуру данных блокчейна;

– все узлы применяют одинаковый критерий для выбора хронологии транзакций;

– в соответствии с критерием самой длинной цепочки каждый узел независимо выбирает в древовидной структуре данных блокчейна путь, который содержит наибольшее количество блоков;

– в соответствии с критерием самой затратной цепочки каждый узел независимо выбирает в древовидной структуре данных блокчейна путь с максимальным суммарным значением сложности.

• Выбор одного пути в древовидной структуре данных блокчейна приводит к перечисленным ниже последствиям:

– появление блоков-«сирот»;

– отмена поощрений;

– уточнение права владения;

– повторная обработка транзакций;

– увеличение размера общего ствола;

– сохранение общей целостности;

– устойчивость против сторонних манипуляций.

• Чем глубже в утвержденной корректной цепочке расположен блок:

– тем раньше по времени он добавлен;

– тем больше времени прошло с момента его включения в структуру данных блокчейна;

– тем больше суммарных усилий было затрачено на добавление последующих блоков;

– тем меньше он подвержен воздействию случайных изменений в блоках, принадлежащих самой длинной цепочке;

– тем меньше вероятность его удаления;

– тем больше обосновано его включение в структуру узлами системы;

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

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

• Атака 51 процента обладает следующими характерными особенностями:

– с экономической точки зрения: изменение распределения прав владения посредством изменения общей хронологии данных транзакций;

– с точки зрения принятия решений: получение большинства голосов для навязываемого получения желаемого результата;

– с технической точки зрения: нарушение целостности системы;

– с архитектурной точки зрения: установка, по меньшей мере временная, скрытого элемента централизации, который изменяет состояние системы.