Манія написів передається на рівень 2, чому zkSync може пройти стрес-тест захмарної торгівлі?

Написано: Haotian

Вигравіруваний напис на ланцюжку zkSync і короткочасний приплив захмарних транзакцій - це дійсно “стрес-тест” працездатності публічного ланцюжка layer2, але результат не є “простоєм”, навпаки, це публічне тренування 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, часто публікував у 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, а потім позбудетеся від нерозуміння “поганого досвіду”, то повинні розуміти, що все працює добре, і ми повинні надати layer2 трохи більше впевненості.