Оригінальна назва: «OP+ZK, чи стане Hybrid Rollup остаточним майбутнім розширення Ethereum?» "
Оригінальний допис від @kelvinfichter
Оригінальна збірка: Jaleel, BlockBeats
Нещодавно я переконався, що майбутнє Ethereum Rollup насправді є гібридом двох основних підходів, ZK і Optimistic. У цій публікації я спробую викласти основи того, якою я уявляю цю архітектуру, і чому я вважаю, що це напрямок, у якому ми повинні рухатися. Зауважте, що я проводжу більшу частину свого часу, працюючи над Optimism, він же Optimistic Rollup, але я не експерт по ZK. Якщо я зробив якісь помилки в розмові про ZK, сміливо звертайтеся до мене, я виправлю це.
У цій статті я не маю наміру докладно описувати принцип роботи ZK і Optimistic Rollups, якщо витратити час на пояснення суті Rollups, то ця стаття буде занадто довгою. Отже, ця стаття заснована на тому, що ви вже маєте певне уявлення про ці технології.Звісно, вам не обов’язково бути експертом, але ви повинні принаймні знати, що таке ZK і Optimistic Rollups і їх загальний механізм роботи. У будь-якому випадку, будь ласка, насолоджуйтесь читанням цієї статті.
Почнемо з Optimistic Rollup
Система, яка змішувала ZK і Optimistic Rollup, спочатку базувалася на Optimistic Rollup на основі архітектури Bedrock Optimism. Bedrock розроблено для максимальної сумісності («EVM-еквівалент») з Ethereum завдяки запуску клієнта виконання, майже ідентичного клієнту Ethereum. Bedrock використовує майбутню модель поділу клієнта на консенсус/виконання Ethereum, значно зменшуючи відхилення від EVM (звичайно, завжди будуть певні зміни, але ми можемо з цим впоратися).
Як і всі хороші Rollups, Optimism витягує дані блоків/транзакцій з Ethereum, потім сортує ці дані певним детермінованим способом у консенсусному клієнті та передає ці дані клієнту виконання L2 для виконання. Ця архітектура вирішує першу половину головоломки «ідеального зведення» та дає нам L2, еквівалентний EVM.
Звичайно, проблема, яку нам ще потрібно вирішити зараз, полягає в тому, щоб розповісти Ethereum про те, що сталося в Optimism, у спосіб, який можна перевірити. Якщо цю проблему не вирішити, розумні контракти не можуть приймати рішення на основі стану оптимізму. Це означатиме, що користувачі можуть вносити кошти на Optimism, але не можуть виводити свої активи. Хоча в деяких випадках можливе одностороннє згортання, у більшості випадків двостороннє зведення є більш ефективним.
Надаючи певне зобов’язання щодо цього стану та доказ того, що це зобов’язання є правильним, ми можемо повідомляти Ethereum про стан усіх зведених пакетів. Іншими словами, ми доводимо, що «зведена програма» була виконана правильно. Єдина суттєва відмінність між ZK і Optimistic Rollups полягає у формі цього доказу. У ZK Rollup вам потрібно надати явне підтвердження нульового знання, щоб підтвердити правильне виконання програми. У Optimistic Rollup ви можете зробити заяву про обіцянку, не надаючи чітких доказів. Оскаржуючи та ставлячи під сумнів ваше твердження, інші користувачі можуть змусити вас взяти участь у «грі» туди-сюди обговорення та оскарження, щоб визначити, хто в кінцевому підсумку «так».
Я не збираюся вдаватися в подробиці про виклики Optimistic Rollup. Варто зазначити, що на цьому етапі найсучаснішим є компіляція вашої програми (Geth EVM + деякі додаткові елементи у випадку Optimism) до якоїсь простої машинної архітектури, як-от MIPS. Ми робимо це, тому що нам потрібно створити інтерпретатор програми в ланцюжку, а створити інтерпретатор MIPS набагато легше, ніж інтерпретатор EVM. EVM також є рухомою ціллю (у нас є звичайні форки оновлення) і не повністю охоплює програми, які ми хочемо підтвердити (тут також є деякі речі, не пов’язані з EVM).
Після того, як ви створили онлайн-інтерпретатор для вашої простої архітектури машини та створили деякі офлайн-інструменти, у вас має бути повнофункціональний Optimistic Rollup.
Перейдіть до ZK Rollup
Загалом я твердо вірю, що Optimistic Rollups домінуватиме протягом наступних кількох років. Деякі люди думають, що ZK Rollups згодом перевершить Optimistic Rollups, але я з цією думкою не згоден. Я вважаю, що поточна відносна простота та гнучкість Optimistic Rollups означає, що їх можна поступово трансформувати в ZK Rollups. Якщо ми зможемо знайти шаблон для здійснення цього переходу, тоді замість того, щоб намагатися побудувати більш негнучку та крихку екосистему ZK, ми зможемо просто розгорнути її у вже існуючій екосистемі Optimistic Rollup.
Тому моєю метою є створення архітектури та шляху міграції, які дозволять існуючій сучасній екосистемі OP (наприклад, 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.
Ваша місія перетворюється на час перевірки
Час доказів з нульовим знанням масштабується за двома осями: кількість обмежень і розмір схеми. Зосередившись на схемі простої машини, як-от MIPS (а не на більш складній машині, як-от EVM), ми змогли значно зменшити розмір і складність схеми. Однак кількість обмежень залежить від кількості виконуваних машинних команд. Кожен код операції EVM розбивається на кілька кодів операції MIPS, що означає, що кількість обмежень значно збільшується, а також загальний час перевірки.
Однак скорочення часу перевірки також є проблемою, яка глибоко вкорінена в домені Web2. З огляду на те, що архітектура машини MIPS навряд чи зміниться найближчим часом, ми можемо максимально оптимізувати схему та прувер незалежно від майбутніх змін у EVM. Я почуваюся досить впевненим у найнятті старшого інженера апаратного забезпечення для оптимізації чітко визначеної проблеми, можливо, у десять чи навіть сто разів більше, ніж кількість інженерів, які створюють і перевіряють рухому ціль zkEVM. Така компанія, як Netflix, ймовірно, має велику кількість апаратних інженерів, які оптимізують мікросхеми перекодування, і вони, ймовірно, готові витратити купу венчурних фондів, щоб взятися за цей цікавий виклик ZK.
Початковий час перевірки для такої схеми може перевищувати 7-денний період виведення Optimistic Rollup. Цей час перевірки з часом лише зменшуватиметься. Впроваджуючи ASIC і FPGA, ми можемо значно прискорити час перевірки. За допомогою статичної цілі ми можемо створити більш оптимальні прувери.
Згодом час перевірки для цієї схеми буде нижчим, ніж поточний 7-денний період виведення Optimism, і ми зможемо розпочати процес перевірки, щоб розглянути питання про видалення Optimism. Проводити перевірку протягом 7 днів, ймовірно, все ще занадто дорого, тому ми могли б почекати трохи довше, але це справедливо. Ви навіть можете запускати обидві системи доказів одночасно, щоб ми могли якнайшвидше почати використовувати докази ZK і повернутися до доказів Optimism, якщо перевірка з будь-якої причини зазнає невдачі. Коли перевірки Optimism будуть готові, їх можна видалити повністю прозорим для програми способом, тож ваш Optimistic Rollup стане ZK Rollup.
Ви можете піти і подбати про інші важливі питання
Запуск блокчейну є складною проблемою, яка передбачає більше, ніж просто написання великої кількості серверного коду. У Optimism велика частина нашої роботи зосереджена на покращенні досвіду користувачів і розробників шляхом надання корисних інструментів на стороні клієнта. Ми також приділяємо багато часу та енергії «м’яким» питанням: розмовляємо з проектами, розуміємо їхні больові точки та розробляємо стимули. Чим більше часу ви витрачаєте на програмне забезпечення ланцюжка, тим менше часу вам доведеться мати справу з іншими речами. Хоча ви завжди можете спробувати найняти більше людей, організації не масштабуються лінійно, і кожен новий найм збільшує витрати на внутрішню комунікацію.
Оскільки роботу схеми з нульовим знанням можна безпосередньо застосувати до вже запущеного ланцюжка, ви можете створити основну платформу та розробити програмне забезпечення для перевірки одночасно. Оскільки клієнт можна модифікувати без зміни схеми, ви можете роз’єднати клієнта та команду перевірки. Таким чином оптимістичний зведений пакет може на роки випереджати конкурентів із нульовими знаннями щодо фактичної активності в мережі.
на завершення
Відверто кажучи, я не бачу суттєвих недоліків прувера zkMIPS, якщо тільки його не можна суттєво оптимізувати з часом. Єдиний реальний вплив, який я бачу на програму, полягає в тому, що вартість газу для різних кодів операції може знадобитися скоригувати, щоб відобразити збільшення часу перевірки для цих кодів операції. Якщо справді неможливо оптимізувати цей прувер до розумного рівня, то я визнаю, що зазнав невдачі. Але якщо можливо оптимізувати цей прувер, то підхід zkMIPS/zkVM може повністю замінити поточний підхід zkEVM. Це може здатися радикальним твердженням, але не так давно одноетапні оптимістичні докази відмови були повністю замінені багатоетапними доказами.
Оригінальне посилання
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Чи стане суміш ZK і OP майбутнім Ethereum Rollup?
Оригінальна назва: «OP+ZK, чи стане Hybrid Rollup остаточним майбутнім розширення Ethereum?» "
Оригінальний допис від @kelvinfichter
Оригінальна збірка: Jaleel, BlockBeats
Нещодавно я переконався, що майбутнє Ethereum Rollup насправді є гібридом двох основних підходів, ZK і Optimistic. У цій публікації я спробую викласти основи того, якою я уявляю цю архітектуру, і чому я вважаю, що це напрямок, у якому ми повинні рухатися. Зауважте, що я проводжу більшу частину свого часу, працюючи над Optimism, він же Optimistic Rollup, але я не експерт по ZK. Якщо я зробив якісь помилки в розмові про ZK, сміливо звертайтеся до мене, я виправлю це.
У цій статті я не маю наміру докладно описувати принцип роботи ZK і Optimistic Rollups, якщо витратити час на пояснення суті Rollups, то ця стаття буде занадто довгою. Отже, ця стаття заснована на тому, що ви вже маєте певне уявлення про ці технології.Звісно, вам не обов’язково бути експертом, але ви повинні принаймні знати, що таке ZK і Optimistic Rollups і їх загальний механізм роботи. У будь-якому випадку, будь ласка, насолоджуйтесь читанням цієї статті.
Почнемо з Optimistic Rollup
Система, яка змішувала ZK і Optimistic Rollup, спочатку базувалася на Optimistic Rollup на основі архітектури Bedrock Optimism. Bedrock розроблено для максимальної сумісності («EVM-еквівалент») з Ethereum завдяки запуску клієнта виконання, майже ідентичного клієнту Ethereum. Bedrock використовує майбутню модель поділу клієнта на консенсус/виконання Ethereum, значно зменшуючи відхилення від EVM (звичайно, завжди будуть певні зміни, але ми можемо з цим впоратися).
Як і всі хороші Rollups, Optimism витягує дані блоків/транзакцій з Ethereum, потім сортує ці дані певним детермінованим способом у консенсусному клієнті та передає ці дані клієнту виконання L2 для виконання. Ця архітектура вирішує першу половину головоломки «ідеального зведення» та дає нам L2, еквівалентний EVM.
Звичайно, проблема, яку нам ще потрібно вирішити зараз, полягає в тому, щоб розповісти Ethereum про те, що сталося в Optimism, у спосіб, який можна перевірити. Якщо цю проблему не вирішити, розумні контракти не можуть приймати рішення на основі стану оптимізму. Це означатиме, що користувачі можуть вносити кошти на Optimism, але не можуть виводити свої активи. Хоча в деяких випадках можливе одностороннє згортання, у більшості випадків двостороннє зведення є більш ефективним.
Надаючи певне зобов’язання щодо цього стану та доказ того, що це зобов’язання є правильним, ми можемо повідомляти Ethereum про стан усіх зведених пакетів. Іншими словами, ми доводимо, що «зведена програма» була виконана правильно. Єдина суттєва відмінність між ZK і Optimistic Rollups полягає у формі цього доказу. У ZK Rollup вам потрібно надати явне підтвердження нульового знання, щоб підтвердити правильне виконання програми. У Optimistic Rollup ви можете зробити заяву про обіцянку, не надаючи чітких доказів. Оскаржуючи та ставлячи під сумнів ваше твердження, інші користувачі можуть змусити вас взяти участь у «грі» туди-сюди обговорення та оскарження, щоб визначити, хто в кінцевому підсумку «так».
Я не збираюся вдаватися в подробиці про виклики Optimistic Rollup. Варто зазначити, що на цьому етапі найсучаснішим є компіляція вашої програми (Geth EVM + деякі додаткові елементи у випадку Optimism) до якоїсь простої машинної архітектури, як-от MIPS. Ми робимо це, тому що нам потрібно створити інтерпретатор програми в ланцюжку, а створити інтерпретатор MIPS набагато легше, ніж інтерпретатор EVM. EVM також є рухомою ціллю (у нас є звичайні форки оновлення) і не повністю охоплює програми, які ми хочемо підтвердити (тут також є деякі речі, не пов’язані з EVM).
Після того, як ви створили онлайн-інтерпретатор для вашої простої архітектури машини та створили деякі офлайн-інструменти, у вас має бути повнофункціональний Optimistic Rollup.
Перейдіть до ZK Rollup
Загалом я твердо вірю, що Optimistic Rollups домінуватиме протягом наступних кількох років. Деякі люди думають, що ZK Rollups згодом перевершить Optimistic Rollups, але я з цією думкою не згоден. Я вважаю, що поточна відносна простота та гнучкість Optimistic Rollups означає, що їх можна поступово трансформувати в ZK Rollups. Якщо ми зможемо знайти шаблон для здійснення цього переходу, тоді замість того, щоб намагатися побудувати більш негнучку та крихку екосистему ZK, ми зможемо просто розгорнути її у вже існуючій екосистемі Optimistic Rollup.
Тому моєю метою є створення архітектури та шляху міграції, які дозволять існуючій сучасній екосистемі OP (наприклад, 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.
Ваша місія перетворюється на час перевірки
Час доказів з нульовим знанням масштабується за двома осями: кількість обмежень і розмір схеми. Зосередившись на схемі простої машини, як-от MIPS (а не на більш складній машині, як-от EVM), ми змогли значно зменшити розмір і складність схеми. Однак кількість обмежень залежить від кількості виконуваних машинних команд. Кожен код операції EVM розбивається на кілька кодів операції MIPS, що означає, що кількість обмежень значно збільшується, а також загальний час перевірки.
Однак скорочення часу перевірки також є проблемою, яка глибоко вкорінена в домені Web2. З огляду на те, що архітектура машини MIPS навряд чи зміниться найближчим часом, ми можемо максимально оптимізувати схему та прувер незалежно від майбутніх змін у EVM. Я почуваюся досить впевненим у найнятті старшого інженера апаратного забезпечення для оптимізації чітко визначеної проблеми, можливо, у десять чи навіть сто разів більше, ніж кількість інженерів, які створюють і перевіряють рухому ціль zkEVM. Така компанія, як Netflix, ймовірно, має велику кількість апаратних інженерів, які оптимізують мікросхеми перекодування, і вони, ймовірно, готові витратити купу венчурних фондів, щоб взятися за цей цікавий виклик ZK.
Початковий час перевірки для такої схеми може перевищувати 7-денний період виведення Optimistic Rollup. Цей час перевірки з часом лише зменшуватиметься. Впроваджуючи ASIC і FPGA, ми можемо значно прискорити час перевірки. За допомогою статичної цілі ми можемо створити більш оптимальні прувери.
Згодом час перевірки для цієї схеми буде нижчим, ніж поточний 7-денний період виведення Optimism, і ми зможемо розпочати процес перевірки, щоб розглянути питання про видалення Optimism. Проводити перевірку протягом 7 днів, ймовірно, все ще занадто дорого, тому ми могли б почекати трохи довше, але це справедливо. Ви навіть можете запускати обидві системи доказів одночасно, щоб ми могли якнайшвидше почати використовувати докази ZK і повернутися до доказів Optimism, якщо перевірка з будь-якої причини зазнає невдачі. Коли перевірки Optimism будуть готові, їх можна видалити повністю прозорим для програми способом, тож ваш Optimistic Rollup стане ZK Rollup.
Ви можете піти і подбати про інші важливі питання
Запуск блокчейну є складною проблемою, яка передбачає більше, ніж просто написання великої кількості серверного коду. У Optimism велика частина нашої роботи зосереджена на покращенні досвіду користувачів і розробників шляхом надання корисних інструментів на стороні клієнта. Ми також приділяємо багато часу та енергії «м’яким» питанням: розмовляємо з проектами, розуміємо їхні больові точки та розробляємо стимули. Чим більше часу ви витрачаєте на програмне забезпечення ланцюжка, тим менше часу вам доведеться мати справу з іншими речами. Хоча ви завжди можете спробувати найняти більше людей, організації не масштабуються лінійно, і кожен новий найм збільшує витрати на внутрішню комунікацію.
Оскільки роботу схеми з нульовим знанням можна безпосередньо застосувати до вже запущеного ланцюжка, ви можете створити основну платформу та розробити програмне забезпечення для перевірки одночасно. Оскільки клієнт можна модифікувати без зміни схеми, ви можете роз’єднати клієнта та команду перевірки. Таким чином оптимістичний зведений пакет може на роки випереджати конкурентів із нульовими знаннями щодо фактичної активності в мережі.
на завершення
Відверто кажучи, я не бачу суттєвих недоліків прувера zkMIPS, якщо тільки його не можна суттєво оптимізувати з часом. Єдиний реальний вплив, який я бачу на програму, полягає в тому, що вартість газу для різних кодів операції може знадобитися скоригувати, щоб відобразити збільшення часу перевірки для цих кодів операції. Якщо справді неможливо оптимізувати цей прувер до розумного рівня, то я визнаю, що зазнав невдачі. Але якщо можливо оптимізувати цей прувер, то підхід zkMIPS/zkVM може повністю замінити поточний підхід zkEVM. Це може здатися радикальним твердженням, але не так давно одноетапні оптимістичні докази відмови були повністю замінені багатоетапними доказами.
Оригінальне посилання