Я бачив друга, який скаржився, що @zkSync постійно не працює. Насправді назвати це «простоєм» трохи перебільшено. Якщо бути точним, це «нестабільна генерація блоків».
По суті, остаточний перевірений час транзакції, надісланий Sequencer, є нестабільним, але сприйняття користувача неочевидне в інтерактивному кінці, оскільки дизайн перевірки zkSync має затримку підтвердження.
Нестабільність на майбутньому етапі децентралізації буде послаблена. Я намалював робочий процес для обговорення з вами.
Причиною, чому користувачі сприймають простой, може бути збій транзакції, спричинений деякими DApps, і основна сумісність ланцюжка. Зрештою, розробка DApps на zkSync сама по собі дуже складна.
Мені потрібно близько 30 хвилин-1 години, щоб спостерігати за зміною статусу з Commit на Verified з офіційного веб-переглядача, тоді як інтерактивний DApp на стороні користувача це майже не впливає.
Ця стаття присвячена основній логіці науково-популярної технології zkSync і дає вам чітке розуміння zkSync.
Як показано в робочому процесі, zkSync виконується за такими кроками:
Користувач надсилає пакетні транзакції до секвенсора через ретрансляцію;
Секвенсор відповідає за сортування транзакцій, агрегування та упаковку пакетів у дерево Merkle;
zkPorter генерує сертифікати zk-SNARK з дерева Merkle; сертифікати zk-SNARK відповідно ретранслюються до валідаторів L2 та основного ланцюга L1 для генерації хешу фіксації; валідатори відповідають за перевірку
Правильність підтвердження zk-SNARK надсилається в смарт-контракт L1 для генерації верифікаційного хешу;
Смарт-контракт zkSync на L1 перевіряє відповідність Commit Hash і Verify Hash;
Після успішного зіставлення генерується перевірена транзакція, і транзакція остаточно завантажується в ланцюжок;
Якщо зіставлення не вдасться, вихідний хеш фіксації буде визнано недійсним, а секвенсор повторно надішле пакет і повторить процес.
Тут слід підкреслити, що zkSync використовує «двофазову фіксацію (2PC)» і, нарешті, визначає легальну партію транзакцій за допомогою перевірки хешу на двох етапах фіксації хешу та перевірки хешу.
З одного боку, це може забезпечити узгодженість даних і безпеку в процесі роботи системи.На моє особисте розуміння це також є проявом ідеї децентралізації, яка обмежує два компоненти системи, Sequencer і Validator, і є гідною похвали.
Робочий процес zkSync в основному виконує чотири ролі: ретранслятор, секвенсер, zkPorter і валідатор.У роботі координації буде багато «нестабільних факторів».
Це можна підсумувати як стабільність функцій вузла, стабільність взаємодії вузла та складність алгоритмів і базових протоколів. Будь-яка помилка в будь-якому посиланні може спричинити затримку блокування. Поширені технічні збої Arbitrum Sequencer є типовими, і zkSync стикається лише з більшими проблемами.
Що стосується складності алгоритму, то це доля ланцюжка zkSync, і екологічним розробникам потрібно багато працювати, щоб її подолати. Що стосується стабільності інтелекту вузлів і співпраці, я думаю, що після настання етапу децентралізації в майбутньому вони будуть ефективно покращені. Логіка також проста:
Кілька розподілених вузлів можуть уникнути нестабільності мережі, викликаної єдиною точкою збою, а система є надійною; механізм стимулювання розподілених токенів може надати розробникам джерело мотивації підтримувати стабільність вузла.
З іншого боку, тривалий час верифікації не є проблемою на ранній стадії екології. Це може ефективно покращити безпеку ланцюга та запобігти деяким вузлам у системі від шкоди.
Коротше кажучи, якщо ви проясните весь процес роботи zkSync і глибше зрозумієте технічну складність рівня 2 і «спеціальний» механізм, призначений для безпеки, ви зможете зміцнити свою впевненість у технічній версії L2.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Механізм роботи zkSync налагоджений, він не простоює часто
Я бачив друга, який скаржився, що @zkSync постійно не працює. Насправді назвати це «простоєм» трохи перебільшено. Якщо бути точним, це «нестабільна генерація блоків».
По суті, остаточний перевірений час транзакції, надісланий Sequencer, є нестабільним, але сприйняття користувача неочевидне в інтерактивному кінці, оскільки дизайн перевірки zkSync має затримку підтвердження.
Нестабільність на майбутньому етапі децентралізації буде послаблена. Я намалював робочий процес для обговорення з вами.
Причиною, чому користувачі сприймають простой, може бути збій транзакції, спричинений деякими DApps, і основна сумісність ланцюжка. Зрештою, розробка DApps на zkSync сама по собі дуже складна.
Мені потрібно близько 30 хвилин-1 години, щоб спостерігати за зміною статусу з Commit на Verified з офіційного веб-переглядача, тоді як інтерактивний DApp на стороні користувача це майже не впливає.
Ця стаття присвячена основній логіці науково-популярної технології zkSync і дає вам чітке розуміння zkSync.
Як показано в робочому процесі, zkSync виконується за такими кроками:
Користувач надсилає пакетні транзакції до секвенсора через ретрансляцію;
Секвенсор відповідає за сортування транзакцій, агрегування та упаковку пакетів у дерево Merkle;
zkPorter генерує сертифікати zk-SNARK з дерева Merkle; сертифікати zk-SNARK відповідно ретранслюються до валідаторів L2 та основного ланцюга L1 для генерації хешу фіксації; валідатори відповідають за перевірку
Правильність підтвердження zk-SNARK надсилається в смарт-контракт L1 для генерації верифікаційного хешу;
Смарт-контракт zkSync на L1 перевіряє відповідність Commit Hash і Verify Hash;
Після успішного зіставлення генерується перевірена транзакція, і транзакція остаточно завантажується в ланцюжок;
Якщо зіставлення не вдасться, вихідний хеш фіксації буде визнано недійсним, а секвенсор повторно надішле пакет і повторить процес.
Тут слід підкреслити, що zkSync використовує «двофазову фіксацію (2PC)» і, нарешті, визначає легальну партію транзакцій за допомогою перевірки хешу на двох етапах фіксації хешу та перевірки хешу.
З одного боку, це може забезпечити узгодженість даних і безпеку в процесі роботи системи.На моє особисте розуміння це також є проявом ідеї децентралізації, яка обмежує два компоненти системи, Sequencer і Validator, і є гідною похвали.
Робочий процес zkSync в основному виконує чотири ролі: ретранслятор, секвенсер, zkPorter і валідатор.У роботі координації буде багато «нестабільних факторів».
Це можна підсумувати як стабільність функцій вузла, стабільність взаємодії вузла та складність алгоритмів і базових протоколів. Будь-яка помилка в будь-якому посиланні може спричинити затримку блокування. Поширені технічні збої Arbitrum Sequencer є типовими, і zkSync стикається лише з більшими проблемами.
Що стосується складності алгоритму, то це доля ланцюжка zkSync, і екологічним розробникам потрібно багато працювати, щоб її подолати. Що стосується стабільності інтелекту вузлів і співпраці, я думаю, що після настання етапу децентралізації в майбутньому вони будуть ефективно покращені. Логіка також проста:
Кілька розподілених вузлів можуть уникнути нестабільності мережі, викликаної єдиною точкою збою, а система є надійною; механізм стимулювання розподілених токенів може надати розробникам джерело мотивації підтримувати стабільність вузла.
З іншого боку, тривалий час верифікації не є проблемою на ранній стадії екології. Це може ефективно покращити безпеку ланцюга та запобігти деяким вузлам у системі від шкоди.
Коротше кажучи, якщо ви проясните весь процес роботи zkSync і глибше зрозумієте технічну складність рівня 2 і «спеціальний» механізм, призначений для безпеки, ви зможете зміцнити свою впевненість у технічній версії L2.