! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
У міру того, як користувачі починають інтегрувати Avail у свої конструкції ланцюгів, часто виникає питання: «Скільки транзакцій може обробити Avail?». У цій публікації ми порівняємо пропускну здатність Ethereum і Avail на основі поточної архітектури двох ланцюгів.
Це перший із серії статей про масштабованість Avail, в якому обговорюватимуться поточні показники Avail та його здатність масштабуватися в найближчій та довгостроковій перспективі.
Avail проти Ethereum
Блоки Ethereum можуть містити до 1,875 МБ даних і мають час блокування близько 13 секунд. Однак блоки Ethereum зазвичай не заповнюються. Майже кожен блок не досягне верхньої межі даних, тому що він досягає ліміту газу, тому що і виконання, і розрахунок споживають газ. В результаті обсяг даних, що зберігаються в кожному блоці, є змінним.
Необхідність об'єднати виконання, розрахунки та доступність даних в одному блоці є центральною проблемою єдиної архітектури блокчейну. L2-ролапи запустили рух до модульних блокчейнів, дозволяючи обробляти операції виконання в одному ланцюжку, а блоки ланцюга призначені для виконання. Avail робить крок далі, застосовуючи модульну структуру, яка також відокремлює доступність даних, дозволяючи блокам ланцюжка виділятися для доступності даних.
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Наразі час блокування Avil становить 20 секунд, і кожен блок може містити близько 2 МБ даних. Припускаючи, що середній розмір транзакції становить 250 байт, кожен блок Avail сьогодні може містити близько 8 400 транзакцій (420 транзакцій в секунду).
Більше того, Avail завжди може заповнювати блоки до ліміту пам'яті та збільшувати розмір за потреби. У нас є ряд важелів, які можна швидко налаштувати, щоб збільшити кількість транзакцій на блок до більш ніж 500 000 (25 000 транзакцій в секунду), коли це необхідно.
Чи можемо ми збільшити пропускну здатність?
Для того, щоб збільшити пропускну здатність (особливо кількість транзакцій в секунду), архітекторам мережі необхідно збільшити розмір блоку або зменшити час блоку.
Щоб бути доданим до ланцюжка, кожен блок повинен генерувати зобов'язання, створювати докази, розповсюджувати їх і змушувати всі інші вузли перевіряти ці докази. Ці кроки завжди займають час, який встановлює природну верхню межу часу, необхідного для генерації та підтвердження блоків.
Тому ми не можемо просто скоротити час блокування, скажімо, до однієї секунди. У нього просто не вистачає часу, щоб генерувати зобов'язання, генерувати докази та поширювати ці частини серед усіх учасників мережі. У теоретичному часі блоку в одну секунду, навіть якщо кожен учасник мережі запускає найпотужнішу машину, здатну миттєво видавати зобов'язання та докази, вузьке місце полягає в поширенні даних. Через обмеження швидкості інтернету мережа не в змозі сповіщати всі повні вузли про блокування досить швидко. Тому ми повинні переконатися, що час блокування достатньо високий, щоб дозволити розподілити дані в мережі після досягнення консенсусу.
І навпаки, також можна збільшити пропускну здатність, збільшивши розмір блоку, тобто збільшивши обсяг даних, які ми можемо містити в кожному блоці.
Поточна архітектура: Додайте блок до ланцюжка
Для початку розглянемо кроки, необхідні для додавання блоку в ланцюжок. Є три основні кроки, необхідні для додавання кожного блоку в ланцюжок. Це включає час, необхідний для генерації блоку, його поширення та перевірки.
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Генерація блоків
Цей крок включає час, необхідний для збору та сортування транзакцій Avail, створення зобов'язань і масштабування (стирання коду) матриці даних.
Генерація блоку вимірює час, необхідний для генерації блоку, оскільки це завжди займе принаймні деякий час. Тому треба враховувати не тільки час в кращому випадку, але і середню ситуацію і час в гіршому випадку на різних машинах.
Найслабша машина, яка може брати участь у генерації нових блоків, - це та, яка в середньому досягає межі продуктивності. Всі повільніші машини врешті-решт відстануть, тому що вони не зможуть наздогнати швидші машини.
2. Затримка розмноження
Затримка поширення — це міра часу, необхідного для поширення блоку від виробника до валідатора та однорангової мережі.
Наразі розмір блоку Avail становить 2 МБ. Протягом поточного 20-секундного ліміту часу блоку такий розмір блоку може бути поширений. Більші розміри блоків ускладнюють поширення.
Наприклад, якщо ми збільшимо Avail до підтримки блоку розміром 128 МБ, обчислення можна масштабувати (близько 7 секунд). Однак вузьким місцем стає час, необхідний для надсилання та завантаження цих блоків у мережі.
Відправка блоку розміром 128 МБ на земну кулю через однорангову мережу за 5 секунд може бути межею досяжного на даний момент.
Обмеження в 128 МБ не має нічого спільного з доступністю даних або нашим сценарієм зобов'язань, а скоріше з обмеженням пропускної здатності зв'язку.
Ця необхідність враховувати затримку поширення дає нам поточне теоретичне обмеження розміру блоку Avail.
3. Валідація блоків
Після розповсюдження валідатори-учасники не просто довіряють блокам, наданим їм ініціатором блоку — їм потрібно перевірити, чи створений блок дійсно містить дані, заявлені виробником.
Між цими трьома кроками є певна напруга. Ми можемо зробити всі валідатори потужними машинами та тісно пов'язаними чудовою мережею в одному дата-центрі – це скоротить час виробництва та валідації, а також дозволить нам поширювати набагато більше даних. Однак, оскільки ми також хочемо мати децентралізовану, різноманітну мережу з різними типами учасників, це не ідеальний підхід.
Натомість збільшення пропускної здатності буде досягнуто за рахунок розуміння кроків, необхідних для додавання блоків до ланцюжка Avail, і які кроки можна оптимізувати.
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
В даний час валідатори, які використовують Avail, беруть весь блок і копіюють всі зобов'язання, згенеровані ініціатором для перевірки блоку. Це означає, що виробники блоків і всі валідатори повинні виконати кожен з кроків на діаграмі вище.
В одному блокчейні за замовчуванням кожен валідатор реконструює весь блок. Однак у такому ланцюжку, як Avail, де транзакції не виконуються, ця перебудова не потрібна. Таким чином, один із способів оптимізації Avail полягає в тому, щоб дозволити валідаторам досягати власних гарантій доступності даних за допомогою вибірки, а не шляхом реконструкції блоків. Це менш ресурсозатратно для валідаторів, ніж вимагати від них повторення всіх зобов'язань. Детальніше про це в наступній статті.
Як працює вибірка доступності дослідницьких даних?
В Avail легкі клієнти використовують три основні інструменти для підтвердження доступності даних: зразки, зобов'язання та докази.
Наразі легкі клієнти виконують операції вибірки, які запитують значення певної комірки та пов'язаний з нею доказ валідності з мережі Avail. Чим більше зразків вони візьмуть, тим більше вони впевнені в тому, що всі дані доступні.
Зобов'язання генеруються ініціаторами блоків і узагальнюють цілий ряд даних у блоці Avail. (Підказка: це крок, який ми оптимізуємо пізніше в цій серії.) ）
Кожна комірка в мережі генерує доказ. Легкі клієнти використовують атестації та обіцянки перевірити правильність наданих їм значень осередків.
Використовуючи ці інструменти, легкий клієнт виконує три кроки.
Рішення: Необхідна впевненість у доступності визначає кількість зразків для легкого виконання клієнта. Їм не потрібно багато зразків (8-30 зразків), щоб досягти гарантії доступності понад 99,95%.
Завантаження: Потім легкий клієнт запитує ці зразки та пов'язані з ними докази та завантажує їх із мережі (повного вузла або іншого легкого клієнта).
Перевірка: Вони дивляться на проміс у заголовку блоку (який завжди доступний для легких клієнтів) і перевіряють доказ кожної комірки з промісом.
Тільки завдяки цьому легкі клієнти можуть підтвердити доступність усіх даних у блоці без необхідності завантажувати більшу частину вмісту блоку. Інші кроки, вжиті легкими клієнтами, також сприяють безпеці Avail, але не перераховані тут. Наприклад, легкі клієнти можуть ділитися зразками та коректурами, які вони завантажують, з іншими легкими клієнтами, якщо їм це потрібно. Але це процедура для легких клієнтів, щоб підтвердити доступність даних!
У другій частині цієї серії ми розглянемо способи збільшення пропускної здатності Avail у короткостроковій перспективі. Ми пояснимо, чому ми вважаємо, що Avail може задовольнити потреби будь-якої мережі в наступному році, і як ми можемо вдосконалити мережу, щоб відповідати викликам наступних років.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Масштабованість DA: поточний стан Avail
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
У міру того, як користувачі починають інтегрувати Avail у свої конструкції ланцюгів, часто виникає питання: «Скільки транзакцій може обробити Avail?». У цій публікації ми порівняємо пропускну здатність Ethereum і Avail на основі поточної архітектури двох ланцюгів.
Це перший із серії статей про масштабованість Avail, в якому обговорюватимуться поточні показники Avail та його здатність масштабуватися в найближчій та довгостроковій перспективі.
Avail проти Ethereum
Блоки Ethereum можуть містити до 1,875 МБ даних і мають час блокування близько 13 секунд. Однак блоки Ethereum зазвичай не заповнюються. Майже кожен блок не досягне верхньої межі даних, тому що він досягає ліміту газу, тому що і виконання, і розрахунок споживають газ. В результаті обсяг даних, що зберігаються в кожному блоці, є змінним.
Необхідність об'єднати виконання, розрахунки та доступність даних в одному блоці є центральною проблемою єдиної архітектури блокчейну. L2-ролапи запустили рух до модульних блокчейнів, дозволяючи обробляти операції виконання в одному ланцюжку, а блоки ланцюга призначені для виконання. Avail робить крок далі, застосовуючи модульну структуру, яка також відокремлює доступність даних, дозволяючи блокам ланцюжка виділятися для доступності даних.
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Наразі час блокування Avil становить 20 секунд, і кожен блок може містити близько 2 МБ даних. Припускаючи, що середній розмір транзакції становить 250 байт, кожен блок Avail сьогодні може містити близько 8 400 транзакцій (420 транзакцій в секунду).
Більше того, Avail завжди може заповнювати блоки до ліміту пам'яті та збільшувати розмір за потреби. У нас є ряд важелів, які можна швидко налаштувати, щоб збільшити кількість транзакцій на блок до більш ніж 500 000 (25 000 транзакцій в секунду), коли це необхідно.
Чи можемо ми збільшити пропускну здатність?
Для того, щоб збільшити пропускну здатність (особливо кількість транзакцій в секунду), архітекторам мережі необхідно збільшити розмір блоку або зменшити час блоку.
Щоб бути доданим до ланцюжка, кожен блок повинен генерувати зобов'язання, створювати докази, розповсюджувати їх і змушувати всі інші вузли перевіряти ці докази. Ці кроки завжди займають час, який встановлює природну верхню межу часу, необхідного для генерації та підтвердження блоків.
Тому ми не можемо просто скоротити час блокування, скажімо, до однієї секунди. У нього просто не вистачає часу, щоб генерувати зобов'язання, генерувати докази та поширювати ці частини серед усіх учасників мережі. У теоретичному часі блоку в одну секунду, навіть якщо кожен учасник мережі запускає найпотужнішу машину, здатну миттєво видавати зобов'язання та докази, вузьке місце полягає в поширенні даних. Через обмеження швидкості інтернету мережа не в змозі сповіщати всі повні вузли про блокування досить швидко. Тому ми повинні переконатися, що час блокування достатньо високий, щоб дозволити розподілити дані в мережі після досягнення консенсусу.
І навпаки, також можна збільшити пропускну здатність, збільшивши розмір блоку, тобто збільшивши обсяг даних, які ми можемо містити в кожному блоці.
Поточна архітектура: Додайте блок до ланцюжка
Для початку розглянемо кроки, необхідні для додавання блоку в ланцюжок. Є три основні кроки, необхідні для додавання кожного блоку в ланцюжок. Це включає час, необхідний для генерації блоку, його поширення та перевірки.
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Генерація блоків
Цей крок включає час, необхідний для збору та сортування транзакцій Avail, створення зобов'язань і масштабування (стирання коду) матриці даних.
Генерація блоку вимірює час, необхідний для генерації блоку, оскільки це завжди займе принаймні деякий час. Тому треба враховувати не тільки час в кращому випадку, але і середню ситуацію і час в гіршому випадку на різних машинах.
Найслабша машина, яка може брати участь у генерації нових блоків, - це та, яка в середньому досягає межі продуктивності. Всі повільніші машини врешті-решт відстануть, тому що вони не зможуть наздогнати швидші машини.
2. Затримка розмноження
Затримка поширення — це міра часу, необхідного для поширення блоку від виробника до валідатора та однорангової мережі.
Наразі розмір блоку Avail становить 2 МБ. Протягом поточного 20-секундного ліміту часу блоку такий розмір блоку може бути поширений. Більші розміри блоків ускладнюють поширення.
Наприклад, якщо ми збільшимо Avail до підтримки блоку розміром 128 МБ, обчислення можна масштабувати (близько 7 секунд). Однак вузьким місцем стає час, необхідний для надсилання та завантаження цих блоків у мережі.
Відправка блоку розміром 128 МБ на земну кулю через однорангову мережу за 5 секунд може бути межею досяжного на даний момент.
Обмеження в 128 МБ не має нічого спільного з доступністю даних або нашим сценарієм зобов'язань, а скоріше з обмеженням пропускної здатності зв'язку.
Ця необхідність враховувати затримку поширення дає нам поточне теоретичне обмеження розміру блоку Avail.
3. Валідація блоків
Після розповсюдження валідатори-учасники не просто довіряють блокам, наданим їм ініціатором блоку — їм потрібно перевірити, чи створений блок дійсно містить дані, заявлені виробником.
Між цими трьома кроками є певна напруга. Ми можемо зробити всі валідатори потужними машинами та тісно пов'язаними чудовою мережею в одному дата-центрі – це скоротить час виробництва та валідації, а також дозволить нам поширювати набагато більше даних. Однак, оскільки ми також хочемо мати децентралізовану, різноманітну мережу з різними типами учасників, це не ідеальний підхід.
Натомість збільшення пропускної здатності буде досягнуто за рахунок розуміння кроків, необхідних для додавання блоків до ланцюжка Avail, і які кроки можна оптимізувати.
! [Масштабованість DA: поточний стан Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
В даний час валідатори, які використовують Avail, беруть весь блок і копіюють всі зобов'язання, згенеровані ініціатором для перевірки блоку. Це означає, що виробники блоків і всі валідатори повинні виконати кожен з кроків на діаграмі вище.
В одному блокчейні за замовчуванням кожен валідатор реконструює весь блок. Однак у такому ланцюжку, як Avail, де транзакції не виконуються, ця перебудова не потрібна. Таким чином, один із способів оптимізації Avail полягає в тому, щоб дозволити валідаторам досягати власних гарантій доступності даних за допомогою вибірки, а не шляхом реконструкції блоків. Це менш ресурсозатратно для валідаторів, ніж вимагати від них повторення всіх зобов'язань. Детальніше про це в наступній статті.
Як працює вибірка доступності дослідницьких даних?
В Avail легкі клієнти використовують три основні інструменти для підтвердження доступності даних: зразки, зобов'язання та докази.
Використовуючи ці інструменти, легкий клієнт виконує три кроки.
Тільки завдяки цьому легкі клієнти можуть підтвердити доступність усіх даних у блоці без необхідності завантажувати більшу частину вмісту блоку. Інші кроки, вжиті легкими клієнтами, також сприяють безпеці Avail, але не перераховані тут. Наприклад, легкі клієнти можуть ділитися зразками та коректурами, які вони завантажують, з іншими легкими клієнтами, якщо їм це потрібно. Але це процедура для легких клієнтів, щоб підтвердити доступність даних!
У другій частині цієї серії ми розглянемо способи збільшення пропускної здатності Avail у короткостроковій перспективі. Ми пояснимо, чому ми вважаємо, що Avail може задовольнити потреби будь-якої мережі в наступному році, і як ми можемо вдосконалити мережу, щоб відповідати викликам наступних років.