• Переслана оригінальна назва: Неправильне розуміння доступності даних: DA = оприлюднення даних ≠ пошук історичних даних

Вступ:

Що саме означає доступність даних? Для більшості людей першим враженням може бути "доступ до історичних даних певного моменту", але насправді це велике нерозуміння концепції DA. Нещодавно співзасновники L2BEAT і прихильники данкшардингу разом із засновником Celestia роз'яснили це хибне уявлення. Вони зазначили, що доступність даних (DA) насправді має стосуватися "публікації даних", але більшість людей інтерпретують DA як "історичну доступність даних", що насправді включає в себе питання зберігання даних.

Наприклад, нещодавно Данкрад згадав про механізм обов'язкового виведення/виходу з шару 2, зазначивши, що обов'язкове виведення валідію вимагає отримання останнього стану L2 для побудови доказу Меркла, тоді як плазмі потрібні дані лише за 7 днів до цього (це пов'язано з їхніми методами визначення легітимного кореня стану).

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

На L2BEAT було ще більше підкреслено різницю між доступністю даних (DA) та зберіганням даних (DS). Бартек з L2BEAT неодноразово підкреслював, що DA і зберігання даних/історичний пошук даних - це дві різні речі, і що користувачі можуть отримати доступ до потрібних їм даних L2 тільки тому, що вузли, які надають дані, "досить добрі до вас". Крім того, L2BEAT планує використовувати "наявність дозволених вузлів зберігання даних" як нову метрику для оцінки Rollups, окрім DA.

Заяви членів спільноти Ethereum/Фундації Ethereum показують їх намір прояснити і уточнити концепції, пов'язані з Layer 2, в майбутньому, а також надати більш детальне визначення самого Layer 2. Це пов'язано з тим, що багато термінів, пов'язаних з Rollup і L2, не мають чіткого пояснення, наприклад, наскільки давні дані вважаються "історичними" - дехто вважає, що оскільки смарт-контракти можуть звертатися до даних лише за останні 256 блоків, то "історичними" вважаються дані за період до 256 блоків (50 хвилин).

Однак "згортання", згадане Celestia і Ethereum Foundation, чітко відноситься до двох різних речей. Ця стаття має на меті пояснити різницю між концепцією DA та зберіганням даних, починаючи від джерела DA, вибірки доступності даних і закінчуючи методами реалізації DA в Rollups, пояснюючи, що насправді означає доступність даних - публікація даних.

Походження концепції ПДР

Концепція DA походить від питання "доступності даних", яке засновник Celestia Мустафа пояснює наступним чином: DA - це про те, як гарантувати, що всі дані в блоці публікуються в мережі, коли виробник блоку пропонує новий блок. Якщо виробник блоку не оприлюднює всі дані в блоці, неможливо перевірити, чи містить блок помилкові транзакції.

Мустафа також зазначає, що Ethereum Rollups просто публікують дані L2 блоку в ланцюжку Ethereum і покладаються на ETH для забезпечення доступності даних. На офіційному сайті Ethereum проблема доступності даних сформульована у вигляді питання: "Як перевірити, чи доступні дані нового блоку?" Для легких клієнтів питання доступності даних стосується перевірки доступності блоку без необхідності завантажувати весь блок.

На офіційному сайті Ethereum також чітко розрізняють доступність даних і можливість їх відновлення: доступність даних - це здатність вузлів завантажувати дані блоку, коли вони пропонуються, іншими словами, це пов'язано з часом до того, як блок досягне консенсусу. Можливість відновлення даних - це здатність вузлів отримувати історичну інформацію з блокчейну. Хоча для архівування можуть знадобитися історичні дані блокчейну, вузлам не обов'язково використовувати історичні дані для перевірки блоків і обробки транзакцій.

На думку китайського учасника Celestia і партнера W3Hitchhiker, Рен Хонгі (Ren Hongyi), рівень 2 заздалегідь передбачає, що Ethereum є достатньо безпечним і децентралізованим. Сортувальники можуть впевнено відправляти дані DA в Ethereum, і ці дані будуть безперешкодно поширюватися на всі повні вузли Ethereum. Оскільки повні вузли L2 самі запускають клієнт Geth, вони вважаються підмножиною повних вузлів Ethereum і можуть отримувати дані DA 2-го рівня.

З точки зору доктора Ци Чжоу, засновника EthStorage, визначення доступності даних (DA) полягає в тому, що ніхто не може приховати дані про транзакції, які користувачі передають в мережу. Відповідна модель довіри полягає в тому, що нам потрібно довіряти тільки самому протоколу рівня 1 (L1), без необхідності вводити інші припущення про довіру.

Ци Чжоу вказує, що поточна реалізація DA в Ethereum - це, по суті, P2P-трансляція (з використанням протоколу пліток), де кожна повна нода завантажує, поширює нові блоки і зберігає дані Rollup. Однак повні ноди Ethereum не будуть зберігати історичні блоки вічно. Після впровадження EIP-4844 вони можуть автоматично видаляти дані певної давнини (очевидно, 18 днів). Існує не так багато архівних вузлів, які зберігають всі історичні дані в усьому світі. EthStorage планує заповнити цю прогалину в екосистемі Ethereum і допомогти Layer 2 створити свої спеціальні вузли постійності даних.

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

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

Його початкова ідея насправді була пов'язана з ідеєю, згаданою в Біткоїн whitepaper, яка стверджує, що легким вузлам не потрібно отримувати повний блок, але вони будуть попереджені чесними повними вузлами, якщо виникне проблема з блоком. Ця концепція може бути поширена на пізніші докази шахрайства, але вона не гарантує, що чесні повні вузли завжди зможуть отримати достатньо даних, а також не може судити постфактум про те, чи не приховував пропонент блоку якісь дані від публікації.

Наприклад, вузол А може опублікувати доказ шахрайства, стверджуючи, що він отримав неповний блок від вузла Б. Однак неможливо визначити, чи був неповний блок сфабрикований А, чи надісланий Б. Віталік зазначив, що цю проблему можна вирішити за допомогою вибірки доступності даних (Data Availability Sampling, DAS), яка, очевидно, пов'язана з питаннями публікації даних.

Віталік коротко обговорив ці проблеми та їх вирішення у своїй статті "Зауваження щодо доступності даних та кодування стирання". Він зазначив, що докази наявності даних (DA) є, по суті, "доповненням" до доказів шахрайства.

Вибірка наявності даних

Однак концепцію DA не так легко пояснити, про що свідчить документ Віталіка на GitHub, який зазнав 18 виправлень, останнє з яких було внесено 25 вересня 2018 року. Буквально за день до цього, 24 вересня 2018 року, засновник Celestia Мустафа і Віталік стали співавторами знаменитої статті "Шахрайство і докази доступності даних: Максимізація безпеки легких клієнтів та масштабування блокчейнів з нечесною більшістю".

Цікаво, що першим автором статті вказаний Мустафа, а не Віталік (інший автор зараз є дослідником публічного блокчейну Sui). У статті згадується концепція доказів шахрайства та пояснюється принцип вибірки доступності даних (DAS), приблизно розробляється змішаний протокол DAS + двовимірне кодування стирання + докази шахрайства. У документі особливо наголошується, що система доказів прокурорських перевірок є необхідним доповненням до доказів шахрайства.

З точки зору Віталіка, протокол працює наступним чином:

Припустимо, що публічний блокчейн має N вузлів консенсусу (валідаторів) з високопродуктивним обладнанням, що забезпечує високу пропускну здатність і ефективність передачі даних. Хоча такий блокчейн може мати високу кількість транзакцій в секунду (TPS), кількість вузлів консенсусу, N, відносно невелика, що робить його більш централізованим і підвищує ймовірність змови між вузлами.

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

Як вже згадував Віталік, якщо чесна повна нода отримає блок і виявить, що в ньому не вистачає якоїсь частини, і опублікує доказ шахрайства, важко визначити, чи не опублікував цю частину пропонент блоку, чи вона була прихована іншими нодами під час передачі, чи це помилковий прапор з боку ноди, яка опублікувала доказ шахрайства. Більше того, якщо більшість вузлів вступить у змову, чесний валідатор 1/N може бути ізольований і не зможе отримувати нові блоки, що є сценарієм атаки з приховуванням даних. У таких випадках чесний вузол не може визначити, чи це пов'язано з поганими умовами мережі, чи з навмисною змовою інших вузлів, а також не може знати, чи інші вузли також ізольовані, що ускладнює судження про те, чи змовилася більшість у приховуванні даних.

Тому повинен існувати спосіб гарантувати, з дуже високою ймовірністю, що чесні валідатори зможуть отримати дані, необхідні для валідації блоків; а також визначити, хто стоїть за атакою з приховуванням даних - чи це той, хто запропонував блок, який не опублікував достатню кількість даних, чи вони були приховані іншими вузлами, чи це змова більшості. Очевидно, що ця модель безпеки забезпечує набагато більший захист, ніж "припущення чесної більшості", поширене в типових ланцюжках PoS, а вибірка доступності даних (Data Availability Sampling, DAS) є конкретним методом її реалізації.

Припустимо, що в мережі є багато легких вузлів, можливо, в 10 разів більше N, кожен з яких підключений до декількох валідаторів (для простоти припустимо, що кожен легкий вузол підключений до всіх N валідаторів). Ці легкі вузли здійснюватимуть багаторазові вибірки даних з валідаторів, щоразу випадковим чином запитуючи невелику порцію даних (припустимо, лише 1% від блоку). Потім вони поширювали отримані фрагменти серед валідаторів, які не мали цих даних. Якщо є достатня кількість легких вузлів і частота вибірки даних досить висока, навіть якщо деякі запити відхиляються, але на більшість з них дається відповідь, можна гарантувати, що всі валідатори в кінцевому підсумку зможуть отримати необхідну кількість даних для перевірки блоку. Це може звести нанівець вплив приховування даних іншими вузлами, окрім того, що запропонував блок.

(Джерело зображення: W3 Hitchhiker)

Якщо більшість валідаторів змовиться і відмовиться відповідати на більшість запитів від легких вузлів, людям буде легко зрозуміти, що в ланцюжку є проблема (адже навіть якщо у когось поганий інтернет, це не призведе до того, що більшість запитів легких вузлів буде відхилено). Таким чином, вищезгадана схема може з великою ймовірністю визначати поведінку більшості в умовах змови, хоча самі по собі такі ситуації є рідкісними. За допомогою цього підходу можна вирішити невизначеності з інших джерел, окрім того, хто запропонував блок. Якщо пропонент блоку приховує дані, наприклад, не публікує достатньо даних у блоці для його перевірки (після введення двовимірного кодування зі стиранням блок містить 2k2k фрагментів, і для відновлення початкових даних блоку потрібно щонайменше kk фрагментів, або 1/4. Щоб інші не змогли відновити вихідні дані, учасник повинен буде приховати щонайменше k+1*k+1 фрагментів), їх зрештою виявлять чесні валідатори, які потім опублікують докази шахрайства, щоб попередити інших.

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

Як реалізована доступність даних (DA) в Ethereum Rollup

З огляду на вищесказане, давайте подивимося, як доступність даних (DA) реалізована в роллапах Ethereum, і це стає цілком зрозумілим: пропонент блоку в роллапі називається секвенсором, який через певні проміжки часу публікує дані, необхідні для перевірки переходів станів другого рівня в Ethereum. Зокрема, він ініціює транзакцію за визначеним контрактом, вставляючи дані, пов'язані з DA, в користувацькі вхідні параметри, які потім записуються в блок Ethereum. З огляду на високий ступінь децентралізації Ethereum, можна бути впевненим, що дані, подані секвенсором, будуть безперешкодно отримані "верифікаторами". Однак організації, які відіграють роль "верифікаторів", відрізняються в різних мережах Rollup.

Наприклад, у випадку Arbitrum, секвенсор відправляє партії транзакцій на певний контракт на Ethereum. Сам контракт не перевіряє ці дані, але видає подію для повних вузлів L2, яка повідомляє їм про те, що секвенсор опублікував пакет транзакцій. Зокрема, ZK Rollups використовують контракт Verifier на Ethereum як "верифікатор". У ZK Rollup потрібно опублікувати лише State Diff + Validity Proof, тобто інформацію про зміни стану плюс підтвердження дійсності. Верифікатор перевіряє підтвердження дійсності, щоб переконатися, що воно збігається з State Diff. Якщо перевірка пройшла успішно, опублікований секвенсором L2-блок/пакет вважається дійсним.

(Джерело: колишня Біла книга "Полігон Гермес")

Оптимістичні роллапи вимагають публікації більшої кількості даних в Ethereum, оскільки вони покладаються виключно на повні вузли L2 для завантаження даних і перевірки дійсності блоків. Це означає, що, як мінімум, цифрові підписи кожної транзакції L2 (зараз зазвичай використовують агреговані підписи) повинні бути розкриті. Якщо здійснюються виклики контрактів, вхідні параметри також повинні бути розкриті, на додаток до адрес передачі транзакцій, значень nonce для запобігання атакам повторного відтворення і т.д. Однак, порівняно з повними даними про транзакції, все ж таки є певна обрізка.

У порівнянні з ZK Rollups, вартість DA (доступність даних) оптимістичних згортань є вищою, оскільки ZK Rollups потрібно лише розкрити остаточні зміни стану після виконання пакету транзакцій, супроводжуючи їх підтвердженням, використовуючи лаконічність ZK SNARK/STARK; тоді як оптимістичні згортання можуть використовувати лише найбільш громіздкий метод, що вимагає повторного виконання всіх транзакцій іншими повними вузлами L2.

Раніше W3hitchhiker приблизно підрахував, що без урахування майбутніх розробок EIP-4844 і блобів ефект масштабування ZKR (Zero-Knowledge Rollups) може в кілька разів перевищити ефект OPR (Optimistic Rollups). Якщо розглянути смарт-гаманці, пов'язані з EIP-4337 (які використовують відбитки пальців, дані райдужної оболонки ока замість підписів приватних ключів), то перевага ZKR буде ще більш очевидною, оскільки їм не потрібно публікувати бінарні дані відбитків пальців, райдужної оболонки ока на Ethereum, в той час як Optimistic Rollups це роблять.

Що стосується валідіуму і плазми/оптимуму, то вони фактично використовують позаланцюговий шар DA Ефіріуму для досягнення DA. Наприклад, ImmutableX, яка прийняла систему перевірки достовірності, створила набір вузлів DAC (Data Availability Committee) спеціально для публікації даних, пов'язаних з DA; Metis публікує дані DA на Memlabs, а Rooch і Manta використовують Celestia. В даний час, завдяки наявності DAS (Data Availability Solutions) і систем захисту від шахрайства, Celestia є одним з найбільш надійних проектів рівня DA за межами Ethereum.

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

1. Ця стаття передрукована з[Geek Web3]. Переслати оригінальну назву: Непорозуміння щодо доступності даних: DA = Data Publishing ≠ Historical Data Retrieva, всі авторські права належать оригінальному автору [ Faust, Geek web3]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.