J'ai vu un ami se plaindre que @zkSync est toujours en panne. En fait, l'appeler "en panne" est une exagération. Pour être précis, cela signifie "production de blocs instables". Essentiellement, la transaction soumise par Sequencer est finalement vérifiée à un moment instable, mais cela n'est pas évident pour les utilisateurs du côté interactif car la conception Verify de zkSync présente un décalage de confirmation. L’instabilité sera également atténuée lors de la future étape de décentralisation. J'ai dessiné un organigramme technique et j'en ai discuté avec tout le monde. 🧵
La raison pour laquelle certains utilisateurs perçoivent un « temps d'arrêt » peut être due à un échec de transaction causé par la compatibilité de certains DApp et de la chaîne sous-jacente. Après tout, développer des DApp sur zkSync lui-même est très difficile. J'ai observé depuis le navigateur officiel que le changement de statut de Commit à Verified prend environ 30 minutes à 1 heure. Au début, pour la sécurité du système de la chaîne L2, il était normal qu'un tel intervalle de temps existe. Cet article se concentre sur la logique sous-jacente de la technologie zkSync.
Comme indiqué dans le workflow, zkSync s'exécute selon les étapes suivantes :
1) L'utilisateur envoie des transactions par lots au séquenceur via une transmission par relais ;
2) Sequencer est responsable du tri des transactions, de l'agrégation et du conditionnement des lots dans des arbres Merkle ;
3) zkPorter génère une preuve zk-SNARK à partir de l'arborescence Merkle ;
4) La preuve zk-SNARK est relayée vers les validateurs L2 et la chaîne principale L1 pour générer respectivement le Commit Hash ;
5) Le validateur est chargé de vérifier l'exactitude du certificat zk-SNARK, et s'il est correct, de le soumettre au contrat intelligent L1 pour générer Verify Hash ;
6) Le contrat intelligent zkSync sur L1 vérifie la correspondance de Commit Hash et Verify Hash ;
7) Une fois la correspondance réussie, la transaction vérifiée est générée et finalement téléchargée sur la chaîne ;
8) Si la correspondance échoue, le hachage de validation d'origine sera invalidé et le séquenceur soumettra à nouveau le lot et recommencera le processus. 4/n
Il convient de souligner ici que zkSync adopte une « validation en deux phases (2PC) » pour finalement déterminer le lot de transactions légales à travers deux étapes de vérification du hachage, Commit Hash et Verify Hash. D'une part, cela peut garantir la cohérence et la sécurité des données dans le processus de fonctionnement du système. Je comprends personnellement qu'il s'agit également d'une idée décentralisée qui restreint les deux composants du système, Sequencer et Validator, ce qui mérite des éloges.
Le workflow de zkSync a principalement quatre rôles principaux : relais, séquenceur, zkPorter et validateur. Il y aura de nombreux « facteurs instables » dans le travail de coordination. Cela peut être résumé par la stabilité des fonctions des nœuds, la stabilité de la collaboration des nœuds et la complexité des algorithmes et des protocoles sous-jacents. Une erreur dans n'importe quel lien peut entraîner un retard dans la production du bloc. Les pannes techniques courantes d'Arbitrum Sequencer sont typiques et zkSync ne fera que faire face à davantage de défis.
Quant à la complexité des algorithmes, c'est le destin de la chaîne zkSync et nécessite que les développeurs écologiques travaillent dur pour la surmonter. Quant à la stabilité de l'intelligence et de la collaboration des nœuds, je pense qu'elle sera efficacement améliorée lorsque l'étape de décentralisation arrivera dans le futur. La logique est également simple :
1) Plusieurs nœuds distribués peuvent éviter l'instabilité du réseau causée par une défaillance ponctuelle, qui est due à la robustesse du système ;
2) Le mécanisme d’incitation aux jetons distribués peut motiver les développeurs à maintenir la stabilité des nœuds.
En y réfléchissant sous un autre angle, le temps de vérification n'est pas un problème au début de l'écosystème. Il peut effectivement améliorer la sécurité de la chaîne et empêcher certains nœuds du système de faire du mal. En bref, si nous clarifions l'ensemble du processus de fonctionnement de zkSync et comprenons davantage la complexité technique de la couche 2 et le mécanisme « spécial » conçu pour la sécurité, nous pouvons consolider notre confiance dans la piste technologique L2. Invitez tout le monde à partager et à partager, envoyez-moi un message à tout moment, ayons des échanges approfondis et apprenons ensemble zkSync.