作者: シュー & ファウスト、オタク web3

コンサルタント: CryptoNerdCn、Starknet エコシステムのコア開発者、ブラウザサイド Cairo 開発プラットフォーム WASM Cairo の創設者

まとめ：

Starknet の主な技術機能には、ZK 証明の生成、ネイティブ レベルの AA、ビジネス ロジックや状態ストレージから独立したスマート コントラクト モデルを容易にする Cairo 言語が含まれます。

Cairo は、Starknet でスマート コントラクトを実装したり、より伝統的なアプリケーションを開発したりするために使用できるユニバーサル ZK 言語です。Sierra は、コンパイル プロセスの中間言語として導入され、Cairo が最下層を変更することなく頻繁に反復できるようにします。中間言語に変更を送信するだけで済みます。Cairo の標準ライブラリには、アカウントの抽象化に必要な多くの基本的なデータ構造も含まれています。

Starknet スマート コントラクトは、ビジネス ロジックとステータス データを別々に保存します。EVM チェーンとは異なり、Cairo コントラクト デプロイメントには、「コンパイル、宣言、デプロイメント」の 3 つの段階が含まれます。ビジネス ロジックは Contract クラスで宣言され、Contract インスタンスにはステータスが含まれますデータをクラスと組み合わせて関連付けを確立し、後者に含まれるコードを呼び出すことができます。

上述した Starknet のスマート コントラクト モデルは、コードの再利用、コントラクト状態の再利用、ストレージの階層化、ジャンク コントラクトの検出に役立ち、ストレージ リースやトランザクションの並列化の実現にも役立ちます。後者の 2 つはまだ実装されていませんが、カイロのスマート コントラクトの構造により、それらに「必要な条件」が作成されています。

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

本文: Starknet によるトークンの発行後、STRK はイーサリアム監視者の目には徐々に不可欠な要素の 1 つになりました。このイーサリアム レイヤー 2 のスターは常に「異端者」で「ユーザー エクスペリエンスに注意を払っていない」ことで知られていますが、世間から距離を置いて暮らしている隠者のようなもので、EVM が存在するレイヤー 2 エコシステムで静かに自分のニッチを切り開いています。互換性が普及しています。

本文: Starknet によるトークンの発行後、STRK はイーサリアム監視者の目には徐々に不可欠な要素の 1 つになりました。このイーサリアム レイヤー 2 のスターは常に「異端者」で「ユーザー エクスペリエンスに注意を払っていない」ことで知られていますが、世間から距離を置いて暮らしている隠者のようなもので、EVM が存在するレイヤー 2 エコシステムで静かに自分のニッチを切り開いています。互換性が普及しています。

ユーザーを無視しすぎ、さらには Discord 上に「電子乞食」チャンネルを公に開設したため、Starknet はかつて魯毛党から批判されました。「非人間的」と批判される一方で、その深い技術的成果は即座に「無価値」になりました。 UXと富の創造効果だけがすべてのようです。 『金閣寺』の「他人に理解されないことが、私の唯一の誇りになった」というフレーズは、まさにスタークネットの自画像である。

しかし、純粋にコードマニアの「技術的好み」に基づいたこれらの些細な問題はさておき、ZK Rollup の先駆者の 1 つである 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 証明を生成するのに最も適したプログラミング言語かもしれません。

コンパイル プロセスの観点から見ると、Cairo は、次の図に示すように、中間言語ベースのコンパイル方法を使用します。写真の Sierra は、カイロ言語コンパイル プロセスの中間形式 (IR) であり、Sierra は、Starknet ノード デバイス上で直接実行される、CASM という名前の下位レベルのバイナリ コード形式にコンパイルされます。

Sierra を中間形式として導入すると、Cairo 言語に新しい機能を追加することが容易になります。多くの場合、基盤となる CASM コードを直接変更せずに、Sierra 中間言語を操作するだけで済みます。これにより、多くのトラブルが節約され、Starknet ノードがクライアントは頻繁に更新する必要はありません。このようにして、StarkNet の基礎となるロジックを変更することなく、カイロ言語の頻繁な反復を実現できます。 Cairo の標準ライブラリには、アカウントの抽象化に必要な多くの基本的なデータ構造も含まれています。

Cairo の他のイノベーションには、Cairo Native と呼ばれる理論的ソリューションが含まれており、これは Cairo を、さまざまなハードウェア デバイスに適応できる低レベルのマシン コードにコンパイルすることを計画しています。Starknet ノードは、スマート コントラクトの実行時に CairoVM 仮想マシンに依存する必要がなくなります。コードの実行速度が大幅に向上します (まだ理論段階にあり、実装されていません)。

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

EVM 互換チェーンとは異なり、Starknet はスマート コントラクト システムの設計に画期的な革新をもたらしており、これらの革新は主に、将来開始されるネイティブ AA およびパラレル トランザクション機能に向けて準備されています。ここで、イーサリアムなどの従来のパブリック チェーンでは、スマート コントラクトのデプロイメントは多くの場合、「コンパイル後のデプロイメント」方式に従っていることを知っておく必要があります。ETH スマート コントラクトを例に挙げます。

1. 開発者がローカルでスマート コントラクトを作成した後、エディターを使用して Solidity プログラムを EVM バイトコードにコンパイルし、EVM が直接理解して処理できるようにします。

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

（画像出典：not-さとし.com）

Starknetのスマートコントラクトも「最初にコンパイルしてからデプロイする」という考え方に従っていますが、スマートコントラクトはCairoVMがサポートするCASMバイトコードの形式でチェーン上にデプロイされます。ただし、スマートコントラクトの呼び出し方法と状態保存モードの点で異なります。契約とは異なり、Starknet は EVM チェーンと互換性がありません。大きな違いがあります。

正確に言うと、イーサリアムのスマートコントラクト = ビジネスロジック + ステータス情報です。たとえば、USDT コントラクトは、転送や承認などの共通機能を実装するだけでなく、すべての USDT 保有者の資産ステータスも保存します。コードとステータスは、Together で結合されます。これは多くの問題を引き起こします。第一に、これは DAPP 契約のアップグレードや状態移行に役立たず、トランザクションの並列処理にも役立たないため、技術的な負担が大きくなります。

正確に言うと、イーサリアムのスマートコントラクト = ビジネスロジック + ステータス情報です。たとえば、USDT コントラクトは、転送や承認などの共通機能を実装するだけでなく、すべての USDT 保有者の資産ステータスも保存します。コードとステータスは、Together で結合されます。これは多くの問題を引き起こします。第一に、これは DAPP 契約のアップグレードや状態移行に役立たず、トランザクションの並列処理にも役立たないため、技術的な負担が大きくなります。

この点で、Starknet は状態保存方法を改善しました。そのスマート コントラクト実装計画では、DAPP のビジネス ロジックが資産ステータスから完全に切り離され、別の場所に保存されます。この利点は明らかです。まず、システムの効率が向上し、コードの重複または冗長なデプロイメントが存在するかどうかを迅速に特定します。ここでの原則は次のとおりです。

イーサリアムのスマートコントラクト = ビジネスロジック + ステータスデータ ビジネスロジックが全く同じでステータスデータが異なるコントラクトが複数ある場合、これらのコントラクトのハッシュも異なります この時点でシステムが区別することは困難ですこれらの契約が重複しているかどうか、「ジャンク契約」があるかどうか。

Starknet のソリューションでは、コード部分とステータス データが直接分離されており、システムはコード部分のハッシュに基づいて、ハッシュが同じであるため、同じコードが複数回デプロイされているかどうかをより簡単に判断できます。これにより、コードのデプロイ動作の繰り返しを防止し、Starknet ノード上のストレージ スペースを節約できます。

Starknetのスマートコントラクトシステムでは、コントラクトの展開と利用は「コンパイル、宣言、展開」の3段階に分かれています。資産発行者が Cairo コントラクトを展開したい場合、最初のステップは、書かれた Cairo コードを自分のデバイス上でローカルに Sierra および基礎となるバイトコード CASM 形式にコンパイルすることです。

次に、コントラクト デプロイヤは「宣言」トランザクションを発行し、コントラクトの CASM バイトコードと Sierra 中間コードをコントラクト クラスという名前のチェーンにデプロイします。

（画像出典：スタークネット公式サイト）

後で、資産コントラクトで定義された関数を使用する場合は、DAPP フロントエンドを通じて「デプロイ」トランザクションを開始し、コントラクト クラスに関連付けられたコントラクト インスタンスをデプロイできます。このインスタンスには、資産のステータスが保存されます。その後、ユーザーは Contract クラスの関数 function を呼び出して、Contract インスタンスの状態を変更できます。

実際、オブジェクト指向プログラミングを理解している人なら誰でも、Starknet でクラスとインスタンスが何を表しているのかを簡単に理解できるはずです。開発者が宣言したContract Classには、スマートコントラクトのビジネスロジックのみが含まれており、誰でも呼び出すことができる関数ですが、実際の資産の状態を持たないため、「資産の実体」を直接実装するものではありません。あるのは「魂」だけで「肉体」はない。

ユーザーが特定の Contract インスタンスをデプロイすると、資産が「具体化」されます。トークンを他人に譲渡するなど、資産「エンティティ」のステータスを変更したい場合は、Contract Classに記述された関数を直接呼び出すことができます。上記のプロセスは、従来のオブジェクト指向プログラミング言語の「インスタンス化」に似ています (ただし、まったく同じではありません)。

スマート コントラクトがクラスとインスタンスに分離されると、ビジネス ロジックとステータス データが分離され、Starknet に次の機能がもたらされます。

1. ストレージ階層化と「ストレージレンタルシステム」の実現に貢献

いわゆるストレージ階層化とは、開発者が Starknet チェーンの下など、独自のニーズに応じてカスタマイズされた場所にデータを配置できることを意味します。 StarkNet は Celestia などの DA レイヤーと互換性を持つ準備ができており、DAPP 開発者はこれらのサードパーティ DA レイヤーにデータを保存できます。たとえば、ゲームは最も重要な資産データを Starknet メインネットに保存し、他のデータを Celestia などのオフチェーン DA レイヤーに保存できます。セキュリティ要件に従って DA 層をカスタマイズするこのソリューションは、Starknet によって「Volition」と名付けられました。

いわゆるストレージレンタルシステムとは、誰もが占有するストレージスペースに対して料金を支払い続けなければならないことを意味します。チェーン上で占有しているスペースと同じだけ、理論的には家賃を払い続ける必要があります。

イーサリアムのスマート コントラクト モデルでは、コントラクトの所有権が不明瞭で、ERC-20 コントラクトの「レンタル」をデプロイヤーと資産所有者のどちらが支払うべきかを区別するのは困難です。導入者には料金が請求されますが、これは合理的な保管料金モデルではありません。

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

2. 真のコード再利用を実現し、ジャンク コントラクトの展開を削減します。

チェーン上にクラスとして保存される一般的なトークン コントラクトを宣言すると、誰もがこのクラスの関数を呼び出して独自のトークン インスタンスをデプロイできます。さらに、コントラクトはクラス内のコードを直接呼び出すこともでき、Solidity のライブラリ関数ライブラリと同様の効果を実現します。

同時に、Starknet のスマート コントラクト モデルは、「ジャンク コントラクト」の特定にも役立ちます。これについては以前に説明しました。コードの再利用とジャンク コントラクトの検出をサポートした後、Starknet はチェーン上のデータ量を大幅に削減し、ノードにかかるストレージの負担を可能な限り軽減できます。

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

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

イーサリアム契約のビジネスロジックを変更するには、代理店契約にビジネスロジックを「委託」し、従属代理店契約を変更することで主契約のビジネスロジックを変更する必要がある場合が多いですが、この方法はそれほど単純ではありません。そして「ネイティブではない」。

（画像出典：wtfアカデミー）

シナリオによっては、古いイーサリアムコントラクトを完全に破棄した場合、内部の資産ステータスを新しい場所に直接移行することができず、非常に面倒ですが、カイロコントラクトではステータスを移行する必要がなく、直接「再利用」することができます。古いものの状態です。

4. トランザクションの並列処理に役立つ

シナリオによっては、古いイーサリアムコントラクトを完全に破棄した場合、内部の資産ステータスを新しい場所に直接移行することができず、非常に面倒ですが、カイロコントラクトではステータスを移行する必要がなく、直接「再利用」することができます。古いものの状態です。

4. トランザクションの並列処理に役立つ

さまざまな取引命令の並行性を最大限に高めるために必要な手順は、ビットコイン、CKB、Sui で見られるように、さまざまな人々の資産ステータスを別々の場所に保存することです。上記の目標の前提条件は、スマート コントラクトのビジネス ロジックを資産ステータス データから分離することです。 Starknet はトランザクション並列処理の詳細な技術実装をまだ実装していませんが、並列トランザクションは将来の重要な目標となるでしょう。

Starknet のネイティブ AA とアカウント契約の導入

実際、いわゆるアカウント抽象化と AA はイーサリアム コミュニティによって発明された独自の概念であり、多くの新しいパブリック チェーンでは EOA アカウントとスマート コントラクト アカウントの区別がなく、イーサリアム スタイルのアカウント システムはイーサリアム コミュニティから回避されています。始まりのピット。例えば、イーサリアムの設定では、EOA アカウントコントローラーはトランザクションを開始する前にチェーン上に ETH を持たなければなりませんが、さまざまな認証方法を直接選択する方法はなく、カスタマイズされた支払いロジックを追加するのは非常に面倒です。イーサリアムのアカウントデザインは単に反人間的であるとさえ考える人もいます。

Starknet や zkSyncEra などの「ネイティブ AA」に焦点を当てたチェーンを見ると、明らかな違いが観察できます: まず、Starknet と zkSyncEra はアカウント タイプが統一されています。チェーン上にはスマート コントラクト アカウントのみが存在し、そのようなものはありません。最初から EOA アカウントとして使用します (zkSync Era は、メタマスクとの互換性を容易にするために、ユーザーが新しく作成したアカウントに一連のコントラクト コードをデフォルトで展開し、イーサリアム EOA アカウントの特性をシミュレートします)。

Starknetはメタマスクなどのイーサリアム周辺機能との直接的な互換性を考慮しておらず、ユーザーが初めてStarknetウォレットを利用する際には専用のコントラクトアカウントが自動的にデプロイされますが、端的に言えば上記のコントラクトインスタンスをデプロイすることになります。ウォレットプロジェクトにはコントラクトインスタンスが事前にデプロイされており、コントラクトクラスに関連付けられているため、クラス内に記述された一部の関数を直接呼び出すことができます。

次に、興味深いトピックについて話します: STRK エアドロップを受け取ったとき、多くの人が Argent と Braavos ウォレットが互いに互換性がないことに気づきました. Argent のニーモニック フレーズを Braavos にインポートした後、対応するアカウントをエクスポートできません. これは実際には Argent が原因ですおよび Braavos 異なるアカウント生成計算方法が使用されるため、同じニーモニック フレーズに対して異なるアカウント アドレスが生成されます。

具体的には、Starknet では、新しくデプロイされたコントラクト アドレスは、次の式を使用した決定論的アルゴリズムを通じて取得できます。

上の式の pedersen() は、ZK システムで使いやすいハッシュ アルゴリズムです。アカウントを生成するプロセスは、実際には、いくつかの特別なパラメーターを pedersen 関数に入力して、対応するハッシュを生成することです。このハッシュは、生成されたハッシュですアカウントアドレスです。

上の図は、Starknet が「新しいコントラクト アドレス」を生成するために使用するいくつかのパラメーターを示しています。deployer_address は、「コントラクト デプロイヤ」のアドレスを表します。このパラメーターは空にすることができます。事前に Starknet コントラクト アカウントを持っていない場合でも、まだ新しいコントラクトを展開しています。

上の図は、Starknet が「新しい契約アドレス」を生成するために使用するいくつかのパラメーターを示しています。deployer_address は、「契約デプロイヤー」のアドレスを表します。このパラメーターは空にすることができます。事前に Starknet 契約アカウントを持っていない場合でも、まだ新しいコントラクトを展開しています。

Salt はコントラクトアドレスのソルト値を計算するために使用され、簡単に言うと乱数ですが、実際にはコントラクトアドレスの重複を避けるためにこの変数が導入されています。 class_hash は先ほど紹介したコントラクトインスタンスに対応するクラスのハッシュ値です。そしてconstructor_calldata_hashはコントラクト初期化パラメータのハッシュを表します。

上記の式に基づいて、ユーザーはコントラクトがチェーンにデプロイされる前に、生成されたコントラクト アドレスを事前に計算できます。 Starknet を使用すると、ユーザーは事前に Starknet アカウントを持たずにコントラクトを直接展開できます。プロセスは次のとおりです。

1. ユーザーはまず、デプロイしたいコントラクト インスタンス、どのコントラクト クラスと関連付けたいかを決定し、そのクラスのハッシュを初期化パラメータの 1 つとして使用し、生成したコントラクト アドレスを知るためにソルトを計算します。

2. ユーザーはコントラクトを展開する場所を知った後、まずコントラクト展開料金として一定量の ETH をそのアドレスに送金します。一般に、ETH のこの部分は、クロスチェーン ブリッジを介して L1 から Starknet ネットワークに渡される必要があります。

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

実際、すべての Starknet アカウントは上記のプロセスを経てデプロイされますが、ほとんどのウォレットは詳細を保護しており、ユーザーはそのプロセスをまったく認識することができず、あたかも ETH を送金した後に契約アカウントがデプロイされるかのようです。

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

前述のケースでは、Argent と Braavos の両方が ECDSA 署名アルゴリズムを使用していましたが、両者のソルト計算方法が異なっていたため、2 つのウォレットで同じニーモニック フレーズによって生成されたアカウント アドレスが一致しなくなります。

アカウントの抽象化の話に戻りましょう。 StarknetとzkSync Eraは、本人確認（デジタル署名の検証）やガス料金の支払い、その他のコアロジックなど、トランザクション処理プロセスに関わる一連のプロセスを「チェーンの最下層」の外側に実装する。ユーザーは、自分のアカウントで上記のロジックの実装の詳細をカスタマイズできます。

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

イーサリアムの設計では、本人確認 (デジタル署名) などのロジックがノードのクライアント コードにハードコーディングされており、アカウント機能のカスタマイズをネイティブにサポートできません。

(Starknet アーキテクトによって指定されたネイティブ AA ソリューションの概略図。トランザクション検証とガス料金適格性検証は、処理のためにオンチェーン コントラクトに転送されます。チェーンの基礎となる仮想マシンは、これらのユーザー定義または指定された関数を呼び出すことができます)

zkSyncEra と Starknet 関係者によると、この一連のアカウント機能モジュール化のアイデアは EIP-4337 に基づいています。しかし、違いは、zkSync と Starknet が最初からアカウント タイプを統合し、トランザクション タイプを統一し、すべてのトランザクションを受信して​​処理するために統一された入り口を使用していることです。しかし、イーサリアムには歴史的な問題があり、財団はハードフォークを可能な限り回避したいと考えています大まかな反復計画を待って、「カーブで国を救う」という EIP-4337 計画をサポートします。ただし、その影響は、EOA アカウントと 4337 計画がそれぞれ独立したトランザクション処理プロセスを採用することになり、扱いにくく肥大化しているように見えます。ネイティブの AA とは異なり、便利です。

(画像出典: ArgentWallet)

ただし、Starknet のネイティブ アカウントの抽象化はまだ完全に成熟していません。実際の進捗から判断すると、Starknet の AA アカウントは署名検証アルゴリズムのカスタマイズを実装しています。ただし、手数料支払いのカスタマイズについては、現在 Starknet は実際には ETH のみをサポートし、STRK はガス料金とガス料金を支払いますガスの第三者支払いはまだサポートしていません。したがって、ネイティブ AA に関する Starknet の進歩は、「理論的な解決策は基本的に成熟しており、実用的な解決策はまだ進歩している」と言えます。

Starknet にはスマート コントラクト アカウントのみが存在するため、アカウントのスマート コントラクトの影響はトランザクション プロセス全体で考慮されます。まず、トランザクションが Starknet ノードのメモリ プール (Mempool) で受信された後、検証する必要があります。検証手順には次のものが含まれます。

ここで、アカウントスマートコントラクトでカスタマイズされた署名検証機能を使用するということは、攻撃シナリオが存在することを意味することに注意してください。メモリ プールでは、新しいトランザクションの署名を検証するときにガス料金が請求されないため (ガス料金が直接請求される場合、より深刻な攻撃シナリオにつながる可能性があります)。悪意のあるユーザーは、まずアカウント契約で非常に複雑な署名検証機能をカスタマイズし、その後、大量のトランザクションを開始することができ、これらのトランザクションが検証されると、カスタマイズされた複雑な署名検証機能を呼び出し、ノードの電力を直接使い果たす可能性があります。リソース。

この状況を回避するために、StarkNet はトランザクションに次の制限を課します。

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

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

トランザクション検証プロセスをさらに高速化するために、Braavos ウォレットと Argent ウォレットの署名検証アルゴリズムが Starknet ノード クライアントに直接実装されていることは注目に値します。ノードがトランザクションがこれら 2 つの主流の Starknet ウォレットから生成されたことを検出すると、 Braavos/Argent 署名アルゴリズムは、このキャッシュのようなアイデアにより、Starknet のトランザクション検証時間を短縮できます。

トランザクション データがシーケンサーの検証に合格した後 (シーケンサーの検証手順はメモリ プール検証よりもはるかに深い)、シーケンサーはメモリ プールからトランザクションをパッケージ化し、ZK 証明書ジェネレーターに送信します。このリンクに入るトランザクションが失敗した場合でも、ガスが請求されます。

しかし、もし読者が Starknet の歴史を理解していれば、初期の Starknet では失敗した取引に対して手数料が請求されなかったことに気づくでしょう。最も一般的な取引失敗の状況は、ユーザーが 1 ETH しか資金を持っていないのに 10 ETH を送金することです。この種のトランザクションには明らかにロジックがあります。間違いがあれば最終的には必ず失敗しますが、結果がどうなるかは実行されるまで誰にもわかりません。

しかし、StarkNet は過去にそのような失敗した取引に対して手数料を請求したことはありません。このコストのかからない誤ったトランザクションは、Starknet ノードのコンピューティング リソースを浪費し、DDoS 攻撃シナリオにつながります。一見、誤った取引に対する手数料の請求は簡単に実行できるように見えますが、実際には非常に複雑です。 Starknet は、失敗したトランザクションのガス収集の問題を主に解決するために、Cairo1 言語の新バージョンをリリースしました。

ZK Proof は有効性の証明であり、失敗したトランザクションの結果は無効であり、出力結果をチェーンに残すことができないことは誰もが知っています。有効性証明を使用して、特定の命令が無効で出力結果を生成できないことを証明しようとすることは、非常に奇妙に聞こえますが、実際には実行可能ではありません。したがって、以前は Starknet がプルーフを生成するときに、出力結果を生成できなかった失敗したトランザクションをすべて直接排除していました。

Starknet チームはその後、よりスマートなソリューションを採用し、新しいコントラクト言語 Cairo1 を構築しました。これにより、「すべてのトランザクション命令が出力結果を生成し、オンチェーンにできる」ようになりました。一見すると、すべてのトランザクションは出力を生成できますが、これは論理エラーが存在しないことを意味しますが、ほとんどの場合、トランザクションが失敗するのは、命令の実行が中断されるバグが発生したためです。

決して中断せずに出力を正常に生成するトランザクションを実現することは困難ですが、実際には非常に簡単な代替手段があり、それは、トランザクションがロジック エラーに遭遇して中断が発生した場合に出力結果を生成できるようにするというものですが、現時点ではFalse 値を返すと、トランザクションがスムーズに実行されなかったことを全員に知らせることができます。

ただし、False 値を返すと出力結果も返されることに注意してください。つまり、Cairo1 では、命令が論理エラーに遭遇したか、一時的な中断があったかどうかに関係なく、出力結果を生成してオンチェーンにすることができます。この出力は正しい場合もあれば、False エラー メッセージである場合もあります。

たとえば、次のようなコードセグメントがあるとします。

ここの _balances::read(from) - amount は、アンダーフローによるエラーを報告する可能性があります。このとき、対応するトランザクション命令は中断されて実行が停止され、トランザクション結果はチェーンに残されません。次の形式では、トランザクションが失敗しても出力結果が返され、チェーン上に残ります。純粋に視覚的な観点から見ると、すべてのトランザクションがトランザクション出力をチェーン上に正常に残すことができるかのように見えます。統一手数料がかかりリーズナブルです。

StarknetAA 契約の概要

この記事の読者の中にはプログラミングのバックグラウンドを持つ人もいることを考慮して、Starknet のアカウント抽象コントラクトのインターフェイスの簡単なデモンストレーションを以下に示します。

上記のインターフェイスの __validate_declare__ は、ユーザーによって開始された宣言トランザクションを検証するために使用されます。一方、 __validate__ は、主にユーザーの署名が正しいかどうかを検証するために、一般的なトランザクションを検証するために使用され、 __execute__ は、トランザクションを実行するために使用されます。 Starknet 契約アカウントがデフォルトでマルチコールをサポートしていることがわかります。複数の呼び出しにより、特定の DeFi インタラクションを実行するときに次の 3 つのトランザクションをパッケージ化するなど、いくつかの非常に興味深い機能を実現できます。

もちろん、複数の呼び出しはアトミックであるため、特定の裁定取引の実行など、より複雑な使用法もあります。

要約する

Starknet の主な技術機能には、ZK 証明の生成、ネイティブ レベルの AA、ビジネス ロジックや状態ストレージから独立したスマート コントラクト モデルを容易にする Cairo 言語が含まれます。

Cairo は、Starknet でスマート コントラクトを実装したり、より伝統的なアプリケーションを開発したりするために使用できるユニバーサル ZK 言語です。Sierra は、コンパイル プロセスの中間言語として導入され、Cairo が最下層を変更することなく頻繁に反復できるようにします。中間言語に変更を送信するだけで済みます。Cairo の標準ライブラリには、アカウントの抽象化に必要な多くの基本的なデータ構造も含まれています。

Starknet スマート コントラクトは、ビジネス ロジックとステータス データを別々に保存します。EVM チェーンとは異なり、Cairo コントラクト デプロイメントには、「コンパイル、宣言、デプロイメント」の 3 つの段階が含まれます。ビジネス ロジックは Contract クラスで宣言され、Contract インスタンスにはステータスが含まれますデータをクラスと組み合わせて関連付けを確立し、後者に含まれるコードを呼び出すことができます。

上述した Starknet のスマート コントラクト モデルは、コードの再利用、コントラクト状態の再利用、ストレージの階層化、ジャンク コントラクトの検出に役立ち、ストレージ リースやトランザクションの並列化の実現にも役立ちます。後者の 2 つはまだ実装されていませんが、カイロのスマート コントラクトの構造により、それらに「必要な条件」が作成されています。

上述した Starknet のスマート コントラクト モデルは、コードの再利用、コントラクト状態の再利用、ストレージの階層化、ジャンク コントラクトの検出に役立ち、ストレージ リースやトランザクションの並列化の実現にも役立ちます。後者の 2 つはまだ実装されていませんが、カイロのスマート コントラクトの構造により、それらに「必要な条件」が作成されています。

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