Файловым системам всегда находился укромный уголок в сердце автора. Он учился программированию на языке сценариев командной оболочки Unix, автоматизируя инсталляцию Disksuite – бесплатного, но садистического ПО по зеркалированию дисков от Sun. Затрудняясь припомнить, в чём именно заключался его труд, он помнит, как к нему шёл. Чтобы научиться программированию, ему пришлось попутешествовать в буквальном смысле слова – он не раз навестил друга, которому явно доставляло удовольствие указывать на ошибки.
Когда компания Sun начала рекламировать свою файловую систему ZFS как (долгожданную!) преемницу Disksuite и её файловой системы UFS, то большая часть функционала казалась явно эффективной: система позволяла компьютерам управлять дисками, от пользователей не требовалось с самого начала знать её размеры, она не разрушалась в результате краха сервера. В общем, такие приятные пустяки. Но вот вопрос – насколько была обеспечена целостность системы данных? Автору стыдно признаться, но он не сразу понял, что нуждается в этой характеристике – кому интересно, что файловая система эффективна в вопросе хранения данных, верно? И ещё больше времени ушло на то, чтобы разобраться, как она работает.
Чтобы объяснить это, читателям необходим маленький урок криптографии. Они могут пропустить эту часть, если уже обладают соответствующими познаниями. Как правило, обучение криптографии начинается с указания: «Получить степень магистра по математике в Массачусетском технологическом институте». В действительности, можно пойти немного более коротким путём. Криптография – просто разновидность математики. Хотя большинству сложно разобраться в этой сфере досконально, можно как минимум понять функциональную диаграмму с алгоритмами. Когда люди говорят о тщетности попыток запретить криптографию, они подразумевают следующее: «невозможно запретить математику».
Криптография более всего известна как инструмент, обеспечивающий приватность: она служит гарантией того, что только пользователь, прибегающий к её помощи, имеет доступ к файлам и личным сообщениям в чатах. Задача несколько усложняется, когда возникает необходимость читать их на всех устройствах пользователя одновременно, однако сама концепция практически не изменяется. Она даже более эффективна в ситуации, когда позволяет одновременно читать текст двум избранным лицам, но не третьему. Это более сложная схема, но по сути является продолжением первой.
Приватность – не единственный сценарий использования криптографии. Она также эффективна в деле верификации. Например, с её помощью можно проверить, идентичен ли файл, который находится в распоряжении пользователя, тому, что был у него вчера. Скажем, у пользователя, которому присылают файл, возникает сомнение – как он может убедиться в том, что файл не изменился в процессе пересылки?
Безусловно, решением может послужить просто повторная отправка файла. Это решение не идеально, поскольку подразумевает доверие к аутентичности файла с самого начала. Кроме того, такая модель плоха, если пропускная способность соединения обходится дорого. Идеал – это механизм верификации, занимающий меньше места, чем оригинальный файл, и требующий меньшей мощности CPU, чем те, что необходимы для прямого сопоставления двух файлов.
Криптография как раз предоставляет такую возможность, обычно именуемую «функцией хэширования». Это алгоритм, превращающий, скажем, большой текстовый файл в гораздо более короткий ряд символов. Чтобы убедиться в том, что файл не подвергся изменениям, достаточно осуществить обратное преобразование короткой версии и сравнить результат с оригиналом. Короткие строки сравнивать легче, чем длинные документы. Их даже можно зачитать по телефону собеседнику, с тем, чтобы тот проверил файл. Обычно эти алгоритмы создают строку фиксированной длины, независимо от объёма вводимой информации. Таким образом, они служат эффективным средством длительного хранения данных и их сравнения, и могут безопасно преобразовывать файл любого размера. Пример результата работы хэш-функции:
03f39f4bfad04f6f2cfe09ced161ab740094905c
Как видят читатели, это просто длинная строка абракадабры. Она позволяет легко проводить сравнение двух файлов. Другим достоинством служит тот факт, что сам по себе этот набор символов лишён смысла.
Критически важной характеристикой этих алгоритмов служит их способность неизменно обеспечивать уникальный вывод при уникальном вводе. Если два человека имеют файл, который хэшируется в определённую строку, то они оба могут быть уверены в том, что это один и тот же файл. Конечно, не в буквальном смысле слова: можно создать хэш-функцию, имеющую всего лишь 256 возможным выводов, тогда как возможных вводов существует явно гораздо больше. В результате, возникают многочисленные конфликты, когда два файла хэшируются в один вывод. Увы, от такого сценария мало проку.
Все современные функции хэширования – невероятно длинные. Хотя конфликт возможен в теории, на практике он нереален. Необходимо выполнить функцию 2¹²⁸ раз. Это 3.4 с 38 нулями. Таким образом, математически это возможно, но скорее солнце поглотит землю, чем самая надёжная функция хэширования пострадает. Иначе говоря, это немыслимо, то есть файлы будут в безопасности.
Теперь, когда читатели стали не менее сведущи в криптографии, чем большинство «ходлеров» биткоина, возникает вопрос – почему всё это важно?
Речь шла о целостности данных.
Читатели не ошибутся, посчитав, что файловая система ZFS использует эти хэш-функции для подтверждения целостности. Она способна на большее, нежели просто проверка достоверности индивидуальных файлов.
Ключом служит толика криптографического гения – явление под названием древо Меркла (хэш-дерево). В рамках этой модели контент не просто хэшируется на диск с целью дальнейшей проверки достоверности, но создаётся дерево хэшей, в листовые вершины которого помещены хэши от блоков данных, а внутренние вершины содержат хэши от сложения значений в дочерних вершинах. Корневой узел дерева содержит хэш от всего набора данных. Если любая часть системы портится – повреждается диск или кто-то изменяет контент – это обстоятельство легко распознать. Изменяется не только индивидуальный хэш, но ошибочными становятся и все родительские хэши всех дочерних хэшей.
Если контент изменяется посредством любого механизма, который также не обновляет древо Меркла, это легко можно заметить, заново хэшируя весь контент и сравнивая результаты с сохранённым древом.
Так ZFS удостоверяет данные. Она может записать блок на диск, затем вынуть блок и проверить, соответствует ли он по-прежнему хэшу. Когда система пишет блок, то обновляет параллельное древо. Если позже попросить систему предоставить блок, она сообщит, аутентичен ли он. Если нет, система, вместо того, чтобы возвращать блок, сообщит об ошибке.
Возможно это перебор, но стоит вспомнить, насколько многочисленны способы повреждения данных.Достаточно распространённый – искажение данных в преступных целях, но гораздо чаще встречается ошибка в процессе записи или чтения. Старые вращающиеся диски были ненадёжны, а новые твердотельные диски с течением времени разрушаются. Главной проблемой служит чрезмерная изощрённость процесса чтения и записи, но также существует риск порчи многочисленных уровней кэша, драйверов и связей.
Впрочем, ZFS впервые в рамках промышленной файловой системы хотя бы даёт возможность распознать любые из этих проблем. Прискорбно, что никто и никогда не использовал её ранее. Разумеется есть люди, которые любят и используют ZFS. Но не в тех масштабах, в которых следовало бы.
Автор прекрасно понимает: читатели ожидали, что что узнают о чудесной возможности воспользоваться всеми преимуществами блокчейна без самого блокчейна. Вместо этого, он читает лекции о двух явлениях, которые читателям до фонаря: криптографии и файловых системах. Но не стоит переживать — дальше будет ещё хуже.
Спустя продолжительное время после того, как автор узнал и сразу же позабыл ZFS (в конце концов, он ею не пользовался), он принял на вооружение Git. Это распределённая система управления версиями, используемая для хранения и управления программным кодом.
Все приличные программисты давно о ней знали, но массы познакомились с системой лишь недавно, когда корпорация Microsoft приобрела Github за $7.5 миллиардов. Автор был одним из ранних пользователей – в 2008 он перешёл с Puppet на Git. Ему приятно щекотал нервы и немного пугал тот факт, что он сумел воспроизвести в Puppet одну из ключевых рабочих характеристик Git: систему хранения файлов, которая позволяла находить их по содержанию (или, скорее, по хэшу содержания). Как правило, файлы сохраняется по имени, но если множество людей (или, как в случае Puppet, компьютеров) хранят один и тот же файл, то могут не давать ему одно название. Соответственно, Git и Puppet, сохраняли файлы с помощью хэша. Таким образом, существовала гарантия того, что пользователи не копируют (хранят) больше одного экземпляра файла, экономя много пространства. Кроме того, эта модель облегчала задачу проверки изменений в файлах. В рамках Puppet с помощью этой модели просто дублировались изменяемые файлы, на тот случай, если кто-то хотел вернуться к первоначальной версии. Однако Git оказалась способна на гораздо большее.
Как и ZFS, она строит древо Меркла всего файлового репозитория, с аналогичной целью: понять, какие файлы изменились, и как. В конце концов, Git используется для отслеживания изменений и их передачи в коллекцию файлов. Критически важным компонентом здесь является совместное использование файлов; пользователь легко может скопировать весь репозиторий Git на другой компьютер, или передать их другому пользователю. Важно, чтобы они смогли подтвердить наличие аутентичной копии.
Git хранит древо хэшей наряду со всеми файлами. В любой момент можно использовать древо для проверки любого файла в древе. Если присутствуют изменения, то система управления версиями может автоматически сохранить новые файлы и обновить связанное древо – фактически, это главное достоинство системы.
Как и в случае ZFS, одна из ключевых характеристик системы состоит в том, что древо Меркла позволяет проверять каждый хранимый файл. Можно пройти всё древо файлов и сравнить каждый файл с его хэшем, а затем сравнить листинг файла с его собственным хэшем, по восходящей. И любое несоответствие легко распознать.
Именно этот набор характеристик импонирует большего всего: система проста в смысле внедрения, гибка и эффективна. Она обладает мощью, которой недостаёт другим системам управления версиями, просто потому, что в её основе лежит механизм хранения и проверки подлинности. Здесь мы подошли к сути вопроса.
Легко рассматривать блокчейн как внезапную революцию, как драматическое изменение в том, что возможно. Если рассматривать его так, то непросто отделить части от целого. Если в поле зрения находится лишь глобальная картина, то легко упустить из виду тот факт, что каждый индивидуальный компонент обладает собственной историей и ценностью.
Блокчейн на самом деле возникал постепенно. Он отнюдь не был одним гигантским скачком. Он был составной частью определённого сюжета, последовательности. Самый интересный его аспект – древо Меркла – основан на математических изысканиях, которые насчитывают историю в десятилетия. Сейчас даже широкие массы пользователей благодаря этому аспекту соприкасаются с ветхозаветной математикой. Большинство самых интересных – и активно рекламируемых – характеристик блокчейна имеют своим фундаментом как раз эту математику. Неизменяемость и отсутствие необходимости в доверии непосредственно происходят из неё.
Однако, в отличие от блокчейна как целого, индивидуальные технические компоненты использовались в условиях эксплуатации годами, даже десятилетиями. Концентрация на текущем тренде может вылиться в слепоту по отношению к возможностям, которую демонстрирует история. Автор считает, что вместо попыток заменить валюту, лучше, обращаясь к истории, найти решения с более широким применением.
Поскольку автор – выходец из мира файловых систем и систем управления версиями, то он видит иные преимущества, нежели те, что очевидны, если смотреть сквозь призму валют, бирж или мессенджеров. И, может быть, не только прошлое, но и будущее блокчейна — не в торговле и финансах, а именно в технической инфраструктуре?
Об авторе: Люк Канис – предприниматель, консультант, стратег и журналист. В центре его интересов – увеличение инклюзивности и производительности ПО и работа с создателями проектов.
