Під написом стрес-тест zkSync завершив успішне "відкрите навчання"

Оригінальний автор: Haotian (X: @tmel0211)

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

Вигравіруваний напис на ланцюжку zkSync і короткочасний приплив захмарних транзакцій дійсно є «стрес-тестом» працездатності публічного ланцюжка Layer 2, але результат не є «простоєм», навпаки, це @zksync публічне навчання, і в результаті пік TPS, стабільність GAS і т.д. були ідеально протестовані. **

На перший погляд, чи не звучить це трохи нелогічно? Далі, з технічною логікою, дозвольте мені пояснити це для вас:

Принцип роботи блоків упаковки zkSync полягає в наступному: користувачі конструюють транзакції в послідовність сортування zkSync Sequencer, а потім Секвенсер упаковує їх у блоки відповідно до ранжування плати gas, а потім передає блоки в систему 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 через проблему на стороні гаманця та виклику інтерфейсу zkSync API. Користувачі думають, що транзакцій було відправлено дуже багато, але насправді zkSync отримав лише частину з них, і як тільки вони їх отримають, вони їх відсортують.

Дивлячись на це таким чином, користувачі бачать, що MetaMask повідомляє про те, що транзакції не відбулися, і акт постійного подання нових транзакцій також спричинить велику кількість збоїв транзакцій, тому що подання до бекенду ланцюжка zkSync взагалі відсутнє, але ви думаєте, що надіслали його на фронтенді. **

Загалом, проблеми з логікою часу відгуку RPC гаманця MetaMask і поспіх користувачів накладати транзакції в ланцюжку спричинять велику кількість «збоїв» транзакцій, і відносно легше уникнути цих проблем з оптимізацією, якщо ви чітко знаєте робочий процес обробки транзакцій zkSync.

-Виходячи з наведеного вище науково-популярного, уточнимо проблему «простою»:

Ланцюжок zkSync не “даун”, це просто проблема відображення на фронтенді браузера, тому що браузер буде підтягувати останні дані через RPC інтерфейс zkSync, але буде затримка у відповіді інтерфейсу, і велика кількість нових транзакцій буде гальмувати відповідь.

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

Якщо браузер не працює, ви можете використовувати інші браузери, які синхронізують інформацію про дані блоку zkSync для перехресної перевірки, наприклад:

-Яка «операційна ефективність» реального ланцюга?

1. Після того, як з’явилися чутки про так звані відключення, офіційні співробітники zkSync @anthonykrose опублікували в Twitter оновлення TPS. Фактично zkSync TPS злетів до піку 187,9, а за звичайних обставин TPS становить лише близько 50-100, що свідчить про величезний приплив нових транзакцій, і zkSync фактично встояв перед тиском. Це забезпечує повний «стрес-тест» для тисяч, якщо не десятків тисяч, TPS у майбутньому.

2. Спеціальний механізм ZK-Rollup визначає, що чим більший обсяг обробленої транзакції, тим дешевша плата за газ, насправді комісія за газ zkSync дійсно дешевша, тому що вартість транзакції також поділяється, згідно з даними growthepie, **За останні 24 години середній газ zkSync також знизився на 5,2%, із середнім показником близько $0,19, ці дані можуть бути не однаковими для всіх, але дані про роботу інтегрованого ланцюга справді дешевші. **Це доводить, що для більш плавної роботи ZK-Rollup потрібне на порядок збільшення існуючої шкали користувача.

-Вплив подій написів на публічні ланцюжки рівня 2?

Згідно з даними дюни, карбування написів Sync додало 5 мільйонів транзакцій за 14 годин, і в ньому взяли участь 65 575 власників. Як згадувалося вище, офіційні особи zkSync знають про цей ініційований спільнотою «стрес-тест» і вживають термінових заходів, щоб переконатися, що ланцюжок zkSync працює впорядковано.

Ці дані дійсно є хорошим експериментом зі стрес-тестом для zkSync, і його позитивні ефекти переважують негативні. ** У довгостроковій перспективі інцидент з написом не став подальшим, а скоріше надав практичний досвід для подальшої оптимізації продуктивності рівня 2. **

Однак, наскільки мені відомо, крім Sync карбуються й інші написи, які не такі fomo, як Sync, але підливають масла у вогонь цього стрес-тесту.

Так чи інакше, результати в цілому хороші, якщо ви проясните технічну логіку бекенд-сортування блоків zkSync, а потім позбудетеся від нерозуміння “поганого досвіду”, ви повинні розуміти, що все працює добре, і нам потрібно надати 2 рівню трохи більше впевненості.

Посилання на оригінал статті