8 квітня 2025 року засновник Ethereum Віталік на саміті Web3 Scholar Summit 2025 виступить з основним доповіддю. Golden Finance підготував зміст доповіді наступним чином.
Зараз вихід з Optimism або Arbitrum потребує 1 тижня виходу, що викликає багато проблем.
Чому нам це важливо? Чому важливо швидше зв'язувати L2 та L1? Я вважаю, що є дві причини для мене. Одна з них — це досвід користувачів, ми хочемо, щоб у користувачів був кращий досвід, чекати 1 тиждень — це поганий досвід. Інша причина — це нам потрібна більш інтегрована екосистема. Нам потрібно зробити деякі речі, щоб справді покращити Optimism, Arbitrum, Polygon.
Ці частини світу Ethereum не є незалежними.
Наразі реалізація взаємодії між L1 та L2 є дуже швидкою, але вона потребує багато Gas. Ми дійсно почали звертати на це увагу з минулого літа. Два питання, які нас цікавлять, включають: специфічні адреси блокчейну та проекти намірів. Я сподіваюся, що перенести Optimism на Arbitrum не знадобиться тиждень часу, навіть я сподіваюся, що можна буде помістити Optimism у смарт-контракт.
У смарт-контракті, якщо будь-хто спочатку надає докази, що вони через контракт надіслали кошти на будь-яку адресу призначення, він автоматично переходить до цього етапу. Тому ми хочемо знайти відповідний спосіб якомога більше зменшити тижневий період очікування.
Чому ми зараз маємо тижневий вікно для виведення? Тому що Rollup Optimism потрібно чекати тиждень, щоб побачити, чи хтось оскаржує його хеш, і якщо ніхто не оскаржує, тоді ви можете прийняти хеш. Перевага Optimism полягає в тому, що технологія, на якій вона базується, є дуже обережною, але ціною є тижневий термін очікування.
Якщо ми не хочемо чекати 1 тиждень, тоді нам потрібно створити систему, яка може повністю використовувати не Optimism доказову систему для упаковки блоків, як поєднання ZK+TEE+OP — це наш запропонований дизайн.
За звичайних обставин, як тільки відбувається транзакція L2, статус буде завершено на L1 протягом години, скорочуючи 1 годину до 12 секунд, що, по суті, є лише питанням ефективності. Отже, це перша мета. Друга мета полягає в тому, що ми хочемо, щоб L2 не мав довіри. Ми хочемо довести, що система здатна визначати правильний стан і реєструвати стан помилки, навіть якщо компонент, якому потрібно довіряти, зламаний. Отже, сьогодні Rollups перебувають або в нульовій, або в першій фазі, а це означає, що вони покладають певний рівень довіри або всю свою довіру на якийсь комітет з безпеки. Ви повинні довіряти виробнику, щоб правильно їх розробити. Ви повинні вірити, що виробник не зберігає копію на самому ключі сайту.
І ви також повинні вірити, що апаратний механізм не є чимось, що може знищити будь-хто, хто має апаратуру, ви повинні вірити, що вони не можуть знайти способу, наприклад, лазера, інфрачервоного сканування обладнання, витягти інформацію без пошкодження зображення.
Зараз ми не хочемо покладати всю довіру на ZK.
Ви будете розподіляти довіру між трьома різними механізмами, які працюють за дуже різними логічними типами. Якщо ми маємо таку конструкцію, то ви зможете скоротити термін остаточного підтвердження з 1 тижня до 1 години. До речі, інший спосіб - це те, як я раніше бачив групову систему, я в основному ділив їх на дві категорії. Одна категорія - це довіра установ, а інша - це криптодовіра.
Інший вимір – швидкий і повільний. Швидкі речі можуть бути схвалені відразу, тоді як повільні речі потрібно почекати деякий час. Цікаво, що, як і чотири речі тут, це, по суті, 4 типи компонентів системи доказів, які люди використовують або думають у контексті L2, чи не так? Якби ми дійсно могли помістити їх у коробку, вони б помістилися рівно 2×2.
Перший крок, в основному, ми скорочуємо вікно для "диявольської прогулянки" з 1 тижня до 1 години. Що це вам дає? В основному це означає, що якщо ви використовуєте нативний міст для прямого переведення активів, ваш час очікування скорочено з 1 тижня до 1 години. Якщо ви використовуєте міст на основі наміру, то міст на основі наміру є миттєвим, але постачальники ліквідності не повинні чекати 1 годину, а повинні чекати 1 годину. Вартість надання ліквідності знизилася в 168 разів. Отже, витрати, які вам потрібно буде сплатити, знизяться до 168 разів.
L2s можуть використовувати lowlookahead для асинхронного читання L1. Це функція, яка вже є у L2, оскільки вони повинні мати можливість обробляти депозити. Ми використовуємо той самий стан, що й для читання депозитів, і надаємо його L1SLOADopcode. Підтримка читання даних L1, даних з оракулів, гаманців секретних ключів та багатьох інших застосувань є дуже цінною, оскільки однією з часто зустрічаються проблем L2 є необхідність сплачувати величезні суми.
Отже, я отримав різні користувацькі програми та специфічні інтеграції. Це дійсно може знизити витрати, оскільки в багатьох випадках альтернативи зможуть безпосередньо читати вже існуючі копії програм, що стосується обробки даних. Це підходить для певних речей, але не підходить для тих, що потребують запису для когось.
Гаманець для зберігання ключів – це ще одна цікава ідея, чи не так? Ідея гаманця для зберігання ключів полягає в тому, що в нормальній мережевій безпеці ви хочете змінити ключ, ви не хочете, щоб ключ мав безмежний термін життя. Neo є частиною мети абстракції облікового запису, про яку я сьогодні говоритиму.
Але я вже неодноразово згадував, що, по суті, мова йде про створення облікових записів з будь-якою логікою, щоб ви могли виконувати деякі дії, наприклад, змінювати криптографічний алгоритм, змінювати ключі, робити їх більш стійкими і додавати snark так, як це робиться за допомогою методу відновлення. Тепер одним з викликів є те, що якщо ви можете змінити ключ, то у вас є сто результатів після змін. Тому вам потрібно змінити запис поточного ключа в 100 місцях.
Як ви вирішуєте цю проблему? Ми вирішуємо цю проблему, розміщуючи записи поточного ключа в центральному контракті. Потім ви отримуєте копії гаманців на кожному L2, просто читаючи L1. Це робить багато дуже розумних і дуже схожих практик сек'юризації безпеки більш реальними та практичними у світі L2.
Інша перевага полягає в тому, що це робить робочі процеси, що одночасно містять L2 та L1, для розробників простішими і природнішими. Ми говоримо не лише про теорію і купу повністю незалежних ланцюгів, ми насправді говоримо про те, що теорія L1 продовжує залишатися в основі користувацького досвіду застосунків і людей.
Третій крок – це доведення агрегування. Раніше я згадував, що якщо ми використовуватимемо цей підхід, заснований на двох або трьох методах, або в майбутньому, якщо ми проведемо дуже хорошу формалізацію перевірки, покладаючись лише на ZK, ми можемо скоротити час подання з 1 тижня до 1 години. Чому 1 година? Чому не 12 секунд? Є дві причини, які ми можемо вирішити. Перша причина – це вартість подання. Отже, подання доказу до L1 вимагає додаткових витрат, приблизно 500,000 gas, і вартість AA дуже висока.
Зараз, якщо уявити подачу довідки за кожен період, то в році 2,5 мільйона періодів. Це божевілля, що ми витрачаємо 27,5 мільйонів доларів на рік лише для того, щоб підтримувати відносну вартість. Ось хто хоче платити $27 млн на рік. Але якщо ви вкладаєте кожну хвилину, а не кожні 12 секунд, ці 27 мільйонів доларів на рік стануть 5,5 мільйонами доларів. Потім, якщо ви надсилаєте кожну годину, вона опускається нижче 100 000 доларів на рік. Насправді це можна контролювати. Таким природним рішенням є агрегація доказів.
Якщо у нас є велика кількість різних інструментів, то ці інструменти не обов'язково подавати різним групам окремо, ланцюгові докази можуть бути згруповані, групи можуть подати свої докази в сукупність, а потім агрегат може подати окремий SNARK, щоб довести існування інших SNARK. Вартість верифікації СНАРК становить лише одноразову вартість газу в 500 000 осіб. Те, що тут відбувається, в основному є тим, що зображено на цій діаграмі? Праворуч? По суті, у вас є купа доказів, і ці докази також вказують, який контракт. Ми в блоці. Тоді у вас є сукупний доказ. Сукупні докази перевіряються. Сукупна атестація містить всю інформацію одного агрегату як загальний вхід, а потім атестація відбувається лише один раз. Тоді цей контракт здійснюватиме лише один виклик на зведення, і єдине, що він робить, це для кожного зведення. Він просто завантажується окремо. Вартість одного візиту впала з 500 000 газу до менш ніж 10 000 газу.
Зараз є четвертий крок, а саме зменшити затримку підтвердження. Обчислення підтвердження займає більше часу та потребує більше обчислювальних потужностей, ніж виконання обчислень. За замовчуванням це обчислення не буде паралізовано. Вам потрібно його розширити, і вам потрібно виконати таке надзвичайно інтенсивне обчислення.
Отже, в результаті виходить, що в рівновазі блоку, генерація якого займає 5 секунд, все одно потрібно 500 секунд, щоб довести, чи не так? Це проблема. Тож питання в тому, як вирішити цю проблему? Є дві ідеї. Одна з них полягає в тому, що ми можемо покращити його за допомогою спеціального обладнання. Деякі компанії вже цим займаються. Якщо ви отримаєте 100-кратний коефіцієнт апаратного прискорення, то ви зможете довести це в режимі реального часу. Ще одна ідея – суперпаралізуючий доказ. Отже, з математичної точки зору, насправді все досить просто. По суті, ви розбиваєте розрахунок на кроки. Потім ви створюєте докази для кожного кроку окремо та окремо на різних пристроях.
Якщо цього ще недостатньо, то швидкість покращення спеціалізованого обладнання буде ще вищою. Водночас, витрати на покращення також будуть нижчими. Тож у нас є багато варіантів.
Якщо ви використовуєте Intensive Optimism та Arbitrum, обидва мають значно швидші часові слоти, ви також зможете завершити за 2 секунди. Отже, це буде дуже дешево. Тому, якщо ви використовуєте Intensive, ви зможете швидко переносити практично необмежену кількість ефіру за низькою вартістю. Це також означає, що ми можемо встановити більш тісні зв’язки між L1 та L2. Ми отримали більш інтегрований світ, в якому все стає легшим і швидшим для всіх. Дякую.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Vatilik：Чому потрібно прискорити швидкість підтвердження L2? Як прискорити?
Організація: П'ять чжус, Золоте фінансування
8 квітня 2025 року засновник Ethereum Віталік на саміті Web3 Scholar Summit 2025 виступить з основним доповіддю. Golden Finance підготував зміст доповіді наступним чином.
! c6IWD5wcjs585el116TgkbKAvbwA43Kqgzsvk4aS.jpeg
Зараз вихід з Optimism або Arbitrum потребує 1 тижня виходу, що викликає багато проблем.
Чому нам це важливо? Чому важливо швидше зв'язувати L2 та L1? Я вважаю, що є дві причини для мене. Одна з них — це досвід користувачів, ми хочемо, щоб у користувачів був кращий досвід, чекати 1 тиждень — це поганий досвід. Інша причина — це нам потрібна більш інтегрована екосистема. Нам потрібно зробити деякі речі, щоб справді покращити Optimism, Arbitrum, Polygon.
Ці частини світу Ethereum не є незалежними.
Наразі реалізація взаємодії між L1 та L2 є дуже швидкою, але вона потребує багато Gas. Ми дійсно почали звертати на це увагу з минулого літа. Два питання, які нас цікавлять, включають: специфічні адреси блокчейну та проекти намірів. Я сподіваюся, що перенести Optimism на Arbitrum не знадобиться тиждень часу, навіть я сподіваюся, що можна буде помістити Optimism у смарт-контракт.
У смарт-контракті, якщо будь-хто спочатку надає докази, що вони через контракт надіслали кошти на будь-яку адресу призначення, він автоматично переходить до цього етапу. Тому ми хочемо знайти відповідний спосіб якомога більше зменшити тижневий період очікування.
Чому ми зараз маємо тижневий вікно для виведення? Тому що Rollup Optimism потрібно чекати тиждень, щоб побачити, чи хтось оскаржує його хеш, і якщо ніхто не оскаржує, тоді ви можете прийняти хеш. Перевага Optimism полягає в тому, що технологія, на якій вона базується, є дуже обережною, але ціною є тижневий термін очікування.
Якщо ми не хочемо чекати 1 тиждень, тоді нам потрібно створити систему, яка може повністю використовувати не Optimism доказову систему для упаковки блоків, як поєднання ZK+TEE+OP — це наш запропонований дизайн.
! DgiWcMrcMkwxgOfjSfT9BcXQXFNajasojnfkTkPt.jpeg
За звичайних обставин, як тільки відбувається транзакція L2, статус буде завершено на L1 протягом години, скорочуючи 1 годину до 12 секунд, що, по суті, є лише питанням ефективності. Отже, це перша мета. Друга мета полягає в тому, що ми хочемо, щоб L2 не мав довіри. Ми хочемо довести, що система здатна визначати правильний стан і реєструвати стан помилки, навіть якщо компонент, якому потрібно довіряти, зламаний. Отже, сьогодні Rollups перебувають або в нульовій, або в першій фазі, а це означає, що вони покладають певний рівень довіри або всю свою довіру на якийсь комітет з безпеки. Ви повинні довіряти виробнику, щоб правильно їх розробити. Ви повинні вірити, що виробник не зберігає копію на самому ключі сайту.
! ncHxzOasQPGl1fjBSG8cycQLUYzCU1kQkjmpevq6.jpeg
І ви також повинні вірити, що апаратний механізм не є чимось, що може знищити будь-хто, хто має апаратуру, ви повинні вірити, що вони не можуть знайти способу, наприклад, лазера, інфрачервоного сканування обладнання, витягти інформацію без пошкодження зображення.
Зараз ми не хочемо покладати всю довіру на ZK.
Ви будете розподіляти довіру між трьома різними механізмами, які працюють за дуже різними логічними типами. Якщо ми маємо таку конструкцію, то ви зможете скоротити термін остаточного підтвердження з 1 тижня до 1 години. До речі, інший спосіб - це те, як я раніше бачив групову систему, я в основному ділив їх на дві категорії. Одна категорія - це довіра установ, а інша - це криптодовіра.
Інший вимір – швидкий і повільний. Швидкі речі можуть бути схвалені відразу, тоді як повільні речі потрібно почекати деякий час. Цікаво, що, як і чотири речі тут, це, по суті, 4 типи компонентів системи доказів, які люди використовують або думають у контексті L2, чи не так? Якби ми дійсно могли помістити їх у коробку, вони б помістилися рівно 2×2.
Перший крок, в основному, ми скорочуємо вікно для "диявольської прогулянки" з 1 тижня до 1 години. Що це вам дає? В основному це означає, що якщо ви використовуєте нативний міст для прямого переведення активів, ваш час очікування скорочено з 1 тижня до 1 години. Якщо ви використовуєте міст на основі наміру, то міст на основі наміру є миттєвим, але постачальники ліквідності не повинні чекати 1 годину, а повинні чекати 1 годину. Вартість надання ліквідності знизилася в 168 разів. Отже, витрати, які вам потрібно буде сплатити, знизяться до 168 разів.
L2s можуть використовувати lowlookahead для асинхронного читання L1. Це функція, яка вже є у L2, оскільки вони повинні мати можливість обробляти депозити. Ми використовуємо той самий стан, що й для читання депозитів, і надаємо його L1SLOADopcode. Підтримка читання даних L1, даних з оракулів, гаманців секретних ключів та багатьох інших застосувань є дуже цінною, оскільки однією з часто зустрічаються проблем L2 є необхідність сплачувати величезні суми.
! 4ZTnBOtkTIBfxYOBykB3r2sM9Y8960iNQpjEVHVb.jpeg
Отже, я отримав різні користувацькі програми та специфічні інтеграції. Це дійсно може знизити витрати, оскільки в багатьох випадках альтернативи зможуть безпосередньо читати вже існуючі копії програм, що стосується обробки даних. Це підходить для певних речей, але не підходить для тих, що потребують запису для когось.
Гаманець для зберігання ключів – це ще одна цікава ідея, чи не так? Ідея гаманця для зберігання ключів полягає в тому, що в нормальній мережевій безпеці ви хочете змінити ключ, ви не хочете, щоб ключ мав безмежний термін життя. Neo є частиною мети абстракції облікового запису, про яку я сьогодні говоритиму.
Але я вже неодноразово згадував, що, по суті, мова йде про створення облікових записів з будь-якою логікою, щоб ви могли виконувати деякі дії, наприклад, змінювати криптографічний алгоритм, змінювати ключі, робити їх більш стійкими і додавати snark так, як це робиться за допомогою методу відновлення. Тепер одним з викликів є те, що якщо ви можете змінити ключ, то у вас є сто результатів після змін. Тому вам потрібно змінити запис поточного ключа в 100 місцях.
Як ви вирішуєте цю проблему? Ми вирішуємо цю проблему, розміщуючи записи поточного ключа в центральному контракті. Потім ви отримуєте копії гаманців на кожному L2, просто читаючи L1. Це робить багато дуже розумних і дуже схожих практик сек'юризації безпеки більш реальними та практичними у світі L2.
Інша перевага полягає в тому, що це робить робочі процеси, що одночасно містять L2 та L1, для розробників простішими і природнішими. Ми говоримо не лише про теорію і купу повністю незалежних ланцюгів, ми насправді говоримо про те, що теорія L1 продовжує залишатися в основі користувацького досвіду застосунків і людей.
Третій крок – це доведення агрегування. Раніше я згадував, що якщо ми використовуватимемо цей підхід, заснований на двох або трьох методах, або в майбутньому, якщо ми проведемо дуже хорошу формалізацію перевірки, покладаючись лише на ZK, ми можемо скоротити час подання з 1 тижня до 1 години. Чому 1 година? Чому не 12 секунд? Є дві причини, які ми можемо вирішити. Перша причина – це вартість подання. Отже, подання доказу до L1 вимагає додаткових витрат, приблизно 500,000 gas, і вартість AA дуже висока.
Зараз, якщо уявити подачу довідки за кожен період, то в році 2,5 мільйона періодів. Це божевілля, що ми витрачаємо 27,5 мільйонів доларів на рік лише для того, щоб підтримувати відносну вартість. Ось хто хоче платити $27 млн на рік. Але якщо ви вкладаєте кожну хвилину, а не кожні 12 секунд, ці 27 мільйонів доларів на рік стануть 5,5 мільйонами доларів. Потім, якщо ви надсилаєте кожну годину, вона опускається нижче 100 000 доларів на рік. Насправді це можна контролювати. Таким природним рішенням є агрегація доказів.
! Rbld5A07Dvj7MocDpMKcbzb1tz923MsbGM7f3LBG.jpeg
Якщо у нас є велика кількість різних інструментів, то ці інструменти не обов'язково подавати різним групам окремо, ланцюгові докази можуть бути згруповані, групи можуть подати свої докази в сукупність, а потім агрегат може подати окремий SNARK, щоб довести існування інших SNARK. Вартість верифікації СНАРК становить лише одноразову вартість газу в 500 000 осіб. Те, що тут відбувається, в основному є тим, що зображено на цій діаграмі? Праворуч? По суті, у вас є купа доказів, і ці докази також вказують, який контракт. Ми в блоці. Тоді у вас є сукупний доказ. Сукупні докази перевіряються. Сукупна атестація містить всю інформацію одного агрегату як загальний вхід, а потім атестація відбувається лише один раз. Тоді цей контракт здійснюватиме лише один виклик на зведення, і єдине, що він робить, це для кожного зведення. Він просто завантажується окремо. Вартість одного візиту впала з 500 000 газу до менш ніж 10 000 газу.
Зараз є четвертий крок, а саме зменшити затримку підтвердження. Обчислення підтвердження займає більше часу та потребує більше обчислювальних потужностей, ніж виконання обчислень. За замовчуванням це обчислення не буде паралізовано. Вам потрібно його розширити, і вам потрібно виконати таке надзвичайно інтенсивне обчислення.
! VthFsqHrhyIZegJNNmzkb6wxoqmLsBlAMQL0Ttip.jpeg
Отже, в результаті виходить, що в рівновазі блоку, генерація якого займає 5 секунд, все одно потрібно 500 секунд, щоб довести, чи не так? Це проблема. Тож питання в тому, як вирішити цю проблему? Є дві ідеї. Одна з них полягає в тому, що ми можемо покращити його за допомогою спеціального обладнання. Деякі компанії вже цим займаються. Якщо ви отримаєте 100-кратний коефіцієнт апаратного прискорення, то ви зможете довести це в режимі реального часу. Ще одна ідея – суперпаралізуючий доказ. Отже, з математичної точки зору, насправді все досить просто. По суті, ви розбиваєте розрахунок на кроки. Потім ви створюєте докази для кожного кроку окремо та окремо на різних пристроях.
Якщо цього ще недостатньо, то швидкість покращення спеціалізованого обладнання буде ще вищою. Водночас, витрати на покращення також будуть нижчими. Тож у нас є багато варіантів.
Якщо ви використовуєте Intensive Optimism та Arbitrum, обидва мають значно швидші часові слоти, ви також зможете завершити за 2 секунди. Отже, це буде дуже дешево. Тому, якщо ви використовуєте Intensive, ви зможете швидко переносити практично необмежену кількість ефіру за низькою вартістю. Це також означає, що ми можемо встановити більш тісні зв’язки між L1 та L2. Ми отримали більш інтегрований світ, в якому все стає легшим і швидшим для всіх. Дякую.