Файловим системам завжди знаходився затишний куточок в серце автора. Він навчався програмування на мові сценаріїв командної оболонки Unix, автоматизуючи інсталяцію Disksuite – безкоштовного, але садистичного ПО віддзеркалення дисків від Sun. Вагаючись пригадати, в чому саме полягав його працю, він пам’ятає, як до нього йшов. Щоб навчитися програмуванню, йому довелося помандрувати в буквальному сенсі слова, він не раз відвідав друга, якому явно приносило задоволення вказувати на помилки.
Коли компанія Sun почала рекламувати свою файлову систему ZFS як (довгоочікувану!) наступницю Disksuite і її файлової системи UFS, то більша частина функціоналу здавалася явно ефективною: система дозволяла комп’ютерів управляти дисками, від користувачів не потрібно було з самого початку знати її розміри, вона не руйнувалася в результаті краху сервера. Загалом, такі приємні дрібниці. Але от питання – наскільки була забезпечена цілісність системи даних? Автору соромно зізнатися, але він не відразу зрозумів, що потребує в цій характеристиці – кому цікаво, що файлова система ефективна в питанні зберігання даних, вірно? І ще більше часу пішло на те, щоб розібратися, як вона працює.
Щоб пояснити це, читачам необхідний маленький урок криптографії. Вони можуть пропустити цю частину, якщо вже володіють відповідними знаннями. Як правило, навчання криптографії починається з вказівки: «Отримати ступінь магістра з математики в Массачусетському технологічному інституті». Насправді, можна піти трохи більш коротким шляхом. Криптографія – просто різновид математики. Хоча більшості складно розібратися в цій сфері досконально, можна як мінімум зрозуміти функціональну схему алгоритмами. Коли люди говорять про марність спроб заборонити криптографію, вони мають на увазі наступне: «неможливо заборонити математику».
Криптографія найбільше відома як інструмент, що забезпечує приватність: вона служить гарантією того, що тільки користувач, прибегающий до її допомоги, має доступ до файлів і особистих повідомлень в чаті. Завдання дещо ускладнюється, коли виникає необхідність читати їх на всіх пристроях користувача одночасно, проте сама концепція практично не змінюється. Вона навіть більш ефективна в ситуації, коли дозволяє одночасно читати текст двом обраним особам, але не третій. Це більш складна схема, але по суті є продовженням першої.
Приватність – не єдиний сценарій використання криптографії. Вона також ефективна у справі верифікації. Наприклад, з її допомогою можна перевірити, ідентичний файл, який перебуває в розпорядженні користувача, того, що був у нього вчора. Скажімо, у користувача, якому надсилають файл, виникає сумнів – як він може переконатися в тому, що файл не змінився в процесі пересилання?
Безумовно, рішенням може послужити просто повторна відправка файлу. Це рішення не ідеально, оскільки передбачає довіру до автентичності файлу з самого початку. Крім того, така модель погана, якщо пропускна здатність з’єднання обходиться дорого. Ідеал – це механізм верифікації, займає менше місця, ніж оригінальний файл, і вимагає меншої потужності CPU, ніж ті, що необхідні для прямого порівняння двох файлів.
Криптографія як раз надає таку можливість, зазвичай іменується «функції хешування». Це алгоритм, що перетворює, скажімо, великий текстовий файл в набагато більш короткий ряд символів. Щоб переконатися в тому, що файл не зазнав змін, достатньо здійснити зворотне перетворення короткої версії і порівняти результат з оригіналом. Короткі рядки порівнювати легше, ніж довгі документи. Їх навіть можна зачитати по телефону співрозмовнику, з тим, щоб той перевірив файл. Зазвичай ці алгоритми створюють рядок фіксованої довжини, незалежно від обсягу інформації, що вводиться. Таким чином, вони служать ефективним засобом тривалого зберігання даних та їх порівняння, і можуть безпечно конвертувати файли будь-якого розміру. Приклад результату роботи хеш-функції:
03f39f4bfad04f6f2cfe09ced161ab740094905c
Як бачать читачі, це просто довга рядок абракадабри. Вона дозволяє легко проводити порівняння двох файлів. Іншою перевагою є той факт, що сам по собі цей набір символів позбавлений сенсу.
Критично важливою характеристикою цих алгоритмів слугує їх здатність незмінно забезпечувати унікальний висновок при унікальному введенні. Якщо дві людини мають файл, який хэшируется в певну рядок, то вони обидва можуть бути впевнені в тому, що це один і той же файл. Звичайно, не в буквальному сенсі слова: можна створити хеш-функцію, що має всього лише 256 можливих висновків, тоді як можливих вводів існує явно набагато більше. В результаті, виникають численні конфлікти, коли два файлу хешуються в один висновок. На жаль, від такого сценарію мало пуття.
Всі сучасні функції хешування – неймовірно довгі. Хоча можливий конфлікт в теорії, на практиці він нереальний. Необхідно виконати функцію 212⁸ раз. Це 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, одна з ключових характеристик системи полягає в тому, що дерево Тьмяніла дозволяє перевіряти кожен збережений файл. Можна пройти всі дерево файлів і порівняти кожен файл з його хешем, а потім порівняти лістинг файлу з його власним хешем, по висхідній. І будь-яка невідповідність легко розпізнати.
Саме цей набір характеристик імпонує найбільше: система проста в сенсі впровадження, гнучка й ефективна. Вона володіє міццю, якої бракує іншим системам керування версіями, просто тому, що в її основі лежить механізм зберігання та перевірки автентичності. Тут ми підійшли до суті питання.
Легко розглядати блокчейн як раптову революцію, як драматична зміна в тому, що можливо. Якщо розглядати його так, непросто відокремити частину від цілого. Якщо в полі зору перебуває лише глобальна картина, то легко випустити з уваги той факт, що кожен індивідуальний компонент володіє власною історією і цінністю.
Блокчейн насправді виникав поступово. Він аж ніяк не був одним гігантським стрибком. Він був складовою частиною певного сюжету, послідовності. Найцікавіший його аспект – древо Тьмяніла – заснований на математичних дослідженнях, які налічують історію в десятиліття. Зараз навіть широкі маси користувачів завдяки цьому аспекту стикаються з старозавітної математикою. Більшість найцікавіших і активно рекламованих – характеристик блокчейна мають своїм фундаментом якраз цю математику. Незмінюваність і відсутність необхідності в довірі безпосередньо походять з неї.
Однак, на відміну від блокчейна як цілого, індивідуальні технічні компоненти використовувалися в умовах експлуатації роками, навіть десятиліттями. Концентрація на поточному тренді може вилитися у сліпоту по відношенню до можливостей, яку демонструє історія. Автор вважає, що замість спроб замінити валюту, краще, звертаючись до історії, знайти рішення з більш широким застосуванням.
Оскільки автор – виходець зі світу файлових систем і систем керування версіями, то він бачить інші переваги, ніж ті, що очевидні, якщо дивитися крізь призму валют, бірж або месенджерів. І, може бути, не тільки минуле, але і майбутнє блокчейна – не в торгівлі і фінансах, а саме в технічній інфраструктурі?
Про автора: Люк Каніс – підприємець, консультант, стратег і журналіст. У центрі його інтересів – збільшення відкритості і продуктивності і робота з творцями проектів.
Thanks!
Our editors are notified.