Inscription mania передается на Layer 2, почему zkSync может пройти стресс-тест заоблачной торговли?

Question

**Автор: Haotian**Надпись, выгравированная на цепочке zkSync и краткосрочный приток заоблачных транзакций — это действительно «стресс-тест» работоспособности публичной цепочки layer2, но результат — не «даунтайм», наоборот, это публичное обучение zkSync, и в результате пик TPS и стабильность GAS были отлично протестированы.На первый взгляд, не кажется ли вам это немного нелогичным? Далее, с технической логикой, позвольте мне прояснить ее для вас:Принцип работы блоков упаковки zkSync прост: пользователи конструируют транзакции в последовательность сортировки zkSync Sequencer, а затем Sequencer упаковывает их в блоки в соответствии с рейтингом платы за газ, а затем передает блоки в систему Proof для проверки, и, наконец, отправляет их в основную сеть для завершения подтверждения статуса завершенности.Здесь есть 2 ключевых момента, которые легко могут создать иллюзию «плохого опыта»:1) Пользователи создают транзакции: Большинство пользователей инициируют транзакции через кошельки, такие как Metamask, и отправляют транзакции в zkSync через кошельки, и транзакции сначала поступают на сервер удаленного вызова RPC, а затем Sequencer получает эти транзакции и входит в последовательность очереди. Время ожидания в очереди здесь может составлять от нескольких секунд до нескольких минут, и если вы будете ждать долго, MetaMask будет считать, что транзакция не удалась, а затем фронтенд вернет сообщение о том, что транзакция не удалась.Однако это не означает, что транзакция на самом деле завершилась сбоем, а только потому, что существует «несовместимость» между временем отклика RPC и логикой обратной связи Metamask и логикой транзакций Sequencer zkSync. Вот почему, подождав некоторое время, бэкенд-сервер показывает, что некоторые транзакции, которые MetaMask показывает как неудачные.Если пользователь не проходит через конвейер кошелька и напрямую использует бэкенд-код для вызова RPC zkSync, времени ожидания ответа и сбоя запроса не будет, и работа будет относительно гладкой. Это дает преимущество некоторым "ученым", которые могут использовать инструкции бэкенд-кода, но по сути это проблема со стороны кошелька и не имеет ничего общего с вычислительной мощностью цепочки zkSync.2) Ссылка справедливого упорядочения секвенсора: когда пользователь отправляет транзакцию в очередь RPC на короткое время, каждая транзакция будет наложена со значения nonce 0, если предыдущая транзакция все еще находится в состоянии очереди, nonce равен 0, то пользователь инициирует новую транзакцию с nonce 1, Sequencer zkSync назначит nonce этим транзакциям в соответствии со временем, а затем отсортирует их по порядку.Однако, если пользователь отправляет новую транзакцию одновременно после того, как увидел, что предыдущая транзакция не удалась в предыдущем разделе MetaMask, вполне вероятно, что некоторые из вновь отправленных транзакций не будут успешно отправлены в очередь RPC из-за проблемы на стороне кошелька и вызова интерфейса API zkSync. Пользователи думают, что было отправлено много транзакций, но на самом деле zkSync получил только часть из них, и как только они их получат, они их отсортируют.Глядя на это с этой точки зрения, пользователи видят, что MetaMask сообщает о том, что транзакции не удались, и поведение постоянной отправки новых транзакций также вызовет большое количество сбоев транзакций, потому что отправка в бэкенд цепочки zkSync вообще отсутствует, но вы думаете, что отправили ее на фронтенде.В целом, логика времени отклика RPC кошелька MetaMask и спешка пользователя с наложением транзакций в цепочку приведут к большому количеству «сбоев» транзакций, и этих проблем с оптимизацией относительно легко избежать, если вы четко представляете себе фоновый рабочий процесс обработки транзакций zkSync.Исходя из вышеприведенного научно-популярного рассказа, внесем ясность в проблему «простоя»:Цепочка zkSync не "не работает", это просто проблема отображения на фронтенде браузера, потому что браузер будет тянуть последние данные через RPC-интерфейс zkSync, но будет задержка в ответе интерфейса, и большое количество новых транзакций замедлит ответ.Короче говоря, скорость синхронизации данных по запросу в браузере не успевает за скоростью распространения транзакций в очереди, что является проблемой интерфейса браузера и не имеет ничего общего с работой цепочки. Как правило, проблема решается, когда скорость транзакции соответствующим образом замедляется и браузер может фиксировать новые данные.Когда браузер не работает, вы можете использовать другие браузеры, которые синхронизируют информацию о данных блока zkSync для перекрестной проверки, например:Какова «операционная эффективность» реальной цепочки?1) После того, как появились так называемые слухи об отключениях, Энтони Роуз, официальный сотрудник zkSync, часто публиковал в Твиттере отчеты об обновлении TPS. Фактически, zkSync TPS взлетел до пика 187,9, а при нормальных обстоятельствах TPS составляет всего около 50-100, что указывает на большой приток новых транзакций, и zkSync фактически сопротивляется давлению. Это действительно достаточный «стресс-тест» для тысяч, а то и десятков тысяч TPS в будущем.2) Специальный механизм ZK-Rollup определяет, что чем больше объем обрабатываемой транзакции, тем дешевле плата за газ, на самом деле, плата за газ zkSync действительно дешевле, потому что стоимость транзакции также распределяется, согласно данным growthepie, за последние 24 часа средний газ zkSync также снизился на 5,2%, в среднем около 0,19 доллара, эти данные могут быть не одинаковыми для всех, но данные об операциях интегрированной цепочки действительно дешевле. Это доказывает, что для более плавного взаимодействия с ZK-Rollup необходимо на порядок увеличить масштаб существующего пользователя.Каково влияние событий регистрации на публичные цепочки уровня 2?Согласно данным dune, чеканка надписей Sync добавила 5 миллионов транзакций за 14 часов, и в ней приняли участие 65 575 держателей. Как упоминалось выше, должностные лица zkSync знают об этом инициированном сообществом «стресс-тесте» и предпринимают срочные шаги для обеспечения упорядоченной работы цепочки zkSync.Эти данные действительно являются хорошим стресс-тестом для zkSync, и их положительные эффекты перевешивают отрицательные. В долгосрочной перспективе инцидент с записью не вызвал бурных событий, а скорее дал практический опыт для дальнейшей оптимизации производительности Layer 2.Однако, насколько я знаю, помимо Sync чеканятся и другие надписи, которые не такие fomo, как Sync, но подливают масла в огонь этого стресс-теста.В любом случае, результаты в целом хорошие, если прояснить техническую логику сортировки блоков бэкендом zkSync, а затем избавиться от недоразумения "плохого опыта", то должно быть понятно, что все работает хорошо, и мы должны дать layer2 чуть больше уверенности.