Forward the Original Title：解读Starknet智能合约模型与原生AA：特立独行的技术巨匠

オリジナルの著者: Shew & Faust、Web3アドバイザー: CryptoNerdCn、Starknetのコア開発者、ブラウザサイドのCairo開発プラットフォームWASM Cairoの創設者

要約:

Starknetの主な技術的特徴には、ZK証明の生成に有利なCairo言語、ネイティブレベルのAA、およびビジネスロジックが状態保存から独立しているスマートコントラクトモデルが含まれます。 Cairoは汎用性のあるZK言語であり、Starknet上でスマートコントラクトを実装するだけでなく、伝統的な傾向を持つアプリケーションを開発するために使用できます。そのコンパイルプロセスでは、中間言語としてSierraを導入することで、基礎となるバイトコードを直接変更せずにCairoの頻繁な反復を可能にします。さらに、Cairoの標準ライブラリには、口座抽象化に必要な多くの基本データ構造が含まれています。 Starknetスマートコントラクトは、EVMチェーンとは異なり、ビジネスロジックを状態データ保存から分離しています。 Cairo契約の展開には、コンパイル、宣言、展開の3つの段階が関与し、ビジネスロジックはContractクラスで宣言されます。状態データを含む契約のインスタンスは、クラスに関連付けられ、それが含むコードを呼び出すことができます。

Starknetの前述のスマートコントラクトモデルは、コードの再利用、契約状態の再利用、ストレージの階層化、およびジャンク契約の検出に有益です。また、ストレージリースとトランザクションの並列化の実現にも役立ちます。後者の2つはまだ実装されていませんが、Cairoスマートコントラクトの構造はそれらのための「必要条件」を作成しました。Starknetチェーンにはスマートコントラクトアカウントのみがあり、EOAアカウントはありません。最初からネイティブレベルのAAアカウントの抽象化をサポートしています。そのAAプランは、ERC-4337のアイデアをある程度取り入れており、ユーザーが高度にカスタマイズされたトランザクション処理ソリューションを選択できるようにしています。潜在的な攻撃シナリオを防ぐために、Starknetは多くの対策を講じ、AAエコシステムに重要な探求を行っています。

text: Starknetでのトークンの発行に続いて、STRKは徐々にイーサリアムのオブザーバーの目には不可欠な要素になりました。「独立」と「ユーザーエクスペリエンスを無視する」姿勢で知られるこのイーサリアムのレイヤー2スターは、EVMと互換性のある繁栄するレイヤー2エコシステムの中で、静かに独自の領域を切り開いてきました。ユーザーを過度に無視し、Discordに「電子乞食」チャンネルを公然と設定したため、Starknetはかつてコミュニティから批判されました。「非人道的」という非難の中で、その深い技術的専門知識は、あたかもUXと富の創造だけがすべてであるかのように、一瞬にして価値を下げたように見えました。「黄金館の神殿」のセリフ「他人に理解されないことが、私の唯一の誇りだった」は、ほとんどスタークネットの自画像です。しかし、これらの些細なことはさておき、純粋にコードオタクの技術的な好みに基づいて、ZK RollupのパイオニアとしてのStarknetとStarkExは、カイロ愛好家の目にはほとんど宝物です。一部のブロックチェーンゲーム開発者の頭の中では、StarknetとCairoはWeb3のすべてであり、SolidityとMoveを凌駕しています。今日の「技術オタク」と「ユーザー」の間の最大のギャップは、実際には、人々がStarknetを理解していないことに大きく起因しています。ブロックチェーン技術への関心とStarknetの価値の探求に駆り立てられて、この記事の著者は、StarknetのスマートコントラクトモデルとネイティブAAから始めて、その技術的ソリューションとメカニズム設計を簡単に概説し、Starknetの技術的特徴をより多くの人に紹介すると同時に、人々がこの「誤解されたローンレンジャー」を理解するのを助けることを望んでいます。次のセクションでカイロ言語の簡単な紹介に続いて、Starknetのスマートコントラクトモデルとネイティブアカウントの抽象化について議論し、StarknetがネイティブAAをどのように実現するかを説明します。この記事を読んだ後、読者は、異なるウォレットのニーモニックフレーズをStarknetで混在させることができない理由も理解するでしょう。しかし、ネイティブアカウントの抽象化を紹介する前に、まずStarknetによって作成された革新的なカイロ言語を理解しましょう。Cairoの開発プロセスでは、Cairo0と呼ばれる初期バージョンがあり、その後に現代バージョンが続きました。Cairoの現代版の全体的な構文はRustに似ており、実際には用途の広いZK言語です。Starknetでスマートコントラクトを書くために使用されるだけでなく、一般的なアプリケーションの開発にも使用できます。たとえば、カイロ言語を使用してZK本人確認システムを開発でき、このプログラムはStarkNetネットワークに依存することなく独自のサーバーで実行できます。検証可能な計算特性を必要とするプログラムは、カイロ言語を使用して実装できると言えます。そして、Cairoは現在、ZK証明を生成するのに最も役立つプログラミング言語かもしれません。

コンパイルプロセスの観点からは、カイロは図に示すように、中間言語ベースのコンパイル方法を使用しています。写真のシエラは、カイロ言語のコンパイルプロセスにおける中間表現（IR）であり、シエラは、Starknetノードデバイス上で直接実行される、CASMと呼ばれるより低レベルのバイナリコード表現にコンパイルされます。

Sierraを中間表現として導入することで、Cairo言語が新しい機能を追加しやすくなります。多くの場合、基盤となるCASMコードを直接変更することなく、Sierra中間言語を操作するだけで済みます。これにより、多くの手間が省け、Starknetのノードクライアントを頻繁に更新する必要がなくなります。このようにして、StarkNetの基盤となるロジックを変更することなく、カイロ言語の頻繁な反復を実現できます。Cairoの標準ライブラリには、アカウントの抽象化に必要な多くの基本的なデータ構造も含まれています。Cairo のその他のイノベーションには、Cairo Native と呼ばれる理論的なソリューションがあり、これは Cairo をさまざまなハードウェア デバイスに適応できる低レベルのマシン コードにコンパイルすることを計画しています。Starknetノードは、スマートコントラクトを実行する際にCairoVM仮想マシンに依存する必要がなくなります。これにより、コードの実行速度を大幅に向上させることができます(まだ理論段階であり、まだ実装されていません)。

Starknetスマートコントラクトモデル：コードロジックと状態ストレージの剥離

イーサリアム互換チェーンとは異なり、Starknetはそのスマートコントラクトシステムの設計において画期的な革新を成し遂げており、ネイティブAAや並列トランザクション処理などの今後の機能に備えています。ここでは、イーサリアムのような従来のパブリックチェーンとは異なり、Starknet上でのスマートコントラクトの展開は異なるプロセスに従います。イーサリアムのスマートコントラクトを展開する例を取り上げてみましょう。

1. 開発者はスマートコントラクトコードをローカルで書き、エディタを使用してSolidityプログラムをEVMバイトコードにコンパイルします。このバイトコードはその後、EVMによって直接理解および処理されることができます。

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

ソース：not-satoshi.com

Starknetのスマートコントラクトも「まずコンパイルしてからデプロイする」という考え方に従いますが、スマートコントラクトはCairoVMがサポートするCASMバイトコードの形式でチェーン上に展開されます。ただし、StarknetとEVM互換チェーンとの間には、スマートコントラクトの呼び出し方法や状態保存モードにおいて大きな違いがあります。具体的には、イーサリアムのスマートコントラクトはビジネスロジックと状態情報の組み合わせです。例えば、USDTコントラクトはTransferやApprovalなどの一般的な機能を実装するだけでなく、すべてのUSDT保有者の資産状況を保存します。コードと状態が結び付けられており、これにより多くの問題が生じます。まず第一に、DAPPコントラクトのアップグレードや状態移行が困難であり、トランザクションの並列処理も容易ではありません。これは重い技術的負担です。

これに対応して、Starknetは状態の保存方法を改善しました。スマートコントラクトの実装ソリューションでは、DAppsのビジネスロジックは資産の状態から完全に切り離され、別々に保存されます。このアプローチの利点は明らかで、まず、重複したコード展開や冗長なコード展開があるかどうかをシステムが迅速に区別できることです。イーサリアムでは、スマートコントラクトはビジネスロジックと状態データの両方で構成されています。複数のコントラクトのビジネス ロジックが同一で状態データが異なる場合、それらのハッシュも異なるため、システムが "ガベージ コントラクト" が存在するかどうかを判断するのが困難になります。ただし、Starknetのソリューションでは、コードと状態データが分離されているため、コード部分のハッシュに基づいて、同じコードが複数回デプロイされているかどうかをシステムが簡単に検出できます。これにより、重複したコードのデプロイを防ぎ、Starknetノードのストレージスペースを節約できます。

Starknetのスマートコントラクトシステムでは、契約の展開と使用が「コンパイル、宣言、展開」という3つの段階に分かれています。資産発行者がCairo契約を展開したい場合、最初にローカルデバイスで書かれたCairoコードをSierraおよび低レベルバイトコードCASM形式にコンパイルします。次に、契約デプロイヤーは「宣言」トランザクションを公開し、契約のCASMバイトコードとSierra中間コードをチェーンに展開します。これは契約クラスとして名付けられます。

（ソース：Starknet公式ウェブサイト）

後で、資産契約で定義された機能の機能を利用したい場合は、DAppフロントエンドを介して「展開」トランザクションを開始し、契約クラスに関連付けられた契約インスタンスを展開できます。このインスタンスは資産の状態を保持します。その後、ユーザーは契約クラス内の機能を呼び出して契約インスタンスの状態を変更できます。実際、オブジェクト指向プログラミングに精通している人なら、Starknetでのクラスとインスタンスの意味を簡単に理解できるはずです。開発者によって宣言された契約クラスには、スマートコントラクトのビジネスロジックのみが含まれており、誰でも呼び出せる機能が含まれていますが、実際の資産状態は持っておらず、「実体」を直接実装していないため、「魂」だけで「体」がない状態です。ただし、ユーザーが特定の契約インスタンスを展開すると、資産が「具現化」されます。トークンを他の人に譲渡するなど、資産「実体」の状態を変更する必要がある場合は、契約クラスに記述された機能を直接呼び出すことができます。上記のプロセスは、従来のオブジェクト指向プログラミング言語における「インスタンス化」といくぶん似ています（完全に同一ではありませんが）。

スマートコントラクトがクラスとインスタンスに分割された後、ビジネスロジックと状態データが切り離され、Starknetに以下の機能がもたらされます:

1. ストレージティアリングや「ストレージリースシステム」の実現に役立ちます

いわゆるストレージレイヤリングとは、開発者が必要に応じてデータをカスタマイズされた場所に配置できることを意味します。たとえば、Starknetチェーンの下にデータを配置することができます。StarkNetはCelestiaなどのDAレイヤーと互換性があり、DAPP開発者はこれらのサードパーティDAレイヤーにデータを格納することができます。たとえば、ゲームは最も重要な資産データをStarknetメインネットに格納し、CelestiaなどのオフチェーンDAレイヤーに他のデータを格納することができます。このセキュリティ要件に応じてDAレイヤーをカスタマイズするという解決策は、Starknetによって「Volition」と名付けられました。

いわゆる貸し倉システムは、誰もが占有するストレージスペースに対して引き続き支払いを続ける必要があることを意味します。占有するチェーン上のスペースが多いほど、理論上は家賃を支払い続ける必要があります。

イーサリアムのスマートコントラクトモデルでは、契約の所有権が不明確であり、デプロイヤーか資産保持者かがERC-20契約の「家賃」を支払うべきかどうかを区別するのは難しいです。ストレージリース機能は長い間導入されていませんでしたが、契約がデプロイされるときのみデプロイヤーに料金が請求されます。このストレージ料金モデルは理にかなっていません。

Starknet、Sui、CKB、およびSolanaのスマートコントラクトモデルの下では、スマートコントラクトの所有権がより明確に分割され、ストレージ資金を集めやすくなります【現在、Starknetは直接ストレージリースシステムを立ち上げていませんが、将来実装される予定です】

1. 真のコード再利用を実現し、ジャンク契約の展開を削減します

一般的なトークン契約をクラスとしてチェーンに保存することができ、その後、誰でもこのクラス内の関数を呼び出してトークンインスタンスを展開できます。さらに、契約はクラス内のコードを直接呼び出すこともでき、これにより、SolidityのLibrary関数ライブラリと類似した効果が得られます。同時に、Starknetのスマートコントラクトモデルは「ジャンク契約」を識別するのに役立ちます。これは以前説明されていました。コード再利用とジャンク契約の検出をサポートした後、Starknetはチェーンにアップロードされるデータ量を大幅に削減し、ノード上のストレージ圧力をできるだけ低減できます。

1. 実際の契約「状態」の再利用

ブロックチェーン上での契約のアップグレードは主にビジネスロジックの変更を含みます。 Starknetシナリオでは、スマートコントラクトのビジネスロジックは資産の状態から本質的に分離されています。契約インスタンスが関連する契約タイプクラスを変更する場合、ビジネスロジックのアップグレードを完了できます。資産の状態を新しい場所に移行する必要はありません。この形式の契約のアップグレードは、イーサリアムよりも徹底的でネイティブです。

イーサリアム契約の業務ロジックを変更するには、通常、業務ロジックを代理店契約に「外部委託」し、依存する代理店契約を変更することで、主契約の業務ロジックを変更する必要があります。ただし、この方法は簡潔でなく、「ネイティブ」ではありません。

出典：wtf Academy

いくつかのシナリオでは、古いイーサリアム契約が完全に放棄される場合、内部の資産状況は新しい場所に直接移行することはできず、非常に面倒です。カイロ契約は状況を移行する必要がなく、古い状況を直接「再利用」することができます。

1. 取引の並列処理を促進する

異なる取引指示の並列性を最大限にするためには、ビットコイン、CKB、およびSuiで見ることができるように、異なる人々の資産状況を別々の場所に保存することが必要です。上記の目標の前提条件は、スマートコントラクトのビジネスロジックを資産状態データから分離することです。Starknetはまだ並列取引の詳細な技術実装を行っていませんが、将来的には並列取引を重要な目標と見なします。

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

実際、アカウント抽象化（AA）およびEOA（外部所有アカウント）の概念は、ユニークな概念としてイーサリアムコミュニティによって発明されました。多くの新しい公開チェーンでは、EOAアカウントとスマートコントラクトアカウントの区別がなく、イーサリアムスタイルのアカウントシステムの落とし穴を最初から回避しています。例えば、イーサリアムの設定下では、EOAアカウントのコントローラーは取引を開始する前にチェーン上にETHを持っている必要があります。さまざまな認証方法を直接選択する方法はなく、カスタマイズされた支払いロジックを追加するのは非常に面倒です。一部の人々は、イーサリアムのアカウント設計は単に非人間的だとさえ考えています。

フラッグシップ製品であるStarknetやzkSyncEraの「Native AA」チェーンなどを見ると、明らかに違いが見られます。まず、StarknetとzkSyncEraは統一されたアカウントタイプを持っています。チェーン上にはスマートコントラクトアカウントしかありません。最初からEOAアカウントというものはありません。(zkSync Eraは、新しく作成されたユーザーのアカウントにデフォルトで一連の契約コードを展開し、イーサリアムのEOAアカウントの特性をシミュレートしてMetamaskと互換性があるようにします)。

ただし、StarknetはMetamaskなどのEthereum周辺機器との直接的な互換性を考慮していません。ユーザーがStarknetウォレットを初めて使用すると、専用の契約アカウントが自動的にデプロイされます。つまり、前述のコントラクトインスタンスがデプロイされ、このインスタンスはウォレットプロジェクトによって事前にデプロイされたコントラクトクラスに関連付けられます。ユーザーは、クラスに記述された機能の一部を直接呼び出すことができます。さて、興味深いトピックを掘り下げてみましょう:STRKエアドロップを主張するとき、多くの人がArgentとBraavosのウォレットが互いに互換性がないことに気づきました。ArgentからBraavosにニーモニックをインポートすると、主にArgentとBraavosで使用されるアカウント生成アルゴリズムが異なり、同じニーモニックから異なるアカウントアドレスが生成されたため、対応するアカウントをエクスポートできませんでした。具体的には、Starknetでは、新しく展開されたコントラクトアドレスは、次のように決定論的アルゴリズムによって導き出すことができます。

上記の「pedersen()」関数は、ZKシステムで使いやすいハッシュアルゴリズムです。アカウントを生成するプロセスには、生成されたアカウントアドレスである対応するハッシュを生成するために、pedersen関数にいくつかの特別なパラメーターを指定することが含まれます。上の画像は、Starknetが「新しいコントラクトアドレス」を生成するために使用するパラメータを示しています。「deployer_address」は「コントラクト展開者」のアドレスを表します。このパラメータは空にすることができ、事前にStarknet契約アカウントを持っていなくても、新しい契約を展開できます。「ソルト」は、コントラクトアドレスの計算に使用されるソルト値であり、基本的にはコントラクトアドレスの重複を避けるために導入された乱数です。「class_hash」は、コントラクト インスタンスが関連付けられている前述のクラスのハッシュ値に対応します。「constructor_calldata_hash」は、コントラクトの初期化パラメータのハッシュを表します。

上記の式に基づいて、ユーザーは契約をチェーンに展開する前に生成された契約アドレスを計算することができます。Starknetでは、ユーザーは事前にStarknetアカウントを持たずに契約を直接展開することができます。

1. ユーザーは、最初に展開したい契約インスタンスとそれを関連付ける契約クラスを決定し、クラスのハッシュを初期化パラメーターの1つとして使用し、生成された契約アドレスを決定するためのソルトを計算します。
2. 契約を展開する場所を知った後、ユーザーはまず契約展開手数料として一定額のETHをそのアドレスに送金します。一般的に、このETHはL1からスタークネットワークにクロスチェーンブリッジを介して送金する必要があります。
3. ユーザーは契約展開のための取引リクエストを開始します。

実際、すべてのStarknetアカウントは上記のプロセスを通じて展開されていますが、ほとんどのウォレットは詳細をシールドしており、ユーザーはETHを送金すると契約アカウントが展開されたとは認識していません。

上記の解決策は、異なるウォレットがアカウントアドレスを生成すると、生成される結果が一貫性がないため、互換性の問題を引き起こしました。以下の条件を満たすウォレットのみが混合できます:

1. ウォレットで使用される秘密鍵から派生した公開鍵は、署名アルゴリズムと同じです;
2. ウォレットのソルト計算プロセスは同じです;
3. ウォレットのスマートコントラクトクラスは、実装の詳細において基本的に異なるものではありません;

前述のケースでは、ArgentとBraavosの両方がECDSA署名アルゴリズムを使用しましたが、塩の計算方法が異なり、同じニーモニックから生成されたアカウントアドレスが一貫していませんでした。

さて、アカウント抽象化のトピックについて再考しましょう。StarknetとzkSync Eraは、トランザクション処理に関与する一連のプロセス（デジタル署名の確認など）やガス手数料の支払いなどを、“チェーン層”の外に移動しました。ユーザーは、上記のロジックの実装詳細を独自のアカウントでカスタマイズできます。たとえば、Starknetスマートコントラクトアカウントに専用のデジタル署名確認機能を展開することができます。あなたがイニシエートしたトランザクションを受信すると、Starknetノードは、あなたがチェーン上でカスタマイズした一連のトランザクション処理ロジックを呼び出します。

このアプローチは明らかにより柔軟性を提供します。ただし、イーサリアムの設計では、アイデンティティ検証（デジタル署名）などのロジックがノードクライアントコードにハードコードされており、カスタマイズ可能なアカウント機能をネイティブにサポートすることはできません。

Starknetのアーキテクトによって指定されたネイティブAAソリューションの回路図。取引の検証とガス手数料の資格確認は、処理のためにオンチェーン契約に転送されます。チェーンの基礎となる仮想マシンは、ユーザーによってカスタマイズまたは指定されたこれらの機能を呼び出すことができます。

zkSyncEraとStarknetの関係者によると、アカウント機能に対するこのモジュール式アプローチは、EIP-4337に触発されています。しかし、両者を際立たせているのは、zkSyncとStarknetが最初からアカウントタイプを統合し、トランザクションタイプを統合し、単一のエントリポイントを利用してすべてのトランザクションを受信して処理したことです。対照的に、イーサリアムは、歴史的な荷物と、ハードフォークなどの積極的な反復戦略をできるだけ避けたいという財団の願望により、問題を解決するために別の方法を使用してEIP-4337をサポートしました。しかし、その結果、EOAアカウントとEIP-4337ソリューションにはそれぞれ独立したトランザクション処理ワークフローがあり、ネイティブAAの俊敏性とは異なり、厄介で煩雑に見えます。

ソース：ArgentWallet

ただし、Starknetのネイティブアカウント抽象化はまだ完全な成熟を迎えていません。実用的な観点からは、StarknetのAAアカウントはカスタム署名検証アルゴリズムを実装していますが、現時点ではETHとSTRKでのガス手数料支払いのみをサポートしており、第三者のガス支払いはまだサポートされていません。そのため、StarknetのネイティブAAにおける進捗は、「理論的なフレームワークはほぼ成熟しているが、実装はまだ進行中」と表現できます。Starknetは内部的にスマートコントラクトアカウントしか持たないため、取引の全プロセスではアカウントスマートコントラクトの影響が考慮されます。まず、取引がStarknetノードのメモリプール（Mempool）に受信されると、検証が行われます。

1. 取引のデジタル署名が正しいかどうかをチェックし、その時点で署名者のアカウントのカスタム検証関数が呼び出されます;
2. イニシエータの口座残高がガス料金をカバーできるかどうかを確認します。

ここで注意すべきは、アカウントスマートコントラクトでカスタマイズされた署名検証機能を使用すると、攻撃シナリオが存在するということです。なぜなら、メモリプールは新しいトランザクションの署名を検証する際にガス料金を請求しないからです（ガス料金が直接請求されれば、より深刻な攻撃シナリオが発生します）。悪意のあるユーザーはまず、自分のアカウント契約で超複雑な署名検証機能をカスタマイズし、その後大量のトランザクションを起動することができます。これらのトランザクションが検証されると、カスタマイズされた複雑な署名検証機能が呼び出され、ノードの計算リソースを直接枯渇させることができます。このような状況を避けるために、StarkNetはトランザクションに以下の制限を課しています:

1. 単位時間内に単一のユーザーが開始できる取引数には上限があります;
2. スタークネットのアカウント契約におけるカスタム署名検証機能には複雑さの制限があり、過度に複雑な署名検証機能は実行されません。スタークネットは署名検証機能のガス消費量を制限しています。署名検証機能によって消費されるガス量が高すぎる場合、トランザクションは直接拒否されます。同時に、アカウント契約の署名検証機能は他の契約を呼び出すことが許可されていません。

Starknetトランザクションのフローチャートは次のようになります。

トランザクション検証プロセスをさらに迅速化するために、StarknetノードクライアントはBraavosおよびArgentウォレットの署名検証アルゴリズムを直接実装していることは注目に値します。ノードは、これら2つの主要な主流のStarknetウォレットから生成されたトランザクションを検出すると、クライアントに組み込まれているBraavos/Argent署名アルゴリズムを呼び出します。このキャッシングのようなアプローチにより、Starknetはトランザクション検証時間を短縮できます。トランザクションデータがシーケンサによって検証された後(シーケンサの検証手順はメモリプールの検証手順よりもはるかに徹底的です)、シーケンサはトランザクションをパッケージ化し、メモリプールからZKプルーフジェネレータに送信します。この段階に入った取引は、失敗した場合でもガス料金が請求されます。ただし、読者がStarknetの歴史に精通している場合は、以前のバージョンのStarknetが失敗したトランザクションに対して手数料を請求しなかったことに気付くでしょう。トランザクションの失敗の最も一般的なシナリオは、ユーザーが1ETHしか持っていないのに、10ETHを外部に転送しようとする場合で、これは明らかに論理エラーを示しており、必然的に失敗しますが、実行前に結果は誰にもわかりません。ただし、過去には、StarkNetはそのような失敗したトランザクションに対して手数料を請求しませんでした。これらのコストのかからない誤ったトランザクションは、Starknetノードの計算リソースを浪費し、DDoS攻撃シナリオにつながる可能性があります。表面的には、誤った取引に対して手数料を請求することは簡単に見えますが、実際には非常に複雑です。Starknetは、主に失敗したトランザクションのガス料金の問題に対処するために、Cairo1言語の新しいバージョンを導入しました。ご存知のように、ZKプルーフは有効性の証明であり、失敗したトランザクションの結果は無効であり、チェーンに出力結果を残すことはできません。妥当性の証明を使用して、特定の命令の実行が無効であり、出力結果を生成できないことを証明しようとすると、奇妙に聞こえ、実際には実行不可能です。そのため、これまでStarknetは、プルーフ生成時に出力結果を生成できなかった失敗したトランザクションを除外していました。その後、Starknetチームはよりスマートなソリューションを採用し、新しいコントラクト言語であるCairo1を構築し、「すべてのトランザクション命令がアウトプット結果を生成し、オンチェーンにすることができる」ことを保証しました。一見すると、すべてのトランザクションが出力結果を生成できるという事実は、論理エラーが発生しないことを意味します。ただし、ほとんどの場合、トランザクションは命令の実行を中断するバグに遭遇するため失敗します。トランザクションが中断されず、出力結果を正常に生成するようにすることは困難ですが、実際には、トランザクションの実行がスムーズではなかったことを示す False 値を返すものの、中断につながる論理エラーが発生したときにトランザクションが出力結果を生成できるようにするという、単純な代替ソリューションがあります。False値を返すと出力結果も返されるため、Cairo1では、命令が論理エラーに遭遇したか、一時的に中断されたかに関係なく、出力結果を生成してオンチェーンにすることができることに注意することが重要です。この出力結果は、正しい場合もあれば、False エラー メッセージになる場合もあります。たとえば、次のコード スニペットについて考えてみます。

この時点で、_balances::read(from) - amount はアンダーフローエラーを引き起こす可能性があり、対応するトランザクション命令が中断され、チェーン上にトランザクション結果が残らずに停止することがあります。しかし、以下の形式で書き直すと、トランザクションが失敗した場合でも出力結果を返し、それをチェーン上に残します。美的な観点から見ると、すべてのトランザクションが滑らかにチェーン上にトランザクションのアウトプットを残せるように見え、一様な手数料の徴収が特に合理的であるように見えます。

StarknetAA コントラクト概要

この記事の一部の読者がプログラミングのバックグラウンドを持っている可能性を考慮して、Starknetのアカウント抽象契約のインターフェースの簡単なデモをここに示します。

ザvalidate_declare上記のインターフェースは、ユーザーによって開始された宣言トランザクションを検証するために使用されます。検証する一般的なトランザクション検証に使用され、主にユーザーの署名の正確性を検証します。一方、実行はトランザクションの実行に使用されます。特に、Starknet契約口座は固有にマルチコールをサポートしており、複数のコールを行うことができます。マルチコール機能により、特定のDeFiプロトコルとやり取りする際に次の3つのトランザクションをまとめて処理するなど、さまざまな興味深い機能が可能です。

1. 最初の取引でDeFiコントラクトにトークンを認可します。
2. 第2トランザクションでDeFi契約のロジックをトリガーする。
3. 第3トランザクションでDeFiコントラクトへの権限を取り消す。

もちろん、マルチコールの原子性により、アービトラージ取引のようなより複雑なユースケースがあります。

概要

Starknetの主な技術的特徴には、ZK証明生成に最適化されたCairo言語、ネイティブレベルのアカウント抽象化、およびビジネスロジックと状態ストレージを分離するスマートコントラクトモデルが含まれています。

Cairoは、Starknet上でスマートコントラクトに使用することも、より伝統的なアプリケーションを開発するためにも使用できる汎用性のあるZK言語です。そのコンパイルプロセスでは、中間言語としてSierraを導入することで、Cairoは基礎となるバイトコードを変更せずに頻繁に反復することができ、変更を中間言語に伝播させるだけです。Cairo標準ライブラリには、口座抽象化に必要な多くの基本データ構造も含まれています。

Starknetのスマートコントラクトは、EVMチェーンとは異なり、ビジネスロジックを状態データの格納から分離します。Cairo契約の展開には、コンパイル、宣言、展開の3つの段階があります。ビジネスロジックはContractクラスで宣言され、状態データを含むContractインスタンスはクラスに関連付けられ、それが含むコードを呼び出すことができます。

Starknetのスマートコントラクトモデルは、コードの再利用、契約状態の再利用、ストレージの階層化、および不要な契約の検出を容易にします。また、ストレージリースやトランザクションの並列化の実装を容易にしますが、これらの機能はまだ完全に実装されていません。Cairoスマートコントラクトのアーキテクチャは、これらの機能のための必要な条件を作り出します。

Starknetにはスマートコントラクトアカウントのみがあり、EOAアカウントはありません。また、最初からネイティブレベルのAA（アカウント抽象化）ソリューションをサポートしています。そのAAソリューションは部分的にERC-4337のアイデアを取り入れており、ユーザーが高度にカスタマイズされたトランザクション処理ソリューションを選択できます。潜在的な攻撃シナリオを防ぐため、Starknetはさまざまな対策を実装しており、AAエコシステムにおける重要な探求を行っています。

免責事項：

1. この記事は[から転載されましたゲート ウェブ3]. *元のタイトル「解読Starknetスマートコントラクトモデルと原生AA：特立独行の技術巨匠」を転送します。すべての著作権は元の著者[Shew＆Faust]に帰属します。この転載に異議がある場合は、お問い合わせください。ゲートラーンチームがすぐに対処します。
2. 責任の免責事項：この記事に表現されている意見は著者個人のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームによって他の言語への記事の翻訳が行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。