РОЗРОБНИКИ ПРО РОЗРОБНИКІВ: Розмова TDOT з BEN JONES

У цьому спеціальному випуску програми "Розробник для розробника" ми запросили основного розробника протоколу 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 все ще був джерелом доступності даних (DA) для ланцюга OP Stack, що було дуже дорого. Тому ми явно не могли запустити 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, а намагалися зберегти простоту у складному середовищі. Тож загалом це дуже крута інженерна подорож.

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, і