РОЗРОБНИКИ ПРО РОЗРОБНИКІВ: Поговоріть з tdot і Беном Джонсом

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

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

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

tdot: Я приєднався до Lattice приблизно рік тому, спеціально відповідаючи за Plasma Mode. Мета була дуже чіткою: у нас є багато MUD додатків, які споживають велику кількість газу, і при цьому ми намагаємося розмістити великі обсяги даних в ланцюгу, тому нам потрібне рішення, яке б підтримувало ці вимоги і було дешевим. Команда 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.

Отже, ми запитали себе: "Що буде, якщо почати з оффчейн 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, а намагалися зберегти простоту в складному середовищі. Отже, в цілому, це дуже крута інженерна подорож.

Бен: Я можу поговорити з точки зору 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 використовується іншими, але й еволюціонує в те, що ми намагалися зробити спочатку, але дуже заплутаним і недозрілим абстрактним чином, просто вражає. Ми завершили повний цикл, ви навколо цього створили чудову абстракцію і змусили це працювати у розумний і раціональний спосіб. Це справді круто.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бен: Говорячи про це, це буде ще одне випробування для модульності OP Stack. Ви пропонуєте