Це остання частина серії інтерв’ю Decentralized Rollup. У цьому епізоді досліджується децентралізація зведених даних з точки зору «Доступності даних і децентралізованого зберігання». Ми запросили Ці Чжоу, засновника EthStorage, обговорити, як DA може повторно використовувати атрибути безпеки основної мережі Ethereum, EIP-4844 і danksharding, а також порівняти безпеку різних моделей DA. Вчитель Чжоу також представив, як EthStorage можна поєднати з EIP-4844 у наступному оновленні Ethereum.
Представлення гостей
Я дуже радий поділитися з вами деякими нашими думками про всю технологію Ethereum DA та децентралізоване сховище, яке ми створили для неї. Я приєднався до індустрії Web3 на повний робочий день у 2018 році. Раніше я працював інженером у великих компаніях, таких як Google і Facebook. Має ступінь доктора філософії в Технологічному інституті Джорджії. З 2018 року я стежу та працюю над інфраструктурою Web3. Основна причина в тому, що я також робив це на великих фабриках раніше, включаючи розподілені системи та розподілене зберігання. Крім того, я також вважаю, що є ще багато можливостей для вдосконалення цього аспекту всього блокчейну. Незалежно від того, що ми робили на початку, як-от технологія, яка називається шардинг виконання. Отже, це сегментування Ethereum 1.0, а тепер і технологія, що називається сегментуванням даних Ethereum 2.0, і подальша доступність даних. Насправді всі вони є деякими інноваціями та роботами, які перевірені на всій інфраструктурі Web3.
Тож ми також уважно стежимо за дорожньою картою Ethereum, вивчаємо та досліджуємо, беремо участь і вдосконалюємось у цій спільноті. Наприкінці минулого року ми мали велику честь отримати підтримку від Ethereum Foundation для нашого дослідження «Вибірка доступності даних». Допоможіть Ethereum Foundation провести деяку теоретичну роботу, деякі дослідницькі роботи щодо danksharding, зокрема, як ефективно відновлювати дані. У той же час ми також розробляємо EthStorage, рівень даних Ethereum на основі технології DA Ethereum. Ми можемо використовувати смарт-контракти Ethereum для перевірки зберігання даних поза мережею в масштабі. Це також дуже важливо для Ethereum. Тому я дуже радий поділитися з вами сьогодні тим, як EthStorage може краще побудувати мережу рівнів зберігання даних на основі технології DA.
Розділ інтерв’ю
Частина 1: Обговорення визначення DA
Як доступність даних (DA) забезпечує безпеку зведених даних
Перш за все, у процесі дослідження DA я також виявив, що багато людей не розуміють визначення DA. Я також дуже радий обговорити це сьогодні. До цього я також обговорював DA з багатьма членами Ethereum Foundation, такими як Dankrad Feist, і важливу роль, яку DA відіграє в усьому Ethereum L2.
Я згадав деякі основні робочі механізми зведення Ethereum, як перемістити ці транзакції в ланцюжку в оф-чейн, а потім використати низку методів доказів (доказ шахрайства та доказ дійсності), щоб повідомити смарт-контракт L1, що ці результати виконання прийнятні. Доведіть, що це істинно за допомогою цих доказів.
Тоді дуже важливим ядром є те, що вони сподіваються повторно використовувати безпеку самої мережі Ethereum, але в той же час зможуть значно розширити всю обчислювальну потужність Ethereum. Щойно я сказав, що розширення обчислювальної потужності фактично виводить обчислення з ланцюжка за межі ланцюга, тож як можна забезпечити безпеку Ethereum одночасно.
Наприклад, у випадку Optimistic Rollup, як переконатися, що хтось може викликати секвенсор на зловмисні дії?Дуже важливо знати, як виглядає конкретна вихідна транзакція в ланцюжку. Якщо конкретні вихідні транзакції поза ланцюжком недоступні, я не можу знайти вихідні записи транзакцій, щоб оскаржити секвенсор у ланцюжку. Таким чином, DA може гарантувати безпеку, оскільки йому потрібно дозволити метаданим кожної транзакції поза ланцюгом бути доступними в ланцюжку.
Розширити простір блоку
Оскільки всі наші дані про транзакції мають бути завантажені в ланцюжок, навіть якщо обчислення не потрібні, ми все одно створимо величезні дані про транзакції. Тоді основна проблема, яку вона має вирішити, кожен може зрозуміти, що це дуже ефективна технологія для розширення блокового простору. Якщо ви добре розумієте структуру всього блокчейну, кожен блок містить багато вмісту транзакцій. Сам блок цієї транзакції, ми називаємо його простором блоку.
Зараз простір кожного блоку в Ethereum становить близько 2300 Кб. Але така кількість явно не зможе задовольнити потреби наступного розширення Ethereum. Тут можна зробити дуже швидкий розрахунок: розділіть простір у 200 Кбайт на кількість кожної транзакції приблизно в 100 байтів і отримайте кількість у 2000 транзакцій. Розділіть 2000 транзакцій на час блокування Ethereum 12, що означає, що верхня межа TPS Ethereum обмежена приблизно 100. Що ж, насправді це дуже мала кількість для всього плану розширення Ethereum.
Тому Ethereum L2 піклується про те, як забезпечити безпеку та як розмістити велику кількість блокових даних у просторі блоків. Тоді, незалежно від того, чи є це доказом шахрайства чи доказом дійсності, дані в просторі блоків Ethereum можна повторно використовувати для відповідних перевірок. Нарешті, Ethereum може гарантувати безпеку результатів обчислень транзакцій поза мережею. Отже, це в основному взаємозв’язок між DA та безпекою Ethereum.
Зрозумійте DA з точки зору вартості пропускної здатності мережі та вартості зберігання
Основна вартість DA складається з двох аспектів: один називається вартістю пропускної здатності мережі, а інший – вартістю зберігання.
З точки зору вартості пропускної здатності мережі, наприклад, у мережі P2P поточний метод блокової трансляції Bitcoin та Ethereum полягає в тому, щоб надсилати всі вузли P2P через плітки (мовлення), щоб повідомити всім, що у мене є новий блок. Ось так. Перевага такого мережевого підходу полягає в тому, що він дуже безпечний, і всі вузли мережі згодом отримають резервну копію.
Недоліком є те, що він має великі накладні витрати на пропускну здатність мережі та затримку. Ми знаємо, що Ethereum створює блок за 12 секунд після оновлення POS. Отже, якщо блок занадто великий і це може зайняти більше 12 секунд, велика кількість блоків не може бути згенерована, і, зрештою, вся пропускна здатність мережі впаде до неприйнятного рівня. Тож ви можете розглядати DA як рішення проблеми пропускної здатності великої кількості даних у блокчейні.
По-друге, це вартість зберігання.Насправді Ethereum Foundation веде багато дискусій щодо цього аспекту. У дизайні основного рішення це не дозволить постійно зберігати дані блоку, завантажені всім DA.
Це призводить до іншого питання. Коли у мене так багато даних у ланцюжку, але через тиждень або два вони будуть відкинуті протоколом Ethereum. Тож у цьому процесі ми маємо кращі децентралізовані рішення для збереження даних DA?
Це також один із наших початкових намірів під час розробки EthStorage. По-перше, для багатьох зведених даних потрібно зберігати дані протягом більш тривалого періоду часу. Щодо другого аспекту, з цими даними я можу фактично використовувати DA для кращого виконання деяких повноланцюжкових програм. Наприклад, NFT цілого ланцюжка або інтерфейс багатьох DApps, навіть включаючи велику кількість статей або коментарів, написаних усіма в соціальних мережах. Потім їх можна буде завантажити в увесь блокчейн через мережу DA за нижчою ціною та отримати такий же рівень безпеки, як Ethereum L1.
Це сталося після того, як ми дослідили всю технологію Ethereum DA, включаючи обговорення з багатьма основними співробітниками Ethereum, ми виявили, що в цьому відношенні Ethereum потребує рівня зберігання, і це децентралізований рівень, який не повинен відповідати за Сам Ethereum. Рівень зберігання, який оновлює протокол, або те, що ми називаємо модульним рівнем зберігання, щоб вирішити проблему довгострокового зберігання даних.
Частина II: Обговорення різних схем DA
Взаємозв’язок між EIP-4844 і Danksharding і чому потрібно розгортати EIP-4844
Proto-danksharding також називається EIP-4844, який, на мою думку, можна вважати наступним дуже великим оновленням Ethereum. Існує дуже важлива причина, чому виконано 4844. Коли Ethereum Gene оцінює шлях оновлення шардингу Ethereum, тобто час для Danksharding, вони вважають, що весь час оновлення досить довгий, наприклад, може знадобитися три роки, щоб п'ять років. Це був 2021, 2020 рік.
Тоді в процесі вони прогнозують, що незабаром на Ethereum буде запущено багато Rollup, але через Danksharding інтерфейс даних, який він надає, повністю відрізняється від інтерфейсу даних Calldata, який зараз використовується Rollup. Це призведе до того, що велика кількість додатків Ethereum не зможе швидко оновитися через новий інтерфейс і зможе безперешкодно отримати переваги, надані їм Danksharding.
Коли я був у Devcon минулого року, Віталік також згадав, що він сподівається, що Ethereum зможе краще обслуговувати цей рівень 2, щоб вони могли розробляти свої контракти, використовуючи той самий інтерфейс Danksharding. Після оновлення Danksharding вони можуть безпосередньо успадкувати нові переваги, надані Danksharding, без необхідності оновлювати свої існуючі та перевірені контракти.
Тож EIP-4844 насправді є надзвичайно спрощеною версією Danksharding, яка надає той самий інтерфейс програми, що й Danksharding, включаючи новий код операції під назвою Data Hash; і новий об’єкт даних під назвою Binary Large Objects, який є Blob.
Ці об’єкти даних розроблено, щоб зробити зведення сумісним зі структурою даних, заздалегідь наданою Danksharding, тобто Danksharding забезпечить подібні концепції, такі як той самий хеш даних і Blob. Але через EIP-4844 вони заздалегідь реалізували ці ідеї в наступному оновленні Ethereum. Таким чином, у всій функції дизайну EIP-4844 ви можете подивитися на їхні інтерфейси та, наприклад, інструкції попередньої компіляції та нещодавно додані, тоді ви вже можете смутно бачити майбутнє всього Danksharding, як застосувати його на Ethereum Процес взаємодії шарів.
У зв’язку з цим Ethereum також думає з точки зору додатків, як можна зробити деякі оновлення заздалегідь, щоб дозволити додаткам краще користуватися різними технологіями розширення на Ethereum, і немає потреби в додаткових витратах на оновлення.
Але є проблема, що EIP-4844 не вирішує проблему розширення всього блокового простору, а Danksharding може її вирішити. Поточний розмір блоку Ethereum становить близько 200 КБ. Після Danksharding запланований розмір у специфікації становить 32 мегабайти, що майже в 100 разів більше. Отже, поточний EIP-4844 фактично не вирішує проблему пропускної здатності блокчейну в блоці.
Як Danksharding вирішує проблему розширення блокового простору
Згідно з проектом 4844, під час процесу трансляції даних у ланцюжку він усе ще використовує той самий метод, що й попередній виклик даних, і транслює через мережу P2P. Тоді цей метод трансляції зрештою буде обмежений фізичним вузьким місцем усієї смуги пропускання мережі P2P. Метод проектування Danksharding змінив мережеве мовлення P2P, а потім технологію вибірки даних, так що кожному не потрібно завантажувати всі блокові дані, але також відомо, що ці блокові дані можна завантажити.
Насправді, у певному сенсі це трохи схоже на метод ZK. Завдяки вибірці даних я знаю, що мережа містить (32 мегабайти/блок) блокові дані, надані Danksharding. Але мені не потрібно завантажувати всі 32 мегабайти даних, щоб зберегти їх локально. Це також можна зробити, якщо є достатня пропускна здатність машини та достатня продуктивність пам’яті, але для звичайного верифікатора йому не потрібно завантажувати всі 32 мегабайти даних.
Деякі розробки та досвід тестової мережі EIP-4844
Нещодавно ми запустили нашу внутрішню тестову мережу EIP-4844 і розгорнули відповідний контракт для тестування, включаючи завантаження даних blob, виклик контракту та перевірку даних, які ми повністю пройшли. Отже, як тільки EIP-4844 буде онлайн, ми зможемо розгорнути наші контракти якомога швидше.
У той же час ми також сподіваємося, що завдяки нашій поточній співпраці з деякими розробниками Ethereum, а також деяким із наших розроблених контрактів, ми зможемо надати час для розробки різних зведених пакетів в Ethereum, а також для навчання та різноманітних інструментів.
Тож нещодавно ми надіслали багато коду в Ethereum, набір інструментів для EIP-4844, включаючи нові смарт-контракти для підтримки коду операції, оскільки solidity все ще не підтримує код операції хешу даних. Отже, усю роботу ми вже синхронізуємо з деякими розробниками Ethereum Foundation.
Застосування та обмеження Комітету з доступності даних (DAC)
Тому що більше 90% витрат, які сплачують користувачі L2, оплачуються доступністю даних.Щоб краще знизити вартість завантаження даних, багато проектів L2, включаючи ZKSync, запустили ZKPorter, а Arbitrum створив Arbitrum Nova. Вони надають власний рівень даних, надаючи власний Комітет доступності даних DAC.
Цей комітет даних забезпечить додаткову довіру для досягнення такого ж додаткового рівня безпеки, як Ethereum. Тож коли вони обирають комітет із даних, вони зазвичай обирають відомих постачальників даних або відомі компанії для участі у збереженні цих даних. Але насправді буде багато викликів і сумнівів, тому що всі вважають, що це фактично порушення принципу недоступності децентралізації, а значить, кожен може брати участь. Але нинішня ситуація полягає в тому, що більшість комітетів з даних – це кілька організацій, які дуже близькі до партії проекту Layer2.
Як Arbitrum Nova, коли я дивився останній раз, таких вузлів було, напевно, шість-сім. Наприклад, запуск у хмарі Google або запуск на вузлах комітету хмарних даних Amazon для збереження цих даних, і вони можуть забезпечити всі витрати на виконання на Arbitrum Nova. Перевагою цього є те, що його поточна вартість виконання становить приблизно одну тисячну від вартості Ethereum. Оскільки йому не потрібно записувати всі дані на рівень 1 Ethereum. Але зараз він все ще відносно централізований, тому щодо програми з відносно високою вартістю виникнуть відносно великі занепокоєння, оскільки якщо є велика сума коштів, десятки або сотні мільйонів коштів, тоді він повинен вірити, що дані даних комітет придатний для використання.
Отже, коли ми розробляли EthStorage, у нас не було жодного поняття комітету даних. Ми сподіваємося, що в процесі розробки кожен зможе взяти участь і стати постачальником даних. І вони використовують зашифровані докази, щоб довести, що вони справді зберігали ці дані. Через цю модель комітету даних теоретично, хоча я сказав, що у мене є сім і вісім вузлів комітету даних, насправді я можу зберегти лише один фрагмент фізичних даних, але я можу показати, що маю сім або вісім адрес. надати ці дані.
Тоді як довести, що я маю достатньо фізичних копій цих даних для забезпечення безпеки даних. Насправді, це дуже важлива інновація, коли ми робимо EthStorage, і це також те, на чому ми наголошуємо, коли йдемо проповідувати ESP Foundation Ethereum (Програма екологічної підтримки). Ми використовуємо технологію шифрування ZK, яку використовує EthStorage, щоб захистити вузли, надані даними Layer2. Вони можуть приєднатися без дозволу та можуть довести, що вони мають стільки копій сховища, і можуть краще забезпечити безпеку даних.
Тож я думаю, що DAC справді є дуже тимчасовим рішенням щодо вартості завантаження даних на Layer1. Ми вважаємо, що ми можемо забезпечити краще рішення для зберігання даних за допомогою деяких технологій шифрування EthStorage в поєднанні з деякими методами перевірки доказів у контрактах рівня 1 на основі Ethereum. Далі, із запуском Ethereum 4844, ми візьмемо на себе ініціативу, щоб поділитися з вами цим інноваційним вмістом і результатами його роботи в мережі.
Різниця між EthStorage і DAC
EthStorage – це фактично зведене сховище Ethereum, Storage rollup. Тоді ми можемо припустити, що рівень 2 — це не реалізація Ethereum EVM, а дуже велика база даних або база даних ключових значень. Це може бути до 10 ТБ, сотні ТБ і навіть тисячі, що становить таку базу даних на рівні ПБ.
Тоді як переконатися, що дані в моїй базі даних можуть мати такий самий захист, як Ethereum. Перш за все, перший крок полягає в тому, що нам потрібно опублікувати всі ці великомасштабні дані в базі даних на рівні 1 Ethereum через DA, щоб кожен міг побачити, що ці дані доступні на всьому рівні DA Ethereum. Але ми не можемо гарантувати, що їх можна отримати назавжди, оскільки Ethereum DA видалить дані приблизно через два або чотири тижні.
Другий крок – після того, як ми завантажимо дані, а потім збережемо їх на наших вузлах рівня 2. На відміну від DAC, наші вузли зберігання даних не мають дозволу, і кожен може брати участь. І воно підтверджує своє зберігання, а потім отримує відповідну винагороду. Цей метод реалізується через набір механізмів підтвердження зберігання, які ми створили. Звичайно, цей механізм підтвердження зберігання також натхненний деякими схемами проектування систем підтвердження зберігання, таких як Filecoin і Arweave. Однак нам потрібна мережа та система перевірки для фреймворку DA Ethereum і смарт-контрактів Ethereum, щоб виконати відповідні перевірки зберігання. Тож у зв’язку з цим ми вважаємо, що маємо унікальний внесок у всю екологію Ethereum і навіть у все децентралізоване сховище.
Механізм підтвердження зберігання
По суті, всі механізми підтвердження зберігання, включаючи Filecoin і Arweave, повинні спочатку закодувати метадані користувача. Але цей процес кодування потрібно кодувати відповідно до адреси постачальника даних, тобто кожен постачальник даних повинен мати власну адресу, а потім кодувати відповідно до своєї адреси та метаданих, щоб зберегти унікальну репліку. (тільки копіювати) речі. Наприклад, дані hello world можуть зберігатися на чотирьох або п’яти різних фізичних машинах у традиційній централізованій базі даних або в традиційній розподіленій системі, кожна з яких є hello world. Але в EthStorage він зберігає чотири, п’ять, десять або двадцять, і його hello world буде закодовано в різні дані відповідно до адреси кожного постачальника даних, а потім збережено в різних місцях.
Перевагою цього є те, що ми можемо використовувати криптографічні механізми, щоб довести, що існує дуже багато різних адрес, які є різними провайдерами зберігання. Вони закодували дані та зробили відповідні докази зберігання на основі закодованих даних. По суті, Filecoin і Arweave схожі на це. Але вони призначені лише для статичних даних, зараз ми націлені на гарячі дані Ethereum DA. І за допомогою смарт-контракту Ethereum можна перевірити, що існує дуже багато фізичних копій цих даних. Тобто для кожного закодованого даних ми доведемо, що ці закодовані дані зберігаються в цій мережі, а дані, які відповідають кожному закодованому даному, різні, оскільки вони закодовані адресами різних постачальників сховищ.
Таким чином, в основному ми оптимізуємо та покращуємо деякі існуючі ідеї децентралізованого зберігання під час процесу проектування. Але в той же час нам також потрібно зробити багато оптимізації рішення DA Ethereum, включаючи модифікацію динамічних даних, як ефективно доводити та оптимізувати витрати на газ за контрактами Ethereum. Отже, потрібно провести багато передових технологій і досліджень.
Як EthStorage підтримує Proof of Storage без дозволу
В Ethereum є свого роду вузол, який називається архівним вузлом, який зберігатиме історичні записи всіх транзакцій в Ethereum, включаючи стан світу. Але величезна проблема в Danksharding полягає в тому, що план Danksharding генеруватиме близько 80 ТБ даних на рік. Таким чином, якщо припустити, що Ethereum працює протягом трьох-чотирьох років, він генеруватиме від 200 до 300 ТБ даних і буде продовжувати збільшуватися. Ну, насправді це створить багато проблем для архівного вузла, оскільки в процесі роботи архівного вузла він не має додаткової економії маркерів, щоб мотивувати всіх зберігати ці дані.
EthStorage спочатку має вирішити проблему стимулів токенів для постійного зберігання даних. У зв’язку з цим ми фактично застосували модель дисконтованих грошових потоків Arweave, щоб реалізувати стимули. І в той же час дуже ефективно дозволити йому виконуватися на всьому розумному контракті.
По-друге, це бездозвільний підхід. Оскільки наш дизайн стимулів заохочує 10, 50 або навіть 100 вузлів зберігати дані в мережі. Таким чином, для будь-якого вузла він може зв’язатися з будь-яким із них, синхронізувати відповідні дані, а потім він може стати стороною зберігання даних. Також можуть бути деякі оптимізовані проекти для збільшення обсягу даних.
По-третє, оскільки вузол зберігання повинен зберігати всі дані одночасно, у довгостроковій перспективі це можуть бути сотні терабайт або навіть рівень даних PB. Тому для одного вузла вартість дуже висока. Тож ми створили ще одну річ під назвою шардинг даних. Таким чином, для звичайних вузлів він повинен мати ємність лише 4 ТБ (наш поточний проект становить 4 ТБ, звичайно, у майбутньому він може бути оновлений до 8 ТБ), і він може зберегти частину архівованих файлів. даних у мережі, але ми також використовуємо деякі механізми заохочення, щоб гарантувати, що після того, як усі нарешті об’єднають усі ці дані, усі вони можуть бути збережені в нашій мережі рівня 2.
Тож тут є багато проблем, як-от проблема надто великої кількості даних, спричинена вузлами архівування; проблема стимулювання токенів; проблема децентралізованого доступу... Ми можемо вирішити ці проблеми через Ethereum. Смарт-контракт розгорнуто на рівні 1, щоб реалізувати це автоматично. Тож для нас ми просто надаємо мережу передачі даних, щоб кожен міг завантажити дані та створити сертифікат зберігання, якщо у нього є достатня вартість даних, надіслати його в мережу Ethereum, а потім отримати відповідний прибуток. Увесь наш контракт уже розроблено, і ми почали налагоджувати на 4844 Devnet Ethereum.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Засновник EthStorage: доступність даних і децентралізоване зберігання
Вступ
Це остання частина серії інтерв’ю Decentralized Rollup. У цьому епізоді досліджується децентралізація зведених даних з точки зору «Доступності даних і децентралізованого зберігання». Ми запросили Ці Чжоу, засновника EthStorage, обговорити, як DA може повторно використовувати атрибути безпеки основної мережі Ethereum, EIP-4844 і danksharding, а також порівняти безпеку різних моделей DA. Вчитель Чжоу також представив, як EthStorage можна поєднати з EIP-4844 у наступному оновленні Ethereum.
Представлення гостей
Я дуже радий поділитися з вами деякими нашими думками про всю технологію Ethereum DA та децентралізоване сховище, яке ми створили для неї. Я приєднався до індустрії Web3 на повний робочий день у 2018 році. Раніше я працював інженером у великих компаніях, таких як Google і Facebook. Має ступінь доктора філософії в Технологічному інституті Джорджії. З 2018 року я стежу та працюю над інфраструктурою Web3. Основна причина в тому, що я також робив це на великих фабриках раніше, включаючи розподілені системи та розподілене зберігання. Крім того, я також вважаю, що є ще багато можливостей для вдосконалення цього аспекту всього блокчейну. Незалежно від того, що ми робили на початку, як-от технологія, яка називається шардинг виконання. Отже, це сегментування Ethereum 1.0, а тепер і технологія, що називається сегментуванням даних Ethereum 2.0, і подальша доступність даних. Насправді всі вони є деякими інноваціями та роботами, які перевірені на всій інфраструктурі Web3.
Тож ми також уважно стежимо за дорожньою картою Ethereum, вивчаємо та досліджуємо, беремо участь і вдосконалюємось у цій спільноті. Наприкінці минулого року ми мали велику честь отримати підтримку від Ethereum Foundation для нашого дослідження «Вибірка доступності даних». Допоможіть Ethereum Foundation провести деяку теоретичну роботу, деякі дослідницькі роботи щодо danksharding, зокрема, як ефективно відновлювати дані. У той же час ми також розробляємо EthStorage, рівень даних Ethereum на основі технології DA Ethereum. Ми можемо використовувати смарт-контракти Ethereum для перевірки зберігання даних поза мережею в масштабі. Це також дуже важливо для Ethereum. Тому я дуже радий поділитися з вами сьогодні тим, як EthStorage може краще побудувати мережу рівнів зберігання даних на основі технології DA.
Розділ інтерв’ю
Частина 1: Обговорення визначення DA
Як доступність даних (DA) забезпечує безпеку зведених даних
Перш за все, у процесі дослідження DA я також виявив, що багато людей не розуміють визначення DA. Я також дуже радий обговорити це сьогодні. До цього я також обговорював DA з багатьма членами Ethereum Foundation, такими як Dankrad Feist, і важливу роль, яку DA відіграє в усьому Ethereum L2.
Я згадав деякі основні робочі механізми зведення Ethereum, як перемістити ці транзакції в ланцюжку в оф-чейн, а потім використати низку методів доказів (доказ шахрайства та доказ дійсності), щоб повідомити смарт-контракт L1, що ці результати виконання прийнятні. Доведіть, що це істинно за допомогою цих доказів.
Тоді дуже важливим ядром є те, що вони сподіваються повторно використовувати безпеку самої мережі Ethereum, але в той же час зможуть значно розширити всю обчислювальну потужність Ethereum. Щойно я сказав, що розширення обчислювальної потужності фактично виводить обчислення з ланцюжка за межі ланцюга, тож як можна забезпечити безпеку Ethereum одночасно.
Наприклад, у випадку Optimistic Rollup, як переконатися, що хтось може викликати секвенсор на зловмисні дії?Дуже важливо знати, як виглядає конкретна вихідна транзакція в ланцюжку. Якщо конкретні вихідні транзакції поза ланцюжком недоступні, я не можу знайти вихідні записи транзакцій, щоб оскаржити секвенсор у ланцюжку. Таким чином, DA може гарантувати безпеку, оскільки йому потрібно дозволити метаданим кожної транзакції поза ланцюгом бути доступними в ланцюжку.
Розширити простір блоку
Оскільки всі наші дані про транзакції мають бути завантажені в ланцюжок, навіть якщо обчислення не потрібні, ми все одно створимо величезні дані про транзакції. Тоді основна проблема, яку вона має вирішити, кожен може зрозуміти, що це дуже ефективна технологія для розширення блокового простору. Якщо ви добре розумієте структуру всього блокчейну, кожен блок містить багато вмісту транзакцій. Сам блок цієї транзакції, ми називаємо його простором блоку.
Зараз простір кожного блоку в Ethereum становить близько 2300 Кб. Але така кількість явно не зможе задовольнити потреби наступного розширення Ethereum. Тут можна зробити дуже швидкий розрахунок: розділіть простір у 200 Кбайт на кількість кожної транзакції приблизно в 100 байтів і отримайте кількість у 2000 транзакцій. Розділіть 2000 транзакцій на час блокування Ethereum 12, що означає, що верхня межа TPS Ethereum обмежена приблизно 100. Що ж, насправді це дуже мала кількість для всього плану розширення Ethereum.
Тому Ethereum L2 піклується про те, як забезпечити безпеку та як розмістити велику кількість блокових даних у просторі блоків. Тоді, незалежно від того, чи є це доказом шахрайства чи доказом дійсності, дані в просторі блоків Ethereum можна повторно використовувати для відповідних перевірок. Нарешті, Ethereum може гарантувати безпеку результатів обчислень транзакцій поза мережею. Отже, це в основному взаємозв’язок між DA та безпекою Ethereum.
Зрозумійте DA з точки зору вартості пропускної здатності мережі та вартості зберігання
Основна вартість DA складається з двох аспектів: один називається вартістю пропускної здатності мережі, а інший – вартістю зберігання.
З точки зору вартості пропускної здатності мережі, наприклад, у мережі P2P поточний метод блокової трансляції Bitcoin та Ethereum полягає в тому, щоб надсилати всі вузли P2P через плітки (мовлення), щоб повідомити всім, що у мене є новий блок. Ось так. Перевага такого мережевого підходу полягає в тому, що він дуже безпечний, і всі вузли мережі згодом отримають резервну копію.
Недоліком є те, що він має великі накладні витрати на пропускну здатність мережі та затримку. Ми знаємо, що Ethereum створює блок за 12 секунд після оновлення POS. Отже, якщо блок занадто великий і це може зайняти більше 12 секунд, велика кількість блоків не може бути згенерована, і, зрештою, вся пропускна здатність мережі впаде до неприйнятного рівня. Тож ви можете розглядати DA як рішення проблеми пропускної здатності великої кількості даних у блокчейні.
По-друге, це вартість зберігання.Насправді Ethereum Foundation веде багато дискусій щодо цього аспекту. У дизайні основного рішення це не дозволить постійно зберігати дані блоку, завантажені всім DA.
Це призводить до іншого питання. Коли у мене так багато даних у ланцюжку, але через тиждень або два вони будуть відкинуті протоколом Ethereum. Тож у цьому процесі ми маємо кращі децентралізовані рішення для збереження даних DA?
Це також один із наших початкових намірів під час розробки EthStorage. По-перше, для багатьох зведених даних потрібно зберігати дані протягом більш тривалого періоду часу. Щодо другого аспекту, з цими даними я можу фактично використовувати DA для кращого виконання деяких повноланцюжкових програм. Наприклад, NFT цілого ланцюжка або інтерфейс багатьох DApps, навіть включаючи велику кількість статей або коментарів, написаних усіма в соціальних мережах. Потім їх можна буде завантажити в увесь блокчейн через мережу DA за нижчою ціною та отримати такий же рівень безпеки, як Ethereum L1.
Це сталося після того, як ми дослідили всю технологію Ethereum DA, включаючи обговорення з багатьма основними співробітниками Ethereum, ми виявили, що в цьому відношенні Ethereum потребує рівня зберігання, і це децентралізований рівень, який не повинен відповідати за Сам Ethereum. Рівень зберігання, який оновлює протокол, або те, що ми називаємо модульним рівнем зберігання, щоб вирішити проблему довгострокового зберігання даних.
Частина II: Обговорення різних схем DA
Взаємозв’язок між EIP-4844 і Danksharding і чому потрібно розгортати EIP-4844
Proto-danksharding також називається EIP-4844, який, на мою думку, можна вважати наступним дуже великим оновленням Ethereum. Існує дуже важлива причина, чому виконано 4844. Коли Ethereum Gene оцінює шлях оновлення шардингу Ethereum, тобто час для Danksharding, вони вважають, що весь час оновлення досить довгий, наприклад, може знадобитися три роки, щоб п'ять років. Це був 2021, 2020 рік.
Тоді в процесі вони прогнозують, що незабаром на Ethereum буде запущено багато Rollup, але через Danksharding інтерфейс даних, який він надає, повністю відрізняється від інтерфейсу даних Calldata, який зараз використовується Rollup. Це призведе до того, що велика кількість додатків Ethereum не зможе швидко оновитися через новий інтерфейс і зможе безперешкодно отримати переваги, надані їм Danksharding.
Коли я був у Devcon минулого року, Віталік також згадав, що він сподівається, що Ethereum зможе краще обслуговувати цей рівень 2, щоб вони могли розробляти свої контракти, використовуючи той самий інтерфейс Danksharding. Після оновлення Danksharding вони можуть безпосередньо успадкувати нові переваги, надані Danksharding, без необхідності оновлювати свої існуючі та перевірені контракти.
Тож EIP-4844 насправді є надзвичайно спрощеною версією Danksharding, яка надає той самий інтерфейс програми, що й Danksharding, включаючи новий код операції під назвою Data Hash; і новий об’єкт даних під назвою Binary Large Objects, який є Blob.
Ці об’єкти даних розроблено, щоб зробити зведення сумісним зі структурою даних, заздалегідь наданою Danksharding, тобто Danksharding забезпечить подібні концепції, такі як той самий хеш даних і Blob. Але через EIP-4844 вони заздалегідь реалізували ці ідеї в наступному оновленні Ethereum. Таким чином, у всій функції дизайну EIP-4844 ви можете подивитися на їхні інтерфейси та, наприклад, інструкції попередньої компіляції та нещодавно додані, тоді ви вже можете смутно бачити майбутнє всього Danksharding, як застосувати його на Ethereum Процес взаємодії шарів.
У зв’язку з цим Ethereum також думає з точки зору додатків, як можна зробити деякі оновлення заздалегідь, щоб дозволити додаткам краще користуватися різними технологіями розширення на Ethereum, і немає потреби в додаткових витратах на оновлення.
Але є проблема, що EIP-4844 не вирішує проблему розширення всього блокового простору, а Danksharding може її вирішити. Поточний розмір блоку Ethereum становить близько 200 КБ. Після Danksharding запланований розмір у специфікації становить 32 мегабайти, що майже в 100 разів більше. Отже, поточний EIP-4844 фактично не вирішує проблему пропускної здатності блокчейну в блоці.
Як Danksharding вирішує проблему розширення блокового простору
Згідно з проектом 4844, під час процесу трансляції даних у ланцюжку він усе ще використовує той самий метод, що й попередній виклик даних, і транслює через мережу P2P. Тоді цей метод трансляції зрештою буде обмежений фізичним вузьким місцем усієї смуги пропускання мережі P2P. Метод проектування Danksharding змінив мережеве мовлення P2P, а потім технологію вибірки даних, так що кожному не потрібно завантажувати всі блокові дані, але також відомо, що ці блокові дані можна завантажити.
Насправді, у певному сенсі це трохи схоже на метод ZK. Завдяки вибірці даних я знаю, що мережа містить (32 мегабайти/блок) блокові дані, надані Danksharding. Але мені не потрібно завантажувати всі 32 мегабайти даних, щоб зберегти їх локально. Це також можна зробити, якщо є достатня пропускна здатність машини та достатня продуктивність пам’яті, але для звичайного верифікатора йому не потрібно завантажувати всі 32 мегабайти даних.
Деякі розробки та досвід тестової мережі EIP-4844
Нещодавно ми запустили нашу внутрішню тестову мережу EIP-4844 і розгорнули відповідний контракт для тестування, включаючи завантаження даних blob, виклик контракту та перевірку даних, які ми повністю пройшли. Отже, як тільки EIP-4844 буде онлайн, ми зможемо розгорнути наші контракти якомога швидше.
У той же час ми також сподіваємося, що завдяки нашій поточній співпраці з деякими розробниками Ethereum, а також деяким із наших розроблених контрактів, ми зможемо надати час для розробки різних зведених пакетів в Ethereum, а також для навчання та різноманітних інструментів.
Тож нещодавно ми надіслали багато коду в Ethereum, набір інструментів для EIP-4844, включаючи нові смарт-контракти для підтримки коду операції, оскільки solidity все ще не підтримує код операції хешу даних. Отже, усю роботу ми вже синхронізуємо з деякими розробниками Ethereum Foundation.
Застосування та обмеження Комітету з доступності даних (DAC)
Тому що більше 90% витрат, які сплачують користувачі L2, оплачуються доступністю даних.Щоб краще знизити вартість завантаження даних, багато проектів L2, включаючи ZKSync, запустили ZKPorter, а Arbitrum створив Arbitrum Nova. Вони надають власний рівень даних, надаючи власний Комітет доступності даних DAC.
Цей комітет даних забезпечить додаткову довіру для досягнення такого ж додаткового рівня безпеки, як Ethereum. Тож коли вони обирають комітет із даних, вони зазвичай обирають відомих постачальників даних або відомі компанії для участі у збереженні цих даних. Але насправді буде багато викликів і сумнівів, тому що всі вважають, що це фактично порушення принципу недоступності децентралізації, а значить, кожен може брати участь. Але нинішня ситуація полягає в тому, що більшість комітетів з даних – це кілька організацій, які дуже близькі до партії проекту Layer2.
Як Arbitrum Nova, коли я дивився останній раз, таких вузлів було, напевно, шість-сім. Наприклад, запуск у хмарі Google або запуск на вузлах комітету хмарних даних Amazon для збереження цих даних, і вони можуть забезпечити всі витрати на виконання на Arbitrum Nova. Перевагою цього є те, що його поточна вартість виконання становить приблизно одну тисячну від вартості Ethereum. Оскільки йому не потрібно записувати всі дані на рівень 1 Ethereum. Але зараз він все ще відносно централізований, тому щодо програми з відносно високою вартістю виникнуть відносно великі занепокоєння, оскільки якщо є велика сума коштів, десятки або сотні мільйонів коштів, тоді він повинен вірити, що дані даних комітет придатний для використання.
Отже, коли ми розробляли EthStorage, у нас не було жодного поняття комітету даних. Ми сподіваємося, що в процесі розробки кожен зможе взяти участь і стати постачальником даних. І вони використовують зашифровані докази, щоб довести, що вони справді зберігали ці дані. Через цю модель комітету даних теоретично, хоча я сказав, що у мене є сім і вісім вузлів комітету даних, насправді я можу зберегти лише один фрагмент фізичних даних, але я можу показати, що маю сім або вісім адрес. надати ці дані.
Тоді як довести, що я маю достатньо фізичних копій цих даних для забезпечення безпеки даних. Насправді, це дуже важлива інновація, коли ми робимо EthStorage, і це також те, на чому ми наголошуємо, коли йдемо проповідувати ESP Foundation Ethereum (Програма екологічної підтримки). Ми використовуємо технологію шифрування ZK, яку використовує EthStorage, щоб захистити вузли, надані даними Layer2. Вони можуть приєднатися без дозволу та можуть довести, що вони мають стільки копій сховища, і можуть краще забезпечити безпеку даних.
Тож я думаю, що DAC справді є дуже тимчасовим рішенням щодо вартості завантаження даних на Layer1. Ми вважаємо, що ми можемо забезпечити краще рішення для зберігання даних за допомогою деяких технологій шифрування EthStorage в поєднанні з деякими методами перевірки доказів у контрактах рівня 1 на основі Ethereum. Далі, із запуском Ethereum 4844, ми візьмемо на себе ініціативу, щоб поділитися з вами цим інноваційним вмістом і результатами його роботи в мережі.
Різниця між EthStorage і DAC
EthStorage – це фактично зведене сховище Ethereum, Storage rollup. Тоді ми можемо припустити, що рівень 2 — це не реалізація Ethereum EVM, а дуже велика база даних або база даних ключових значень. Це може бути до 10 ТБ, сотні ТБ і навіть тисячі, що становить таку базу даних на рівні ПБ.
Тоді як переконатися, що дані в моїй базі даних можуть мати такий самий захист, як Ethereum. Перш за все, перший крок полягає в тому, що нам потрібно опублікувати всі ці великомасштабні дані в базі даних на рівні 1 Ethereum через DA, щоб кожен міг побачити, що ці дані доступні на всьому рівні DA Ethereum. Але ми не можемо гарантувати, що їх можна отримати назавжди, оскільки Ethereum DA видалить дані приблизно через два або чотири тижні.
Другий крок – після того, як ми завантажимо дані, а потім збережемо їх на наших вузлах рівня 2. На відміну від DAC, наші вузли зберігання даних не мають дозволу, і кожен може брати участь. І воно підтверджує своє зберігання, а потім отримує відповідну винагороду. Цей метод реалізується через набір механізмів підтвердження зберігання, які ми створили. Звичайно, цей механізм підтвердження зберігання також натхненний деякими схемами проектування систем підтвердження зберігання, таких як Filecoin і Arweave. Однак нам потрібна мережа та система перевірки для фреймворку DA Ethereum і смарт-контрактів Ethereum, щоб виконати відповідні перевірки зберігання. Тож у зв’язку з цим ми вважаємо, що маємо унікальний внесок у всю екологію Ethereum і навіть у все децентралізоване сховище.
Механізм підтвердження зберігання
По суті, всі механізми підтвердження зберігання, включаючи Filecoin і Arweave, повинні спочатку закодувати метадані користувача. Але цей процес кодування потрібно кодувати відповідно до адреси постачальника даних, тобто кожен постачальник даних повинен мати власну адресу, а потім кодувати відповідно до своєї адреси та метаданих, щоб зберегти унікальну репліку. (тільки копіювати) речі. Наприклад, дані hello world можуть зберігатися на чотирьох або п’яти різних фізичних машинах у традиційній централізованій базі даних або в традиційній розподіленій системі, кожна з яких є hello world. Але в EthStorage він зберігає чотири, п’ять, десять або двадцять, і його hello world буде закодовано в різні дані відповідно до адреси кожного постачальника даних, а потім збережено в різних місцях.
Перевагою цього є те, що ми можемо використовувати криптографічні механізми, щоб довести, що існує дуже багато різних адрес, які є різними провайдерами зберігання. Вони закодували дані та зробили відповідні докази зберігання на основі закодованих даних. По суті, Filecoin і Arweave схожі на це. Але вони призначені лише для статичних даних, зараз ми націлені на гарячі дані Ethereum DA. І за допомогою смарт-контракту Ethereum можна перевірити, що існує дуже багато фізичних копій цих даних. Тобто для кожного закодованого даних ми доведемо, що ці закодовані дані зберігаються в цій мережі, а дані, які відповідають кожному закодованому даному, різні, оскільки вони закодовані адресами різних постачальників сховищ.
Таким чином, в основному ми оптимізуємо та покращуємо деякі існуючі ідеї децентралізованого зберігання під час процесу проектування. Але в той же час нам також потрібно зробити багато оптимізації рішення DA Ethereum, включаючи модифікацію динамічних даних, як ефективно доводити та оптимізувати витрати на газ за контрактами Ethereum. Отже, потрібно провести багато передових технологій і досліджень.
Як EthStorage підтримує Proof of Storage без дозволу
В Ethereum є свого роду вузол, який називається архівним вузлом, який зберігатиме історичні записи всіх транзакцій в Ethereum, включаючи стан світу. Але величезна проблема в Danksharding полягає в тому, що план Danksharding генеруватиме близько 80 ТБ даних на рік. Таким чином, якщо припустити, що Ethereum працює протягом трьох-чотирьох років, він генеруватиме від 200 до 300 ТБ даних і буде продовжувати збільшуватися. Ну, насправді це створить багато проблем для архівного вузла, оскільки в процесі роботи архівного вузла він не має додаткової економії маркерів, щоб мотивувати всіх зберігати ці дані.
EthStorage спочатку має вирішити проблему стимулів токенів для постійного зберігання даних. У зв’язку з цим ми фактично застосували модель дисконтованих грошових потоків Arweave, щоб реалізувати стимули. І в той же час дуже ефективно дозволити йому виконуватися на всьому розумному контракті.
По-друге, це бездозвільний підхід. Оскільки наш дизайн стимулів заохочує 10, 50 або навіть 100 вузлів зберігати дані в мережі. Таким чином, для будь-якого вузла він може зв’язатися з будь-яким із них, синхронізувати відповідні дані, а потім він може стати стороною зберігання даних. Також можуть бути деякі оптимізовані проекти для збільшення обсягу даних.
По-третє, оскільки вузол зберігання повинен зберігати всі дані одночасно, у довгостроковій перспективі це можуть бути сотні терабайт або навіть рівень даних PB. Тому для одного вузла вартість дуже висока. Тож ми створили ще одну річ під назвою шардинг даних. Таким чином, для звичайних вузлів він повинен мати ємність лише 4 ТБ (наш поточний проект становить 4 ТБ, звичайно, у майбутньому він може бути оновлений до 8 ТБ), і він може зберегти частину архівованих файлів. даних у мережі, але ми також використовуємо деякі механізми заохочення, щоб гарантувати, що після того, як усі нарешті об’єднають усі ці дані, усі вони можуть бути збережені в нашій мережі рівня 2.
Тож тут є багато проблем, як-от проблема надто великої кількості даних, спричинена вузлами архівування; проблема стимулювання токенів; проблема децентралізованого доступу... Ми можемо вирішити ці проблеми через Ethereum. Смарт-контракт розгорнуто на рівні 1, щоб реалізувати це автоматично. Тож для нас ми просто надаємо мережу передачі даних, щоб кожен міг завантажити дані та створити сертифікат зберігання, якщо у нього є достатня вартість даних, надіслати його в мережу Ethereum, а потім отримати відповідний прибуток. Увесь наш контракт уже розроблено, і ми почали налагоджувати на 4844 Devnet Ethereum.