1. На ранній стадії блокчейна підтримка узгодженості даних вважається надзвичайно важливою для забезпечення безпеки та децентралізації. Однак із розвитком екосистеми блокчейну тиск на зберігання також зростає, що призводить до тенденції централізації роботи вузлів. У такому випадку необхідно терміново вирішити проблему вартості зберігання, спричинену зростанням TPS на рівні 1.
2. Зіткнувшись із цією проблемою, розробники повинні запропонувати рішення, яке повністю враховує безпеку, вартість зберігання, швидкість читання даних і універсальність рівня DA.
3. У процесі вирішення цієї проблеми з’явилося багато нових технологій та ідей, зокрема Sharding, DAS, Verkle Tree, проміжні компоненти DA тощо. Вони намагаються оптимізувати схему зберігання рівня DA шляхом зменшення надмірності даних і підвищення ефективності перевірки даних.
4. Рішення DA загалом класифікуються на два типи з точки зору місця зберігання даних, а саме: DA основного ланцюга та сторонні DA. DA основного ланцюга розроблені з точки зору регулярного очищення даних і зберігання фрагментованих даних, щоб зменшити тиск на зберігання на вузлах, тоді як DA сторонніх виробників розроблено для задоволення потреб у сховищі та мають розумні рішення для великих обсягів даних. У результаті ми в основному знаходимо компроміс між сумісністю з одним ланцюгом і сумісністю з кількома ланцюжками в сторонніх DA і пропонуємо три типи рішень: DA для основного ланцюга, модульні DA та публічні DA для зберігання.
5. Публічні ланцюжки платіжного типу мають дуже високі вимоги до безпеки історичних даних і тому підходять для використання в основному ланцюзі як рівень DA. Однак для загальнодоступних ланцюжків, які працюють протягом тривалого часу та мають велику кількість майнерів, що керують мережею, краще прийняти сторонній DA, який не включає зміну консенсусного рівня з відносно високим рівнем безпеки. Для всеосяжних публічних ланцюгів краще використовувати виділене сховище DA головного ланцюга з більшою ємністю даних, нижчою ціною та безпекою. Однак, враховуючи попит на крос-ланцюги, модульний DA також є хорошим варіантом.
6. Загалом блокчейн рухається до зменшення надмірності даних, а також багатоланцюгового розподілу праці.

1. Фон

Будучи розподіленою книгою, блокчейн повинен зберігати історичні дані на всіх вузлах, щоб забезпечити безпеку та достатню децентралізацію зберігання даних. Оскільки правильність кожної зміни стану пов’язана з попереднім станом (джерелом транзакції), щоб забезпечити коректність транзакцій, блокчейн повинен, у принципі, зберігати всі історичні записи від першої транзакції до поточної транзакції. Якщо взяти Ethereum як приклад, навіть якщо середній розмір блоку оцінюється в 20 Кб, поточний загальний розмір блоків Ethereum досяг 370 ГБ. Окрім самого блоку, повний вузол також повинен записувати статус і квитанції про транзакції. Враховуючи цю частину, загальна ємність пам’яті одного вузла перевищила 1 ТБ, що зосереджує роботу вузла декільком людям.

Остання висота блоку Ethereum, джерело зображення: Etherscan

2. Показники ефективності ДА

2.1 Безпека

Порівняно з базами даних або структурами зберігання зв’язаних списків, непорівнянність блокчейна пояснюється здатністю перевіряти щойно згенеровані дані за допомогою історичних даних. Таким чином, забезпечення безпеки історичних даних є першим питанням, яке слід розглянути в сховищі рівня DA. Оцінюючи безпеку даних у системах блокчейн, ми часто аналізуємо її за кількістю надлишкових даних і методом перевірки доступності даних.

1. Рівень надлишковості: Що стосується надлишковості даних у системі блокчейну, вона може головним чином виконувати такі ролі: По-перше, якщо кількість надлишкових даних у мережі більша, коли верифікатору потрібно переглянути статус облікового запису в певному історичному блоці, щоб verify Коли транзакція перевіряється, вона може отримати більшість зразків для довідки та вибрати дані, записані більшістю вузлів. У традиційних базах даних, оскільки дані зберігаються лише у формі пар ключ-значення на певному вузлі, зміни історичних даних можна зробити лише на одному вузлі, а вартість атаки надзвичайно низька. Теоретично, чим більша кількість надлишків, тим меншою ймовірністю будуть дані. Чим вище ступінь достовірності. У той же час, чим більше вузлів зберігається, тим менша ймовірність втрати даних. Це також можна порівняти з централізованим сервером, який зберігає ігри Web2. Після вимкнення всіх внутрішніх серверів сервер буде повністю вимкнено. Однак чим більше, тим краще, тому що кожна надлишкова частина принесе додатковий простір для зберігання. Надмірна надмірність даних призведе до надмірного тиску на зберігання в системі. Хороший рівень DA повинен вибрати відповідний. Резервний підхід збалансовує безпеку та ефективність зберігання.
2. Перевірка доступності даних: кількість резервів гарантує наявність достатньої кількості записів даних у мережі, але точність і повнота даних, які будуть використовуватися, повинні бути перевірені. Зазвичай використовуваним методом перевірки в поточному блокчейні є алгоритм криптографічного зобов’язання, який зберігає невелике криптографічне зобов’язання для запису всієї мережі. Це зобов'язання отримано шляхом змішування даних транзакцій. Якщо ви хочете перевірити автентичність певної частини історичних даних, вам потрібно відновити криптографічне зобов’язання за допомогою даних і перевірити, чи криптографічне зобов’язання, отримане цим відновленням, узгоджується із записами всієї мережі. Якщо він відповідний, перевірка пройдена. Зазвичай використовувані алгоритми перевірки криптографії включають Verkle Root і Verkle Root. Алгоритм перевірки доступності даних високого рівня безпеки вимагає лише невеликої кількості даних перевірки та може швидко перевірити історичні дані.

2.2 Вартість зберігання

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

2.3 Швидкість читання даних

Після досягнення скорочення витрат наступним кроком є підвищення ефективності, яка є здатністю швидко викликати дані з рівня DA, коли їх потрібно використовувати. Цей процес складається з двох етапів. Перший — пошук вузлів, які зберігають дані. Цей процес в основному призначений для загальнодоступних мереж, які не досягли узгодженості даних у всій мережі. Якщо публічний ланцюг досягає синхронізації даних для вузлів у всій мережі, це можна проігнорувати. Витрата часу на процес. По-друге, у поточних основних блокчейн-системах, включаючи Bitcoin, Ethereum і Filecoin, методом зберігання вузлів є база даних Leveldb. У Leveldb дані зберігаються трьома способами. По-перше, дані, записані негайно, зберігатимуться у файлах типу Memtable. Коли сховище Memtable буде заповнено, тип файлу буде змінено з Memtable на Immutable Memtable. Обидва типи файлів зберігаються в пам’яті, але файли Immutable Memtable більше не можна змінити, з них можна лише зчитувати дані. Гаряче сховище, яке використовується в мережі IPFS, зберігає дані в цій частині. При його виклику його можна швидко прочитати з пам'яті. Однак мобільна пам'ять звичайного вузла часто становить ГБ, і записувати його легко повільно. Коли вузол аварійно завершує роботу або виникає інша ненормальна ситуація, дані в пам'яті буде остаточно втрачено. Якщо ви хочете, щоб дані зберігалися постійно, вам потрібно зберегти їх у формі файлу SST на твердотільному накопичувачі (SSD). Однак під час зчитування даних вам потрібно спочатку прочитати дані в пам’ять, що значно знижує швидкість індексації даних. Нарешті, для систем, які використовують спільне сховище, відновлення даних вимагає надсилання запитів на дані до кількох вузлів і їх відновлення. Цей процес також зменшить швидкість читання даних.

Метод зберігання даних Leveldb, джерело зображення: довідник Leveldb

2.4 DA Узагальнення

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

3. Методи щодо DA

3.1 Шардинг

1. У традиційній розподіленій системі файл не зберігається в повному вигляді на певному вузлі. Замість цього вихідні дані розділені на кілька блоків, і один блок зберігається в кожному вузлі. Блоки часто не зберігаються лише на одному вузлі, але залишають відповідні резервні копії на інших вузлах. У існуючих основних розподілених системах ця кількість резервних копій зазвичай дорівнює 2. Цей механізм шардингу може зменшити навантаження на сховище окремого вузла, збільшити загальну ємність системи до суми ємності сховища кожного вузла, а також в той же час забезпечити безпеку зберігання через відповідне резервування даних. Схема шардингу, прийнята в блокчейні, загалом схожа, але конкретні деталі відрізнятимуться. Перш за все, оскільки кожен вузол у блокчейні є ненадійним за замовчуванням, процес впровадження шардингу вимагає достатньо великого обсягу резервного копіювання даних для подальшого оцінювання автентичності даних, тому кількість резервних копій для цього вузла має бути набагато більше двох. В ідеалі в системі блокчейн, що використовує цю схему зберігання, якщо загальна кількість вузлів перевірки дорівнює T, а кількість шардів дорівнює N, то кількість резервних копій має бути T/N. По-друге, це процес зберігання Блоку. У традиційних розподілених системах менше вузлів, тому один вузол часто адаптується до кількох блоків даних. Спочатку дані відображаються в хеш-кільці за допомогою узгодженого алгоритму хешування, а потім кожен вузол зберігає блоки даних, пронумеровані в певному діапазоні, і може прийняти, що вузол не розподіляє завдання зберігання під час певного зберігання. У блокчейні те, чи кожному вузлу присвоєно блок, більше не є випадковою подією, а неминучою подією. Кожен вузол випадковим чином вибере блок для зберігання. Цей процес поєднує вихідні дані з інформацією про блок і вузол. Результат хешування даних доповнюється вирахуванням модуля кількості фрагментів. Якщо припустити, що кожна частина даних розділена на N блоків, фактичний розмір зберігання кожного вузла становить лише 1/N від початкового. Правильно встановивши N, можна досягти балансу між зростаючим TPS і тиском зберігання на вузлі.

Спосіб зберігання даних після шардингу, джерело зображення: Kernel Ventures

3.2 DAS（Вибірка доступності даних）

Технологія DAS базується на подальшій оптимізації методів зберігання Sharding. Під час процесу шардингу через просте довільне зберігання вузлів певний Блок може бути втрачено. По-друге, для фрагментованих даних також дуже важливо підтвердити автентичність і цілісність даних під час процесу відновлення. У DAS ці дві проблеми вирішуються за допомогою коду Eraser і поліноміального зобов’язання KZG.

1. Код Eraser: враховуючи величезну кількість вузлів перевірки в Ethereum, ймовірність того, що певний Блок не зберігається жодним вузлом, майже дорівнює 0, але теоретично така екстремальна ситуація все ще існує. Щоб пом’якшити цю можливу загрозу втрати пам’яті, за цією схемою вихідні дані часто не діляться безпосередньо на блоки для зберігання. Замість цього вихідні дані спочатку зіставляються з коефіцієнтами полінома n-го порядку, а потім 2n береться з полінома. точок, і дозвольте вузлу випадковим чином вибрати одну з них для зберігання. Для цього полінома n-го порядку потрібно лише n+1 точок, щоб відновити його. Тому тільки половина блоків повинна бути виділена вузлами, і ми зможемо відновити вихідні дані. За допомогою коду Eraser покращено безпеку зберігання даних і можливість відновлення даних у мережі.
2. Дуже важливим аспектом зберігання даних є перевірка достовірності даних. У мережах, які не використовують код Eraser, для перевірки можна використовувати різні методи, але якщо код Eraser, наведений вище, вводиться для покращення безпеки даних, тоді доцільніше використовувати поліноміальне зобов’язання KZG, яке може перевіряти вміст одного блокувати безпосередньо у формі полінома, таким чином усуваючи необхідність зводити поліном до двійкових даних. Поліноміальне зобов’язання KZG може безпосередньо перевіряти вміст окремого блоку у формі поліномів, таким чином усуваючи необхідність зводити поліноми до двійкових даних, а загальна форма перевірки схожа на форму Merkle Tree, але не потребує спеціальних Дані вузла шляху, для перевірки автентичності блоку потрібні лише дані кореня KZG і дані блоку.

3.3 Метод перевірки даних у DA

Перевірка даних гарантує, що дані, викликані з вузла, точні та повні. Для мінімізації обсягу даних і обчислювальних витрат, необхідних у процесі перевірки, рівень DA тепер використовує деревоподібну структуру як основний метод перевірки. Найпростішою формою є використання Merkle Tree для перевірки, яка використовує форму повних бінарних записів дерева, потрібно лише зберегти Merkle Root і хеш-значення піддерева на іншій стороні шляху вузла, можна перевірити, часова складність перевірки становить O(logN) рівня (logN за замовчуванням log2(N)). Незважаючи на те, що процес перевірки значно спростився, обсяг даних для процесу перевірки в цілому все ще зростає зі збільшенням даних. Щоб вирішити проблему збільшення обсягу перевірки, на цьому етапі пропонується інший метод перевірки, Verkle Tree, у якому кожен вузол у Verkle Tree не лише зберігає значення, але також додає векторне зобов’язання, яке може швидко підтвердити автентичність даних, використовуючи значення вихідного вузла та підтвердження зобов’язання, без необхідності викликати значення інших вузлів-сестерів, що робить обчислення кожної перевірки легшим і швидшим. Це робить кількість обчислень для кожної перевірки пов’язаною лише з глибиною дерева Веркле, яка є фіксованою константою, що значно прискорює швидкість перевірки. Однак обчислення Vector Commitment вимагає участі всіх сестринських вузлів на одному рівні, що значно збільшує вартість запису та зміни даних. Однак для таких даних, як історичні дані, які постійно зберігаються і не можуть бути підроблені, а також їх можна лише читати, але не записувати, дерево Веркле надзвичайно підходить. Крім того, дерево Merkle та саме дерево Verkle мають K-ічну форму варіантів, конкретна реалізація механізму схожа, просто змініть кількість піддерев під кожним вузлом, конкретне порівняння продуктивності можна побачити в наступній таблиці.

Порівняння часових характеристик методів перевірки даних, джерело зображення: Verkle Trees

3.4 Загальне проміжне програмне забезпечення DA

Постійне розширення екосистеми блокчейнів призвело до постійного збільшення кількості публічних мереж. Завдяки перевагам і незамінності кожного публічного ланцюга у відповідних галузях, публічним ланцюгам рівня 1 майже неможливо об’єднатися за короткий час. Однак із розвитком DeFi та різними проблемами з CEX вимоги користувачів до активів децентралізованої міжланцюжкової торгівлі також зростають. Тому все більше уваги приділяється багатоланцюжковому сховищу даних на рівні DA, яке може усунути проблеми безпеки під час міжланцюгової взаємодії даних. Однак, щоб приймати історичні дані з різних загальнодоступних ланцюжків, рівень DA повинен забезпечити децентралізований протокол для стандартизованого зберігання та перевірки потоків даних. Наприклад, kvye, проміжне програмне забезпечення для зберігання на основі Arweave, активно захоплює дані з ланцюжка, і всі Дані в ланцюжку зберігаються в Arweave в стандартній формі, щоб мінімізувати відмінності в процесі передачі даних. Відносно кажучи, Layer2, який спеціально забезпечує зберігання даних рівня DA для певного публічного ланцюжка, взаємодіє з даними через внутрішні спільні вузли. Хоча це зменшує вартість взаємодії та покращує безпеку, воно має відносно великі обмеження та може надавати дані лише певним публічним мережам, які надають послуги.

4. Способи зберігання ДА

4.1 Головний ланцюг DA

4.1.1 Схожий на DankSharding

Цей тип рішення для зберігання даних ще не має чіткої назви, і найвідомішим представником є DankSharding на Ethereum, тому в цій статті для позначення цього типу рішення використовується клас DankSharding. Цей тип рішення в основному використовує дві технології зберігання DA, згадані вище, Sharding і DAS. Спочатку дані поділяються на відповідні частки за допомогою шардингу, а потім кожен вузол витягує блок даних у формі DAS для зберігання. Якщо у всій мережі є достатня кількість вузлів, ми можемо вибрати більшу кількість шардів N, щоб навантаження на сховище кожного вузла становило лише 1/N вихідного, таким чином досягаючи N-кратного розширення загального простору для зберігання. У той же час, щоб запобігти надзвичайній ситуації, коли певний блок не зберігається в жодному блоці, DankSharding кодує дані за допомогою коду стирання, і лише половину даних можна повністю відновити. Останнім кроком є процес перевірки даних, який використовує деревовидну структуру Verkle та поліноміальне зобов’язання для досягнення швидкої перевірки.

4.1.2 Тимчасове зберігання

Для DA основного ланцюга одним із найпростіших методів обробки даних є зберігання історичних даних у короткостроковій перспективі. По суті, блокчейн відіграє роль загальнодоступної книги, дозволяючи всій мережі спостерігати за змінами вмісту книги без необхідності постійного зберігання. Візьмемо Solana як приклад, хоча її історичні дані синхронізуються з Arweave, головний мережевий вузол зберігає лише дані транзакцій за останні два дні. У загальнодоступному ланцюжку, заснованому на записах облікових записів, історичні дані в кожен момент зберігають остаточний статус облікового запису в блокчейні, чого достатньо, щоб забезпечити базу перевірки для змін у наступний момент. Для проектів, які мають особливі потреби в даних до цього періоду, вони можуть зберігати їх самостійно в інших децентралізованих публічних ланцюжках або в довіреної третьої сторони. Іншими словами, ті, кому потрібні додаткові дані, повинні платити за зберігання історичних даних.

4.2 Сторонній DA

4.2.1 Спеціальний DA для основного ланцюга: EthStorage

1. Основний ланцюжок DA: Найважливішим у рівні DA є безпека передачі даних. Найбільш безпечним на цьому етапі є DA основного ланцюга. Однак сховище основного ланцюга піддається обмеженню простору для зберігання та конкуренції за ресурси. Таким чином, коли кількість мережевих даних швидко зростає, сторонній DA буде кращим вибором, якщо потрібно досягти тривалого зберігання даних. Якщо сторонній DA має більш високу сумісність з основною мережею, він може реалізувати спільне використання вузлів, а також матиме більш високий рівень безпеки під час процесу взаємодії даних. Тому, виходячи з передумови розгляду безпеки, основний ланцюжок DA матиме величезні переваги. Якщо взяти Ethereum як приклад, основна вимога до DA для основного ланцюга — бути сумісною з EVM і забезпечити взаємодію з даними та контрактами Ethereum. Представницькі проекти включають Topia, EthStorage тощо. Серед них EthStorage на даний момент є найбільш розвиненим з точки зору сумісності, оскільки крім сумісності на рівні EVM, він також спеціально налаштував відповідні інтерфейси для підключення до інструментів розробки Ethereum, таких як Remix і Hardhat, для досягнення сумісності на Рівень інструменту розробки Ethereum.
2. EthStorage: EthStorage є загальнодоступним ланцюгом, незалежним від Ethereum, але вузли, що працюють на ньому, перевершують вузли Ethereum. Тобто вузли, на яких працює EthStorage, можуть одночасно запускати Ethereum. Через коди операцій на Ethereum ви можете отримати прямий доступ до EthStorage. EthStorage виконує операції. У моделі зберігання EthStorage лише невелика кількість метаданих зберігається в основній мережі Ethereum для індексації, по суті створюючи децентралізовану базу даних для Ethereum. У поточному рішенні EthStorage реалізує взаємодію між основною мережею Ethereum і EthStorage шляхом розгортання контракту EthStorage в основній мережі Ethereum. Якщо Ethereum хоче зберігати дані, йому потрібно викликати функцію put() у контракті. Вхідними параметрами є двобайтові змінні key і data, де data представляє дані, які будуть зберігатися, а ключ — це їх розташування в мережі Ethereum. Ідентифікацію можна розглядати як подібну до існування CID в IPFS. Після того, як пара даних (ключ, дані) буде успішно збережена в мережі EthStorage, EthStorage згенерує kvldx і поверне його в основну мережу Ethereum і відповідатиме ключу в Ethereum. Це значення відповідає адресі зберігання даних на EthStorage, тому спочатку це можливо. Проблема необхідності зберігати великі обсяги даних тепер полягає у зберіганні однієї пари (ключ, kvldx), що значно знижує вартість зберігання основної мережі Ethereum. . Якщо вам потрібно викликати раніше збережені дані, вам потрібно скористатися функцією get() в EthStorage та ввести параметр ключа. Ви можете швидко шукати дані в EthStorage через kvldx, що зберігається в Ethereum.

Контракт EthStorage, джерело зображення: Kernel Ventures

1. З точки зору того, як саме вузли зберігають дані, EthStorage спирається на модель Arweave. По-перше, велика кількість (k, v) пар з ETH шардується. Кожен шардинг містить фіксовану кількість (k, v) пар даних. Існує також обмеження на конкретний розмір кожної (k, v) пари. Таким чином забезпечується справедливість подальшого робочого навантаження для майнерів у процесі винагороди за зберігання. Для видачі винагороди необхідно спочатку перевірити, чи зберігаються на вузлі дані. Під час цього процесу EthStorage розділить шардинг (розмір рівня ТБ) на багато частин і збереже корінь Verkle в основній мережі Ethereum для перевірки. Потім майнер повинен спочатку надати nonce, щоб згенерувати адреси кількох блоків за допомогою випадкового алгоритму з хешем попереднього блоку на EthStorage. Майнер повинен надати дані цих фрагментів, щоб довести, що він справді зберігає весь шардинг. Але цей одноразовий номер не можна вибрати довільно, інакше вузол вибере відповідний одноразовий номер, який відповідає лише його збереженому фрагменту, і пройде перевірку. Таким чином, цей одноразовий номер має бути таким, щоб значення складності згенерованого блоку відповідало вимогам мережі після змішування та хешування, і лише перший вузол, який надав одноразовий номер і підтвердження довільного доступу, може отримати винагороду.

4.2.2 Модулярність DA: Celestia

1. Модуль Blockchain: на цьому етапі транзакції, які вимагає публічний ланцюг рівня 1, в основному поділяються на такі чотири частини: (1) Розробка базової логіки мережі, вибір вузлів перевірки певним чином, запис блоків і розподіл винагороди операторам мережі; (2) Упаковувати та обробляти транзакції та публікувати пов’язані з ними транзакції; (3) Перевірити транзакції, які будуть завантажені в ланцюг, і визначити остаточний статус; (4) Зберігайте та обслуговуйте історичні дані в блокчейні. Відповідно до різних виконаних функцій ми можемо розділити блокчейн на чотири модулі, а саме рівень консенсусу, рівень виконання, рівень розрахунків і рівень доступності даних (рівень DA).
2. Модульний дизайн блокчейна: протягом тривалого часу ці чотири модулі були інтегровані в загальнодоступний ланцюг. Такий блокчейн називається єдиним блокчейном. Ця форма є більш стабільною та легшою в обслуговуванні, але вона також чинить величезний тиск на один публічний ланцюг. Під час фактичної роботи ці чотири модулі обмежують один одного та конкурують за обмежені обчислювальні ресурси та ресурси зберігання загальнодоступного ланцюга. Наприклад, збільшення швидкості обробки рівня обробки збільшить навантаження на рівень доступності даних; для забезпечення безпеки рівня виконання потрібен більш складний механізм перевірки, але він уповільнює швидкість обробки транзакцій. Тому розробка публічних мереж часто стикається з компромісами між цими чотирма модулями. Щоб подолати вузьке місце підвищення продуктивності публічного ланцюга, розробники запропонували модульне блокчейн-рішення. Основна ідея модульного блокчейну полягає в тому, щоб відокремити один або більше з чотирьох модулів, згаданих вище, і реалізувати їх в окремому загальнодоступному ланцюжку. Таким чином, публічний ланцюг може зосередитися лише на покращенні швидкості транзакцій або ємності зберігання, долаючи попередні обмеження на загальну продуктивність блокчейна через недоліки.
3. Модульний DA: складний метод відокремлення рівня DA від блокчейн-бізнесу та передачі його загальнодоступному ланцюгу вважається можливим рішенням щодо зростаючих історичних даних рівня 1. Дослідження в цій галузі на цьому етапі все ще знаходяться на ранніх стадіях. , а найпредставнішим проектом на даний момент є Celestia. Що стосується конкретного методу зберігання, Celestia спирається на метод зберігання Danksharding, який також розділяє дані на кілька блоків, і кожен вузол витягує частину для зберігання та використовує поліноміальне зобов’язання KZG для перевірки цілісності даних. У той же час Celestia використовує розширений двовимірний код стирання RS, вихідні дані переписуються у формі матриці ak, і лише 25% вихідних даних можна відновити. Однак сховище даних, що розподіляється, по суті просто помножує тиск на зберігання всього вузла мережі на коефіцієнт загального обсягу даних. Тиск зберігання вузла та обсяг даних все ще зберігають лінійне зростання. Оскільки рівень 1 продовжує підвищувати швидкість транзакцій, тиск на зберігання вузлів може одного разу досягти неприйнятного критичного рівня. Щоб вирішити цю проблему, компонент IPLD введено в Celestia для обробки. для kДані в матриці k не зберігаються безпосередньо на Celestia, а зберігаються в мережі LL-IPFS, і лише код CID даних на IPFS зберігається у вузлі. Коли користувач запитує частину історичних даних, вузол надсилає відповідний CID до компонента IPLD, а вихідні дані викликаються на IPFS через цей CID. Якщо дані існують на IPFS, їх буде повернуто через компонент і вузол IPLD; якщо він не існує, дані не можуть бути повернуті.

Метод зчитування даних Celestia, джерело зображення: Celestia Core

1. Celestia: Взявши Celestia як приклад, ми можемо отримати уявлення про застосування модульного блокчейну для вирішення проблеми зберігання Ethereum. Вузол зведення надсилатиме запаковані та перевірені дані транзакції до Celestia та зберігатиме дані в Celestia. Під час цього процесу Celestia лише зберігає дані без надмірної обізнаності. Нарешті, вузол Rollup буде згорнуто відповідно до розміру простору для зберігання. Відповідні токени tia будуть сплачені Celestia як плата за зберігання. Сховище в Celstia використовує DAS і коди стирання, подібні до тих, що в EIP4844, але поліноміальні коди стирання в EIP4844 оновлені, а двовимірні коди стирання RS використовуються для відновлення безпеки сховища. Тільки 25% переломів можуть відновити всі дані транзакції. По суті, це просто публічний ланцюжок POS з низькими витратами на зберігання. Якщо його використовувати для вирішення проблеми зберігання історичних даних Ethereum, для співпраці з Celestia потрібно багато інших спеціальних модулів. Наприклад, з точки зору зведення, на офіційному веб-сайті Celestia дуже рекомендований режим зведення – це Sovereign Rollup. На відміну від звичайного зведення на рівні 2, транзакції лише обчислюються та перевіряються, тобто завершуються операції на рівні виконання. Sovereign Rollup включає весь процес виконання та розрахунків, що мінімізує обробку транзакцій у Celestia. Якщо загальна безпека Celestia слабша, ніж у Ethereum, цей захід може максимізувати безпеку всього процесу транзакцій. З точки зору забезпечення безпеки даних, викликаних Celestia, основною мережею Ethereum, найпоширенішим рішенням на даний момент є розумний контракт quantum gravity bridge. Для даних, що зберігаються на Celestia, він створить Verkle Root (доказ доступності даних) і збереже його в контракті мосту квантової гравітації основної мережі Ethereum. Кожного разу, коли Ethereum викликає історичні дані Celestia, його хеш-результат буде порівнюватися з Verkle Root, який використовується для порівняння, і якщо він збігається, це означає, що це справді реальні історичні дані.

4.2.3 Ланцюг зберігання DA

З точки зору технічних принципів основного ланцюга DA, багато технологій, подібних до шардингу, запозичені з публічного ланцюга зберігання. Серед сторонніх DA деякі напряму використовують публічний ланцюжок зберігання для виконання деяких завдань зберігання. Наприклад, конкретні дані транзакцій у Celestia розміщуються в мережі LL-IPFS. У сторонньому рішенні DA, окрім побудови окремого загальнодоступного ланцюжка для вирішення проблеми зберігання Layer1, більш прямим способом є пряме з’єднання загальнодоступного ланцюга зберігання з Layer1 для зберігання величезних історичних даних на Layer1. Для високопродуктивних блокчейнів обсяг історичних даних ще більший. Під час роботи на повній швидкості об’єм даних високопродуктивного публічного ланцюга Solana наближається до 4 PG, що повністю виходить за межі діапазону зберігання звичайних вузлів. Рішення, яке обрала Solana, полягає в тому, щоб зберігати історичні дані в децентралізованій мережі зберігання Arweave та зберігати лише 2 дні даних на основних вузлах мережі для перевірки. Щоб забезпечити безпеку збереженого процесу, Solana та Arweave Chain спеціально розробили протокол мосту зберігання даних Solar Bridge. Дані, перевірені вузлом Solana, будуть синхронізовані з Arweave, і буде повернено відповідний тег. Лише за допомогою цього тегу вузол Solana може переглядати історичні дані блокчейну Solana в будь-який час. У Arweave немає потреби, щоб усі вузли мережі підтримували узгодженість даних і використовували це як поріг для участі в мережевих операціях. Натомість використовується зберігання винагород. По-перше, Arweave не використовує традиційну структуру ланцюга для побудови блоків, а більше схожа на структуру графа. В Arweave новий блок не лише вказуватиме на попередній блок, а й випадковим чином вказуватиме на згенерований блок Recall Block. Конкретне розташування блоку відкликання визначається результатом хешування його попереднього блоку та його висотою блоку. Місцезнаходження блоку відкликання невідоме, доки не буде видобуто попередній блок. Однак у процесі генерації нового блоку вузол повинен мати дані Recall Block, щоб використовувати механізм POW для обчислення хешу вказаної складності. Тільки той майнер, який першим обчислить хеш, що відповідає складності, може отримати винагороду, що спонукає майнерів зберігати якомога більше. історичні дані. У той же час, чим менше людей зберігає певний історичний блок, тим менше конкурентів у вузлів буде при генеруванні одноразових номерів, які відповідають труднощам, заохочуючи майнерів зберігати менше блоків у мережі. Нарешті, щоб переконатися, що вузли постійно зберігають дані в Arweave, він запроваджує механізм оцінки вузлів WildFire. Вузли, як правило, спілкуються з вузлами, які можуть швидше надати більше історичних даних, тоді як вузли з нижчими рейтингами часто не можуть якнайшвидше отримати останні дані про блоки та транзакції, а отже, не можуть скористатися перевагами конкуренції військовополонених…

Метод побудови блоків Arweave, джерело зображення: Arweave Yellow-Paper

5. Синтезоване порівняння

Далі ми порівняємо переваги та недоліки п’яти рішень для зберігання на основі чотирьох вимірів показників продуктивності DA.

1. Безпека. Найбільшим джерелом проблем із безпекою даних є втрата під час процесу передачі даних і зловмисне втручання з боку недобросовісних вузлів. У крос-ланцюжковому процесі через незалежність і стан двох публічних ланцюгів безпека передачі даних є однією з найбільш постраждалих областей. Крім того, рівень 1, який наразі потребує виділеного рівня DA, часто має сильну консенсусну групу, і його безпека буде набагато вищою, ніж у звичайних загальнодоступних ланцюгах зберігання. Таким чином, рішення основного ланцюга DA має більш високий рівень безпеки. Після забезпечення безпеки передачі даних наступним кроком є забезпечення безпеки даних виклику. Якщо розглядаються лише короткострокові історичні дані, які використовуються для перевірки транзакцій, ці дані резервуються всією мережею в мережі тимчасового зберігання. У рішенні, подібному до DankSharding, середня кількість резервних копій даних становить лише 1/N від кількості вузлів у всій мережі. , більша надлишковість даних може зменшити ймовірність втрати даних, а також може надати більше еталонних зразків під час перевірки. Таким чином, тимчасове зберігання матиме відносно вищий рівень безпеки даних. У сторонньому рішенні DA спеціальний DA для основного ланцюга використовує загальнодоступні вузли з основним ланцюгом, і дані можуть безпосередньо передаватися через ці вузли ретрансляції під час міжланцюжкового процесу, тому він матиме відносно вищий рівень безпеки, ніж інші рішення DA. .
2. Витрати на зберігання. Найбільшим фактором, що впливає на витрати на зберігання, є кількість надлишкових даних. У рішеннях короткострокового зберігання основного ланцюга DA воно зберігається у формі синхронізації даних усіх вузлів мережі. Будь-які щойно збережені дані потребують резервного копіювання в усьому мережевому вузлі, який має найвищу вартість зберігання. Висока вартість зберігання, у свою чергу, визначає, що цей метод підходить лише для тимчасового зберігання в мережах з високим TPS. По-друге, це метод зберігання шардингу, включаючи шардинг в основному ланцюзі та шардинг у сторонньому DA. Оскільки основний ланцюг часто має більше вузлів, відповідний блок також матиме більше резервних копій, тому рішення шардингу основного ланцюга матиме вищі витрати. Найнижчу вартість зберігання має загальнодоступний ланцюжок DA, який використовує метод зберігання винагороди. За цією схемою обсяг надлишкових даних часто коливається навколо фіксованої константи. У той же час механізм динамічного коригування також введено в загальнодоступний ланцюг зберігання даних DA, щоб залучити вузли для зберігання меншої кількості резервних копій даних шляхом збільшення винагороди для забезпечення безпеки даних.
3. Швидкість читання даних: на швидкість зберігання даних головним чином впливає розташування даних у просторі зберігання, шлях індексу даних і розподіл даних у вузлах. Серед них місце зберігання даних на вузлі має більший вплив на швидкість, оскільки зберігання даних у пам’яті або SSD може призвести до того, що швидкість читання буде відрізнятися в десятки разів. Зберігання загальнодоступного ланцюга DA здебільшого використовує SSD-накопичувач, оскільки навантаження на цей ланцюг включає не лише дані рівня DA, але також містить особисті дані з великим використанням пам’яті, такі як відео та зображення, завантажені користувачами. Якщо мережа не використовує твердотільний накопичувач як простір для зберігання, буде важко витримувати величезний тиск на зберігання та задовольняти довгострокові потреби в сховищі. По-друге, для сторонніх DA і DA основного ланцюга, які використовують стан пам’яті для зберігання даних, сторонній DA спочатку повинен знайти відповідні дані індексу в основному ланцюжку, а потім передати дані індексу через ланцюжок до третього -party DA і повернути його через міст зберігання даних. Навпаки, DA головного ланцюга може безпосередньо запитувати дані з вузлів і, отже, має вищу швидкість отримання даних. Нарешті, в рамках основного ланцюга DA метод Sharding вимагає виклику Block з кількох вузлів і відновлення вихідних даних. Таким чином, порівняно з короткостроковим зберіганням без фрагментованого зберігання, швидкість буде нижчою.
4. Універсальність рівня DA: Універсальність DA основного ланцюга близька до нуля, оскільки неможливо передати дані загальнодоступного ланцюга з недостатнім простором для зберігання в інший загальнодоступний ланцюг із недостатнім простором для зберігання. У сторонньому DA універсальність рішення і його сумісність з певним основним ланцюгом є суперечливими показниками. Наприклад, у спеціальному рішенні DA для основного ланцюга, розробленому для певного основного ланцюга, було зроблено багато вдосконалень на рівні типу вузла та мережевого консенсусу для адаптації до публічного ланцюга. Таким чином, ці вдосконалення відіграватимуть роль під час спілкування з іншими публічними мережами. величезна перешкода. У сторонньому DA DA публічного ланцюга зберігання працює краще з точки зору універсальності порівняно з модульним DA. Публічна мережа зберігання даних DA має більшу спільноту розробників і більше засобів розширення, які можуть адаптуватися до умов різних публічних мереж. У той же час DA публічного ланцюга зберігання отримує дані більш активно через захоплення пакетів, а не пасивно отримує інформацію, що передається з інших публічних ланцюгів. Таким чином, він може кодувати дані по-своєму, досягти стандартизованого зберігання потоків даних, полегшити керування інформацією даних з різних основних ланцюгів і підвищити ефективність зберігання.

Порівняння продуктивності рішення для зберігання, джерело зображення: Kernel Ventures

6. Підведення підсумків

Поточний блокчейн трансформується з Crypto на більш інклюзивний Web3. Цей процес приносить не тільки багатство проектів на блокчейні. Щоб забезпечити одночасну роботу такої кількості проектів на рівні 1, забезпечуючи досвід проектів Gamefi та Socialfi, рівень 1, представлений Ethereum, застосував такі методи, як Rollup і Blobs для покращення TPS. Серед нових блокчейнів також зростає кількість високопродуктивних блокчейнів. Але вищий TPS означає не лише вищу продуктивність, але й більший тиск на зберігання в мережі. Для масивних історичних даних наразі пропонуються різні методи DA, засновані на основному ланцюзі та сторонніх розробниках, щоб адаптуватися до збільшення тиску на зберігання в ланцюзі. Кожен метод покращення має переваги та недоліки та має різну застосовність у різних ситуаціях.

Блокчейни, які зосереджені на платежах, мають надзвичайно високі вимоги до безпеки історичних даних і не прагнуть до особливо високого TPS. Якщо цей тип загальнодоступного ланцюга все ще знаходиться на стадії підготовки, можна застосувати метод зберігання, подібний до DankSharding, який може досягти значного збільшення ємності зберігання, забезпечуючи безпеку. Однак, якщо це публічний ланцюжок, такий як біткойн, який уже сформувався і має велику кількість вузлів, є величезні ризики в необдуманих покращеннях на рівні консенсусу. Таким чином, спеціалізований DA основного ланцюга з вищим рівнем безпеки в сховищі поза ланцюгом може бути використаний для збалансування питань безпеки та зберігання… Однак варто зазначити, що функції блокчейну не є статичними, а постійно змінюються. Наприклад, перші функції Ethereum були в основному обмежені платежами та простою автоматизованою обробкою активів і транзакцій за допомогою смарт-контрактів. Однак, оскільки ландшафт блокчейну продовжує розширюватися, різні проекти Socialfi та Defi поступово додаються до Ethereum. Змусити Ethereum розвиватися в більш комплексному напрямку. Нещодавно, у зв’язку з вибухом напису «Екологія» на біткойнах, комісія за транзакції в мережі біткойн зросла майже в 20 разів із серпня. Це свідчить про те, що швидкість транзакцій мережі біткойн на цьому етапі не може задовольнити попит на транзакції, і трейдери можуть лише підвищувати комісію, щоб транзакції оброблялися якомога швидше. Тепер біткойн-спільнота повинна прийняти компроміс: прийняти високі комісії та низьку швидкість транзакцій або знизити безпеку мережі, щоб збільшити швидкість транзакцій, але порушити початковий намір платіжної системи. Якщо біткойн-спільнота вибере останнє, то перед обличчям зростаючого тиску даних, відповідне рішення для зберігання також потрібно буде налаштувати.

Комісії за транзакції основної мережі Bitcoin коливаються, джерело зображення: OKLINK

Загальнодоступні ланцюги з комплексними функціями мають більшу гонитву за TPS, а зростання історичних даних ще більше. Важко адаптуватися до швидкого зростання TPS у довгостроковій перспективі, прийнявши рішення, подібне до DankSharding. Тому більш відповідним способом є перенесення даних на сторонній DA для зберігання. Серед них DA, специфічний для основного ланцюга, має найвищу сумісність і може мати більше переваг, якщо розглядати лише проблеми зберігання єдиного публічного ланцюга. Але сьогодні, коли публічні ланцюги рівня 1 процвітають, міжланцюгова передача активів і взаємодія даних стали звичайним заняттям спільноти блокчейнів. Якщо брати до уваги довгостроковий розвиток усієї екосистеми блокчейну, зберігання історичних даних різних публічних ланцюжків в одному публічному ланцюзі може усунути багато проблем безпеки в процесі обміну даними та перевірки. Таким чином, відмінність між модульним DA та загальнодоступним ланцюгом DA може бути кращим вибором. Відповідно до передумови максимальної універсальності, модульний DA зосереджується на наданні послуг рівня DA блокчейну, запроваджуючи більш точні історичні дані керування даними індексу, які можуть обґрунтовано класифікувати різні дані публічного ланцюга та зберігати дані публічного ланцюга. Має більше переваг, ніж. Однак наведене вище рішення не враховує вартість коригування рівня консенсусу в існуючому загальнодоступному ланцюжку. Цей процес надзвичайно ризикований. Якщо виникають проблеми, це може призвести до системної вразливості та спричинити втрату громадським ланцюгом консенсусу спільноти. Тому, якщо це перехідне рішення під час процесу розширення блокчейну, найпростіше тимчасове сховище основного ланцюга може бути більш придатним. Нарешті, наведене вище обговорення базується на продуктивності під час фактичної роботи. Однак, якщо метою певної громадської мережі є розвиток своєї екології та залучення більшої кількості сторін та учасників проекту, вона також може віддавати перевагу проектам, які підтримуються та фінансуються її фондом… Наприклад, коли загальна продуктивність еквівалентна або навіть трохи Нижче, ніж у публічних мережевих сховищах, спільнота Ethereum також буде прагнути до проектів рівня 2, які підтримує Ethereum Foundation, таких як EthStorage, щоб продовжувати розвивати екосистему Ethereum.

Загалом, функції сучасного блокчейну стають дедалі складнішими, що також призводить до більших вимог до місця для зберігання. Коли є достатньо вузлів верифікації рівня 1, не потрібно створювати резервні копії історичних даних усіма вузлами всієї мережі. Лише тоді, коли кількість резервних копій досягне певного значення, можна гарантувати відносну безпеку. Водночас розподіл праці в публічних ланцюгах також стає дедалі детальнішим., Рівень 1 відповідає за консенсус і виконання, Rollup відповідає за обчислення та перевірку, а окремий блокчейн використовується для зберігання даних. Кожна частина може зосереджуватися на певній функції, не обмежуючись виконанням інших частин. Однак, який конкретний обсяг пам’яті або яка частка вузлів має бути дозволена для зберігання історичних даних, може досягти балансу між безпекою та ефективністю, і як забезпечити безпечну взаємодію між різними блокчейнами, це питання, яке вимагає від розробників блокчейну подумати. і постійно вдосконалюватися. Інвестори, але зверніть увагу на основний ланцюжковий проект DA на Ethereum, тому що Ethereum вже має достатньо прихильників на цьому етапі, і йому не потрібно покладатися на інші спільноти, щоб розширити свій вплив. Що ще потрібно, так це вдосконалювати та розвивати свою спільноту та залучати більше проектів до екосистеми Ethereum. Однак для державних мереж, що наздоганяють, як-от Solana та Aptos, одна мережа сама по собі не має такої повної екології, тому вона може бути більш схильною об’єднати зусилля з іншими спільнотами для створення величезної міжланцюгової екології. розширити вплив. Таким чином, Layer1, загальний сторонній DA, заслуговує на більшу увагу.

Kernel Ventures — це крипто-венчурний фонд, керований дослідницьким співтовариством і розробником із понад 70 інвестиціями на ранніх стадіях, зосередженими на інфраструктурі, проміжному програмному забезпеченні, dApps, особливо ZK, Rollup, DEX, модульних блокчейнах і адаптаційних вертикальних зонах для мільярдів користувачів криптовалюти майбутнє, наприклад абстракція облікового запису, доступність даних, масштабованість тощо. Протягом останніх семи років ми підтримували розвиток основних спільнот розробників та університетських блокчейн-асоціацій у всьому світі.

Відмова від відповідальності:

1. Ця стаття передрукована з [дзеркало]. Усі авторські права належать оригінальному автору [Kernel Ventures Jerry Luo]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.