Чому Avail необхідний для криптосвіту?

Розширений10/11/2024, 1:24:06 AM
Ця стаття розглядає дизайн, функціональність та безпеку блокчейну Avail, зосереджуючись на його модульній архітектурі, рішеннях щодо доступності даних та тому, як він вирішує проблеми взаємодії. Завдяки технологіям, таким як Avail DA, Avail Nexus та Fusion, Avail прагне покращити масштабованість, оптимізувати процеси передачі активів та підвищити безпеку мережі.

Вступ

Зі швидким розвитком технології блокчейн монолітні блокчейни стикаються з серйозними проблемами масштабованості та сумісності. Провідні платформи, такі як Ethereum, відчувають різке зростання комісій за транзакції в періоди високого попиту користувачів, що значно ускладнює впровадження децентралізованих додатків. Для вирішення цих проблем розробники постійно шукають інноваційні рішення, і поява Avail пропонує новий напрямок для вирішення цих проблем. Після оновлення Cancun транзакційні витрати в екосистемі Ethereum значно знизилися, а модульна технологія стала ключовим наративом у розвитку блокчейну. У першій половині року модульні блокчейни, такі як Celestia та EigenDA, очолили цю тенденцію, а 23 липня Avail зробила великий крок вперед у модульній сфері, запустивши основну мережу Avail DA.

Як один з основних проектів у модульних блокчейнах, Avail, EigenDA та Celestia обслуговують схожі області. Однак, кожен з них має свої унікальні характеристики щодо інфраструктури, моделей виконання та токеномічного дизайну.

Команда

Avail походить від Polygon і став незалежною, нейтральною організацією у 2023 році. До того, як доступність даних (DA) стала центром уваги в галузі, Анураг Арджун співпрацював з іншими для розробки ланцюжка Plasma, спрямованого на вирішення проблем масштабованості Ethereum. Хоча цей ланцюжок допоміг Polygon отримати дохід у розмірі 19 мільярдів доларів, зрештою він не став ідеальним рішенням для масштабування. Під час цього процесу Anurag зрозумів, що всі блокчейни в кінцевому підсумку зіткнуться з однією і тією ж проблемою - доступністю даних. Приблизно 80% транзакційних витрат Rollup пов'язані з DA, що змусило його передбачити створення економічно ефективного рівня DA, який міг би вирішити проблеми масштабованості для кількох блокчейнів.

Ця ідея не була унікальною для Анурага; багато проектів блокчейну рівня 1 (L1) також намагалися позиціонувати себе як шари DA. Наприклад, Ethereum досліджує рішення DA за допомогою підходу Rollup, тоді як інші проекти L1 інновують в цьому просторі. Анураг вважає, що блокчейн рівня 1, спеціально розроблений для DA, пропонує особливі переваги.

Під час роботи в Matic, Анураг зустрів Прабала Банерджі, поточного співзасновника Avail, який здобував ступінь доктора філософії з криптографії та безпеки. Пізніше Прабал приєднався до команди як дослідник, і разом вони присвятили себе побудові масштабованого шару DA. Зі зростанням технології Zero-Knowledge Proof (ZK), двоє інтегрували дизайни блокчейну на основі доказів правдивості. З використанням досвіду Анурага у створенні протоколу вартістю мільярд доларів на Polygon, вони продовжили розробку рішень для вирішення проблем доступності даних.

Від монолітичного до модульного


Джерело: Доступна офіційна документація

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

Rollups представили модульну архітектуру, перемістивши виконання поза мережею, що зменшило перевантаження в мережах рівня 1 (L1), знизило транзакційні витрати для користувачів і підвищило пропускну здатність транзакцій. Незважаючи на те, що ця архітектура значно підвищила ефективність ончейн, обмежений простір блоків Ethereum залишається вузьким місцем, і в міру зростання попиту ця проблема може знову виникнути. В даний час децентралізовані додатки (Dapps) покладаються на L1 для передачі даних і розрахунків, в той час як Rollups використовують L1 для управління цими процесами. Незважаючи на те, що Rollups оптимізував використання блокового простору, сам блоковий простір залишається дефіцитним ресурсом.

Аналіз L1 транзакцій Ethereum Rollups показує, що витрати на DA становлять 90% витрат Rollup, що робить його найбільшим джерелом витрат. Більшість цих витрат становлять платежі за L1 комісії для публікації даних транзакцій.

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

Модулярна архітектура Avail

Avail прагне прискорити уніфікацію Web3, використовуючи свій модульний стек технологій, який об'єднує доступність даних, агрегацію та спільну безпеку. Зведення, які використовують Avail для публікації даних про офчейн-транзакції, утворюють системи на кшталт Validium (для Optimistic Rollups це називається Optimium). Validiums і Sovereign Rollups можуть покладатися на Avail для доступності даних з низьким рівнем довіри та замовлення послуг.

Ось огляд того, як Avail підтримує Validiums та Sovereign Rollups:

  1. Подання транзакції: Як і більшість існуючих Rollups, дані транзакцій пакетуються, а кореневий стан подається до Avail DA (доступність даних). Кожен пакет пов'язаний з унікальним ідентифікатором програми для представлення походження Rollup.
  2. Розширення даних та кодування стирання: Транзакції, подані до Avail DA, піддаються кодуванню стирання. Блок даних розбивається на n початкових частин і розширюється до 2n частин. Будь-які n частин з набору з 2n можуть бути використані для відновлення початкових даних, забезпечуючи збільшену надлишковість та стійкість до помилок.
  3. Створення зобов'язання: Avail DA застосовує криптографічні докази KZG поліноміальних зобов'язань до зайвих даних, що гарантує їх цілісність. Ці зобов'язання забезпечують точність та захист від втручання збережених даних.
  4. Поширення блокування: Валідатори отримують блоки, що містять зобов'язання КЗГ і відновлюють їх, щоб перевірити їх точність. Правильність блоку вирішується шляхом консенсусу.
  5. Мережа легкого клієнта: Легкі клієнти використовують вибіркову доступність даних (DAS), щоб перевірити цілісність блочних даних. Це робиться шляхом виконання перевірки відкриття полінома KZG на зобов'язання блок-заголовків, усуваючи потребу у відновленні повного зобов'язання KZG або покладанніся на докази обману.
  6. Перевірка доказів: Легкі клієнти виконують перевірку доказів, використовуючи докази на рівні комірки, згенеровані з матриці даних. Це гарантує наявність та правильність даних без необхідності завантаження або перевірки повного блоку.

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


Джерело: Доступна офіційна документація

Технічні характеристики

Використання легкого клієнта

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

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

Вибірка доступності даних (DAS)

Подібно до традиційних легких клієнтів, легкі клієнти Avail лише потребують завантаження даних заголовка блока. Крім того, вони виконують випадкове вибіркове відбірку частин даних блока для перевірки їх доступності за допомогою вибіркової відбірки доступності даних (DAS). Шляхом поєднання кодування з видаленням з KZG поліноміальними зобов'язаннями, легкі клієнти можуть забезпечити майже 100% доступність даних без підтвердження шахрайства, вимагаючи лише невеликої та фіксованої кількості запитів.

Кодування з коригуванням помилок та доступність даних

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

KZG Зобов'язання

Зобов'язання KZG, розроблені Aniket Kate, Gregory M. Zaverucha та Ian Goldberg у 2010 році, є ефективним методом зобов'язання поліномів, який здобув широке поширення в системах доведення нульового розкриття в останні роки. У архітектурі Avail зобов'язання KZG пропонують наступні переваги:

  • Вони дозволяють лаконічне зобов'язання до значень, записаних у заголовку блоку.
  • Легкі клієнти можуть перевірити доступність даних через ці зобов'язання.
  • Криптографічні властивості зв'язування зобов'язань KZG роблять практично неможливими генерацію хибних зобов'язань, що значно зменшує потребу в доказах шахрайства.

Об'єднаний рівень Avail

Avail будує «Єдиний Шар», комплексний технологічний стек, починаючи з базового шару доступності даних (DA), об'єднаного шару Nexus та додаткового захисного шару під назвою Fusion. За допомогою масштабованого шару доступності даних Avail має на меті підтримувати всю екосистему Web3. Використовуючи докази дійсності на основі комітетів поліномів KZG, Avail забезпечує миттєву, надійну доступність даних, що дозволяє розвивати ролапи, взаємодіяти, забезпечувати безпеку та адаптуватися.

Отримати DA


Джерело: Доступна офіційна документація

Avail DA є базовою архітектурою, спеціально оптимізованою для доступності даних. Вона використовує алгоритми згоди GRANDPA та BABE, що відрізняє її від інших рівнів доступності даних. Ця конструкція надає Avail DA високу масштабованість, забезпечуючи надійні гарантії щодо даних за низькі витрати через вибірковість доступності даних (DAS) та докази валідності.

У своєму корінні Avail DA пріоритизує та публікує транзакції, дозволяючи користувачам перевірити наявність даних блоку без завантаження всього блоку. Однією з ключових особливостей Avail DA є його нечутливість до даних. Він підтримує різноманітні середовища виконання, включаючи EVM, WASM та власні нові середовища виконання, що забезпечує універсальний фундамент для широкого спектру блокчейн-додатків.

Доступний Nexus


Джерело: Доступна Офіційна Документація

Avail Nexus, другий стовп екосистеми Avail, — це інклюзивний фреймворк, розроблений для уніфікації екосистеми Web3. Він з'єднує як внутрішні, так і зовнішні блокчейни, використовуючи Avail DA як надійну основу та діючи як центр перевірки. Nexus інтегрує систему зведення, координовану ZK, яка об'єднує агрегацію доказів, рівень перевірки, механізм вибору секвенсера та систему аукціону слотів. Nexus періодично надсилає на перевірку агреговані докази до Ethereum і рівня Avail DA, забезпечуючи надійність кросчейн-операцій.

Avail Fusion


Джерело: Доступна офіційна документація

Avail Fusion, третій стовп, забезпечує додаткову безпеку для екосистеми Avail та широкого простору Web3. Основна концепція за Ф'южн полягає в тому, що уніфікована система потребує уніфікованої безпеки на економічному рівні. Безпека Ф'южн підвищує консенсус Avail, використовуючи власні активи від встановлених екосистем, таких як BTC та ETH, сприяючи безпеці консенсусу Avail. Це позначає першу спробу використання зовнішніх токенів для досягнення консенсусу між блокчейнами.

Fusion підтримує два типи стейкінгу активів: встановлені криптовалюти та нові токени Rollup. Наразі прототип Fusion включає два модулі стейкінгу: один працює на блокчейні Avail, а інший - для стейкінгу конвертації активів. Важливо зазначити, що перший публічний прототип Avail Fusion все ще знаходиться у розробці.

Типи вузлів в Avail

Хоча архітектура Avail відрізняється від традиційних монолітних блокчейнів, вона все ще підтримує різні типи вузлів, включаючи повні вузли, легкі клієнти, архівні вузли та валідаторні вузли.

  • Повний вузол: Повні вузли відповідають за завантаження та перевірку правильності блоків, але вони не беруть участі в процесі консенсусу. Хоча повні вузли забезпечують додаткову надлишковість та стійкість системи, вони не є обов'язковими для функціонування мережі.
  • Валідаторний вузол: Валідаторні вузли надзвичайно важливі для генерації блоків, визначення того, які транзакції включати, і підтримання порядку. Ці вузли допомагають мережі досягати згоди.
  • Легкий клієнт: Легкі клієнти дозволяють користувачам взаємодіяти зі шаром доступності даних (DA) Avail без запуску повного вузла або покладаючись на віддалені вузли рівноправних користувачів. Вони досягають цього, виконуючи вибіркове зразокування доступності даних (DAS) на кожен новостворений блок, забезпечуючи доступність даних без завантаження всього блоку.
  • Вузол RPC: вузли RPC надають API для віддаленої взаємодії, діючи як шлюз для розробників і зовнішніх користувачів для взаємодії з мережею Avail.

Легкі клієнти моніторять підтверджені блоки в мережі Avail і виконують DAS на попередньо визначених одиницях даних у кожному новому блоку. Після успішної перевірки система обчислює впевненість підмножини одиниць даних у блоку на основі рівня впевненості, необхідного для користувача.

Економічна модель

Розподіл токенів

З запуском головної мережі Avail DA команда роздала токени AVAIL вибраним користувачам з загальною кількістю 10 мільярдів токенів. Розподіл розбивається таким чином:

  • 6% для роздач токенів та публічного розподілу
  • 30% на розвиток екосистеми
  • 23.88% для спільноти та досліджень
  • 14,12% виділено інвесторам
  • 20% виділено як основну частину внеску


Джерело: Доступна офіційна документація

Стейкінг

Токен AVAIL виконує кілька функцій, включаючи управління екосистемою та рідкий стейкінг. Хоча офіційна структура управління ще не була повністю розкрита, будь-хто може стейкати AVAIL на інфраструктурі Avail, щоб отримувати винагороди за стейкінг.

Для стейкінгу Avail використовує механізм консенсусу Nominated Proof-of-Stake (NPoS), успадкований від екосистеми Substrate. Стейкінг відіграє важливу роль в цій системі, так як користувачі стейкують токени AVAIL для підвищення безпеки мережі та отримання винагород. Чим більше токенів стейкують, тим безпечнішою стає мережа, оскільки вартість атаки на мережу зростає зі збільшенням кількості стейкнутих токенів.

Застосунки стейкінгу включають:

  • Доступне стейкінг DA: Користувачі можуть стейкати токени AVAIL валідаторам або пулам номінацій, щоб захистити мережу та підтримувати різні додатки, такі як веб-ігри Web3 та платформи децентралізованих фінансів. Стейкери отримують винагороду за свої внески.
  • Отримайте можливість стейкінгу Nexus: Секвенцери повинні стейкати токени AVAIL, щоб брати участь у поданні транзакцій та впорядкуванні. Високопродуктивні секвенцери отримують винагороду, тоді як непродуктивні покарані.
  • Avail Fusion Staking: окрім токенів AVAIL, користувачі можуть здійснювати стейкінг інших основних криптоактивів, таких як BTC та ETH, щоб підвищити безпеку мережі, а стейкери отримують винагороду.

Важливо зазначити, що користувачі, які бажають вивести свої токени зі стейкінгу, повинні пройти 28-денний період розкріпачення, протягом якого їхні токени AVAIL не можуть бути використані або передані.

Виклики

Ризик конкуренції Rollup

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

Конкуренція в DA Solutions

З різними рішеннями доступності даних (DA), такими як Celestia та EigenDA, а також майбутнім EIP-4844 Ethereum, який вводить "блоби" як опцію публікації даних, конкуренція на рівні DA посилюється. Чутливість Rollups до витрат на публікацію даних та жорстка конкуренція між рішеннями DA можуть змусити їх віддавати перевагу встановленим системам DA або покладатися на внутрішню доступність даних Ethereum, особливо після того, як буде реалізовано повний danksharding. Це може потенційно вплинути на прийняття рішення DA Avail.

Ризик спільної безпеки

Модель спільної безпеки, надана Avail Fusion, ґрунтується на стейкінгу кількох активів разом із токеном AVAIL, що може викликати побоювання серед користувачів щодо безпеки цих різних активів. Деякі розробники можуть віддавати перевагу одержанню безпеки з одного, добре встановленого активу, такого як ETH або BTC, замість залежності від кількох токенів. Крім того, розробники можуть переходити до рішень DA з більшою економічною безпекою, якщо Avail Fusion не забезпечить достатню безпеку.

Конкуренція з екосистеми додаткових послуг

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

Автор: Snow
Перекладач: Piper
Рецензент(-и): Piccolo、Edward、Elisa
Рецензент(и) перекладу: Ashely、Joyce
* Ця інформація не є фінансовою порадою чи будь-якою іншою рекомендацією, запропонованою чи схваленою Gate.io.
* Цю статтю заборонено відтворювати, передавати чи копіювати без посилання на Gate.io. Порушення є порушенням Закону про авторське право і може бути предметом судового розгляду.

Чому Avail необхідний для криптосвіту?

Розширений10/11/2024, 1:24:06 AM
Ця стаття розглядає дизайн, функціональність та безпеку блокчейну Avail, зосереджуючись на його модульній архітектурі, рішеннях щодо доступності даних та тому, як він вирішує проблеми взаємодії. Завдяки технологіям, таким як Avail DA, Avail Nexus та Fusion, Avail прагне покращити масштабованість, оптимізувати процеси передачі активів та підвищити безпеку мережі.

Вступ

Зі швидким розвитком технології блокчейн монолітні блокчейни стикаються з серйозними проблемами масштабованості та сумісності. Провідні платформи, такі як Ethereum, відчувають різке зростання комісій за транзакції в періоди високого попиту користувачів, що значно ускладнює впровадження децентралізованих додатків. Для вирішення цих проблем розробники постійно шукають інноваційні рішення, і поява Avail пропонує новий напрямок для вирішення цих проблем. Після оновлення Cancun транзакційні витрати в екосистемі Ethereum значно знизилися, а модульна технологія стала ключовим наративом у розвитку блокчейну. У першій половині року модульні блокчейни, такі як Celestia та EigenDA, очолили цю тенденцію, а 23 липня Avail зробила великий крок вперед у модульній сфері, запустивши основну мережу Avail DA.

Як один з основних проектів у модульних блокчейнах, Avail, EigenDA та Celestia обслуговують схожі області. Однак, кожен з них має свої унікальні характеристики щодо інфраструктури, моделей виконання та токеномічного дизайну.

Команда

Avail походить від Polygon і став незалежною, нейтральною організацією у 2023 році. До того, як доступність даних (DA) стала центром уваги в галузі, Анураг Арджун співпрацював з іншими для розробки ланцюжка Plasma, спрямованого на вирішення проблем масштабованості Ethereum. Хоча цей ланцюжок допоміг Polygon отримати дохід у розмірі 19 мільярдів доларів, зрештою він не став ідеальним рішенням для масштабування. Під час цього процесу Anurag зрозумів, що всі блокчейни в кінцевому підсумку зіткнуться з однією і тією ж проблемою - доступністю даних. Приблизно 80% транзакційних витрат Rollup пов'язані з DA, що змусило його передбачити створення економічно ефективного рівня DA, який міг би вирішити проблеми масштабованості для кількох блокчейнів.

Ця ідея не була унікальною для Анурага; багато проектів блокчейну рівня 1 (L1) також намагалися позиціонувати себе як шари DA. Наприклад, Ethereum досліджує рішення DA за допомогою підходу Rollup, тоді як інші проекти L1 інновують в цьому просторі. Анураг вважає, що блокчейн рівня 1, спеціально розроблений для DA, пропонує особливі переваги.

Під час роботи в Matic, Анураг зустрів Прабала Банерджі, поточного співзасновника Avail, який здобував ступінь доктора філософії з криптографії та безпеки. Пізніше Прабал приєднався до команди як дослідник, і разом вони присвятили себе побудові масштабованого шару DA. Зі зростанням технології Zero-Knowledge Proof (ZK), двоє інтегрували дизайни блокчейну на основі доказів правдивості. З використанням досвіду Анурага у створенні протоколу вартістю мільярд доларів на Polygon, вони продовжили розробку рішень для вирішення проблем доступності даних.

Від монолітичного до модульного


Джерело: Доступна офіційна документація

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

Rollups представили модульну архітектуру, перемістивши виконання поза мережею, що зменшило перевантаження в мережах рівня 1 (L1), знизило транзакційні витрати для користувачів і підвищило пропускну здатність транзакцій. Незважаючи на те, що ця архітектура значно підвищила ефективність ончейн, обмежений простір блоків Ethereum залишається вузьким місцем, і в міру зростання попиту ця проблема може знову виникнути. В даний час децентралізовані додатки (Dapps) покладаються на L1 для передачі даних і розрахунків, в той час як Rollups використовують L1 для управління цими процесами. Незважаючи на те, що Rollups оптимізував використання блокового простору, сам блоковий простір залишається дефіцитним ресурсом.

Аналіз L1 транзакцій Ethereum Rollups показує, що витрати на DA становлять 90% витрат Rollup, що робить його найбільшим джерелом витрат. Більшість цих витрат становлять платежі за L1 комісії для публікації даних транзакцій.

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

Модулярна архітектура Avail

Avail прагне прискорити уніфікацію Web3, використовуючи свій модульний стек технологій, який об'єднує доступність даних, агрегацію та спільну безпеку. Зведення, які використовують Avail для публікації даних про офчейн-транзакції, утворюють системи на кшталт Validium (для Optimistic Rollups це називається Optimium). Validiums і Sovereign Rollups можуть покладатися на Avail для доступності даних з низьким рівнем довіри та замовлення послуг.

Ось огляд того, як Avail підтримує Validiums та Sovereign Rollups:

  1. Подання транзакції: Як і більшість існуючих Rollups, дані транзакцій пакетуються, а кореневий стан подається до Avail DA (доступність даних). Кожен пакет пов'язаний з унікальним ідентифікатором програми для представлення походження Rollup.
  2. Розширення даних та кодування стирання: Транзакції, подані до Avail DA, піддаються кодуванню стирання. Блок даних розбивається на n початкових частин і розширюється до 2n частин. Будь-які n частин з набору з 2n можуть бути використані для відновлення початкових даних, забезпечуючи збільшену надлишковість та стійкість до помилок.
  3. Створення зобов'язання: Avail DA застосовує криптографічні докази KZG поліноміальних зобов'язань до зайвих даних, що гарантує їх цілісність. Ці зобов'язання забезпечують точність та захист від втручання збережених даних.
  4. Поширення блокування: Валідатори отримують блоки, що містять зобов'язання КЗГ і відновлюють їх, щоб перевірити їх точність. Правильність блоку вирішується шляхом консенсусу.
  5. Мережа легкого клієнта: Легкі клієнти використовують вибіркову доступність даних (DAS), щоб перевірити цілісність блочних даних. Це робиться шляхом виконання перевірки відкриття полінома KZG на зобов'язання блок-заголовків, усуваючи потребу у відновленні повного зобов'язання KZG або покладанніся на докази обману.
  6. Перевірка доказів: Легкі клієнти виконують перевірку доказів, використовуючи докази на рівні комірки, згенеровані з матриці даних. Це гарантує наявність та правильність даних без необхідності завантаження або перевірки повного блоку.

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


Джерело: Доступна офіційна документація

Технічні характеристики

Використання легкого клієнта

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

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

Вибірка доступності даних (DAS)

Подібно до традиційних легких клієнтів, легкі клієнти Avail лише потребують завантаження даних заголовка блока. Крім того, вони виконують випадкове вибіркове відбірку частин даних блока для перевірки їх доступності за допомогою вибіркової відбірки доступності даних (DAS). Шляхом поєднання кодування з видаленням з KZG поліноміальними зобов'язаннями, легкі клієнти можуть забезпечити майже 100% доступність даних без підтвердження шахрайства, вимагаючи лише невеликої та фіксованої кількості запитів.

Кодування з коригуванням помилок та доступність даних

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

KZG Зобов'язання

Зобов'язання KZG, розроблені Aniket Kate, Gregory M. Zaverucha та Ian Goldberg у 2010 році, є ефективним методом зобов'язання поліномів, який здобув широке поширення в системах доведення нульового розкриття в останні роки. У архітектурі Avail зобов'язання KZG пропонують наступні переваги:

  • Вони дозволяють лаконічне зобов'язання до значень, записаних у заголовку блоку.
  • Легкі клієнти можуть перевірити доступність даних через ці зобов'язання.
  • Криптографічні властивості зв'язування зобов'язань KZG роблять практично неможливими генерацію хибних зобов'язань, що значно зменшує потребу в доказах шахрайства.

Об'єднаний рівень Avail

Avail будує «Єдиний Шар», комплексний технологічний стек, починаючи з базового шару доступності даних (DA), об'єднаного шару Nexus та додаткового захисного шару під назвою Fusion. За допомогою масштабованого шару доступності даних Avail має на меті підтримувати всю екосистему Web3. Використовуючи докази дійсності на основі комітетів поліномів KZG, Avail забезпечує миттєву, надійну доступність даних, що дозволяє розвивати ролапи, взаємодіяти, забезпечувати безпеку та адаптуватися.

Отримати DA


Джерело: Доступна офіційна документація

Avail DA є базовою архітектурою, спеціально оптимізованою для доступності даних. Вона використовує алгоритми згоди GRANDPA та BABE, що відрізняє її від інших рівнів доступності даних. Ця конструкція надає Avail DA високу масштабованість, забезпечуючи надійні гарантії щодо даних за низькі витрати через вибірковість доступності даних (DAS) та докази валідності.

У своєму корінні Avail DA пріоритизує та публікує транзакції, дозволяючи користувачам перевірити наявність даних блоку без завантаження всього блоку. Однією з ключових особливостей Avail DA є його нечутливість до даних. Він підтримує різноманітні середовища виконання, включаючи EVM, WASM та власні нові середовища виконання, що забезпечує універсальний фундамент для широкого спектру блокчейн-додатків.

Доступний Nexus


Джерело: Доступна Офіційна Документація

Avail Nexus, другий стовп екосистеми Avail, — це інклюзивний фреймворк, розроблений для уніфікації екосистеми Web3. Він з'єднує як внутрішні, так і зовнішні блокчейни, використовуючи Avail DA як надійну основу та діючи як центр перевірки. Nexus інтегрує систему зведення, координовану ZK, яка об'єднує агрегацію доказів, рівень перевірки, механізм вибору секвенсера та систему аукціону слотів. Nexus періодично надсилає на перевірку агреговані докази до Ethereum і рівня Avail DA, забезпечуючи надійність кросчейн-операцій.

Avail Fusion


Джерело: Доступна офіційна документація

Avail Fusion, третій стовп, забезпечує додаткову безпеку для екосистеми Avail та широкого простору Web3. Основна концепція за Ф'южн полягає в тому, що уніфікована система потребує уніфікованої безпеки на економічному рівні. Безпека Ф'южн підвищує консенсус Avail, використовуючи власні активи від встановлених екосистем, таких як BTC та ETH, сприяючи безпеці консенсусу Avail. Це позначає першу спробу використання зовнішніх токенів для досягнення консенсусу між блокчейнами.

Fusion підтримує два типи стейкінгу активів: встановлені криптовалюти та нові токени Rollup. Наразі прототип Fusion включає два модулі стейкінгу: один працює на блокчейні Avail, а інший - для стейкінгу конвертації активів. Важливо зазначити, що перший публічний прототип Avail Fusion все ще знаходиться у розробці.

Типи вузлів в Avail

Хоча архітектура Avail відрізняється від традиційних монолітних блокчейнів, вона все ще підтримує різні типи вузлів, включаючи повні вузли, легкі клієнти, архівні вузли та валідаторні вузли.

  • Повний вузол: Повні вузли відповідають за завантаження та перевірку правильності блоків, але вони не беруть участі в процесі консенсусу. Хоча повні вузли забезпечують додаткову надлишковість та стійкість системи, вони не є обов'язковими для функціонування мережі.
  • Валідаторний вузол: Валідаторні вузли надзвичайно важливі для генерації блоків, визначення того, які транзакції включати, і підтримання порядку. Ці вузли допомагають мережі досягати згоди.
  • Легкий клієнт: Легкі клієнти дозволяють користувачам взаємодіяти зі шаром доступності даних (DA) Avail без запуску повного вузла або покладаючись на віддалені вузли рівноправних користувачів. Вони досягають цього, виконуючи вибіркове зразокування доступності даних (DAS) на кожен новостворений блок, забезпечуючи доступність даних без завантаження всього блоку.
  • Вузол RPC: вузли RPC надають API для віддаленої взаємодії, діючи як шлюз для розробників і зовнішніх користувачів для взаємодії з мережею Avail.

Легкі клієнти моніторять підтверджені блоки в мережі Avail і виконують DAS на попередньо визначених одиницях даних у кожному новому блоку. Після успішної перевірки система обчислює впевненість підмножини одиниць даних у блоку на основі рівня впевненості, необхідного для користувача.

Економічна модель

Розподіл токенів

З запуском головної мережі Avail DA команда роздала токени AVAIL вибраним користувачам з загальною кількістю 10 мільярдів токенів. Розподіл розбивається таким чином:

  • 6% для роздач токенів та публічного розподілу
  • 30% на розвиток екосистеми
  • 23.88% для спільноти та досліджень
  • 14,12% виділено інвесторам
  • 20% виділено як основну частину внеску


Джерело: Доступна офіційна документація

Стейкінг

Токен AVAIL виконує кілька функцій, включаючи управління екосистемою та рідкий стейкінг. Хоча офіційна структура управління ще не була повністю розкрита, будь-хто може стейкати AVAIL на інфраструктурі Avail, щоб отримувати винагороди за стейкінг.

Для стейкінгу Avail використовує механізм консенсусу Nominated Proof-of-Stake (NPoS), успадкований від екосистеми Substrate. Стейкінг відіграє важливу роль в цій системі, так як користувачі стейкують токени AVAIL для підвищення безпеки мережі та отримання винагород. Чим більше токенів стейкують, тим безпечнішою стає мережа, оскільки вартість атаки на мережу зростає зі збільшенням кількості стейкнутих токенів.

Застосунки стейкінгу включають:

  • Доступне стейкінг DA: Користувачі можуть стейкати токени AVAIL валідаторам або пулам номінацій, щоб захистити мережу та підтримувати різні додатки, такі як веб-ігри Web3 та платформи децентралізованих фінансів. Стейкери отримують винагороду за свої внески.
  • Отримайте можливість стейкінгу Nexus: Секвенцери повинні стейкати токени AVAIL, щоб брати участь у поданні транзакцій та впорядкуванні. Високопродуктивні секвенцери отримують винагороду, тоді як непродуктивні покарані.
  • Avail Fusion Staking: окрім токенів AVAIL, користувачі можуть здійснювати стейкінг інших основних криптоактивів, таких як BTC та ETH, щоб підвищити безпеку мережі, а стейкери отримують винагороду.

Важливо зазначити, що користувачі, які бажають вивести свої токени зі стейкінгу, повинні пройти 28-денний період розкріпачення, протягом якого їхні токени AVAIL не можуть бути використані або передані.

Виклики

Ризик конкуренції Rollup

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

Конкуренція в DA Solutions

З різними рішеннями доступності даних (DA), такими як Celestia та EigenDA, а також майбутнім EIP-4844 Ethereum, який вводить "блоби" як опцію публікації даних, конкуренція на рівні DA посилюється. Чутливість Rollups до витрат на публікацію даних та жорстка конкуренція між рішеннями DA можуть змусити їх віддавати перевагу встановленим системам DA або покладатися на внутрішню доступність даних Ethereum, особливо після того, як буде реалізовано повний danksharding. Це може потенційно вплинути на прийняття рішення DA Avail.

Ризик спільної безпеки

Модель спільної безпеки, надана Avail Fusion, ґрунтується на стейкінгу кількох активів разом із токеном AVAIL, що може викликати побоювання серед користувачів щодо безпеки цих різних активів. Деякі розробники можуть віддавати перевагу одержанню безпеки з одного, добре встановленого активу, такого як ETH або BTC, замість залежності від кількох токенів. Крім того, розробники можуть переходити до рішень DA з більшою економічною безпекою, якщо Avail Fusion не забезпечить достатню безпеку.

Конкуренція з екосистеми додаткових послуг

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

Автор: Snow
Перекладач: Piper
Рецензент(-и): Piccolo、Edward、Elisa
Рецензент(и) перекладу: Ashely、Joyce
* Ця інформація не є фінансовою порадою чи будь-якою іншою рекомендацією, запропонованою чи схваленою Gate.io.
* Цю статтю заборонено відтворювати, передавати чи копіювати без посилання на Gate.io. Порушення є порушенням Закону про авторське право і може бути предметом судового розгляду.
Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!