Devs on Devs: tdot та Ben Jones обговорюють

У цьому спеціальному випуску 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

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.

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

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

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

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

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

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

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