Devs on Devs: tdot у розмові з Беном Джонсом

У цьому спеціальному випуску Devs on Devs ми запросили основного розробника протоколу Plasma Mode tdot(, який також є розробником Redstone ), та співзасновника відомого проекту Layer 2 Бена Джонса для бесіди. Відомий проект Layer 2 є основним двигуном OP Stack. Plasma Mode дозволяє розробникам будувати на OP Stack, але без необхідності публікувати дані на L1, а натомість можна гнучко переходити до постачальників даних поза ланцюгом, що знижує витрати та покращує масштабованість. У цій розмові вони обговорили походження співпраці Redstone та цього Layer 2 проекту, важливість відродження 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. В той же час ми майже повністю переписали весь OP Stack, цей реліз ми назвали Bedrock.

В основному, через два роки після створення rollup, ми зробили крок назад і задумалися: "Гаразд, якщо ми хочемо використати всі отримані досвіди на максимум, яким це буде?" Це перетворилося на кодову базу, яка в кінцевому підсумку отримала назву Bedrock, що є нашим найбільшим оновленням мережі.

Тоді ми співпрацювали з вами над проєктом під назвою OPCraft, я вважаю, що Biomes є його духом-наступником, це був найвеселіший момент, коли ми грали в блокчейні. Одночасно ми зітхнули з полегшенням, бо інші також можуть використовувати OP Stack для розробки. Я вважаю, що ще одним важливим моментом розширення в останні кілька років є те, що багато людей можуть запустити блокчейн.

Не тільки ті, хто розробив величезні і складні кодові бази, можуть це зробити. Коли ми почали співпрацю, бачити, як інші можуть взяти на себе цю кодову базу і зробити деякі надзвичайні речі, це велике підтвердження. А потім спостерігати, як ця ситуація розширюється на Plasma в реальному застосуванні, дійсно круто. Я навіть можу трохи поговорити про ту історію.

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