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