PeerDAS
Протокол Ethereum проходить найзначніше оновлення масштабування з моменту впровадження blob-транзакцій за допомогою EIP-4844. У рамках оновлення Fusaka, PeerDAS впроваджує новий спосіб обробки blob-даних, забезпечуючи збільшення ємності для L2 приблизно на порядок у доступності даних (DA).
Докладніше про план розвитку масштабування blob-даних (opens in a new tab)
Масштабованість
Бачення Ethereum полягає в тому, щоб бути нейтральною, безпечною та децентралізованою платформою, доступною для всіх у світі. Зі зростанням використання мережі це вимагає збалансування трилеми масштабування, безпеки та децентралізації мережі. Якби Ethereum просто збільшив обсяг даних, що обробляються мережею в рамках поточної архітектури, це створило б ризик перевантаження вузлів, на які Ethereum покладається для своєї децентралізації. Масштабованість вимагає ретельної розробки механізму, який мінімізує компроміси.
Однією зі стратегій для досягнення цієї мети є створення різноманітної екосистеми рішень для масштабування другого рівня замість обробки всіх транзакцій у головній мережі . або зведення обробляють транзакції у власних окремих ланцюжках і використовують Ethereum для верифікації та безпеки. Публікація лише критично важливих для безпеки зобов'язань та стиснення корисного навантаження дозволяє L2 ефективніше використовувати ємність DA Ethereum. Своєю чергою, L1 переносить менше даних, не поступаючись гарантіями безпеки, а L2 залучають більше користувачів за меншу вартість газу. Спочатку L2 публікували дані як calldata у звичайних транзакціях, що конкурували з транзакціями L1 за газ і було непрактичним для забезпечення доступності великих обсягів даних.
Proto-Danksharding
Першим великим кроком до масштабування L2 стало оновлення Dencun, яке запровадило Proto-Danksharding (EIP-4844). Це оновлення створило новий спеціалізований тип даних для зведень під назвою blob. Blob-об'єкти, або бінарні великі об'єкти, є ефемерними фрагментами довільних даних, які не потребують виконання в EVM, і які вузли зберігають лише протягом обмеженого часу. Ця ефективніша обробка дозволила L2 публікувати більше даних в Ethereum і масштабуватися ще більше.
Попри значні переваги для масштабування, використання blob-об'єктів є лише частиною кінцевої мети. У поточному протоколі кожен вузол у мережі все ще повинен завантажувати кожен blob-об'єкт. Вузьким місцем стає пропускна здатність, яка вимагається від окремих вузлів, оскільки обсяг даних, які необхідно завантажити, прямо пропорційно зростає зі збільшенням кількості blob-об'єктів.
Ethereum не йде на компроміси щодо децентралізації, а пропускна здатність є одним з найбільш чутливих параметрів. Навіть за наявності потужних обчислювальних ресурсів, доступних кожному, хто може їх собі дозволити, обмеження пропускної здатності висхідного каналу (opens in a new tab) навіть у великих містах розвинених країн (таких як Німеччина (opens in a new tab), Бельгія (opens in a new tab), Австралія (opens in a new tab) або Сполучені Штати (opens in a new tab)) можуть обмежити можливість запуску вузлів лише з дата-центрів, якщо вимоги до пропускної здатності не будуть ретельно налаштовані.
Оператори вузлів стикаються з дедалі вищими вимогами до пропускної здатності та дискового простору зі збільшенням кількості blob-об'єктів. Розмір і кількість blob-об'єктів обмежені цими факторами. Кожен blob-об'єкт може містити до 128 КБ даних, і в середньому на блок припадає 6 blob-об'єктів. Це був лише перший крок до майбутньої архітектури, яка використовує blob-об'єкти ще ефективніше.
Вибірка доступності даних
Доступність даних — це гарантія того, що всі дані, необхідні для незалежної валідації ланцюжка, доступні всім учасникам мережі. Це гарантує, що дані були повністю опубліковані і можуть бути використані для довірчої верифікації нового стану ланцюжка або вхідних транзакцій.
Blob-об'єкти Ethereum забезпечують надійну гарантію доступності даних, що гарантує безпеку L2. Для цього вузли Ethereum повинні завантажувати та зберігати blob-об'єкти повністю. Але що, якби ми могли розподіляти blob-об'єкти в мережі ефективніше і уникнути цього обмеження?
Іншим підходом до зберігання даних та забезпечення їх доступності є вибірка доступності даних (DAS). Замість того, щоб кожен комп’ютер, на якому запущено Ethereum, повністю зберігав кожен blob-об'єкт, DAS впроваджує децентралізований розподіл праці. Це зменшує навантаження з обробки даних шляхом розподілу менших, керованих завдань по всій мережі вузлів. Blob-об'єкти діляться на частини, і кожен вузол завантажує лише кілька частин, використовуючи механізм для рівномірного випадкового розподілу між усіма вузлами.
Це створює нову проблему — доведення доступності та цілісності даних. Як мережа може гарантувати, що дані доступні та повністю коректні, коли окремі вузли зберігають лише невеликі фрагменти? Зловмисний вузол може надавати підроблені дані і легко порушити надійні гарантії доступності даних! Тут на допомогу приходить криптографія.
Щоб забезпечити цілісність даних, у EIP-4844 вже були реалізовані KZG-зобов'язання. Це криптографічні докази, які створюються, коли новий blob-об'єкт додається до мережі. Невеликий доказ включається в кожен блок, і вузли можуть перевірити, чи отримані blob-об'єкти відповідають KZG-зобов'язанню блоку.
DAS — це механізм, який будується на основі цього і гарантує, що дані є одночасно коректними та доступними. Вибірка — це процес, під час якого вузол запитує лише невелику частину даних і перевіряє її на відповідність зобов’язанню. KZG — це схема поліноміальних зобов’язань, що означає, що будь-яка окрема точка на поліноміальній кривій може бути перевірена. Перевіряючи лише кілька точок на поліномі, клієнт, що виконує вибірку, може отримати надійну ймовірнісну гарантію, що дані доступні.
PeerDAS
PeerDAS (EIP-7594) (opens in a new tab) — це конкретна пропозиція, яка реалізує механізм DAS в Ethereum і є, ймовірно, найбільшим оновленням з часів The Merge. PeerDAS призначений для розширення blob-даних, розділяючи їх на стовпці та розподіляючи підмножину між вузлами.
Для цього Ethereum запозичує деякі розумні математичні методи: він застосовує до blob-даних кодування зі стиранням у стилі Ріда-Соломона. Blob-дані представлені у вигляді полінома, коефіцієнти якого кодують дані, потім цей поліном обчислюється в додаткових точках для створення розширеного blob-об'єкта, подвоюючи кількість обчислень. Ця додана надлишковість дозволяє відновлювати дані після стирання: навіть якщо деякі обчислення відсутні, вихідний blob-об'єкт можна відновити, за умови, що доступна принаймні половина всіх даних, включаючи розширені частини.
Насправді, цей поліном має тисячі коефіцієнтів. KZG-зобов'язання — це значення розміром у кілька байтів, схожі на хеш, відомі всім вузлам. Кожен вузол, що зберігає достатню кількість точок даних, може ефективно відновити повний набір blob-даних (opens in a new tab).
Цікавий факт: такий самий метод кодування використовувався в DVD. Якщо ви подряпали DVD, програвач все одно міг його прочитати завдяки кодуванню Ріда-Соломона, яке додає відсутні частини полінома.
Історично дані в блокчейнах, чи то блоки, чи то blob-об'єкти, транслювалися всім вузлам. Завдяки підходу PeerDAS, що полягає в розділенні та вибірці, трансляція всього всім більше не потрібна. Після оновлення Fusaka мережева взаємодія на рівні консенсусу організована у вигляді тем/підмереж для пліток (gossip): стовпці blob-об'єктів призначаються конкретним підмережам, і кожен вузол підписується на заздалегідь визначені підмножини і зберігає лише ці частини.
У PeerDAS розширені blob-дані діляться на 128 частин, що називаються стовпцями. Дані розподіляються між цими вузлами через спеціальний gossip-протокол у конкретних підмережах, на які вони підписані. Кожен звичайний вузол у мережі бере участь у щонайменше 8 випадково обраних підмережах стовпців. Отримання даних лише з 8 зі 128 підмереж означає, що цей стандартний вузол отримує лише 1/16 всіх даних, але оскільки дані були розширені, це становить 1/8 вихідних даних.
Це дозволяє досягти нового теоретичного ліміту масштабування, що у 8 разів перевищує поточну схему «кожен завантажує все». Коли вузли підписуються на різні випадкові підмережі, що обслуговують стовпці blob-об'єктів, імовірність їх рівномірного розподілу дуже висока, і, отже, кожна частина даних існує десь у мережі. Вузли, що запускають валідаторів, повинні підписуватися на більшу кількість підмереж з кожним запущеним валідатором.
Кожен вузол має унікальний випадково згенерований ID, який зазвичай слугує його публічним ідентифікатором для з'єднань. У PeerDAS цей номер використовується для визначення випадкового набору підмереж, на які він повинен підписатися, що призводить до рівномірного випадкового розподілу всіх blob-даних.
Після того, як вузол успішно відновить вихідні дані, він повторно поширює відновлені стовпці назад у мережу, активно заповнюючи прогалини в даних і підвищуючи загальну стійкість системи. Вузли, підключені до валідаторів із сукупним балансом ≥4096 ETH, повинні бути супервузлами і, отже, повинні підписатися на всі підмережі стовпців даних і зберігати всі стовпці. Ці супервузли будуть постійно заповнювати прогалини в даних. Імовірнісна природа самовідновлення протоколу дозволяє забезпечити надійні гарантії доступності, не обмежуючи домашніх операторів, які зберігають лише частини даних.
Доступність даних може бути підтверджена будь-яким вузлом, що зберігає лише невелику підмножину blob-даних, завдяки описаному вище механізму вибірки. Ця доступність забезпечується примусово: валідатори повинні дотримуватися нових правил вибору форку, що означає, що вони прийматимуть і голосуватимуть за блоки лише після того, як перевірять доступність даних.
Прямий вплив на користувачів (особливо на користувачів L2) полягає в зниженні комісій. З 8-кратним збільшенням простору для даних зведень операції користувачів у їхньому ланцюжку з часом стають ще дешевшими. Але зниження комісій після оновлення Fusaka потребуватиме часу і залежатиме від BPO.
Форки лише з параметрами blob-об'єктів (BPO)
Теоретично мережа зможе обробляти у 8 разів більше blob-об'єктів, але збільшення їх кількості — це зміна, яка потребує належного тестування і безпечного поетапного впровадження. Тестові мережі дають достатньо впевненості для розгортання функцій у головній мережі, але нам потрібно забезпечити стабільність P2P-мережі, перш ніж вмикати значно більшу кількість blob-об'єктів.
Щоб поступово збільшувати цільову кількість blob-об'єктів на блок, не перевантажуючи мережу, оновлення Fusaka впроваджує форки лише з параметрами blob-об'єктів (BPO) (opens in a new tab). На відміну від звичайних форків, які потребують широкої координації екосистеми, згоди та оновлення програмного забезпечення, BPO (EIP-7892) (opens in a new tab) — це попередньо запрограмовані оновлення, які з часом збільшують максимальну кількість blob-об'єктів без втручання.
Це означає, що одразу після активації Fusaka та запуску PeerDAS кількість blob-об'єктів залишиться незмінною. Кількість blob-об'єктів почне подвоюватися кожні кілька тижнів, доки не досягне максимуму в 48, у той час як розробники будуть стежити за тим, щоб механізм працював належним чином і не чинив негативного впливу на вузли, що працюють у мережі.
Майбутні напрямки
PeerDAS — це лише крок до більш масштабного бачення масштабування FullDAS (opens in a new tab), або Danksharding. У той час як PeerDAS використовує 1D-кодування зі стиранням для кожного blob-об'єкта окремо, повний Danksharding використовуватиме більш досконалу 2D-схему кодування зі стиранням для всієї матриці blob-даних. Розширення даних у двох вимірах створює ще сильніші властивості надлишковості та більш ефективне відновлення і верифікацію. Реалізація FullDAS вимагатиме значних оптимізацій мережі та протоколу, а також додаткових досліджень.
Додаткові матеріали
- PeerDAS: вибірка доступності даних між вузлами від Francesco D'Amato (opens in a new tab)
- Документація щодо PeerDAS в Ethereum (opens in a new tab)
- Доведення безпеки PeerDAS без AGM (opens in a new tab)
- Віталік про PeerDAS, його вплив і тестування Fusaka (opens in a new tab)
Останні оновлення сторінки: 23 лютого 2026 р.
