Огляд

• Зростаючий обсяг зберігання становить значні виклики для вузлів Ethereum.
• Деякі клієнти почали видалення історичних даних через обмеження зберігання, що призводить до неоднорідності поведінки зберігання серед повних вузлів у мережі.
• Для забезпечення вирівнювання у всіх клієнтів, видалення історичних даних стандартизується в EIP-4444 та EIP-4844
• Отже, відновлення останнього стану L1 або L2 шляхом повторення історичних даних ґрунтується на централізованих, позапротокольних сервісах, що спонукає до дослідження більш децентралізованих рішень, вирішених у межах Ethereum
• Мережа порталу Ethereum - це легка, децентралізована P2P-мережа для всіх типів даних Ethereum, включаючи історичні дані. Вона призначена для пристроїв з обмеженими ресурсами і надає сервіс Ethereum JSON-RPC. Історична мережа та мережа маяка майже готові до використання.
• EthStorage мережа - це стимульована модульна сховища для EIP-4844 BLOBs. Щоб зберегти BLOB, користувач викликає контракт зберігання L1put()метод з хешем BLOB та комісією в ETH. Комісія буде поступово розподілятися серед постачальників сховищ при поданні дійсного доказу зберігання позананціональних BLOB з плином часу. Тестову мережу EthStorage запущено на тестовій мережі Ethereum Sepolia з численними учасниками спільноти, які успішно доводять своє місцеве сховище.
• Майбутні ініціативи включають розробку децентралізованої державної мережі, впровадження доказу зберігання для динамічних даних різного розміру та децентралізований доступ безпосередньо з браузерів.

Визнання: Велика подяка Пайперу Мерріаму з EF, Картику Раджу з Polychain, Цяну з EthStorage за надання зворотного зв'язку щодо статті.

Фон

22 жовтня 2023 року відомий керівник розробки Go-Ethereum (Geth) Петер Силажі висловив своє глибоке занепокоєння в Twitter. Він вказав, що в той час як клієнти Geth зберігають всі історичні дані, інші клієнти Ethereum, такі як Nethermind та Besu, можуть бути налаштовані для роботи без певних історичних даних Ethereum, таких як історичні тіла та заголовки блоків. Це робить всі клієнти непослідовними і недоброчесними для Geth. Це спричинило інтенсивні обговорення та дебати щодо проблеми зберігання Ethereum у межах дорожньої карти Ethereum.

Виклик зберігання

Чому Nethermind та Besu вирішили припинити зберігання історичних даних? Які проблеми лежать в основі цього рішення? З мого погляду, існують дві основні причини:

• Вимоги до обсягу пам'яті для клієнта Ethereum стають все більш вимогливими.
• Немає жодної внутрішньопротокольної стимуляції або штрафу за зберігання історичних даних Ethereum.

Перша причина випливає з зростаючих вимог до зберігання при запуску клієнта Ethereum. Щоб детально розібратися у конкретних вимогах, наступна кругова діаграма показує розподіл витрат на зберігання для свіжого вузла Geth, на блоку 18 779 761 на 13 грудня 2023 року.

Як показує зображення:

• Загальна потреба в сховищі: 925.39 ГБ
• Історичні дані (блоки/квитанції): Приблизно 628.69 ГБ
• Стан в дереві Меркла-Патріції (MPT): Приблизно 269,74 ГБ

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

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

Ілюстрація: Настроювання Nethermined для запуску вузла без історичних тіл блоків - заощадження вартості зберігання приблизно в 460 ГБ на даний момент.

Виклик зберігання очікується посилити з майбутнім оновленням доступності даних Ethereum (DA). The шляхнаправлення на повне масштабування Ethereum DA починається з EIP-4844 в DenCun, де вводиться фіксований об'єкт великого об'єкта (BLOB), супроводжуваний незалежною моделлю оплати, відомою як blobGasPrice. Кожен BLOB встановлений на розмірі 128 КБ, і EIP-4844 дозволяє кожному блоку містити до 6 BLOBs. Для покращення масштабованості даних план передбачає впровадження 1D коду Ріда-Соломона, що дозволяє спочатку включати 32 BLOBs на блок, а в кінцевому рахунку досягати 256 BLOBs на блок при повному масштабуванні.

За участю Ethereum DA, що працює на повну ємність даних з 256 BLOB на блок, протягом одного року мережа Ethereum DA має прийняти приблизно 80 ТБ даних, перевищивши потужності зберігання більшості вузлів Ethereum.

Дорожня карта зберігання Ethereum та наслідки

Vitalik’sтвітпро дорожню карту Ethereum, в якій Пурга в основному займається зберіганням.

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

1. EIP-4444: Bound Historical Data in Execution Clients: Ця пропозиція дозволяє клієнту видалити історичні блоки, які старше одного року. Припускаючи середній розмір блоку 100K, дані історичного блоку обмежені приблизно 250 ГБ (100K (3600 24 * 365) / 12, при умові, що час блоку = 12 с).
2. EIP-4844: Shard BLOB Transactions: EIP-4844 відкидає BLOB, старший ніж 18 днів. Це більш агресивний підхід порівняно з EIP-4444, обмежуючи розмір історичного BLOB приблизно в 100 ГБ ((18 3600 24)128K 6 / 12, за умови часу блоку = 12с).

Які наслідки має видалення історичних даних з усіх клієнтів? Основна проблема полягає в тому, що свіжий вузол не може синхронізуватися з останнім станом через «повну синхронізацію» - синхронізацію для відтворення транзакцій з блоку генезису до останнього блоку. Замість цього нам доводиться вдаватися до «швидкої синхронізації» або «синхронізації стану», щоб синхронізувати останній стан від пірингів Ethereum. Цей підхід вже реалізований в Geth і працює як типова синхронізація.

Так само ця наслідок також застосовується до всіх L2, тобто свіжий вузол L2 не може повністю відтворити останній стан від L2 генезису від Ethereum, відтворюючи блоки L2 від генезису L2. Крім того, оскільки вузли L1 не зберігають стан L2, підхід «snap sync» для L2 не може походити на останній стан L2 від L1 - порушуючи важливе припущення L2 про успадкування гарантій безпеки Ethereum. Проектоване рішення буде покладатися на послуги сторонніх сторін, такі як Infura / Etherscan / самі проекти L2, щоб зберігати копію історичних даних або стану L2, який централізований з позапротокольним непрямим стимулом.

Основні питання, які ми задаємо, - це

• Чи можемо ми мати краще децентралізоване рішення, як зберігання, так і доступу, до проблеми?
• Чи можливо побудувати рішення, спрямоване на довіру до Ethereum (наприклад, на основі контракту L1) з прямим інцентивним рішенням?
• З усім цим, чи ми можемо відкрити шлях до рішення з прямим стимулюванням у протоколі для Ethereum зберігання та доступу до них у повністю децентралізований спосіб в дорожньої карти Ethereum?

Рішення

Рішення 1: Портал Ethereum мережі

Мережа Ethereum Portal служить як легка, децентралізована мережа доступу до протоколу Ethereum. Пропонуючи інтерфейс Ethereum JSON-RPC, такий як eth_call, eth_getBlockByNumber, вона перетворює запити JSON-RPC в запити P2P до розподіленої хеш-таблиці, схожої на мережу IPFS. На відміну від IPFS, який дозволяє зберігання будь-якого типу даних і піддається спаму, мережа Portal P2P виключно містить дані Ethereum, такі як історичні заголовки та тіла. Це досягається за допомогою вбудованої техніки перевірки легкого клієнта в мережі Portal.

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

Розвиток мережі Portal відповідає філософії різноманітності клієнтів Ethereum, клієнти написані на Rust, JavaScript, Nim та Go. Мережа маяка та мережа історії готові до використання, тоді як мережа стану активно розробляється. На відміну, мережа Portal не надає прямих стимулів для зберігання даних — всі вузли в мережі діють альтруїстично.

Ілюстрація: Запуск мережі Portal (Trin) з обмеженням на сховище 100 МБ.

Рішення 2: EthStorage мережі

Мережа EthStorage - децентралізована мережа з інцентивами для зберігання, спеціально розроблена для зберігання BLOBs EIP-4844, підтримувана грантом від програми ESP.

• Мінімальна довіра: на відміну від існуючих рішень, які потребують централізованого моста даних, EthStorage покладається на консенсус Ethereum та модель довіри $1/m$ постачальників зберігання EthStorage без дозволу. Процедура зберігання BLOB виглядає так: користувач підписує транзакцію, яка містить BLOB, яка викликає метод _put(key, blob_idx)_ контракту зберігання. Потім контракт зберігання зареєструє хеш BLOB і повідомить постачальників зберігання подією. Постачальники зберігання, після отримання події, завантажать та збережуть BLOB безпосередньо з мережі Ethereum DA, обійшовши проблему моста даних.
• Вирівняти вартість зберігання зі стимулом: При викликупокласти()метод, плата за зберігання повинна бути відправлена (черезmsg.value) і збережені в контракті. Ця плата за зберігання поступово розподіляється провайдерам зберігання з часом після успішного подання та верифікації доказу зберігання. Порівняно з поточною моделлю оплати плати за зберігання Ethereum, яка сплачує одноразову плату за зберігання пропоненту, плата за зберігання з часом слідує моделі обліку грошових потоків зі зниженням - припускаючи, що вартість зберігання з часом знижується по відношенню до ETH. Ця значуща інновація, запропонована EthStorage, вирівнює плату, яку сплачують користувачі та внесок провайдерів зберігання з часом.
• Доказ сховища: Доказ сховища інспірований вибірковим доступом до даних, тоді як вибірковий доступ до даних в EthStorage виконується відносно BLOB-об'єктів протягом часу, а не тих, які мають бути запропоновані в блоках. Для ефективної перевірки вибіркового доступу на ланцюжку, EthStorage широко використовує розумні контракти та найновіші розробки в технологіях SNARK.
• Мережа без дозволу: Будь-який вузол в EthStorage може бути оплачений як постачальник зберігання, поки він зберігає дані і періодично надсилає докази зберігання on-chain.

З точки зору модульності блокчейну, EthStorage діє як Ethereum Layer 2, але збирає зберігання замість комісій за транзакції. Шляхом індексації BLOB-хешів on-chain, EthStorage є модульним зберіганням для Ethereum з значною масштабованістю зберігання та економією коштів - націлено на близько 1000 разів.

З точки зору розвитку EthStorage вже інтегрований з EIP-4844 на тестовій мережі Ethereum Sepolia. Був проведений стрес-тест на EthStorage та тестовій мережі Ethereum Sepolia, включаючи запис приблизно сотень гігабайтів BLOBs на EthStorage. Понад 50 учасників спільноти приєдналися до мережі та успішно довели свої локальні сховища.

Основною перевагою мережі EthStorage є надання децентралізованої прямої стимуляції на основі Ethereum - першопрохідна функція, наскільки стосується наших поточних знань. Однак обмеження мережі полягає в тому, що вона спеціально адаптована для BLOBs фіксованого розміру.

Панель приладів EthStorage на Ethereum Devnet

Прогнозування майбутнього

Сховище Ethereum, хоч і менше висвітлене, має велике значення в екосистемі Ethereum. Оскільки мережа Ethereum переживає швидкий ріст, зберігання та доступність даних Ethereum виходять як критичні виклики. Хоча мережа Portal та мережа EthStorage знаходяться на ранніх етапах, ми уявляємо кілька захоплюючих напрямків на довгострокову перспективу:

• Децентралізований доступ з низькою затримкою до стану Ethereum. Доступ до стану Ethereum у децентралізований та перевірний спосіб є критично важливим, але складним завданням. З урахуванням традиційної настройки DHT запит до облікового запису зазвичай потребує кількох запитів до внутрішніх вузлів трие, що зберігаються в різних вузлах P2P. Це часто призводить до значних затримок. Ключовою є техніка використання структури дерева стану для прискорення доступу, як це вирішується у майбутній мережі стану мережі Ethereum Portal.
• Інтеграція між мережею Portal та мережею EthStorage: Мережа Portal може безперешкодно розширити свою підтримку для включення BLOBs в мережу, крок, вже частково зроблений командою EthStorage. Природним рухом буде об'єднати ці мережі, щоб запропонувати децентралізовану мережу JSON-RPC, здатну викликати контракти з доступом до BLOBs. Поєднуючи логіку застосування в контрактах та масштабування сховища BLOB від EthStorage, ми дозволяємо нові додатки на Ethereum, такі як динамічні децентралізовані веб-сайти (наприклад, децентралізований twitter/youtube/wikipedia/тощо).
• Децентралізований доступ з браузерів: Схоже на протокол ipfs://, який використовується для доступу до даних в мережі IPFS, є зростаюча потреба в протоколі доступу з браузерів, що є власним для Ethereum, для розблокування великого потенціалу багатофункціональних даних Ethereum. Ці дані охоплюють широкий спектр, починаючи від власності токенів та балансів до зображень NFT та динамічних децентралізованих веб-сайтів, все це стає можливим завдяки можливостям смарт-контрактів та майбутнього зберігання Ethereum. У цій сфері протокол web3://, як визначено в ERC-4804/6860, наразі активно розробляється для виконання цієї мети.
• Розширений доказ сховища для динамічних даних розміру: Поза фіксованими BLOB-ами, дослідження розширеного доказу сховища стає надзвичайно важливим для вирішення динамічних даних, таких як історичні блоки або навіть об'єкти стану. Розробка складних алгоритмів може підвищити пристосованість засобів сховища.

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

заява:

1. Ця стаття відтворена з [ технічний потік глибокого припливу], початковий заголовок - «Ethereum Storage Roadmap: Challenges and Opportunities», авторське право належить оригінальному автору [EthStorage], якщо у вас є які-небудь зауваження до репринту, будь ласка, зв'яжітьсяКоманда Gate Learn, команда займеться цим якнайшвидше згідно з відповідними процедурами.

2. Увага: Погляди та думки, висловлені у цій статті, представляють лише особисті погляди автора і не становлять жодної інвестиційної поради.

3. Інші мовні версії статті перекладені командою Gate Learn, не згадано вGate, перекладена стаття не повинна бути відтворена, поширена або плагіатована.