Від IPFS до Ceramic: майбутнє мережі передачі даних Web3

Недолік IPFS
Коли мова заходить про децентралізоване зберігання даних, InterPlanetary File System, відома як IPFS, є проектом, який неможливо обійти.
Будучи одним із найвідоміших проектів децентралізованого зберігання даних, IPFS використовує структуру даних Merkle DAG (Directed Acyclic Graph), модифікацію на основі дерева Merkle. За допомогою цієї структури даних IPFS реалізує адресацію вмісту та завантаження фрагментів файлів.
Зокрема, IPFS призначає кожному файлу унікальне хеш-значення, подібне до відбитка файлу. Кожен кореневий файл вказує на кілька файлів вузла, і як тільки вміст файлу вузла змінюється, хеш-значення змінюється відповідно, внаслідок чого хеш кореневого файлу також змінюється.
Таким чином IPFS зберігає та знаходить файли в унікальній адресації на основі вмісту, а не на основі адреси. Це означає, що якщо ви шукаєте файл, вам не потрібно знати, де він знаходиться, а лише те, що він містить. IPFS генерує унікальний хеш для кожного файлу, і коли користувачеві потрібно отримати цей файл, йому потрібно лише попросити IPFS, який має цей хеш, завершити отримання. Оскільки хеші запобігають повторюваному зберіганню, файли з однаковим вмістом не дублюються IPFS. Цей підхід оптимізує зберігання та покращує продуктивність мережі.
Механізм адресації контенту є основною перевагою IPFS, але у кожної медалі є дві сторони, є й недолік. У IPFS після збереження файлу його неможливо змінити в системі, оскільки зміна вмісту файлу змінює хеш файлу, і користувач не може знайти змінений файл за оригінальним хеш-значенням. Це проблема, яка широко критикується: IPFS не підходить для зберігання файлів, які час від часу потрібно оновлювати та змінювати.
Незважаючи на те, що IPFS добре працює для зберігання статичних файлів, їй не вистачає можливостей обчислення та керування станом для більш просунутих функцій, подібних до бази даних, таких як змінюваність, контроль версій, контроль доступу та програмована логіка, які необхідні розробникам для створення повнофункціональних децентралізованих програми. Тому існує нагальна потреба в ефективному та децентралізованому рішенні для зберігання динамічних даних — Ceramic вирішує цю проблему за допомогою бази даних, схожої на NoSQL, для розробників, щоб зберігати структурований і змінний вміст.
Створено для змінного вмісту
Конструкція зберігання Ceramic базується на IPFS і розширює його за допомогою децентралізованого рівня динамічного зберігання.
На Ceramic кожна частина інформації представлена ​​як журнал комітів лише для додавання, який називається «Потік», який показано як комбінація сірих квадратів на малюнку нижче. Концепція Stream схожа на дерева Git: початковий стан (Genesis Commit) і кожна наступна зміна (Commit) зберігаються в IPLD (InterPlanetary Linked Data, рівень IPFS, призначений для структур даних), і ці записи об’єднуються, щоб сформувати Потік. Оскільки Потоки записують «зміни», а не «миттєві знімки» кінцевого стану, необхідно лише обробити всі події в Потоці, щоб отримати останній стан журналу.
Наприклад, схема запису Ceramic така: спочатку Аліса та Боб мають по 10 доларів; на другий день Аліса перераховує 5 доларів Бобу; на третій день Боб переказує 3 долари Алісі. Це також дуже схоже на реєстр блокчейну, де в реєстрі не вказується баланс кожного користувача, а всі проміжні процеси потрібно розрахувати, щоб отримати остаточний баланс користувача.
Для порівняння, традиційний шаблон запису IPFS такий: у файлі а Аліса та Боб мають по 10 доларів; у файлі b Аліса має 5 доларів, а Боб має 15 доларів; а у файлі c Аліса має 8 доларів, а Боб має 12 доларів. Тут кожен запис є знімком отриманого стану, і новий знімок потрібно створити, щойно відбудуться зміни.
Ця конструкція Ceramic гарантує, що кожен журнал має унікальний ідентифікатор потоку з глобальним уніфікованим іменуванням і не змінює назву через зміни вмісту. Кожен запис вимагає авторизації користувача, і весь процес подібний до бухгалтерського обліку в блокчейні, за винятком того, що записуються не дані транзакцій, а інший змінний вміст, наприклад інформація про обліковий запис користувача.
Компонування даних
Ceramic досягає можливості комбінування даних у різних програмах, насамперед завдяки використанню нової абстракції, яка називається моделями даних.
Моделі даних зазвичай представляють одну логічну функцію програми, таку як профіль користувача, соціальний графік або блог. Наприклад, ви можете уявити, що кожна децентралізована реалізація Twitter працюватиме на кількох спільних моделях даних: одна для твітів кожного користувача, одна для їхнього соціального графіка, одна для їхніх DM тощо. Прийнявши ті самі основні моделі даних, програми можуть для внутрішньої взаємодії з тими самими даними.
У певному сенсі ви можете порівняти використання Ceramic стандартів моделі даних із використанням стандартів токенів для бухгалтерських книг активів. В Ethereum, наприклад, впровадження стандартів взаємозамінного токена ERC20 і незамінного токена ERC721 призвело до появи цілих екосистем токенів і фінансових додатків, які безпосередньо взаємодіють. Кераміка переносить цю саму концепцію на дані.
Ceramic використовує підхід до створення цих моделей даних, керований спільнотою, що дозволяє будь-якому розробнику легко визначати, ділитися та повторно використовувати свої моделі з іншими розробниками в екосистемі. У міру того, як спільнота створить більше моделей даних, ви побачите безперервне розширення кількості та різноманітності додатків, створених із складеними даними.
Компонування, виконане таким чином, також покращує роботу розробника. Створення програми на Ceramic виглядає як перегляд ринку моделей даних, підключення їх до вашої програми та автоматичне отримання доступу до всіх даних у мережі, які зберігаються в цих моделях. Використовуючи Ceramic, розробникам не потрібно буде турбуватися про початкове завантаження своєї програми за допомогою власних ізольованих користувачів і даних. Швидкість поєднання інновацій серед розробників різко прискориться.
Масштабованість
Ceramic досягає масштабованості завдяки сегментованому середовищу виконання. Усі потоки на Ceramic підтримують свій стан незалежно, а вузли мережі виконують потокові транзакції паралельно. Цей підхід, на відміну від більшості блокчейнів, дозволяє Ceramic працювати з масштабованістю, необхідною для децентралізованих версій соціальних програм, таких як Twitter або Facebook.
На відміну від традиційних блокчейн-систем, де масштабованість обмежена єдиним глобальним віртуальним середовищем виконання, а стан однієї книги розподіляється між усіма вузлами, кожен вузол Ceramic діє як окреме середовище виконання для виконання обчислень і перевірки транзакцій у потоках — глобального немає. бухгалтерська книга. Це «вбудоване» сегментування виконання дозволяє масштабувати Ceramic Network горизонтально, щоб розпаралелювати обробку все більшої кількості одночасних потокових транзакцій у міру збільшення кількості вузлів у мережі. Така конструкція необхідна для обробки масштабу світових даних, який на порядки перевищує пропускну здатність, необхідну для фінансового блокчейну. Ще одна перевага цього дизайну полягає в тому, що вузол Ceramic може виконувати потокові транзакції в автономному середовищі, а потім пізніше синхронізувати оновлення з рештою мережі, коли він повертається в режим онлайн.
DID Рішення
Ceramic також пропонує гнучке та надійне рішення ідентифікації під назвою IDX, перше повнофункціональне рішення децентралізованої ідентифікації (DID).
IDX — це міжланцюжковий протокол ідентифікації для відкритих додатків із децентралізованою ідентифікацією та сумісними даними користувача, який дозволяє користувачам створювати уніфіковану цифрову ідентифікацію, що складається з усіх їхніх даних, а також дозволяє розробникам розбивати роз'єми та вільно обмінюватися даними користувача між програмами. Як показано на малюнку нижче, він забезпечує децентралізований індекс, який дозволяє зв’язувати структуровані дані з децентралізованим ідентифікатором (DID), а дані визначаються визначеннями та зберігаються в записах.
Крім того, IDX можна використовувати з будь-яким типом сховища даних, таким як Ceramic, Textile, OrbitDB, IPFS, Sia, Arweave, блокчейн-реєстрами або навіть централізованими базами даних і підтримує автентифікацію з будь-якого гаманця Web3.
IDX чудово підходить для децентралізованого зв’язування профілів користувачів, переносних соціальних графіків, показників репутації, підтверджених тверджень, створеного користувачами вмісту, даних програм, налаштувань, доменних імен, адрес у блокчейні та соціальних облікових записів Web2.
Висновок
Таким чином, поява Ceramic значно розширила можливості створення Web3 і розблокувала нові функції для розробників Web3. Незалежно від того, який публічний блокчейн (Ethereum, BSC, Polygon, Avalanche тощо) розробники будують, вони можуть одночасно використовувати Ceramic для функцій, орієнтованих на дані, щоб покращити свої програми. Крім того, через гнучку систему облікових записів Ceramic на основі DID, Ceramic природним чином взаємодіє з обліковими записами та ключовими системами поточних основних блокчейнів, що забезпечує користувачам велику зручність.
Приємно бачити, що вже є багато проектів соціальних платформ DID і Web3, розроблених на Ceramic. Серед них можна назвати кілька проектів, які заслуговують на увагу: CyberConnect, платформа проміжного програмного забезпечення для соціальних графів; Orbis, платформа Web3 Twitter; і The Convo Space, платформа обміну миттєвими повідомленнями тощо. Ми з нетерпінням чекаємо нових можливостей, які інфраструктура мережі даних Ceramic може привнести на прикладний рівень Web3.
Відмова від відповідальності: це дослідження призначено лише для інформаційних цілей. Він не є інвестиційною порадою чи рекомендацією щодо купівлі чи продажу будь-яких інвестицій і не повинен використовуватися для оцінки достоїнств прийняття будь-якого інвестиційного рішення.
🐦 @chestersigned
📅 8 травня 2022 р
Посилання:
https://developers.ceramic.network/learn/welcome/
https://blog.ceramic.network/what-is-ceramic/
https://multicoin.capital/2022/02/16/the-composable-web3-data-network/
https://blog.ipfs.io/2021-07-13-ceramic-mainnet-launch/