Бутерін обіцяє, що механізм PeerDAS зробить L2 швидшим

Фото - Бутерін обіцяє, що механізм PeerDAS зробить L2 швидшим
Віталік Бутерін вважає, що схема PeerDAS є ключем для масштабування екосистеми Ethereum і її реалізація у оновленні Fusaka збільшить пропускну здатність L2 у кілька разів.
PeerDAS – це механізм на рівні протоколу Ethereum, оформлений як специфікація EIP. Простіше кажучи, це нове правило роботи мережі, за яким вузли можуть перевірити доступність даних з blob'ів, не завантажуючи їх повністю.

Як пояснив Бутерін, ця схема робить перевірку «по шматочках»: вузол запитує обмежену кількість рандомних фрагментів і з високою часткою ймовірності переконується, що більше половини блоку дійсно валідна. Якщо доступність підтверджена, відсутні частини відновлюють за допомогою кодування, без необхідності зберігати у себе всю історію мережі.
Приводом для обговорення стала статистика, на яку звернув увагу Хільдеберт Мульє з Dragon XYZ. Він опублікував дані, з яких видно, що мережа вперше з моменту запуску стійко вийшла на цільовий показник шість blob'ів у блоці. Саме blob'и (окремі контейнери для даних L2) знижують витрати для роллапів.

У моменти пікових навантажень найбільше простору займала мережа Base (близько 42%), далі йшли World (~25%), Arbitrum (~8%) і OP Mainnet (~4%); внесок Scroll і Soneium оцінювався приблизно по 3% кожна.
При цьому в інфраструктури залишаються обмеження. За підрахунками Мульє, валідатору сьогодні потрібно понад 70 ГБ на неупаковані blob'и, а без обрізки старих даних обсяг може перевалювати за 1,2 ТБ. Близько 10% контейнерів публікуються недозаповненими (особливо у невеликих мереж), а приблизно третина блоків з blob'ами зачіпається MEV-активністю.

Відповіддю на ці виклики стане апгрейд Fusaka, намічений на 3 грудня у головній мережі Ethereum. Він запустить механізм PeerDAS, після чого максимальна місткість по blob'ам зросте з поточних 6 до 9, а потім у два етапи буде підвищуватися далі: спочатку до 15, потім до 21.

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

Для користувачів це означає потенційно дешевші та більш передбачувані комісії на L2, а для розробників – поетапне зростання лімітів без різких перевантажень мережі.