Я бачив, як деякі друзі скаржилися на те, що 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 для генерації хешу перевірки, якщо він правильний;
Смарт-контракт zkSync на L1 перевіряє відповідність Commit Hash і Verify Hash;
Після успішного зіставлення генерується перевірена транзакція, яка остаточно завантажується в ланцюжок;
Якщо зіставлення не вдається, оригінальний хеш фіксації буде визнано недійсним, а секвенсор повторно надішле пакет і повторить процес.
Тут слід підкреслити, що **zkSync приймає «двофазну фіксацію (2PC)» і остаточно визначає легальну партію транзакцій за допомогою перевірки хешу на двох етапах «Фіксація хешу» та «Перевірка хешу». З одного боку, це може забезпечити узгодженість даних і безпеку в процесі роботи системи.На моє особисте розуміння це також є проявом ідеї децентралізації, яка обмежує два компоненти системи, Sequencer і Validator, і гідна похвали. **
Робочий процес zkSync в основному виконує чотири ролі: ретранслятор, секвенсер, zkPorter і валідатор. У координаційній роботі буде багато «нестабільних факторів». Це можна підсумувати як стабільність функцій вузла, стабільність взаємодії вузла та складність алгоритмів і базових протоколів. Будь-яка помилка в будь-якому посиланні може спричинити затримку блокування. Звичайні технічні збої Arbitrum Sequencer є типовими, і zkSync зіткнеться з новими проблемами.
Що стосується складності алгоритму, то це доля ланцюжка zkSync, і екологічним розробникам потрібно багато працювати, щоб її подолати. Що стосується стабільності інтелекту **вузлів і співпраці, я думаю, що після настання етапу децентралізації в майбутньому вони будуть ефективно покращені. **Логіка також проста:
1) Багаторозподілені вузли можуть уникнути нестабільності мережі, спричиненої єдиною точкою збою, яка пов’язана з надійністю системи;
**2) Механізм заохочення розподілених токенів може надати розробникам джерело мотивації для підтримки стабільності вузла. **
З іншої точки зору, тривалий час **перевірки не є проблемою на ранній стадії екології. Це може ефективно покращити безпеку ланцюга та запобігти деяким вузлам у системі робити зло. ** Коротше кажучи, якщо ви проясните весь процес роботи 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 для генерації хешу перевірки, якщо він правильний;
Смарт-контракт zkSync на L1 перевіряє відповідність Commit Hash і Verify Hash;
Після успішного зіставлення генерується перевірена транзакція, яка остаточно завантажується в ланцюжок;
Якщо зіставлення не вдається, оригінальний хеш фіксації буде визнано недійсним, а секвенсор повторно надішле пакет і повторить процес.
Тут слід підкреслити, що **zkSync приймає «двофазну фіксацію (2PC)» і остаточно визначає легальну партію транзакцій за допомогою перевірки хешу на двох етапах «Фіксація хешу» та «Перевірка хешу». З одного боку, це може забезпечити узгодженість даних і безпеку в процесі роботи системи.На моє особисте розуміння це також є проявом ідеї децентралізації, яка обмежує два компоненти системи, Sequencer і Validator, і гідна похвали. **
Робочий процес zkSync в основному виконує чотири ролі: ретранслятор, секвенсер, zkPorter і валідатор. У координаційній роботі буде багато «нестабільних факторів». Це можна підсумувати як стабільність функцій вузла, стабільність взаємодії вузла та складність алгоритмів і базових протоколів. Будь-яка помилка в будь-якому посиланні може спричинити затримку блокування. Звичайні технічні збої Arbitrum Sequencer є типовими, і zkSync зіткнеться з новими проблемами.
Що стосується складності алгоритму, то це доля ланцюжка zkSync, і екологічним розробникам потрібно багато працювати, щоб її подолати. Що стосується стабільності інтелекту **вузлів і співпраці, я думаю, що після настання етапу децентралізації в майбутньому вони будуть ефективно покращені. **Логіка також проста:
1) Багаторозподілені вузли можуть уникнути нестабільності мережі, спричиненої єдиною точкою збою, яка пов’язана з надійністю системи;
**2) Механізм заохочення розподілених токенів може надати розробникам джерело мотивації для підтримки стабільності вузла. **
З іншої точки зору, тривалий час **перевірки не є проблемою на ранній стадії екології. Це може ефективно покращити безпеку ланцюга та запобігти деяким вузлам у системі робити зло. ** Коротше кажучи, якщо ви проясните весь процес роботи zkSync і глибше зрозумієте технічну складність рівня 2 і «особливий» механізм, розроблений для безпеки, ви зможете зміцнити свою впевненість у технічній версії L2. Кожен може пересилати та ділитися, надсилати мені DM у будь-який час, і давайте поглиблено обмінюватися та вивчати zkSync.