StarkWare

導入

導入

StarkEx と StarkNet はどちらも StarkWare チームによって開発されたプロジェクトです。前者は Iaas に似ており、アプリケーション チェーンに似ています。Starkware は大規模プロジェクトの独自アプリケーション Rollup の開発を支援します。後者は汎用アプリケーションを展開できる Rollup です。

StarkEx: 独自の ZKR エンジン

導入

導入

昨年と今年上半期、Starkware はスケーリング テクノロジー ソリューション StarkEx を提供することにより、サービスとしてのスケーリング (サービスとしての拡張) ビジネス モデルを構築し、アプリケーション固有のネットワークを確立し、業界の主要顧客 dYdX にサービスを提供しました、ソラレ、ImmutableX、DeversiFiなど。

全体構造

• ワークフローには次の 4 つのリンクが含まれています

• パッケージ化されたトランザクション: オフチェーン サーバーはクライアントのリクエストを処理し、StarkEx が処理できるように複数のトランザクションを「バッチ」に結合します。

• トランザクションの確認とステータスの更新: オフチェーン サーバーは、トランザクションが正当であることを確認し、圧縮されたハッシュ形式でシステム ステータスを更新します。

• 取引の証明を生成する: 上記のプロセスが完了すると、SHARP は取引の正当性を確認するために、取引の STARK 証明を生成します。その後、プルーフと更新がオンチェーン Verifier スマート コントラクトに送信され、トランザクションの整合性が保証されます。

オンチェーン検証済みプルーフ: STARK プルーフが検証されると、状態の更新がコミットされ、イーサリアム メインネットに戻されます。すべてのトランザクションはオフチェーンで処理および検証され、その整合性の証明はオンチェーンで検証されます。

SHARP は、複数の StarkEx クライアント/アプリケーションに証明生成サービスを同時に提供し、計算上の整合性主張の証明を生成する共有証明者です。

StarkWare Applications

Verifier は、StarkEx からのトランザクションの正確性を検証するためにイーサリアム上にデプロイされたスマート コントラクトです。

StarkEx アプリケーション (写真の Exchange) は、スポット取引とレバレッジ取引を区別する、スケーラブルな自己保管取引をサポートする一連のアプリケーションです。アプリケーションは、スマート コントラクトとバックエンドの 2 つのコンポーネントで構成されます。

• 標準手順

• ユーザーがトランザクションを開始すると、トランザクションはスマート コントラクトと直接対話できます。

• 各トランザクションには一意の ID があり、それらがまとめてトランザクション フローを形成し、StarkEx アプリケーションがトランザクション フローをバックエンドに送信します。

• バックエンドは状態遷移を SHARP に送信し、SHARP は状態遷移の証明を生成します

• SHARP は証明を検証者コントラクトに送信し、検証者が検証を完了すると、検証者はそれを Verifier Fact Registry に記録し、バックエンドが StarkEx スマート コントラクトの状態遷移を実行します。

StarkEx スマート コントラクトは、状態遷移が事前定義されたルールに準拠しているかどうかをチェックして、(バリデータ コントラクトを通じて) 状態遷移の有効性を確認します。

参考リンク: はじめに :: StarkEx ドキュメント

概要

• 以下の図に示すように、StarkEx システムはパートナー バックエンドからのユーザー トランザクションを受け入れるように設計されています。これらのトランザクションはバッチ処理され、StarkEx システムによって処理されます。上記のスマート コントラクトとバックエンドの導入と組み合わせると、StarkEx トランザクション処理プロセス全体と責任分担は次のように要約されます。

• フロントエンドでは、StarkEx クライアントはオンチェーンとオフチェーンの 2 種類の操作をサポートします。前者は標準的なイーサリアムトランザクションであり、ユーザーはStarkExコントラクトを通じて直接入出金を行いますが、後者はdydxなどのStarkExエンジンを通じて実行される操作です。

• 注文の検証。StarkEx クライアントのバックエンドによって設定および検証されます。

• ビジネス ロジック、StarkEx 契約 (下位契約) をカスタマイズして顧客のビジネス ロジックをサポートする

• トランザクション フロー。StarkEx に送信されるすべてのトランザクションは検証され、ノンスと同様の tx_id と呼ばれる連続識別子を使用してインデックス付けされます。

• トランザクション送信者は、StarkEx ゲートウェイがトランザクションが正しいことを確認すると、それを (実際にはすぐにではなく) 実行することを保証し、チェーン上のファイナライズを待つのではなく、フロントエンドで事前にユーザーに表示します。

• エラー処理: 無効なトランザクションが検出された場合、StarkEx システムは顧客のプロフェッショナル エンドポイントにエラーを報告し、顧客は無効なトランザクションを、空のリストなど、実行されるトランザクションの別のリストに置き換えます。

• バッチ レビュー。チェーン上で送信される前に、クライアントによってバッチをレビューできます。遷移が予期された状態と矛盾する場合、クライアントは承認またはロールバックできません。

検閲防止のため、顧客がユーザーのリクエストを確認した場合、StarkEx はユーザーが StarkEx 契約を通じて直接操作を実行できるようにし、顧客は指定された時間内にそれをユーザーに提供する必要があります。そうしないと、StarkEx 契約は凍結されます。

StarkNet: ユニバーサル ZKR

導入

導入

さまざまなアプリケーション向けに ZK ロールアップをカスタマイズする StarkEx とは異なり、StarkNet は汎用 ZK ロールアップであり、開発者は StarkNet 上にアプリケーションを展開できます。

基本的な紹介

https://ethereum.org/zh/developers/docs/evm/ 

イーサリアムでは、トランザクションが送信されるたびに、すべてのノードがトランザクションをチェック、検証、実行して計算が正しいことを確認し、計算された状態の変化をネットワークにブロードキャストする必要があります。

StarkNet は、チェーン外で計算を実行して ZK プルーフを生成するだけで、次にチェーン上でプルーフの正しさを検証し、最終的に複数の L2 トランザクションをイーサリアム上の 1 つのトランザクションにパッケージ化します。したがって、StarkNet で発生する取引コストは、相乗り (Pinduoduo) と同様に、同じパッケージング バッチ内の他の取引所で共有することができ、取引が増えるほどコストが低くなります。

さらに、各ノードがトランザクションを完全に実行できるようにするイーサリアムの方法と比較して、トランザクションの ZK プルーフを生成する StarkNet の方法は、ネットワーク動作速度を大幅に向上させ、オンチェーン通信トラフィックを削減し、ネットワーク スループットを向上させることができ、より高い TPS とより低いガスを実現します。

つまり、計算の正しさを検証することと比較すると、教師は生徒が知識を習得したかどうかを確認する必要があるということです。イーサリアムの方法は、各クラスメートが教科書全体を暗唱できるかどうかをチェックすることですが、スタークネットの方法は、生徒にレポートをやらせることです。後者はより効率的で安価ですが、それでも安全性は保証されます。

EVM対応

StarkNet ネットワーク自体は EVM と互換性がないため、別の ZK フレンドリーな Cairo VM セットが設計されています。

StarkNet は Hermez や Scroll のようなイーサリアム オペコード用の ZK 回路を作成しませんでしたが、より ZK に優しいアセンブリ言語、AIR (代数中間表現) および高級言語 Cairo のセットを作成しました。

https://vitalik.eth.limo/general/2022/08/04/zkevm.html

StarkNet は、Vitalik によって定義されたタイプ 4 レベル (言語互換の zkEVM) に属します (StarkNet は、カスタマイズされた仮想マシンであるため、厳密には zkVM に属します)。

StarkNet 自体は EVM と互換性がありませんが、StarkNet は他の方法で Ethereum と互換性を保つことができます。

1. Warp: Solidity をカイロ語に翻訳する翻訳ツール

Warp は、有名な Ethereum インフラストラクチャ チーム Nethermind によって開発された Solidity-Cairo トランスレータです。 Warp は Solidity コードを Cairo に変換できますが、実行効率を最大化するために、翻訳された Cairo プログラムを変更して Cairo 機能 (組み込み関数の呼び出し、メモリの最適化など) を追加する必要があることがよくあります。

2. Kakarot: カイロ語で書かれた zkEVM

• Kakarot はカイロで書かれたスマート コントラクトで、現在 Starknet (goerli testnet) 上に展開されており、そのバイトコードは EVM と同等です。現在ベータ版です。 Ethereum アプリケーションは、Kakarot にデプロイすることで StarkNet に移植できます。

• Kakarot は、(a) 任意の EVM バイトコードを実行する、(b) EVM スマート コントラクトをそのままデプロイする、(c) Kakarot によってデプロイされた EVM スマート コントラクトの関数 (表示および書き込みメソッド) を呼び出すことができます。

現在、EVM のすべてのオペコードがサポートされています。

https://github.com/sayajin-labs/kakarot

動作原理

動作原理

成分

https://david-barreto.com/starknets-architecture-review/#more-4602 

• StarkNet には 5 つのコンポーネントがあります。それは、StarkNet 上の Prover (認証者)、Sequencer (ソーター) およびフル ノード、そして Ethereum 上に展開される Verifier (Verifier) およびコア ステート コントラクト (StarkNet Core) です。

• StarkNet 上でトランザクションを開始すると、オフチェーン サーバー (ソーター) がそれらを受信し、並べ替え、検証し、ブロックにパッケージ化します。トランザクションを実行し、状態遷移を StarkNet Core コントラクトに送信します。

• 証明者はトランザクションの証明を生成し、それをイーサリアムの検証者コントラクトに送信します。

検証者は検証結果を Ethereum 上の StarkNet Core コントラクトに送信し、StarkNet Core コントラクトから新しい Ethereum トランザクションのセットをトリガーして、記録を保持するためにチェーン上のグローバル状態を更新します。 L1 トランザクション ガスを節約するために、状態トランザクションは「calldata」(EIP-4844 以降の BLOB) として送信されます。これらの「メタデータ」は、StarkNet フル ノードによって復号化できます。

フルノードは基本的にストレージ機能を実行します。フルノードは、実行されたすべてのトランザクションの状態変更、メタデータ、証明、および記録を StarkNet に保存し、システムの現在のグローバル状態を追跡します。必要に応じて、フルノードは「メタデータ」を復号化し、StarkNet の歴史を再構築します。

StarkNet 開発提唱者 @barretodavid による StarkNet のアーキテクチャ レビューを参照してください。 【 1 】

ブラウザ https://testnet.starkscan.co/、L2ダイナミックブロック生成、イーサリアム1時間決済

アカウントの抽象化とトランザクション モデル

イーサリアム EOA+CA のデュアルアカウント設計とは異なり、StarkNet は、EIP 4337 の精神を活かし、ネイティブ アカウントの抽象化と 1 つのアカウント設計のみを実現します。

https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781 

次の図はトランザクション モデルを示しています。

• ネイティブ アカウントの抽象化により、アカウント プログラマビリティへの扉が開きます。StarkNet 開発提唱者 @barretodavid は、StarkNet に携帯電話のハード ウォレットを実装するというアイデアについて言及しました。

• イーサリアム上の EOA は、Secp 256 k 1 楕円曲線上の署名スキーム ECDSA のみをサポートします

• ほとんどのスマートフォンはイーサリアムの楕円曲線をサポートしていません。

• したがって、モバイル ウォレットはトランザクションに署名するためにソフトウェアに依存する必要があり、したがってモバイル ウォレットはホット ウォレットとなります。

StarkNet のネイティブ アカウント抽象化は複数の楕円曲線をサポートし、署名検証は高度にプログラム可能であるため、StarkNet/Cairo に基づくモバイル ウォレットを完全にハード ウォレットに変えることができます。

https://github.com/spartucus/nistp 256-cairo

Cairo にはすでに nistp 256 (Smartphone Secure Enlave 用) が実装されています。

STARK

簡単に言うと、携帯電話の暗号化モジュールを直接呼び出して、トランザクションに「ハード署名」することです。

現在、Halo、PLONK、Groth 16、Groth 09、Marlin、Plonky 2 など、さまざまな証明システム (証明の生成と検証) があり、それらはすべて SNARK 証明システムに属しています。証明システムには、証明を生成する証明者と、証明を検証する検証者がいます。異なる ZK プロジェクトは、ほぼすべて異なる証明システムを使用しており、StarkNet で使用される STARK は、ある意味で特別な SNARK に属します。

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

https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/

スケーラビリティの点では、STARK の方がスケーラビリティが優れています。プルーフの生成速度は線形にスケーラブルで、検証時間とプルーフ サイズは対数的にスケーラブルです。ただし、生成されるプルーフ サイズが大きくなるという欠点があります。しかし、証明のサイズが大きくなるにつれて、検証のコストはわずかに減少します。つまり、証明が大きくなるほど、総コストは低くなります。

まとめると、SNARK と比較すると、STARK は安全性が高く、検証規模が大きくなるにつれて平均検証時間と証明サイズが減少しますが、初期証明サイズが大きいというデメリットがあり、大規模なアプリケーションに適しています。 。

詳細な拡張

証明時間は直線的に増加します: 証明者が費やした時間は、ハッシュ呼び出しの数に応じてほぼ直線的に増加します。

https://eprint.iacr.org/2021/582.pdf

80 ビットのセキュリティ レベルでは、STARK の 12288 回のハッシュ呼び出しごとの証明者の実行時間は 1 秒 (12288 回/秒)、98304 回のハッシュ呼び出しごとに 10 秒 (9830 回/秒) が必要です。 STARK の証明時間とハッシュ呼び出しは基本的にほぼ線形であることが知られています。以下に示すように

**検証と証明サイズの対数スケール: 検証時間 (および証明サイズ) は、ハッシュ呼び出しで対数的にスケールされます。 **以下に示すように:

左の図からわかるように、ハッシュ呼び出しが 3072 から 49152 に増加すると、検証時間は 40 ミリ秒から 60 ミリ秒に増加します。また、ハッシュ呼び出しが 49152 から 786432 に増加しても、検証時間は 60 ミリ秒から 80 ミリ秒に増加するだけでした。同じ大きさであることの証明。したがって、ハッシュ呼び出しの数が多いほど、平均検証時間が短くなり、平均プルーフ サイズ (ハッシュ値/プルーフを生成するためのハッシュの呼び出し) が小さくなることがわかります。

再帰的証明"知識システム (特に STARK) の一般的で簡潔な証明/議論は、計算を段階的に検証するために使用できます。これは、計算によって、その計算の前のインスタンスの正しさの証明を生成できることを意味します。この概念は非公式に「再帰的証明合成」として知られています。"または

再帰的スターク」。

https://medium.com/starkware/recursive-starks-78 f 8 dd 401025 

言い換えれば、再帰的 STARK 証明者は、システムの状態が a から a+1 に移動できるというステートメントの証明を生成できます。証明者は a の計算上の完全性の (再帰的) 証明を検証し、状態 a の計算を忠実に実行したため、新しい状態 a+1 に到達します。つまり、2 つの証明 a と a+1 を 1 つの証明**に結合するプロセスであることが理解できます。以下に示すように:**

Cairo VM: 計算が正確であることを確認する

カイロ VM の概要

StarkNet OS/Cairo OS という形で現れることもありますが、計算を行う EVM とは異なり、Cairo VM 自体は計算のための証明を生成し、正しさを検証するだけです。

Cairo VM はノイマン型アーキテクチャを採用した CPU VM で、そのプログラミング言語は Cairo とも呼ばれ、Cairo 言語は Cairo アセンブリに基づいているため、コンパイル効率が非常に高くなります。 Cairo は、CPU Algebraic Intermediate Representation の頭字語です。 Cairo VM には、この「CPU」の命令セットを検証するための 1 つの AIR が含まれています。

その仕組みについては、受信したトランザクションに基づいてシステムの L2 状態を更新します。 (カイロベースの) StarkNet 契約の実行を促進します。このオペレーティング システムは Cairo に基づいており、本質的には STARK 証明システムを使用して出力を証明および検証するプログラムです。 StarkNet コントラクトで利用できる特定のシステム操作と機能は、オペレーティング システムへの呼び出しとして利用できます。

カイロ言語の概要

Cairo は StarkNet のスマート コントラクト言語であり、STARK 設計に基づいており、Cairo プログラムは STARK プルーフを生成できます。

Cairo プログラムはアセンブリ コードのコレクションであり、Cairo 開発者は、Cairo アセンブリではなく高級言語 Cairo でスマート コントラクトを作成します。 Cairo プログラムを作成するとき、Cairo コンパイラは Cairo コードを Cairo アセンブリにコンパイルし、Cairo アセンブラはそのアセンブリ コードを使用して、Cairo VM で実行するための Cairo バイトコード (Cairo CPU で実行される) を生成します。また、実際のマシン上でオペコードとマシンコード (および命令) にコンパイルする必要があります。

非決定的な計算

Cairo プログラムの目的は、特定の計算が正しいことを検証することであるため、それらの決定論的な計算に比べてショートカットを実行することが可能です。これは、計算を証明するために、検証者が計算に含まれない追加の作業を実行できることを意味します。

たとえば、x = 961 の平方根 y が 0、1、…、100 の範囲にあることを証明します。簡単なアプローチは、961 で始まる複雑なコードを作成し、そのルートを計算し、このルートが必要な範囲内にあることを確認することです。

疑似コードは次のとおりです。y の値を推測します (これは非決定的な部分です)。 y 2 を計算し、その結果が x と等しいことを確認します。 y が範囲内にあることを確認します。そして、以下のような計算方法を取るとします。 Y = SQRT(X) 代わりに、次のように計算できます (非決定的計算)。 Y*Y=X

ご覧のとおり、考えられる解決策は 2 つあります。 +Y と -Y ですが、そのうちの 1 つだけが残りの命令を満たす可能性があります。

これは、一部の Cairo プログラム (上記のような) は追加情報がなければ効率的に実行できないことを意味します。この情報は、いわゆるヒントによって提供されます。ヒントは Cairo Runner のための特別な命令であり、値を簡単に導き出すことができない非決定論的な問題を解決するために使用されます。理論的には、ヒントは任意のプログラミング言語で記述できます。現在の Cairo 実装では、ヒントは Python で記述されています。

決定的仮想マシンと非決定的仮想マシンについて、証言者

• an accepting input to the Cairo deterministic machine, that constitutes the witness to the nondeterministic machine.

ここでの Cairo には、実際には決定論的な Cairo VM と非決定論的な Cairo VM が関係します。前者は本格的な zkVM、証明と検証であり、後者は非決定論的コンピューティングに使用されます。

Cairo 決定論的 VM の許容可能な入力は非決定論的 VM の証人を構成し、ZKP はその証人を入力および出力証明として使用する必要があります。 (NP ステートメントの証人は、ステートメントが正しいことを効率的に検証できる情報の一部です。たとえば、あるグラフにハミルトニアン サイクルが存在すると述べられている場合、証人はそのようなサイクルです。サイクルが与えられると、有効なハミルトニアン環であるかどうかを効率的に確認できますが、そのような環を見つけるのは困難です)

並列ステートマシンです。

メモリモデル: 読み取り専用、非決定的

読み取り専用の非決定的メモリ。つまり、各メモリ セルの値は証明者によって選択され、時間の経過とともに (カイロ プログラムの実行中) 変更できず、不変です。この命令は読み取りのみ可能です。これはライトワンス メモリと考えることができます。値はセルに 1 回だけ書き込むことができますが、後で変更することはできません。

これは連続的で、空の場合は任意の値が入ります。

ROM の利点には次のものがあります。

RAMよりも回路がシンプルで低コスト

永久保存、

改ざん不可、データ変更・削除不可

組み込み関数: コードのコンパイルを削減します。

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b 71976 ad 0108 

開発者は、コードを変換せずに組み込み関数を直接呼び出してコンピューティングのオーバーヘッドを削減し、開発エクスペリエンスを最適化できます。組み込み関数を追加しても CPU の制約には影響しません。これは、示されているように、CPU と組み込み関数の間で同じメモリが共有されることを意味します。

Cairo アーキテクチャでは、特定の組み込み関数のセットは指定されていません。組み込み関数は、必要に応じて AIR (代数中間表現) に追加または削除できます。

CPU アーキテクチャ: 柔軟

より柔軟で、ソフトウェア プログラミングを通じて AISC のパフォーマンスに限りなく近づけることができます (つまり、Cairo が CPU を行うのでしょうか?)。 Cairo を使用して他の仮想マシンをフォークします。

ブートロード: ハッシュからプログラムをロードします

• プログラムは別のプログラムのバイトコードをメモリに書き込み、プログラム カウンタがそのメモリ セグメントを指すようにして、そのプログラムを実行できます。ハッシュからのブートローディングの使用例は、ブートローダーと呼ばれるプログラムが別のプログラムのバイトコードを計算して出力し、その後、以前と同様に実行を開始する場合です。この方法では、検証者は完全なバイトコードではなく、プログラムのハッシュのみを知る必要があります。これには次の 2 つの利点があります。

• STARK セクションで説明したように、スケーラビリティ、検証時間、およびプログラム サイズは対数関係を示します。

プライバシー、検証者は計算を知らなくてもプログラムが正しく実行されていることを検証できます。

連続メモリ: メモリアドレスへの連続アクセス

Cairo には、プログラムがアクセスするメモリ アドレスが連続している必要があるという技術要件があります。たとえば、アドレス 7 と 9 にアクセスする場合、プログラムが終了する前にアドレス 8 にもアクセスする必要があります (アクセスの順序は関係ありません)。アドレス範囲に小さなギャップがある場合、証明者はこれらのアドレスを任意の値で自動的に埋めます。一般に、このようなギャップがあると、使用されていないときにメモリが消費されることになるため、非効率的です。穴が多すぎると、誠実な証明者が実行するには証明生成のコストが高くなりすぎる可能性があります。ただし、これでも健全性の保証に違反するわけではありません。とにかく虚偽の証明は作成できません。

StarkNet の生態の目録:

https://h 0 m 83 hhc 6 r.feishu.cn/docx/doxcnS 3 GGdXXc 1 PzKh 9 uTgTR 73 c

フルチェーンゲーム

フルチェーンゲーム

Matchbox DAO：https://mirror.xyz/matchboxdao.eth

The Future of On-Chain Gaming：

https://volt.capital/blog/the-future-of-on-chain-gaming

Game 2.0 ：

https://www.guiltygyoza.xyz/2022/07/game 2 

フルチェーン ゲーム — 生産効率 + 消費者エクスペリエンスの変革、基本的に、思考 (さまざまな組織やチームからの記事)、実践 (チェーン上のゲーム プロジェクトやハッカソン)、資金調達 (融資や補助金)、そして最も重要なのは、活気に満ちた開発者がいるということです。コミュニティ。

トポロジー チームである Lootreamls を強くお勧めします。

コントラクトウォレット

• コントラクトウォレットがハードウォレットになることを実現するには2つの方法があります。

• コンセンサス層は携帯電話ハードウェアをサポートします。 StarkNet (プログラミング言語 Cairo) などのネイティブ アカウント抽象化の L2 では、イーサリアムのような ECDSA (Secp 256 k 1 ) だけをサポートするのではなく、さまざまな楕円曲線をサポートしているため、携帯電話の暗号化チップ/モジュールはトランザクションに直接署名できます (ほとんどの携帯電話は ECDSA をサポートしていません)。したがって、ネイティブアカウントが抽象化されたL2では、コントラクトウォレットはハードウォレットと同様に、ハードウェアを介して直接トランザクションに署名できます。

ウォレット層は署名の転写を実行します。イーサリアムのような非ネイティブのアカウント抽象化ネットワークでは、コントラクトウォレットは署名して転記できます。 EIP-4337 と同様に、検証ロジックをカスタマイズでき、ユーザーは携帯電話ハードウェアでサポートされているアルゴリズムで署名し、イーサリアムでサポートされている ECDSA に変換します。

• StarkNet の開発提唱者である @barretodavid は、StarkNet に携帯電話のハード ウォレットを実装するというアイデアについて言及しました。

• イーサリアム上の EOA は、Secp 256 k 1 楕円曲線上の署名スキーム ECDSA のみをサポートします

• ほとんどのスマートフォンはイーサリアムの楕円曲線をサポートしていません。

• したがって、モバイル ウォレットはトランザクションに署名するためにソフトウェアに依存する必要があり、したがってモバイル ウォレットはホット ウォレットとなります。

https://twitter.com/barretodavid/status/1563584823884935168 

StarkNet のネイティブ アカウント抽象化は複数の楕円曲線をサポートし、署名検証は高度にプログラム可能であるため、StarkNet/Cairo に基づくモバイル ウォレットを完全にハード ウォレットに変えることができます。

カイロにはすでに [nistp 256](

) (スマートフォン Secure Enlave 用) の実装。

コントラクトウォレット＋フルチェーンゲームの組み合わせにより、ウォレット＋DeFi以外の新たなシナリオが広がります。 Argent や Cartridge.gg がやってます。

オンチェーンAI

Modulus Labs：https://www.moduluslabs.xyz/

Giza - Machine Learning in the Blockchain：

https://gizatech.xyz/

StarkNet decentralization : Kicking off the discussion

mirror.xyz：https://community.starknet.io/t/starknet-decentralization-kicking-off-the-discussion/711 

現在、ML プラットフォーム Giza とオンチェーン取引ロボット (ModulusLabs の Rockybot) という 2 つの機械学習プロジェクトがあり、StarkNet 中国グループにはもう 1 つあります。

アプリケーションには、ゲーム、オラクル、トランザクション (自動収入)、魔女対​​策、KYC、データ プライバシー、AI モデル コンピューティング パワー マイニングが含まれます。

ありがとう

ありがとう

この記事は HackerDojo によって資金提供および執筆されました。 Hacker Dojo は、Hacker が共同構築した暗号化および Web3 フロンティア テクノロジーのオープンソース ナレッジ コミュニティです。

クリエイターの Maxlion と HackerDojo に感謝します。