vlsergey Aug 20 2017 at 15:46

Blockchain

9 min

122K

Данный текст будет являться новой главой для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github. На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

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

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

В таких системах есть три группы действующих лиц:

источники событий (транзакций)
источники блоков (фиксаторы транзакций)
получатели (читатели) блоков и зафиксированных транзакций.

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

Основное требование к таким журналам таково:

Невозможность модификации журнала: после добавления транзакции в журнал должно быть невозможно её оттуда удалить или изменить.

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

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

Ответ на первый вопрос прост: нужно снабдить каждый блок хеш-суммой от его содержимого. И эту хеш-сумму включить в качестве дополнительной полезной информации (тоже хешируемой) в следующий блок. Тогда для того, чтобы поменять что-то в блоке без разрушения доверия клиентов к нему, нужно будет это сделать таким образом, чтобы хеш-сумма от блока не поменялась. А это как раз практически невозможно, если у нас используется криптографически стойкая хеш-функция. Либо поменять в том числе и хеш-сумму блока. Но тогда придётся менять и значение этой хеш-суммы в следующем блоке. А это потребует изменений, в свою очередь, в хеш-сумме всего второго блока, а потом и в третьем, и так далее. Получается, что для того, чтобы поменять информацию в одном из блоков, нужно будет перегенерировать всю цепочку блоков, начиная с модифицируемого. Можно ли это сделать?

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

централизованный с доверенным центром
централизованный с недоверенным центром
децентрализованный вариант с использованием доказательства работы

Централизованный blockchain с доверенным центром

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

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

Централизованный blockchain с недоверенным центром

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

Для этого можно использовать, например, следующие два метода.

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

Децентрализованный blockchain

Наибольший интерес для нас (и – наименьший для компаний, продающих blockchain-решения) представляет децентрализованная система blockchain без выделенных центров генерации блоков. Каждый участник может взять набор транзакций, ожидающих включения в журнал, и сформировать новый блок. Более того, в системах типа BitCoin такой участник (будем его назвать «майнером», от англ. to mine — копать) ещё и получит премию в виде определённой суммы и/или комиссионных от принятых в блок транзакций.

Но нельзя просто так взять и сформировать блок в децентрализованных системах. Надёжность таких систем основывается именно на том, что новый блок нельзя сформировать быстрее (в среднем) чем за определённое время. Например, за 10 минут (BitCoin). Это обеспечивается механизмом, который получил название доказательство работы.

Механизм основывается на следующей идее. Пусть есть криптографически стойкая хэш-функция $inline$ и задан некоторый параметр $inline$ (от англ. target – цель). $0 < t < 2^{n}$ , где $inline$ — размер выхода хэш-функции в битах. Корректным новым блоком blockchain-сеть будет признавать только такой, значение хэш-суммы которого меньше текущего заданного параметра $inline$ . В этом случае алгоритм работы майнера выглядит следующий образом:

собрать из пула незафиксированных транзакций те, которые поместятся в 1 блок (1 мегабайт для сети Bitcoin) и имеют максимальную комиссию (решить задачу о рюкзаке)
добавить в блок информацию о предыдущем блоке;
добавить в блок информацию о себе (как об авторе блока, кому начислять комиссии и бонусы за блок);
установить $inline$ в некоторое значение, например, $inline$ ;
выполнять в цикле:
- обновить значение $inline$ ;
- посчитать значение $inline$ ;
- если $inline$ , добавить в блок $inline$ и считать блок сформированным, иначе — повторить цикл.

Для каждой итерации цикла вероятность получить корректный блок равна $t / 2^{n}$ . Так как $inline$ обычно мало, то майнерам нужно сделать большое количество итераций цикла, чтобы найти нужный $inline$ . При этом только один (обычно — первый) из найденных блоков будет считаться корректным. Чем больше вычислительная мощность конкретного майнера, тем больше вероятность, что именно он первым сумеет найти нужный $inline$ .

Зная суммарную вычислительную мощность blockchain-сети, участники могут договориться о таком механизме изменения параметра $inline$ , чтобы время генерации нового корректного блока было примерно заданное время. Например, в сети Bitcoin параметр $inline$ пересчитывается каждые 2016 блоков таким образом, чтобы среднее время генерации блока было 10 минут. Это позволяет адаптировать сеть к изменению количества участников, их вычислительных мощностей и к появлению новых механизмов вычисления хэш-функций.

Кроме задания параметра $inline$ можно оперировать другими величинами, так или иначе относящимися к мощности вычислений.

Hashrate — количество хешей, которые считают за единицы времени конкретный майнер или сеть в целом. Например, в ноябре 2017 года общий hashrate для сети Bitcoin составлял примерно $7,7 \times 10^{18}$ хэшей в секунду.
Difficulty — сложность поиска корректного блока, выражаемая как $d = d_{const} / t$ , где $d_{const}$ — некоторая константа сложности, а t — текущая цель (англ. target). В отличие от параметра t, который падает с ростом вычислительной мощности сети, d изменяется вместе с hashrate, что делает его более простым для восприятия и анализа человеком.

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

В случае нормального поведения системы на включение конкретных транзакций в блоки это влияет мало, так как каждый из добросовестных майнеров следует одному и тому же алгоритму включения транзакций в блок (например, в сети BitCoin – алгоритму максимизации комиссии за блок). Однако можно предположить, что какой-нибудь злоумышленник захочет «модерировать» распределённый blockchain, включая или не включая в блоки транзакции по своему выбору. Предположим, что доля вычислительных ресурсов злоумышленника (направленных на генерацию нового блока) равна $inline$ ( 0% < $inline$ < 50%). В этом случае каждый следующий сгенерированный блок с вероятностью $inline$ будет сгенерирована мощностями злоумышленника. Это позволит ему включать в блоки те транзакции, которые другие майнеры включать не захотели.

Но позволит ли это злоумышленнику не включать что-то в цепочку транзакций? Нет. Потому что после его блока с вероятностью $inline$ будет следовать блок «обычного» майнера, который с радостью (пропорциональной комиссии-награде) включит все транзакции в свой блок.

Однако ситуация меняется, если мощности злоумышленника составляют более 50% от мощности сети. В этом случае, если после блока злоумышленника был с вероятностью $inline$ сгенерирован «обычный» блок, злоумышленник его может просто проигнорировать и продолжать генерировать новые блоки, как будто он единственный майнер в сети. Тогда если среднее время генерации одного блока всеми мощностями $inline$ , то за время $inline$ злоумышленник сможет сгенерировать $inline$ , а легальные пользователи $inline$ блоков, $inline$ . Даже если с некоторой вероятностью легальные пользователи сгенерируют 2 блока быстрее, чем злоумышленник один, последний всё равно «догонит и перегонит» «легальную» цепочку примерно за время $inline$ . Так как в blockchain есть договоренность, что за текущее состояние сети принимается наиболее длинная цепочка, именно цепочка злоумышленника всегда будет восприниматься правильной. Получается, что злоумышленник сможет по своему желанию включать или не включать транзакции в цепочки.

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

Кроме концепции «доказательство работы» используются и другие. Например, в подходе «доказательство доли владения» (англ. proof of stake), используемой в сетях Etherium и EmerCoin, вероятность генерации блока пропорциональна количеству средств на счетах потенциальных создателей нового блока. Это намного более энергоэффективно по сравнению с PoW, и, кроме того, связывает ответственность за надёжность и корректность генерации новых блоков с размером капитала (чем больше у нас средств, тем меньше мы хотим подвергать опасности систему). С другой стороны, это даёт дополнительную мотивацию концентрировать больше капитала в одних руках, что может привести к централизации системы.

Механизм внесения изменений в протокол

Любая система должна развиваться. Но у децентрализованных систем нельзя просто «включить один рубильник» и заставить участников системы работать по новому – иначе систему нельзя назвать полностью децентрализованной. Механизмы и способы внесения изменений могут выглядеть на первый взгляд нетривиально. Например:

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

Подводя итоги, Сатоши Накамото (псевдоним), автор технологий blockchain и bitcoin, сумел предложить работающий децентрализованный механизм, в котором и само поведение системы, и изменения к этой системе проходят через явный или неявный механизм поиска консенсуса участников. Для получения контроля над системой в целом злоумышленнику придётся получить контроль как минимум над 50% всех мощностей системы (в случае PoW), а без этого можно лишь попытаться ограничить возможность использования системы конкретными участниками.

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

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

Это произведение доступно по лицензии Creative Commons «Attribution» («Атрибуция») 4.0 Всемирная

История изменений

2017-11-17: Добавлено указание лицензии CC-BY
2017-11-18: Уточнёна и расширена информация про механизм proof-of-work и связанные определения

Tags:

Hubs: