Я видел друга, жалующегося, что @zkSync всегда не работает, На самом деле, называть это «временем простоя» — это немного преувеличение, если быть точным, это «нестабильная генерация блоков».
По сути, окончательное проверенное время транзакции, отправленное Sequencer, нестабильно, но восприятие пользователя не является очевидным в интерактивном конце, потому что дизайн zkSync Verify имеет задержку подтверждения.
Нестабильность на будущем этапе децентрализации будет смягчена. Я нарисовал рабочий процесс, чтобы обсудить с вами.
Причиной, по которой пользователи воспринимают «время простоя», может быть проблема сбоя транзакции, вызванная совместимостью между некоторыми DApps и нижним уровнем цепочки.В конце концов, разработка DApps на самом zkSync очень сложна.
Мне требуется около 30 минут-1 час, чтобы наблюдать за изменением статуса с Commit на Verified в официальном браузере, в то время как на интерактивное DApp на стороне пользователя это практически не влияет.
Эта статья посвящена базовой логике научно-популярной технологии zkSync и дает вам четкое представление о zkSync.
Как показано в рабочем процессе, zkSync выполняется в следующие этапы:
Пользователь отправляет пакетные транзакции в Sequencer через релейную пересылку;
Sequencer отвечает за сортировку транзакций, агрегирование и упаковку пакетов в дерево Меркла;
zkPorter генерирует сертификаты zk-SNARK из дерева Merkle, сертификаты zk-SNARK соответственно передаются валидаторам L2 и основной цепочке L1 для генерации хэша фиксации, валидаторы отвечают за проверку
Корректность доказательства zk-SNARK передается смарт-контракту L1 для генерации Verify Hash;
Смарт-контракт zkSync на L1 проверяет соответствие Commit Hash и Verify Hash;
После успешного сопоставления генерируется проверенная транзакция, и транзакция, наконец, загружается в цепочку;
Если сопоставление не удается, исходный хэш фиксации будет признан недействительным, и секвенсор повторно отправит пакет и повторит процесс.
Здесь необходимо подчеркнуть, что zkSync принимает «двухэтапную фиксацию (2PC)» и, наконец, определяет пакет законных транзакций посредством проверки хэша на двух этапах фиксации хэша и проверки хэша.
С одной стороны, это может обеспечить непротиворечивость данных и безопасность в процессе работы системы, а также в моем личном понимании является проявлением идеи децентрализации, сдерживающей два компонента системы, Sequencer и Validator, и достойным похвалы.
Рабочий процесс zkSync в основном имеет четыре роли: Relay, Sequencer, zkPorter и Validator.В работе координации будет много «нестабильных факторов».
Его можно резюмировать как стабильность функций узлов, стабильность взаимодействия узлов и сложность алгоритмов и базовых протоколов. Любая ошибка в любой ссылке может вызвать задержку блокировки. Общие технические сбои Arbitrum Sequencer типичны, и zkSync столкнется с еще большими проблемами.
Что касается сложности алгоритма, то это судьба цепочки zkSync, и экологическим разработчикам нужно потрудиться, чтобы ее преодолеть. Что касается стабильности нодового интеллекта и совместной работы, я думаю, что после наступления этапа децентрализации в будущем она будет эффективно улучшена. Логика тоже проста:
Несколько распределенных узлов могут избежать нестабильности сети, вызванной одной точкой отказа, а система является надежной; механизм поощрения распределенных токенов может предоставить разработчикам источник мотивации для поддержания стабильности узла.
Если подумать под другим углом, то долгое время верификации не является проблемой на ранней стадии экологии, оно может эффективно повысить безопасность цепи и не допустить, чтобы некоторые узлы в системе совершали зло.
Короче говоря, если вы проясните весь процесс работы zkSync и дополнительно поймете техническую сложность уровня 2 и «специальный» механизм, предназначенный для обеспечения безопасности, вы сможете укрепить свою уверенность в техническом треке L2.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Механизм работы zkSync отлажен, он не часто "зависает"
Я видел друга, жалующегося, что @zkSync всегда не работает, На самом деле, называть это «временем простоя» — это немного преувеличение, если быть точным, это «нестабильная генерация блоков».
По сути, окончательное проверенное время транзакции, отправленное Sequencer, нестабильно, но восприятие пользователя не является очевидным в интерактивном конце, потому что дизайн zkSync Verify имеет задержку подтверждения.
Нестабильность на будущем этапе децентрализации будет смягчена. Я нарисовал рабочий процесс, чтобы обсудить с вами.
Причиной, по которой пользователи воспринимают «время простоя», может быть проблема сбоя транзакции, вызванная совместимостью между некоторыми DApps и нижним уровнем цепочки.В конце концов, разработка DApps на самом zkSync очень сложна.
Мне требуется около 30 минут-1 час, чтобы наблюдать за изменением статуса с Commit на Verified в официальном браузере, в то время как на интерактивное DApp на стороне пользователя это практически не влияет.
Эта статья посвящена базовой логике научно-популярной технологии zkSync и дает вам четкое представление о zkSync.
Как показано в рабочем процессе, zkSync выполняется в следующие этапы:
Пользователь отправляет пакетные транзакции в Sequencer через релейную пересылку;
Sequencer отвечает за сортировку транзакций, агрегирование и упаковку пакетов в дерево Меркла;
zkPorter генерирует сертификаты zk-SNARK из дерева Merkle, сертификаты zk-SNARK соответственно передаются валидаторам L2 и основной цепочке L1 для генерации хэша фиксации, валидаторы отвечают за проверку
Корректность доказательства zk-SNARK передается смарт-контракту L1 для генерации Verify Hash;
Смарт-контракт zkSync на L1 проверяет соответствие Commit Hash и Verify Hash;
После успешного сопоставления генерируется проверенная транзакция, и транзакция, наконец, загружается в цепочку;
Если сопоставление не удается, исходный хэш фиксации будет признан недействительным, и секвенсор повторно отправит пакет и повторит процесс.
Здесь необходимо подчеркнуть, что zkSync принимает «двухэтапную фиксацию (2PC)» и, наконец, определяет пакет законных транзакций посредством проверки хэша на двух этапах фиксации хэша и проверки хэша.
С одной стороны, это может обеспечить непротиворечивость данных и безопасность в процессе работы системы, а также в моем личном понимании является проявлением идеи децентрализации, сдерживающей два компонента системы, Sequencer и Validator, и достойным похвалы.
Рабочий процесс zkSync в основном имеет четыре роли: Relay, Sequencer, zkPorter и Validator.В работе координации будет много «нестабильных факторов».
Его можно резюмировать как стабильность функций узлов, стабильность взаимодействия узлов и сложность алгоритмов и базовых протоколов. Любая ошибка в любой ссылке может вызвать задержку блокировки. Общие технические сбои Arbitrum Sequencer типичны, и zkSync столкнется с еще большими проблемами.
Что касается сложности алгоритма, то это судьба цепочки zkSync, и экологическим разработчикам нужно потрудиться, чтобы ее преодолеть. Что касается стабильности нодового интеллекта и совместной работы, я думаю, что после наступления этапа децентрализации в будущем она будет эффективно улучшена. Логика тоже проста:
Несколько распределенных узлов могут избежать нестабильности сети, вызванной одной точкой отказа, а система является надежной; механизм поощрения распределенных токенов может предоставить разработчикам источник мотивации для поддержания стабильности узла.
Если подумать под другим углом, то долгое время верификации не является проблемой на ранней стадии экологии, оно может эффективно повысить безопасность цепи и не допустить, чтобы некоторые узлы в системе совершали зло.
Короче говоря, если вы проясните весь процесс работы zkSync и дополнительно поймете техническую сложность уровня 2 и «специальный» механизм, предназначенный для обеспечения безопасности, вы сможете укрепить свою уверенность в техническом треке L2.