Cairo スタックは、Cairo コードを STARK フレンドリーな CPU アーキテクチャ、つまり Cairo VM (以下、CVM と呼びます) の命令にコンパイルすることにより、証明された汎用コンピューティングを容易にします。汎用 CPU の利点の多くは固有のコストを伴い、CVM は一部の一般的な操作に対して最適化されていません。 Keccak、Pedersen、Poseidon のハッシュ関数は、楕円曲線演算、範囲チェック (特定の数値が特定の値の範囲内にあるかどうかのチェック) などと同様、一般的な演算です。
CVM の相対的な非効率性に対処するために、Cairo スタックでは、重要な操作に対する組み込みの概念、つまり複雑さを証明するためにそのような操作を最適化するプラグインが導入されています。組み込み関数は ASIC と比較できます。ASIC はアプリケーション固有の集積回路であり、組み込み関数はアプリケーション固有の代数制約 (AIR) です。 AIR が何なのかを知らない場合、または覚えていない場合は、この記事の後半で簡単に説明しますので、詳細についてはこの記事をお読みください。
つまり、証明の複雑さはトレース ユニットと呼ばれるリソースに (ほぼ線形で) 関係しており、組み込み関数は Cairo VM よりもはるかに少ないトレース ユニットを使用することで特定の操作の証明を簡素化します。
AIR を記述する際の課題に加えて、残りの 2 つのフェーズには改善の余地がたくさんあります。この高度な記事では、アプリケーション固有の AIR の組み込み機能、上記の問題点、および将来の計画について詳しく説明します。
組み込み関数: アプリケーション固有の AIR
AIR は、Algebraic Intermediate Representation の頭字語です。この記事および他の StarkWare 記事では、AIR は仮想マシンを表す多項式システムです。たとえば、Cairo の名前は、特定の CPU アーキテクチャを表す多項式システムである CPU AIR から取られています。この多項式システムの解は、効率的な代数実行軌道 (AET) と呼ばれる効率的な状態遷移を表します。
STARK は、特定の AIR に対応する実行軌跡が有効であることを証明することで、仮想マシンの動作が正しいことを証明します。大まかに言えば、実行軌跡は数値の表であり、STARK プロトコルは、これらの数値が多項式系を解くことを証明します。
同じ操作をさまざまな方法で計算できますが、その中にはより効率的なものもあります。この論文では、証明の複雑さは基本的にトラック サイズ、つまりテーブル内のトラック セルの数に依存します。トレースは AIR 用に生成されるため、AIR はアプリケーションが特定の計算の実行トレースを大幅に削減できるように設計されています。組み込み関数は、アプリケーションに最適化された特化した AIR です。
以下の表は、特定の組み込み関数 (すべて実稼働環境) の効率の向上を示しています。
軌道レイアウト: 現在と未来
前述したように、AET は、コード化された仮想マシンのステップ (つまり、プログラムの実行) の順序を表す数字の表です。証明を計算するために、証明者は関連する AIR の実行トラックで STARK プロトコルを実行します。
上記では、計算のエンコードに必要なトレースユニットの数を減らすことで証明の複雑さを最小限に抑えるように設計された、アプリケーション固有の AIR としての組み込み関数を紹介しました。ただし、組み込み関数が Starknet にランダムに統合された場合、多くの軌道ユニットが無駄になる可能性があり、期待される利点は減少します。以下で詳しく説明しましょう。
Starknet 組み込み関数の利点と課題
オリジナル: ビルトインと動的レイアウト
翻訳・校正:「StarkNet Chinese Community」
### まとめ
組み込み関数により校正プロセスが最適化されます。ただし、各証明はレイアウトから計算されます。特定の校正作業では、レイアウトが非効率であると、組み込み関数の利点が大幅に減少します。現在、レイアウトの小さな静的なリストがあり、各プルーフはそのリストからの最も適切なレイアウトに基づいて計算されます。静的リストをレイアウトするこの方法には 2 つの欠点があります。まず、レイアウトの種類が限られています。これはほとんどの証明作業にとって非効率であり、ユーザーに不必要なコストを課す複雑な料金メカニズムが作成されます。次に、リストを手動で維持するのは困難です。組み込みの数が多くなりすぎると、手動メンテナンスが困難になり、実際に、多数のニュアンスをサポートする効率的な組み込みを証明するプロセスが妨げられる可能性があります。これらの問題に対処するために、StarkWare チームは、プルーフ オブ ワークごとにレイアウトがカスタムメイドされる動的レイアウト システムを開発しています。
Cairo スタックは、Cairo コードを STARK フレンドリーな CPU アーキテクチャ、つまり Cairo VM (以下、CVM と呼びます) の命令にコンパイルすることにより、証明された汎用コンピューティングを容易にします。汎用 CPU の利点の多くは固有のコストを伴い、CVM は一部の一般的な操作に対して最適化されていません。 Keccak、Pedersen、Poseidon のハッシュ関数は、楕円曲線演算、範囲チェック (特定の数値が特定の値の範囲内にあるかどうかのチェック) などと同様、一般的な演算です。
CVM の相対的な非効率性に対処するために、Cairo スタックでは、重要な操作に対する組み込みの概念、つまり複雑さを証明するためにそのような操作を最適化するプラグインが導入されています。組み込み関数は ASIC と比較できます。ASIC はアプリケーション固有の集積回路であり、組み込み関数はアプリケーション固有の代数制約 (AIR) です。 AIR が何なのかを知らない場合、または覚えていない場合は、この記事の後半で簡単に説明しますので、詳細についてはこの記事をお読みください。
つまり、証明の複雑さはトレース ユニットと呼ばれるリソースに (ほぼ線形で) 関係しており、組み込み関数は Cairo VM よりもはるかに少ないトレース ユニットを使用することで特定の操作の証明を簡素化します。
組み込み関数の利点を説明したので、多くの一般的な操作のために組み込み関数が開発された理由が明らかになりました。これは言うは易く行うは難しです。新しいビルトインを Starknet に導入する現在のプロセスは、次の手順で構成されます。
AIRを書く
新しいレイアウトを作成して証明者と統合します (後述)。
Starknet に統合します。つまり、新しい組み込み関数を使用するようにコード ベースと開発者ツールを変更します。
AIR を記述する際の課題に加えて、残りの 2 つのフェーズには改善の余地がたくさんあります。この高度な記事では、アプリケーション固有の AIR の組み込み機能、上記の問題点、および将来の計画について詳しく説明します。
組み込み関数: アプリケーション固有の AIR
AIR は、Algebraic Intermediate Representation の頭字語です。この記事および他の StarkWare 記事では、AIR は仮想マシンを表す多項式システムです。たとえば、Cairo の名前は、特定の CPU アーキテクチャを表す多項式システムである CPU AIR から取られています。この多項式システムの解は、効率的な代数実行軌道 (AET) と呼ばれる効率的な状態遷移を表します。
STARK は、特定の AIR に対応する実行軌跡が有効であることを証明することで、仮想マシンの動作が正しいことを証明します。大まかに言えば、実行軌跡は数値の表であり、STARK プロトコルは、これらの数値が多項式系を解くことを証明します。
同じ操作をさまざまな方法で計算できますが、その中にはより効率的なものもあります。この論文では、証明の複雑さは基本的にトラック サイズ、つまりテーブル内のトラック セルの数に依存します。トレースは AIR 用に生成されるため、AIR はアプリケーションが特定の計算の実行トレースを大幅に削減できるように設計されています。組み込み関数は、アプリケーションに最適化された特化した AIR です。
以下の表は、特定の組み込み関数 (すべて実稼働環境) の効率の向上を示しています。
軌道レイアウト: 現在と未来
前述したように、AET は、コード化された仮想マシンのステップ (つまり、プログラムの実行) の順序を表す数字の表です。証明を計算するために、証明者は関連する AIR の実行トラックで STARK プロトコルを実行します。
上記では、計算のエンコードに必要なトレースユニットの数を減らすことで証明の複雑さを最小限に抑えるように設計された、アプリケーション固有の AIR としての組み込み関数を紹介しました。ただし、組み込み関数が Starknet にランダムに統合された場合、多くの軌道ユニットが無駄になる可能性があり、期待される利点は減少します。以下で詳しく説明しましょう。
つまり、トラック レイアウトとは、トラック セルをさまざまな「コンポーネント」に割り当てることです。この記事では、これらのコンポーネントは CVM と組み込み関数です。具体的には、レイアウトは各コンポーネントが取得するトラック セルの相対数を指定します。 (レイアウト構造は検証を簡素化するために常に使用されます。詳細については、この投稿の「簡素化」セクションを参照してください)。
重要な点は、証明の複雑さはレイアウトによって割り当てられるトラック セルの総数に依存し、トラック セルの割り当ては実際に必要な量よりも大きくなる可能性があるということです。たとえば、CVM のステップ順序を示すために、トレース セルのみを CVM コンポーネントに割り当てるレイアウトは、トレース セルの半分を Poseidon 組み込み関数に割り当てるレイアウトよりもおよそ 2 倍効率的です。結論として、適切なレイアウトにより、特定の計算を証明する複雑さを大幅に軽減できます。
現在、手動で管理されているレイアウトのリストがあり、主に次の 2 つの理由により時間の経過とともに増加します。
内蔵機能は、割り当てられたトラックユニットのレイアウトに対してのみ使用できます。したがって、組み込みを追加するには、少なくとも新しいレイアウトが必要です。
Cairo コードを実行するように調整されたレイアウトにより、セル割り当てが最適化されます。したがって、セル内のユースケースを最適化するには、多くの場合、新しいレイアウトが必要になります。
証明者と検証者のコード (Solidity および Cairo 検証者) は、レイアウト リストに従って構成されます。
Keccak ビルトインと Poseidon ビルトインが追加されるにつれて、多くのビルトインを収容するのに十分な大きさのレイアウト リストを維持し、ほとんどの Starknet ブロックを効率的に実行し続けることがますます困難になってきました。さらに、レイアウトでは組み込み間の多くの可能な組み合わせと比率を考慮する必要があるため、追加の組み込みが導入されると効率が大幅に低下すると予想されます。
StarkWare チームは現在、既成のレイアウト リストを廃止し、Cairo コードを実行するたびに即座にカスタマイズできる「動的レイアウト」を採用してシステムの改善に取り組んでいます。動的レイアウトは、実行中の検証ジョブに対して常に最適な比率で割り当てを実行します。エンジニアリングの観点から見ると、動的型付けをサポートするには、コードベースに大幅な変更を加える必要があります。ただし、StarkWare チームは、動的なレイアウト、トラック ユニットの使用率の向上、証明者の利用効率の向上を利用して、Starknet の証明層を簡素化したいと考えています。
動的レイアウトを使用すると、多くの組み込みを手動で保守する手間がなくなり、より多くの新しい組み込みを Starknet に統合するプロセスが簡素化されます。
動的レイアウトと料金
トランザクション手数料の目的の 1 つは、トランザクションによって発生する限界プロトコル コストをユーザーに請求することです。トランザクション手数料の単位は通貨であるため、手数料メカニズムにはリソース (仮想マシンのステップ、組み込み関数、コールデータ、イーサリアム ガスなど) からトークン (STRK、ETH など) への変換が含まれます。
現在、証明者は使用率ではなく合計トレースに基づいて料金を請求するため、無駄なリソースはユーザーの負担となります。動的レイアウトによりトラックユニットの使用率が向上し、それによって「不必要な」トランザクション料金の請求が削減されます (ユーザートランザクションによって直接引き起こされないリソース消費を含む)。
Starknet 組み込み関数の統合
この時点では、組み込み関数の統合は、実用化を実現するために Starknet コード ベースを変更するという最後のステップに至っていません。コード変更の範囲はレイアウト アプリケーションに関連しており、可能な場合には Starknet オペレーティング システムが組み込み関数を呼び出すようにコードを変更する必要があります。たとえば、Starknet オペレーティング システムは、Cairo コードの実行中に Poseidon ハッシュ関数を呼び出し、同時に Poseidon 組み込み関数を呼び出します。
レイアウトと同様に、Starknet 組み込みも手動でサポートできるようになりました。ただし、レイアウトの場合とは異なり、多くの組み込み関数があるにもかかわらず、この手動サポートは統合の障害にはなりません。言い換えれば、Starknet ビルトインのサポートは統合の障壁ではなく、動的レイアウトが実際に追加のビルトインを作成して統合するための道を切り開くことになります。
要約
この記事では、組み込み機能とは何か、その利点、関連する課題、および StarkWare の計画について説明します。現在、動的レイアウトに焦点を当てています。これにより、証明プロセスの効率が向上するだけでなく、新しい組み込みの統合も容易になります。