Що таке історичний зріст?

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

На рис. 1 показано взаємозв'язок між історичним зростанням, різними метриками протоколу та обмеженнями апаратного забезпечення вузлів Ethereum. На відміну від зростання стану, історичне зростання обмежене іншим набором обмежень апаратного забезпечення. Цей ріст тисне на мережевий I/O, оскільки нові блоки та транзакції повинні передаватися по мережі. Він також натягує простір зберігання вузла, оскільки кожен вузол Ethereum зберігає повну копію історичного запису. Якщо історичне зростання перевищує ці обмеження апаратного забезпечення, вузли більше не зможуть досягти стійкої згоди зі своїми ровесниками. Щодо огляду зростання стану та інших питань масштабування див. Частина 1цієї серії.

Рисунок 1: Перешкода розширення Ethereum

До недавнього часу більшість пропускної здатності мережі кожного вузла використовувалася для передачі історичних записів (наприклад, нових блоків та транзакцій). Це змінилося з введенням blobs в Dencunхардфорк. Краплі тепер становлять значну частину активності мережі вузлів. Однак краплі не вважаються частиною історичного запису, тому що 1) вузли зберігають їх лише протягом 2 тижнів перед викиданням їх, і 2) вони не потрібні для повторення ланцюжка від Генезису. Через (1) краплі не значно збільшують навантаження на зберігання на кожному вузлі Ethereum. Ми обговоримо краплі більш докладно пізніше в цій статті.

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

Як швидко розвивається історія?

На рисунку 2 показана швидкість історичного зростання з часу генезису Ethereum. Кожна вертикальна смуга представляє зростання за один місяць. Ось Y-вісь представляє кількість ГБ, доданих до історії за цей місяць. Транзакції категоризуються за їх "адресою призначення", а їх розмір визначається за допомогою їх RLPпредставлення байтів. Контракти, які не можуть бути легко ідентифіковані, класифікуються як «невідомі». Категорія «інші» включає довгий хвіст менших категорій, таких як інфраструктура та геймінг.

З цієї діаграми можна зробити кілька ключових висновків:

1. Історична швидкість зростання приблизно в 6-8 разів швидше, ніж зростання області: Історичний зріст недавно досяг піку на рівні 36,0 Гб/місяць і наразі становить 19,3 Гб/місяць. Зріст області досяг піку близько 6,0 Гб/місяць і зараз становить 2,5 Гб/місяць. Порівняння між історичним та обласним зростанням, як у темпах, так і в накопиченому обсязі, можна знайти пізніше у цій статті.
2. Історична швидкість зростання швидко набирала обертів перед Dencun: хоча зростання економіки штату було приблизно лінійним протягом років ( дивись Частина 1) історичний зріст був суперлінійним. Лінійний зріст призводить до квадратичного збільшення загального розміру, тоді як суперлінійний зріст призводить до збільшення швидше, ніж квадратичне. Це прискорення раптово зупинилося після Dencun, позначивши перший значний сповільнення історичного зростання в історії Ethereum.
3. Останній історичний ріст головним чином походить від Rollups: Кожен L2 публікує копію своїх транзакцій на головну мережу, генеруючи значну кількість історичних даних і роблячи rollups найбільшим внеском у історичний ріст протягом останнього року. Однак Dencun дозволяє L2 використовувати блоби замість історичних записів для публікації своїх даних транзакцій, тому rollups більше не генерують більшість історичних записів Ethereum. Ми розглянемо rollups більш детально пізніше в цій статті.

Які найбільші учасники в історії Ethereum?

Кількість історичних даних, що генерується кожною категорією контрактів, розкриває, як з часом еволюціонували патерни використання Ethereum. Фігура 3 показує відносні внески різних категорій контрактів. Це використовує ті ж дані, що й Фігура 2, нормалізовані до 100%.

Дані показують чотири відмінних епохи використання Ethereum:

Початковий період (фіолетовий): У перші роки існування Ethereum на блокчейні було мінімальна активність. Більшість цих ранніх контрактів зараз важко ідентифікувати й позначені як "невідомі" на графіку.

Епоха ERC-20 (зелена): стандарт ERC-20була завершена наприкінці 2015 року, але значного прогресу досягла лише у 2017 та 2018 роках. У 2019 році контракти ERC-20 стали найбільшою категорією за історичним зростанням.

Епоха DEX/DeFi (Коричневий): DEX та DeFi контракти з'явилися на ланцюжку ще в 2016 році і почали привертати увагу вже в 2017. Однак вони не стали найбільшою історичною категорією до Літа DeFi 2020. Контракти DeFi та DEX досягли піку понад 50% історичного зростання у різний час у 2021 та 2022 роках.

Ера Rollup (Сіра): У початковому 2023 році L2 Rollups почали систематично виконуватибільше транзакцій, ніж головна мережа. Це співпало з тим, що їхні контракти генерували велику частину історичних даних, що становило близько двох третин історичного зростання Ethereum у місяцях, що передували Денкуну.

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

У найновіших даних (квітень 2024 року) ролапи вже не генерують більшість історичних записів. Невідомо, чи майбутній історичний зріст буде домінувати ринками DEX та DeFi, чи виникнуть нові патерни використання.

Що на рахунок крапель?

Введення блобів у хардфорку Dencun значно змінило динаміку історичного зростання, дозволяючи Rollups використовувати недорогі блоби замість історичних записів для публікації даних. На рисунку 4 показано динаміку історичного зростання навколо дати оновлення Dencun. Ця діаграма схожа на рисунок 2, але кожна вертикальна смуга представляє один день, а не один місяць.

З цієї діаграми можна зробити кілька ключових висновків:

Історичний зріст від Rollups зменшився приблизно на дві третини з часу Dencun: Більшість Rollups перейшли від використання call-даних до blobs, що значно зменшило обсяг історичних даних, які вони генерують. Однак, станом на квітень 2024 року, деякіrollupsще не перейшли з виклику даних на блоби.

Загальний історичний зріст зменшився приблизно на третину з часу Dencun: Dencun в основному зменшив історичний зріст від rollups. Історичний зріст з інших категорій контрактів трохи збільшився. Навіть після Dencun історичний зріст залишається приблизно в вісім разів більшим, ніж зріст держави (деталі у наступному розділі).

Незважаючи на зменшення історичного зростання, краплі залишаються новим додатком до Ethereum. Наразі неясно, де стабілізується історичне зростання в присутності крапель.

На скільки історичний зріст є прийнятним?

Збільшення ліміту газу підвищить історичний темп зростання. Тому пропозиції щодо підвищення ліміту газу (наприклад, Pump the GasПотрібно врахувати взаємозв'язок між історичним зростанням та апаратними обмеженнями на кожному вузлі.

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

На рисунку 5 показано навантаження зберігання вузлів Ethereum з часом, а також передбачається, як це навантаження може зростати протягом наступних 3 років. Прогнози робляться за зростанням з квітня 2024 року. Цей темп може зростати або зменшуватися в майбутньому через зміни в шаблонах використання або газових лімітів.

З цього графіка можна зробити кілька ключових висновків:

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

Критичний поріг близько 1,8 терабайт: на цьому етапі багато вузлів будуть змушені оновлювати свої накопичувачі. Жорсткий диск обсягом 2 ТБ, який є типовим, надає лише 1,8 тебібайт використовуваного простору. Зверніть увагу, що терабайти (ТБ) і тебібайти (TiB, = 1024^4 байтів) - це різні одиниці. Для багатьох операторів вузла «реальний» критичний поріг ще нижчий, оскільки валідатори повинні запускати клієнт консенсусу разом із клієнтом виконання після злиття.

Поріг досягнутий за 2-3 роки: Будь-яке збільшення ліміту газу прискорить цей графік. Досягнення цього порогу накладе значний обслуговувальний бремінь на операторів вузлів, що потребує покупки додаткового обладнання, такого як $300 NVME диск.

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

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

Для того, щоб зрозуміти, наскільки історичний зріст мережевої потужності типового вузла Ethereum може підтримувати, необхідно описати взаємозв'язок між історичним зростанням та різними метриками мережевого здоров'я, такими як швидкість реорганізації, пропущені слоти, відсутність остаточності, відсутність заяв, пропуски комітету синхронізації та затримки в пропозиції блоку. Аналіз цих метрик виходить за межі цієї статті, але може бути знайдений у попередніх дослідженнях здоров'я шару узгодження [1] [2] [3] 4]. Додатково, Фонд Ефіріуму @ethpandaops/xatu-overview">Проект Xatu вже створював загальнодоступні набори даних для полегшення таких аналізів.

Як вирішити історичний зріст?

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

На рисунку 6 показано, як EIP-4444 вплине на обсяг зберігання кожного вузла протягом наступних 3 років. Це таке саме, як на рисунку 4, з додаванням тонших ліній, що представляють обсяг зберігання після впровадження EIP-4444.

З цієї діаграми можна зробити кілька ключових висновків:

EIP-4444 зменшить поточне навантаження на зберігання: обсяг зберігання зменшиться з 1,2 TiB до 633 GiB.

EIP-4444 Зафіксує Історичне Обтяження Зберігання: Припускаючи постійний темп історичного зростання, історичні дані будуть видалятися з таким же темпом, з яким вони генеруються.

Після EIP-4444 на досягнення сьогоднішнього рівня навантаження на сховище пройде багато років: це тому, що зростання стану, яке повільніше, ніж історичний ріст, буде єдиним фактором, що збільшує навантаження на сховище.

EIP-4444 все ще накладе певне обмеження на обсяг зберігання через один рік історичних даних: однак це обтяження буде управляється навіть якщо Ethereum масштабується глобально. Як тільки метод обробки історичних даних виявиться надійним, період зберігання на один рік в EIP-4444 може бути скорочений до кількох місяців, тижнів або навіть менше.

Як зберегти історію Ethereum?

EIP-4444 ставить питання: якщо самі вузли Ethereum не зберігають історію, як це повинно бути збережено? Історія є ключовою для верифікації, обліку та аналізу Ethereum, тому вона повинна бути збережена. На щастя, збереження історії є простим, потрібно лише 1/n чесних постачальників даних, порівняно з проблемою консенсусу стану, для якої потрібно від 1/3 до 2/3 чесних учасників. Оператори вузлів можуть перевірити автентичність будь-якого історичного набору даних, повторивши всі транзакції з Genesis; та 2) перевірити, чи ці транзакції відтворюють той самий кореневий стан, що і поточний підказка ланцюга.

Існують кілька методів збереження історії, кожен з яких слід застосовувати паралельно для максимізації шансів на збереження:

Torrents / P2P: Торенти є найпростішим і надійним методом. Вузли Ethereum можуть періодично упаковувати частини історії та ділитися ними як загальнодоступними торрент-файлами. Наприклад, вузол може створювати новий торрент-файл історії кожні 100 000 блоків. Деякі клієнти вузлів, такі як Erigon, вже виконують цей процес нестандартизованим способом. Щоб стандартизувати цей процес, усі клієнти вузлів повинні використовувати однаковий формат даних, параметри та мережу P2P. Вузли можуть брати участь у цій мережі на основі їх сховища та пропускної здатності. Перевагою торрентів є використання зрілих відкритих стандартів, що підтримуються великою екосистемою інструментів обробки даних.

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

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

Залишкові виклики впровадження більше соціальні, ніж технічні. Спільноті Ethereum потрібно узгодити конкретні деталі реалізації, щоб їх можна було безпосередньо інтегрувати в кожен вузол клієнта. Наприклад, повна синхронізація з Genesis (замість синхронізації зі снапшоту) буде вимагати отримання історії від постачальників історичних даних, а не від вузлів Ethereum. Ці зміни не потребують жорсткого вілки і можуть бути реалізовані до наступної жорсткої вілки Ethereum, Pectra.

L2 також можуть використовувати всі ці методи для збереження даних блоба, які вони публікують на головну мережу. Збереження блоба є 1) складнішим через більший обсяг загальних даних; 2) менш критичним, оскільки блоби не потрібні для відтворення історії головної мережі. Однак збереження блоба необхідне для кожного L2 для відтворення власної історії. Тому яка-небудь форма збереження блоба є важливою для всього екосистеми Ethereum. Крім того, якщо L2 розвиватимуть міцну інфраструктуру зберігання блобів, вони також зможуть легко зберігати історичні дані L1.

Пряме порівняння наборів даних, збережених різними конфігураціями вузлів до та після EIP-4444, буде корисним. На рис. 7 показано обсяг зберігання типів вузлів Ethereum. Дані стану включають рахунки та контракти, історичні дані включають блоки та транзакції, архівні дані - це набір необов'язкових індексів. Кількість байтів у таблиці базується на останніх знімках reth, але ці цифри повинні бути приблизно порівнянні з іншими клієнтами вузлів.

Рисунок 7: Обсяг зберігання типів вузлів Ethereum

У мові,

1. Вузли архіву зберігають дані стану, історичні дані та архівні дані. Вони використовуються, коли потрібен простий запит історичного стану ланцюжка.
2. Повні вузли зберігають лише історичні дані та дані стану. Більшість вузлів сьогодні є повними вузлами. Обсяг сховища повних вузлів приблизно удвічі менший, ніж у архівних вузлів.
3. Після EIP-4444 повні вузли будуть зберігати лише дані стану та історичні дані останнього року. Це зменшить обсяг зберігання з 1,2 TiB до 633 GiB та стабілізує використання простору для історичних даних.
4. Бездержавні вузли, також відомі як «легкі вузли», не зберігають жодних з цих наборів даних і можуть миттєво перевіряти на віці ланцюга. Цей тип вузла стає можливим, як тільки Verkle спробуєабо інші схеми зобов'язань держави додаються до Ethereum.

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

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

EIP-4488: Ця пропозиція накладає обмеження на загальний обсяг даних виклику, який може бути включений в кожний блок, застосовуючи більш суворий контроль над темпами історичного зростання.

Ці EIP-и легше впровадити, ніж EIP-4444, і можуть служити як тимчасові заходи, поки EIP-4444 не буде готовий до впровадження виробництва.

Висновок

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

Історичний зріст як ділянка для масштабовності Ethereum не отримав достатньої уваги. Навіть без збільшення газових лімітів, поточна практика збереження історії на Ethereum потребуватиме, щоб багато вузлів оновили своє обладнання протягом кількох років. На щастя, це не особливо складна проблема для вирішення. Чіткі рішення були описані в EIP-4444. Ми вважаємо, що слід прискорити впровадження цього EIP, щоб забезпечити місце для майбутніх збільшень газових лімітів.

Якщо вас цікавить дослідження масштабованості Ethereum, будь ласка, зв'яжітьсяstorm@paradigm.xyz та georgios@paradigm.xyz.Ми хотіли б почути ваші перспективи з цього питання та дослідити потенційні співпраці. Дані та код, використані в цій статті, можуть бути знайдено наGithub.

Подяки

Велика подякаТомас Тірі、Команда Beiko、Тоні Варштаттер、Олівер НордбергіРоман Красюкдля їхнього огляду та відгуку. Дякуємо вамAchal Srinivasanдля цифр, наведених на рисунку 1 та рисунку 7.

Disclaimer：

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