Джеррі Луо, Kernel Ventures

TL;DR

1. У перші дні публічні ланцюги вимагали, щоб вузли в мережі підтримували узгодженість даних для забезпечення безпеки та децентралізації. Однак з розвитком блокчейн-екосистеми тиск зберігання продовжує зростати, що призводить до тенденції централізації операцій вузлів. На цьому етапі Layer 1 терміново потрібно вирішити проблему вартості зберігання, спричинену зростанням TPS.

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

3. У процесі вирішення цієї проблеми з’явилося багато нових технологій та ідей, включаючи Sharding, DAS, Verkle Tree, проміжні компоненти DA тощо. Вони намагалися оптимізувати схему зберігання шару DA, зменшивши надмірність даних і підвищивши ефективність верифікації даних.

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

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

6. В цілому блокчейн розвивається в напрямку скорочення надлишковості даних і багатоланцюгового поділу праці.

1. тло

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

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

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

2.1 Безпека

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

Кількість резервування: Для резервування даних у системі блокчейн вона в основному може відігравати такі ролі: по-перше, якщо кількість резервувань у мережі більша, коли валідатору потрібно перевірити статус облікового запису в історичному блоці, щоб перевірити поточну транзакцію, він може отримати найбільшу кількість зразків для довідки та вибрати дані, записані більшістю вузлів. У традиційних базах даних, оскільки дані зберігаються лише у вигляді пар ключ-значення на певному вузлі, вартість атаки надзвичайно низька, щоб змінити історичні дані лише на одному вузлі, і теоретично, чим надлишковіші дані, тим достовірніші дані. При цьому, чим більше вузлів зберігається, тим менша ймовірність втрати даних. Це також можна порівняти з централізованими серверами, які зберігають ігри Web2, і як тільки всі сервери будуть закриті, відбудеться повне відключення. Однак більше не означає краще, тому що кожне резервування принесе додатковий простір для зберігання, а надмірне резервування даних призведе до надмірного навантаження на систему, і хороший рівень DA повинен вибрати відповідний метод резервування, щоб знайти баланс між безпекою та ефективністю зберігання.

Перевірка доступності даних: Резервування гарантує, що в мережі достатньо записів даних, але дані, які будуть використовуватися, також повинні бути перевірені на точність і повноту. На цьому етапі зазвичай використовуваним методом верифікації в блокчейні є алгоритм криптографічних зобов’язань, який зберігає невелике криптографічне зобов’язання для запису всією мережею, і це зобов’язання отримується шляхом змішування даних транзакцій. Щоб перевірити достовірність фрагмента історичних даних, необхідно відновити криптографічну обіцянку через дані, перевірити, чи криптографічна обіцянка, отримана в результаті відновлення, узгоджується із записами всієї мережі, і якщо вона послідовна, то перевірка проходить. Часто використовуваними алгоритмами перевірки пароля є Merkle Root і Verkle Root. Алгоритм перевірки доступності даних із високим рівнем безпеки вимагає дуже мало даних для перевірки та може швидко перевірити історичні дані.

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

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

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

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

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

2.4 Спільність шару DA

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

3. Дослідження технологій, пов’язаних з DA

3.1 Шардинг

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

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

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

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

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

Поліноміальна обіцянка KZG: Дуже важливою частиною зберігання даних є перевірка автентичності даних. У мережах, які не використовують код Eraser, існують різні способи валідації процесу, але якщо наведений вище код Eraser вводиться для підвищення безпеки даних, то доцільніше використовувати поліноміальні зобов’язання KZG. Многочлен KZG обіцяє пряму перевірку вмісту одного блоку у вигляді поліномів, таким чином усуваючи необхідність відновлення поліномів у двійкові дані, а форма перевірки в цілому схожа на форму Дерева Меркла, але не потрібні конкретні дані вузла Path, для перевірки його автентичності потрібні лише кореневі та блокові дані KZG.

3.3 Режим верифікації даних шару DA

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

Порівняння методів верифікації даних і часових показників, джерело зображення: Дерева Веркла

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

Безперервне розширення екології блокчейну призвело до збільшення кількості публічних ланцюжків. У зв’язку з перевагами та незамінністю кожного публічного ланцюга у відповідних сферах, публічний ланцюг Layer1 практично неможливо уніфікувати за короткий проміжок часу. Однак з розвитком DeFi та проблемами CEX зростає і попит на децентралізовані крос-чейн торгові активи. В результаті мультичейн сховище даних на рівні DA, яке може усунути проблеми з безпекою при крос-чейн обміні даними, привертає все більше уваги. Однак, щоб приймати історичні дані з різних публічних ланцюгів, необхідно, щоб рівень DA надав децентралізований протокол для стандартизованого зберігання та перевірки потоків даних, такий як kvye, проміжне програмне забезпечення для зберігання на основі Arweave, яке бере на себе ініціативу щодо збору даних з ланцюжка та може зберігати всі дані в ланцюжку в стандартній формі для Arweave, щоб мінімізувати відмінності в процесі передачі даних. Умовно кажучи, Layer2, який спеціалізується на наданні зберігання даних на рівні DA для певного публічного ланцюга, взаємодіє з даними через внутрішні вузли спільного використання, що знижує вартість взаємодії та покращує безпеку, але має відносно великі обмеження та може надавати послуги лише певним публічним ланцюгам.

4. Схема зберігання DA-рівня

4.1 Материнська мережа DA

4.1.1 клас DankSharding

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

4.1.2 Короткочасне зберігання

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

4.2 Сторонні DA

4.2.1 Виділена DA: EthStorage

DA для основного ланцюга:D Найголовніше в шарі А - це безпека передачі даних, а найбільш безпечним в цьому плані є DA основного ланцюга. Однак сховище основного ланцюга обмежене простором для зберігання та конкуренцією за ресурси, тому, коли обсяг мережевих даних швидко зростає, якщо ви хочете досягти довгострокового зберігання даних, сторонній DA буде кращим вибором. Якщо сторонній DA має більш високу сумісність з основною мережею, він може реалізувати спільне використання вузлів і мати більш високу безпеку в процесі обміну даними. Тому, виходячи з міркувань безпеки, будуть величезні переваги для DA, присвяченого основному ланцюжку. Візьмемо для прикладу Ethereum, однією з основних вимог виділеного DA основного ланцюга є те, що він може бути сумісний з EVM для забезпечення сумісності з даними та контрактами Ethereum, а представницькі проекти включають Topia, EthStorage тощо. Серед них EthStorage наразі є найбільш розвиненим з точки зору сумісності, оскільки на додаток до сумісності на рівні EVM, він також налаштовує відповідні інтерфейси для підключення до інструментів розробки Ethereum, таких як Remix і Hardhat, щоб досягти сумісності на рівні інструментів розробки Ethereum.

EthStorage: EthStorage — це публічний ланцюг, незалежний від Ethereum, але вузли, що працюють на ньому, є кращими за вузли Ethereum, тобто вузли, на яких працює EthStorage, також можуть одночасно запускати Ethereum, а EthStorage можна безпосередньо керувати через код операції на Ethereum. У моделі зберігання EthStorage, яка зберігає лише невелику кількість метаданих в основній мережі Ethereum для індексації, по суті, створюється децентралізована база даних для Ethereum. У поточному рішенні EthStorage реалізував взаємодію між основною мережею Ethereum і EthStorage, розгорнувши контракт EthStorage в основній мережі Ethereum. Якщо Ethereum хоче депонувати дані, йому потрібно викликати функцію put() у контракті, а вхідними параметрами є дві байтові змінні key, data, де data представляє дані, які потрібно депонувати, і key – це його ідентифікація в мережі Ethereum, що можна розглядати як подібне до існування CID в IPFS. Після того, як пара (ключ, дані) буде успішно збережена в мережі EthStorage, EthStorage згенерує kvldx і поверне його в основну мережу Ethereum, що відповідає ключу на Ethereum, і це значення відповідає адресі зберігання даних на EthStorage, так що проблема зберігання великого обсягу даних тепер змінена на зберігання однієї (key, kvldx) пари, що значно знижує вартість зберігання основної мережі Ethereum. Якщо вам потрібно зробити виклик раніше збережених даних, вам потрібно скористатися функцією get() в EthStorage і ввести ключовий параметр, а також ви зможете виконати швидкий пошук даних на EthStorage через kvldx, що зберігаються на Ethereum.

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

З точки зору того, як вузли зберігають дані, EthStorage запозичує патерн Arweave. Перш за все, шардинг великої кількості (k,v) пар з ETH шардінг містить фіксовану кількість (k,v) пар даних, з яких також існує обмеження на конкретний розмір кожної (k,v) пари, щоб забезпечити справедливість розміру робочого навантаження в процесі зберігання винагород для майнерів. Для видачі винагород потрібно перевірити, чи зберігає нода дані. У цьому процесі EthStorage ділить шардинг (терабайтний розмір) на велику кількість фрагментів і зберігає корінь Merkle в основній мережі Ethereum для перевірки. Далі майнер повинен надати nonce для генерації адрес кількох фрагментів за допомогою випадкового алгоритму з хешем попереднього блоку на EthStorage, а майнер повинен надати дані цих фрагментів, щоб довести, що він дійсно зберіг весь шардинг. Однак, цей nonce не може бути обраний довільно, інакше вузол вибере відповідний nonce, який відповідає лише його збереженому фрагменту, щоб пройти перевірку, тому цей nonce повинен змусити згенерований фрагмент відповідати вимогам мережі після змішування та хешування, і лише перший вузол, який надіслав nonce та доказ довільного доступу, може отримати винагороду.

4.2.2 Модульна DA: Celestia

Модуль блокчейну: На цьому етапі транзакції, які повинні бути виконані публічним ланцюгом рівня 1, в основному поділяються на наступні чотири частини: (1) розробляти базову логіку мережі, вибирати валідаторів певним чином, писати блоки та розподіляти винагороди серед супроводжуючих мережі, (2) упаковувати та обробляти транзакції та публікувати пов’язані транзакції, (3) перевіряти транзакції, які будуть розміщені в ланцюжку, і визначати остаточний стан, і (4) зберігати та підтримувати історичні дані в блокчейні. Залежно від виконуваних функцій ми можемо розділити блокчейн на чотири модулі, а саме рівень консенсусу, рівень виконання, рівень розрахунків і рівень доступності даних (рівень DA).

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

Модульна DA: Комплексний підхід відокремлення рівня DA від блокчейн-бізнесу та передачі його єдиному публічному ланцюжку вважається життєздатним рішенням для зростаючих історичних даних рівня 1. Дослідження в цій області все ще знаходяться на ранніх стадіях, і Celestia є найбільш репрезентативним проектом на даний момент. З точки зору конкретного методу зберігання, Celestia запозичує метод зберігання Danksharding, який полягає в тому, щоб розділити дані на кілька блоків, витягти їх частину кожним вузлом для зберігання та перевірити цілісність даних за допомогою поліноміального зобов’язання KZG. У той же час Celestia використовує просунуте 2D кодування стирання RS для перезапису вихідних даних у вигляді kk-матриці, і, нарешті, лише 25% вихідних даних можуть бути відновлені. Однак сховище шардингу даних, по суті, лише множить тиск сховища вузлів у всій мережі на коефіцієнт від загального обсягу даних, а тиск зберігання та об’єм даних вузлів все ще підтримують лінійне зростання. Оскільки рівень 1 продовжує підвищувати швидкість транзакцій, тиск сховища вузлів все ще може одного разу досягти неприйнятного порогу. Щоб вирішити цю проблему, в Celestia був введений компонент IPLD для обробки. Що стосується даних в матриці kk, то вони зберігаються не безпосередньо на Celestia, а в мережі LL-IPFS, і тільки CID-код цих даних на IPFS зберігається в вузлі. Коли користувач запитує фрагмент історичних даних, вузол надсилає відповідний CID компоненту IPLD і використовує CID для виклику необроблених даних на IPFS. Якщо дані існують в IPFS, вони повертаються через компоненти та вузли IPLD, а якщо ні, їх не можна повернути.

Як читаються дані Celestia, джерело зображення: Celestia Core

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

4.2.3 Магазин публічної мережі DA

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

Як будуються блоки Arweave, джерело зображення: Arweave Yellow-Paper

5. Комплексне порівняння

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

Безпека: Найбільшим джерелом проблем безпеки даних є втрати, спричинені передачею даних та зловмисним втручанням з боку нечесних вузлів, а в крос-чейн процесі, через незалежність та стан двох публічних ланцюгів, які не поділяються, це найбільш постраждала область безпеки передачі даних. Крім того, рівень 1, який вимагає виділеного рівня DA на цьому етапі, часто має сильну групу консенсусу, і його власна безпека буде набагато вищою, ніж у звичайних публічних ланцюгів зберігання. Тому схема основного ланцюга DA має більш високу безпеку. Після забезпечення безпеки передачі даних, наступним кроком є забезпечення безпеки даних виклику. Якщо розглядаються лише короткострокові історичні дані, які використовуються для перевірки транзакцій, ті самі дані резервуються всією мережею в тимчасово збереженій мережі, тоді як середня кількість резервних копій даних у схемі, подібній до DankSharding, становить лише 1/N від кількості вузлів у всій мережі, більша надмірність даних може зменшити ймовірність втрати даних, а також може надати більше еталонних зразків для перевірки. Тому тимчасове сховище матиме вищу безпеку даних. У схемі стороннього DA виділена DA основного ланцюга використовує загальні вузли з основним ланцюгом, і дані можуть безпосередньо передаватися через ці ретрансляційні вузли під час крос-чейн процесу, тому вона також матиме відносно вищу безпеку, ніж інші рішення DA.

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

Швидкість читання даних: на швидкість зберігання даних в основному впливає розташування даних у просторі зберігання, шлях індексу даних і розподіл даних у вузлах. Серед них, де дані зберігаються на вузлі, має більший вплив на швидкість, оскільки зберігання даних у пам’яті або SSD може призвести до того, що швидкість читання зміниться в десятки разів. Публічна мережа зберігання даних DA в основному використовує SSD-сховища, оскільки навантаження на ланцюжок включає не тільки дані рівня DA, але й особисті дані з високим обсягом пам’яті, такі як відео та зображення, завантажені користувачами. Якщо мережа не використовує SSD як місце для зберігання, важко витримати величезний тиск зберігання та задовольнити потреби тривалого зберігання. По-друге, для сторонніх DA та DA, які використовують дані зберігання в пам’яті, сторонній DA спочатку потрібно знайти відповідні індексні дані в основному ланцюжку, а потім передати дані індексу сторонньому DA через ланцюг і повернути дані через міст зберігання. Навпаки, материнські мережі мейнчейн можуть запитувати дані безпосередньо від вузлів і, отже, мають вищу швидкість пошуку даних. Нарешті, всередині основного ланцюга DA метод Sharding повинен викликати блок з декількох вузлів і відновити вихідні дані. Як наслідок, короткострокове зберігання відбувається повільніше, ніж короткострокове без шардингу.

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

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

6. зведення

Блокчейни на цьому етапі переживають перехід від криптовалют до більш інклюзивного Web3, приносячи більше, ніж просто безліч проектів на блокчейні. Для того, щоб вмістити таку кількість проєктів, що працюють одночасно на рівні 1, забезпечуючи при цьому досвід проєктів Gamefi та Socialfi, рівень 1, представлений Ethereum, застосував такі методи, як Rollups і Blobs, для покращення TPS. Серед блокчейнів, що зароджуються, також зростає кількість високопродуктивних блокчейнів. Але вищий TPS означає не тільки вищу продуктивність, але й більший тиск на мережу. Для масивних історичних даних на цьому етапі пропонуються різноманітні методи DA, засновані на основному ланцюжку та третіх сторонах, щоб адаптуватися до зростання тиску на сховище в мережі. У кожного методу вдосконалення є плюси і мінуси, і він має різну застосовність у різних контекстах.

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

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

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

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