РОЗРОБНИКИ ПРО РОЗРОБНИКІВ: РОЗМОВА TDOT І БЕНА ДЖОНСА

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

Як покращити OP Stack за допомогою режиму Plasma

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

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

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, і які у нього різні припущення щодо безпеки.

Ben: Кажучи про це, це буде ще одне випробування для модульності OP Stack. Ми дуже чекаємо на його впровадження в Plasma, яке ти згадав, з використанням доказів несправностей (fault proofs).