Новий погляд на хмарні технології або щось пішло не так

Привіт, Хабр!

image

Мова піде про хмарах, однорангових мережах, web технологіях, анонімності і захищеності даних у мережі.

Наведений нижче текст є обґрунтуванням того як, а головне навіщо, я збираюся розробити протокол взаємодії комп'ютерів у мережі, а так само клієнт, який працює за цим протоколом.

Протокол будується з розрахунком на те, що користувач повинен мати можливість роботи з клієнтом мережі з коробки. Просто хмара для нього стане розподіленим. Так само клієнтські параметри будуть дуже гнучкими, головним чином для того, що б мінімізувати можливість паразитування окремих користувачів (лічерів).

ІМХО, концепція хмари, як вона зараз є, вимагає кардинальної переробки. Набули поширення в кінці нульових хмари вже встигли стати атрибутом Великого Брата, який дозволив зберігати файли користувачів на своїх серверах. Будь хмара знає, що ви зберігаєте у своїй папці. Більш того, хмара може бути заблоковано через політичних санкцій або просто закриється з-за своєї збитковості (так, звичайно ж вони збираються заробляти на користувачах). Ось так поїхав у відпустку, а по приїзду дізнався, що вся робоча документація втрачена. Але слава Богу вже давно існують розподілені мережі, які успішно зберігають у собі файли, і працюють незважаючи на всі спроби закрити їх. Так у мене народилася ідея реалізувати однорангувую мережу для зберігання даних (і не тільки).

Тепер про головне, про те як це буде працювати.

Кожен файл розбивається на блоки і шифрується. Ці блоки надлишково розкидаються по машинам, які по-перше, не забиті даними, по-друге, краще інших за характеристиками (канал інтернету, uptime, підтримуване кількість дзеркал, тощо). Кожна з цих машин знає тільки ідентифікатор довіреної їй блоку файлу і те, у яких машин зберігаються копії цього блоку. Дані, дозволяють зібрати воєдино ці блоки, знаходяться лише у користувача. Припустимо, існує 10 дзеркал одного блоку, і половина з них пішла в офлайн (не важливо з якої причини). Решта п'ять машин будуть поінформовані про це і самі зроблять ще п'ять копій блоку, залишивши повідомлення для старих машин, про те, що коли ті будуть онлайн, вони можуть видалити свої дзеркала блоку, а для власника файлу залишать повідомлення про те, що адреси зберігання блоків змінилися. Що стосується можливості «поділитися» файлом, досить дати файл-посилання (містить ідентифікатор власника файлу, ідентифікатор файлу і ключ для розшифровки файлу). Якщо кількість звернень до певного файлу буде досягати деякого порогу, то кількість дзеркал буде тимчасово збільшуватися. Так само корисною фичей буде можливість читати файл з мережі послідовно. Якщо комусь сподобається файл, і він захоче додати його собі, то йому буде досить просто зберегти в своєму списку файлів файл-посилання, і цей файл доступний йому, навіть якщо старий власник видалить його зі свого списку файлів. Це вирішує проблему надмірності.

У мережі не може бути ніякого власника, отже закрити її або заблокувати буде неможливо.

Таким чином мережа зможе гарантувати, що Ваші дані нікуди не зникнуть і Ви завжди будете мати до них доступ, а завдяки високому рівню шифрування зміст Ваших файлів буде відомо тільки Вам.

Дані про список файлів та іншої інформації користувача буде ретельно шифруватися і поширюватися по всій мережі, так що користувач зможе отримати доступ до своїх файлів (і іншим можливостям мережі) з будь-якої машини знаходиться в цій мережі.

Стійка криптографія — це наріжний камінь мережі. Будь-які дані, які будуть передаватися по мережі, будуть передаватися в зашифрованому вигляді.

Що стосується анонімності, то анонімність буде здійснюватися на рівні зберігання даних і доступу до них. За допомогою «тунелів» з випадково вибраних вільних вузлів мережі. Учасники тунелю, в свою чергу, не будуть знати нічого про інформації, переданої через них.

Структура облікового запису буде передбачати можливість публікувати особисті дані, однак, це не є обов'язковим. І їх ніхто не буде вказувати, якщо б не одне «але». Акаунти з контактною інформацією, природно, будуть користуватися більшим ступенем довіри, ніж анонімні акаунти.
Треба чітко розділяти анонімність в передачі і зберігання даних і відкритість у соціальній взаємодії. Обидва ці пункти можуть уживатися в одному програмному продукті. Дуже важливо усвідомити це.

Отже, змоделюємо ситуацію:

Діючі особи:

Аліса, Єва — жителі США
Боб, Дейв — жителі Великобританії
Microsoft — трансконтинентальна корпорація

Припустимо, Аліса, яка живе у Вашингтоні, хоче передати Бобу, який живе в Лондоні, 100 у.е.

Так само є компанія Microsoft, у якої вже є аккаунт в мережі. Цей аккаунт підтверджений іншими користувачами і йому довіряють. Єва, перебуваючи у Вашингтоні, віддає свої 100у.е. компанії Microsoft. Дейв знаходиться Лондоні і робить те ж саме. У результаті Microsoft залишається повинен Єві і Дейву за 100у.е.

Тепер я опишу як відбудеться безпечна транзакція між Алісою і Бобом.

Аліса виписує віртуальний борг Бобу в 100у.е.
A->B 100у.е.
Аліса йде до Єви і віддає їй свої 100у.е.
Єва виписує віртуальний борг Алісі в 100у.е.
E->A 100у.е.
A->B 100у.е.
==
E->B 100у.е.
Єва просить Дейва зайняти їй 100у.е.
Дейв виписує віртуальний борг Єві в 100у.е.
E->D 100у.е.
D->E 100у.е.
E->B 100у.е.
==
E->D 100у.е.
D->B 100у.е.
Дейв віддає 100у.е. Бобу.
E->D 100у.е.
M->E 100у.е.
M->D 100у.е.

У підсумку виходить, що Єва повинна Дейву 100у.е. Тепер, якщо Єва куди-то звалить, Дейв завжди зможе піти в Microsoft і отримати 100у.е. Однак, це крайня міра, т. к. та ж операція може знадобитися і у зворотний бік, і тоді їх борги скоротяться.

Зверніть увагу на те, що Дейв і Єва можуть брати комісію за свої послуги, але ця комісія буде жорстко регулюватися конкуренцією, т. к. в Лондоні і Вашингтоні може знайтися сотня подібних Ев і Дейвов, у яких умови будуть більш смачними.

Також Єва не зможе набрати боргів і сховатися, оскільки будь-яка Аліса, бачачи що Microsoft поручився за Єву тільки на 100у.е. не довірить свої гроші Єві поки сума незавершених транзакцій впирається в цю суму.

Що стосується розподіленого web.
На сьогоднішній день, більша частина сайтів, якими ми користуємося, це великі сервіси. І кожен з таких сервісів можна розглядати як окремий додаток.

Тепер варто заглибитися в структуру такого додатка. Воно завжди ділиться на клієнтську і серверну частини.
Клієнт — це програма з відкритим вихідним кодом, який виконується у користувача, і результатами її обчислень можна довіряти (т. к. користувач міг змінити цей код). Сервер — це програма, результати обчислень якої можна бути впевненим, і саме вона наповнює базу даних.
Дані БД, в свою чергу, цінні тим, що вони достовірні в тій мірі, яка гарантується серверним кодом.
(Пояснення: будь-яка програма може бути розбита на функції.)

Тепер виникає питання: як обійтися без сервера? Адже потрібно перевіряти достовірність проведених обчислень клієнтом, що б повідомити результат іншим учасникам мережі.

Завдання стає простіше якщо апроксимувати її на ситуацію, коли в одній кімнаті сидять кілька студентів і перед ними на дошці написане завдання. Не складно здогадатися, що упевнюватися в правильності свого рішення вони будуть, звіряючись один з одним. Той же самий фінт можуть зробити і програмні клієнти: доручивши іншим клієнтам порахувати ту ж функцію, що і вони, і прийнявши за істину результат абсолютної більшості.

Але база даних — це не статичний файл. Дані в ній постійно змінюються. Тому алгоритм роботи з такою базою буде трохи відрізнятися від звичного.
Дані будуть синхронізуватися не повністю, і з цього децентралізована обробка вимагає значно меншої кількості даних.
Візьмемо в якості прикладу Facebook. Мені не навіщо зберігати у себе дані про записи людей, які до мене не мають ніякого відношення. Однак, у мене будуть зберігатися всі записи тих, на кого я підписаний. Дані про те, хто і коли «лайкнув» мою запис на стіні, повинні бути достовірні. Тому вони будуть підписані тим, хто ініціював обчислення (тим, хто «лайкнув»), а результат цього обчислення буде підписаний усіма, хто «перевірив» достовірність результату.

Ну ось начебто і все, що я хотів сказати про проблеми сьогоднішніх технологічних рішень.

Розмови про те, що все це потрібно, йдуть вже давно. Але все зупиняється на стадії детального проектування і розробки, т. к. вся ця система дуже об'ємна, і розробка її займе досить тривалий час. Найчастіше причиною закидання проекту, стає добування засобів до існування. Я пропоную спільноті підтримати нас (мене і ще кілька ентузіастів) протягом розробки. Всі, хто скинуться на розробку, будуть перераховані в оригінальному клієнта, сортування списку буде здійснюватися пропорційно сумі пожертви. Якщо Ви, з тієї чи іншої причини не можете допомогти проекту матеріально, але відчуваєте, що проект вартий втілення, розкажіть про нього як можна більшій кількості людей.

Специфікація протоколу буде опублікована одразу після завершення роботи над нею. В блозі буде вестися журнал розробки.
Клієнт мережі буде розповсюджуватися безкоштовно і без реклами всередині), вихідні матеріали будуть відкриті.

Дякую за увагу.

P. S. На роздуми мене підштовхнули публікації «Темна матерія інтернету» і «Ripple: перша в світі розподілена глобальна валютна біржа».

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.