Коли ми подивимося на бачення та дорожню карту різних зведених рішень, ми виявимо, що майже всі зведені мають кінцеву мету. Якщо цю мету стиснути в одне речення: створити стек технологій, надати його спільноті, вирішити розширення блокчейн і, зрештою, децентралізація технологічного стеку операцій і управління. Це призводить до терміну децентралізоване зведення.
Тож що таке децентралізація? Який розподіл праці між різними частинами системи Rollup? Чи означає децентралізація максимізацію учасників роботи системи? Який вплив матиме централізований сортувальник? Як має бути розроблений спільний упорядник і локальний консенсус L2? Яка функція унікального прувера в ZK-Rollup? Як би виглядала відкрита децентралізована мережа перевірки? Навіщо нам апаратне прискорення zk? Яке вирішення проблеми доступності даних? ....
У спільноті ведуться нескінченні дискусії навколо децентралізованого зведення, тому ECN підготував серію подкастів-інтерв’ю на тему «Децентралізований зведений пакет» і запросив видатних засновників і дослідників у цій галузі поговорити про своє розуміння децентралізованого зведення.
У міру того, як на платформу рівня 2 надходить все більше і більше ліквідності, з’являється все більше постачальників послуг згортання, не лише універсальні рішення для зведення, ланцюжки зведення для окремих програм, а й платформи зведення як послуга. Тому все більше і більше людей стурбовані тим, що дуже важлива роль «секвенсера» майже в усіх зведених досі централізована. Які ризики централізованого сортувальника? Децентралізований сортувальник – термінова робота?
**У другому епізоді ми запросили Яоці Цзя, засновника AltLayer Network, Тогрула Магеррамова, дослідника Scroll, і Абдельхаміда Бахту, керівника дослідження Starknet, провести круглий стіл на тему децентралізованих сортувальників, щоб аудиторія та читачі може зрозуміти поточний прогрес і дилеми децентралізованих сортувальників. **
Гості випуску:
Яоці Цзя, засновник AltLayer Network, twitter @jiayaoqi
Дослідник сувоїв Тогрул Магеррамов, твіттер @toghrulmaharram
Керівник дослідження Starknet Абдельхамід Бахта, twitter @dimahledba
Минуле
Проблема 1. Як децентралізувати зведений пакет?
Дослідник Arbitrum Патрік Маккоррі
Попередній перегляд
Проблема 3: Прискорення мережі прувера та апаратного забезпечення zk
Є Чжан, співзасновник Scroll
Лео Фан, співзасновник Cysic
Проблема 4: Доступність даних і децентралізоване зберігання
Ци Чжоу, засновник EthStorage
Слухай
Натисніть, щоб підписатися на подкаст, щоб дізнатися більше:
Youtube:
Мікросвіт:
штамп часу
00:49 Яоці представляється
01:37 Абдельхамід представляється
02:50 Тогрул представляється
04:03 Роль сортувальника в rollup
08:37 Децентралізований замовник: покращення взаємодії з користувачем і вирішення проблем живучості та цензури
19:43 Як Starknet децентралізує сортувальник
22:59 Як Scroll децентралізує сортувальник
26:34 Різниця між консенсусом L2 в контексті Optimistic rollup і zkRollup
32:28 zkRollup децентралізує сортувальник, а також потребує врахування перевірки
36:01 Що таке зведення на основі?
40:53 Недоліки спільного секвенсора та базованого зведення та сценарії їх застосування
49:02 Який вплив матиме децентралізований замовник на MEV?
Представлення гостей
Яоці
Я засновник AltLayer. AltLayer створює платформу «Зведення як послуга», де розробники просто натискають деякі кнопки та налаштовують параметри. Використовуючи нашу панель запуску або панель керування, вони можуть швидко запускати зведення для певної програми за лічені хвилини. Ось що ми зараз намагаємося зробити, щоб надати розробникам загальне середовище виконання та функціональність. Ми також пропонуємо кілька секвенсорів, кілька систем віртуальних машин і різноманітні системи доказів для розробників на вибір.
Абдельхамід
Я працюю в Starkware і очолюю дослідницьку групу. Метою цієї групи є, в основному, запуск проектів з відкритим кодом, схожих на дослідження, але з інженерною спрямованістю. Наша мета — працювати над проектами з відкритим кодом у тісній співпраці з громадою та людьми з інших екосистем. Одним із таких проектів є Madara, який насправді є сортувальником Starknet. Це не лише кандидат у загальнодоступну мережу Starknet, а й секвенсор для ланцюжка додатків Starknet і Layer3. Це також пов’язано з тим, що сказав попередній гість, ми також думаємо про надання зведення як сервісної функції, люди можуть розгортати свій ланцюжок додатків Starknet і вибирати різні рішення щодо доступності даних дещо модульним способом. До цього я чотири роки працював розробником ядра Ethereum, в основному відповідаючи за роботу EIP-1559.
Вибір
Я дослідник у Scroll, і мої основні обов’язки в Scroll – це розробка протоколів, розробка мостів, децентралізація, стимули тощо. Тож коли я не пишу в Твіттері, більшу частину часу я просто працюю над тим, як децентралізувати протокол або замовників, перевірників тощо. Подібно до Starkware, одна з речей, над якою ми працюємо, це зведений SDK. Таким чином, ви можете випустити зведення на основі Scroll і модульно використовувати різні параметри доступності даних тощо. Ми все ще розглядаємо варіант, згідно з яким зведені пакети на основі Scroll SDK можуть використовувати сортувальник Scroll, щоб допомогти досягти децентралізації, не вимагаючи, щоб кожне зведене обробляло децентралізацію самостійно. Звісно, план ще не остаточно розроблений. Але це також той напрямок, над яким ми працюємо.
Розділ інтерв'ю
тема перша
Поясніть сортувальник зведення?
Абдельхамід
Сортувальник є дуже важливим компонентом в архітектурі layer2, цей компонент отримує транзакції від користувачів, потім пакує та групує їх у блоки, виконує транзакції тощо. Це дуже важливо, оскільки це компонент, який відповідає за створення блоків, оскільки рівень 2 також є блокчейном із блоками транзакцій. Замовники створюють ці блоки, а перевіряючі підтверджують ці блоки.
Яоці
Як зазначив Абдель, замовник — це комбінація багатьох функцій у блокчейні. Тож ми можемо фактично покласти на замовника занадто багато відповідальності порівняно з типовим публічним блокчейном. Спочатку потрібно звести всі транзакції від користувачів, а потім відсортувати ці транзакції за ціною на газ або за принципом «першим прийшов, першим обслужено». Після цього секвенсор повинен виконати ці транзакції. Як і зараз, деякі Layer2 використовують EVM (Starware має іншу віртуальну машину), але в основному секвенсору потрібна спеціальна віртуальна машина для виконання транзакцій і генерування стану. Потім транзакція досягає етапу попереднього підтвердження, що означає, що якщо ви бачите час підтвердження в одну-дві секунди або навіть підсекунди, це в основному стан попереднього підтвердження, завершений секвенсором. Потім для більшості сортувальників їм також потрібно завантажити або опублікувати контрольні точки чи хеші стану в L1. Це підтвердження на рівні L1, який ми називаємо доступністю даних. Отже, сортувальник насправді має багато ролей у системі зведення. Але загалом я вважаю, що це найважливіший компонент системи згортання.
** Тема 2 **
Чому децентралізований сортувальник важливий? Якщо ми використовуємо централізований сортувальник, які приховані небезпеки для користувачів і системи?
Вибір
Перш за все, нам потрібно знати, що, за винятком Fuel V1 на поточному етапі, немає справжнього зведення, тому що інші зведення все ще мають тренувальні колеса.
Однак ми можемо сказати, що як тільки його класифікують як зведення, це означає, що мультипідпис видалено тощо. Тоді проблема децентралізації сортувальника стає проблемою взаємодії з користувачем, а не проблемою безпеки. Отже, коли люди говорять про, скажімо, децентралізацію L1, проблема зовсім інша. Тому що L1 має давати гарантії на замовлення та легких клієнтів. Отже, якщо легкий клієнт хоче перевірити правильність стану, він повинен довіряти валідаторам L1. Для зведення це не так. Оскільки сортувальник забезпечує лише тимчасове сортування, яке потім завершується L1. І оскільки зведені версії також гарантовано стійкі до цензури, нам не потрібна децентралізація, щоб це сталося.
Отже, є кілька причин, чому вам потрібен децентралізований сортувальник. По-перше, якщо, скажімо, завершення L1 відбувається повільно (або через те, що надіслані вами докази дійсності надто повільні, або через механізм перевірки періоду оптимістичних зведених доказів шахрайства), ви повинні покладатися на щось, щоб отримати швидке підтвердження транзакції. На цьому етапі швидкого підтвердження, хоча ви можете бути впевнені, що Starkware або Scroll не обдурять вас, вони вказують, що після підтвердження блоку реорганізації не буде. Це припущення про довіру. А децентралізація може додати якісь економічні гарантії тощо.
Але виходячи з цього, зведення також не має гарантії остаточності в реальному часі. По суті, ви можете примусово упаковувати транзакцію через L1, але для упаковки цієї транзакції потрібні години. Так, наприклад, якщо є оракул, відповідальний за оновлення, і час коливається, то, в основному, якщо оракул оновлюється протягом години або більше, програми в зведеному пакеті будуть недоступні. По суті, децентралізація дозволяє нам надати деякі сильніші гарантії стійкості до цензури в реальному часі, тому що тоді зловмиснику потрібно буде скомпрометувати не лише одну сутність або декілька організацій, а всю мережу замовників.
Тож для нас децентралізація — це радше рішення для покращення взаємодії з користувачем або виправлення кутового випадку оновлень Oracle тощо. Замість того, щоб надавати базові гарантії безпеки, це робить L1.
Абдельхамід
Так, питання про децентралізований сортувальник, яке ви згадали, не зовсім те саме, що децентралізований L1, який, на мою думку, є дуже важливим. Тому що коли ми бачимо, як деякі L1 критикують централізовані сортувальники, вони не розглядають належним чином компроміси, які роблять централізовані сортувальники.
На цій основі я хотів би додати щось, що стосується досвіду користувача, пов’язане з діяльністю. Тому що, коли у вас є лише один сортувальник, у вас більший ризик його збою. Таким чином, децентралізований замовник також підвищує стійкість і живучість мережі. Але навіть у централізованому контексті ми маємо хорошу безпеку, коли мова йде про безпеку. Тому що коли ви можете примусово здійснювати пакетні транзакції через L1, різниця між ними полягає лише в часовій шкалі. А наявність децентралізованого сортувальника дозволяє отримати швидкі гарантії, стійкі до цензури, як зазначив Тогрул. Тож я лише хочу додати, що для життя також важливо мати децентралізовану мережу замовників.
Яоці
Я хотів би дещо додати. Діяльність, мабуть, найважливіше, що нам потрібно враховувати на цьому етапі. В останніх випадках аірдропу на найпопулярніших L2, таких як Optimism і Arbitrum, спостерігався період простою. Тому я думаю, що нам потрібно вирішити, як обробляти тисячі запитів на транзакції в секунду, коли у нас є лише один сортувальник. Навіть теоретично, якщо у вас є лише один вузол, він не може обробляти стільки запитів одночасно. Отже, що стосується живучості, нам точно потрібні кілька сортувальників. Єдина точка відмови є справжньою перешкодою не лише для Web3, навіть Web2 є великою проблемою.
Крім цього, є питання цензури. Якщо у нас є лише один координатор, навіть якщо ми бачимо, що ним може керувати команда, вам все одно потрібно довести, що команда насправді не переглядатиме транзакції. Іноді зловмисники можуть додати певні транзакції до чорного списку. Це децентралізована система замовників, вони також можуть спробувати відправити транзакції через інших замовників. Ось чому останнім часом ми отримуємо багато критики щодо окремих сортувальників.
Окрім цього, є деякі інші проблеми, такі як MEV і ранні запуски. У системі з централізованими сортувальниками, особливо для протоколів DeFi, вони могли б легко перевірити mempool. Ймовірно, не у формі лідера, але вони мають більше шансів зупинити торгівлю та арбітражувати її.
Багато з цих проблем з різних причин, хоча ми бачимо, що L2 дуже відрізняється від L1. Але зрештою нам все одно потрібно зробити його максимально децентралізованим. Тому нам доводиться стикатися з деякими подібними проблемами, які ми маємо з публічними блокчейнами або L1.
Абдельхамід
Так, я згоден, що децентралізований сортувальник важливий. Але я також хочу сказати, що, як ми всі знаємо, це непросте питання.
Крім того, **оскільки зведення мають дуже специфічну архітектуру з кількома сутностями. Ми говоримо про єдиний замовник, але також є перевірка, і нам потрібно децентралізувати обидва. **Будуть певні компроміси та певні труднощі в тому, як оцінювати транзакції, оскільки для роботи мережі потрібні різні фактори. Отже, як ви оцінюєте угоду? Сортувальник і прувер мають різні вимоги до апаратного забезпечення, пруверу потрібна надпотужна машина тощо. Тому ціноутворення в децентралізованому світі також є дуже складною проблемою, тому нам потрібен час, щоб повільно рухатися вперед.
Отже, ми всі зіткнемося з таким компромісом.Якщо ми хочемо швидко децентралізуватися, нам, можливо, доведеться взяти деякі навчальні колеса та поступово децентралізуватись, тому що якщо ми безпосередньо хочемо ідеальної архітектури, це займе кілька років. Тому я думаю, що ми підійдемо прагматично і спробуємо поступово децентралізуватись. Принаймні це наш поточний план, як, можливо, почати з простого механізму консенсусу BFT, а потім додати інший механізм консенсусу в короткостроковій перспективі чи щось подібне. Тому я просто хочу сказати, що це непросте питання. Оскільки, очевидно, існує компроміс між швидкістю розробки та застосовністю архітектури до децентралізованого середовища.
Тема 3
Як децентралізувати сортувальник?
Абдельхамід
Є багато функцій, які ми хочемо децентралізувати, і всі вони мають різні компроміси.
Наприклад, при децентралізації ви хочете запровадити якийсь механізм консенсусу. Однак у механізмі консенсусу є кілька частин. Перший — це вибори лідера, тобто як вибрати, хто буде створювати блоки, хто буде замовником, відповідальним за створення блоків у певному слоті або протягом певного часу. **Команда Starknet планує максимально використовувати рівень 1. Тобто в нашому алгоритмі виборів лідера ми хочемо зробити ставку на рівень 1. Наприклад, у нас є токени, а застава буде відбуватися на смарт-контракті Ethereum рівня 1, який використовується для визначення механізму обрання лідера. **Це означає, що нам потрібна певна взаємодія, під час якої замовник L2 запитуватиме смарт-контракт Ethereum, щоб знати, хто буде наступним лідером чи щось подібне. Отже, очевидно, потрібна якась випадковість та інші речі. Тож це не просте запитання. Але це перша частина. Тоді потрібно мати механізм самого консенсусу. Є кілька варіантів: або найдовший ланцюговий механізм, або BFT, або гібрид обох. Як і Ethereum, він має LMG Ghost і Casper FFG для остаточного завершення.
Тож ми можемо прийняти прагматичний підхід і почати спочатку з BFT. чому? Коли рівень 2 розглядає децентралізацію, наша мета полягає не в тому, щоб мати такий великий сортувальник, як рівень 1. Наприклад, на Ethereum метою є участь мільйонів валідаторів. У цьому випадку ви не можете просто використовувати механізм BFT, тому що він буде дуже поганим за ефективністю, і це створить дуже великі проблеми. Наприклад, якщо є проблема в мережі Bitcoin, якщо це механізм BFT, ланцюжок повністю зупиниться. Але це не так, мережа Bitcoin продовжує створювати блоки, атакується лише механізм остаточності.
Але на рівні 2, якщо метою є від кількох сотень до 1000 сортувальників, було б добре почати з механізму BFT. Отже, у нас є механізм виборів лідера, потім консенсус, а потім є ще дві частини, але я залишу це для інших гостей, щоб вони продовжували додавати. Але дві інші частини — це оновлення стану та створення доказів.
Вибір
По-перше, у L2 децентралізація є багатогранною проблемою, як описано Абделем. Особливо в zkRollup, оскільки є перевіряльники та замовники, вам потрібно координувати роботу між ними, вам потрібно децентралізувати обох. Ця проблема повністю відрізняється від L1.
Інша відмінність полягає в тому, що в L2 весь ваш проект полягає в тому, щоб переконати базовий міст у правильності консенсусу, а не в тому, щоб переконати будь-яку кількість інших вузлів. Ви, очевидно, повинні зробити те саме, але вашою головною увагою має бути сам міст.
Зараз ми працюємо у двох різних напрямках. Номер один, я думаю, як і всі інші, ми працюємо над протоколом BFT. Це не дуже ефективно, і є деякі переломи, які потрібно усунути. Ми знайшли приблизне рішення, але воно все одно не є оптимальним. Наприклад, одне із запитань полягає в тому, як ви збалансовуєте стимули між сортувальниками та перевіряльниками? Оскільки замовник контролює MEV, а перевірка не має доступу до MEV, є стимул для людей запускати замовник замість перевірки. Але насправді нам потрібно більше перевіряючих, ніж замовників, тож як збалансувати стимули між ними? Це одна з тих проблем.
Друге рішення, над яким ми працюємо, – інший напрямок. Пам’ятайте, що все може змінитися. Щодня з’являються нові пропозиції. Наприклад, останнім часом було багато розмов про зведення на основі баз і про те, як ви можете повністю передати сортування L1. Другий напрямок полягає в тому, щоб повністю відмовитися від сортувальника та використовувати зовнішній конструктор. Наприклад, конструктори ethereum або Flashbots SUAVE тощо пропонують упорядковані блоки, а потім запускають консенсус у перевірці. Перевагою тут є те, що вам не потрібно мати справу зі стимулами, оскільки в основному ви можете використовувати PBS у протоколі, і це створює простіший протокол. Але недоліком є те, що оскільки нам потрібна велика кількість пруверів (оскільки ми можемо доводити паралельно), з ними досить важко запустити класичний протокол BFT. Отже, питання полягає в тому, як оптимізувати існуючий протокол BFT для роботи з сотнями або навіть тисячами пруверів? І на це запитання непросто відповісти.
Чи потрібне запровадження консенсусу L2 для децентралізованого замовника?
Яоці
Я можу приблизно відповісти на це питання, тому що нещодавно ми випустили щось подібне.
Тож чи запроваджувати консенсус не залежить від того, хочемо ми цього чи ні. Якщо у вас є багато замовників або навіть лише вузли, ви повинні змусити їх погодитися. Це дійсно залежить від ваших припущень. Якщо це візантійське припущення, ми можемо використовувати BFT або будь-який існуючий візантійський консенсусний протокол. Наприклад, якщо це не візантійська установка, якщо ми просто припустимо, що вузол може бути лише онлайн і офлайн, і що він не може діяти зловмисно, тоді ми можемо використовувати протокол Raft або якийсь інший швидший протокол консенсусу. Але в будь-якому випадку, якщо у нас є група замовників або перевірників, якщо ми хочемо організувати їх разом, щоб виробляти блоки протягом певного періоду часу, тоді ви повинні мати консенсусний протокол навколо них.
Тож, як щойно згадали Тогрул і Абдель, я вважаю, що є багато пропозицій і тем для дослідження щодо того, як ми можемо запровадити децентралізовану систему впорядкування чи перевірки. Отже, оскільки ми щойно запустили тестову мережу для зведеної системи з кількома сортувальниками (наразі підтримує лише докази шахрайства для оптимістичних зведених даних), ґрунтуючись на нашому досвіді розробки та впровадження, я можу поділитися деякими речами щодо труднощів. Як щойно згадав Тогрул, складність полягає не в самому консенсусному протоколі. Справжня складність полягає в інших речах, таких як частина доказів. Тому що, якщо це один сортувальник, вам не потрібно багато вузлів. Ми можемо розглядати це як EVM, віртуальну машину. Отже, просто вибирайте транзакції та виконуйте їх, виконуйте переходи між станами. Підтверджувач відповідає за створення доказів для переходу стану попереднього набору транзакцій. Однак, якщо ми запустимо консенсус-протокол для сортувальника та перевірки під час зведення, то нам потрібно буде ввести туди додаткову консенсусну логіку. Окрім цього, вам також потрібна система перевірки протоколу консенсусу. Таким чином, це призведе до великої роботи для створення системи доказів. Після того як ви згенеруєте доказ, ви зможете легко перевірити його на L1 Ethereum.
Ось чому, у певному сенсі, коли ми запустили першу тестову мережу з кількома замовленнями, оптимістичне зведення мало певні переваги в цьому плані. Загалом, ви можете спростити багато речей, наприклад, не брати до уваги частину підтвердження дійсності. Як і ми, ми в основному порівнюємо все з WASM. Отже, зрештою, це інструкція WASM. Отже, перевіривши ці інструкції WASM, це відносно легко перевірити за допомогою коду Solidity. Якби ми просто повторно реалізували всі інтерпретації інструкцій WASM на Ethereum.
Але загалом проблема не поодинока. Якщо у нас є вирішення проблеми, то, відповідно, буде ще якась подальша робота, яку потрібно вирішити одночасно. Звичайно, будуть питання MEV, наприклад, як ми справедливо розподіляємо MEV. Ви можете призначити всіх замовників і перевірників залежно від того, створили вони блок чи перевірили блок. Але врешті-решт це насправді поєднання багатьох проблем, не лише технічних, а й економічних стимулів.
І ми повинні пам’ятати, що L2 пропонується, тому що ми хочемо значно знизити вартість газу. Тому ми не можемо мати стільки вузлів. Навіть у створенні доказів L2 може бути дорожчим за L1. Тож нам справді потрібно знайти збалансований підхід до такого роду проблем.
Абдельхамід
Я хотів би додати ще один момент. По-перше, наразі немає фактичних доказів шахрайства без дозволу для оптимістичних зведених пакетів. І я продовжую наголошувати на цьому при кожній нагоді, тому що під час порівняння важливо бути чесним. Отже, вони зовсім не L2. Це перше.
Потім я хотів би додати дещо про асинхронність між сортуванням і доказами, оскільки це дуже важливо. Як ви сказали, ми хочемо оптимізувати сортування, оскільки зараз це вузьке місце для всіх рішень. Але це добре в контексті централізованого сортування, тому що ми знаємо, що сортувальник вироблятиме лише переходи значень, і ми зможемо їх перевірити. Але це буде складніше в контексті децентралізованого сортування, тому що, можливо, ваш сортувальник зможе створити щось, що неможливо перевірити. Тоді вам доведеться розібратися з цим пізніше.
У контексті централізованого сортування, щоб оптимізувати сортування, оскільки нам не потрібно генерувати докази під час процесу сортування, ми можемо спробувати зробити це з локальною швидкістю, що ми і хочемо зробити. Перекладіть Cairo на машинну мову низького рівня, як-от LLVM, і надшвидко запустіть сортувальник. Тоді ви можете довести асинхронно. І найкрутіше в доказах те, що ви можете робити їх паралельно. Масова паралелізованість досягається шляхом доведення того, що рекурсія можлива. Тому ми зможемо наздогнати швидкість сортувальника. Але при децентралізації це складно, тому що нам потрібно переконатися, що замовник створює лише дійсні переходи станів.
Вибір
Додам, що я не впевнений, що тут робить Starknet. Але для нас, я думаю, загальним припущенням кожного zkRollup є те, що якщо ви децентралізуєте сортувальник, ваша система перевірки повинна мати можливість обробляти недійсні пакети. Отже, якщо, скажімо, ви надсилаєте пакет із недійсним підписом, ви повинні бути в змозі довести, що отриманий стан еквівалентний початковому. Тож у будь-якому випадку будуть певні накладні витрати. Йдеться про те, як мінімізувати ймовірність цього.
Абдельхамід
Так, правильно. Ось чому ми представили Sierra в Cairo 1, щоб усе можна було перевірити. Це проміжне представлення гарантує, що кожну програму Cairo 1 можна перевірити, щоб ми могли включити транзакцію повернення.
Що таке зведення на основі?
Яоці
Основне зведення спочатку було отримано з публікації в блозі Джастіна Дрейка на форумах Ethereum. Одна з його ідей полягає в тому, що ми можемо повторно використовувати деякі верифікатори Ethereum для перевірки транзакцій зведення, щоб нам не потрібна окрема група вузлів для перевірки різних транзакцій зведення. Зокрема, у майбутньому ми матимемо багато зведених пакетів, у тому числі загального призначення та багато зведених програм для окремих програм. Отже, у цьому випадку було б чудово, якби ми могли знайти спільне місце, як-от пул валідаторів Ethereum, для перевірки цих транзакцій.
Звісно, це лише ідея, оскільки вона також створює багато технічних труднощів. Наприклад, теоретично ми могли б вимагати валідаторів Ethereum для перевірки зведених транзакцій, але дуже важко отримати логіку перевірки зведених транзакцій у пакеті або вбудованих у сам протокол Ethereum. Ми називаємо це внутрішньопротокольною перевіркою, яка вимагає хардфорка вузлів Ethereum. Звичайно, у цьому випадку ми можемо перевірити деякі зведені транзакції. Але якщо ми це зробимо, ви побачите проблеми. Це трохи схоже на те, що ми хочемо, щоб зведення L2 розділило тиск Ethereum, але зрештою ми все одно просимо валідаторів Ethereum взяти на себе частину роботи, покладеної на L2. Тому багато людей говорять про те, як ми можемо це зробити.
Потім ми поговорили з Барнабі, дослідником з Ethereum Foundation, який зараз працює над PBS. Це пропозиція Ethereum, яка полягає в тому, щоб розділити завдання валідаторів на кілька ролей, розробників і пропонентів. Тепер у нас є Flashbots, які виконують роль конструкторів у PBS, вони створюють усі блоки та надсилають їх розробникам Ethereum. Отже, коли ці блоки будуть упаковані в мережу Ethereum, розробники також отримають певні винагороди. Тоді як у цьому випадку винагородити ці валідатори з мережі Ethereum? Вони також відповідають за перевірку зведених даних.
Одним із рішень є «переставлення», про яке ви, можливо, багато чули від EigenLayer або деяких інших протоколів. Користувачі можуть переставити ETH на інші мережі сортування. Або винагороджуйте валідаторів Ethereum за фактичний запуск програмного забезпечення для виконання перевірки для зведення. У цьому випадку вони можуть отримати винагороду як з L2, так і через протокол рестейкінгу. Наразі було багато пропозицій щодо цього, але загалом це ідея того, як перепрофілювати існуючі валідатори Ethereum. Як ми можемо повторно використовувати існуючий ETH, щоб розпочати нову еру зведених систем або систем L2? Таким чином, це в основному спроба спростити багато речей для зведеного проекту. Якщо зведенню потрібен новий сортувальник, якщо їм потрібне нове джерело забезпечення, вони можуть повторно використовувати існуючу інфраструктуру чи наявне забезпечення. Ось чому його створено на основі Ethereum, а потім подальшу інфраструктуру та стейкинг можна повторно використовувати для зведення та L2.
Недоліки спільного секвенсора та базового зведення та сценарії їх застосування.
Вибір
Я хочу поскаржитися на цю пропозицію, мене не переконала пропозиція, пов’язана зі спільним секвенсором. Звичайно, вони все ще знаходяться в зародковому стані, і якщо ці проекти покращаться в майбутньому, цілком можливо, що я підтримаю їх. Просто нинішня форма мене не переконує. Є багато причин.
По-перше, для мене основна цінність спільного сортувальника полягає в тому, щоб дозволити користувачам отримати атомарну компонування між зведеними продуктами загального призначення, такими як Scroll або Starknet. Але проблема полягає в тому, що якщо у вас є атомарна компонування, то ваш зведення є таким же остаточним, як і найповільніше зведення, з яким ви об’єднуєте. Отже, якщо припустити, що Scroll об’єднано з Optimistic Rollup, кінцевий термін дії Scroll складатиме сім днів. Хоча головною цінністю ZKRollup є досягнення відносно швидкого завершення, користувачі можуть вийти на L1 протягом декількох хвилин. І в цьому випадку взагалі відмовтеся від цього.
Іншим недоліком є те, що якщо ви хочете отримати остаточність поза ланцюгом, вам потрібно запустити вузол L2, і якщо дані, надіслані в ланцюжок, завершуються L1, ви отримуєте остаточність локально в L2. Якщо кожен комбінований L2 не запускає повний вузол, практично неможливо досягти локальної фіналізації. Це означає, що запуск цієї системи може бути дорожчим, ніж запуск такої системи, як Solana, оскільки у вас є кілька повних вузлів, що працюють одночасно, з власними накладними витратами тощо.
Тому з цих причин я просто не думаю, що це має сенс для L2. Це трохи інше для L3, тому що якщо хтось хоче побудувати ланцюжок для конкретної програми і не хоче мати справу з децентралізацією. Скажімо, я створюю гру, і я просто хочу мати справу зі створенням гри, тоді я можу аутсорсингувати децентралізовану роботу. Але я не думаю, що це має сенс для L2 на даний момент.
Щодо базованого зведення, я також маю свої занепокоєння. Наприклад, як ви розподіляєте прибуток від MEV між перевіряючими? Оскільки, якщо не розглядати проблему розподілу, L1 може отримати весь прибуток від MEV. Інша дрібниця полягає в тому, що його час підтвердження дорівнює часу підтвердження L1, який становить 12 хвилин, що не може бути швидше. Інша проблема полягає в тому, що оскільки він не має дозволу, кілька шукачів можуть надсилати пакети транзакцій одночасно, що означає, що результати можуть бути централізованими. Оскільки розробники заохочуються включати свої транзакції, якщо один шукач підключається легше, ніж інші. Тому це може призвести до того, що зрештою лише один Шукач запропонує партії для L2, що є не дуже хорошим рішенням, тому що якщо це станеться, ми фактично повернемося до початку.
Яоці
Цікаво, що минулого тижня у мене був телефонний дзвінок із Беном, засновником Espresso. Ми багато обговорюємо це в темі спільних сортувальників. Як згадав Тогрул, я думаю, що є певна невизначеність щодо сценаріїв використання спільної системи замовлення. Це головним чином тому, що для загального призначення L2 ми зазвичай не маємо великої кількості сортувальників через ефективність, складність та економічність. І я досі вважаю, що найкращим варіантом використання є здебільшого RAS (зведення як послуга) або такі платформи, де ми можемо розгорнути багато зведень, незалежно від того, чи йдеться про спільний секвенсор, зведення на основі чи повторне виконання. Чесно кажучи, нам не потрібна велика мережа сортування, якщо зведень небагато. Ці збірки вже мають власні системи сортування та власні спільноти чи партнерів, хоча є лише деякі загальні L2. Їм насправді не потрібна окрема та стороння мережа. Крім того, це тягар для сторонньої мережі, тому що вам потрібно налаштувати для кожного L2, і кожен L2 має інший тестовий стек. Це вимагає багато змін у вашій власній мережі.
Але в той же час, як згадав Тогрул, для деяких особливих випадків використання. Наприклад, якщо ми хочемо мати певну сумісність на рівні сортувальника, спільні сортувальники можуть бути потенційним шляхом. Наприклад, той самий сортувальник використовується для кількох зведень. У цьому випадку цей сортувальник може в основному обробляти деякі транзакції перехресного зведення, щоб забезпечити атомарність між ланцюжками між зведенням A, B і C.
Але ви також можете побачити проблему тут, коли я описую ситуацію. Якби ми справді мали багато цих спільних секвенсорів, вони знову стали б вузьким місцем і новою єдиною точкою відмови. Ми надаємо занадто багато повноважень цим так званим спільним замовникам. Вони стають більше схожими на мережу, контролюючи багато зведень. Нарешті, нам знову потрібно придумати спосіб децентралізації цього спільного сортувальника.
Але в будь-якому випадку, я вважаю, що це добре, що люди поступово виявляють все більше проблем і придумують все більше рішень. Загалом, цікаво спостерігати щодня за новинками в цій галузі. Завдяки всім цим новим рішенням ми принаймні на правильному шляху до справжньої децентралізації всього простору згортання.
Абдель
Так, я згоден з вами обома. Я вважаю, що це має більше сенсу для Layer3 і Lisk, оскільки вони більше не хочуть брати на себе відповідальність за стимулювання децентралізованої мережі, і їм потрібно знайти партнерів, щоб розпочати такі речі, як сортувальники. Тому я думаю, що для Ліска це має сенс. Але, як і Тогрул, я не думаю, що це має сенс для Layer2.
Тема 4
Який вплив матиме децентралізований замовник на MEV?
Абдель
Для Starknet, у контексті централізації, ми не робимо жодного типу MEV, а приймаємо модель «першим прийшов, першим обслужено». Тобто в контексті децентралізації, звісно, більше МЕВ буде запроваджено пізніше. Але ще занадто рано говорити про співвідношення, оскільки це також залежить від конструкції механізму консенсусу та інших аспектів.
Вибір
Але справа в тому, що навіть якщо ви не робите MEV, деякі MEV все ще можуть відбуватися в Starknet. Сама по собі децентралізація насправді не зменшує чи збільшує MEV. Звичайно, якщо ви застосовуєте, наприклад, якийсь протокол чесного впорядкування або порогове шифрування, тоді так, ви мінімізуєте MEV. Але повністю виключити його не можна. Моя філософія така: MEV неможливо усунути. Але припустімо, що ви просто створюєте консенсус BFT або будуєте щось на основі консенсусу BFT. Насправді це взагалі не впливає на MEV. MEV все ще існує, це має бути питання про те, як шукач працює з сортувальником, щоб отримати цей MEV.
Яоці
Проблема в тому, що навіть модель «перший прийшов, перший обслужений» має складні частини. Після того, як ми відкриваємо мемпул деяким шукачам, вони все одно матимуть перевагу грати більше. Наприклад, для секвенсорів вони еквівалентні очікуванню біля дверей офісу. Тож у цьому випадку, як тільки вони бачать якусь можливість арбітражу, а не лише про фронт-ранінг або сендвіч-атаку, щойно користувач надсилає транзакцію, він одразу може побачити це в mempool. Таким чином, вони можуть швидко розмістити свої операції попереду інших. Отже, вони мають перевагу над іншими пошукачами.
Але повертаючись до децентралізації, я думаю, що це здебільшого спротив цензури, як ми обговорювали на початку. Секвенсорами керує команда. Команда може сказати, що вони справедливі до всіх. Але це не заборонено в коді. Отже, якби ми могли мати мережу P2P, було б чудово, якби ми відчували, що ці вузли перевіряють мої транзакції, а потім ми зможемо надсилати на інші вузли. Отже, справді йдеться про чесність обробки транзакцій на L2.
Що стосується MEV, тому що останнім часом, окрім MEV, створених в рамках одного зведення, є деякі MEV, створені через мости. У цій відносно децентралізованій мережі сортування ви матимете більше можливостей для отримання MEV. Якщо припустити, що у нас є спільна мережа замовлень, то якщо ви можете якимось чином вплинути на спільного замовника, щоб він змінив порядок транзакцій, у вас є велика перевага над усіма іншими.
Спільна мережа секвенсора має переваги та недоліки. З іншого боку, ми можемо додатково децентралізувати систему рейтингів. Але, з іншого боку, кожен має можливість бути сортувальником. Тож вони, по суті, можуть робити все, що завгодно, і знову темний ліс. Отже, ми запровадили децентралізацію, а потім нам довелося зіткнутися з подібними проблемами, з якими ми зіткнулися в Ethereum. Ось чому Flashbots і співробітники Ethereum Foundation хочуть рухатися вперед з PBS, розділити пропонентів і розробників, а потім спробувати мати єдине рішення на стороні розробника.
Отже, коли ми дивимося на проблему, це не просто одна проблема. Це вже не проблема один на один, а один на шість і більше.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Діалог із командами AltLayer, Scroll, Starknet: спільний секвенсор і L2 Consensus
Вступ
Коли ми подивимося на бачення та дорожню карту різних зведених рішень, ми виявимо, що майже всі зведені мають кінцеву мету. Якщо цю мету стиснути в одне речення: створити стек технологій, надати його спільноті, вирішити розширення блокчейн і, зрештою, децентралізація технологічного стеку операцій і управління. Це призводить до терміну децентралізоване зведення.
Тож що таке децентралізація? Який розподіл праці між різними частинами системи Rollup? Чи означає децентралізація максимізацію учасників роботи системи? Який вплив матиме централізований сортувальник? Як має бути розроблений спільний упорядник і локальний консенсус L2? Яка функція унікального прувера в ZK-Rollup? Як би виглядала відкрита децентралізована мережа перевірки? Навіщо нам апаратне прискорення zk? Яке вирішення проблеми доступності даних? ....
У спільноті ведуться нескінченні дискусії навколо децентралізованого зведення, тому ECN підготував серію подкастів-інтерв’ю на тему «Децентралізований зведений пакет» і запросив видатних засновників і дослідників у цій галузі поговорити про своє розуміння децентралізованого зведення.
У міру того, як на платформу рівня 2 надходить все більше і більше ліквідності, з’являється все більше постачальників послуг згортання, не лише універсальні рішення для зведення, ланцюжки зведення для окремих програм, а й платформи зведення як послуга. Тому все більше і більше людей стурбовані тим, що дуже важлива роль «секвенсера» майже в усіх зведених досі централізована. Які ризики централізованого сортувальника? Децентралізований сортувальник – термінова робота?
**У другому епізоді ми запросили Яоці Цзя, засновника AltLayer Network, Тогрула Магеррамова, дослідника Scroll, і Абдельхаміда Бахту, керівника дослідження Starknet, провести круглий стіл на тему децентралізованих сортувальників, щоб аудиторія та читачі може зрозуміти поточний прогрес і дилеми децентралізованих сортувальників. **
Гості випуску:
Минуле
Проблема 1. Як децентралізувати зведений пакет?
Попередній перегляд
Проблема 3: Прискорення мережі прувера та апаратного забезпечення zk
Проблема 4: Доступність даних і децентралізоване зберігання
Слухай
Натисніть, щоб підписатися на подкаст, щоб дізнатися більше:
Youtube:
Мікросвіт:
штамп часу
00:49 Яоці представляється
01:37 Абдельхамід представляється
02:50 Тогрул представляється
04:03 Роль сортувальника в rollup
08:37 Децентралізований замовник: покращення взаємодії з користувачем і вирішення проблем живучості та цензури
19:43 Як Starknet децентралізує сортувальник
22:59 Як Scroll децентралізує сортувальник
26:34 Різниця між консенсусом L2 в контексті Optimistic rollup і zkRollup
32:28 zkRollup децентралізує сортувальник, а також потребує врахування перевірки
36:01 Що таке зведення на основі?
40:53 Недоліки спільного секвенсора та базованого зведення та сценарії їх застосування
49:02 Який вплив матиме децентралізований замовник на MEV?
Представлення гостей
Яоці
Я засновник AltLayer. AltLayer створює платформу «Зведення як послуга», де розробники просто натискають деякі кнопки та налаштовують параметри. Використовуючи нашу панель запуску або панель керування, вони можуть швидко запускати зведення для певної програми за лічені хвилини. Ось що ми зараз намагаємося зробити, щоб надати розробникам загальне середовище виконання та функціональність. Ми також пропонуємо кілька секвенсорів, кілька систем віртуальних машин і різноманітні системи доказів для розробників на вибір.
Абдельхамід
Я працюю в Starkware і очолюю дослідницьку групу. Метою цієї групи є, в основному, запуск проектів з відкритим кодом, схожих на дослідження, але з інженерною спрямованістю. Наша мета — працювати над проектами з відкритим кодом у тісній співпраці з громадою та людьми з інших екосистем. Одним із таких проектів є Madara, який насправді є сортувальником Starknet. Це не лише кандидат у загальнодоступну мережу Starknet, а й секвенсор для ланцюжка додатків Starknet і Layer3. Це також пов’язано з тим, що сказав попередній гість, ми також думаємо про надання зведення як сервісної функції, люди можуть розгортати свій ланцюжок додатків Starknet і вибирати різні рішення щодо доступності даних дещо модульним способом. До цього я чотири роки працював розробником ядра Ethereum, в основному відповідаючи за роботу EIP-1559.
Вибір
Я дослідник у Scroll, і мої основні обов’язки в Scroll – це розробка протоколів, розробка мостів, децентралізація, стимули тощо. Тож коли я не пишу в Твіттері, більшу частину часу я просто працюю над тим, як децентралізувати протокол або замовників, перевірників тощо. Подібно до Starkware, одна з речей, над якою ми працюємо, це зведений SDK. Таким чином, ви можете випустити зведення на основі Scroll і модульно використовувати різні параметри доступності даних тощо. Ми все ще розглядаємо варіант, згідно з яким зведені пакети на основі Scroll SDK можуть використовувати сортувальник Scroll, щоб допомогти досягти децентралізації, не вимагаючи, щоб кожне зведене обробляло децентралізацію самостійно. Звісно, план ще не остаточно розроблений. Але це також той напрямок, над яким ми працюємо.
Розділ інтерв'ю
тема перша
Поясніть сортувальник зведення?
Абдельхамід
Сортувальник є дуже важливим компонентом в архітектурі layer2, цей компонент отримує транзакції від користувачів, потім пакує та групує їх у блоки, виконує транзакції тощо. Це дуже важливо, оскільки це компонент, який відповідає за створення блоків, оскільки рівень 2 також є блокчейном із блоками транзакцій. Замовники створюють ці блоки, а перевіряючі підтверджують ці блоки.
Яоці
Як зазначив Абдель, замовник — це комбінація багатьох функцій у блокчейні. Тож ми можемо фактично покласти на замовника занадто багато відповідальності порівняно з типовим публічним блокчейном. Спочатку потрібно звести всі транзакції від користувачів, а потім відсортувати ці транзакції за ціною на газ або за принципом «першим прийшов, першим обслужено». Після цього секвенсор повинен виконати ці транзакції. Як і зараз, деякі Layer2 використовують EVM (Starware має іншу віртуальну машину), але в основному секвенсору потрібна спеціальна віртуальна машина для виконання транзакцій і генерування стану. Потім транзакція досягає етапу попереднього підтвердження, що означає, що якщо ви бачите час підтвердження в одну-дві секунди або навіть підсекунди, це в основному стан попереднього підтвердження, завершений секвенсором. Потім для більшості сортувальників їм також потрібно завантажити або опублікувати контрольні точки чи хеші стану в L1. Це підтвердження на рівні L1, який ми називаємо доступністю даних. Отже, сортувальник насправді має багато ролей у системі зведення. Але загалом я вважаю, що це найважливіший компонент системи згортання.
** Тема 2 **
Чому децентралізований сортувальник важливий? Якщо ми використовуємо централізований сортувальник, які приховані небезпеки для користувачів і системи?
Вибір
Перш за все, нам потрібно знати, що, за винятком Fuel V1 на поточному етапі, немає справжнього зведення, тому що інші зведення все ще мають тренувальні колеса.
Однак ми можемо сказати, що як тільки його класифікують як зведення, це означає, що мультипідпис видалено тощо. Тоді проблема децентралізації сортувальника стає проблемою взаємодії з користувачем, а не проблемою безпеки. Отже, коли люди говорять про, скажімо, децентралізацію L1, проблема зовсім інша. Тому що L1 має давати гарантії на замовлення та легких клієнтів. Отже, якщо легкий клієнт хоче перевірити правильність стану, він повинен довіряти валідаторам L1. Для зведення це не так. Оскільки сортувальник забезпечує лише тимчасове сортування, яке потім завершується L1. І оскільки зведені версії також гарантовано стійкі до цензури, нам не потрібна децентралізація, щоб це сталося.
Отже, є кілька причин, чому вам потрібен децентралізований сортувальник. По-перше, якщо, скажімо, завершення L1 відбувається повільно (або через те, що надіслані вами докази дійсності надто повільні, або через механізм перевірки періоду оптимістичних зведених доказів шахрайства), ви повинні покладатися на щось, щоб отримати швидке підтвердження транзакції. На цьому етапі швидкого підтвердження, хоча ви можете бути впевнені, що Starkware або Scroll не обдурять вас, вони вказують, що після підтвердження блоку реорганізації не буде. Це припущення про довіру. А децентралізація може додати якісь економічні гарантії тощо.
Але виходячи з цього, зведення також не має гарантії остаточності в реальному часі. По суті, ви можете примусово упаковувати транзакцію через L1, але для упаковки цієї транзакції потрібні години. Так, наприклад, якщо є оракул, відповідальний за оновлення, і час коливається, то, в основному, якщо оракул оновлюється протягом години або більше, програми в зведеному пакеті будуть недоступні. По суті, децентралізація дозволяє нам надати деякі сильніші гарантії стійкості до цензури в реальному часі, тому що тоді зловмиснику потрібно буде скомпрометувати не лише одну сутність або декілька організацій, а всю мережу замовників.
Тож для нас децентралізація — це радше рішення для покращення взаємодії з користувачем або виправлення кутового випадку оновлень Oracle тощо. Замість того, щоб надавати базові гарантії безпеки, це робить L1.
Абдельхамід
Так, питання про децентралізований сортувальник, яке ви згадали, не зовсім те саме, що децентралізований L1, який, на мою думку, є дуже важливим. Тому що коли ми бачимо, як деякі L1 критикують централізовані сортувальники, вони не розглядають належним чином компроміси, які роблять централізовані сортувальники.
На цій основі я хотів би додати щось, що стосується досвіду користувача, пов’язане з діяльністю. Тому що, коли у вас є лише один сортувальник, у вас більший ризик його збою. Таким чином, децентралізований замовник також підвищує стійкість і живучість мережі. Але навіть у централізованому контексті ми маємо хорошу безпеку, коли мова йде про безпеку. Тому що коли ви можете примусово здійснювати пакетні транзакції через L1, різниця між ними полягає лише в часовій шкалі. А наявність децентралізованого сортувальника дозволяє отримати швидкі гарантії, стійкі до цензури, як зазначив Тогрул. Тож я лише хочу додати, що для життя також важливо мати децентралізовану мережу замовників.
Яоці
Я хотів би дещо додати. Діяльність, мабуть, найважливіше, що нам потрібно враховувати на цьому етапі. В останніх випадках аірдропу на найпопулярніших L2, таких як Optimism і Arbitrum, спостерігався період простою. Тому я думаю, що нам потрібно вирішити, як обробляти тисячі запитів на транзакції в секунду, коли у нас є лише один сортувальник. Навіть теоретично, якщо у вас є лише один вузол, він не може обробляти стільки запитів одночасно. Отже, що стосується живучості, нам точно потрібні кілька сортувальників. Єдина точка відмови є справжньою перешкодою не лише для Web3, навіть Web2 є великою проблемою.
Крім цього, є питання цензури. Якщо у нас є лише один координатор, навіть якщо ми бачимо, що ним може керувати команда, вам все одно потрібно довести, що команда насправді не переглядатиме транзакції. Іноді зловмисники можуть додати певні транзакції до чорного списку. Це децентралізована система замовників, вони також можуть спробувати відправити транзакції через інших замовників. Ось чому останнім часом ми отримуємо багато критики щодо окремих сортувальників.
Окрім цього, є деякі інші проблеми, такі як MEV і ранні запуски. У системі з централізованими сортувальниками, особливо для протоколів DeFi, вони могли б легко перевірити mempool. Ймовірно, не у формі лідера, але вони мають більше шансів зупинити торгівлю та арбітражувати її.
Багато з цих проблем з різних причин, хоча ми бачимо, що L2 дуже відрізняється від L1. Але зрештою нам все одно потрібно зробити його максимально децентралізованим. Тому нам доводиться стикатися з деякими подібними проблемами, які ми маємо з публічними блокчейнами або L1.
Абдельхамід
Так, я згоден, що децентралізований сортувальник важливий. Але я також хочу сказати, що, як ми всі знаємо, це непросте питання.
Крім того, **оскільки зведення мають дуже специфічну архітектуру з кількома сутностями. Ми говоримо про єдиний замовник, але також є перевірка, і нам потрібно децентралізувати обидва. **Будуть певні компроміси та певні труднощі в тому, як оцінювати транзакції, оскільки для роботи мережі потрібні різні фактори. Отже, як ви оцінюєте угоду? Сортувальник і прувер мають різні вимоги до апаратного забезпечення, пруверу потрібна надпотужна машина тощо. Тому ціноутворення в децентралізованому світі також є дуже складною проблемою, тому нам потрібен час, щоб повільно рухатися вперед.
Отже, ми всі зіткнемося з таким компромісом.Якщо ми хочемо швидко децентралізуватися, нам, можливо, доведеться взяти деякі навчальні колеса та поступово децентралізуватись, тому що якщо ми безпосередньо хочемо ідеальної архітектури, це займе кілька років. Тому я думаю, що ми підійдемо прагматично і спробуємо поступово децентралізуватись. Принаймні це наш поточний план, як, можливо, почати з простого механізму консенсусу BFT, а потім додати інший механізм консенсусу в короткостроковій перспективі чи щось подібне. Тому я просто хочу сказати, що це непросте питання. Оскільки, очевидно, існує компроміс між швидкістю розробки та застосовністю архітектури до децентралізованого середовища.
Тема 3
Як децентралізувати сортувальник?
Абдельхамід
Є багато функцій, які ми хочемо децентралізувати, і всі вони мають різні компроміси.
Наприклад, при децентралізації ви хочете запровадити якийсь механізм консенсусу. Однак у механізмі консенсусу є кілька частин. Перший — це вибори лідера, тобто як вибрати, хто буде створювати блоки, хто буде замовником, відповідальним за створення блоків у певному слоті або протягом певного часу. **Команда Starknet планує максимально використовувати рівень 1. Тобто в нашому алгоритмі виборів лідера ми хочемо зробити ставку на рівень 1. Наприклад, у нас є токени, а застава буде відбуватися на смарт-контракті Ethereum рівня 1, який використовується для визначення механізму обрання лідера. **Це означає, що нам потрібна певна взаємодія, під час якої замовник L2 запитуватиме смарт-контракт Ethereum, щоб знати, хто буде наступним лідером чи щось подібне. Отже, очевидно, потрібна якась випадковість та інші речі. Тож це не просте запитання. Але це перша частина. Тоді потрібно мати механізм самого консенсусу. Є кілька варіантів: або найдовший ланцюговий механізм, або BFT, або гібрид обох. Як і Ethereum, він має LMG Ghost і Casper FFG для остаточного завершення.
Тож ми можемо прийняти прагматичний підхід і почати спочатку з BFT. чому? Коли рівень 2 розглядає децентралізацію, наша мета полягає не в тому, щоб мати такий великий сортувальник, як рівень 1. Наприклад, на Ethereum метою є участь мільйонів валідаторів. У цьому випадку ви не можете просто використовувати механізм BFT, тому що він буде дуже поганим за ефективністю, і це створить дуже великі проблеми. Наприклад, якщо є проблема в мережі Bitcoin, якщо це механізм BFT, ланцюжок повністю зупиниться. Але це не так, мережа Bitcoin продовжує створювати блоки, атакується лише механізм остаточності.
Але на рівні 2, якщо метою є від кількох сотень до 1000 сортувальників, було б добре почати з механізму BFT. Отже, у нас є механізм виборів лідера, потім консенсус, а потім є ще дві частини, але я залишу це для інших гостей, щоб вони продовжували додавати. Але дві інші частини — це оновлення стану та створення доказів.
Вибір
По-перше, у L2 децентралізація є багатогранною проблемою, як описано Абделем. Особливо в zkRollup, оскільки є перевіряльники та замовники, вам потрібно координувати роботу між ними, вам потрібно децентралізувати обох. Ця проблема повністю відрізняється від L1.
Інша відмінність полягає в тому, що в L2 весь ваш проект полягає в тому, щоб переконати базовий міст у правильності консенсусу, а не в тому, щоб переконати будь-яку кількість інших вузлів. Ви, очевидно, повинні зробити те саме, але вашою головною увагою має бути сам міст.
Зараз ми працюємо у двох різних напрямках. Номер один, я думаю, як і всі інші, ми працюємо над протоколом BFT. Це не дуже ефективно, і є деякі переломи, які потрібно усунути. Ми знайшли приблизне рішення, але воно все одно не є оптимальним. Наприклад, одне із запитань полягає в тому, як ви збалансовуєте стимули між сортувальниками та перевіряльниками? Оскільки замовник контролює MEV, а перевірка не має доступу до MEV, є стимул для людей запускати замовник замість перевірки. Але насправді нам потрібно більше перевіряючих, ніж замовників, тож як збалансувати стимули між ними? Це одна з тих проблем.
Друге рішення, над яким ми працюємо, – інший напрямок. Пам’ятайте, що все може змінитися. Щодня з’являються нові пропозиції. Наприклад, останнім часом було багато розмов про зведення на основі баз і про те, як ви можете повністю передати сортування L1. Другий напрямок полягає в тому, щоб повністю відмовитися від сортувальника та використовувати зовнішній конструктор. Наприклад, конструктори ethereum або Flashbots SUAVE тощо пропонують упорядковані блоки, а потім запускають консенсус у перевірці. Перевагою тут є те, що вам не потрібно мати справу зі стимулами, оскільки в основному ви можете використовувати PBS у протоколі, і це створює простіший протокол. Але недоліком є те, що оскільки нам потрібна велика кількість пруверів (оскільки ми можемо доводити паралельно), з ними досить важко запустити класичний протокол BFT. Отже, питання полягає в тому, як оптимізувати існуючий протокол BFT для роботи з сотнями або навіть тисячами пруверів? І на це запитання непросто відповісти.
Чи потрібне запровадження консенсусу L2 для децентралізованого замовника?
Яоці
Я можу приблизно відповісти на це питання, тому що нещодавно ми випустили щось подібне.
Тож чи запроваджувати консенсус не залежить від того, хочемо ми цього чи ні. Якщо у вас є багато замовників або навіть лише вузли, ви повинні змусити їх погодитися. Це дійсно залежить від ваших припущень. Якщо це візантійське припущення, ми можемо використовувати BFT або будь-який існуючий візантійський консенсусний протокол. Наприклад, якщо це не візантійська установка, якщо ми просто припустимо, що вузол може бути лише онлайн і офлайн, і що він не може діяти зловмисно, тоді ми можемо використовувати протокол Raft або якийсь інший швидший протокол консенсусу. Але в будь-якому випадку, якщо у нас є група замовників або перевірників, якщо ми хочемо організувати їх разом, щоб виробляти блоки протягом певного періоду часу, тоді ви повинні мати консенсусний протокол навколо них.
Тож, як щойно згадали Тогрул і Абдель, я вважаю, що є багато пропозицій і тем для дослідження щодо того, як ми можемо запровадити децентралізовану систему впорядкування чи перевірки. Отже, оскільки ми щойно запустили тестову мережу для зведеної системи з кількома сортувальниками (наразі підтримує лише докази шахрайства для оптимістичних зведених даних), ґрунтуючись на нашому досвіді розробки та впровадження, я можу поділитися деякими речами щодо труднощів. Як щойно згадав Тогрул, складність полягає не в самому консенсусному протоколі. Справжня складність полягає в інших речах, таких як частина доказів. Тому що, якщо це один сортувальник, вам не потрібно багато вузлів. Ми можемо розглядати це як EVM, віртуальну машину. Отже, просто вибирайте транзакції та виконуйте їх, виконуйте переходи між станами. Підтверджувач відповідає за створення доказів для переходу стану попереднього набору транзакцій. Однак, якщо ми запустимо консенсус-протокол для сортувальника та перевірки під час зведення, то нам потрібно буде ввести туди додаткову консенсусну логіку. Окрім цього, вам також потрібна система перевірки протоколу консенсусу. Таким чином, це призведе до великої роботи для створення системи доказів. Після того як ви згенеруєте доказ, ви зможете легко перевірити його на L1 Ethereum.
Ось чому, у певному сенсі, коли ми запустили першу тестову мережу з кількома замовленнями, оптимістичне зведення мало певні переваги в цьому плані. Загалом, ви можете спростити багато речей, наприклад, не брати до уваги частину підтвердження дійсності. Як і ми, ми в основному порівнюємо все з WASM. Отже, зрештою, це інструкція WASM. Отже, перевіривши ці інструкції WASM, це відносно легко перевірити за допомогою коду Solidity. Якби ми просто повторно реалізували всі інтерпретації інструкцій WASM на Ethereum.
Але загалом проблема не поодинока. Якщо у нас є вирішення проблеми, то, відповідно, буде ще якась подальша робота, яку потрібно вирішити одночасно. Звичайно, будуть питання MEV, наприклад, як ми справедливо розподіляємо MEV. Ви можете призначити всіх замовників і перевірників залежно від того, створили вони блок чи перевірили блок. Але врешті-решт це насправді поєднання багатьох проблем, не лише технічних, а й економічних стимулів.
І ми повинні пам’ятати, що L2 пропонується, тому що ми хочемо значно знизити вартість газу. Тому ми не можемо мати стільки вузлів. Навіть у створенні доказів L2 може бути дорожчим за L1. Тож нам справді потрібно знайти збалансований підхід до такого роду проблем.
Абдельхамід
Я хотів би додати ще один момент. По-перше, наразі немає фактичних доказів шахрайства без дозволу для оптимістичних зведених пакетів. І я продовжую наголошувати на цьому при кожній нагоді, тому що під час порівняння важливо бути чесним. Отже, вони зовсім не L2. Це перше.
Потім я хотів би додати дещо про асинхронність між сортуванням і доказами, оскільки це дуже важливо. Як ви сказали, ми хочемо оптимізувати сортування, оскільки зараз це вузьке місце для всіх рішень. Але це добре в контексті централізованого сортування, тому що ми знаємо, що сортувальник вироблятиме лише переходи значень, і ми зможемо їх перевірити. Але це буде складніше в контексті децентралізованого сортування, тому що, можливо, ваш сортувальник зможе створити щось, що неможливо перевірити. Тоді вам доведеться розібратися з цим пізніше.
У контексті централізованого сортування, щоб оптимізувати сортування, оскільки нам не потрібно генерувати докази під час процесу сортування, ми можемо спробувати зробити це з локальною швидкістю, що ми і хочемо зробити. Перекладіть Cairo на машинну мову низького рівня, як-от LLVM, і надшвидко запустіть сортувальник. Тоді ви можете довести асинхронно. І найкрутіше в доказах те, що ви можете робити їх паралельно. Масова паралелізованість досягається шляхом доведення того, що рекурсія можлива. Тому ми зможемо наздогнати швидкість сортувальника. Але при децентралізації це складно, тому що нам потрібно переконатися, що замовник створює лише дійсні переходи станів.
Вибір
Додам, що я не впевнений, що тут робить Starknet. Але для нас, я думаю, загальним припущенням кожного zkRollup є те, що якщо ви децентралізуєте сортувальник, ваша система перевірки повинна мати можливість обробляти недійсні пакети. Отже, якщо, скажімо, ви надсилаєте пакет із недійсним підписом, ви повинні бути в змозі довести, що отриманий стан еквівалентний початковому. Тож у будь-якому випадку будуть певні накладні витрати. Йдеться про те, як мінімізувати ймовірність цього.
Абдельхамід
Так, правильно. Ось чому ми представили Sierra в Cairo 1, щоб усе можна було перевірити. Це проміжне представлення гарантує, що кожну програму Cairo 1 можна перевірити, щоб ми могли включити транзакцію повернення.
Що таке зведення на основі?
Яоці
Основне зведення спочатку було отримано з публікації в блозі Джастіна Дрейка на форумах Ethereum. Одна з його ідей полягає в тому, що ми можемо повторно використовувати деякі верифікатори Ethereum для перевірки транзакцій зведення, щоб нам не потрібна окрема група вузлів для перевірки різних транзакцій зведення. Зокрема, у майбутньому ми матимемо багато зведених пакетів, у тому числі загального призначення та багато зведених програм для окремих програм. Отже, у цьому випадку було б чудово, якби ми могли знайти спільне місце, як-от пул валідаторів Ethereum, для перевірки цих транзакцій.
Звісно, це лише ідея, оскільки вона також створює багато технічних труднощів. Наприклад, теоретично ми могли б вимагати валідаторів Ethereum для перевірки зведених транзакцій, але дуже важко отримати логіку перевірки зведених транзакцій у пакеті або вбудованих у сам протокол Ethereum. Ми називаємо це внутрішньопротокольною перевіркою, яка вимагає хардфорка вузлів Ethereum. Звичайно, у цьому випадку ми можемо перевірити деякі зведені транзакції. Але якщо ми це зробимо, ви побачите проблеми. Це трохи схоже на те, що ми хочемо, щоб зведення L2 розділило тиск Ethereum, але зрештою ми все одно просимо валідаторів Ethereum взяти на себе частину роботи, покладеної на L2. Тому багато людей говорять про те, як ми можемо це зробити.
Потім ми поговорили з Барнабі, дослідником з Ethereum Foundation, який зараз працює над PBS. Це пропозиція Ethereum, яка полягає в тому, щоб розділити завдання валідаторів на кілька ролей, розробників і пропонентів. Тепер у нас є Flashbots, які виконують роль конструкторів у PBS, вони створюють усі блоки та надсилають їх розробникам Ethereum. Отже, коли ці блоки будуть упаковані в мережу Ethereum, розробники також отримають певні винагороди. Тоді як у цьому випадку винагородити ці валідатори з мережі Ethereum? Вони також відповідають за перевірку зведених даних.
Одним із рішень є «переставлення», про яке ви, можливо, багато чули від EigenLayer або деяких інших протоколів. Користувачі можуть переставити ETH на інші мережі сортування. Або винагороджуйте валідаторів Ethereum за фактичний запуск програмного забезпечення для виконання перевірки для зведення. У цьому випадку вони можуть отримати винагороду як з L2, так і через протокол рестейкінгу. Наразі було багато пропозицій щодо цього, але загалом це ідея того, як перепрофілювати існуючі валідатори Ethereum. Як ми можемо повторно використовувати існуючий ETH, щоб розпочати нову еру зведених систем або систем L2? Таким чином, це в основному спроба спростити багато речей для зведеного проекту. Якщо зведенню потрібен новий сортувальник, якщо їм потрібне нове джерело забезпечення, вони можуть повторно використовувати існуючу інфраструктуру чи наявне забезпечення. Ось чому його створено на основі Ethereum, а потім подальшу інфраструктуру та стейкинг можна повторно використовувати для зведення та L2.
Недоліки спільного секвенсора та базового зведення та сценарії їх застосування.
Вибір
Я хочу поскаржитися на цю пропозицію, мене не переконала пропозиція, пов’язана зі спільним секвенсором. Звичайно, вони все ще знаходяться в зародковому стані, і якщо ці проекти покращаться в майбутньому, цілком можливо, що я підтримаю їх. Просто нинішня форма мене не переконує. Є багато причин.
По-перше, для мене основна цінність спільного сортувальника полягає в тому, щоб дозволити користувачам отримати атомарну компонування між зведеними продуктами загального призначення, такими як Scroll або Starknet. Але проблема полягає в тому, що якщо у вас є атомарна компонування, то ваш зведення є таким же остаточним, як і найповільніше зведення, з яким ви об’єднуєте. Отже, якщо припустити, що Scroll об’єднано з Optimistic Rollup, кінцевий термін дії Scroll складатиме сім днів. Хоча головною цінністю ZKRollup є досягнення відносно швидкого завершення, користувачі можуть вийти на L1 протягом декількох хвилин. І в цьому випадку взагалі відмовтеся від цього.
Іншим недоліком є те, що якщо ви хочете отримати остаточність поза ланцюгом, вам потрібно запустити вузол L2, і якщо дані, надіслані в ланцюжок, завершуються L1, ви отримуєте остаточність локально в L2. Якщо кожен комбінований L2 не запускає повний вузол, практично неможливо досягти локальної фіналізації. Це означає, що запуск цієї системи може бути дорожчим, ніж запуск такої системи, як Solana, оскільки у вас є кілька повних вузлів, що працюють одночасно, з власними накладними витратами тощо.
Тому з цих причин я просто не думаю, що це має сенс для L2. Це трохи інше для L3, тому що якщо хтось хоче побудувати ланцюжок для конкретної програми і не хоче мати справу з децентралізацією. Скажімо, я створюю гру, і я просто хочу мати справу зі створенням гри, тоді я можу аутсорсингувати децентралізовану роботу. Але я не думаю, що це має сенс для L2 на даний момент.
Щодо базованого зведення, я також маю свої занепокоєння. Наприклад, як ви розподіляєте прибуток від MEV між перевіряючими? Оскільки, якщо не розглядати проблему розподілу, L1 може отримати весь прибуток від MEV. Інша дрібниця полягає в тому, що його час підтвердження дорівнює часу підтвердження L1, який становить 12 хвилин, що не може бути швидше. Інша проблема полягає в тому, що оскільки він не має дозволу, кілька шукачів можуть надсилати пакети транзакцій одночасно, що означає, що результати можуть бути централізованими. Оскільки розробники заохочуються включати свої транзакції, якщо один шукач підключається легше, ніж інші. Тому це може призвести до того, що зрештою лише один Шукач запропонує партії для L2, що є не дуже хорошим рішенням, тому що якщо це станеться, ми фактично повернемося до початку.
Яоці
Цікаво, що минулого тижня у мене був телефонний дзвінок із Беном, засновником Espresso. Ми багато обговорюємо це в темі спільних сортувальників. Як згадав Тогрул, я думаю, що є певна невизначеність щодо сценаріїв використання спільної системи замовлення. Це головним чином тому, що для загального призначення L2 ми зазвичай не маємо великої кількості сортувальників через ефективність, складність та економічність. І я досі вважаю, що найкращим варіантом використання є здебільшого RAS (зведення як послуга) або такі платформи, де ми можемо розгорнути багато зведень, незалежно від того, чи йдеться про спільний секвенсор, зведення на основі чи повторне виконання. Чесно кажучи, нам не потрібна велика мережа сортування, якщо зведень небагато. Ці збірки вже мають власні системи сортування та власні спільноти чи партнерів, хоча є лише деякі загальні L2. Їм насправді не потрібна окрема та стороння мережа. Крім того, це тягар для сторонньої мережі, тому що вам потрібно налаштувати для кожного L2, і кожен L2 має інший тестовий стек. Це вимагає багато змін у вашій власній мережі.
Але в той же час, як згадав Тогрул, для деяких особливих випадків використання. Наприклад, якщо ми хочемо мати певну сумісність на рівні сортувальника, спільні сортувальники можуть бути потенційним шляхом. Наприклад, той самий сортувальник використовується для кількох зведень. У цьому випадку цей сортувальник може в основному обробляти деякі транзакції перехресного зведення, щоб забезпечити атомарність між ланцюжками між зведенням A, B і C.
Але ви також можете побачити проблему тут, коли я описую ситуацію. Якби ми справді мали багато цих спільних секвенсорів, вони знову стали б вузьким місцем і новою єдиною точкою відмови. Ми надаємо занадто багато повноважень цим так званим спільним замовникам. Вони стають більше схожими на мережу, контролюючи багато зведень. Нарешті, нам знову потрібно придумати спосіб децентралізації цього спільного сортувальника.
Але в будь-якому випадку, я вважаю, що це добре, що люди поступово виявляють все більше проблем і придумують все більше рішень. Загалом, цікаво спостерігати щодня за новинками в цій галузі. Завдяки всім цим новим рішенням ми принаймні на правильному шляху до справжньої децентралізації всього простору згортання.
Абдель
Так, я згоден з вами обома. Я вважаю, що це має більше сенсу для Layer3 і Lisk, оскільки вони більше не хочуть брати на себе відповідальність за стимулювання децентралізованої мережі, і їм потрібно знайти партнерів, щоб розпочати такі речі, як сортувальники. Тому я думаю, що для Ліска це має сенс. Але, як і Тогрул, я не думаю, що це має сенс для Layer2.
Тема 4
Який вплив матиме децентралізований замовник на MEV?
Абдель
Для Starknet, у контексті централізації, ми не робимо жодного типу MEV, а приймаємо модель «першим прийшов, першим обслужено». Тобто в контексті децентралізації, звісно, більше МЕВ буде запроваджено пізніше. Але ще занадто рано говорити про співвідношення, оскільки це також залежить від конструкції механізму консенсусу та інших аспектів.
Вибір
Але справа в тому, що навіть якщо ви не робите MEV, деякі MEV все ще можуть відбуватися в Starknet. Сама по собі децентралізація насправді не зменшує чи збільшує MEV. Звичайно, якщо ви застосовуєте, наприклад, якийсь протокол чесного впорядкування або порогове шифрування, тоді так, ви мінімізуєте MEV. Але повністю виключити його не можна. Моя філософія така: MEV неможливо усунути. Але припустімо, що ви просто створюєте консенсус BFT або будуєте щось на основі консенсусу BFT. Насправді це взагалі не впливає на MEV. MEV все ще існує, це має бути питання про те, як шукач працює з сортувальником, щоб отримати цей MEV.
Яоці
Проблема в тому, що навіть модель «перший прийшов, перший обслужений» має складні частини. Після того, як ми відкриваємо мемпул деяким шукачам, вони все одно матимуть перевагу грати більше. Наприклад, для секвенсорів вони еквівалентні очікуванню біля дверей офісу. Тож у цьому випадку, як тільки вони бачать якусь можливість арбітражу, а не лише про фронт-ранінг або сендвіч-атаку, щойно користувач надсилає транзакцію, він одразу може побачити це в mempool. Таким чином, вони можуть швидко розмістити свої операції попереду інших. Отже, вони мають перевагу над іншими пошукачами.
Але повертаючись до децентралізації, я думаю, що це здебільшого спротив цензури, як ми обговорювали на початку. Секвенсорами керує команда. Команда може сказати, що вони справедливі до всіх. Але це не заборонено в коді. Отже, якби ми могли мати мережу P2P, було б чудово, якби ми відчували, що ці вузли перевіряють мої транзакції, а потім ми зможемо надсилати на інші вузли. Отже, справді йдеться про чесність обробки транзакцій на L2.
Що стосується MEV, тому що останнім часом, окрім MEV, створених в рамках одного зведення, є деякі MEV, створені через мости. У цій відносно децентралізованій мережі сортування ви матимете більше можливостей для отримання MEV. Якщо припустити, що у нас є спільна мережа замовлень, то якщо ви можете якимось чином вплинути на спільного замовника, щоб він змінив порядок транзакцій, у вас є велика перевага над усіма іншими.
Спільна мережа секвенсора має переваги та недоліки. З іншого боку, ми можемо додатково децентралізувати систему рейтингів. Але, з іншого боку, кожен має можливість бути сортувальником. Тож вони, по суті, можуть робити все, що завгодно, і знову темний ліс. Отже, ми запровадили децентралізацію, а потім нам довелося зіткнутися з подібними проблемами, з якими ми зіткнулися в Ethereum. Ось чому Flashbots і співробітники Ethereum Foundation хочуть рухатися вперед з PBS, розділити пропонентів і розробників, а потім спробувати мати єдине рішення на стороні розробника.
Отже, коли ми дивимося на проблему, це не просто одна проблема. Це вже не проблема один на один, а один на шість і більше.