Первая часть серии 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

Во-первых, нам нужно четко понимать, как работают роллапы. Появление Rollup заключается в масштабировании вычислений Ethereum, конкретный метод реализации заключается в том, чтобы передать выполнение транзакций на аутсорсинг Rollup, а затем сохранить транзакцию и состояние (State) после выполнения транзакции в контракте Ethereum.

Оптимистичный роллап

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

Накопительный пакет с нулевым разглашением

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

См. официальное определение Ethereum:

Самая большая разница между Rollup с нулевым разглашением и Optimistic Rollup заключается в том, что время достижения окончательности отличается из-за разных способов проверки действительности состояния.

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

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

Во-вторых, процесс выполнения Polygon zkEVM

Давайте посмотрим, как работает Polygon zkEVM с простым процессом подтверждения транзакций, чтобы иметь конкретное представление об общем протоколе, и весь его процесс можно разделить на три основных этапа:

1. Секвенсор упаковывает несколько пользовательских транзакций в пакеты и отправляет их в контракт L1.

2. Прувер генерирует доказательство действительности для каждой транзакции и объединяет доказательства действительности нескольких транзакций в одно доказательство действительности.

3. Агрегатор предоставляет доказательство действительности агрегатора, агрегировавшего несколько транзакций в контракт L1.

1 Секвенсор упаковывает пользовательские транзакции в пакеты и отправляет их в контракт L1.

1. Пользователь отправляет транзакцию в Sequencer, и Sequencer будет обрабатывать транзакцию локально в порядке получения (FRFS), когда Sequencer выполняет транзакцию локально, если пользователь считает, что Sequencer честен, то он может считать транзакцию достигшей завершенности. Здесь важно отметить, что большинство мемпулов в Sequencer в настоящее время являются частными, поэтому в настоящее время существует относительно мало MEV, которые можно получить.

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

(Следует отметить, что подается сразу несколько партий, чтобы максимально снизить расход газа L1.)

3. Когда PolygonZkEvm.sol получает пакеты, предоставленные Sequencer, он по очереди вычисляет хэш каждого пакета в контракте, а затем записывает хэш предыдущего пакета в следующий пакет, поэтому мы получаем структуру пакета на следующем рисунке.

4) Также определяется порядок транзакций в каждом пакете, поэтому когда порядок пакета определен, мы считаем, что порядок всех транзакций, которые входят в пакет для отправки в контракт L1 Polygon zkEVM, определен.

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

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

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

2. После получения этих транзакций, zkProver сгенерирует доказательство валидности для каждой транзакции, а затем агрегирует доказательство валидности транзакций, содержащихся в нескольких пакетах, в доказательство валидности.

3. zkProver отправляет доказательство валидности агрегирования нескольких транзакций в Агрегатор.

3. Агрегатор передает контракт на агрегированные доказательства в L1

Агрегатор отправит это доказательство валидности в контракт Polygon zkEvm.sol на L1 вместе с соответствующим состоянием выполнения пакета, вызвав следующий метод:

Затем в рамках контракта выполняются следующие действия, чтобы убедиться в правильности перехода состояния.

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

3. Роль Ethereum в Polygon-zkEVM

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

На первом шаге Sequencer собирает транзакции свертки и упаковывает их в пакеты, которые затем отправляются в контракт L1. L1 не только обеспечивает функциональность уровня DA, но и фактически выполняет некоторые функции упорядочения транзакций, когда вы отправляете транзакцию в Sequencer, транзакция на самом деле не упорядочена, потому что Sequencer имеет право изменять порядок транзакций по своему желанию, но когда транзакция включена в Batch и отправлена в контракт L1, никто не имеет права изменять порядок транзакций.

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

Затем валидатор извлекает соответствующий пакет из контракта и объединяет его с Validity Proof, чтобы проверить легитимность перехода состояния, и если проверка прошла успешно, контракт фактически будет обновлен до нового состояния соответствующего Validity Proof.

В-четвертых, структурируйте Роллап смарт-контракта с точки зрения модульности

Если с точки зрения модульности Polygon zkEVM относится к типу Smart Contract Rollup, мы можем попытаться деконструировать его модули, и из диаграммы, приведенной Delphi, мы также можем увидеть, что Polygon ZkEVM на самом деле является уровнем консенсуса, уровнем DA и расчетом Smart Contrat Rollup Слои на самом деле связаны с контрактом PolygonZkEVM.sol, который не очень хорошо различим. Но давайте попробуем разобрать модули:

Уровень доступности данных: Где хранятся транзакции свертки, и в случае Polygon-zkEVM, когда Sequencer вызывает метод SequenceBatch(), он фактически включает отправку данных транзакции на уровень DA.

Settlement Layer: Конкретно относится к механизму движения денег между Rollup и L1, в частности, к официальному мосту Polygon-zkEVM (подробнее об этом в следующей статье).

Уровень консенсуса: содержит порядок транзакций и способ определения следующего допустимого состояния (выбор вилки), Sequencer завершает упорядочение транзакций при вызове SequenceBatch() в контракте L1 и подтверждает следующее допустимое состояние, когда Aggregator вызывает TustedVerifyBatches() в контракте L1.

Уровень выполнения: Процесс, с помощью которого выполняется транзакция и получается новое мировое состояние, когда пользователь отправляет транзакцию в Sequencer, и новое состояние получается после выполнения Sequencer ( Вот почему мы склонны говорить, что роллапы — это вычислительное масштабирование, потому что L1 передает процесс выполнения транзакций для получения нового состояния на аутсорсинг роллапам, а секвенсор делегирует zkProver для помощи в создании доказательства валидности через агрегатор.

5. Почему Polygon-zkEVM наследует безопасность L1

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

С другой стороны, поскольку все транзакции и состояние роллапов хранятся в Ethereum, даже если команда Polygon zkEVM сбежит, у любого все равно будет возможность восстановить всю сеть Rollup на основе данных, хранящихся в Ethereum.

6. Механизм поощрения Polygon zkEVM

Поощрения за роллап в первую очередь направлены на то, чтобы сделать секвенсор и агрегатор прибыльными и, таким образом, продолжить работу.

Прежде всего, пользователям необходимо оплатить свои собственные комиссии за транзакции на Rollup, которые деноминированы в ETH и оплачены в Bridged ETH.

Sequencer должен будет оплатить стоимость загрузки пакета, содержащего транзакцию Rollup, в Calldata транзакции L1 (стоимость вызова SequenceBatch(batches()), и Matic должен будет заплатить определенное количество Matic контракту L1 одновременно с загрузкой пакета, что позже оплатит стоимость Aggregator, предоставляющего доказательство валидности для этих пакетов.

В то время как агрегатор вызывает доверенные VerifyBatches для предоставления доказательства валидности для пакетов в контракте L1, которые еще не были завершены, Sequencer также может взять токены MATIC, заранее оплаченные Sequencer в контракте, в качестве вознаграждения за предоставление доказательства действительности.

Выручка секвенсора = плата за газ для всех транзакций в роллапе - плата за газ сети L1, потраченная на загрузку пакетов в L1 - плата за аттестацию, уплаченная агрегатору (номинал MATIC).

Доход агрегатора = вознаграждения MATIC, выплаченные секвенсором - плата за газ, отправленная в подтверждение действительности в L1 - плата за оборудование, потраченная на создание доказательств валидности.

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

В договоре есть метод, который корректирует стоимость предоставления доказательств для партий:

функция _updateBatchFee(uint64 newLastVerifiedBatch) внутренняя

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

Механизм изменения следующий:

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

Контракт будет записывать все пакеты, которые не были проверены после превышения VeryBatchTimeTarget, и общее количество этих пакетов будет записано как DiffBatches.

Таким образом, когда пакеты задерживаются, BatchFee будет скорректирован по следующей формуле:

MultiplierBatchFee - это число, которое ограничено диапазоном 1000~1024, которое может быть изменено администратором контракта через функцию setMultiplierBatchFee():

Набор функцийMultiplier BatchFee(uint16newMultiplierBatchFee) только публичныйAdmin

Следует отметить, что использование MultiplierBatchFee и 10^3 здесь заключается в достижении точности корректировки после 3 знаков после запятой.

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

Резюме

В этой статье мы разберемся с основным механизмом Polygon zkEVM и проанализируем его возможность достижения вычислительного масштабирования Ethereum. В следующих статьях мы углубимся во внутреннюю часть протокола, проанализировав детали проектирования zkEVM Bridge, маршрут децентрализации Sequencer, реализацию zkProver и принципы проектирования zkEVM.

——Продолжение следует——