本文では、StarkNet の重要なコンポーネントについて簡単に説明し、技術的な詳細やコードの部分にはあまり触れませんが、読者が ZK-Rollup（Validity-Rollup）に基本的な理解を持てることを望んでいます。
また、StarkNet のシステムデザインは、ゼロ知識証明や Merkle ツリーに関連するデータ構造が多く関わっているため、読者はゼロ知識証明や関連する Merkle ツリーについても大まかに理解する必要があります。これにより、読解のプロセスがスムーズになります！将来的には各システムコンポーネントについてさらに詳しく議論する可能性もあります。
概要
StarkNet OS（オペレーティングシステム）は、Cairo という StarkNet のネイティブ言語で主に記述されています。Cairo は、StarkNet 上の Solidity のようなものであり、（Cairo ベースの）スマートコントラクトの記述に使用できますが、同時にゼロ知識証明言語でもあり、StarkNet のコアオペレーティングシステムやさまざまな機能の構築に使用できます。
StarkNet 上のすべてのロジックは、StarkNet OS に含まれます。アカウントの状態の定義方法、トランザクションの原則、コントラクトの実行方法、ビット演算、ハッシュ演算、ネイティブの署名アルゴリズムなど、すべてここで定義されます。
要するに、オペレーティングシステムは、トランザクションとコントラクトの入力を受け取った後、出力を生成し、この出力を StarkNet の L2 ステータス（State）に更新する必要があります。
では、なぜ StarkNet OS を記述するためにゼロ知識証明言語を使用するのでしょうか？他の一般的な言語ではなく。
多くの人がスケーリングの方向性の 1 つは「煩雑な計算を Off-Chain に投げて、On-Chain での検証だけで済むようにする」ということを知っていると思います。ZK-Rollups の一員である StarkNet は、Cairo で記述された ZK-STARK プログラムの実行結果を STARK-proof システムで証明し（prove）、Ethereum 上で検証（verify）します。
ここまで理解が進んでいなくても問題ありません。次のいくつかのセクションでは、これらの用語の説明と使用シナリオを順番に補完していきます！
StarkNet システムの概要
StarkNet Sequencer
StarkNet は、私たちが以前知っていたマイナーのような役割は持っていませんが、「トランザクションの検証」、「トランザクションの順序決定」、「ブロックの構築」を行う役割が必要です。これらの作業を担当するのが Sequencer です。
Sequencer は、オフチェーンのサーバーであり、ワークフローの最初のステップは、ユーザーからのトランザクション（異なるユーザーからの複数の異なるトランザクション）を受け取り、その後、Sequencer がトランザクションの順序を決定し、L2 のブロックを構築します。
Sequencer は、トランザクションがアカウントの所有者によって承認されたことを確認する必要があります（StarkNet はネイティブの AA アカウントシステムを使用しているため、単純な署名の正当性を確認するだけでなく、マルチサインやその他の検証ロジックかもしれません）。その後、StarkNet OS を使用してトランザクションを 1 回実行し、EVM に似た概念で、入力を受け取り、コントラクトロジックを実行し、出力を生成します。
Sequencer がトランザクションを実行すると、トレースが生成されます（このトレースは関数の戻り値ではなく、実行プロセスの証明です）。そして、これらの実行内容の「プロセスの証明」を Prover に送信し、「私はこのコードを実行しました」と伝えます。
次に説明する Prover と Verifier が検証に成功した後、Sequencer は L1 の StarkNet コアコントラクトの状態を更新します。
StarkNet Prover＆Verifier
Prover もまたオフチェーンのサーバーであり、主な役割は Sequencer が生成したコードのトレースを受け取り、対応する STARK 証明を生成し、L1 上で実行される Verifier コントラクトによって検証された後、将来の L1 StarkNet コアコントラクトのクエリに使用するためにファクトを登録することです。
Verifier コントラクトは、すべてが合法であるかどうかを L1 で検証する役割を果たします。入力と STARK 証明を受け取り、決定します。
補足説明：現在、StarkNet には 1 つの Prover しかありません。これは StarkNet の証明を生成するだけでなく、StarkWare 自身の StarkEx ロールアップ上で実行される他のすべてのアプリケーション（例：Immutable X、dYdX、Sorare など）のために証明を生成します。これがこのサービスが Shared Prover または SHARP と呼ばれる理由です。
StarkNet L1 コアコントラクト
StarkNet L1 コアコントラクトは、L2 上の状態の証明を保持しています。Rollups のセキュリティは、Ethereum の L1 が保証しているとよく言われています。私たちのトレースが Prover によって証明され、L1 Verifier コントラクトで検証された後、L1 コアコントラクトに「状態の更新」が正しいことを伝えます。
「状態の更新」とは、StarkNet がトランザクションを実行した後に状態が変化することを意味します。L2 上の状態が S から S' に変わったことを L1 コアコントラクトに正しく伝える必要があります。
L1 コアコントラクトは、Verifier がこの更新が合法であることを知った後、State Root を更新します。
つまり、「この状態の更新が合法である」ということは、オフチェーンの計算が正しく実行されたことを ZKP で証明し、ランダムなトランザクション結果を作り出すだけで L1 コアコントラクトを更新するのではなく、真の計算が行われたことを証明したという意味です。
また、StarkNet が L1 で定義するいくつかの操作がある場合、これらも StarkNet L1 コアコントラクトで定義されます。例えば：
公式に認められた Verifier コントラクト（アドレスリスト）
L1 ↔ L2 のインタラクションロジック（メッセージパッシングの方法）
議論
分散化とオープンソース
StarkNet の Sequencer や Prover のような役割が公式に制御されていると、コミュニティから疑問が投げかけられる可能性があるため、オープンソース化は長期的な発展にとって非常に重要です。コードをより多くの目で見ることができるだけでなく、コミュニティの協力と貢献によってシステムをより安全かつ効率的にすることができます。さらに、コミュニティはネットワーク全体を独自に開発およびメンテナンスすることもできます。
StarkNet コミュニティでは、分散化について 2 つの主要な議論があります：
許可なしで動作する Sequencers や Provers は、このネットワークが検閲に対して耐性を持つことを保証します。
STARK-proofs を使用しているため、誰でも低コストでチェーン全体の正当性を検証することができます。また、第三者に依存する必要もありません。
現在、StarkNet は最新の Sequencer をオープンソース化しており、Prover も近日中にオープンソース化される予定です。興味のある方は、以下のリソースを参照してください：
StarkNet Decentralized Protocol III - Consensus
オープンソース：StarkNet の新しい Sequencer
オープンソースの StarkNet Prover
パフォーマンスとボトルネック
StarkNet のパフォーマンスとガス料金は、これらの数ヶ月間の私の使用経験ではあまり良くありませんでした（時には悪くなったり、完全に使用できなくなったりしました）。しかし、StarkNet 公式は過去には主に機能性に重点を置いていたと述べており、現在（Cairo 1.0 のリリースが近づいた後）基盤の構築が完了し、開発の重点をパフォーマンスに移す予定です。
StarkNet は、同じブロック生成時間の下で処理できるトランザクション量を増やすことで、TPS を向上させることが最善の方法だと考えています。つまり、ブロック制限を増やす必要があります。したがって、ブロック生成に関連するすべてのコンポーネントは効率を向上させる必要があります。たとえば、Sequencer は最大のボトルネックですので、異なるアルゴリズム（先着順から並行処理への変更）、異なるデータ構造（元は Patricia-Trie でした）、および Python から Rust への新しい Sequencer である Blockifier に変更する計画があります。
新しい並行 Sequencer の詳細については、以下のリソースを参照してください：
https://twitter.com/starkience/status/1615502502773903361?s=20
https://twitter.com/Starknet/status/1595341405655683072
https://www.youtube.com/watch?v=9IszIArEt1M
この問題に関して、StarkNet は、なぜブロック制限を増やすことが L2 にとって有益であり、L1 にとっては有益ではないのかという説明を提供しています。理由は、ブロックサイズが大きすぎると、フルノードへの要件が高くなるためです（これにより、彼らはチェーンの成長に遅れずに追いつき、検証を行うことができます）。この要件がほとんどのユーザーにとって負担が大きく、自己検証ができない場合、ほとんどの人がネットワークに参加するために信頼できない方法を取らざるを得なくなります。
結論
StarkNet の紹介文を書くにあたり、多くの参考文献を参照する必要がありました。参照したコンテンツはできる限りすべて（本文または文末）に記載しました。深く理解しようとする人々に助けを提供できることを願っています。また、StarkNet の研究成果を共有してくれた多くの方々にも感謝しています！