J'ai vu un ami se plaindre que @zkSync est toujours en panne. En fait, l'appeler "temps d'arrêt" est un peu exagéré. Pour être précis, il s'agit de "génération de blocs instables".
Essentiellement, l'heure finale de vérification de la transaction soumise par Sequencer est instable, mais la perception de l'utilisateur n'est pas évidente à la fin interactive, car la conception de vérification de zkSync a un retard de confirmation.
L'instabilité de la future phase de décentralisation sera atténuée. J'ai dessiné un workflow pour discuter avec vous.
La raison pour laquelle les utilisateurs perçoivent un "temps d'arrêt" peut être l'échec de la transaction causé par certains DApps et la compatibilité sous-jacente de la chaîne.Après tout, développer des DApps sur zkSync lui-même est très difficile.
Il me faut environ 30 minutes à 1 heure pour observer le changement de statut de Commit à Verified depuis le navigateur officiel, tandis que le DApp interactif côté utilisateur n'est guère affecté par cela.
Cet article se concentre sur la logique sous-jacente de la technologie scientifique populaire zkSync et vous apporte une compréhension claire de zkSync.
Comme indiqué dans le workflow, zkSync s'exécute selon les étapes suivantes :
L'utilisateur envoie des transactions par lots au séquenceur via le transfert de relais ;
Sequencer est responsable du tri des transactions, de l'agrégation et du conditionnement des lots dans un arbre Merkle ;
zkPorter génère des certificats zk-SNARK à partir de l'arborescence Merkle ; les certificats zk-SNARK sont respectivement relayés aux validateurs L2 et à la chaîne principale L1 pour générer Commit Hash ; les validateurs sont responsables de la vérification
L'exactitude de la preuve zk-SNARK est soumise au contrat intelligent L1 pour générer un hachage de vérification ;
Le contrat intelligent zkSync sur L1 vérifie la correspondance de Commit Hash et Verify Hash ;
Après une mise en correspondance réussie, une transaction vérifiée est générée et la transaction est finalement téléchargée sur la chaîne ;
Si la correspondance échoue, le Commit Hash d'origine sera invalidé et le séquenceur soumettra à nouveau le lot et recommencera le processus.
Il convient de souligner ici que zkSync adopte la "validation en deux phases (2PC)" et détermine finalement le lot de transactions légales via la vérification du hachage dans les deux étapes de Commit Hash et Verify Hash.
D'une part, cela peut assurer la cohérence et la sécurité des données dans le processus d'exploitation du système.Dans ma compréhension personnelle, c'est aussi une manifestation de l'idée de décentralisation qui restreint les deux composants du système, le séquenceur et le validateur, et est digne de louange.
Le flux de travail de zkSync a principalement quatre rôles : relais, séquenceur, zkPorter et validateur. Il y aura de nombreux « facteurs instables » dans le travail de coordination.
Il peut être résumé comme la stabilité des fonctions des nœuds, la stabilité de la coopération des nœuds et la complexité des algorithmes et des protocoles sous-jacents. Toute erreur dans un lien peut entraîner un retard de blocage. Les défaillances techniques courantes du séquenceur Arbitrum sont typiques, et zkSync ne fera que faire face à plus de défis.
Quant à la complexité de l'algorithme, c'est le destin de la chaîne zkSync, et les développeurs écologiques doivent travailler dur pour la surmonter. Quant à la stabilité de l'intelligence des nœuds et de la collaboration, je pense qu'après l'arrivée de l'étape de décentralisation dans le futur, elle sera effectivement améliorée. La logique est aussi simple :
Plusieurs nœuds distribués peuvent éviter l'instabilité du réseau causée par un seul point de défaillance, et le système est robuste ; le mécanisme d'incitation à jeton distribué peut fournir aux développeurs une source de motivation pour maintenir la stabilité du nœud.
Vu sous un autre angle, le long temps de Verifing n'est pas un problème au début de l'écologie, il peut effectivement améliorer la sécurité de la chaîne et empêcher certains nœuds du système de faire le mal.
En bref, si vous clarifiez l'ensemble du processus de fonctionnement de zkSync et comprenez davantage la complexité technique de la couche 2 et le mécanisme "spécial" conçu pour la sécurité, vous pouvez renforcer votre confiance dans la piste technique L2.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Le mécanisme de fonctionnement de zkSync est réglé, il n'y a pas de "temps d'arrêt" fréquent
J'ai vu un ami se plaindre que @zkSync est toujours en panne. En fait, l'appeler "temps d'arrêt" est un peu exagéré. Pour être précis, il s'agit de "génération de blocs instables".
Essentiellement, l'heure finale de vérification de la transaction soumise par Sequencer est instable, mais la perception de l'utilisateur n'est pas évidente à la fin interactive, car la conception de vérification de zkSync a un retard de confirmation.
L'instabilité de la future phase de décentralisation sera atténuée. J'ai dessiné un workflow pour discuter avec vous.
La raison pour laquelle les utilisateurs perçoivent un "temps d'arrêt" peut être l'échec de la transaction causé par certains DApps et la compatibilité sous-jacente de la chaîne.Après tout, développer des DApps sur zkSync lui-même est très difficile.
Il me faut environ 30 minutes à 1 heure pour observer le changement de statut de Commit à Verified depuis le navigateur officiel, tandis que le DApp interactif côté utilisateur n'est guère affecté par cela.
Cet article se concentre sur la logique sous-jacente de la technologie scientifique populaire zkSync et vous apporte une compréhension claire de zkSync.
Comme indiqué dans le workflow, zkSync s'exécute selon les étapes suivantes :
L'utilisateur envoie des transactions par lots au séquenceur via le transfert de relais ;
Sequencer est responsable du tri des transactions, de l'agrégation et du conditionnement des lots dans un arbre Merkle ;
zkPorter génère des certificats zk-SNARK à partir de l'arborescence Merkle ; les certificats zk-SNARK sont respectivement relayés aux validateurs L2 et à la chaîne principale L1 pour générer Commit Hash ; les validateurs sont responsables de la vérification
L'exactitude de la preuve zk-SNARK est soumise au contrat intelligent L1 pour générer un hachage de vérification ;
Le contrat intelligent zkSync sur L1 vérifie la correspondance de Commit Hash et Verify Hash ;
Après une mise en correspondance réussie, une transaction vérifiée est générée et la transaction est finalement téléchargée sur la chaîne ;
Si la correspondance échoue, le Commit Hash d'origine sera invalidé et le séquenceur soumettra à nouveau le lot et recommencera le processus.
Il convient de souligner ici que zkSync adopte la "validation en deux phases (2PC)" et détermine finalement le lot de transactions légales via la vérification du hachage dans les deux étapes de Commit Hash et Verify Hash.
D'une part, cela peut assurer la cohérence et la sécurité des données dans le processus d'exploitation du système.Dans ma compréhension personnelle, c'est aussi une manifestation de l'idée de décentralisation qui restreint les deux composants du système, le séquenceur et le validateur, et est digne de louange.
Le flux de travail de zkSync a principalement quatre rôles : relais, séquenceur, zkPorter et validateur. Il y aura de nombreux « facteurs instables » dans le travail de coordination.
Il peut être résumé comme la stabilité des fonctions des nœuds, la stabilité de la coopération des nœuds et la complexité des algorithmes et des protocoles sous-jacents. Toute erreur dans un lien peut entraîner un retard de blocage. Les défaillances techniques courantes du séquenceur Arbitrum sont typiques, et zkSync ne fera que faire face à plus de défis.
Quant à la complexité de l'algorithme, c'est le destin de la chaîne zkSync, et les développeurs écologiques doivent travailler dur pour la surmonter. Quant à la stabilité de l'intelligence des nœuds et de la collaboration, je pense qu'après l'arrivée de l'étape de décentralisation dans le futur, elle sera effectivement améliorée. La logique est aussi simple :
Plusieurs nœuds distribués peuvent éviter l'instabilité du réseau causée par un seul point de défaillance, et le système est robuste ; le mécanisme d'incitation à jeton distribué peut fournir aux développeurs une source de motivation pour maintenir la stabilité du nœud.
Vu sous un autre angle, le long temps de Verifing n'est pas un problème au début de l'écologie, il peut effectivement améliorer la sécurité de la chaîne et empêcher certains nœuds du système de faire le mal.
En bref, si vous clarifiez l'ensemble du processus de fonctionnement de zkSync et comprenez davantage la complexité technique de la couche 2 et le mécanisme "spécial" conçu pour la sécurité, vous pouvez renforcer votre confiance dans la piste technique L2.