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

Корни блокчейна в файловых системах и управлении версиями

58

Файловым системам вечно находился укромный уголок в сердце автора. Он учился программированию на языке сценариев командной оболочки 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, одна из ключевых характеристик системы заключается в том, что древо Меркла позволяет проверять каждый хранимый файл. Можно пройти всё древо файлов и сравнить любой файл с его хэшем, а затем сравнить листинг файла с его собственным хэшем, по восходящей. И любое несоответствие легко распознать.

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

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

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

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

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

Об авторе: Люк Канис – предприниматель, консультант, стратег и журналист. В середине его интересов – увеличение инклюзивности и производительности ПО и работа с создателями проектов.

Источник: bits.media