Нещодавно я переконався, що майбутнє Ethereum Rollups насправді є гібридом двох основних підходів (ZK і Optimistic). У цій публікації я спробую пояснити основну архітектуру того, що я бачу, і поясню, чому я вважаю, що це найкращий шлях уперед.
Я не збираюся витрачати надто багато часу на обговорення природи ZK або Optimistic Rollups. Ця публікація передбачає, що ви вже добре розумієте, як ці речі працюють. Вам не потрібно бути експертом, але ви повинні принаймні знати, що це таке і як вони працюють на високому рівні. Якби я спробував пояснити вам Rollups, цей пост був би дуже, дуже довгим. Загалом, приємного читання!
Почніть із Optimistic Rollup
Hybrid ZK/Optimistic Rollup починався як Optimistic Rollup, який дуже схожий на архітектуру Bedrock Optimism. Bedrock прагне максимальної сумісності з Ethereum («еквівалент EVM») і досягає цього за допомогою запуску клієнта виконання, майже ідентичного звичайному клієнту Ethereum. Bedrock використовує майбутню модель поділу клієнта Ethereum на консенсус/виконання, що значно зменшує дисперсію EVM (деякі зміни завжди будуть потрібні, але ми можемо впоратися з цим). Коли я це пишу, відмінність Bedrock Geth становить +388 -30.
Як і будь-який хороший Rollup, Optimism бере дані блоків/транзакцій з Ethereum, сортує ці дані певним чином у консенсусному клієнті, а потім передає ці дані в клієнт виконання L2 для виконання. Ця архітектура вирішує першу половину головоломки «ідеального зведення», даючи нам EVM Equivalent L2.
Звичайно, зараз нам також потрібно вирішити проблему того, як розповісти доказовим способом, що відбувається всередині Ethereum Optimism. Без цієї функції контракти не можуть приймати рішення на основі стану оптимізму. Це означало б, що користувачі можуть вносити кошти в Optimism, але ніколи не зможуть вивести свої активи. Хоча в деяких випадках однонаправлене зведення може бути дійсно корисним, загалом двонаправлене зведення більш корисне.
Ми можемо повідомити Ethereum про стан будь-якого Rollup, надавши зобов’язання щодо цього стану та підтвердивши, що зобов’язання було згенеровано правильно. Іншим способом сказати це є те, що ми доводимо, що «зведена програма» була виконана правильно. Єдина справжня відмінність між ZK і Optimistic Rollups полягає у формі цього доказу. У ZK Rollup вам потрібно надати явний ZK-доказ того, що програма виконується правильно. У Optimistic Rollup ви стверджуєте про обіцянки, але не надаєте явних доказів. Інші користувачі можуть оскаржити ваші твердження та змусити вас зіграти в ітераційну гру, де ви зрештою з’ясуєте, хто правий.
Я не буду вдаватися в подробиці гри Challenge Optimistic Rollup. Варто зазначити, що найсучаснішим у цій грі є компіляція вашої програми (Geth EVM + деякі додаткові частини у випадку Optimism) до якоїсь простої машинної архітектури, як-от MIPS. Ми робимо це, тому що нам потрібно створити інтерпретатор для нашої програми в ланцюжку, а створити інтерпретатор MIPS набагато легше, ніж інтерпретатор EVM. EVM також є рухомою ціллю (у нас є звичайні форки оновлення) і не зовсім охоплює програми, які ми хочемо підтвердити (тут також є деякі речі, не пов’язані з EVM).
Після того, як ви створили інтерпретатор у ланцюжку для вашої простої архітектури машини та створили деякі інструменти поза ланцюгом, у вас має бути повнофункціональний Optimistic Rollup.
Перетворено на ZK Rollup
Загалом, я думаю, що Optimistic Rollups домінуватиме принаймні наступні кілька років. Деякі люди думають, що ZK Rollups згодом перевершить Optimistic Rollups, але я думаю, що це може бути неправильним. Я думаю, що відносна простота та гнучкість Optimistic Rollups сьогодні означає, що з часом їх можна перетворити на ZK Rollups. Якщо ми можемо визначити модель, яка це здійснить, насправді немає сильного стимулу для розгортання менш гнучкої та більш крихкої моделі, коли ви можете просто розгорнути існуючу систему Optimistic і назвати її системою ZK за день роботи.
Тому моя мета — створити архітектуру та шлях міграції, щоб існуючі сучасні системи Optimistic (такі як Bedrock) можна було плавно трансформувати в системи ZK. Я вважаю, що це не тільки можливо, але й виходить за рамки поточного підходу zkEVM.
Ми починаємо з архітектури в стилі Bedrock, яку я описав вище. Зауважте, що я (коротко) пояснив, як Bedrock має складну гру, яка затверджує програму L2 (запуск EVM + деякі додаткові речі, щоб перетворити її на ZK Rollup
Загалом, я думаю, що Optimistic Rollups домінуватиме протягом наступних кількох років. Існує думка, що ZK Rollup згодом перевершить Optimistic Rollup, але я вважаю, що це може бути неправильно. Я думаю, що відносна простота та гнучкість Optimistic Rollups означає, що з часом їх можна перетворити на ZK Rollups. Якщо ми зможемо визначити модель для цього переходу, насправді не буде сильного стимулу розгортати менш гнучкі та більш схильні до проблем системи ZK.
Тому моєю метою є створення архітектури та шляху міграції, які дозволять існуючим сучасним системам Optimistic (таким як Bedrock) плавно переходити до систем ZK. Ось, на мою думку, спосіб не тільки здійснити цей перехід, але й зробити це таким чином, що виходить за межі сьогоднішнього підходу zkEVM.
Ми починаємо з архітектури в стилі Bedrock, яку я описав раніше. Зауважте, що я (коротко) пояснив, як Bedrock має гру викликів, яка може стверджувати валідність виконання програми L2 (програма MIPS, що запускає EVM + деякі додаткові функції). Одним із головних недоліків цього підходу є те, що нам потрібно дати користувачеві певний період часу, щоб виявити та успішно оскаржити помилкову пропозицію результату програми. Це додає значну кількість часу для процесу виведення активів (наразі 7 днів у мережі Optimism).
Однак наш L2 — це лише програма, що працює на простій машині (MIPS). Для такої простої машини цілком можливо побудувати ЗК схему. Потім ми можемо використовувати цю схему, щоб однозначно довести правильне виконання програми L2. Не вносячи жодних змін у поточну кодову базу Bedrock, ви можете почати публікувати докази дійсності для Optimism. Це справді так просто.
Чому цей метод працює так добре
Коротка примітка: у цьому розділі я згадав «zkMIPS», але насправді я використовую його для позначення будь-якої загальної «простої» zkVM.
zkMIPS простіше, ніж zkEVM
Величезною перевагою створення zkMIPS (або zk[вставте інше ім’я машини]) замість zkEVM є те, що архітектура цільової машини є простою та статичною. EVM часто змінюється. Ціни на газ зміняться, коди операцій будуть налаштовані, а також щось буде додано або видалено. І MIPS-V не змінився з 1996 року. Націлюючись на zkMIPS, ви працюєте над проблемним простором. Вам не потрібно змінювати та, можливо, повторно перевіряти вашу схему кожного разу, коли оновлюється EVM.
zkMIPS більш гнучкий, ніж zkEVM
Іншим ключовим моментом суперечок є те, що zkMIPS більш гнучкий, ніж zkEVM. Завдяки zkMIPS у вас є більше можливостей для зміни коду клієнта за бажанням для досягнення різних оптимізацій або покращення взаємодії з користувачем. Оновлення клієнта більше не потрібно надсилати разом із оновленнями схеми. Ви також можете створити основний компонент, який можна використовувати для перетворення будь-якого блокчейну на ZK Rollup, а не лише Ethereum.
Ваше запитання перетворюється на час перевірки
Час перевірки ZK розподіляється за двома осями: кількість обмежень і розмір схеми. Зосередившись на схемі простої машини, як-от MIPS (а не на більш складній машині, як-от EVM), ми змогли значно зменшити розмір і складність схеми. Однак кількість обмежень залежить від кількості виконуваних машинних команд. Кожен код операції EVM розбивається на кілька кодів операції MIPS, що означає, що кількість обмежень значно збільшується, як і загальний час перевірки.
Але скорочення часу перевірки є проблемою, міцно вкоріненою в просторі Web2. З огляду на те, що архітектура машини MIPS не зміниться найближчим часом, ми можемо максимально оптимізувати наші схеми та програми перевірки, не турбуючись про зміни EVM на пізнішому етапі. Я майже впевнений, що пул наймання інженерів апаратного забезпечення, які можуть оптимізувати чітко визначену програму, принаймні в 10 (якщо не 100) разів більший, ніж пул наймання для створення та аудиту постійно мінливої цілі zkEVM. У такій компанії, як Netflix, ймовірно, є багато апаратних інженерів, які працюють над оптимізацією чіпів транскодування, і вони з радістю приймуть купу венчурних грошей, щоб впоратися з цікавою проблемою ZK.
Початковий час перевірки для такої схеми може перевищувати 7-денний період виведення Optimistic Rollup. Цей час перевірки з часом лише зменшуватиметься. Впроваджуючи ASIC і FPGA, ми можемо значно прискорити час перевірки. За допомогою статичної цілі ми можемо створити більш оптимальні прувери.
Згодом час перевірки для цієї схеми буде нижчим, ніж поточний 7-денний період виведення Optimistic Rollup, і ми зможемо розпочати процес перевірки, щоб розглянути можливість скасування Optimistic. Проводити перевірку протягом 7 днів, ймовірно, все ще занадто дорого, тому ми можемо зачекати трохи довше, але те, що все ще актуально. Ви навіть можете запустити обидві системи доказів одночасно, щоб ми могли негайно почати використовувати докази ZK, і якщо з якоїсь причини програма перевірки зазнає збою, ми зможемо повернутися до оптимістичних доказів. Коли все буде готово, його легко перейти до доказів ZK у спосіб, який буде повністю прозорим для програми. Жодна інша система не пропонує такої гнучкості та плавного шляху міграції.
Ви можете зосередитися на інших важливих питаннях
Запуск блокчейну — складне завдання, і воно включає не лише написання великої кількості серверного коду. Більшість того, що ми робимо в Optimism, зосереджено на покращенні досвіду користувачів і розробників за допомогою корисних інструментів на стороні клієнта. Ми також витратили багато часу та енергії на «м’які» речі: розмови з проектами, розуміння проблемних моментів, розробка стимулів. Чим більше часу ви витрачаєте на програмне забезпечення блокчейну, тим менше часу ви витрачаєте на роздуми про інші речі. Ви завжди можете спробувати найняти більше людей, але організації не масштабуються лінійно, і кожен новий найманець збільшує навантаження на внутрішні комунікації.
Оскільки роботу зі схемою ZK можна додати до існуючого робочого ланцюжка, ви можете паралельно працювати над створенням основної платформи та програмного забезпечення для перевірки. Крім того, оскільки клієнт можна модифікувати без зміни схеми, ви можете розділити клієнтську та атестаційну групи. Optimistic Rollup, який використовує цей підхід, може на багато років випередити конкурентів ZK з точки зору фактичної активності в мережі.
** A **** ДЕЯКІ ВИСНОВКИ **
Відверто кажучи, я не бачу істотних недоліків у цьому підході, якщо припустити, що прувер zkMIPS можна суттєво оптимізувати з часом. Єдиний реальний вплив, який я бачу на програму, полягає в тому, що витрати на газ для різних кодів операції можуть знадобитися скоригувати, щоб відобразити час перевірки, доданий цими кодами операцій. Якщо дійсно неможливо оптимізувати цей прувер до розумного рівня, то я визнаю поразку. Якщо насправді можливо оптимізувати цей прувер, то підхід zkMIPS/zkVM видається набагато кращим за поточний підхід zkEVM, що він може повністю зробити останній застарілим. Це може здатися радикальним твердженням, але не так давно одноетапні оптимістичні докази відмови були повністю замінені багатоетапними доказами.
Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Обговорення ZK/Optimistic Hybrid Rollup
Автор: kelvinfichter; Упорядник: MarsBit, MK
Нещодавно я переконався, що майбутнє Ethereum Rollups насправді є гібридом двох основних підходів (ZK і Optimistic). У цій публікації я спробую пояснити основну архітектуру того, що я бачу, і поясню, чому я вважаю, що це найкращий шлях уперед.
Я не збираюся витрачати надто багато часу на обговорення природи ZK або Optimistic Rollups. Ця публікація передбачає, що ви вже добре розумієте, як ці речі працюють. Вам не потрібно бути експертом, але ви повинні принаймні знати, що це таке і як вони працюють на високому рівні. Якби я спробував пояснити вам Rollups, цей пост був би дуже, дуже довгим. Загалом, приємного читання!
Почніть із Optimistic Rollup
Hybrid ZK/Optimistic Rollup починався як Optimistic Rollup, який дуже схожий на архітектуру Bedrock Optimism. Bedrock прагне максимальної сумісності з Ethereum («еквівалент EVM») і досягає цього за допомогою запуску клієнта виконання, майже ідентичного звичайному клієнту Ethereum. Bedrock використовує майбутню модель поділу клієнта Ethereum на консенсус/виконання, що значно зменшує дисперсію EVM (деякі зміни завжди будуть потрібні, але ми можемо впоратися з цим). Коли я це пишу, відмінність Bedrock Geth становить +388 -30.
Як і будь-який хороший Rollup, Optimism бере дані блоків/транзакцій з Ethereum, сортує ці дані певним чином у консенсусному клієнті, а потім передає ці дані в клієнт виконання L2 для виконання. Ця архітектура вирішує першу половину головоломки «ідеального зведення», даючи нам EVM Equivalent L2.
Звичайно, зараз нам також потрібно вирішити проблему того, як розповісти доказовим способом, що відбувається всередині Ethereum Optimism. Без цієї функції контракти не можуть приймати рішення на основі стану оптимізму. Це означало б, що користувачі можуть вносити кошти в Optimism, але ніколи не зможуть вивести свої активи. Хоча в деяких випадках однонаправлене зведення може бути дійсно корисним, загалом двонаправлене зведення більш корисне.
Ми можемо повідомити Ethereum про стан будь-якого Rollup, надавши зобов’язання щодо цього стану та підтвердивши, що зобов’язання було згенеровано правильно. Іншим способом сказати це є те, що ми доводимо, що «зведена програма» була виконана правильно. Єдина справжня відмінність між ZK і Optimistic Rollups полягає у формі цього доказу. У ZK Rollup вам потрібно надати явний ZK-доказ того, що програма виконується правильно. У Optimistic Rollup ви стверджуєте про обіцянки, але не надаєте явних доказів. Інші користувачі можуть оскаржити ваші твердження та змусити вас зіграти в ітераційну гру, де ви зрештою з’ясуєте, хто правий.
Я не буду вдаватися в подробиці гри Challenge Optimistic Rollup. Варто зазначити, що найсучаснішим у цій грі є компіляція вашої програми (Geth EVM + деякі додаткові частини у випадку Optimism) до якоїсь простої машинної архітектури, як-от MIPS. Ми робимо це, тому що нам потрібно створити інтерпретатор для нашої програми в ланцюжку, а створити інтерпретатор MIPS набагато легше, ніж інтерпретатор EVM. EVM також є рухомою ціллю (у нас є звичайні форки оновлення) і не зовсім охоплює програми, які ми хочемо підтвердити (тут також є деякі речі, не пов’язані з EVM).
Після того, як ви створили інтерпретатор у ланцюжку для вашої простої архітектури машини та створили деякі інструменти поза ланцюгом, у вас має бути повнофункціональний Optimistic Rollup.
Перетворено на ZK Rollup
Загалом, я думаю, що Optimistic Rollups домінуватиме принаймні наступні кілька років. Деякі люди думають, що ZK Rollups згодом перевершить Optimistic Rollups, але я думаю, що це може бути неправильним. Я думаю, що відносна простота та гнучкість Optimistic Rollups сьогодні означає, що з часом їх можна перетворити на ZK Rollups. Якщо ми можемо визначити модель, яка це здійснить, насправді немає сильного стимулу для розгортання менш гнучкої та більш крихкої моделі, коли ви можете просто розгорнути існуючу систему Optimistic і назвати її системою ZK за день роботи.
Тому моя мета — створити архітектуру та шлях міграції, щоб існуючі сучасні системи Optimistic (такі як Bedrock) можна було плавно трансформувати в системи ZK. Я вважаю, що це не тільки можливо, але й виходить за рамки поточного підходу zkEVM.
Ми починаємо з архітектури в стилі Bedrock, яку я описав вище. Зауважте, що я (коротко) пояснив, як Bedrock має складну гру, яка затверджує програму L2 (запуск EVM + деякі додаткові речі, щоб перетворити її на ZK Rollup
Загалом, я думаю, що Optimistic Rollups домінуватиме протягом наступних кількох років. Існує думка, що ZK Rollup згодом перевершить Optimistic Rollup, але я вважаю, що це може бути неправильно. Я думаю, що відносна простота та гнучкість Optimistic Rollups означає, що з часом їх можна перетворити на ZK Rollups. Якщо ми зможемо визначити модель для цього переходу, насправді не буде сильного стимулу розгортати менш гнучкі та більш схильні до проблем системи ZK.
Тому моєю метою є створення архітектури та шляху міграції, які дозволять існуючим сучасним системам Optimistic (таким як Bedrock) плавно переходити до систем ZK. Ось, на мою думку, спосіб не тільки здійснити цей перехід, але й зробити це таким чином, що виходить за межі сьогоднішнього підходу zkEVM.
Ми починаємо з архітектури в стилі Bedrock, яку я описав раніше. Зауважте, що я (коротко) пояснив, як Bedrock має гру викликів, яка може стверджувати валідність виконання програми L2 (програма MIPS, що запускає EVM + деякі додаткові функції). Одним із головних недоліків цього підходу є те, що нам потрібно дати користувачеві певний період часу, щоб виявити та успішно оскаржити помилкову пропозицію результату програми. Це додає значну кількість часу для процесу виведення активів (наразі 7 днів у мережі Optimism).
Однак наш L2 — це лише програма, що працює на простій машині (MIPS). Для такої простої машини цілком можливо побудувати ЗК схему. Потім ми можемо використовувати цю схему, щоб однозначно довести правильне виконання програми L2. Не вносячи жодних змін у поточну кодову базу Bedrock, ви можете почати публікувати докази дійсності для Optimism. Це справді так просто.
Чому цей метод працює так добре
Коротка примітка: у цьому розділі я згадав «zkMIPS», але насправді я використовую його для позначення будь-якої загальної «простої» zkVM.
zkMIPS простіше, ніж zkEVM
Величезною перевагою створення zkMIPS (або zk[вставте інше ім’я машини]) замість zkEVM є те, що архітектура цільової машини є простою та статичною. EVM часто змінюється. Ціни на газ зміняться, коди операцій будуть налаштовані, а також щось буде додано або видалено. І MIPS-V не змінився з 1996 року. Націлюючись на zkMIPS, ви працюєте над проблемним простором. Вам не потрібно змінювати та, можливо, повторно перевіряти вашу схему кожного разу, коли оновлюється EVM.
zkMIPS більш гнучкий, ніж zkEVM
Іншим ключовим моментом суперечок є те, що zkMIPS більш гнучкий, ніж zkEVM. Завдяки zkMIPS у вас є більше можливостей для зміни коду клієнта за бажанням для досягнення різних оптимізацій або покращення взаємодії з користувачем. Оновлення клієнта більше не потрібно надсилати разом із оновленнями схеми. Ви також можете створити основний компонент, який можна використовувати для перетворення будь-якого блокчейну на ZK Rollup, а не лише Ethereum.
Ваше запитання перетворюється на час перевірки
Час перевірки ZK розподіляється за двома осями: кількість обмежень і розмір схеми. Зосередившись на схемі простої машини, як-от MIPS (а не на більш складній машині, як-от EVM), ми змогли значно зменшити розмір і складність схеми. Однак кількість обмежень залежить від кількості виконуваних машинних команд. Кожен код операції EVM розбивається на кілька кодів операції MIPS, що означає, що кількість обмежень значно збільшується, як і загальний час перевірки.
Але скорочення часу перевірки є проблемою, міцно вкоріненою в просторі Web2. З огляду на те, що архітектура машини MIPS не зміниться найближчим часом, ми можемо максимально оптимізувати наші схеми та програми перевірки, не турбуючись про зміни EVM на пізнішому етапі. Я майже впевнений, що пул наймання інженерів апаратного забезпечення, які можуть оптимізувати чітко визначену програму, принаймні в 10 (якщо не 100) разів більший, ніж пул наймання для створення та аудиту постійно мінливої цілі zkEVM. У такій компанії, як Netflix, ймовірно, є багато апаратних інженерів, які працюють над оптимізацією чіпів транскодування, і вони з радістю приймуть купу венчурних грошей, щоб впоратися з цікавою проблемою ZK.
Початковий час перевірки для такої схеми може перевищувати 7-денний період виведення Optimistic Rollup. Цей час перевірки з часом лише зменшуватиметься. Впроваджуючи ASIC і FPGA, ми можемо значно прискорити час перевірки. За допомогою статичної цілі ми можемо створити більш оптимальні прувери.
Згодом час перевірки для цієї схеми буде нижчим, ніж поточний 7-денний період виведення Optimistic Rollup, і ми зможемо розпочати процес перевірки, щоб розглянути можливість скасування Optimistic. Проводити перевірку протягом 7 днів, ймовірно, все ще занадто дорого, тому ми можемо зачекати трохи довше, але те, що все ще актуально. Ви навіть можете запустити обидві системи доказів одночасно, щоб ми могли негайно почати використовувати докази ZK, і якщо з якоїсь причини програма перевірки зазнає збою, ми зможемо повернутися до оптимістичних доказів. Коли все буде готово, його легко перейти до доказів ZK у спосіб, який буде повністю прозорим для програми. Жодна інша система не пропонує такої гнучкості та плавного шляху міграції.
Ви можете зосередитися на інших важливих питаннях
Запуск блокчейну — складне завдання, і воно включає не лише написання великої кількості серверного коду. Більшість того, що ми робимо в Optimism, зосереджено на покращенні досвіду користувачів і розробників за допомогою корисних інструментів на стороні клієнта. Ми також витратили багато часу та енергії на «м’які» речі: розмови з проектами, розуміння проблемних моментів, розробка стимулів. Чим більше часу ви витрачаєте на програмне забезпечення блокчейну, тим менше часу ви витрачаєте на роздуми про інші речі. Ви завжди можете спробувати найняти більше людей, але організації не масштабуються лінійно, і кожен новий найманець збільшує навантаження на внутрішні комунікації.
Оскільки роботу зі схемою ZK можна додати до існуючого робочого ланцюжка, ви можете паралельно працювати над створенням основної платформи та програмного забезпечення для перевірки. Крім того, оскільки клієнт можна модифікувати без зміни схеми, ви можете розділити клієнтську та атестаційну групи. Optimistic Rollup, який використовує цей підхід, може на багато років випередити конкурентів ZK з точки зору фактичної активності в мережі.
** A **** ДЕЯКІ ВИСНОВКИ **
Відверто кажучи, я не бачу істотних недоліків у цьому підході, якщо припустити, що прувер zkMIPS можна суттєво оптимізувати з часом. Єдиний реальний вплив, який я бачу на програму, полягає в тому, що витрати на газ для різних кодів операції можуть знадобитися скоригувати, щоб відобразити час перевірки, доданий цими кодами операцій. Якщо дійсно неможливо оптимізувати цей прувер до розумного рівня, то я визнаю поразку. Якщо насправді можливо оптимізувати цей прувер, то підхід zkMIPS/zkVM видається набагато кращим за поточний підхід zkEVM, що він може повністю зробити останній застарілим. Це може здатися радикальним твердженням, але не так давно одноетапні оптимістичні докази відмови були повністю замінені багатоетапними доказами.