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