Перша частина серії zkEVM: загальна архітектура та процес виконання транзакцій Polygon zkEVM

Автор: 0xhhh, Ethstorage(Twitter:@hhh69251498 )

Редактор:Червоний

27 березня була офіційно запущена бета-версія основної мережі Polygon zkEVM, і Віталік здійснив свою першу транзакцію по ній.

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

У наступних двох статтях ми також детально розповімо про деталі дизайну zkEVM Bridge і zkEVM від Polygon zkEVM, а також про дорожню карту наступного децентралізованого секвенсера Polygon zkEVM.

По-перше, Rollup призначений для досягнення обчислювального масштабування для Ethereum

По-перше, ми повинні чітко розуміти, як працюють Rollups. Поява Rollup полягає в масштабуванні обчислень Ethereum, специфічний метод реалізації полягає в тому, щоб передати виконання транзакцій на аутсорсинг Rollup, а потім зберігати транзакцію та стан (State) після виконання транзакції в контракті Ethereum.

Оптимістичне зведення

Оптимістично, що транзакція зведення та відповідний стан зведення, надіслані до Ethereum, є правильними, і будь-хто може оскаржити стан зведення, який все ще перебуває в періоді випробування, надавши доказ шахрайства.

Зведення з нульовим розголошенням

ZK надасть доказ дійсності для транзакції rollup, надісланої в Ethereum, і відповідний стан зведення (перевіряється контрактом на Ethereum, щоб довести, що зведення знаходиться в правильному стані після виконання відповідної транзакції).

Зверніться до офіційного визначення Ethereum:

Найбільша відмінність між Zero-knowledge Rollup і Optimistic Rollup полягає в тому, що час досягнення остаточності різний через різні способи перевірки валідності стану.

Optimistic Rollup оптимістично налаштований щодо того, що транзакції та статуси, надіслані в Ethereum, є правильними, тому існує 7-денний період оскарження (час досягнення остаточності становить 7 днів), протягом якого будь-хто, хто виявить, що відповідний стан транзакції в Ethereum неправильний, може оскаржити, надіславши правильний статус.

Час, необхідний для того, щоб Rollup з нульовим розголошенням (zk-Rollup) досяг остаточності, залежить від часу, необхідного для того, щоб доказ дійсності транзакції був відправлений в Ethereum і перевірений. Наразі це може бути близько 1 години для остаточного завершення (через необхідність враховувати вартість газу).

Другий, процес виконання Polygon zkEVM

Давайте подивимося, як працює Polygon zkEVM з простим процесом підтвердження транзакцій, щоб мати конкретне уявлення про загальний протокол, і весь його процес можна розділити на три основні етапи:

1. Секвенсер упаковує кілька транзакцій користувача в пакети і відправляє їх в L1-контракт.

2. Prover генерує доказ валідності для кожної транзакції та об’єднує докази дійсності кількох транзакцій в один доказ дійсності.

3. Агрегатор подає Validity Proof агрегованих багаторазових транзакцій агрегатора в L1-контракт.

1 Секвенсор упаковує транзакції користувача в пакети та надсилає їх до L1-контракту.

1. Користувач відправляє транзакцію в Секвенсер, і Секвенсер буде обробляти транзакцію локально в порядку отримання (FRFS), коли Секвенсер виконує транзакцію локально, якщо користувач вважає, що Секвенсер чесний, то він може вважати транзакцію завершеною. Тут важливо зазначити, що більшість мемпулів у Секвенсері наразі є приватними, тому на даний момент є відносно небагато MEV, які можна отримати.

2. Секвенсер упакує кілька транзакцій у пакет (наразі лише одна транзакція в пакеті), а потім надішле кілька пакетів разом до транзакцій Calldata L1 через функцію SequenceBatch() PolygonZKEvm.sol на L1.

(Слід зазначити, що подається відразу кілька партій, щоб максимально знизити витрату газу L1.)

3. Коли PolygonZkEvm.sol отримує Batches, надані Sequencer, він по черзі обчислює хеш кожної партії в контракті, а потім записує хеш попередньої партії в наступну партію, тому ми отримуємо структуру Batch на наступному малюнку.

4) Також визначається порядок транзакцій у кожній партії, тому при визначенні порядку партії ми вважаємо, що порядок усіх транзакцій, які входять до пакету, що подається до контракту L1 Polygon zkEVM, визначений.

Наведений вище фактичний процес також є роботою, яку L1 має виконати як рівень Rollup DA (на даний момент не завершено жодної державної перевірки чи роботи з просування).

**2. Агрегатор генерує доказ валідності для кількох пакетів транзакцій

1. Коли агрегатор слухає успішну відправку нових пакетів в контракті PolyonZKEVM.sol на L1, він синхронізує ці пакети зі своїм вузлом і відправляє ці транзакції в zkProver.

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

3. zkProver надсилає Aggregator доказ валідності агрегування кількох транзакцій.

3. Агрегатор подає контракт на сукупні докази до L1

Агрегатор надішле цей доказ валідності контракту Polygon zkEvm.sol на L1 разом із відповідним станом пакетного виконання, викликавши наступний метод:

Потім у контракті виконуються наступні дії, щоб перевірити правильність переходу стану.

Коли цей крок буде успішно виконаний в L1-контракті, всі транзакції, що входять в цю частину пакету, дійсно досягнуть Finality (що відповідає закінченню 7-денного періоду оскарження OP).

3. Роль Ethereum у Polygon-zkEVM

Тепер, коли ми розглянули загальний процес Polygon zkEVM, давайте розглянемо, що Ethereum зробив для Rollup:

На першому кроці секвенсер збирає транзакції зведення та упаковує їх у пакети, які потім надсилаються до L1-контракту. L1 не тільки забезпечує функціональність рівня DA, але і фактично завершує деякі функції впорядкування транзакцій, коли ви відправляєте транзакцію в Секвенсер, транзакція насправді не впорядкована, тому що Секвенсер має повноваження змінювати порядок транзакцій за бажанням, але коли транзакція включена в Пакет і представлена в контракті L1, ніхто не має права змінювати порядок транзакцій.

На другому кроці агрегатор приносить доказ валідності до контракту L1, щоб досягти нового стану, агрегатор є роллю, подібною до пропонента, і контракт схожий на роль валідатора, а агрегатор надає доказ валідності, щоб довести, що новий стан правильний, і повідомляє валідатору про валідність, яку я надаю Які пакети транзакцій беруть участь у Proof, і де вони знаходяться в L1.

Потім валідатор витягує відповідну партію з контракту та поєднує її з Validity Proof для перевірки легітимності переходу стану, і якщо перевірка пройде успішно, контракт фактично буде оновлено до нового стану відповідного Validity Proof.

По-четверте, структуруйте Smart Contract Rollup з точки зору модульності

Якщо з точки зору модульності, Polygon zkEVM належить до типу Smart Contract Rollup, ми можемо спробувати деконструювати його модулі, і з діаграми, наведеної Delphi, ми також можемо побачити, що Polygon ZkEVM насправді є Consensus Layer, DA Layer і Settlement of Smart Contrat Rollup Шари фактично пов’язані з контрактом PolygonZkEVM.sol, який не дуже добре розрізняється. Але спробуємо розібрати модулі:

Рівень доступності даних: де зберігаються транзакції зведення, і у випадку Polygon-zkEVM, коли секвенсер викликає метод SequenceBatch(), він фактично включає надсилання даних транзакцій на рівень DA.

Розрахунковий рівень: Конкретно відноситься до механізму грошового потоку між Rollup і L1, а саме офіційного мосту Polygon-zkEVM (докладніше про це в наступній статті).

Рівень консенсусу: містить упорядкування транзакцій і те, як визначити наступний дійсний стан (вибір форку), Секвенсер завершує впорядкування транзакцій, коли викликає SequenceBatch() у контракті L1, і підтверджує наступний юридичний стан, коли агрегатор викликає TustedVerifyBatches() у контракті L1.

Виконавчий рівень: процес, за допомогою якого виконується транзакція та отримується новий стан світу, коли користувач надсилає транзакцію секвенсеру, а новий стан отримується після виконання секвенсера ( Ось чому ми схильні говорити, що Rollups — це обчислювальне масштабування, тому що L1 передає процес виконання транзакцій на аутсорсинг для отримання нового стану Rollups, а Sequencer делегує zkProver для допомоги у генерації Validity Proof через Aggregator.

5. Чому Polygon-zkEVM успадковує безпеку L1

Судячи із загального процесу, описаного вище, Sequencer фактично робить щось схоже на Ethereum Proposer, пропонуючи, щоб пакет транзакцій був дійсними транзакціями, і надаючи новий стан цього пакету транзакцій після виконання, а логіка перевірки L1-контракту еквівалентна тому, що всі валідатори L1 будуть виконуватися у власних клієнтах Ethereum, фактично всі валідатори Ethereum виступають валідаторами Rollup, тому ми думаємо, що Polygon zkEVM Успадкував безпеку Ethereum.

З іншого боку, оскільки всі транзакції та стан Rollups зберігаються на Ethereum, навіть якщо команда Polygon zkEVM втече, будь-хто все одно матиме можливість відновити всю мережу Rollup на основі даних, що зберігаються в Ethereum.

6. Механізм заохочення Polygon zkEVM

Стимули ролапу – це, перш за все, про те, як зробити секвенсер і агрегатор прибутковими, а отже, продовжити роботу?

Перш за все, користувачі повинні сплачувати власні комісії за транзакції в Rollup, які деноміновані в ETH і сплачуються в Bridged ETH.

Секвенсеру потрібно буде сплатити вартість завантаження Batch, що містить транзакцію Rollup, до Calldata транзакції L1 (вартість виклику SequenceBatch(batches()), а Matic повинен буде сплатити певну кількість Matic контракту L1 одночасно з завантаженням пакета, який пізніше сплатить вартість Агрегатора, що надає Validity Proof для цих пакетів.

У той час як Aggregator викликає довірені VerifyBatches для надання доказу валідності для пакетів у контракті L1, які ще не є остаточними, Секвенсер також може вилучити токени MATIC, заздалегідь сплачені Sequencer у контракті, як винагороду за надання доказу валідності.

Дохід секвенсера = плата за газ для всіх транзакцій у зведенні - плата за газ мережі L1, витрачена на завантаження пакетів у L1 - плата за атестацію, що сплачується агрегатору (номінал MATIC).

Дохід агрегатора = Винагороди MATIC, що виплачуються секвенсером - Плата за газ, надіслана до Validity Proof до L1 - Апаратні збори, витрачені на створення доказів валідності.

Відкоригуйте плату за атестацію, що сплачується Агрегатору, і для того, щоб запобігти страйку Секвенсера, передбачено наступний механізм коригування плати за атестацію, що сплачується Секвенсером Агрегатору.

У договорі є метод, який коригує витрати на надання доказів для партій:

function _updateBatchFee(uint64 newLastVerifiedBatch) внутрішня

Він змінює змінну в контракті під назвою BatchFee, яка визначає кількість токенів MATIC, які Sequencer платить за кожну партію.

Механізм змін полягає в наступному:

Контракт підтримує змінну VeryBatchTimeTarget, яка представляє очікуваний стан кожної партії, яка має бути перевірена протягом цього часу після того, як секвенсер зафіксував її в L1.

Контракт запише всі партії, які не були перевірені після перевищення VeryBatchTimeTarget, і загальна кількість цих партій буде записана як DiffBatches.

Тому, коли Batches запізнюється, BatchFee буде скориговано за такою формулою:

MultiplierBatchFee – це число, обмежене діапазоном 1000~1024, яке може бути змінено адміністратором контракту за допомогою функції setMultiplierBatchFee():

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) лише для публічних данихAdmin

Слід зазначити, що використання MultiplierBatchFee і 10^3 тут полягає в досягненні точності коригування після 3 десяткових знаків.

Аналогічно, якщо партії заздалегідь, спрацює відповідний механізм коригування batchFee: DiffBatches вказує кількість партій у стані ранньої перевірки.

Підсумки

У цій статті ми розберемося з основним механізмом Polygon zkEVM і проаналізуємо його доцільність досягнення обчислювального масштабування Ethereum. У наступних статтях ми зануримося в інтер’єр протоколу, аналізуючи деталі дизайну мосту zkEVM, маршрут децентралізації Sequencer, реалізацію zkProver та принципи проектування zkEVM.

——Далі буде——