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

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

Бен: