Валідація доступності даних Bitcoin-native у середовищах L2 з наднизькою затримкою @megaeth , @risechain , @nubit_org У блокчейні вираз «ультра-низька затримка» або «реальний час» виходить за межі простого значення швидкості, що сприймається швидкість, а також стосується структури, в якій виконання, реакція та відображення стану послідовно забезпечуються на рівні, що перевищує межі людського сприйняття. Останнім часом високопродуктивні системи другого рівня розробляються з мілісекундними затримками виконання та дуже високою пропускною здатністю, і в цьому процесі стало поширеним розділення виконавчого та верифікаційного шарів. У такому середовище доступність даних не є фактором, який безпосередньо впливає на швидкість, а радше слугує основою, що дозволяє будь-кому перевірити переходи станів пізніше. Системи рівня 2 в реальному часі використовують техніки для попереднього виконання транзакцій перед повним включенням у блок або для завершення порядку шляхом поділу блоку на дуже малі одиниці. Це дозволяє користувачам бачити майже миттєві результати, але криптографічно повна верифікація відбувається значно пізніше. У такій структурі рівень доступності даних повинен забезпечити достатню кількість даних протягом певного періоду часу для перевірки, і у разі затримок або приховувань учасники системи не мають іншого вибору, окрім як довіряти цілісності секвенсора протягом цього періоду. Доступність нативних даних Bitcoin — це підхід, який прагне забезпечити цю функцію верифікації безпосередньо на блокчейні Bitcoin. Блоки біткоїна створюються в середньому приблизно за 10 хвилин, і обсяг даних, які можуть міститися в блоці, обмежений. Ця структура забезпечує високу економічну безпеку та сильний опір цензурі, але має чітку верхню межу за частотою публікації даних і пропускною здатністю. Відповідно, доступність даних на основі Bitcoin передбачає пропускну здатність у кілька кілобайт на секунду та мінімальну затримку визначення понад кілька хвилин. У реальному середовищі L2 затримка виконання становить лише кілька мілісекунд, а якщо доступність даних визначає більше кількох хвилин, часова проміжок між виконанням і валідацією значно збільшується. Під час цієї перерви користувачі не можуть самостійно підтвердити свій статус або безпечно відновити активи, а також не можуть одразу перевірити, чи дані дійсно були опубліковані. Це означає, що рівень доступності даних затримує ефективність початкового наміру мінімізації довіри на основі валідації на значний час. Системи, які реалізують доступність даних, нативних для Bitcoin, використовують допоміжні механізми, такі як консенсус комітетів, вибірка даних і періодичне якоріння біткоїна, щоб пом'якшити ці обмеження. Однак цей метод не забезпечує коротку затримку валідації, необхідну середовищу виконання в реальному часі, якщо тільки не змінює власну швидкість обробки та цикл генерації блоків Bitcoin. У разі приховування або затримки даних це не змінює того, що потрібно принаймні один блок часу, щоб остаточно оцінити і відреагувати на це в ланцюзі. Ця характеристика стає ще більш помітною у застосуваннях із надзвичайною чутливістю до затримки, таких як високочастотні транзакції або ігри в реальному часі. У середньому середовищі, де велика кількість транзакцій відбувається за короткий проміжок часу, простір блоків Bitcoin не може задовольнити попит на доступність даних, а затримки валідації також ускладнюють нормальну роботу додатку. З іншого боку, у застосунках, де частота транзакцій відносно низька, а безпека остаточного розрахунку є важливішою, доступність даних на основі біткоїна може відігравати певну роль. Підсумовуючи, у середовищах L2 з наднизькою затримкою доступність даних, нативних для біткоїна, має структурні обмеження, такі як затримки валідації та обмеження пропускної здатності. Хоча Bitcoin забезпечує високу безпеку та надійність, його конструкція робить його непридатним для використання як шару доступності даних на основі виконання в реальному часі. Об'єктивний аналіз на даний момент підтверджує, що доступність даних, нативних на базі біткоїна, у системах рівня рівня реального часу виконує функції повільної, але високобезпечної допоміжної точки відліку, а не основного засобу верифікації для підтримки виконання.