Зведені програми стають очевидним переможцем у масштабуванні певного набору програм Ethereum. Ці програми користуються перевагами бездозволового доступу та надійних гарантій власності, але не потребують одночасної взаємодії між усіма користувачами програми. Повністю онлайнові ігри (FOG) є найкращим прикладом, який відповідає цьому опису. FOG виграють від сильного володіння ігровими активами, участі в грі без дозволу та модифікації гри без дозволу. Тим не менш, більшість ігор не вимагають, щоб усі гравці взаємодіяли один з одним одночасно. Інші додатки, які можуть отримати вигоду від стратегій масштабування зведених додатків, включають ринки NFT, постійні біржі та інтелектуальний інтелект у мережі.

Зведені додатки вже є реалізацією для багатьох із цих випадків використання. Однак стандартні зведені реалізації, тобто зведені EVM, все ще мають важливі межі масштабованості. Ймовірно, вони можуть досягти пропускної здатності близько 100 транзакцій на секунду. Такої пропускної здатності може бути достатньо для деяких онлайн-ігор, залежно від типу гри. Проте більшість ігор потребують набагато вищої пропускної здатності для підтримки великої кількості (> 1000) одночасних гравців. Ця стаття присвячена підходам до масштабування зведених програм для охоплення сотень тисяч одночасних учасників. Для кожного підходу я обговорюю відповідний тип додатків/ігор і виклики, які постають перед ними.

Розробники, які використовують зведені додатки, або ті, хто створює інфраструктуру для масштабування зведених додатків, заохочуються зв’язатися зі мною та подати заявку в Alliance. Я з нетерпінням чекаю співпраці із засновниками, які будують у цих областях.

Горизонтальне масштабування

Горизонтальна масштабованість — це найпростіший підхід до масштабування зведених програм. Однак простота обумовлена втратою компонування, що робить їх придатними лише для невеликого набору додатків, таких як ігри для одного гравця.

Горизонтальна масштабованість означає просте розгортання кількох зведених програм (OP або ZK) з тим самим смарт-контрактом, розгорнутим для всіх зведених програм. Інтерфейс програми плавно спрямовує користувача до одного зі зведених програм залежно від ємності, розташування або конкретних параметрів програми. Alt Layer нещодавно продемонстрував цю концепцію, запустивши масштабований 2048 FOCG. У інтерфейсі гри користувач має можливість вибрати, до якого зведення приєднатися, залежно від свого географічного розташування. Завдяки простоті та доступності постачальників Rollup-as-a-service, таких як Caldera , які виконують всю інфраструктурну роботу, пов’язану з розгортанням і керуванням цими зведеними пакетами, цей підхід може бути легко прийнятий розробниками ігор.

Незважаючи на простоту, у підході до масштабування з кількома зведеними є кілька проблем. По-перше, це згортання комутації мережі. Поточні гаманці, наприклад Metamask, потребують підтвердження вручну для підключення до нової мережі, тобто екземпляру зведення. Це призводить до складного та заплутаного досвіду для гравців, яким потрібно вручну підключатися до кількох «мереж», щоб грати в одну гру. На щастя, можна абстрагуватися від цієї складності за допомогою рішень АА. Наприклад, EIP 4337 і вбудовані гаманці, такі як Privy і 0xPass.

Ще одна складна задача — це керування станом гравців під час переходу між зведенням. У деяких випадках, наприклад, падіння ємності, програмі може знадобитися об’єднати кілька екземплярів зведення в один екземпляр для економії ресурсів. У такому випадку весь стан активного гравця потрібно перенести до нового екземпляра. Поточні рішення мостів, зокрема мости zk, можуть мати вирішальне значення для вирішення цієї проблеми. Використовуючи ці рішення, можна перевести ігровий стан гравця в новий екземпляр зведення, зберігаючи підтвердження дійсності цього стану. Однак затримка існуючих рішень мосту може бути менш оптимальною для випадків використання ігор.

ЗК Державні канали

Ще один підхід до масштабування зведених програм, який більше підходить для багатокористувацьких ігор, наприклад, покеру, – це канали стану zk. У цих іграх взаємодія гравців відбувається між невеликою кількістю гравців, наприклад, 2–10. Гра між цими гравцями важлива лише під час гри. Однак кінцевий результат гри важливіший, оскільки він впливає на баланс активів кожного гравця. Отже, важливо зберігати результат у спільному постійному шарі.

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

Державні канали ZK виводять ігрові взаємодії за межі мережі. Отже, дії та транзакції в грі не враховуються в пропускній здатності зведеного додатка. Використовуючи цей підхід, зведені додатки можна масово масштабувати для підтримки десятків або сотень тисяч одночасних гравців. Транзакції зведення додатків стосуватимуться лише перевірки згенерованих ZKP і транзакцій оновлення стану, що призведе до коефіцієнта масштабування 100–1000x. Кілька команд, включаючи Ontropy , зосередилися на розробці цієї технології.

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

Модифікацією цього підходу, яка може полегшити цю проблему, є призначення одного з учасників каналу стану zk як тимчасового секвенсора. Цей секвенсор отримуватиме транзакції кожного гравця, генеруватиме відповідні ZKP і ділитиметься ZKP з усіма учасниками каналу. Цю модифікацію можна розглядати як ефемерні ZK L3, які осідають у зведеному додатку. Команда Cartridge реалізувала цю архітектуру, розробляючи спеціалізований секвенсор під назвою Katana.

Підхід до каналу станів zk має великий потенціал. Проте є кілька відкритих питань, пов’язаних із середовищем виконання всередині каналу стану zk і як його оптимізувати для перевірочної рекурсії. Поточні середовища zkEVM не надто ефективні, і більшість із них наразі не підтримують перевіркову рекурсію. Альтернативи включають легкі zkVM або навіть використання спеціалізованих схем zk для взаємодії гравців, якщо кількість дій, можливих для гравця, обмежена.

Зміна середовища виконання

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

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

Розширення функціональності EVM за допомогою попередніх компіляцій

Перший підхід полягає в тому, щоб зведення залишалося сумісним з EVM і усувало деякі обмеження пропускної здатності за допомогою попередніх компіляцій. Ідея тут проста. Попередня компіляція — це просто переміщення обчислювально витратних операцій EVM на рівень вузла. Операцію, яка вимагатиме сотень або тисяч EVM OP і споживатиме понад 100 тисяч газу, можна спростити в одну операцію з у 100 разів меншими витратами на газ. Розширення зведеного середовища за допомогою попередніх компіляцій часто називають EVM+. Приклади цього підходу включають підтримку конфіденційності в ланцюжку та підтримку більш ефективних схем підпису, наприклад, підписів BLS. Наприклад, гра в покер zkHoldem використовує спеціалізовані операції FHE та zk для досягнення приватної роздачі та розкриття покерних карт. Розробка цих спеціалізованих попередніх компіляцій часто є спільною роботою розробника зведених програм і постачальників Raas, які керують розгортанням і обслуговуванням зведених програм.

Використання середовища виконання, відмінного від EVM

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

Сьогодні у нас є зведені програми, які працюють у середовищах виконання WASM, SVM, Cairo і навіть Linux. Більшість із цих підходів дозволяють розробникам писати свої розумні контракти мовами високого рівня, такими як Rust або C. Недоліком є те, що взаємодію з існуючими контрактами Solidity часто втрачається. Проте все ще можливо створити сумісність з EVM. Наприклад, стилус Aributrum використовує співпроцесор, щоб зробити контракти Stylus сумісними з EVM. Цей дизайн наближає Stylus до архітектури EVM+, ніж до архітектури без EVM.

Гібридні середовища виконання

Третій підхід, який особливо популярний у FOGs, полягає в поєднанні найкращих функцій із двох попередніх підходів. Цей підхід поєднує сумісність EVM зі спеціалізованим середовищем виконання не-EVM. Середовище без EVM зосереджено на високопродуктивному виконанні основних ігрових примітивів. Управління внутрішньоігровими активами, наприклад торгівля внутрішньоігровими NFT, можна здійснювати за стандартними контрактами Solidity.

Перевага цього підходу полягає в тому, що сумісність з EVM забезпечує узгодження з більшою екосистемою розробників і існуючих продуктів. Це також дозволяє компонувати без дозволу. Розробники можуть модифікувати та розширювати логіку гри, додаючи смарт-контракти EVM/solidity. У той же час спеціалізований ігровий движок, не пов’язаний з EVM, забезпечує високу пропускну здатність, яку не може задовольнити EVM.

Прикладами такого підходу є World Engine від Argus і Keystone від Curio. World Engine відокремлює виконання логіки гри на окремий рівень під назвою Game Shard, який працює поверх рівня, сумісного з EVM. Game Shard також розроблено для горизонтального масштабування для коригування загальної пропускної здатності згортання на основі попиту. Подібним чином архітектура Curio Keystone об’єднує високопродуктивний ігровий движок із EVM як середовищем виконання зведених операцій. Завдання тут полягає в тому, щоб досягти повної взаємодії між механізмом EVM та ігровим двигуном.

Доступність даних

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

Одна зведена програма потенційно може досягти пропускної здатності понад 10 тис. т/с. Використання Ethereum як рівня DA для цих транзакцій неможливе. По-перше, середня вартість публікації даних простого переказу L2 ETH на L1 може перевищувати 0,10 доларів США. Ці витрати занадто високі для більшості зведених програм. Що ще важливіше, L1 Ethereum наразі не може підтримувати більше ніж приблизно 8 тис. TPS [1] для зведених пакетів, які використовують L1 для DA.

Зведені додатки в основному залежатимуть від зовнішніх рішень DA. Celestia та EigenDA наразі позиціонуються як найбільш життєздатні варіанти для зведених програм. Наприклад, Eclipse планує використовувати Celestia для свого високопродуктивного зведення на основі SVM. Argus і високопродуктивні ігрові движки також спочатку планують використовувати Celestia. Подібним чином EigenDA, який обіцяє пропускну здатність даних до 10 МБ/с, може бути життєздатним рішенням для кількох зведених програм.

Однак інтеграція Celestia або EigneDA має головний недолік — витік економічної вартості. Зведений додаток має сплачувати комісію за рівень DA на додаток до комісії за розрахунки на Ethereum L1. Плата за розрахунки має вирішальне значення для зведення додатків, оскільки воно узгоджує безпеку зведення з безпекою Ethereum. Гарантії DA менш важливі, особливо в контексті FOGs, де вартість транзакцій набагато менша. Крім того, Celestia та EigenDA обіцяють низькі комісії, оскільки ці мережі є новими та спочатку матимуть низький рівень використання. Коли ці мережі DA досягають високого рівня використання, плата за DA також може стати надмірною. На мою думку, зведені програми мають натомість використовувати простий комітет із доступності даних (DAC), щоб засвідчити доступність зведених даних[3] .

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

Я хотів би подякувати Метту Кацу, Кевіну Жангу, Тарренсу ван Асу та Ларрі Лю за їхні цінні відгуки щодо цієї статті.

[1] Припускається, що 50% ліміту блокового газу Ethereum буде призначено лише для зберігання даних за допомогою calldata, середній розмір передачі 10 байтів. 12-секундний час блокування

Відмова від відповідальності:

1. Цю статтю передруковано з [Alliance]. Усі авторські права належать оригінальному автору [Мохамед Фуда]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.