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

概要#

Starknet の仕組み: Ethereum と比較して、Starknet はオフチェーンで計算を実行するためにシーケンサーのみを必要とします。その後、データ量を減らすために、証明者はトランザクションのための ZK-STARK 証明を生成します。最後に、検証者はオンチェーンで証明の正確性を検証し、複数の L2 トランザクションを Ethereum 上の単一のトランザクションにまとめます（これをロールアップと呼びます）。したがって、Starknet はチェーン上の実行およびストレージコストを削減し、結果としてガス料金を低下させ、TPS を向上させます。
EVM 互換性: Starknet は EVM とは異なる ZK フレンドリーな Cairo VM を持っており、これは Starknet が EVM および Solidity をサポートしていないことを意味します。しかし、Solidity コンパイラWarpと Cairo zkEVM Kakarotの導入により、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 は 5 つのコンポーネントで構成されています: Starknet 上の Prover、Sequencer、Full Node、そして Verifier と Starknet Core（これらはすべて 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（代数中間表現）、および高水準言語 Cairo を作成しました。これらはより ZK フレンドリーです。

EVM と互換性がないという欠点は、Ethereum の Solidity コードとツールチェーンを継承できないため、Ethereum アプリケーションエコシステムの大規模な移行の基盤がないことです。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 秒を実行し、1 秒あたり 12,288 回の呼び出しを生成します。一方、98,304 回のハッシュ呼び出しごとに 10 秒を要し、1 秒あたり 9,830 回の呼び出しを生成します。したがって、証明者が費やす時間はハッシュ呼び出しの数にほぼ線形にスケールすることがわかります。以下の図に示します：

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

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

例として: 1 百万ステップの 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 アーキテクチャ