РОЗРОБНИКИ ПРО РОЗРОБНИКІВ: РОЗМОВА 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 додатків, які споживають величезну кількість газу, і при цьому ми намагаємося розмістити велику кількість даних в мережі, тому нам потрібно рішення, яке б підтримувало ці вимоги і було дешевим. Команда 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, а також з контракту виклику DA L1, на випадок, якщо дані будуть подані на блокчейн під час вирішення виклику.

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

Бен: Кажучи про це,