В ходе стресс-теста zkSync успешно прошел «открытое обучение»

Автор оригинала: Haotian (X: @tmel0211)

Примечание редактора: трек надписи все еще горячий, цепочка zkSync была затоплена огромным количеством транзакций за короткий промежуток времени, в этом “стресс-тесте” zkSync не работает из-за надписи, или он был протестирован идеально? Криптоисследователь Haotian (X:@tmel0211) разъяснил иллюзию и непонимание «плохого опыта» zkSync из технической логики, а Odaily Planet Daily разобрался в этом следующим образом:

Надпись, выгравированная на цепочке zkSync и краткосрочный приток заоблачных транзакций действительно являются «стресс-тестом» работоспособности публичной сети Layer 2, но результатом является не «даунтайм», наоборот, это @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, и секвенсор zkSync назначит nonce этим транзакциям в соответствии со временем, а затем отсортирует их по порядку.

Однако, если пользователь отправляет новую транзакцию одновременно после того, как увидел, что предыдущая транзакция не удалась в предыдущем разделе MetaMask, вполне вероятно, что некоторые из вновь отправленных транзакций не будут успешно отправлены в очередь RPC из-за проблемы на стороне кошелька и вызова интерфейса API zkSync. Пользователи думают, что было отправлено много транзакций, но на самом деле zkSync получил только часть из них, и как только они их получат, они их отсортируют.

Глядя на это с этой точки зрения, пользователи видят, что MetaMask сообщает о том, что транзакции не удались, и акт постоянной отправки новых транзакций также вызовет большое количество сбоев транзакций, потому что отправка в бэкенд цепочки zkSync вообще отсутствует, но вы думаете, что отправили ее на фронтенде. **

В целом, проблемы с логикой времени отклика RPC-кошелька MetaMask и спешка пользователей с наложением транзакций в цепочке приведут к большому количеству «сбоев» транзакций, и относительно легче избежать этих проблем с оптимизацией, если вы четко представляете себе внутренний рабочий процесс обработки транзакций zkSync.

-Исходя из приведенной выше научно-популярной литературы, давайте проясним проблему “простоя”:

Цепочка zkSync не “не работает”, это просто проблема отображения на фронтенде браузера, потому что браузер будет тянуть последние данные через RPC-интерфейс zkSync, но будет задержка в ответе интерфейса, и большое количество новых транзакций замедлит ответ.

Короче говоря, скорость синхронизации данных по запросу в браузере не поспевает за всплеском транзакций в очереди, что является проблемой с интерфейсом браузера и не имеет ничего общего с работой цепочки. **Проблема обычно решается, когда скорость транзакции соответственно замедляется и браузер может собирать новые данные.

Когда браузер не работает, вы можете использовать другие браузеры, которые синхронизируют информацию о данных блока zkSync для перекрестной проверки, например:

-Какова «операционная производительность» реальной цепочки?

1. После того, как появились так называемые слухи об отключении, официальный персонал zkSync @anthonykrose опубликовал в Твиттере обновления 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, и их положительные эффекты перевешивают отрицательные. ** В долгосрочной перспективе инцидент с надписью не вызвал слухов, а скорее дал практический опыт для дальнейшей оптимизации производительности уровня 2. **

Однако, насколько я знаю, помимо Sync чеканятся и другие надписи, которые не такие fomo, как Sync, но подливают масла в огонь этого стресс-теста.

В любом случае, результаты в целом хорошие, если прояснить техническую логику блоков сортировки бэкенда zkSync, а затем избавиться от недоразумения “плохого опыта”, то должно быть понятно, что все работает хорошо, и нам нужно придать layer 2 чуть больше уверенности.

Ссылка на оригинальную статью