Starknetとは：異なるzkVMテクノロジースタック

概要#

Starknet の仕組み: Ethereum と比較して、Starknet はオフチェーンで計算を実行するためにシーケンサーのみを必要とします。その後、データ量を削減するために、プローバーはトランザクションのための ZK-STARK 証明を生成します。最後に、検証者はオンチェーンで証明の正当性を検証し、複数の L2 トランザクションを Ethereum 上の単一のトランザクション（ロールアップとして知られる）にまとめます。したがって、Starknet はチェーン上の実行およびストレージコストを削減し、ガス料金を低下させ、TPS を向上させます。
EVM 互換性: Starknet は ZK フレンドリーな Cairo VM を持ち、EVM とは異なります。これは、Starknet が EVM および Solidity をサポートしていないことを意味します。しかし、Solidity コンパイラWarpと Cairo zkEVMKakarotの導入により、Starknet はタイプ 3 のEVM 互換性を達成できます。
STARK 証明システム: 他の ZK 証明システムと比較して、STARKはより安全でスケーラブルです。証明生成速度は線形スケーラブルであり、検証時間と証明サイズは対数的にスケーラブルです（$O (polylog (N))$）。証明が大きくなるほど、総コストと検証時間は低下します。さらに、STARK は純粋にハッシュと情報理論に依存しているため、より単純な暗号学的仮定を持ち、量子攻撃に対して耐性があります。しかし、初期の証明生成のサイズが大きいという欠点があります。
Cairo VM とプログラミング言語: Cairo VM は STARK フレンドリーで、チューリング完全なフォン・ノイマン CPU アーキテクチャです。ソフトウェアプログラミングを通じて ASIC に無限に近い性能を発揮できます。また、Cairo というプログラミング言語を持ち、Cairo アセンブリ AIR とSierraに基づいています。これにより、高効率で安全にコンパイルできます。Rust に似ており、一定の学習難易度があります。Cairo はバイトコードハッシュを通じてプログラムを検証者が検証することをサポートし、オンチェーンのスケーラビリティとプライバシーを向上させます。しかし、Cairo はまだ更新中です。

別の記事では、プローバー、シーケンサー、フルノード、クライアント、Cairo、プロトコルなどの Starknet ネットワークコンポーネントの分散化の進捗を示します。

🛒 Starknet の仕組み#

まず、Ethereum の仕組みを見てみましょう。Ethereum では、トランザクションの正当性を検証するために、すべてのノードが各トランザクションをチェック、検証、実行する必要があります。このプロセスは計算の正確性を保証し、結果として得られる状態変化をネットワーク全体にブロードキャストします。

しかし、Starknet はオフチェーンで計算を実行し、証明を生成し、その後、オンチェーンで証明の正当性を検証し、最終的に複数の L2 トランザクションを Ethereum 上の単一のトランザクションにまとめます。正確には ZKR がトランザクションを Ethereum にcalldataとして書き込み、スマートコントラクト関数への外部呼び出しに含まれるデータが保存されます（メモリに似ています）。

したがって、Starknet はネットワークの運用速度を大幅に向上させ、オンチェーン通信を削減し、ネットワークスループットを増加させることができるため、Ethereum と比較して TPS が高く、ガスが低くなります。

要するに、計算の正当性を検証することは、教師がクラスが特定のトピックを習得したかどうかを確認することに例えることができます。

Ethereum の方法は、各生徒（ノード）が教科書全体（状態履歴）を暗記しているかどうかを確認することですが、Starknet の方法はペーパー試験を実施することです。後者はより効率的でコストが低いですが、安全性が保証されています。

it's not more boring than text exam

Validity Rollup、Scroll、Polygon zkEVM、zkSync などのほとんどの ZKR と同様に、Starknet には証明を生成するためのプローバーと呼ばれる役割のクラスがあります。そして、検証者は L1（Ethereum）上の契約として証明を検証します。

具体的には、Starknet はプローバー、シーケンサー、Starknet 上のフルノード、検証者、Starknet Core の 5 つのコンポーネントで構成されています（すべて Ethereum にデプロイされています）。

以下の図は、Starknet のアーキテクチャを示しており、Davidの素晴らしい仕事に感謝します！

Starknet のワークフローは次のとおりです。

Starknet でトランザクションを開始すると、オフチェーンサーバーであるシーケンサーがそれを受信し、シーケンスし、検証し、ブロックにまとめます。トランザクションを実行し、状態遷移を Starknet Core コントラクトに送信します。
プローバーは各トランザクションのための証明を生成し、それを Ethereum にデプロイされた検証者コントラクトに送信します。
検証者は検証の結果を Ethereum 上の StarkNet Core コントラクトに送信し、記録保持のためにオンチェーンのグローバル状態を更新するために StarkNet Core コントラクトから新しい Ethereum トランザクションのセットをトリガーします。状態遷移は「calldata」（EIP-4844 後の Blob）として送信され、L1 トランザクションのガスを節約します。これらの「メタデータ」は Starknet フルノードによって復号化できます。

A full nodeは、状態変化、メタデータ、証明を保存し、ロールアップで実行されたすべてのトランザクションを記録します。システムの現在のグローバル状態を追跡します。「メタデータ」を復号化することで、必要に応じて Starknet の履歴を再構築できます。

🚄EVM 互換性#

Starknet ネットワーク自体は EVM 互換ではなく、ZK フレンドリーな Cairo VM を設計しています。

Ethernet オペコードのために回路を作成するのではなく、Starknet は独自のアセンブリ言語、AIR（代数的中間表現）、およびより ZK フレンドリーな高水準言語 Cairo を作成しました。

EVM と互換性がないという欠点は、Ethereum の Solidity コードやツールチェーンを継承できないため、Ethereum アプリケーションエコシステムを Starknet に大規模に移行する基盤がないことです。Cairo 言語は開発者にとって一定の学習の閾値があり、Cairo ツールチェーンとライブラリはまだ初期段階にあります。

しかし、独立した VM を設計することには利点があります。たとえば、Starknet の Cairo VM はより ZK フレンドリーであり、回路をより効率的に実行し、将来的により高い TPS と低いガス使用を実現します（詳細は後述）。さらに、EVM 設計を放棄することで、Ethereum では不可能なアプリケーションの革新の多くの可能性が開かれます。

Starknet は、Vitalik によって定義されたタイプ 4 レベルのEVM 互換性に属します（厳密には、Starknet は zkVM です）。

Starknet「自体」は EVM 互換ではありませんが、他の方法で Ethereum と互換性があります。

Warpは、Nethermind によって開発された Solidity-Cairo トランスレーターで、現在完成しています。Warp を使用すると、Ethereum スマートコントラクトを Starknet Cairo コントラクトにトランスパイルすることが可能です。

ただし、Solidity のいくつかの機能はまだサポートされていないか、Starknet に類似のものがありません。これらの機能の一部は将来的に導入される可能性がありますが、他のものはプラットフォーム間の根本的な違いにより不可能かもしれません。

Kakarotは Cairo で書かれた zkEVM（したがって契約です）で、バイトコード互換の EVM であり、開発者が任意の EVM バイトコードプログラムを実行できるようにします。Ethereum アプリケーションは Kakarot にデプロイすることで Starknet にデプロイできます。

Kakarot は進行中の作業であり、まだ生産準備が整っていません。

Starknet の ZK フレンドリーな Cairo VM は EVM および Solidity をサポートしていません。しかし、Solidity コンパイラ Warp と Cairo zkEVM Kakarot の導入により、Starknet はタイプ 3 の EVM 互換性を達成することが可能になります。

🧬 STARK 証明システム#

現在、Halo、PLONK、Groth16、Groth09、Marlin、Plonky2 など、証明を生成および検証するためのさまざまな証明システムが利用可能であり、これらはすべて SNARK 証明システムに属します。すべての証明システムには、証明を生成するプローバーと証明を検証する検証者がいます。異なる ZK プロジェクトはほぼ異なる証明システムを使用しています。主要な証明システムは SNARK と STARK であり、Starknet は STARK を使用しています。

SNARK は Succinct Non-interactive Argument of Knowledge の略で、STARK は Scalable Transparent Argument of Knowledge の略です。STARK は SNARK の特別で革新的なタイプであり、「S」は Succinct から Scalable に変わり、「T」は透明性を意味し、非対話型の特徴を置き換えます。

STARK は SNARK よりも多くの革新があります。SNARK のように「信頼された設定」に依存する必要がなく、より単純な暗号学的仮定を持ち、楕円曲線、ペアリング、指数的知識仮定の必要を回避し、純粋にハッシュと情報理論に依存しているため、量子攻撃に対して耐性があります。一般的に、STARK は SNARK よりも安全です。

STARK はよりスケーラブルです。証明生成速度は線形スケーラブルであり、検証時間と証明サイズは対数的にスケーラブルです。ただし、欠点は生成された証明のサイズが大きいことです。証明のサイズが大きくなると、検証コストはわずかに減少し、証明が大きくなるほど平均コストが低下します。

証明時間は線形にスケールします#

STARKs のドキュメントを見てみましょう。プローバーが費やす時間は、ハッシュ呼び出しの数にほぼ線形にスケールします。

80 ビットのセキュリティで、STARK は 12,288 回のハッシュ呼び出しごとに 1 秒を実行し、毎秒 12,288 回の呼び出しを生成します。一方、98,304 回のハッシュ呼び出しごとに 10 秒かかり、毎秒 9,830 回の呼び出しを生成します。したがって、プローバーが費やす時間はハッシュ呼び出しの数にほぼ線形にスケールすることがわかります。以下の図に示します。

検証者の時間と証明サイズは対数的にスケールします#

左側に示すように、ハッシュ呼び出しが 3,072 から 49,152 に増加すると、検証時間は 40ms から 60ms に増加します。そして、ハッシュ呼び出しが 49,152 から 786,432 に増加すると、検証時間は 60ms から 80ms にしか増加しません。証明サイズは同じです。したがって、ハッシュ呼び出しが多いほど、平均検証時間が短くなり、平均証明サイズが小さくなると結論できます。

例として：100 万ステップの 2 つのプログラムの証明の検証

● 各々を別々に検証した場合の総検証コスト：$2 log2 (T) \approx 794$

● 両方を一緒に検証した場合の総検証コスト：$log2 (2T) \approx 438$

コスト削減の要因は 1.8（またはほぼ 2）です。

すべての実験は、次の仕様の同じマシンで実行されました。

オペレーティングシステム：Linux 5.3.0-51-generic x86 64。
CPU：Intel (R) Core (TM) i7-7700K @ 4.20GHz（4 コア、各コア 2 スレッド）。
RAM：16GB DDR4（8GB × 2、速度：2667 MHz）
プローバーはマルチスレッドを使用しますが、すべての実験で検証者は単一スレッドのみを利用するよう制限されました。

再帰的証明#

STARKs のような普遍的で簡潔な証明 / 知識の主張システムは、計算を段階的に検証するために使用できます。これは、計算が以前のインスタンスの正当性を証明する証明を生成できることを意味します。この概念は非公式に「再帰的証明構成」または「再帰的 STARKs」と呼ばれます。

言い換えれば、再帰的 STARK プローバーは、システムの状態を a からa+1に移動できるという主張のための証明を生成します。なぜなら、プローバーがaの計算の整合性を証明する（再帰的）証明を検証し、状態aで計算を忠実に実行して新しい状態a+1に到達したからです。

要するに、再帰的証明は 2 つの証明、 aとa+1を単一の証明に結合することを理解できます。以下の図に示します。

この例では、4 つのステートメントが SHARP（検証者）に送信され、各ステートメントが並行して証明されます。次に、各ペアの証明が再帰的検証者ステートメントによって検証されます。これは STARK 証明を検証する Cairo プログラムであり、各検証のために証明が生成されます。この再帰的検証者ステートメントは、2 つの証明が正しいと検証されたことを確認します。次に、2 つの証明は別の再帰的検証者ステートメントによって再度統合されます。これにより、4 つの元のステートメントすべてを証明する 1 つの証明が生成されます。最後に、この証明はオンチェーンに提出され、Solidity 検証者スマートコントラクトによって検証されます。

StarkWare の共同創設者であるEli Ben-Sassonによれば、新しい再帰的有効性証明は、Ethereum ブロックチェーン上で 60 百万のトランザクションを単一のトランザクションにロールアップする可能性を秘めています。

⭐Cairo VM と Cairo 言語#

Cairo VM は STARK フレンドリーで、チューリング完全なフォン・ノイマン CPU アーキテクチャです。Cairo アセンブリと AIR（代数的中間表現）に基づくプログラミング言語 Cairo を含み、高効率でコンパイルできます。

まず、Cairo VM を見てみましょう。Cairo VM は並列状態機械であり、トランザクションを同時に実行することができ、TPS を大幅に向上させます。対照的に、EVM は直列状態機械です。

Cairo は Starknet 上またはオフでデプロイ可能なスマートコントラクト言語です。任意の Cairo プログラムは STARK 証明を生成できます。その構文は Rust に似ています。

これは Cairo のvoting systemの例です：

import json

from starkware.crypto.signature.signature import (
    pedersen_hash, private_to_stark_key, sign)

# 投票対象を表す識別子を設定します。
# これは、異なる投票を区別するためにユーザーの署名に表示されます。
POLL_ID = 10018

# キーペアを生成します。
priv_keys = []
pub_keys = []

for i in range(10):
    priv_key = 123456 * i + 654321  # 下記の「安全性ノート」を参照。
    priv_keys.append(priv_key)

    pub_key = private_to_stark_key(priv_key)
    pub_keys.append(pub_key)

# 投票者3、5、8の3つの投票を生成します。
votes = []
for (voter_id, vote) in [(3, 0), (5, 1), (8, 0)]:
    r, s = sign(
        msg_hash=pedersen_hash(POLL_ID, vote),
        priv_key=priv_keys[voter_id])
    votes.append({
        'voter_id': voter_id,
        'vote': vote,
        'r': hex(r),
        's': hex(s),
    })

# データ（公開鍵と投票）をJSONファイルに書き込みます。
input_data = {
    'public_keys': list(map(hex, pub_keys)),
    'votes': votes,
}

with open('voting_input.json', 'w') as f:
    json.dump(input_data, f, indent=4)
    f.write('\n')

Cairo プログラムはアセンブリコードのコレクションであり、Cairo 開発者は Cairo アセンブリではなく高水準言語 Cairo でスマートコントラクトを書くことになります。Cairo プログラムを書くと、Cairo コンパイラが Cairo コードを Cairo アセンブリにコンパイルし、Cairo アセンブラがアセンブリコードを取り、Cairo バイトコード（Cairo CPU 上で実行される）を生成して Cairo VM で実行されます。

以下は Cairo のいくつかの特徴です。

ブートローディング：ハッシュからプログラムを読み込む#

プログラムは、別のプログラムのバイトコードをメモリに書き込み、その後プログラムカウンタをそのメモリセグメントを指すように設定することで、他のプログラムの実行を開始できます。

このアイデアの特定の使用法は「ハッシュからのブートローディング」です。プログラムは「ブートローダー」と呼ばれ、別のプログラムのバイトコードのハッシュを計算して出力し、その後上記のように実行を開始します。この方法では、検証者は実行されるプログラムのハッシュのみを知っていればよく、その完全なバイトコードを知る必要はありません。

これにより、プライバシーとスケーラビリティの両方が向上します：

プライバシー: 検証者はプログラムの実行を検証できますが、計算が何を行うかを知る必要はありません。
スケーラビリティ: プログラムハッシュが検証者に知られていると仮定すると、検証時間はプログラムサイズに線形に依存せず、プログラムが検証者に入力される場合のように、検証時間とプログラムサイズは対数的な関係を持ちます。

CPU アーキテクチャ

Cairo VM は柔軟です。ソフトウェアプログラミングを通じて ASIC の性能に無限に近づくことができます。

ビルトイン#

開発者は、計算開発に必要な計算量を減らすために、コードを変換することなく内部設定機能を直接デバッグおよび使用できます。

ASIC チップによって表される回路や開発者の数学で説明される実験は、Cairo の回路に相当します。しかし、Cairo はまだ更新中で、最新バージョンはCairo 1.0.です。

Cairo 1.0 の主な追加は Sierra（Safe Intermediate Representation）です。これは、Cairo 1.0 と Cairo バイトコードの間の新しい中間表現層として機能します。Sierra の目標は、すべての Cairo 実行 — すなわち Cairo プログラムとその入力 — が証明できることを保証することです。