Блокчейн. Цихилов. Блокчейн (Цихилов). Копирование, воспроизведение и иное использование электронной книги, ее частей
 Скачать 2.63 Mb.
|
|
численность населения и объем взимаемых налогов. Появившиеся в тех местах в первой половине XVI века испанские конкистадоры далеко не сразу постигли утилитарный смысл этих странных веревочно-узловых конструкций, при помощи которых инки фактически управляли своей империей. Для того чтобы сломать установившийся порядок управления, испанцам пришлось навязать завоеванным территориям европейские принципы письменности и учета данных. Кипу были полностью вытеснены из обращения и забыты, и только в начале XIX века ученые начали их изучать на относительно системной основе. Им удалось расшифровать достаточно много информации, содержащейся в сохранившихся экземплярах. Поняв основные принципы логики построения подобной системы учета, ученые были весьма удивлены, что такая древняя цивилизация, будучи изолированной от более прогрессивного мира, сумела найти столь эффективный способ компактной записи и хранения данных, подчиняющийся логике связных информационных блоков. Во второй половине XX века, когда информационные технологии начали медленно, но верно завоевывать мир, возникла необходимость в создании различных форм записи и хранения информации. Одной из таких форм стали связные списки — специальные структуры данных, каждая из которых содержала не только данные как таковые, но и специальные ссылки на подобные же структуры, как на предыдущие, так и на последующие. Это позволяло игнорировать естественный порядок хранения данных на различных носителях и руководствоваться при этом исключительно той информационной логистикой, принцип которой был заложен в наборе внутренних связей между блоками. В зависимости от логики решения поставленных задач формы списков данных в большинстве случаев могли быть односвязными (однонаправленными) или двусвязными (двунаправленными). Также обе формы списков могли иметь кольцевую структуру, когда последний элемент ссылается на первый или наоборот. Пример простого односвязного списка показан на рисунке: Собственно, в своем классическом виде блокчейн представляет собой односвязный список, когда каждый следующий блок в системе ссылается на предыдущий. Вопрос в том, что значит «ссылается»: каким образом это технологически реализовано, а главное, зачем он вообще это делает? Ответ прост — для поддержания целостности базы данных. Блок состоит из двух основных частей — заголовка, содержащего служебную информацию, и списка транзакций для передачи цифровых активов между участниками системы или просто записи фактов. Все это — набор данных, который можно отобразить в виде хеша стандартной длины. Вычислив хеш данных заголовка, мы фиксируем состояние всего блока, и любое вмешательство в его целостность немедленно приведет к тотальному изменению общего хеша. А что, если каждый новый блок будет содержать хеш от данных предыдущего блока как один из элементов своего заголовка? Тогда получится, что, хешируя данные одного заголовка, мы автоматически включаем туда хеш заголовка предыдущего блока, и таким образом получается форма сцепления блоков. Нам известно, что любое малейшее изменение в прообразе меняет его хеш до неузнаваемости. Это означает, что если мы вмешаемся в любой бит данных любого из блоков в середине цепочки, это приведет к пересчету всех хешей последующих блоков. Другими словами, изменятся данные всей цепочки. О чем в первую очередь нам говорит связная структура блоков? О том, что блокчейн — это система, куда можно только добавлять информацию, но нельзя менять или удалять. При этом добавить информацию возможно только в виде новых блоков и только в конец цепочки. Это, безусловно, порождает определенное неудобство при управлении информацией, помещаемой в блокчейн, но, с другой стороны, создает исключительную безопасность хранения данных в распределенном виде. Ведь вся база блоков копируется каждому участнику системы, и каждый из них имеет возможность записать туда что угодно. Другое дело, что эти изменения, будучи сделаны с нарушением правил системы, не будут приняты другими участниками сети. А соответствие правилам проверяется участниками системы чисто математически, поэтому подсунуть им искаженную информацию никак не удастся. Алгоритмы проверки информации, содержащейся в блоках, сразу же просигнализируют о нарушении целостности данных, и данный блок будет считаться неприемлемым для всей сети. Есть и еще одно неудобство: поскольку данные можно только добавить, но нельзя удалить, даже если они в какой-то момент утратили свою актуальность, общая база с момента образования самого первого блока постоянно растет. Ее размер зависит от разных параметров — скорости создания новых блоков, количества транзакций, содержащихся в них, размеров самих транзакций. В зависимости от этих параметров, а также «возраста» базы данных ее размер уже через несколько лет активной работы может исчисляться сотнями гигабайт информации, которая постоянно копируется и синхронизируется между участниками системы. Решение задачи оптимизации размера базы данных в блокчейн должно стать приоритетом для разработчиков популярных систем, в противном случае это может создать дополнительные препятствия для развития перспективной технологии. Впрочем, предложения по решению этой проблемы уже существуют, и мы коснемся их в разделе, посвященном вопросам масштабирования технологии блокчейн. Давайте рассмотрим структуру заголовка блока подробнее, чтобы понять, какого рода служебная информация в нем содержится. Понятно, что в разных практических реализациях структура блоков всегда отличается, но у них есть ряд общих элементов, которые встречаются в том или ином виде почти в каждом проекте. Как правило, первое, с чего начинается любой блок — это его порядковый номер. Самый первый блок называется «генезисным», он отличается от прочих тем, что не содержит ссылки на предыдущий блок по причине отсутствия такового. Обычно в блоке есть информация о номере его версии — это бывает необходимо, если впоследствии структура блока претерпит изменения, и в зависимости от номера версии алгоритмы программного обеспечения должны будут их по- разному обрабатывать. Затем, как отмечалось ранее, в заголовке содержится хеш заголовка предыдущего блока для поддержания целостности данных всей цепочки. Важным элементом заголовка также является время создания блока. Оно записывается в виде числа, равного количеству секунд, прошедших с 1 января 1970 года — формат, принятый в многопользовательских и многозадачных операционных системах, таких, например, как Unix и совместимых с ней. Отдельно заметим, что число это достаточно велико, и через пару десятков лет должно произойти переполнение 32-битной ячейки памяти, обычно выделяемой для переменных, хранящих это значение в различном программном обеспечении. В случае если разработчики этих программ не внесут необходимые исправления, увеличив размер переменной, хранящей значения времени до 64 бит, то 19 января 2038 года по всему миру могут произойти массовые программные сбои. Произойдет это потому, что значения этого числа в силу специфики построения компьютерной архитектуры при выполнении программ будут интерпретироваться как имеющие отрицательные значения — со всеми вытекающими из этого алгоритмическими последствиями. И, наконец, переходим к части заголовка, посвященной содержащимся в блоке транзакциям. Одним из значений в заголовке является число транзакций в блоке, а вот второе значение имеет загадочное название «корень Меркла». Это не что иное, как совокупный хеш всех транзакций, находящихся в данном блоке, вычисленный определенным образом. В 1979 году американский криптограф Ральф Меркл запатентовал алгоритм вычисления результирующего хеша для набора данных, построенных в виде двоичного дерева: Согласно логике алгоритма Меркла, все транзакции в блоке делятся попарно, хешируются, и их хеши суммируются между собой. Если общее число транзакций изначально было нечетным и последней транзакции не хватает пары, то в этом случае ее собственный хеш просто удваивается. На следующем уровне «дерева» количество хешей уже вдвое меньше и их число уже гарантированно четное. Хеши опять разбиваются по парам, эти пары суммируются, и так далее, пока из них не останется только одно конечное число. В итоге на вершине дерева образуется результирующий, или корневой хеш, который и называется «корнем Меркла» и является фактически единым совокупным отпечатком всех транзакций блока. Понятно, что при изменении любой из транзакций в блоке все хеши дерева Меркла сразу же пересчитаются заново, и результирующий хеш также изменится, что будет являться маркером события, соответствующего вмешательству в данные блока. Таким образом, значение корня Меркла является «представителем» транзакционной части блока в его собственном заголовке. Будучи «подхешированным» к общим данным заголовка и, таким образом, опосредованно включенным в заголовок следующего блока, корень Меркла играет роль дополнительной гарантии неизменности транзакций, ранее записанных в блокчейн. Помимо вышеописанных параметров структуры блока, в нем могут присутствовать элементы, связанные с непосредственным получением права на создание блока и его защиты от возможных будущих изменений. Речь идет о создании новых блоков в системах с доказательством работы. Но в данный момент говорить об этом несколько преждевременно, поэтому сначала ознакомимся со структурой транзакций и принципами ведения балансов в блокчейн-системах. ТРАНЗАКЦИИ И БАЛАНСЫ Все мы привыкли иметь дело с классическими банками: открывать счета, осуществлять платежи с одного расчетного счета на другой, получать на свой счет денежные средства. В последние пару десятилетий широкое распространение получили системы «банк — клиент», позволяющие управлять своими счетами через интернет. Несмотря на внешние различия, в первую очередь в части дизайна интерфейса подобных систем, их функционал является более-менее схожим для всех финансовых институтов, предлагающих такие услуги. Первым шагом к получению доступа к своим средствам через интернет в большинстве случаев является прохождение процедуры двухфакторной идентификации. Сначала пользователь вводит обычный пароль многократного использования, а затем система просит ввести специальный однократный код, который либо генерируется посредством специального устройства, либо может быть получен по SMS или электронной почте. Так исключается несанкционированный доступ к счету клиента, данные о котором хранятся на серверах банка, то есть централизованно. Если сервера банка по какой-то причине не работают, например, находятся на техническом обслуживании, то доступ к счету будет невозможен до момента, пока система не вернется к обычной работе. Получив доступ к своему счету, клиент может проверить свой баланс, а затем осуществлять перевод средств с данного счета, также пользуясь системой генерации однократных кодов, поскольку этого требуют правила безопасности доступа к данным. У каждого счета есть свой номер, сгенерированный по определенным правилам и стандартам — либо самого банка, либо государства, в котором банк расположен. Отправляя платежи на другие счета, банк, как правило, взимает комиссию за свои услуги, размер которой устанавливает самостоятельно, в зависимости от своих бизнес-издержек, заложенной нормы прибыли и конкурентной ситуации на рынке банковских услуг. Очевидно, чтобы клиент мог совершать или получать платежи, банк сначала должен открыть ему расчетный счет и выдать реквизиты доступа в интернет-банк, иначе никакие входящие или исходящие переводы невозможны. В блокчейн-системах все организовано совсем по-другому. Во- первых, там нет никаких банков или иных централизованных органов, контролирующих счета и платежи по ним. Во-вторых, никакие счета заранее не создаются, и балансов по ним никто специально не ведет. На первый взгляд это кажется немного странным, однако именно этим отличаются проекты платежных систем, реализованные на базе технологии блокчейн. Для того чтобы стать участником системы, пользователю необходимо сгенерировать себе пару ключей — закрытый и открытый, пользуясь алгоритмом асимметричной криптографии, который используется в конкретной блокчейн-среде. Ключи в паре всегда жестко связаны между собой — секретный может быть сгенерирован случайным образом, а открытый вычисляется из него математически. Впрочем, все это делается автоматически, при помощи программного обеспечения самой системы по запросу пользователя, то есть нажатием соответствующей кнопки в интерфейсе программы-клиента. Таким образом у пользователя появляется свой счет в системе, хотя правильнее было бы сказать — адрес. И этот адрес фактически является модификацией его открытого ключа, который при создании был обработан несколькими процедурами хеширования и специального символьного кодирования. Делается это не только для более удобного визуального восприятия адреса, но и для еще большего усложнения задачи восстановления связанного с ним закрытого ключа, поскольку односторонние хеш-функции, да еще использованные несколько раз подряд, исключительно усложняют любые попытки взлома адреса блокчейн-системы. Напомним, что подобные сети являются децентрализованными, поэтому все действия пользователь совершает не на каком-то удаленном сервере, а непосредственно у себя на компьютере или мобильном устройстве. Там же хранятся и все необходимые ключи, в том числе и закрытые. В отличие от классического банка, вопросы хранения секретной персональной информации теперь возложены на самого клиента. Если он потеряет секретный ключ, то автоматически утратит доступ к активам, которые связаны с адресом, сгенерированным на основе этого секретного ключа. В интернете можно найти огромное количество историй о несостоявшихся криптовалютных миллионерах, которые потеряли свои цифровые миллионы вместе с закрытыми ключами от своих адресов. Это достаточно серьезная проблема, поэтому вопросам безопасности хранения криптоактивов будет посвящена отдельная глава. Теперь, когда у пользователя есть адрес в условной блокчейн- системе, разберемся, каким образом он сможет получать на него и затем переводить с него на другие адреса цифровые активы. Здесь нельзя еще раз не вспомнить аналогию с бухгалтерской книгой, которая состоит из страниц с финансовыми транзакциями: от кого переведено, кому, сколько и за что. Представим, что у нас есть несколько участников в какой-то бизнес-среде, которые постоянно обмениваются товарами, услугами и денежными средствами, а все факты совершения обмена при этом записываются в специальную книгу. Когда один из участников захочет перевести другому определенную сумму, ему для начала необходимо доказать, что он располагает этими средствами. Сделать это можно, только лишь указав на предыдущие входящие транзакции в пользу этого участника, то есть сослаться на них как на доказательство владения определенными активами. Причем сослаться можно не на какую- то одну конкретную транзакцию, а сразу на несколько, если одной будет недостаточно для того, чтобы набрать необходимую сумму для исходящего платежа. Когда банк переводит деньги с одного счета на другой, он проводит следующие три операции: вычитает сумму перевода и сумму комиссии за перевод со счета отправителя и добавляет сумму перевода на счет получателя. Комиссию же банк оставляет себе как оплату за совершенную посредническую услугу. В блокчейн-системах никаких посредников нет, равно как и средства ниоткуда физически не вычитаются и никуда не прибавляются. Владелец активов просто указывает в транзакции адреса одного или нескольких получателей, то есть опять же формирует ссылки. В итоге транзакция представляет собой набор ссылок на входящие поступления на адрес плательщика, а также набор ссылок на исходящие адреса получателей его платежей. Для таких транзакций в блокчейн-среде оперируют понятиями «входы» и «выходы». Существует правило, что сумма всех средств на «выходах» должна быть равна сумме средств на «входах». Если у владельца адреса нет необходимости тратить все средства на задействованных в транзакции «входах» полностью, он формирует дополнительный «выход» в виде сдачи самому себе, чтобы поддержать равный баланс «входов» и «выходов». Очевидно, что «выход» для отправителя будет являться «входом» для получателя, и он сможет потом на него, в свою очередь, сослаться, когда будет совершать собственные исходящие платежи. Какие выводы мы можем сделать из описания этой схемы? Во- первых, проанализировав с самого первого (генезисного) блока базы все «входы» на конкретный адрес и все «выходы» с него, можно легко выявить, сколько у владельца данного адреса осталось непотраченных «выходов». Это и есть баланс его счета. То есть баланс как таковой нигде не хранится, а просто вычисляется как сумма всех непотраченных «выходов». Во- вторых, указывая «выход» на конкретный адрес, отправитель предполагает, что в системе существует такой участник, у которого есть закрытый ключ к этому адресу. Иначе, если, например, ввести адрес получателя с ошибкой, то транзакция, на него ссылающаяся, все равно будет принята системой, но средства этой исходящей транзакции будут навсегда потеряны и исключены из обращения. Это связано с тем, что транзакции, помещенные в блок, прошедшие процедуру консенсуса и включенные в общую цепочку блоков, не смогут в будущем быть изменены. Некоторые проекты, например, Биткоин, формируют определенную защиту от ошибки, преобразуя адрес в формате шестнадцатеричного числа в алфавитно-цифровой формат, добавляя в конец полученного адреса его контрольную сумму. При вводе адреса получателя в соответствующее поле формы перевода средств в случае ошибки в расчете и сравнении контрольной суммы система выдаст предупреждение. Также довольно часто используется представление адреса в виде QR- кода, чтобы отправитель мог его отсканировать своим мобильным телефоном и автоматически преобразовать в правильный набор букв и цифр, составляющих адрес получателя. Возникает вопрос: а может ли участник системы при переводе средств сослаться на «входы», которые ему самому не принадлежат, и каким образом это можно проверить? На самом деле для того, чтобы легитимно сослаться на «входы», необходимо в ссылке указать свой открытый ключ и свою цифровую электронную подпись, сформированную на базе закрытого ключа, связанного с адресом владельца. При помощи алгоритмов проверки цифровой подписи любой участник системы может удостовериться в том, что ссылка на «входы» действительно легитимна. А в случае ошибки проверки данная транзакция просто игнорируется и не включается в блок тем узлом, который его формирует для сети. |