０　注意！（はじめる前に）

実際に実行すると、私の環境では、こちらの「.foundry」フォルダにJSONファイルがどんどん溜まっていきました。

PCの容量がどんどん減っていきますので、不要なものは削除したり、必要時以外はシステムを止めるのが良いと思います。

１　事前準備

こちらの公式に沿って進めていきます。

下の４つを準備してください。

ちなみに、「pnpm」は「performant npm」の略のようです。

その名の通り、パフォーマンスの最適化を図っているようです。

こちらは参考に、chatGPTからです。

ちなみに、「pnpm」のコマンドがうまくいかない場合、第６章も参考にして見てください。

２　実際にやってみよう

では、実際にやってみましょう。

１　プロジェクトの作成

まずは、下のコマンドを実行し、「vanilla」を選択します。

pnpm create mud@next my-project

ちなみに、依存関係として、「@latticexyz/cli」を入れています。

この「Autonomous World」を作っている会社です。

２　プロジェクトの実行

では、次のコマンドで、実行してみましょう。

cd my-project 
pnpm run dev

３　mud.config.tsからの生成

まずは、下のように、「mud.config.ts」というファイルによって、二つのsolidityファイルが作られています。

ちなみに、２つの関係性はこのようになっています。

今回は、１ずつ増えるだけの「Counter」を保持しています。

４　コントラクトフォルダからの生成

そして、コントラクトフォルダを元に、インターフェースが作られます。

具体的な仕組みの部分が「IIncrementSystem」になります。

５　Systemコントラクトのデプロイ

次に、「IncrementSystem」というコントラクトができました。

６　モジュールコントラクトのデプロイ

次に、下の４つのモジュールがデプロイされました。

７　Worldコントラクトのデプロイ

そして、最後に「World」がデプロイされました。

８　Coreモジュールのインポート

次に、こちらの「Core」モジュールをインポートしています。

９　テーブルの登録

次に、「Counter」というテーブルが登録されました。

１０　システムの登録

その後、システムが登録されています。

１１　関数の登録

その上で、関数が登録されたようです。

最後に、結果が「Worlds.json」に格納されています。

１２　動作を確認してみよう

では、実際に確認してみましょう。

http://localhost:3000/

に行き、「Increment」を選択すると、イベントが発生し、その結果がフロントにも反映されているようです。

下の場合、「ブロック番号」が7477で発火しているようです。

では、コードを見てみましょう。

３　全体構成について

まずは、全体像として、「packages」に「client」と「contracts」があります。

１　contractsについて

まずは、「contracts」については、主に下のようになります。

登場人物はこのようなイメージです。

２　clientについて

一方、「client」は下のようになります。

後ほど、一つずつ見ていこうと思います。

４　contractsについて

では、contractsについて細かく見てみましょう。

１　mud.config.tsについて

では、「mud.config.ts」を見てみましょう。

こちらは、使用するテーブルなどを指定します。

例えば、下では、「Counter」というテーブルを作っています。

今回は、すでに作られていますが、「contracts」フォルダ内で、下のコマンドを実行することで、ファイルが作成されます。

pnpm mud tablegen

２　Counter.solについて

コードの中身は下のようになっています。

下はゲッター系と登録を行う関数が並んでいます。

また、最後まで見てみますと、セッター系やレコードの削除を行う関数もあります。

このように、テーブルの構成が決まれば、あとは自動でsolidityのファイルを作成しています。

つまり、下のようなことが行われています。

３　IncrementSystem.solについて

次に、「systems」内の「IncrementSystem」コントラクトを見てみましょう。

下のように、ロジックと値が分離しています。

このコントラクトは、あくまでもロジックの部分のみで、値は「Counter」の「get」と「set」を使っています。

４　PostDeploy.s.solについて

次に、「PostDeploy.s.sol」を見てみましょう。

ここはその名の通り、デプロイ後に、特定の処理を行うコントラクトです。

ただ、個人的に気になったのはこちらです。

処理は、「Iworld」から行われています。

他の箇所でも書かれていたのですが、このように、処理は「World」を起点にして行われているようです。

５　Tables.solについて

ちなみに、「Counter.sol」では、下のように、IDも取得しています。

この、「Counter」ライブラリと「ID（CounterTableId）」を「Table.sol」はインポートしています。

下の部分です。

５　clientについて

では、次に、「client」について見てみましょう。

１　index.tsについて

１ー１　setup関数について

まずは、index.tsを見てみましょう。

トップレベルの非同期処理として、setup関数が実行されています。

そして、「components」「increment」「network」に分割代入しています。

１ー２　observableについて

次に、RxJSのobservableの部分を見てみましょう。

ご不明の方は、この辺りの記事が参考になると思います。

「components.Counter.update$」の部分がObservableになります。

「subscribe」関数で購読を開始しています。

データが流れてくると、中のコールバック関数が実行され、表示が変わります。

なお、「subscribe」関数は登録を行なっているので、１回のみ行われます。

（その後、データが流れてくると、コールバック関数は実行されます。）

１ー３　windowオブジェクトへの関数の追加

下の部分では、「window」オブジェクトに「increment」関数を追加しています。

これにより、consoleから直接実行ができるようになります。

２　setup.tsについて

では、「index.ts」で行われた、「setup」関数を見てみましょう。

下のように構成されています。

３　getNetworkConfig.tsについて（ネットワーク構成の取得）

次に、「getNetworkConfig.ts」の「getNetworkConfig」関数を見てみましょう。

その名の通り、Networkの構成を取得すると考えられます。

なお、結論としましては、下のような情報を取得します。

３ー１　paramsの取得について

まずは、下の部分で、「クエリストリング」のキーと値のペアのオブジェクトを取得しました。

実際に見た方がイメージが湧くかもしれません。

下のような感じです。

３ー２　チェーン情報の取得について

次に、上で取得したparamsを元に、チェーンの情報を取得しています。

３ー３　Worldアドレスの取得について

また、下の部分では、「World」のコントラクトアドレスを取得しています。

３ー４　初期ブロック番号の取得について

さらに、下の部分で最初のブロック番号についても設定しています。

３ー５　秘密鍵の取得について

なお、下の部分を見ると、秘密鍵は、一時的に実行しているアカウントのプライベートキーを取得しているようです。

３ー６　一時アカウントの秘密鍵の取得関数について

少しわきにそれますが、「getBurnerPrivateKey」関数を見てみましょう。

これは、一時的に作成したアカウントの秘密鍵を取得するものです。

まずは「localStorage」になないかを確認します。

もしあるようなら、正しいものかを確認し、正しければ、その秘密鍵を返しています。

３ー７　秘密鍵生成関数について

ないようなら、「generatePrivateKey」関数を使って、秘密鍵を作成し、「localStorage」に保管しています。

ちなみに、「generatePrivateKey」関数は下のように、「secp256k1」の「randomPrivateKey」関数を使っているようです。

３ー８　faucetについて

また、「faucetServiceUrl」では該当するものがあれば、「faucetUrl」を指定しているようです。

４　Worldについて

４ー１　Worldについて

次に、「world」を確認しましょう。

このように、createWorld関数の結果が格納されています。

４ー２　createWorld関数について

下のようになっています。

まとめると、このようになっていました。

５　setupNetworkについて

次は、「setupNetwork」関数を見てみましょう。

５ー１　networkConfigについて

まずは、「networkConfig」を取得しています。

ちなみに、network configは次のようになっていました。

５ー２　戻り値について

「setupNetwork」関数の戻り値は、こちらを返しています。

つまり、このようになります。

５ー３　clientOptinosについて

まずは、「clientOptinos」が次のように設定されています。

下のようになりました。

つまり、どのチェーンで、どのようにして、どのくらいの間隔で、ブロックチェーンとやりとりするのかを選択しています。

５ー４　publicClientについて

そして、この「clientOptions」を元にして、「publicClient」が作成されます。

下のようになりました。

５ー５　burnerWalletClientについて

次は、下の部分の「burnerWalletClient」を見てみましょう。

このようにして、「client Options」を元にして、「burnerWalletClient」を作成しています。

５ー６　write$について

なお、write$では、Subject のインスタンスを作成しています。

SubjectはObservableとObserverの両方の特徴を持ちます。

Subjectについてはこの辺りの記事がわかりやすいです。

これで、データストリームの変更が監視できます。

５ー７　worldContractについて

この部分で、「worldContract」を作成しています。

状況としては、このようになっています。

重要なのはこの部分かと思います。

ここで、受け取ったwriteデータをwrite$に送信しています。

これにより、このSubjectを購読しているすべてのObserverにデータが配信されます。

５ー８　createStoreSync関数について

続いて、「createStoreSync」関数を確認してみましょう。

その名の通り、ここでブロックチェーンとStoreとの同期を行うための情報（主に、「blockStorateOperations$」） が作成されています。

構成としては、下のようになっています。

「開始ブロック」や「最大ブロック範囲」で同期するブロックを指定しています。

その他、「onProgress」で進行状況を報告し、「storageAdapter」はデータの読み書きのインターフェースとして利用されています。

これを元にして、最新ブロックやオペレーション（blockStorageOperations$）などを返しています。

５ー９　blockStorageOperations$について

また、こちらの「blockStorageOperations$」の部分を確認します。

初期のストレージ操作（initialStorageOperations$）とその後のブロックログ(blockLogs$)に基づいてストレージ操作を生成するストリームのようです。

５ー１０　syncToRecs関数について

では、これを踏まえて、「syncToRecs」関数を見てみましょう。

大まかに、下のようになっています。

下のように、途中で、「createStorageSync」を呼び出しています。

つまり、このようになっています。

そして、下の部分で、Observableからのデータやイベントを受け取るための購読を開始しています。

では、「setupNetwork」関数に戻ります。

下のように、「syncToRecs」関数が実行されていることがわかります。

つまり、こんな感じになりました。

５ー１１　戻り値について

そして、「setupNetwork関数」の戻り値は下のようになっています。

それを含めると、次のようになりました。

６　createClientComponent.tsについて

引数として、「setupNetwork」関数の結果として取得した「components」を使用しています。

そして、下のように、「components」をそのまま返しています。

コメントにあるように、「client components」の追加や上書きも想定しているようです。

７　createSystemCalls.tsについて

最後に、「createSystemCalls」関数を見てみましょう。

まずは、引数として、次を取得しています。

そして、こちらの「increment」関数を返しています。

下のように、「increment」は「worldContract」を通じて行われていることが確認できます。

これで以上です。

ただ、まだまだ足りないと感じているため、こちらのノートは都度追加を行なっていきたいと思います。

６　追記　pnpmのコマンドが通らない時

pnpmのコマンドがうまく通らないとの連絡をいただきました。

パスが問題なのではと思いました。

下の部分ができているか、確認して見てください。

１　pnpmの保存場所の確認

まずは、次のコマンドで、pnpmがどこにあるのかを確認しましょう。

which pnpm

私の場合は、「/Users/ytakahashi/.npm-global/bin」の中にありました。

２　パスを確認しよう

次のコマンドで、パスを確認してみましょう。

echo $PATH

「:」は区切り文字です。

私の場合は、このように先頭にありました。

３　PATHを更新する場合

永続的に、PATHを更新する場合は、下のコマンドを行います。

echo 'export PATH=$PATH:<PATHの情報をここに>' >> ~/.zshrc

なお、bashの場合は、「.zshrc」の部分を「/.bashrc」にします。

なお、「bash」か「zsh」かは、次のコマンドで確認ができます。

echo $0

私のPCは「zsh」です。

ちなみに、先ほどのこちらのコマンド、最初はとっつきにくいと思います。

ただ、内容としては、$PATHに新しいパスを追記して、環境変数としてexportしているだけです。

最後に、下のコマンドで、現在のシェルセッションに反映させます。

source ~/.zshrc

シェルセッションとは、現在開いているターミナル（コマンドプロンプト）の一連の操作のことです。

これは、この窓を閉じると、このシェルセッションは閉じられます。

４　うまくいったかを確認しよう

最後に、パスが通っているかを確認してみましょう。

pnpm --version

下のように、バージョンが表示されましたら、成功です。