スタークネットのスマート・コントラクト・モデルとネイティブAA：マーベリック・テックの巨人

By Shew &; Faust, geekweb3

Abstract

• Starknetの最も重要な技術的特徴には、ZK証明生成を容易にするカイロ言語、ネイティブレベルのAA、ビジネスロジックとステートストレージに依存しないインテリジェントな契約モデルである。

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

• Starknetのスマートコントラクトは、ビジネスロジックをステートデータとは別に保存します。EVMチェーンとは異なり、カイロコントラクトのデプロイは「コンパイル、宣言、デプロイ」フェーズで構成され、ビジネスロジックは「コンパイル、宣言、デプロイ」フェーズで宣言されます。ビジネスロジックはコントラクトクラスで宣言され、状態データを含むコントラクトインスタンスはクラスと関連付けられ、後者に含まれるコードを呼び出すことができます。ul class=" list-paddingleft-2" style="list-style-type: disc;">

• Starknet's smart contract model as described above is conduce reuse, contract state reuse, storage tiering, and detection of spammy contracts, and also storageリースとトランザクションの並列化も可能だ。後者2つはまだ整っていないが、Cairoのスマートコントラクトアーキテクチャはそのための「必要条件」を作り出している。

• Starknetはスマートコントラクトのアカウントのみをチェーン上に持ち、EOAアカウントは持たず、ネイティブレベルのAAアカウント抽象化を最初からサポートしている。そのAAスキームはERC-4337の考え方をある程度取り入れており、ユーザーは高度にカスタマイズされた取引処理スキームを選択することができます。潜在的な攻撃シナリオを防ぐため、スタークネットは数々の対策を講じ、AAエコシステムにとって重要な探求を行ってきた。

Starknet's トークンのリリース後、STRKはイーサリアムウォッチャーの目には欠かせない要素となっています。このLayer2 Etherのスターは、常に「ユーザーエクスペリエンスをほとんど考慮しない」「破天荒な」存在として知られてきましたが、まるで世捨て人のように、EVMの互換性が浸透しているLayer2のエコシステムにおいて、ひっそりと独自の土地を切り開いています。

あまりにもユーザーを無視し、さらには公然とDiscordの "電子乞食 "チャンネルで開いているため、Starknetは一度、スプレーで "心に近くない "と同時に、ジャークパーティーの攻撃によって、深遠な技術的な達成即座に。無価値 "になり、それは唯一のUXと富の創出効果がすべてであると思われる。金閣寺の「理解されないことが唯一の誇りになった」というセリフは、スタークネットの自己を映し出している。

しかし、このような些細なことはさておき、純粋にコードおたくの「技術的センス」からすれば、ZK Rollupの先駆者の一人であるStarknetとStarkExは、Cairo愛好家の目にはほとんど宝石のように映り、一部のフルチェーンゲーム開発者の目には、StarknetとCairoはまさにウェブの宝石に映る。一部のフルチェーンゲーム開発者の頭の中では、StarknetとCairoは単にweb3の最高峰であり、SolidityもMoveもかなわない。今日、オタクとユーザーの間にある最大のジェネレーションギャップは、Starknetに対する認識の欠如です。

ブロックチェーン技術に興味を持ち、探求する意欲を持ち、またStarknetの価値を発見したこの記事の著者は、StarknetのスマートコントラクトモデルとネイティブAAから出発し、Starknet技術の特徴を紹介しながら、その技術的ソリューションとメカニズム設計を簡単に説明します。スタークネットの技術の特徴をより多くの人に知ってもらうだけでなく、この「知られざる奇才」を多くの人に知ってもらいたいと考えています。

Cairoの概要

以下の記事では、Starknetのスマートコントラクトモデルとネイティブアカウントの抽象化に焦点を当て、StarknetがどのようにネイティブAAを実装しているかを説明します。この記事を読めば、Starknetで異なるウォレットの補助機能を混在させることができない理由も理解できるでしょう。

しかしネイティブアカウント抽象化を紹介する前に、StarknetのオリジナルのCairo言語について学びましょう。Cairoが開発される過程で、Cairo0と呼ばれる初期バージョンがあり、その後、Rustに似た全体的な構文を持つ最新バージョンが登場しました。

たとえば、Cairo言語でZK認証システムを開発し、StarkNetネットワークに依存することなく、自分で構築したサーバーで実行することができます。間違いなく、検証可能な計算特性を必要とするプログラムはすべて、Cairo言語で実装できます。そしてCairoはおそらく、ZK証明を生成するために利用可能なプログラミング言語の中で、最も使いやすいものでしょう。

コンパイルプロセスに関して、Cairoは次の図に示すような中間言語ベースのコンパイル方法を採用しています。図中のSierraはCairo言語のコンパイルプロセスにおける中間形式(IR)であり、Sierraはその後、CASMと呼ばれるより基礎的な形式のバイナリコードにコンパイルされ、Starknetノードデバイス上で直接実行されます。

Sierra を中間形式として導入することで、Cairo 言語に新しい機能を追加するのが簡単になります。多くの場合、基礎となる CASM コードを直接変更しなくても、中間形式として Sierra をいじるだけで済みます。これは多くの手間を省き、Starknetノードクライアントを頻繁に更新する必要もありません。これにより、基礎となるStarkNetのロジックを変更することなく、Cairo言語を頻繁に繰り返すことができます。また、アカウントの抽象化に必要な基本的なデータ構造の多くは、Cairo の標準ライブラリに組み込まれています。

Cairoのその他のイノベーションには、Cairo Nativeと呼ばれる理論的なソリューションがあり、Cairoをさまざまなハードウェアデバイスに適応可能な基礎となるマシンコードにコンパイルする予定だ。コードの実行速度を劇的に向上させることができる。

Starknet smart contract model: code logic and state storage divestment

EVM 互換チェーンとは異なります。Starknetのスマートコントラクトシステムの設計には画期的なイノベーションがあり、それは主にネイティブAAと将来オンラインになる並列取引機能に備えるためのものです。ここで、Etherのような従来のパブリックチェーンでは、スマートコントラクトは、ETHスマートコントラクトを例にすると、「コンパイル＆デプロイ」方式でデプロイされることが多いということを知っておく必要があります：

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

2.開発者はスマートコントラクトをデプロイするトランザクションリクエストを開始し、コンパイルしたEVMバイトコードをEtherChannelにデプロイする。

(Image source: not-satoshi.com）

Starknetのスマートコントラクトも「コンパイルが先、デプロイは後」という考え方に従っているが、スマートコントラクトはCairoVMがサポートするCASMバイトコードの形でチェーン上にデプロイされる。しかし、スマートコントラクトの呼び出しと状態の保存モードという点では、StarknetとEVM互換チェーンには大きな違いがある。

正確に言うと、Ether スマートコントラクト = ビジネスロジック + 状態情報

salt>はコントラクトのアドレスを計算するためのソルトで、単なる乱数です。class_hash>は、先ほど説明したように、コントラクトインスタンスのクラスのハッシュ値です。そしてconstructor_calldata_hashは、コントラクトの初期化パラメータのハッシュを表します。

上記の式に基づいて、ユーザーは、コントラクトがチェーンにデプロイされる前に、生成されたコントラクトのアドレスを事前に計算することができます。

Starknetでは、ユーザーが事前にStarknetアカウントなしで直接コントラクトをデプロイすることができ、そのプロセスは次のとおりです。

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

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

3.ユーザーはコントラクト展開のためのトランザクションリクエストを開始します。

実際には、すべてのスタークネットアカウントは上記のプロセスを通じてデプロイされますが、ほとんどのウォレットはこの詳細をブロックアウトしており、ユーザーはこのプロセスをまったく認識していません。

上記のシナリオでは互換性に問題があります。異なるウォレットはアカウントアドレスを生成する際に一貫性のない結果を生成するため、以下の条件を満たすウォレットのみ混在させることができます。

1. Wallets use the same private key derived public key and signature algorithm;

2. Wallets have the same salt computation process;

3. Wallets have the same smartコントラクトクラスは、実装の詳細において根本的に異なるものではありません。

前にお話ししたケースでは、ArgentとBraavosの両方がECDSA署名アルゴリズムを使用していますが、両者のソルト計算方法は異なっており、同じヘルパーワードが2つのウォレットで一貫性のないアカウントアドレスを生成します。

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

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

また、イーサネットの設計では、認証（デジタル署名）などのロジックはノードのクライアントコードに死ぬほど書き込まれます。

(Starknet)トランザクションの検証とガス料金の適格性確認はオンチェーン契約によって処理されるようにシフトされ、チェーンの基礎となるVMは、ユーザー定義または指定されたこれらの機能を呼び出すことができます）

zkSyncEraとStarknetの公式担当者によると、アカウント機能のこのモジュール化は、以下の考えに基づいています。しかし、その違いは、zkSyncとStarknetが最初からアカウントタイプを統合し、トランザクションタイプを統一し、すべてのトランザクションを受信して処理するために統一ポータルを使用したのに対し、Etherは、歴史的なお荷物であり、ハードフォークなどの総当たり的な反復的ソリューションを可能な限り避けたいという財団の願望から、次のようなものをサポートしました。EIP-4337ソリューションは「カーブボール」ソリューションです。しかし、この効果は、EOAアカウントと4337ソリューションがそれぞれ独自の個別のトランザクションプロセスを持っていることです。

(Image source：ArgentWallet）

しかし、Starknetのネイティブアカウントの抽象化はまだ完全な成熟には至っておらず、、実際の進捗としては、StarknetのAAアカウントは署名検証アルゴリズムのカスタマイズを実装しているが、手数料支払いのカスタマイズについては、現時点ではStarknetはガス料金の支払いにETHとSTRKしかサポートしておらず、第三者が顧客に代わってガスを支払うことはサポートしていないため、StarknetのネイティブAAに関する進捗は「理論的なソリューションは基本的に成熟しており、実際のソリューションはまだ進んでいる」と言える。

Starknet内にはスマートコントラクトのアカウントしか存在しないため、そのトランザクションの完全な流れはアカウントのスマートコントラクトの影響を考慮に入れている。まず、トランザクションがスタークネットのノードのメモリプール（Mempool）で受信され、検証されます。

ここで、口座のスマートコントラクトでカスタマイズされた署名検証関数を使用することは、攻撃シナリオの存在を意味することに注意してください。なぜならば、メモリプールは新しい着信トランザクションの署名を検証する際にガス料金を請求しないからです（ガス料金が直接請求された場合、より深刻な攻撃シナリオにつながるでしょう）。悪意のあるユーザーは、まず自分のアカウント契約で超複雑な署名検証関数をカスタマイズし、次に大量のトランザクションを開始し、これらのトランザクションが検証されるときに、すべてのトランザクションがカスタマイズされた複雑な署名検証関数を呼び出すようにすることができます。

これを避けるため、StarkNetはトランザクションに以下の制限を課しています：

1. 1 人のユーザーが単位時間当たりに開始できるトランザクション数には上限があります。

2. スタークネットのアカウント契約でカスタマイズされる署名確認機能には複雑さの上限があり、複雑すぎる署名確認機能は実行されません。スタークネットは署名確認機能で消費されるガス量の上限を制限しているため、署名確認機能で消費されるガス量が多すぎる場合、トランザクションは完全に拒否されます。また、口座契約内の署名確認機能が他の契約を呼び出すこともできません。

スタークネットの取引のフローチャートは以下の通りです：

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

トランザクションデータがシーケンサーによって検証された後（これはメモリプールの検証よりもはるかに深い検証ステップです）、シーケンサーは処理のためにメモリプールからトランザクションをパッケージ化し、ZK証明ジェネレーターに渡します。

しかし、読者がStarknetの歴史を知っていれば、初期のStarknetは失敗したトランザクションの実行に手数料を請求していなかったこと、トランザクションが失敗する最も一般的なケースは、ユーザーが1ETHの資金しか持っていないが、10ETHを外部に送金した場合であることがわかるだろう。この種のトランザクションには明らかにロジックエラーがあり、最終的には失敗しなければなりませんが、具体的に実行されるまで結果がどうなるかは誰にもわかりません。

しかし、StarkNetは過去にこのような失敗したトランザクションに対して手数料を請求したことはありません。このようなコストのかからないエラートランザクションは、スタークネットノードの計算リソースを浪費し、DDOS攻撃シナリオを生み出す可能性があります。表面的には、エラートランザクションに手数料を課すことはうまく実装されているように見えるが、実際にはかなり複雑である。StarknetはCairo1言語の新バージョンを導入したが、これは失敗したトランザクションにガスをチャージするという問題に対処するためだった。

ZKプルーフが有効性の証明であり、失敗したトランザクションを実行すると、チェーン上に残すことのできない無効な出力が生じることは誰もが知っている。特定の命令の実行が無効であり、出力結果を生成できないことを証明するために有効性の証明を使用しようとすると、かなり奇妙に聞こえ、現実的には実現不可能です。過去にStarknetが証明を生成する際に、出力結果を生成できなかった失敗トランザクションを単純に削ってきたのはそのためです。

その後、Starknetチームはよりスマートな解決策を採用し、新しい契約言語であるCairo1を構築することで、「すべてのトランザクション命令が出力とオンチェーンを生成する」ことを可能にしました。一見したところ、すべてのトランザクションが出力を生成するという事実は、論理エラーが発生しないことを意味し、ほとんどの場合、トランザクションは命令の実行を中断するバグに遭遇するため失敗する。

トランザクションが決して割り込まず、正常に出力を生成するようにすることは難しいですが、実際には、トランザクションが割り込みの原因となる論理エラーに遭遇したときでさえ、出力を生成するようにする非常に単純な代替手段があります。Cairo1 は、命令がロジックエラーに遭遇したか、一時的に中断されたかに関係なく、出力とオンチェインを行うことができます。

例として、以下のスニペットが存在するとしましょう:

Here _balances::read(from) - amount may be overflowing downwards.amount may report an error due to a downward overflow, which will cause the corresponding transaction instruction to be interrupted and stop executing, leaving transaction result on the chain; 一方、以下のように書き換えると、トランザクションが失敗した場合でもチェーン上に残る出力を返します。純粋に知覚の観点からは、すべてのトランザクションが何の問題もなくチェーン上にトランザクション出力を残しているように見えますが、そして定額料金を請求するのは良い考えです。定額手数料は特に合理的に思えるだろう。

StarknetAA 契約の概要

この記事の読者の中にはプログラミングのバックグラウンドを持っている人がいるかもしれないことを考慮して、これは簡単な概要です。

上記インターフェースのうち、__validate_declare__は、ユーザーの認証に使用されます。はユーザー主導のdeclareトランザクションの検証に使用され、__validate__は一般的なトランザクションの検証、主にユーザーの署名が正しいかどうかの検証に使用され、__execute__はトランザクションの実行に使用されます。Starknetの契約アカウントは、デフォルトでマルチコール、つまり複数のコールをサポートしていることがわかる。マルチコールは、特定のDeFiインタラクションを実行する際に以下の3つのトランザクションをパッケージ化するなど、非常に興味深い機能を可能にします:

1. 1 つ目のトランザクションは、トークンをDeFiコントラクトに認可します

2. 。li>

3. 2つ目のトランザクションは、DeFiコントラクトロジックをトリガーします

4. 3つ目のトランザクションは、DeFiコントラクトへの認可をクリアします

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

まとめ

• スタークネットの最も重要な技術的特徴は、カイロ言語でのZK証明生成を容易にすること、ネイティブレベルのAA、そしてCairo言語でのZK証明生成、ネイティブレベルのAA、ビジネスロジックをステートストレージから分離したスマートコントラクトモデルなどです。

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

• Starknetのスマートコントラクトは、ビジネスロジックと状態データを別々に保存します。 EVMチェーンとは異なり、Cairoのコントラクトのデプロイはコンパイル、宣言、デプロイの3つのフェーズで構成され、ビジネスロジックはコントラクトクラスで宣言され、状態データを含むコントラクトインスタンスは状態データにリンクできます。

• 上記のStarknetのスマートコントラクトモデルは、コードの再利用、コントラクトの状態の再利用、ストレージの階層化、スパムコントラクトの検出を容易にし、ストレージのリースとトランザクションの並列化の実現も容易にします。後者2つはまだ利用できないが、Cairoのスマートコントラクトアーキテクチャはそのための「必要条件」を作り出している。

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