Есть и еще одно неудобство: поскольку данные можно только добавить, но нельзя удалить, даже если они в какой-то момент утратили свою актуальность, общая база с момента образования самого первого блока постоянно растет. Ее размер зависит от разных параметров – скорости создания новых блоков, количества транзакций, содержащихся в них, размеров самих транзакций. В зависимости от этих параметров, а также «возраста» базы данных ее размер уже через несколько лет активной работы может исчисляться сотнями гигабайт информации, которая постоянно копируется и синхронизируется между участниками системы. Решение задачи оптимизации размера базы данных в блокчейн должно стать приоритетом для разработчиков популярных систем, в противном случае это может создать дополнительные препятствия для развития перспективной технологии. Впрочем, предложения по решению этой проблемы уже существуют, и мы коснемся их в разделе, посвященном вопросам масштабирования технологии блокчейн.
Давайте рассмотрим структуру заголовка блока подробнее, чтобы понять, какого рода служебная информация в нем содержится. Понятно, что в разных практических реализациях структура блоков всегда отличается, но у них есть ряд общих элементов, которые встречаются в том или ином виде почти в каждом проекте. Как правило, первое, с чего начинается любой блок – это его порядковый номер. Самый первый блок называется «генезисным», он отличается от прочих тем, что не содержит ссылки на предыдущий блок по причине отсутствия такового. Обычно в блоке есть информация о номере его версии – это бывает необходимо, если впоследствии структура блока претерпит изменения, и в зависимости от номера версии алгоритмы программного обеспечения должны будут их по-разному обрабатывать. Затем, как отмечалось ранее, в заголовке содержится хеш заголовка предыдущего блока для поддержания целостности данных всей цепочки.
Важным элементом заголовка также является время создания блока. Оно записывается в виде числа, равного количеству секунд, прошедших с 1 января 1970 года – формат, принятый в многопользовательских и многозадачных операционных системах, таких, например, как Unix и совместимых с ней. Отдельно заметим, что число это достаточно велико, и через пару десятков лет должно произойти переполнение 32-битной ячейки памяти, обычно выделяемой для переменных, хранящих это значение в различном программном обеспечении. В случае если разработчики этих программ не внесут необходимые исправления, увеличив размер переменной, хранящей значения времени до 64 бит, то 19 января 2038 года по всему миру могут произойти массовые программные сбои. Произойдет это потому, что значения этого числа в силу специфики построения компьютерной архитектуры при выполнении программ будут интерпретироваться как имеющие отрицательные значения – со всеми вытекающими из этого алгоритмическими последствиями.
И, наконец, переходим к части заголовка, посвященной содержащимся в блоке транзакциям. Одним из значений в заголовке является число транзакций в блоке, а вот второе значение имеет загадочное название «корень Меркла». Это не что иное, как совокупный хеш всех транзакций, находящихся в данном блоке, вычисленный определенным образом. В 1979 году американский криптограф Ральф Меркл запатентовал алгоритм вычисления результирующего хеша для набора данных, построенных в виде двоичного дерева:
Согласно логике алгоритма Меркла, все транзакции в блоке делятся попарно, хешируются, и их хеши суммируются между собой. Если общее число транзакций изначально было нечетным и последней транзакции не хватает пары, то в этом случае ее собственный хеш просто удваивается. На следующем уровне «дерева» количество хешей уже вдвое меньше и их число уже гарантированно четное. Хеши опять разбиваются по парам, эти пары суммируются, и так далее, пока из них не останется только одно конечное число. В итоге на вершине дерева образуется результирующий, или корневой хеш, который и называется «корнем Меркла» и является фактически единым совокупным отпечатком всех транзакций блока. Понятно, что при изменении любой из транзакций в блоке все хеши дерева Меркла сразу же пересчитаются заново, и результирующий хеш также изменится, что будет являться маркером события, соответствующего вмешательству в данные блока. Таким образом, значение корня Меркла является «представителем» транзакционной части блока в его собственном заголовке. Будучи «подхешированным» к общим данным заголовка и, таким образом, опосредованно включенным в заголовок следующего блока, корень Меркла играет роль дополнительной гарантии неизменности транзакций, ранее записанных в блокчейн.
Помимо вышеописанных параметров структуры блока, в нем могут присутствовать элементы, связанные с непосредственным получением права на создание блока и его защиты от возможных будущих изменений. Речь идет о создании новых блоков в системах с доказательством работы. Но в данный момент говорить об этом несколько преждевременно, поэтому сначала ознакомимся со структурой транзакций и принципами ведения балансов в блокчейн-системах.
Транзакции и балансы
Все мы привыкли иметь дело с классическими банками: открывать счета, осуществлять платежи с одного расчетного счета на другой, получать на свой счет денежные средства. В последние пару десятилетий широкое распространение получили системы «банк – клиент», позволяющие управлять своими счетами через интернет. Несмотря на внешние различия, в первую очередь в части дизайна интерфейса подобных систем, их функционал является более-менее схожим для всех финансовых институтов, предлагающих такие услуги. Первым шагом к получению доступа к своим средствам через интернет в большинстве случаев является прохождение процедуры двухфакторной идентификации. Сначала пользователь вводит обычный пароль многократного использования, а затем система просит ввести специальный однократный код, который либо генерируется посредством специального устройства, либо может быть получен по SMS или электронной почте. Так исключается несанкционированный доступ к счету клиента, данные о котором хранятся на серверах банка, то есть централизованно. Если сервера банка по какой-то причине не работают, например, находятся на техническом обслуживании, то доступ к счету будет невозможен до момента, пока система не вернется к обычной работе.
Получив доступ к своему счету, клиент может проверить свой баланс, а затем осуществлять перевод средств с данного счета, также пользуясь системой генерации однократных кодов, поскольку этого требуют правила безопасности доступа к данным. У каждого счета есть свой номер, сгенерированный по определенным правилам и стандартам – либо самого банка, либо государства, в котором банк расположен. Отправляя платежи на другие счета, банк, как правило, взимает комиссию за свои услуги, размер которой устанавливает самостоятельно, в зависимости от своих бизнес-издержек, заложенной нормы прибыли и конкурентной ситуации на рынке банковских услуг. Очевидно, чтобы клиент мог совершать или получать платежи, банк сначала должен открыть ему расчетный счет и выдать реквизиты доступа в интернет-банк, иначе никакие входящие или исходящие переводы невозможны.
В блокчейн-системах все организовано совсем по-другому. Во-первых, там нет никаких банков или иных централизованных органов, контролирующих счета и платежи по ним. Во-вторых, никакие счета заранее не создаются, и балансов по ним никто специально не ведет. На первый взгляд это кажется немного странным, однако именно этим отличаются проекты платежных систем, реализованные на базе технологии блокчейн. Для того чтобы стать участником системы, пользователю необходимо сгенерировать себе пару ключей – закрытый и открытый, пользуясь алгоритмом асимметричной криптографии, который используется в конкретной блокчейн-среде. Ключи в паре всегда жестко связаны между собой – секретный может быть сгенерирован случайным образом, а открытый вычисляется из него математически. Впрочем, все это делается автоматически, при помощи программного обеспечения самой системы по запросу пользователя, то есть нажатием соответствующей кнопки в интерфейсе программы-клиента. Таким образом у пользователя появляется свой счет в системе, хотя правильнее было бы сказать – адрес. И этот адрес фактически является модификацией его открытого ключа, который при создании был обработан несколькими процедурами хеширования и специального символьного кодирования. Делается это не только для более удобного визуального восприятия адреса, но и для еще большего усложнения задачи восстановления связанного с ним закрытого ключа, поскольку односторонние хеш-функции, да еще использованные несколько раз подряд, исключительно усложняют любые попытки взлома адреса блокчейн-системы.
