@zkSync が常にダウンしていると友人が愚痴をこぼしているのを見かけましたが、実はこれを「ダウンタイム」と呼ぶのは少し大げさで、正確に言うと「不安定なブロックの生成」です。基本的に、シーケンサーによって送信されたトランザクションの最終検証時刻は不安定ですが、zkSync の検証設計には確認のラグがあるため、対話型エンドではユーザーの認識は明らかではありません。将来の地方分権段階における不安定性は緩和される。あなたと話し合うためにワークフローを描きました。ユーザーが「ダウンタイム」と感じる理由は、一部の DApps によって引き起こされるトランザクションの失敗と、チェーンの根本的な互換性である可能性がありますが、結局のところ、zkSync 上で DApps を開発すること自体が非常に困難です。公式ブラウザからステータスが Commit から Verified に変化するのを確認するには 30 分から 1 時間ほどかかりますが、ユーザー側のインタラクティブ DApp はこの影響をほとんど受けません。この記事は、一般的な科学の zkSync テクノロジーの基礎となるロジックに焦点を当て、zkSync について明確に理解できるようにします。ワークフローに示されているように、zkSync は次の手順で実行されます。1. ユーザーはリレー転送を通じてバッチ トランザクションをシーケンサーに送信します。2. シーケンサーはトランザクションをソートし、バッチを集約してマークル ツリーにパッケージ化する役割を果たします。3. zkPorter はマークル ツリーから zk-SNARK 証明書を生成します。zk-SNARK 証明書はそれぞれ L2 バリデーターと L1 メイン チェーンに中継されてコミット ハッシュを生成します。バリデーターは検証を担当します。4. zk-SNARK 証明の正しさが L1 スマート コントラクトに送信され、検証ハッシュが生成されます。5. L1 の zkSync スマート コントラクトは、コミット ハッシュと検証ハッシュの一致を検証します。6. 照合が成功すると、検証済みトランザクションが生成され、トランザクションは最終的にチェーンにアップロードされます。7. マッチングが失敗した場合、元のコミット ハッシュは無効になり、シーケンサーはバッチを再送信してプロセスを再度実行します。ここで強調しておきたいのは、zkSyncは「2フェーズコミット（2PC）」を採用しており、コミットハッシュとベリファイハッシュの2段階のハッシュ検証を通じて最終的に正当なトランザクションバッチを決定するということである。これは、システム運用プロセスにおけるデータの一貫性と安全性を確保できる一方で、Sequencer と Validator という 2 つのシステムコンポーネントを抑制する分散化の考え方の現れでもあり、価値があると個人的に理解しています。賞賛の。zkSyncのワークフローには主にRelay、Sequencer、zkPorter、Validatorの4つの役割があり、その連携作業には「不安定要素」が多く存在します。それは、ノード機能の安定性、ノード連携の安定性、アルゴリズムと基盤となるプロトコルの複雑さとして要約できます。いずれかのリンクにエラーがあると、ブロック遅延が発生する可能性があります。一般的な Arbitrum Sequencer の技術的障害は典型的なものであり、zkSync はさらなる課題に直面するだけです。アルゴリズムの複雑さに関しては、これは zkSync チェーンの宿命であり、エコロジー開発者はそれを克服するために懸命に取り組む必要があります。ノードのインテリジェンスとコラボレーションの安定性については、将来的に分散化段階が到来すると、効果的に改善されると思います。ロジックも単純です。複数の分散ノードにより、単一障害点によって引き起こされるネットワークの不安定性を回避でき、システムは堅牢です。分散トークンのインセンティブ メカニズムは、開発者にノードの安定性を維持するモチベーションの源を提供できます。別の角度から考えると、エコロジーの初期段階では検証に時間がかかることは問題ではなく、効果的にチェーンのセキュリティを向上させ、システム内の一部のノードの悪行を防ぐことができます。つまり、zkSync の操作プロセス全体を明確にし、レイヤー 2 の技術的な複雑さとセキュリティのために設計された「特別な」メカニズムをさらに理解すれば、L2 技術トラックに対する自信を強化することができます。
zkSyncの動作メカニズムが整理され、頻繁に「ダウンタイム」が発生しません
@zkSync が常にダウンしていると友人が愚痴をこぼしているのを見かけましたが、実はこれを「ダウンタイム」と呼ぶのは少し大げさで、正確に言うと「不安定なブロックの生成」です。
基本的に、シーケンサーによって送信されたトランザクションの最終検証時刻は不安定ですが、zkSync の検証設計には確認のラグがあるため、対話型エンドではユーザーの認識は明らかではありません。
将来の地方分権段階における不安定性は緩和される。あなたと話し合うためにワークフローを描きました。
ユーザーが「ダウンタイム」と感じる理由は、一部の DApps によって引き起こされるトランザクションの失敗と、チェーンの根本的な互換性である可能性がありますが、結局のところ、zkSync 上で DApps を開発すること自体が非常に困難です。
公式ブラウザからステータスが Commit から Verified に変化するのを確認するには 30 分から 1 時間ほどかかりますが、ユーザー側のインタラクティブ DApp はこの影響をほとんど受けません。
この記事は、一般的な科学の zkSync テクノロジーの基礎となるロジックに焦点を当て、zkSync について明確に理解できるようにします。
ワークフローに示されているように、zkSync は次の手順で実行されます。
ユーザーはリレー転送を通じてバッチ トランザクションをシーケンサーに送信します。
シーケンサーはトランザクションをソートし、バッチを集約してマークル ツリーにパッケージ化する役割を果たします。
zkPorter はマークル ツリーから zk-SNARK 証明書を生成します。zk-SNARK 証明書はそれぞれ L2 バリデーターと L1 メイン チェーンに中継されてコミット ハッシュを生成します。バリデーターは検証を担当します。
zk-SNARK 証明の正しさが L1 スマート コントラクトに送信され、検証ハッシュが生成されます。
L1 の zkSync スマート コントラクトは、コミット ハッシュと検証ハッシュの一致を検証します。
照合が成功すると、検証済みトランザクションが生成され、トランザクションは最終的にチェーンにアップロードされます。
マッチングが失敗した場合、元のコミット ハッシュは無効になり、シーケンサーはバッチを再送信してプロセスを再度実行します。
ここで強調しておきたいのは、zkSyncは「2フェーズコミット（2PC）」を採用しており、コミットハッシュとベリファイハッシュの2段階のハッシュ検証を通じて最終的に正当なトランザクションバッチを決定するということである。
これは、システム運用プロセスにおけるデータの一貫性と安全性を確保できる一方で、Sequencer と Validator という 2 つのシステムコンポーネントを抑制する分散化の考え方の現れでもあり、価値があると個人的に理解しています。賞賛の。
zkSyncのワークフローには主にRelay、Sequencer、zkPorter、Validatorの4つの役割があり、その連携作業には「不安定要素」が多く存在します。
それは、ノード機能の安定性、ノード連携の安定性、アルゴリズムと基盤となるプロトコルの複雑さとして要約できます。いずれかのリンクにエラーがあると、ブロック遅延が発生する可能性があります。一般的な Arbitrum Sequencer の技術的障害は典型的なものであり、zkSync はさらなる課題に直面するだけです。
アルゴリズムの複雑さに関しては、これは zkSync チェーンの宿命であり、エコロジー開発者はそれを克服するために懸命に取り組む必要があります。ノードのインテリジェンスとコラボレーションの安定性については、将来的に分散化段階が到来すると、効果的に改善されると思います。ロジックも単純です。
複数の分散ノードにより、単一障害点によって引き起こされるネットワークの不安定性を回避でき、システムは堅牢です。分散トークンのインセンティブ メカニズムは、開発者にノードの安定性を維持するモチベーションの源を提供できます。
別の角度から考えると、エコロジーの初期段階では検証に時間がかかることは問題ではなく、効果的にチェーンのセキュリティを向上させ、システム内の一部のノードの悪行を防ぐことができます。
つまり、zkSync の操作プロセス全体を明確にし、レイヤー 2 の技術的な複雑さとセキュリティのために設計された「特別な」メカニズムをさらに理解すれば、L2 技術トラックに対する自信を強化することができます。