Перейти до основного вмісту

Сторінку востаннє оновлено: 16 лютого 2026 р.

Данкшардинг

Данкшардинг — це спосіб, завдяки якому Ethereum стане справді масштабованим блокчейном, але для цього потрібно кілька оновлень протоколу. Протоданкшардинг — це проміжний крок на цьому шляху. Мета обох — зробити транзакції на Шарі 2 якомога дешевшими для користувачів і масштабувати Ethereum до >100 000 транзакцій на секунду.

Що таке протоданкшардинг?

Протоданкшардинг, також відомий як EIP-4844 (opens in a new tab), — це спосіб для зведень додавати дешевші дані до блоків. Назва походить від імен двох дослідників, які запропонували ідею: Protolambda та Данкрад Файст. Історично зведення були обмежені в тому, наскільки дешево вони можуть зробити транзакції для користувачів, через те, що вони публікують свої транзакції в CALLDATA.

Це дорого, тому що ці дані обробляються всіма вузлами Ethereum і залишаються в ланцюжку назавжди, хоча зведенням дані потрібні лише на короткий час. Протоданкшардинг впроваджує blob-об’єкти, які можна надсилати та прикріплювати до блоків. Дані в цих blob-об’єктах недоступні для EVM і автоматично видаляються через певний проміжок часу (на момент написання статті — 4096 епох, або приблизно 18 днів). Це означає, що зведення можуть надсилати свої дані набагато дешевше, що дає змогу здешевити транзакції для кінцевих користувачів.

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

Зведення публікують комітменти до даних своїх транзакцій у ланцюжку, а також роблять фактичні дані доступними у блобах даних. Це означає, що суб’єкти можуть перевіряти зафіксовані значення і оскаржувати недійсні дані. На рівні вузла blob-об’єкти зберігаються в клієнті консенсусу. Клієнти консенсусу підтверджують перевірку даних і їх розповсюдження по всій мережі. Якби дані зберігалися вічно, це призвело б до надмірного збільшення розміру цих клієнтів і великих вимог до обладнання для запуску вузлів. Замість цього дані автоматично видаляються з вузла кожні 18 днів. Атестації клієнта консенсусу показують, що було достатньо можливостей для перевірки даних. Фактичні дані можуть зберігатися поза ланцюжком операторами зведень, користувачами або іншими особами.

Як перевіряються дані blob-об’єктів? Як можна конвертувати Eth після хардфорку?

Зведення розміщують транзакції, які вони виконують, у blob-об’єктах. Також вони розміщують зафіксовані значення в даних. Вони роблять це, апроксимуючи дані поліноміальною функцією. Потім цю функцію можна обчислювати в різних точках. Наприклад, якщо ми визначимо надзвичайно просту функцію f(x) = 2x-1, то зможемо обчислити цю функцію для x = 1, x = 2, x = 3, що дасть результати 1, 3, 5. Суб’єкт застосовує ту саму функцію до даних і обчислює її в тих самих точках. Якщо вихідні дані буде змінено, функція вже не буде ідентичною, а отже значення, обчислені в кожній точці, також відрізнятимуться. На практиці фіксація і доведення складніші, оскільки їх загорнуто в криптографічні функції.

Що таке KZG?

KZG розшифровується як Кейт-Заверуха-Гольдберг — імена трьох авторів-оригінаторів (opens in a new tab) схеми, яка зводить блоб даних до невеликого криптографічного "комітменту" (opens in a new tab). Blob-об’єкт, що надсилає зведення, необхідно перевіряти, щоб переконатися, що зведення працює коректно. Це передбачає повторне виконання транзакцій у blob-об’єкті для перевірки дійсності зафіксованого значення. У принципі це аналогічно перевірці дійсності транзакцій Ethereum, яку клієнти виконання виконують на рівні 1, використовуючи докази Меркла. KZG є альтернативним доказом, який підбирає поліноміальне рівняння до даних. Фіксація обчислює поліном у деяких секретних точках даних. Суб’єкт підбирає апроксимує дані тим самим поліномом і обчислює його для тих самих значень, перевіряючи, чи збігається результат. Це спосіб перевірки даних, сумісний із методами доведення з нульовим розголошенням, який використовують деякі зведення і зрештою інші частини протоколу Ethereum.

Що таке церемонія KZG?

Під час церемонії KZG багато людей зі спільноти Ethereum колективно згенерували секретний випадковий рядок чисел, який можна використовувати для перевірки деяких даних. Дуже важливо, щоб цей ряд чисел ніхто не знав і не міг відтворити. Для цього кожна особа, яка брала участь у церемонії, отримувала рядок від попереднього учасника. Потім вони створювали кілька нових випадкових значень (наприклад, дозволяючи своєму браузеру вимірювати рух миші) та змішували їх із попереднім значенням. Потім вона надсилала значення наступному учаснику й видаляла його зі свого локального комп’ютера. Якщо хоч би один з учасників церемонії зробив це чесно, зловмисник не знатиме кінцевого значення.

Церемонія KZG EIP-4844 була відкритою для всіх, і десятки тисяч людей взяли участь у ній, щоб додати власну ентропію (випадковість). Загалом було надіслано понад 140 000 внесків, що зробило це найбільшою у світі церемонією такого роду. Щоб зірвати церемонію, 100% учасників мали бути активно нечесними. З погляду учасників, якщо вони знають, що були чесними, немає потреби нікому довіряти, оскільки вони знають, що захистили церемонію (виконали вимогу "1 із N чесних учасників").

Коли зведення публікує дані в блобі, воно надає "комітмент", який публікує в ланцюжку. Це зафіксоване значення є результатом обчислення поліноміальної апроксимації даних у певних точках. Ці точки визначаються випадковими числами, згенерованими під час церемонії KZG. Після цього суб’єкти можуть обчислити поліном у тих самих точках, щоб перевірити дані — якщо вони отримають однакові значення, значить, дані вірні.

Якщо хтось знає випадкові місця, які використовувалися для комітменту, він може легко згенерувати новий поліном, що апроксимує ці конкретні точки (тобто "колізія"). Це означає, що він може додати або видалити дані з blob-об’єкта й все одно надати дійсний доказ. Щоб запобігти цьому, замість того, щоб повідомляти суб’єктам справжні секретні місця, вони фактично отримують ці місця, загорнуті в криптографічний "чорний ящик" за допомогою еліптичних кривих. Вони ефективно шифрують вихідні значення так, що їх неможливо реконструювати, але за допомогою деяких алгебраїчних операцій суб’єкти однаково можуть обчислити поліноми в тих точках, які вони представляють.

Що таке данкшардинг?

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

Це відбувається шляхом збільшення кількості blob-об’єктів, прикріплених до блоків, з шести (6) у протоданкшардингу до 64 у повному данкшардінгу. Решта необхідних змін — це оновлення роботи клієнтів консенсусу, щоб вони могли обробляти нові великі blob-об’єкти. Деякі із цих змін уже включено до плану розвитку для інших цілей, незалежних від данкшардингу. Наприклад, данкшардінг вимагає, щоб уже було впроваджено розділення вузлів створення і пропонування блоків. Це оновлення розділяє завдання створення і пропонування блоків між різними валідаторами. Так само, вибіркова перевірка доступності даних необхідна для данкшардингу, але вона також необхідна для розробки дуже легких клієнтів, які не зберігають багато даних за попередні періоди ("клієнти без збереження стану").

Розділення вузлів створення і пропонування блоків необхідне для того, щоб окремим валідаторам не доводилося створювати дорогі зафіксовані значення і докази для 32 МБ blob-даних. Це надмірно ускладнить життя стейкерів, які використовують домашні ресурси, і вимагатиме від них інвестицій у потужніше обладнання, що завдасть шкоди децентралізації. Натомість відповідальність за цю дорогу обчислювальну роботу беруть на себе вузли створення. Потім настає черга вузлів пропонування. Вони просто обирають найприбутковіші блоки. Будь-хто може перевірити blob-об’єкти дешево та швидко, що означає, що будь-який звичайний валідатор може перевірити чесність вузлів створення. Це дозволяє обробляти великі blob-об’єкти без шкоди для децентралізації. Нечесних можна просто виключити з мережі, інші візьмуть їхнє місце, оскільки створення блоків є прибутковою діяльністю.

Вибіркова перевірка доступності даних необхідна для валідаторів, щоб швидко та ефективно перевіряти blob-дані. Використовуючи вибіркову перевірку доступності даних, валідатори можуть переконатися, що blob-дані доступні й правильно зафіксовані. Кожен валідатор може випадково перевірити кілька точок даних і створити доказ, що означає, що жоден валідатор не має перевіряти весь blob-об’єкт. Якщо будь-яких даних не вистачатиме, це буде швидко виявлено, і blob-об’єкт буде відхилено.

Поточний прогрес

Повне впровадження данкшардингу відбудеться через кілька років. Тим часом церемонія KZG завершилася, зібравши понад 140 000 внесків, а EIP (opens in a new tab) для Протоданкшардингу досяг зрілості. Цю пропозицію було повністю впроваджено в усіх тестових мережах, а в березні 2024 року з оновленням Cancun-Deneb ("Dencun") було запущено в основній мережі.

Для подальшого читання

Останнє оновлення сторінки: 16 лютого 2026 р.

pete-vielhaberp (opens in a new tab)
JoeChenJJ (opens in a new tab)
bskrksyp9b (opens in a new tab)
+10

Ця стаття була корисною?