Інтерв'ю з розробниками Optimism та Redstone: Plasma-режим перетворює Рівень 2

У цьому спеціальному інтерв'ю ми запросили розробника основного протоколу Plasma Mode tdot(, який також є розробником Redstone ), і співзасновника Optimism Бена Джонса. Optimism є основним рушієм OP Stack. Plasma Mode дозволяє розробникам будувати на OP Stack, але не потребує публікації даних на L1, а може гнучко переключатися на зовнішніх постачальників даних, що дозволяє зекономити кошти та підвищити масштабованість. У цій розмові вони обговорили походження співпраці Redstone та Optimism, важливість відновлення Plasma, необхідність впровадження експериментальних протоколів у виробниче середовище, майбутню дорожню карту Plasma Mode та OP Stack, а також їхнє захоплення розвитком у сфері повноцінних ігор.

01. Як покращити OP Stack за допомогою режиму Plasma

Ben: Який процес початку вдосконалення OP Stack?

tdot: Я приєднався до Lattice приблизно рік тому, спеціалізуючись на Plasma Mode. Мета була дуже чіткою: у нас є багато MUD-додатків, які споживають величезну кількість газу, і водночас ми намагаємося розмістити велику кількість даних в ланцюзі, тому нам потрібно рішення, яке б підтримувало ці вимоги і було дешевим. Команда Lattice вже провела деякі експерименти на OP Stack, наприклад, прототипування деяких онлайнових світів і їх розгортання на OP Stack. Ми виявили, що OP Stack вже дуже добре працює.

Отже, ми запитали себе: "Як ми можемо зробити це дешевше?" Основне припущення полягає в тому, що "ми вважаємо, що OP Stack є найбільш сумісною з ідеєю Ethereum та повністю сумісною з EVM архітектурою." Те, що працює в основній мережі, може так само працювати на OP Stack, це ідеальне рішення. Але ми хочемо, щоб це було дешевше.

Тоді calldata все ще була доступністю даних ланцюга OP Stack (DA), що було дуже дорого. Тому ми очевидно не могли використовувати calldata для запуску L2, оскільки наша повноцінна гра на ланцюгу та світ MUD потребують вищої продуктивності. Тому ми вирішили почати експериментувати з іншими варіантами доступності даних (Alt DA). Насправді, у початковій документації OP Stack вже згадувалося про необхідність дослідження Alt DA.

Тож ми запитали себе: "Що буде, якщо почати з офлайн DA?" Ми сподіваємось, що вся модель безпеки та все інше зможе покладатися на L1 Ethereum. Тому ми уникали інших рішень Alt DA, вирішивши зберігати дані в централізованому DA-сховищі, а потім знайти ефективну модель безпеки на L1.

Ось чому ми повинні повторно використовувати деякі старі концепції Plasma та розмістити їх на rollup. Тут є деякі відмінності. Найбільше питання полягає в тому, як реалізувати поза ланцюгом DA та виклики даних на ланцюгу на існуючому OP Stack? Наша мета - внести якомога менше змін в OP Stack, не впливаючи на шлях rollup, оскільки ми не хочемо впливати на безпеку інших rollup ланцюгів, які використовують OP Stack.

При проектуванні rollup ви не думаєте: "Що станеться, якщо хтось змінить процес генерації даних, щоб зберігати дані з інших місць?" Навіть з цими змінами, OP Stack залишається дуже потужним і відмінно працює з коробки. Це те, що ми зробили першим.

Після цього нам потрібно написати контракт для створення цих викликів. Існують DA-виклики для примусового перенесення даних на блокчейн. Це другий етап, інтеграція контракту в процес. Ми повинні побудувати всю інтеграційну систему під час похідного процесу, щоб ви могли отримати дані з джерела DA поза ланцюгом та з контракту виклику L1 DA, на випадок, якщо дані будуть подані на ланцюг під час розв'язання виклику.

Це суть справи. Дуже складно, тому що ми хочемо зберегти елегантність і надійність речей. Водночас це відносно проста концепція. Ми не намагалися винайти все наново або змінити весь OP Stack, а намагалися зберегти простоту в складному середовищі. Отже, в цілому, це дуже крута інженерна подорож.

Ben: Я можу поговорити з точки зору OP. Ви згадали про деякі ранні роботи Lattice. Якраз у той же час, ми в Optimism практично повністю переписали весь OP Stack, це випуск, який ми назвали Bedrock.

Основним чином, через два роки після створення rollup, ми зробили крок назад і подумали: "Гаразд, якщо ми хочемо максимально використати всі отримані знання, яким це буде?" Це перетворилося на кодову базу, яка в підсумку отримала назву Bedrock, що є нашим найбільшим оновленням мережі.

Тоді ми співпрацювали з вами над проектом, що називається OPCraft, я вважаю, що Biomes є його духовним спадкоємцем, це був наш найвеселіший досвід на блокчейні. Водночас ми полегшено зітхнули, тому що інші також можуть використовувати OP Stack для розробки. Я вважаю, що ще одним важливим поворотним моментом у масштабуванні за останні кілька років є те, що багато людей можуть запускати блокчейн.

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

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

Сьогодні Plasma значно простіша. Ми розглядаємо докази та виклики валідації стану окремо від викликів даних. Врешті-решт, кілька років тому ми усвідомили, що Rollups значно простіші за Plasma. Я вважаю, що тоді висновок громади полягав у тому, що "Plasma мертва". Це був жарт епохи розширення Ethereum.

Але ми завжди вважали, що "Plasma не помер, просто ми можемо спочатку спробувати більш просте завдання". Тепер ми використовуємо інші терміни. Наприклад, тоді існували концепції, такі як виходи (exits), тепер ви можете озирнутися назад і сказати: "О, це була проблема доступності даних з деякими додатковими кроками". Тож бачити, що не лише OP Stack використовують інші, але й еволюціонують у те, що ми спочатку намагалися зробити, але в дуже заплутаній і незрілій абстрактній формі, справді вражає. Ми завершили повний цикл, а ви навколо цього зробили чудову абстракцію і змусили це працювати в розумний і раціональний спосіб. Це справді класно.

02. Найголовніше - якомога швидше перейти в продуктивне середовище

tdot: У режимі Plasma все ще існують деякі виклики та нерозв'язані проблеми, над якими ми продовжуємо працювати. Ключове питання - як уникнути витрат часу, що триває до десяти років? Ти розумієш, про що я? Нам потрібно якомога швидше досягти етапу, на якому можна буде представити результати.

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

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

Ben: Або ж це технічне навантаження. Принцип мінімальних змін, про який ти згадував, є одним з наших основних принципів під час переписування Bedrock. Я говорив про повне переписування, але важливіше те, що ми зменшили приблизно на 50 000 рядків коду, що саме по собі є дуже потужним. Тому що ти правий, ці речі справді важкі.

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

tdot: OP Stack дійсно створив спосіб, який дозволяє вам швидко просуватися в таких справах. Узгодити всіх дуже складно, оскільки ми очевидно є двома різними компаніями. У Lattice ми будуємо гру, ігровий движок, а також ланцюг.

А ви будуєте сотні тисяч речей і регулярно постачаєте всі ці продукти. З точки зору координації це дійсно дуже нелегко.

Ben: Так, дійсно, ще довгий шлях попереду. Але саме в цьому і полягає основна привабливість модульності. Для мене, з точки зору OP Stack, це одна з найзахоплюючих речей, не кажучи вже про ті дивовижні ігри та віртуальні світи, які зараз будуються на Redstone. Чисто з точки зору OP Stack, це дуже потужний приклад, що свідчить про те, що багато відмінних основних розробників приєдналися і вдосконалили цей стек, що є вражаючим.

Це вперше, ви можете значно змінити властивості системи за допомогою одного ключового булевого значення. Здатність повністю досягти цього, як ви сказали, дійсно ще довгий шлях попереду. Але навіть для того, щоб наблизитися до ефективного досягнення цього, потрібна підтримка модульності, правильно? Для нас було полегшення побачити, що ви реалізували це без необхідності, наприклад, переписувати L2 Geth. Для мене це доводить, що модульність працює.

tdot: Ситуація зараз стала кращою. З цього прикладу видно, що ви перетворили все на незалежні маленькі модулі, які можна налаштовувати та змінювати властивості. Тому я з нетерпінням чекаю, які нові функції ще будуть інтегровані. Я пам'ятаю, що ми колись турбувалися про те, що у нас є форк, який містить всі зміни до OP Stack, і його потрібно буде об'єднати з основною гілкою. Тоді ми думали: "Боже, перевіряти все це буде божевілля."

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

Ben: Це справді чудово. Цього року одним з наших пріоритетів є створення шляхів внеску для OP Stack. Тому я дуже вдячний вам за участь у тестуванні, стимулюючи ці процеси. Я радий, що ці процеси не були надто важкими, і ми досягли певних результатів. Кажучи про це, мені цікаво, як, на твою думку, ця робота буде розвиватися далі? Чого ти найбільше чекаєш у розробці?

tdot: Є багато різних напрямків роботи. Головним чином, з інтеграцією механізму доказу збоїв. Ми використовуємо прогресивний підхід для децентралізації всього технологічного стеку та підвищення його бездозвільних характеристик, кінцевою метою є реалізація бездозвільних функцій та примусового виходу.

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

Я вважаю, що після підготовки механізму доказу збоїв та всіх цих частин, в аспектах моделі Plasma буде багато оновлень. Я вважаю, що в області пакетної подачі commitment все ще є простір для оптимізації. Зараз ми робимо це дуже просто, один commitment на кожну транзакцію. А commitment – це просто хеш-значення вхідних даних, збережених поза ланцюгом.

Ми поки що зберігаємо все максимально простим, щоб перевірка була простою та швидкою, і щоб не було великих відмінностей від OP Stack. Але зараз є кілька оптимізацій, які можуть зробити це дешевшим, наприклад, обробка commitments пакетами або їх подача в blob, або використання інших різних методів. Тому ми, безумовно, вивчимо це, щоб знизити витрати L1.

Це дуже захоплююча річ для нас. Звісно, ми також з нетерпінням чекаємо на всі майбутні матеріали, пов'язані з взаємодією, і можливість взаємодіяти між усіма ланцюгами. Розуміння цього стане величезним кроком вперед для користувачів.

Багато з цих завдань, безумовно, потрібно буде реалізувати вами. Але ми хочемо зрозуміти, як це виглядає в режимі Plasma та має різні припущення безпеки.

Ben: Говорячи про це, це