РОЗРОБНИКИ ПРО РОЗРОБНИКІВ: РОЗМОВА TDOT І БЕНА ДЖОНСА

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

01.Як використовувати режим Plasma для покращення OP Stack

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

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

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

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

Отже, ми запитали себе: "Що буде, якщо почати з off-chain 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. Але зараз існують деякі оптимізації, які можуть зробити його дешевшим, наприклад, обробка комітментів пакетами або їх подача в blob, або використання інших різних методів. Тому ми обов'язково вивчимо це, щоб знизити витрати L1.

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

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

Ben: Говорячи про це, це буде щодо OP Stack