Un ami s'est plaint que zkSync est toujours en panne. En fait, l'appeler "temps d'arrêt" est un peu exagéré. Pour être précis, cela signifie "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 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 un grand défi. Il me faut environ 30 minutes à 1 heure pour observer le changement de statut de Commit à Verified depuis le navigateur officiel, et 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, pour vous apporter 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 trieur Sequencer via le transfert de relais ;
Sequencer est responsable du tri des transactions, de l'agrégation et du conditionnement des lots dans les arbres Merkle ;
zkPorter génère une preuve zk-SNARK à partir de l'arbre Merkle ;
zk-SNARK prouve que le relais génère respectivement Commit Hash vers les validateurs L2 et la chaîne principale L1
Le validateur est chargé de vérifier l'exactitude de la preuve zk-SNARK et de la soumettre au contrat intelligent L1 pour générer un hachage de vérification une fois qu'il est correct ; 6) Le contrat intelligent zkSync sur L1 vérifie la correspondance du hachage de validation et Vérifier le hachage ; 7) Génère un Vérifié après une correspondance réussie La transaction de transaction est finalement téléchargée dans la chaîne ; 8) 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 enfin le lot de transactions légales via la vérification du hachage des 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, séquenceur et 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 :
Les nœuds multidistribués peuvent éviter l'instabilité du réseau causée par un point de défaillance unique, ce qui est dû à la robustesse du système ;
Le mécanisme d'incitation des jetons distribués peut fournir aux développeurs une source de motivation pour maintenir la stabilité des nœuds.
D'un autre point de vue, la longue période de vérification n'est pas un problème au début de l'écologie, elle 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 consolider votre confiance dans la piste technique L2. Tout le monde est le bienvenu pour transmettre et partager, DM moi à tout moment, et échangeons et étudions en profondeur zkSync.
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.
Pourquoi zkSync est-il toujours "en panne" ? Un article sur le flux de travail zkSync
Un ami s'est plaint que zkSync est toujours en panne. En fait, l'appeler "temps d'arrêt" est un peu exagéré. Pour être précis, cela signifie "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 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 un grand défi. Il me faut environ 30 minutes à 1 heure pour observer le changement de statut de Commit à Verified depuis le navigateur officiel, et 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, pour vous apporter 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 trieur Sequencer via le transfert de relais ;
Sequencer est responsable du tri des transactions, de l'agrégation et du conditionnement des lots dans les arbres Merkle ;
zkPorter génère une preuve zk-SNARK à partir de l'arbre Merkle ;
zk-SNARK prouve que le relais génère respectivement Commit Hash vers les validateurs L2 et la chaîne principale L1
Le validateur est chargé de vérifier l'exactitude de la preuve zk-SNARK et de la soumettre au contrat intelligent L1 pour générer un hachage de vérification une fois qu'il est correct ; 6) Le contrat intelligent zkSync sur L1 vérifie la correspondance du hachage de validation et Vérifier le hachage ; 7) Génère un Vérifié après une correspondance réussie La transaction de transaction est finalement téléchargée dans la chaîne ; 8) 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 enfin le lot de transactions légales via la vérification du hachage des 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, séquenceur et 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 :
Les nœuds multidistribués peuvent éviter l'instabilité du réseau causée par un point de défaillance unique, ce qui est dû à la robustesse du système ;
Le mécanisme d'incitation des jetons distribués peut fournir aux développeurs une source de motivation pour maintenir la stabilité des nœuds.
D'un autre point de vue, la longue période de vérification n'est pas un problème au début de l'écologie, elle 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 consolider votre confiance dans la piste technique L2. Tout le monde est le bienvenu pour transmettre et partager, DM moi à tout moment, et échangeons et étudions en profondeur zkSync.