! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b4e642b2e9-dd1a6f-69ad2a.webp)
Додаток Rollup стає явним переможцем у масштабуванні певного набору додатків Ethereum. Ці програми користуються інклюзивними та надійними гарантіями власності, але не вимагають одночасної взаємодії між усіма користувачами програми. Найкращим прикладом є повністю ончейн-ігри. Ончейн-ігри виграють від сильного володіння ігровими активами, що дозволяє анонімно брати участь у грі та дозволяти анонімно модифікувати гру. Тим не менш, більшість ігор не вимагають, щоб усі гравці взаємодіяли одночасно. Інші програми, які можуть отримати вигоду від стратегії масштабування Rollup, включають NFT-маркетплейси, безстрокові біржі та ончейн висновки штучного інтелекту.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-1dce91a53e-dd1a6f-69ad2a.webp)
Зведення додатків вже є кращою реалізацією для багатьох із цих випадків використання. Однак стандартна реалізація Rollup, EVMRollup, все ще має важливі обмеження масштабованості. Вони можуть досягати пропускної здатності близько 100 транзакцій в секунду. Цієї пропускної здатності може бути достатньо для деяких ончейн-ігор, залежно від типу гри. Однак більшість ігор вимагають більшої пропускної здатності для підтримки великої кількості одночасних гравців (понад 1000). У цій статті ми розглянемо, як масштабується зведення заявок, щоб охопити сотні тисяч одночасних учасників. Для кожного підходу я обговорюю відповідний тип програми/гри та виклики, з якими вона стикається.
Масштаб по горизонталі
Горизонтальна масштабованість – це найпростіший спосіб масштабувати зведену програму. Однак ця простота відбувається за рахунок компонування, що робить їх придатними лише для невеликої підмножини програм, таких як однокористувацькі ігри.
Горизонтальна масштабованість означає просте розгортання кількох зведень додатків (Optimistic або ZK) і розгортання одного смарт-контракту на всіх ролапах. Зовнішня частина програми плавно спрямовує користувача до одного з ролапів залежно від місткості, розташування або конкретних параметрів програми. Нещодавно Alt Layer продемонструвала цю концепцію, запустивши масштабовану гру FOCG 2048. На початку гри користувачі можуть вибрати, до якого ролапу приєднатися, залежно від свого географічного розташування. Завдяки своїй простоті та доступності постачальників rollup-as-a-service, таких як Caldera, які виконують усю інфраструктурну роботу, пов'язану з обертанням та керуванням цими зведеннями, цей підхід може бути легко прийнятий розробниками ігор.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cf4cf9437a-dd1a6f-69ad2a.webp)
Тим не менш, є деякі проблеми з підходом до багатозгорнутих розширень. Перша проблема – це комутатор мережі Rollup. Поточні гаманці, такі як Metamask, вимагають ручного схвалення для підключення до нової мережі, екземпляра Rollup. Це створює складний і заплутаний користувацький досвід для гравців, оскільки гравцям потрібно вручну підключатися до кількох «мереж», щоб грати в одну гру. На щастя, цю складність можна стерти за допомогою рішення Account Abstraction (AA). Приклади включають EIP 4337 і вбудовані гаманці, такі як Privy і 0xPass.
Ще одна складність полягає в управлінні станом гравця під час переходів між ролапами. У деяких випадках, наприклад при зниженні ємності, програмі може знадобитися об'єднати кілька інсталяцій зведення в один екземпляр для економії ресурсів. У цьому випадку стан усіх активних гравців потрібно перенести до нового екземпляра. Поточні мостові рішення, особливо мости ZK, можуть зіграти ключову роль у вирішенні цієї проблеми. Використовуючи ці рішення, ви можете пов'язати ігровий стан гравця з новим екземпляром Rollup, зберігаючи при цьому доказ дійсності цього стану. Однак затримка наявних мостових рішень може бути не оптимальною для ігрових сценаріїв використання.
Канал статусу ZK
Ще одне розширення ролапу програми, яке більше підходить для багатокористувацьких ігор, таких як покер, - це канал стану ZK. У цих іграх взаємодія між гравцями відбувається між невеликою кількістю гравців, наприклад, 2-10 людьми. Ігровий процес між цими гравцями важливий лише під час гри. Однак остаточний результат гри важливіший, оскільки він впливає на баланс активів кожного гравця. Тому важливо зберігати результати в загальному шарі стійкості.
У цьому випадку зведення програми являє собою спільний інформаційний рівень, де зберігаються результати гри та де також існують ігрові активи. Для кожної гри в Rollup ви можете запустити канал стану ZK, щоб обслуговувати гру. Під час ігрового процесу кожен гравець генерує транзакції та створює ZKP, доводячи, що дотримувався правил гри. Докази інших взаємодій гравців агрегують попередні докази за допомогою рекурсивних доведень. Коли гра закінчується, остаточний ZKP подається в додаток Rollup, щоб довести валідність ігрового процесу та остаточний результат. Зміна стану, спричинена грою, змінює стан гравця в додатку Rollup.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-f3acfe5e4d-dd1a6f-69ad2a.webp)
Канал стану ZK переводить ігрові взаємодії за межі ланцюга. Таким чином, внутрішньоігрова активність і транзакції не враховуються в пропускній здатності зведення програми. Використовуючи цей підхід, додаток Rollup може масштабуватися для підтримки тисяч одночасних гравців. Транзакція для зведення програми перевірятиме лише згенеровані транзакції ZKP та оновлення статусу з коефіцієнтом масштабування 100-1000x. Кілька команд, включаючи Ontropy, розробляли технологію.
Одним із недоліків цього підходу є те, що він вимагає від гравців запускати ігрову логіку на власних пристроях і генерувати ZKP. Часто ці докази мають невелику вагу і можуть бути виконані за лічені секунди за допомогою передових систем доказів, таких як Halo2. Однак це все одно може призвести до погіршення досвіду гравців для пристроїв з обмеженими ресурсами.
Одним із способів пом'якшення цієї проблеми є призначення одного з учасників каналу стану zk тимчасовим секвенсором. Секвенсер отримає транзакцію кожного гравця і згенерує відповідний ZKP, розділивши ZKP з усіма учасниками каналу. Цю модифікацію можна розглядати як короткочасне розрахунок ZK L3 до програми Rollup. Команда Cartridge реалізувала цю архітектуру, розробивши спеціальний секвенсор під назвою Katana.
Великий потенціал має підхід до державного каналу zk. Однак є кілька відкритих питань, пов'язаних із середовищем виконання в каналі стану zk і тим, як оптимізувати рекурсивне доведення. Поточні середовища zkEVM не є ефективними, і більшість із них наразі не підтримують рекурсію доказів. Альтернативи включають полегшені zkVM або навіть використання спеціалізованих схем zk для обробки взаємодії з гравцем, якщо гравець має обмежену кількість можливих ходів.
Зміна середовища виконання
Третім способом розширення зведення програми є зміна середовища виконання зведення. Незважаючи на свою зрілість і велику кількість інструментів розробки EVM, вони не підходять для високопродуктивних додатків, таких як ігри. Крім того, однопотокова модель виконання та зберігання EVM призводить до зниження пропускної здатності, яку можна покращити за рахунок удосконалень.
Основна перевага цього підходу полягає в тому, що збільшення пропускної здатності Rollup не вимагає жертвування компонуванням або обмеження кількості варіантів використання. Цей підхід можна використовувати для будь-якої програми Web 3, якщо середовище виконання може досягти пропускної здатності, необхідної для програми. Це робить їх єдиним життєздатним рішенням для додатків, яким потрібен доступ до спільного стану, таких як AMM, протоколи кредитування та інші програми DeFi.
Розширення функціональності EVM за допомогою попередньої компіляції
По-перше, Rollup підтримує сумісність з EVM і передає деякі обмеження на попередньо скомпільовану пропускну здатність адреси. Ідея тут проста. Попередня компіляція – це низхідний рух операцій EVM, що вимагають інтенсивних обчислень, до рівня вузла. Операція, яка вимагає сотень або тисяч кодів операцій EVM і споживає 100 000+ газу, може бути спрощена до однієї операції зі 100-кратним зниженням витрат на газ. Попередню компіляцію, яка розширює середовище Rollup, часто називають EVM+. Приклади такого підходу включають підтримку конфіденційності в ланцюжку та підтримку більш ефективних схем підпису, таких як підписи BLS. Наприклад, у zkHoldem покері використовуються спеціальні операції FHE та zk, щоб уможливити приватну роздачу та презентацію карт. Розробка цих спеціалізованих прекомпіляцій, як правило, є спільними зусиллями розробника зведення додатків і постачальника Raas, який керує розгортанням і обслуговуванням інфраструктури зведення додатків.
Використання середовища виконання, відмінного від EVM
Ще один спосіб поліпшити середовище виконання Rollup - позбутися від EVM. Такий підхід набирає популярності серед нових розробників в екосистемі Ethereum, а також серед розробників, які вважають, що Solidity – не найкраща мова для розробки складних додатків.
Сьогодні у нас є зведені програми, що працюють на середовищах виконання WASM, SVM, Cairo і навіть Linux. Більшість із цих методів дозволяють розробникам писати смарт-контракти, використовуючи мови високого рівня, такі як Rust або C. Недоліком є те, що часто втрачається сумісність з існуючими контрактами Solidity. Однак сумісність з EVM все ще може бути створена. Наприклад, стилус Aributrum використовує співпроцесор, щоб зробити контракт Stylus сумісним з EVM. Такий дизайн наближає Stylus до архітектури EVM+, ніж до не-EVM.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d1e13024e5-dd1a6f-69ad2a.webp)
Змішане середовище виконання
Третій підхід, який особливо популярний серед туманів, є найкращою функцією, яка поєднує в собі перші два. Цей підхід поєднує сумісність з EVM зі спеціальним середовищем виконання, відмінним від EVM. Середовища, що не належать до EVM, зосереджені на високопродуктивному виконанні основних ігрових примітивів. Управління ігровими активами, такими як внутрішньоігрові транзакції NFT, може здійснюватися за допомогою стандартних контрактів Solidity.
Перевага цього підходу полягає в тому, що сумісність з EVM забезпечує узгодження з більшою екосистемою розробників та існуючими продуктами. Це також забезпечує інклюзивне компонування. Розробники можуть змінювати та розширювати логіку гри, додаючи смарт-контракти EVM/Solidity. У той же час спеціально створені ігрові рушії, що не підтримують EVM, досягають високої пропускної здатності, яку не може EVM.
Прикладами такого підходу є World Engine від Argus і Keystone від Curio. World Engine відокремлює виконання ігрової логіки в окремий шар, званий Game Shard, який виконується поверх EVM-сумісного шару. Game Shard також призначений для горизонтального масштабування, щоб регулювати загальну пропускну здатність зведення залежно від попиту. Аналогічно, архітектура Keystone від Curio поєднує високопродуктивний ігровий движок з EVM як середовищем виконання Rollup. Завдання полягає в тому, щоб досягти бездоганної сумісності між рушіями EVM та ігровими рушіями.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-df306665b5-dd1a6f-69ad2a.webp)
Міркування щодо доступності даних
У попередній дискусії основна увага була приділена збільшенню пропускної здатності транзакцій Rollup, що є основним аспектом масштабування Rollup додатків. Інші теми, пов'язані з цим збільшенням пропускної здатності, включають доступність даних (DA), децентралізацію замовлень і швидкість розрахунків. Для високопродуктивних зведень додатків доступність даних є найактуальнішою з цих проблем.
Один додаток Rollup може мати пропускну здатність понад 10 000 транзакцій в секунду. Неможливо використовувати Ethereum як рівень доступності даних для цих транзакцій. По-перше, середня вартість публікації простих даних переказу L2 ETH на L2 може перевищувати $0,1. Ці витрати занадто високі для більшості зведених додатків. Більше того, L1 від Ethereum наразі не може підтримувати зведення, які використовують переваги L1 для доступності даних із приблизно 8 000 транзакцій на секунду.
Зведення додатків буде залежати в першу чергу від зовнішніх рішень DA. Celestia і EigenDA в даний час позиціонуються як найбільш життєздатні варіанти для додатку Rollup. Наприклад, Eclipse планує використовувати Celestia як рівень доступності даних для свого базового зведення SVM з високою пропускною здатністю. Також планується, що в ігрових рушіях Argus і з високою пропускною здатністю спочатку буде використовуватися Celestia. Аналогічно, EigenDA обіцяє пропускну здатність даних до 10 МБ в секунду, а також може надати життєздатне рішення для декількох зведень додатків.
Однак основним недоліком інтеграції Celestia або EigneDA є витік економічної цінності. Зведені додатки повинні сплачувати комісію за рівень DA, а також комісію за розрахунки в Ethereum L1. Комісія за розрахунок є ключовою для програми Rollup, оскільки вона пов'язує безпеку Rollup із безпекою Ethereum. Гарантії DA менш важливі в контексті FOG, де вартість транзакції набагато менша, ніж у цих мереж. Крім того, Celestia та EigenDA обіцяють низькі комісії, оскільки ці мережі тільки запущені, а використання спочатку буде низьким. Коли ці мережі DA досягають високого використання, плата за DA також може стати непомірно високою. На мою думку, для підтвердження доступності зведених даних слід використовувати просту дошку доступності даних (Data Availability Board, DAC).
Підсумовуючи, я вважаю, що зведення додатків є найкращим існуючим рішенням для масштабування додатків з високою пропускною здатністю, особливо повністю ончейн-ігор. Розширення цих програм за допомогою Rollup є ключем до досягнення масового впровадження за межами нативних криптокористувачів.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?
Автор: Мохамед Фуда
Складено: DeepTide TechFlow
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b4e642b2e9-dd1a6f-69ad2a.webp)
Додаток Rollup стає явним переможцем у масштабуванні певного набору додатків Ethereum. Ці програми користуються інклюзивними та надійними гарантіями власності, але не вимагають одночасної взаємодії між усіма користувачами програми. Найкращим прикладом є повністю ончейн-ігри. Ончейн-ігри виграють від сильного володіння ігровими активами, що дозволяє анонімно брати участь у грі та дозволяти анонімно модифікувати гру. Тим не менш, більшість ігор не вимагають, щоб усі гравці взаємодіяли одночасно. Інші програми, які можуть отримати вигоду від стратегії масштабування Rollup, включають NFT-маркетплейси, безстрокові біржі та ончейн висновки штучного інтелекту.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-1dce91a53e-dd1a6f-69ad2a.webp)
Зведення додатків вже є кращою реалізацією для багатьох із цих випадків використання. Однак стандартна реалізація Rollup, EVMRollup, все ще має важливі обмеження масштабованості. Вони можуть досягати пропускної здатності близько 100 транзакцій в секунду. Цієї пропускної здатності може бути достатньо для деяких ончейн-ігор, залежно від типу гри. Однак більшість ігор вимагають більшої пропускної здатності для підтримки великої кількості одночасних гравців (понад 1000). У цій статті ми розглянемо, як масштабується зведення заявок, щоб охопити сотні тисяч одночасних учасників. Для кожного підходу я обговорюю відповідний тип програми/гри та виклики, з якими вона стикається.
Масштаб по горизонталі
Горизонтальна масштабованість – це найпростіший спосіб масштабувати зведену програму. Однак ця простота відбувається за рахунок компонування, що робить їх придатними лише для невеликої підмножини програм, таких як однокористувацькі ігри.
Горизонтальна масштабованість означає просте розгортання кількох зведень додатків (Optimistic або ZK) і розгортання одного смарт-контракту на всіх ролапах. Зовнішня частина програми плавно спрямовує користувача до одного з ролапів залежно від місткості, розташування або конкретних параметрів програми. Нещодавно Alt Layer продемонструвала цю концепцію, запустивши масштабовану гру FOCG 2048. На початку гри користувачі можуть вибрати, до якого ролапу приєднатися, залежно від свого географічного розташування. Завдяки своїй простоті та доступності постачальників rollup-as-a-service, таких як Caldera, які виконують усю інфраструктурну роботу, пов'язану з обертанням та керуванням цими зведеннями, цей підхід може бути легко прийнятий розробниками ігор.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cf4cf9437a-dd1a6f-69ad2a.webp)
Тим не менш, є деякі проблеми з підходом до багатозгорнутих розширень. Перша проблема – це комутатор мережі Rollup. Поточні гаманці, такі як Metamask, вимагають ручного схвалення для підключення до нової мережі, екземпляра Rollup. Це створює складний і заплутаний користувацький досвід для гравців, оскільки гравцям потрібно вручну підключатися до кількох «мереж», щоб грати в одну гру. На щастя, цю складність можна стерти за допомогою рішення Account Abstraction (AA). Приклади включають EIP 4337 і вбудовані гаманці, такі як Privy і 0xPass.
Ще одна складність полягає в управлінні станом гравця під час переходів між ролапами. У деяких випадках, наприклад при зниженні ємності, програмі може знадобитися об'єднати кілька інсталяцій зведення в один екземпляр для економії ресурсів. У цьому випадку стан усіх активних гравців потрібно перенести до нового екземпляра. Поточні мостові рішення, особливо мости ZK, можуть зіграти ключову роль у вирішенні цієї проблеми. Використовуючи ці рішення, ви можете пов'язати ігровий стан гравця з новим екземпляром Rollup, зберігаючи при цьому доказ дійсності цього стану. Однак затримка наявних мостових рішень може бути не оптимальною для ігрових сценаріїв використання.
Канал статусу ZK
Ще одне розширення ролапу програми, яке більше підходить для багатокористувацьких ігор, таких як покер, - це канал стану ZK. У цих іграх взаємодія між гравцями відбувається між невеликою кількістю гравців, наприклад, 2-10 людьми. Ігровий процес між цими гравцями важливий лише під час гри. Однак остаточний результат гри важливіший, оскільки він впливає на баланс активів кожного гравця. Тому важливо зберігати результати в загальному шарі стійкості.
У цьому випадку зведення програми являє собою спільний інформаційний рівень, де зберігаються результати гри та де також існують ігрові активи. Для кожної гри в Rollup ви можете запустити канал стану ZK, щоб обслуговувати гру. Під час ігрового процесу кожен гравець генерує транзакції та створює ZKP, доводячи, що дотримувався правил гри. Докази інших взаємодій гравців агрегують попередні докази за допомогою рекурсивних доведень. Коли гра закінчується, остаточний ZKP подається в додаток Rollup, щоб довести валідність ігрового процесу та остаточний результат. Зміна стану, спричинена грою, змінює стан гравця в додатку Rollup.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-f3acfe5e4d-dd1a6f-69ad2a.webp)
Канал стану ZK переводить ігрові взаємодії за межі ланцюга. Таким чином, внутрішньоігрова активність і транзакції не враховуються в пропускній здатності зведення програми. Використовуючи цей підхід, додаток Rollup може масштабуватися для підтримки тисяч одночасних гравців. Транзакція для зведення програми перевірятиме лише згенеровані транзакції ZKP та оновлення статусу з коефіцієнтом масштабування 100-1000x. Кілька команд, включаючи Ontropy, розробляли технологію.
Одним із недоліків цього підходу є те, що він вимагає від гравців запускати ігрову логіку на власних пристроях і генерувати ZKP. Часто ці докази мають невелику вагу і можуть бути виконані за лічені секунди за допомогою передових систем доказів, таких як Halo2. Однак це все одно може призвести до погіршення досвіду гравців для пристроїв з обмеженими ресурсами.
Одним із способів пом'якшення цієї проблеми є призначення одного з учасників каналу стану zk тимчасовим секвенсором. Секвенсер отримає транзакцію кожного гравця і згенерує відповідний ZKP, розділивши ZKP з усіма учасниками каналу. Цю модифікацію можна розглядати як короткочасне розрахунок ZK L3 до програми Rollup. Команда Cartridge реалізувала цю архітектуру, розробивши спеціальний секвенсор під назвою Katana.
Великий потенціал має підхід до державного каналу zk. Однак є кілька відкритих питань, пов'язаних із середовищем виконання в каналі стану zk і тим, як оптимізувати рекурсивне доведення. Поточні середовища zkEVM не є ефективними, і більшість із них наразі не підтримують рекурсію доказів. Альтернативи включають полегшені zkVM або навіть використання спеціалізованих схем zk для обробки взаємодії з гравцем, якщо гравець має обмежену кількість можливих ходів.
Зміна середовища виконання
Третім способом розширення зведення програми є зміна середовища виконання зведення. Незважаючи на свою зрілість і велику кількість інструментів розробки EVM, вони не підходять для високопродуктивних додатків, таких як ігри. Крім того, однопотокова модель виконання та зберігання EVM призводить до зниження пропускної здатності, яку можна покращити за рахунок удосконалень.
Основна перевага цього підходу полягає в тому, що збільшення пропускної здатності Rollup не вимагає жертвування компонуванням або обмеження кількості варіантів використання. Цей підхід можна використовувати для будь-якої програми Web 3, якщо середовище виконання може досягти пропускної здатності, необхідної для програми. Це робить їх єдиним життєздатним рішенням для додатків, яким потрібен доступ до спільного стану, таких як AMM, протоколи кредитування та інші програми DeFi.
Розширення функціональності EVM за допомогою попередньої компіляції
По-перше, Rollup підтримує сумісність з EVM і передає деякі обмеження на попередньо скомпільовану пропускну здатність адреси. Ідея тут проста. Попередня компіляція – це низхідний рух операцій EVM, що вимагають інтенсивних обчислень, до рівня вузла. Операція, яка вимагає сотень або тисяч кодів операцій EVM і споживає 100 000+ газу, може бути спрощена до однієї операції зі 100-кратним зниженням витрат на газ. Попередню компіляцію, яка розширює середовище Rollup, часто називають EVM+. Приклади такого підходу включають підтримку конфіденційності в ланцюжку та підтримку більш ефективних схем підпису, таких як підписи BLS. Наприклад, у zkHoldem покері використовуються спеціальні операції FHE та zk, щоб уможливити приватну роздачу та презентацію карт. Розробка цих спеціалізованих прекомпіляцій, як правило, є спільними зусиллями розробника зведення додатків і постачальника Raas, який керує розгортанням і обслуговуванням інфраструктури зведення додатків.
Використання середовища виконання, відмінного від EVM
Ще один спосіб поліпшити середовище виконання Rollup - позбутися від EVM. Такий підхід набирає популярності серед нових розробників в екосистемі Ethereum, а також серед розробників, які вважають, що Solidity – не найкраща мова для розробки складних додатків.
Сьогодні у нас є зведені програми, що працюють на середовищах виконання WASM, SVM, Cairo і навіть Linux. Більшість із цих методів дозволяють розробникам писати смарт-контракти, використовуючи мови високого рівня, такі як Rust або C. Недоліком є те, що часто втрачається сумісність з існуючими контрактами Solidity. Однак сумісність з EVM все ще може бути створена. Наприклад, стилус Aributrum використовує співпроцесор, щоб зробити контракт Stylus сумісним з EVM. Такий дизайн наближає Stylus до архітектури EVM+, ніж до не-EVM.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d1e13024e5-dd1a6f-69ad2a.webp)
Змішане середовище виконання
Третій підхід, який особливо популярний серед туманів, є найкращою функцією, яка поєднує в собі перші два. Цей підхід поєднує сумісність з EVM зі спеціальним середовищем виконання, відмінним від EVM. Середовища, що не належать до EVM, зосереджені на високопродуктивному виконанні основних ігрових примітивів. Управління ігровими активами, такими як внутрішньоігрові транзакції NFT, може здійснюватися за допомогою стандартних контрактів Solidity.
Перевага цього підходу полягає в тому, що сумісність з EVM забезпечує узгодження з більшою екосистемою розробників та існуючими продуктами. Це також забезпечує інклюзивне компонування. Розробники можуть змінювати та розширювати логіку гри, додаючи смарт-контракти EVM/Solidity. У той же час спеціально створені ігрові рушії, що не підтримують EVM, досягають високої пропускної здатності, яку не може EVM.
Прикладами такого підходу є World Engine від Argus і Keystone від Curio. World Engine відокремлює виконання ігрової логіки в окремий шар, званий Game Shard, який виконується поверх EVM-сумісного шару. Game Shard також призначений для горизонтального масштабування, щоб регулювати загальну пропускну здатність зведення залежно від попиту. Аналогічно, архітектура Keystone від Curio поєднує високопродуктивний ігровий движок з EVM як середовищем виконання Rollup. Завдання полягає в тому, щоб досягти бездоганної сумісності між рушіями EVM та ігровими рушіями.
! [Інтерпретація технології Dapp Rollup: як зробити високопродуктивний додаток мейнстрімом?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-df306665b5-dd1a6f-69ad2a.webp)
Міркування щодо доступності даних
У попередній дискусії основна увага була приділена збільшенню пропускної здатності транзакцій Rollup, що є основним аспектом масштабування Rollup додатків. Інші теми, пов'язані з цим збільшенням пропускної здатності, включають доступність даних (DA), децентралізацію замовлень і швидкість розрахунків. Для високопродуктивних зведень додатків доступність даних є найактуальнішою з цих проблем.
Один додаток Rollup може мати пропускну здатність понад 10 000 транзакцій в секунду. Неможливо використовувати Ethereum як рівень доступності даних для цих транзакцій. По-перше, середня вартість публікації простих даних переказу L2 ETH на L2 може перевищувати $0,1. Ці витрати занадто високі для більшості зведених додатків. Більше того, L1 від Ethereum наразі не може підтримувати зведення, які використовують переваги L1 для доступності даних із приблизно 8 000 транзакцій на секунду.
Зведення додатків буде залежати в першу чергу від зовнішніх рішень DA. Celestia і EigenDA в даний час позиціонуються як найбільш життєздатні варіанти для додатку Rollup. Наприклад, Eclipse планує використовувати Celestia як рівень доступності даних для свого базового зведення SVM з високою пропускною здатністю. Також планується, що в ігрових рушіях Argus і з високою пропускною здатністю спочатку буде використовуватися Celestia. Аналогічно, EigenDA обіцяє пропускну здатність даних до 10 МБ в секунду, а також може надати життєздатне рішення для декількох зведень додатків.
Однак основним недоліком інтеграції Celestia або EigneDA є витік економічної цінності. Зведені додатки повинні сплачувати комісію за рівень DA, а також комісію за розрахунки в Ethereum L1. Комісія за розрахунок є ключовою для програми Rollup, оскільки вона пов'язує безпеку Rollup із безпекою Ethereum. Гарантії DA менш важливі в контексті FOG, де вартість транзакції набагато менша, ніж у цих мереж. Крім того, Celestia та EigenDA обіцяють низькі комісії, оскільки ці мережі тільки запущені, а використання спочатку буде низьким. Коли ці мережі DA досягають високого використання, плата за DA також може стати непомірно високою. На мою думку, для підтвердження доступності зведених даних слід використовувати просту дошку доступності даних (Data Availability Board, DAC).
Підсумовуючи, я вважаю, що зведення додатків є найкращим існуючим рішенням для масштабування додатків з високою пропускною здатністю, особливо повністю ончейн-ігор. Розширення цих програм за допомогою Rollup є ключем до досягнення масового впровадження за межами нативних криптокористувачів.