StarknetスマートコントラクトモデルとネイティブAA：マーベリックテクニカルマスター

著者：shew＆amp;

まとめ

• ZKプルーフを助長するカイロ語を含む、スタークネットの最も重要な技術的特性、ネイティブレベルAA、ビジネスロジックとステータスストレージのスマートコントラクトモデル。

• Cairoは、StarkNetでスマートコントラクトを実装できる一般的なZK言語であるか、従来のアプリケーションの開発に使用できます。編集プロセスで中間言語としてシエラを導入すると、カイロは頻繁に反復することができますが、バイトコードの最下層を変更する必要はありません。カイロの標準図書館では、アカウントの抽象化に必要な多くの基本的なデータ構造エッセンス

• StarkNetスマートコントラクトは、EVMチェーンとは異なり、カイロ契約の展開が含まれています「編集、宣言、展開」第3段階では、ビジネスロジックは契約クラスで宣言されています。

• Starknetの上記のインテリジェント契約モデルは、コードの再利用、契約ステータスの再利用、ストレージ層、およびゴミ契約の検出に役立ちます。また、ストレージリースシステムの実現とトランザクションの並列化を助長します。後者の2つはまだ上陸していませんが、カイロスマートコントラクトのアーキテクチャは「必要な条件」を作成しました。

• StarkNetチェーンにはスマートコントラクトアカウントのみがあり、EOAアカウントはありません。最初から、ネイティブAAアカウントの抽象化をサポートします。そのAAソリューションは、ERC-4337のアイデアをある程度吸収し、ユーザーが高度にカスタマイズされたトランザクション処理スキームを選択できるようにします。潜在的な攻撃シーンを防ぐために、StarkNetは多くの対策を行い、AAエコシステムの重要な調査を行いました。

Starknetの発行トークンに続いて、STRKは徐々にイーサリアムオブザーバーの目に不可欠な要素の1つになりました。「ユニークさ」と「ユーザーエクスペリエンスに注意を払わない」で知られるEthereum Layer2スターは、世界の隠者のようです

ユーザーにはあまりにも無視され、「電子be食」チャンネルを不和で公開したため、スタークネットはかつて「人間ではない」と噴霧されていました。 「UXと富を築く効果だけがすべてであるようです。「ゴールデンパビリオン寺院」の「私の唯一のプライドとして理解されていない」というフレーズは、単にスタークネットの自己Portaitです。

しかし、これらの些細な問題は別として、コードオタクの「技術的な味」から始まりますすべての鎖のゲーム開発者であるStarknetとCairoの心は、Web3のすべてであり、堅実さも動きも同等ではありません。今日、「技術的なオタク」と「ユーザー」の間の最大の世代のギャップは、実際には人々のスタークネットの認知の欠如のためです。

ブロックチェーンテクノロジーの関心と探求、およびスタークネットの価値の価値により、著者は、StarknetのスマートコントラクトモデルとネイティブAAから始まり、すべての人のための技術的なソリューションとメカニズムの設計を整理します。より多くの人々にスタークネットの技術的特性を示しながら、私は人々にこの「理解できない孤独な男」を理解させることを望んでいます。

カイロ言語ミニマリスト科学

以下では、Starknetのスマートコントラクトモデルとネイティブアカウントの抽象化について議論し、StarkNetがネイティブAAをどのように達成するかを説明することに焦点を当てます。この記事を読んだ後、StarkNetのさまざまな財布の助けが混合できない理由も誰もが理解できます。

しかし、ネイティブアカウントの抽象化を導入する前に、まず、スタークネットの元のカイロ語を理解しましょう。カイロの開発中、Cairo0という名前の初期バージョンが登場し、その後の現代バージョンが登場しました。カイロの現代版の全体的な文法は、実際には一般的なZK言語であるRustに似ています。StarkNetでスマートコントラクトを作成することに加えて、一般的なアプリケーションの開発にも使用できます。

たとえば、Cairo LanguageでZK ID検証システムを開発できます。検証する必要があるプログラムは、カイロ語で実装できると言えます。そしてカイロは、おそらくZKの生成に最も役立つプログラミング言語です。

編集プロセスから判断すると、カイロは、下の図に示すように、中間言語に基づいて編集方法を使用します。図のシエラは、カイロ言語編集プロセスの中間形式（IR）であり、Sierraは、StarkNetノード機器で直接操作されるCASMという名前のより基礎となるバイナリコード形式にまとめられます。

Sierraを中間形式として紹介します。これは、Cairo Languageが新しい機能を増やすのに便利です。これにより多くのトラブルが節約され、StarkNetのノードクライアントを頻繁に更新する必要はありません。このようにして、スタークネットの根底にあるロジックを変更することなく、カイロ語の頻繁な反復を実現できます。そしてカイロ標準ライブラリでは、アカウントの抽象化に必要な多くの基本的なデータ構造が必要です。

カイロネイティブと呼ばれる理論的なソリューションを含む他のカイロは、さまざまなハードウェアデバイスに適応する必要がありますコードの実行速度を大幅に改善します[まだ理論的段階にあり、着陸していません）。

starknetスマートコントラクトモデル：コードロジックと状態ストレージストリッピング

EVMや有能なチェーンとは異なり、StarkNetは、スマートコントラクトシステムの設計において画期的なイノベーションを持っています。ここでは、イーサリアムなどの伝統的な公共チェーンでは、スマートコントラクトの展開は、多くの場合、「コンパイル後の展開」メソッドに従い、たとえばETHスマートコントラクトを使用します。

1。開発者がスマートコントラクトをローカルに書いた後、開発者はEVMを直接理解して処理できるように、編集者を介してSolidityプログラムをEVMのバイトコードにまとめます。

2。開発者は、スマートコントラクトを展開するためのトランザクションリクエストを開始して、EthereumチェーンにコンパイルされたEVMバイトコードを展開します。

（写真出典：not-satoshi.com）

StarkNetのスマートコントラクトは、「コンパイルと展開」のアイデアにも従っていますが、インテリジェントな契約は、CairovmがサポートするCASMバイトコードの形でチェーンに展開されます。ただし、スマートコントラクトの呼び出しとステータスストレージモードの点では、StarkNetとEVM互換チェーンは巨大です。

正確には、Ethereumスマートコントラクト=ビジネスロジック+ステータス情報、たとえば、USDT契約は、転送、承認などの一般的な機能を実装するだけでなく、すべてのUSDT保有者の資産ステータスを保存します。コードとステータスは、まず多くのトラブルをもたらします重荷。

この点で、StarkNetは状態の保管方法を改善しました。Smart Contractの実装計画では、DAPPのビジネスロジックと資産ステータスは完全に分離されており、さまざまな場所に保存されています。そうすることの利点は、まず第一に、複製または追加のコード展開を備えたシステムによってより際立っている可能性があります。ここでの原則は次のとおりです。

Ethereumのスマートコントラクト=ビジネスロジック+ステータスデータ、いくつかの契約のビジネスロジックが完全に一貫しているが、ステータスデータが異なる場合、これらの契約のハッシュもこの時点で、これらの契約が冗長であるかどうかを区別することは困難です。契約」。

そしてStarknetのスキームでは、コード部分とステータスデータは直接分離されています。彼らのハッシュは同じだからです。これは、重複したコードの展開を停止し、スタークネットノードのストレージスペースを保存するのに便利です。

StarkNetのスマートコントラクトシステムでは、契約の展開と使用が分割されます「編集、宣言、展開」3つのステージ。資産発行者がカイロ契約を展開したい場合、最初のステップは、書かれたカイロコードをシエラと基礎となるバイトコードCASMフォームにコンパイルすることです。

次に、契約展開者は「宣言」トランザクションの声明を発行し、契約のCASMバイトコードとSierra中級コードをチェーンに展開します。契約クラスエッセンス

（写真出典：StarkNetの公式ウェブサイト）

その後、アセット契約で定義された関数関数を使用する場合は、DAPPのフロントエンドを介して「展開」トランザクションを開始して展開できます。契約インスタンスこのインスタンスは、アセットステータスを保存します。その後、ユーザーは契約クラスの関数関数を呼び出して、契約インスタンスの状態を変更できます。

実際、オブジェクト指向のプログラミングを理解している人なら誰でも、StarkNetのクラスとインスタンスが何を表すかを簡単に理解する必要があります。開発者が宣言した契約クラスには、スマート契約のビジネスロジックが含まれていますが、実際の資産状態はありません

すべきユーザーが特定の契約インスタンスを展開した後、アセットは「物理化」を完了します。トークンを他の人に転送するなど、資産「エンティティ」のステータスを変更する場合は、契約クラスで記述された関数関数を直接呼び出すことができます。上記のプロセスは、従来のプログラミング言語でやや似ています（ただし、完全に一貫していません）。

インテリジェントな契約がクラスおよびインスタンスとして分離された後、ビジネスロジックとステータスデータの分離は次の機能をもたらします。

1。レイヤーの保存の失敗と「ストレージリースシステム」の実現

SO -Caled Storageの層別化は、開発者がStarkNetチェーンの下など、自分のニーズに応じてカスタマイズされた位置にデータを配置できることを意味します。StarkNetはCelestiaなどのDA層と互換性があり、DAPP開発者はこれらの第3パーティDAレイヤーにデータを保存できます。たとえば、ゲームはStarkNetのメインネットワークに最も重要な資産データを保存し、Celestiaのリンクの下に他のデータをDA層に保存できます。セキュリティニーズのカスタマイズに従ってDAレイヤーに対するこのソリューションは、StarkNetによって「Volition」と呼ばれます。

SO -CALLED STORAGE LEASEシステムは、誰もが占有するストレージスペースの支払いを継続する必要があることを意味します。理論的には、賃貸料を支払う必要があります。

Ethereum Smart Contractモデルでは、契約の所有権は明確ではなく、ERC-20契約を区別することは困難です。ストレージリース機能を起動しておらず、契約展開中にデプロイ担当者に料金のみを請求します。

StarkNetとSUIとCKBとSolanaのスマートコントラクトモデルでは、スマートコントラクトの所有権はより明確であり、ストレージファンドの収集に便利です[Starknetは現在、オンラインストレージリースシステムではありませんが、で実現されます。未来]

2.実際のコードの再利用を実現し、ごみ契約の展開を減らす

普遍的なトークン契約をチェーンに保存しているクラスとして宣言することができ、このクラスの関数を呼び出して独自のトークンインスタンスを展開できます。また、契約はクラス内のコードを直接呼び出すこともできます。これにより、ライブラリ関数ライブラリと同様のライブラリ機能ライブラリの効果が実現します。

同時に、このスマートコントラクトモデルのスタークネット、「ガベージ契約」を区別するのに役立ちます。以前にこれを説明しました。コードの再利用とゴミ契約検出をサポートした後、StarkNetはチェーン上のデータの量を大幅に削減し、ノードのストレージ圧力を可能な限り最小限に抑えることができます。

3。実際の契約の実際の「ステータス」

ブロックチェーンの契約のアップグレードには、主にStarkNetのシナリオの変更が含まれます。ビジネスロジックアップグレードこの契約のアップグレードは、資産のステータスを新しい場所に移行する必要はありません。

Ethereum契約のビジネスロジックを変更するには、依存機関契約を変更することにより、ビジネスロジックを「アウトソーシング」する必要があります

（写真出典：WTFアカデミー）

いくつかのシナリオでは、古いイーサリアム契約が放棄されている場合、内部の資産ステータスは新しい場所に直接移行することはできません。これは非常に面倒ではありません。 「古い。州。

4。トランザクションの並列化の失敗

可能な限り異なるトランザクションの指示の並列程度を増やすために、ビットコイン、CKB、SUIで見ることができる異なる人々の資産ステータスを解散して保存する必要があります。上記の目標の前提条件は、スマート契約のビジネスロジックと資産ステータスデータを剥がすことです。StarkNetは、並列トランザクションの詳細な技術実装でまだ実行されていませんが、将来の重要な目標として並列トランザクションが必要になります。

StarknetのネイティブAAおよびアカウント契約展開

実際、So -Caled Accountの抽象化とAAは、Ethereum Communityによって発明されたユニークな概念です最初から回避しました。たとえば、ETEREAMの設定では、EOAアカウントコントローラーは、トランザクションを開始するためにチェーンにETHを使用する必要があります。一部の人々は、イーサリアムでのこのアカウントの設計は単に反人間であるとさえ考えています。

StarkNetまたはZksynceraなどを観察する場合。「ネイティブAA」チェーンは明らかな違いを観察できます：最初に、StarknetとZksynceraは、最初からスマート契約アカウントのみがあります。（ZKSYNC時代は、ユーザーの新しく作成されたアカウントにデフォルトで一連の契約コードを展開して、メタマスクとの互換性に便利なEthereum EOAアカウントの特性をシミュレートします）。

StarkNetは、メタマスクやイーサリアム周辺の他の施設と直接互換性があるとは考えていません。ユーザーが初めてStarkNetウォレットを使用する場合、専用の契約アカウントを自動的に展開します。この契約インスタンスは、事前にウォレットプロジェクトパーティーによって展開された契約クラスに関連付けられ、クラスで記述されたいくつかの機能を直接呼び出すことができます。

以下に興味深いトピックについて説明します。Strk Airdropを受け取ると、多くの人がArgentとBraavosウォレットが互いに互換性がないことを発見しました。ArgentのメモをBraavosにインポートした後、対応するアカウントをエクスポートすることはできません。これは、実際には、ArgentとBravosが異なるアカウント生成計算方法を使用しているためです。同じエイズによって生成されたアカウントアドレスは異なります。

具体的には、StarkNetでは、新しく展開された契約アドレスを確実性アルゴリズムを使用して取得できます。

Pedersen（）上記の式は、実際にZKシステムで使用できるプロセスであり、Pedersen関数にいくつかの特別なパラメーターを入力して、このハッシュを生成します。アカウントアドレスエッセンス

上記の画像は、「契約者」のアドレスを表す「新しい契約アドレス」を生成するときに使用されるいくつかのパラメーターを示しています。

塩は契約アドレスの塩値です。この変数は、実際には契約アドレスを繰り返し導入しないようにします。class_hashは以前に導入され、契約インスタンスに対応するクラスのハッシュ値が導入されています。constructor_calldata_hashは、契約の初期化のためにハッシュを表します。

上記の式に基づいて、ユーザーは、契約展開がチェーンに展開される前に、事前に生成された契約アドレスを事前に計算できます。StarkNetを使用すると、ユーザーはStarkNetアカウントなしで契約を事前に展開できます。プロセスは次のとおりです。

1.ユーザーは、最初に展開したい契約インスタンスを決定します。契約クラスを関連付け、クラスハッシュを初期化パラメーターの1つとして使用し、塩を計算して契約の契約アドレスについて学習します。

2。ユーザーが契約を展開する場所を知っている後、最初に契約展開料として住所に一定量のETHに転送します。一般的に言えば、L1からStarkNetネットワークまでのチェーンブリッジを横切るETHのこの部分。

3.ユーザーは、契約展開のトランザクション要求を開始します。

実は、すべてのstarknetアカウントは上記のプロセスを通じて展開されますが、ほとんどのウォレットは内部のプロセスを知覚できません。契約アカウントがETHに転送した後に展開されているかのようです。

上記のソリューションは、異なるウォレットがアカウントアドレスを生成すると、結果の結果が一貫していないため、いくつかの互換性の問題をもたらします。次の条件を満たす財布のみを混ぜることができます：

1. ウォレットが使用する秘密鍵由来の公開キーは、署名アルゴリズムと同じです。

2. ウォレットの塩計算プロセスは同じです。

3. ウォレットのスマートコントラクトクラスは、実装の詳細に基本的に違いはありません。

以前のケースでは、ArgentとBraavosは両方ともECDSA署名アルゴリズムを使用していますが、両側の塩計算方法は、2つの財布で生成されたアカウントアドレスと矛盾しています。

アカウントの抽象化のトピックに戻ります。StarknetとZksync時代、認証（検証デジタル署名）、ガス料金の支払いなど、トランザクション処理プロセスに関与する一連のプロセスを作成します。これらはすべて「チェーンの底」の外側に移動します。ユーザーは、アカウントの上記のロジックの詳細をカスタマイズできます。

たとえば、StarkNetスマートコントラクトアカウントに専用のデジタル署名検証機能を展開できます。StarkNetノードが開始したトランザクションを受信すると、チェーンのアカウントでカスタマイズした一連のトランザクション処理ロジックを呼び出します。これは明らかに柔軟性があります。

Ethereumの設計では、認証（デジタル署名）などのロジックはノードクライアントコードに記述されており、アカウント関数のカスタマイズをネイティブにサポートすることはできません。



（StarkNet Architectが述べた元のAA概略図、トランザクション検証と機能検証が契約に転送され、チェーンの基礎となる仮想マシンはユーザーのカスタムまたは指定された関数を呼び出すことができます）

ZksynceraとStarknetの公式人員によると、このアカウント機能のセットはモジュール化されており、EIP-4337は学習されています。しかし、違いは、ZksyncとStarknetが最初からアカウントタイプを統合し、取引タイプを統合し、統一された入り口ですべてのトランザクションを受け取ったことです。イーサリアムには歴史的な負担があり、財団はハードフォークなどの大まかな反復スキームを可能な限り回避したいと考えているため、「国を救うための曲線」スキームEIP-4337をサポートしています。しかし、この効果は、EOAアカウントと4337ソリューションがそれぞれ、ネイティブAAスピリットとは異なり、厄介で肥大化しているように見える独立したトランザクション処理プロセスを採用していることです。



（画像ソース：argentwallet）

しかし、StarkNetのネイティブアカウントの抽象化は、まだ完全な成熟度に達していません。実用的な進捗状況の観点から、StarknetのAAアカウントは署名検証アルゴリズムのカスタマイズを実現しましたが、実際にStarkNetはETHおよびSTRKの支払いガス料金のみをサポートしており、第3パーティの支払いガスをサポートしていませんしたがって、ネイティブAAのスタークネットの進捗は「理論的解決策は基本的に成熟しており、実用的な解決策はまだ進んでいます。」

StarkNetにはスマートコントラクトアカウントのみがあるため、トランザクションのプロセス全体がアカウントスマートコントラクトの影響を考慮します。まず第一に、トランザクションはスタークネットノード（Mempool）のメモリプールによって受け入れられ、検証手順には以下が含まれます。

1. トランザクションのデジタル署名が正しいかどうか。

2. トランザクションイニシエーターの残高を支払うことはできますか？

ここでは、アカウントのインテリジェント契約でカスタマイズされた署名検証関数を使用することは、攻撃シナリオがあることを意味することに注意する必要があります。メモリプールは、新しいトランザクションの確認に署名するときにガス料金を請求しないため（ガス料金を直接請求すると、より深刻な攻撃シナリオがもたらされます）。悪意のあるユーザーは、アカウント契約でSuper -Compliced Signing機能をカスタマイズし、多数のトランザクションを開始するため、これらのトランザクションが検証された場合、Comples Complex Computingリソースを呼び出します。

この状況を回避するために、StarkNetにはトランザクションに次の限界があります。

1. 単位時間中、単位時間に開始できるトランザクションペンの数は限られています。

2. StarkNetアカウント契約のカスタマイズされた署名検証関数には、複雑さが制限されており、過剰に複製された署名関数は実行されません。Starknetは、署名機能の消費量が高すぎる場合、署名機能のガス消費量の上限を制限します。同時に、アカウント契約の他の契約は、アカウント契約の他の契約を呼び出すことは許可されていません。

StarkNetトランザクションのフローチャートは次のとおりです。



注目に値します、トランザクション検証プロセスをさらに加速するために、StarkNetノードクライアントは、BravosおよびArgent Walletsの署名検証アルゴリズムを直接実装します。ノードは、トランザクションが2つの主流のスタークネットウォレットを生成することを発見すると、クライアントに付属するBravos/Argent Signatureアルゴリズムを呼び出します。

トランザクションデータがソーターによって検証された後（ソーターの検証手順はメモリプールの検証よりもはるかに深くなります）、ソーターはメモリプールからトランザクションを梱包し、ZKに送信して発電機を証明します。このリンクに入るトランザクションは、障害がある場合でもガスが充電されます。

しかし、読者がstarknetの歴史を理解している場合、初期のスタークネットは、実行に失敗したトランザクションのハンドリング料金を請求しないことがわかります。最も一般的なトランザクションの障害は、ユーザーが1つのETH資金しか持っていないことですが、10 ETHが外部から転送されます。

しかし、Starknetは、過去にそのような失敗取引に対して料金を請求しません。このコストレストレーディングは、StarkNetノードのコンピューティングリソースを無駄にし、DDOS攻撃シーンを導き出します。表面的には、間違った取引の取り扱い手数料は非常に簡単に達成できるようですが、実際には非常に複雑です。Starknetは、Cairo1言語の新しいバージョンを起動しました。これは、主に故障トランザクションのガスを収集する問題を解決するためのものです。

私たちは皆、ZK証明が効果的な証明であることを知っており、実行に失敗した結果は無効であり、チェーンに出力の結果を残すことができません。特定の命令の実行が無効であることを証明するために、それを有効性で証明してみてください。したがって、過去に、スタークネットが生成されたとき、出力結果を生成できなかった故障トランザクションが直接計画されていました。

StarkNetチームは後によりスマートなソリューションを採用しました、「すべてのトランザクション指示が出力結果とオンチェーンを生成できる」新しい契約言語Cairo1が構築されます。一見すると、すべてのトランザクションが出力を生成する可能性があります。つまり、論理的なエラーがなく、ほとんどの場合、いくつかのバグに遭遇するためにトランザクションが失敗し、命令実行が中断されます。

トランザクションの途切れや成功した出力を達成することは困難ですが、実際には、トランザクションが論理エラーに遭遇すると、出力結果を生成することもできます。リターンは、このトランザクションの実行がスムーズではないことを誰もが認識します。

しかし、注意を払って、虚偽の値を返し、出力の結果を返します。つまり、Cairo1では、命令が論理エラーに遭遇したかどうかに関係なく、一時的な割り込みがあるかどうかに関係なく、出力結果を作成してオンチェーンできます。この出力結果は、正しいエラー情報または誤ったエラー情報になる場合があります。

Exmpleの場合、次のコードセグメントがある場合：



_バランス::（from）-amountは、この時点でエラーを報告する場合があります次のフォームに対してそれを書き直します。トランザクションが失敗し、チェーンを離れるときに出力結果がまだ返されます。認識の観点から見ると、これはすべてのトランザクションがチェーン上に取引出力をスムーズに残すことができるかのようであり、取り扱い料金を徴収することは合理的であるようです。



Starknetaa契約の概要

一部の読者がこの記事でプログラミングの背景を持っている可能性があることを考えると、starknetにアカウント抽象化契約のインターフェイスの簡単な表示があります。



上記のインターフェイスの__Validate_declare__は、ユーザーが開始した宣言トランザクションを検証するために使用されますが、__validate__は一般的なトランザクションの検証に使用され、__execute__はトランザクションの実行に使用されます。StarkNet契約アカウントがデフォルトでMulticalをサポートしていることがわかります。これは複数の呼び出しです。マルチコールは、いくつかのdefiインタラクションを実行するときに次の3つのトランザクションを梱包するなど、非常に興味深い機能をいくつか実現できます。

1. 最初のトランザクションは、defi契約へのトークンを承認します

2. 2番目のトランザクションは、Defi契約ロジックをトリガーします

3. 3番目のトランザクションは、defi契約の承認を許可されています

もちろん、複数の呼び出しはアトミックであるため、特定のアービトラージトランザクションの実行など、より複雑な使用法がいくつかあります。

要約します

• ZKを助長するカイロ言語、AA、およびビジネスロジックおよび州ストレージに独立したスマートコントラクトモデルを含む、StarkNetの最も重要な技術的特性。

• カイロは、スタークネットにスマートコントラクトを実装することができる一般的なZK言語であり、編集プロセスで中間言語としてシエラを導入するだけでなく、底を繰り返すことができますが、底部を変更する必要はありません。レイヤーbytecodeは、カイロの標準的なライブラリで、アカウントの抽象化に必要な多くの基本的なデータ構造に送信する必要があります。

• StarkNetスマートコントラクトは、EVMチェーンとは異なり、「コンパイル、ステートメント、展開」の3つの段階を含みます。

• Starknetの上記のインテリジェント契約モデルは、コードの再利用、契約ステータスの再利用、保管、ガベージ契約の検出、およびリースとトランザクションの並列化の実現を助長します。後者の2つはまだ上陸していませんが、カイロスマートコントラクトのアーキテクチャは「必要な条件」を作成しました。

• StarkNetチェーンにはスマートコントラクトアカウントのみがあり、最初からネイティブレベルの抽象的なAAアカウントをサポートしていません。そのAAソリューションは、ERC-4337のアイデアをある程度吸収し、ユーザーが高度にカスタマイズされたトランザクション処理スキームを選択できるようにします。潜在的な攻撃シーンを防ぐために、StarkNetは多くの対策を行い、AAエコシステムの重要な調査を行いました。