10 жовтня о 14:00 основна мережа Scroll для рішення Ethereum Layer 2 згенерувала свій перший блок, знаменуючи успішний запуск основної мережі Scroll. Станом на 25 жовтня понад 7600 ETH було підключено до мережі Scroll через міжланцюгові мости, а 24 децентралізовані торгові платформи запрацювали в основній мережі Scroll із загальним TVL приблизно 10 мільйонів доларів.

17 жовтня Scroll офіційно оголосив про запуск своєї основної мережі, продовжуючи підтримувати свою відданість відкритому коду та децентралізації. На наступному етапі Scroll зосередиться на створенні децентралізованої мережі підтвердження частки та сортувальника. У цій статті ми надамо детальний аналіз архітектури та технології Scroll, щоб допомогти кожному зрозуміти поточний стан мережі та напрямок майбутнього розвитку Scroll. Ми також пояснимо схему zkEVM Scroll і знання аудиту, щоб посилити заходи безпеки для проектів zk.

Хто такий Scroll, рушійна сила хвилі Layer2?

Scroll — це рішення для масштабування Ethereum Layer 2, засноване на технології захисту від нульового знання, спрямоване на підвищення пропускної здатності транзакцій і швидкості мережі Ethereum. Порівняно з Optimistic Rollup, Scroll досягає масштабованості за рахунок доказів з нульовим знанням і прискорює створення та перевірку доказів з нульовим знанням за допомогою апаратного прискорення. Він прагне досягти сумісності EVM на рівні байт-коду. Це означає, що розробники можуть безпосередньо використовувати інструменти розробки Solidity та Ethereum для створення смарт-контрактів і розгортання їх на Scroll без будь-яких змін.

Згідно з офіційним веб-сайтом Scroll, наразі в команді Scroll є 10 основних членів, розподілених по Азії, Америці та Європі. Члени команди мають багатий досвід розробки та роботи в галузі zkRollup, більшість із них закінчили престижні університети та мають ступінь доктора філософії.

Наразі екосистема Scroll дуже багата з інфраструктурними проектами, включаючи гаманці, інструменти розробки, засоби безпеки тощо. Мета полягає в тому, щоб забезпечити комплексну підтримку проектів протягом усього життєвого циклу, від проектування, розробки, експлуатації до аудиту безпеки. Зараз у мережі Scroll є понад 180 екосистемних проектів.

1. Гаманець
   Наразі Scroll підтримує майже всі основні гаманці: Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafePal Wallet. Крім того, гаманець екосистеми Scroll також включає OKX Wallet, Versa Wallet тощо.

2. Поперечний ланцюговий міст
   Офіційна міжланцюгова інфраструктура Scroll включає Celer Network, Stargate, Orbiter Finance, Hop Protocol, LI.FI, Connext тощо. Крім того, він також включає міжланцюговий протокол ліквідності Synapse Protocol, Owlto Finance, зосереджений на перехресних мостах рівня 2, Ethereum Layer 1 і перехресний міст рівня 2 Pheasant Network, Symbiosis, Catalyst тощо.

3. DeFi
   В екосистемі Scroll є кілька добре налагоджених проектів DeFi, зокрема протокол кредитування Aave, багатоланцюговий агрегатор DEX DODO, DEX SushiSwap, агрегатор DEX OpenOcean, багатоланцюговий протокол DeFi iZUMi Finance, DEX Syncswap, протокол доходності Pendle Finance, кредитування протокол dForce і торговий агрегатор кредитного плеча MUX Protocol. Є також інноваційні проекти, такі як GMX, які не отримали широкого поширення.

4. інші
   Що стосується NFT, ігор і соціальних аспектів, то інші проекти в екосистемі Scroll включають NFTScan, платформу завдань Web3 QuestN, TaskOn, платформу електронного підпису протоколів EthSign, Galaxy Blitz, OmniKingdoms та інші онлайн-ігри на блокчейні.

Що відрізняє технологію Scroll від інших?

1. Загальна архітектура

Архітектура Scroll складається з трьох компонентів:

Scroll Node: генерує блоки в мережі Scroll на основі транзакцій користувачів, надсилає ці транзакції на базовий рівень Ethereum і обробляє передачу повідомлень між Ethereum і Scroll.

Ролик: Ролик відповідає за перетворення смарт-контрактів у схеми zkEVM, а потім генерує докази для підтвердження правильності транзакцій. У мережі Scroll є кілька роликів, які паралельно обробляють транзакції та прискорюють створення доказів за допомогою апаратного забезпечення. Scroll досягає сумісності на рівні байт-коду з EVM, безпосередньо підтверджуючи правильність обробки байт-коду EVM.

Зведений і мостовий контракт: ці контракти забезпечують доступність даних для транзакцій Scroll і перевіряють докази дійсності, створені zkEVM. Можна сказати, що Scroll підключений до базового рівня Ethereum через контракти Rollup і Bridge. За допомогою цих контрактів користувачі можуть обмінюватися довільними повідомленнями між Ethereum і Scroll, а також передавати активи ERC-20 в будь-якому напрямку за допомогою шлюзових контрактів.

Джерело: https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k

Scroll — це основний контракт, розгорнутий у блокчейні Ethereum:

Проксі-контракт маршрутизації шлюзу (забезпечення правильного відображення токенів у міжланцюжкових операціях): 0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6

Договір проксі-сервера повідомлень (передавання повідомлень між L1 і L2): 0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367

Варто зазначити, що ці контракти можуть бути змінені адміністратором і власником проксі. Крім того, Scroll включив функцію білого списку, яка дає змогу регулювати плату за газ для певних адрес у Scroll. Наразі секвенсор Scroll працює централізовано, що дозволяє переглядати повідомлення та транзакції в мережі Scroll. Крім того, є можливість обійти будь-яке повідомлення в черзі повідомлень і безпосередньо підтвердити конкретне повідомлення.

2. Прокрутіть робочий процес zkEVM

Після того, як Scroll генерує блок, він проходить через координатор і кілька пруверів (роликів) для створення агрегованих доказів. Потім ці докази надсилаються до контракту Ethereum Rollup для перевірки. Детальний процес виглядає так:

1、Секвенсер отримує нові транзакції. Віртуальна машина зчитує байт-код, пов’язаний з кожною транзакцією, генеруючи трасування виконання та надсилаючи його координатору. Одночасно секвенсор надсилає дані транзакції до контракту Rollup.

2、Ролики перетворюють сліди виконання, отримані від координатора, у схеми zkEVM. Кожен крок трасування виконання відповідає схемі zkEVM. Для функцій, які не є зручними для zk (таких як hash і Keccak), Scroll створює таблиці пошуку, щоб зіставляти входи та виходи цих функцій у трасі виконання з таблицею пошуку. Для перевірки правильності таблиці пошуку використовуються додаткові схеми. Ролики потім генерують докази для цих схем zkEVM.

3、Після створення доказів Rollers надсилає їх назад координатору. Кожні кілька блоків координатор випадковим чином призначає Ролеру завдання агрегації. Призначений ролик потім об’єднує докази для кількох блоків у єдиний доказ.

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

Прокрутіть схеми та аудит zkEVM

1. Основні ланцюги

zkEVM складається з кількох схем, кожна з яких виконує перевірку певного аспекту EVM (віртуальної машини Ethereum). Зрештою ці схеми об’єднуються або агрегуються для створення підтвердження виконання транзакції. Діаграма нижче ілюструє зв’язок між цими схемами та таблицями.

Існують менші підсхеми, такі як схема ECDSA та підсхеми, пов’язані з кодом операції, які не взаємодіють з іншими таблицями та схемами таким чином, щоб впливати на комбінацію схеми. Ці підсхеми опущені на схемі для ясності.

Схема EVM

Віртуальна машина Ethereum (EVM) — це кінцевий автомат, який встановлює правила для дійсних переходів між станами в межах протоколу Ethereum. Він виконує інструкції (коди операцій) для досягнення цих переходів і генерує трасування виконання. Метою схеми EVM є створення системи обмежень, яка представляє трасування виконання та може бути перевірена за допомогою системи підтвердження з нульовим знанням.

Високорівневий дизайн схеми EVM дещо схожий на дизайн самого EVM, наприклад go-ethereum. У go-ethereum інтерпретатор повторює всі коди операцій інструкцій у трасі виконання. Для кожної інструкції інтерпретатор перевіряє відповідну контекстну інформацію, таку як газ, стек і пам’ять, а потім надсилає код операції до JumpTable, яка надає детальні інструкції щодо виконання коду операції.

Подібним чином у схемах EVM Scroll створює кроки виконання на основі трасування виконання та надає докази для кодів операцій і контекстів виконання. Для кожного кроку виконання застосовується набір обмежень для перевірки контекстної інформації. Для кожного коду операції застосовується набір обмежень, щоб перевірити його поведінку. У трасі виконання той самий код операції повинен мати однакові обмеження. Scroll використовує селектори, щоб «відкрити» всі кроки з однаковим кодом операції в трасуванні виконання, і використовує серверну систему перевірки, щоб підтвердити їхню поведінку.

Державний округ

Під час виконання всі операції читання та запису EVM записуються в rw_table і впорядковуються за змінною rw_counter. Метою схеми стану є демонстрація точної генерації rw_table.

MPT Circuit

Merkle Patricia Tree (MPT) — ключова структура даних, яка використовується на рівні зберігання Ethereum. У zkevm-Circuits Scroll MPT модифіковано на zkTrie, що, по суті, є розрідженим двійковим кодом Merkle Patricia Trie. У zkevm-Circuits Scroll використовує таблицю MPT для відстеження переходів станів операцій MPT крок за кроком. Таблиця MPT має такий вигляд:

Метою схеми MPT є перевірка точності таблиці MPT, згаданої вище. Це гарантує, що кожне оновлення, записане в таблицю MPT, призводить до правильної зміни. Це означає, що для кожного оновлення схема MPT гарантує наявність лише одного способу внесення змін. Це запобігає випадковим або несанкціонованим модифікаціям і забезпечує цілісність і точність MPT. Зокрема, коли MPT зазнає змін через оновлення в облікових записах або сховищі, схема MPT повинна довести, що ці оновлення виконуються відповідно до визначених правил. Крім того, він повинен продемонструвати, що кореневий хеш точно відображає результати всіх змін.

Автодром Keccak

Scroll реалізував власну версію Keccak256 відповідно до специфікації NIST Keccak і специфікації команди Keccak.

А схема Keccak використовується для підтвердження правильності операції Keccak256. Реалізація цієї схеми є складною, головним чином через те, що сам алгоритм keccak256 недружній до zk.

Tx Circuit

Схема Tx надає обмеження для перевірки правильності транзакції. У першу чергу він перевіряє такі аспекти транзакції:

1. Правильність CallDataLength і сукупної CallDataGasCost: визначте спеціальний шлюз і знайдіть останній рядок байтів даних виклику в таблиці tx;

2. Правильність пов’язаних даних TxSign і TxHash: пошук у таблиці RLP і таблиці Keccak;

3. Доведіть правильність «якщо tx_type дорівнює L1Msg, то msg_hash»: перевірте, виконавши пошук у таблиці RLP;

4. Правильно виконати підпис tx за допомогою ECDSA та правильно відновити адресу абонента з підпису ECDSA: перевірити, виконавши пошук у таблиці sig;

5. Правильна перехідна поведінка tx id, cum_num_txs і call_data_length;

6. Деякі основні обмеження, такі як логічні значення певних змінних індикатора.

Схема байт-коду

Схемам EVM потрібно шукати таблицю байт-коду, яка містить правильну інформацію про байт-код. Це гарантує, що байти, збережені в контракті, збігаються з байтами, завантаженими з таблиці. Метою схеми байт-коду є забезпечення правильності таблиці байт-кодів. Це включає:

1. Обмеження, пов’язані з поведінкою кордону з тегами (тег): обмеження на першому та останньому рядках, перетворення тегу == байт у заголовок і навпаки, перетворення заголовка в заголовок;

2. Обмеження на розмір коду: Включно з обчисленням довжини байт-коду через обмеження індексу останнього байта байт-коду;

3. Обмеження на хеш коду: правильне обмеження поведінки RLC байтів у хеші коду та перевірка хешу коду шляхом пошуку таблиці Keccak;

4. Забезпечення правильності поведінки PUSH: is_code = push_data_left == 0 (має бути логічним значенням) і перевірка розміру надісланих даних для PUSH1-PUSH32 шляхом пошуку push_table;

5. Забезпечення правильного розповсюдження в кожному рядку байт-коду.

2. Аудит безпеки

Різні ланцюжки мають свої власні функції бізнес-модуля, які зазвичай змінюють попередньо скомпільовані контракти та коди операцій у EVM. Серед них Scroll zkEVM — це рішення для масштабування другого рівня, засноване на доказах з нульовим знанням. Це рішення реконструює відповідні коди операцій за допомогою схем і генерує докази на основі слідів виконання. Така складна реалізація значно ускладнює аудит. Після оцінки експертів з безпеки Beosin аудит безпеки zkEVM головним чином зосереджується на таких аспектах:

1. GAS: під час створення доказів для трасування виконання схеми zkEVM також перевіряється правильність споживання газу для транзакцій. Якщо необмежені вільні змінні часто використовуються в схемі реалізації кодів операцій, це може призвести до помилки створення доказів або інших невідомих помилок.

2. Безпека пам’яті: деякі схеми zkEVM базуються на поліноміальних зобов’язаннях, таких як зобов’язання KZG, яке використовує Scroll. Однак поліноміальні обчислення не вирівнюються автоматично, тому, якщо в схемі немає обмежень, це може призвести до того, що діапазон значень буде несумісним з діапазоном байтів у комп’ютерних програмах. У деяких випадках, коли розробники контракту вмикають оптимізацію газу, компактне розташування даних може призвести до проблем із безпекою пам’яті, як-от постійний поліном BYTE_C4096 у Polygon zkEVM. Поліноми дозволяють значенням параметрів перевищувати максимальний діапазон значень байтів у 255, що потенційно може дозволити зловмисним секвенсорам маніпулювати параметрами з метою отримання прибутку на деяких платформах обміну, які використовують модель AMM. По суті, ці типи вразливостей виникають через невідповідності між числовим діапазоном дійсності, представленим схемою, та діапазоном змінних значень програми. Прикладом є вразливість CVE-2023-33252, виявлена дослідниками безпеки Beosin у бібліотеці Snarkjs.

3. Безпека коду операції: під час впровадження кодів операції zkEVM виникають загальні проблеми безпеки, особливо щодо точності. Наприклад, під час порівняння двох чисел у базовій схемі, якщо точність операції порівняння в програмі становить 1 байт, обмеження схеми повинні вказати діапазон значень. Інакше точність операцій у схемі перевищить точність програми, що призведе до неправильних результатів.

4. Підтримка захищених EIP: підтримка орієнтованих на безпеку EIP, таких як EIP-2 і EIP-155.

5. Проблема централізації в Sequencer: наразі всі докази, згенеровані Scroll, залежать від траси виконання, згенерованої Sequencer. Якщо Sequencer поводиться зловмисно, zkEVM не може гарантувати безпеку ресурсів користувача.

6. Проблема сумісності: zkEVM генерує докази схеми на основі трасування виконання та перевіряє їх у контракті. Навіть незначні оновлення в Sequencer можуть призвести до значних відмінностей у трасуванні виконання, згенерованому на рівні основної мови.

Прогноз на майбутнє Scroll

1. Scroll наразі використовує двошарову версію KZG системи перевірки Halo2, використовуючи апаратне прискорення GPU для прискорення створення перевірки. Тепер вузьке місце перемістилося до створення свідків і реплікації даних. Крім того, рівень централізації та експлуатаційні витрати на апаратне забезпечення Roller також є аспектами, які Scroll має враховувати для майбутньої розробки багатоступеневих систем перевірки.

2. Оскільки трасування виконання EVM динамічно змінюється, існують різні обмеження схеми та масштаби. Наразі, щоб адаптувати трасування виконання, що динамічно змінюється, кожен крок трасування виконання повинен задовольняти найбільший масштаб схеми, що призводить до додаткової втрати пам’яті.

3. Очікується, що Scroll's Roller отримує прибуток від комісії за мережеві транзакції. Однак поточна кількість користувачів і комісії за транзакції в мережі Scroll не можуть покрити експлуатаційні витрати Roller і секвенсора. Питання, яке необхідно розглянути в майбутньому, як мережа Scroll забезпечує економічні стимули для залучення користувачів і підтримки стабільної роботи мережі.

В даний час Beosin також підтримує аудит проекту zk. Для жорстких досліджень безпеки на zk ви можете прочитати такі статті: 1. Transaction Malleability Attack of Groth16 Proof; 2. Поглиблене вивчення Tornado Cash для виявлення атак податливості в проектах ZKP.

Beosin, як провідна глобальна компанія безпеки блокчейну, створила філії в більш ніж 10 країнах і регіонах по всьому світу. Наші послуги охоплюють перевірку безпеки коду перед запуском проекту, моніторинг ризиків безпеки, раннє попередження та запобігання під час роботи проекту, повернення активів для викрадених віртуальних валют і безпечні послуги відповідності, такі як KYT/AML. Ми надаємо універсальне рішення для продуктів і послуг безпеки блокчейну. Наразі ми надаємо послуги технології безпеки понад 3000 блокчейн-підприємствам у всьому світі та перевіряємо понад 3000 смарт-контрактів. Не соромтеся звертатися до нас.

Відмова від відповідальності:

1. Ця стаття передрукована з [Beosin]. Усі авторські права належать оригінальному автору [Beosin]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.