Bir arkadaşımın @zkSync'in hep kapalı olduğundan şikayet ettiğini gördüm.Aslında buna "kesinti süresi" demek biraz abartı olur.Kesin olmak gerekirse "kararsız blok üretimi"dir.
Temel olarak, Sequencer tarafından gönderilen işlemin nihai Doğrulanmış zamanı kararsızdır, ancak zkSync'in Doğrulama tasarımında bir onay gecikmesi olduğundan, etkileşimli uçta kullanıcının algısı açık değildir.
Gelecekteki ademi merkeziyetçilik aşamasındaki istikrarsızlık hafifletilecektir. Sizinle tartışmak için bir iş akışı çizdim.
Kullanıcıların "kesinti süresi" algılamasının nedeni, bazı DApp'ler ile zincirin en alt katmanı arasındaki uyumdan kaynaklanan işlem hatası sorunu olabilir.Sonuçta, zkSync üzerinde DApp geliştirmek başlı başına çok zordur.
Resmi tarayıcıdan Commit'ten Verified'a durum değişikliğini gözlemlemek benim için yaklaşık 30dk-1 saat sürerken, kullanıcı tarafı etkileşimli DApp bundan neredeyse hiç etkilenmiyor.
Bu makale, popüler bilim zkSync teknolojisinin altında yatan mantığa odaklanmakta ve size zkSync hakkında net bir anlayış sunmaktadır.
İş akışında gösterildiği gibi, zkSync aşağıdaki adımlarda çalışır:
Kullanıcı toplu işlemleri sıralayıcıya aktarma iletme yoluyla gönderir;
Sıralayıcı, işlemleri sıralamaktan, partileri bir araya getirmekten ve bir Merkle ağacında paketlemekten sorumludur;
zkPorter, Merkle ağacından zk-SNARK sertifikaları üretir; zk-SNARK sertifikaları, Commit Hash oluşturmak için sırasıyla L2 Doğrulayıcılara ve L1 ana zincirine iletilir; Doğrulayıcılar, doğrulamadan sorumludur
Başarılı eşleştirmeden sonra Doğrulanmış İşlem oluşturulur ve işlem sonunda zincire yüklenir;
Eşleştirme başarısız olursa, orijinal Commit Hash geçersiz kılınacak ve sıralayıcı toplu işi yeniden gönderecek ve süreci tekrar gözden geçirecektir.
Burada, zkSync'in "iki aşamalı taahhüt (2PC)" benimsediğinin ve son olarak Karma İşleme Geçme ve Hash Doğrulamanın iki aşamasındaki Hash doğrulama yoluyla yasal işlem grubunu belirlediğinin vurgulanması gerekir.
Bu, bir yandan sistem çalışma sürecinde veri tutarlılığını ve güvenliğini sağlayabilir, kişisel anlayışıma göre, iki sistem bileşeni olan Sequencer ve Validator'ı sınırlayan ve buna layık olan ademi merkeziyetçilik fikrinin de bir tezahürüdür. övgü.
zkSync'in İş Akışı temel olarak dört role sahiptir: Relay, Sequencer, zkPorter ve Validator Koordinasyon çalışmasında birçok "kararsız faktör" olacaktır.
Düğüm fonksiyonlarının kararlılığı, düğüm işbirliğinin kararlılığı ve algoritmaların ve altta yatan protokollerin karmaşıklığı olarak özetlenebilir. Herhangi bir bağlantıdaki herhangi bir hata, blok gecikmesine neden olabilir. Yaygın Arbitrum Sequencer teknik arızaları tipiktir ve zkSync yalnızca daha fazla zorlukla karşılaşacaktır.
Algoritmanın karmaşıklığına gelince, bu, zkSync zincirinin kaderidir ve ekolojik geliştiricilerin bunun üstesinden gelmek için çok çalışmaları gerekir. Düğüm zekası ve işbirliğinin istikrarına gelince, gelecekte ademi merkeziyet aşamasına geldikten sonra etkin bir şekilde iyileştirileceğini düşünüyorum. Mantık da basit:
Birden çok dağıtılmış düğüm, tek bir hata noktasından kaynaklanan ağ kararsızlığını önleyebilir ve sistem sağlamdır; dağıtılmış belirteç teşvik mekanizması, geliştiricilere düğüm kararlılığını sürdürmek için bir motivasyon kaynağı sağlayabilir.
Başka bir açıdan bakıldığında, Doğrulamanın uzun sürmesi ekolojinin erken aşamasında bir sorun teşkil etmez, zincirin güvenliğini etkili bir şekilde artırabilir ve sistemdeki bazı düğümlerin kötülük yapmasını engelleyebilir.
Kısacası, zkSync'in tüm çalışma sürecini netleştirirseniz ve katman 2'nin teknik karmaşıklığını ve güvenlik için tasarlanmış "özel" mekanizmayı daha iyi anlarsanız, L2 teknik yoluna olan güveninizi güçlendirebilirsiniz.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
zkSync'in çalışma mekanizması düzenlenmiştir, sık sık "kesinti" olmaz
Bir arkadaşımın @zkSync'in hep kapalı olduğundan şikayet ettiğini gördüm.Aslında buna "kesinti süresi" demek biraz abartı olur.Kesin olmak gerekirse "kararsız blok üretimi"dir.
Temel olarak, Sequencer tarafından gönderilen işlemin nihai Doğrulanmış zamanı kararsızdır, ancak zkSync'in Doğrulama tasarımında bir onay gecikmesi olduğundan, etkileşimli uçta kullanıcının algısı açık değildir.
Gelecekteki ademi merkeziyetçilik aşamasındaki istikrarsızlık hafifletilecektir. Sizinle tartışmak için bir iş akışı çizdim.
Kullanıcıların "kesinti süresi" algılamasının nedeni, bazı DApp'ler ile zincirin en alt katmanı arasındaki uyumdan kaynaklanan işlem hatası sorunu olabilir.Sonuçta, zkSync üzerinde DApp geliştirmek başlı başına çok zordur.
Resmi tarayıcıdan Commit'ten Verified'a durum değişikliğini gözlemlemek benim için yaklaşık 30dk-1 saat sürerken, kullanıcı tarafı etkileşimli DApp bundan neredeyse hiç etkilenmiyor.
Bu makale, popüler bilim zkSync teknolojisinin altında yatan mantığa odaklanmakta ve size zkSync hakkında net bir anlayış sunmaktadır.
İş akışında gösterildiği gibi, zkSync aşağıdaki adımlarda çalışır:
Kullanıcı toplu işlemleri sıralayıcıya aktarma iletme yoluyla gönderir;
Sıralayıcı, işlemleri sıralamaktan, partileri bir araya getirmekten ve bir Merkle ağacında paketlemekten sorumludur;
zkPorter, Merkle ağacından zk-SNARK sertifikaları üretir; zk-SNARK sertifikaları, Commit Hash oluşturmak için sırasıyla L2 Doğrulayıcılara ve L1 ana zincirine iletilir; Doğrulayıcılar, doğrulamadan sorumludur
zk-SNARK kanıtının doğruluğu, Verify Hash oluşturmak için L1 akıllı sözleşmesine gönderilir;
L1'deki zkSync akıllı sözleşmesi, Commit Hash ve Verify Hash'in eşleşmesini doğrular;
Başarılı eşleştirmeden sonra Doğrulanmış İşlem oluşturulur ve işlem sonunda zincire yüklenir;
Eşleştirme başarısız olursa, orijinal Commit Hash geçersiz kılınacak ve sıralayıcı toplu işi yeniden gönderecek ve süreci tekrar gözden geçirecektir.
Burada, zkSync'in "iki aşamalı taahhüt (2PC)" benimsediğinin ve son olarak Karma İşleme Geçme ve Hash Doğrulamanın iki aşamasındaki Hash doğrulama yoluyla yasal işlem grubunu belirlediğinin vurgulanması gerekir.
Bu, bir yandan sistem çalışma sürecinde veri tutarlılığını ve güvenliğini sağlayabilir, kişisel anlayışıma göre, iki sistem bileşeni olan Sequencer ve Validator'ı sınırlayan ve buna layık olan ademi merkeziyetçilik fikrinin de bir tezahürüdür. övgü.
zkSync'in İş Akışı temel olarak dört role sahiptir: Relay, Sequencer, zkPorter ve Validator Koordinasyon çalışmasında birçok "kararsız faktör" olacaktır.
Düğüm fonksiyonlarının kararlılığı, düğüm işbirliğinin kararlılığı ve algoritmaların ve altta yatan protokollerin karmaşıklığı olarak özetlenebilir. Herhangi bir bağlantıdaki herhangi bir hata, blok gecikmesine neden olabilir. Yaygın Arbitrum Sequencer teknik arızaları tipiktir ve zkSync yalnızca daha fazla zorlukla karşılaşacaktır.
Algoritmanın karmaşıklığına gelince, bu, zkSync zincirinin kaderidir ve ekolojik geliştiricilerin bunun üstesinden gelmek için çok çalışmaları gerekir. Düğüm zekası ve işbirliğinin istikrarına gelince, gelecekte ademi merkeziyet aşamasına geldikten sonra etkin bir şekilde iyileştirileceğini düşünüyorum. Mantık da basit:
Birden çok dağıtılmış düğüm, tek bir hata noktasından kaynaklanan ağ kararsızlığını önleyebilir ve sistem sağlamdır; dağıtılmış belirteç teşvik mekanizması, geliştiricilere düğüm kararlılığını sürdürmek için bir motivasyon kaynağı sağlayabilir.
Başka bir açıdan bakıldığında, Doğrulamanın uzun sürmesi ekolojinin erken aşamasında bir sorun teşkil etmez, zincirin güvenliğini etkili bir şekilde artırabilir ve sistemdeki bazı düğümlerin kötülük yapmasını engelleyebilir.
Kısacası, zkSync'in tüm çalışma sürecini netleştirirseniz ve katman 2'nin teknik karmaşıklığını ve güvenlik için tasarlanmış "özel" mekanizmayı daha iyi anlarsanız, L2 teknik yoluna olan güveninizi güçlendirebilirsiniz.