作者: ゲームタバース
一般に、ゲームはループベースです。ゲーム ループは、通常、ユーザー入力の処理、ゲーム状態の更新、ゲーム世界のレンダリングで構成される反復プロセスです。このループはゲームの実行中も継続し、通常はゲームの世界の流れを維持するために 1 秒あたり数十回から数百回実行されます。
ただし、ブロックチェーンのアーキテクチャはプッシュベースです。ブロックチェーンは、ネットワーク内のノードを通じて情報を共有および保存する分散データベースです。ノードが新しいトランザクション (転送、コントラクト呼び出しなど) を生成すると、そのトランザクションはネットワークにプッシュされ、他のノードがそれを検証し、トランザクションを受信した後にブロックチェーンに追加します。これは受動的なプロセスであり、ノードは新しいトランザクションを積極的に検索せず、ネットワーク内の他のノードが新しいトランザクションを送信するのを待ちます。したがって、ブロックチェーンのアーキテクチャはプッシュベースであると言われます。
したがって、フルチェーン ゲームではクロック サイクルによるサイクル システムを実装することが非常に重要です。結局のところ、いわゆる「自律世界」では、ブロックチェーンにプッシュされたトランザクション入力に従って受動的に進化するのではなく、一部の NPC や仮想環境が時間の経過とともに自動的に進化することを誰もが望んでいます。
@therealbytes は、Conway のライフ ゲームの自動ティックティック実装を実行する OP スタックに基づいて概念実証ティック チェーン (クロック サイクルを持つチェーン) を開発しました。彼がそれをどのように実装したかを見てみましょう。
翻訳を簡単にするために、tick を文字通り「tick」に翻訳します。これは「サイクルクロックサイクル」を意味します。
Ticking-Optimism は、Optimism Bedrock ロールアップ アーキテクチャに基づく「Ticking Blockchain」の概念実証実装です。
ティックチェーンには「ティックコントラクト」と呼ばれる特別なスマートコントラクトがあり、各ブロックはプロトコルによって自動的に呼び出されます。これにより、ユーザーがトランザクションを送信する必要がなく、他のスマート コントラクトが特定の時間または間隔で自動的にトリガーされるようになります。
Optimism の新しいモジュラー ロールアップ アーキテクチャである Optimism Bedrock では、「入金トランザクション」と呼ばれる新しいトランザクション タイプが導入されています。通常の取引とは異なり、入金取引では次のことが行われます。
レイヤ 1 からのブロック。
署名検証は必要ありません。
L1 で L2 ガスを購入するため、L2 ガスは返金できません。
オリジナルの Bedrock では、預金トランザクションは次の 2 つの目的で使用されていました。
L1 に直接送信されたトランザクションを実行します。
各ブロックに事前展開された L2 コントラクトの L1 プロパティ (番号、タイムスタンプ、ハッシュなど) を設定します。
後者の場合、トランザクションはロールアップ ノードによって作成されます。ガス代は支払われず、使用したガスはガスプールから差し引かれません。
Ticking-Optimism は、ロールアップ ノードを変更し、同様に動作する「ティック トランザクション」も作成しますが、L1 プロパティを設定する代わりに、アドレス 0x4200000000000000000000000000000000000A0 に事前にデプロイされたコントラクト内の Nick() 関数を呼び出します。このコントラクトは、ターゲット変数を設定することで別のコントラクトを呼び出すことができます。
＃＃＃ モチベーション
ティックチェーンの威力を説明するために、複数の NPC (ノンプレイヤー キャラクター) がマップ上を移動するブロックチェーン上のゲームを想像してください。ティック チェーンを使用しない場合、主な設計アプローチは 2 つあります。
更新が遅い。クライアント側では、NPC は継続的に移動しているように見えますが、その位置はユーザーがトランザクションを送信して対話するときにのみオンチェーンで更新されます。次に、コントラクトは、最後のオンチェーン更新とそれ以降に経過したブロック数に基づいて NPC の新しい位置を計算します。
手動カチカチ音。マップ上の各 NPC の位置を設定する更新関数を定義し、外部アカウントから定期的に呼び出されます。
ティックチェーンを使用すると、ソリューションは手動ティックと似ていますが、ティック コントラクトは手動ではなく自動的に更新関数を呼び出します。
手動ティックの代わりにティック チェーンの「自動ティック」を使用する利点は次のとおりです。
更新は契約により保証されています。
更新はブロック内のすべてのトランザクションの前に実行され、プロトコル自体の一部であるため前に実行することはできません。
更新取引は通常のガス市場には参加しません。
ただし、自動ティックにはカスタム ブロックチェーンが必要です。更新レートが同じ場合、手動ティックと自動ティックではノード上に同じコンピューティング リソースが必要です。一方、遅延更新は、オンチェーン更新の規模が小さく、頻度も低いため、通常は安価です。
さらに、更新する必要がある状態が大きくなるにつれて、ティック トランザクションの計算コストも増加します。これにより、開発者には、コストがチェーンがサポートできる金額を決して超えないようにアプリケーションを設計するというさらなるプレッシャーがかかります。
これらの大きな欠点にもかかわらず、特定の種類のアプリケーションでは、遅延更新よりも自動ティックの方が適しています。
ティックにより、スマート コントラクトは、オープン形式の式を使用して更新される動的状態に、一定のコストでアクセスできるようになります。
状態 (上記の例では、NPC の位置) は、一定の比較的低いガスコストで常にオンチェーンで読み取り可能です。ただし、現在の状態を計算するコストは、前回の更新以降のブロック数に応じて増加し、ガスコストはさらに増加します。
一定の速度で移動するエンティティの位置を更新している場合、最後に設定された位置と更新以降のチャンクの数から、エンティティが特定のチャンク内のどこにあるべきかを計算できます。この操作のコストは、更新間のブロック数に応じて増加しません。
一方、更新する状態がコンウェイのライフ ゲーム (または 3 重力シミュレーション) のようなものである場合、更新のコストは最後の更新以降のステップ数に比例して増加します。ユーザーが支払ってもよい金額やチェーンがサポートできる金額を超えて成長する可能性があるため、これは問題です。
遅延更新では、更新ロジックをスマート コントラクトとクライアントの両方に実装する必要があります。ティッキングを使用すると、ブロックチェーン上に実装するだけで済み、クライアントはオンチェーンのイベントに簡単に反応できます。
遅延更新により、開発者は更新ロジックを多くの関数とスマート コントラクトに分散し、各関数が特定のトランザクションが実行された場合にのみトリガーされるようにすることができます。対照的に、ティックティックアプローチでは、定期的に起動することが保証されている更新関数のみが必要です。後者により、状態の一貫性と整合性を維持することが容易になります。
また、新しい遅延更新状態 (新しいタイプの NPC など) が追加されるたびに、それを考慮してすべての更新関数を変更する必要がある場合があります。これにより、コード ベースがより複雑になり、問題が発生しやすくなります。
遅延更新のコストは大きく異なることが多く、ユーザーは更新の負担のほとんどが他の人にかかるようにトランザクションを作成できます。ティックを使用すると、すべての操作のコストが比較的安定し、MEV 攻撃に対して脆弱になりません。
Conway のライフ ゲームのインタラクティブ バージョンを実行するティックチェーン デモを構築しました。チェーンは、実行エンジンにセル オートマトン ロジックを組み込むように変更され、効率が向上し、スマート コントラクト バイトコードとして実装できるよりも大きなゲーム ボードが可能になりました。
デモのソースコード:
デモビデオ:
10k 人気度
13k 人気度
41k 人気度
29k 人気度
676 人気度
98k 人気度
27k 人気度
26k 人気度
7k 人気度
15k 人気度
OPStack を使用してフルチェーン ゲームのクロック サイクルを構築するにはどうすればよいですか?
作者: ゲームタバース
一般に、ゲームはループベースです。ゲーム ループは、通常、ユーザー入力の処理、ゲーム状態の更新、ゲーム世界のレンダリングで構成される反復プロセスです。このループはゲームの実行中も継続し、通常はゲームの世界の流れを維持するために 1 秒あたり数十回から数百回実行されます。
ただし、ブロックチェーンのアーキテクチャはプッシュベースです。ブロックチェーンは、ネットワーク内のノードを通じて情報を共有および保存する分散データベースです。ノードが新しいトランザクション (転送、コントラクト呼び出しなど) を生成すると、そのトランザクションはネットワークにプッシュされ、他のノードがそれを検証し、トランザクションを受信した後にブロックチェーンに追加します。これは受動的なプロセスであり、ノードは新しいトランザクションを積極的に検索せず、ネットワーク内の他のノードが新しいトランザクションを送信するのを待ちます。したがって、ブロックチェーンのアーキテクチャはプッシュベースであると言われます。
したがって、フルチェーン ゲームではクロック サイクルによるサイクル システムを実装することが非常に重要です。結局のところ、いわゆる「自律世界」では、ブロックチェーンにプッシュされたトランザクション入力に従って受動的に進化するのではなく、一部の NPC や仮想環境が時間の経過とともに自動的に進化することを誰もが望んでいます。
@therealbytes は、Conway のライフ ゲームの自動ティックティック実装を実行する OP スタックに基づいて概念実証ティック チェーン (クロック サイクルを持つチェーン) を開発しました。彼がそれをどのように実装したかを見てみましょう。
翻訳を簡単にするために、tick を文字通り「tick」に翻訳します。これは「サイクルクロックサイクル」を意味します。
Ticking-Optimism は、Optimism Bedrock ロールアップ アーキテクチャに基づく「Ticking Blockchain」の概念実証実装です。
ティックチェーンには「ティックコントラクト」と呼ばれる特別なスマートコントラクトがあり、各ブロックはプロトコルによって自動的に呼び出されます。これにより、ユーザーがトランザクションを送信する必要がなく、他のスマート コントラクトが特定の時間または間隔で自動的にトリガーされるようになります。
達成方法
Optimism の新しいモジュラー ロールアップ アーキテクチャである Optimism Bedrock では、「入金トランザクション」と呼ばれる新しいトランザクション タイプが導入されています。通常の取引とは異なり、入金取引では次のことが行われます。
レイヤ 1 からのブロック。
署名検証は必要ありません。
L1 で L2 ガスを購入するため、L2 ガスは返金できません。
オリジナルの Bedrock では、預金トランザクションは次の 2 つの目的で使用されていました。
L1 に直接送信されたトランザクションを実行します。
各ブロックに事前展開された L2 コントラクトの L1 プロパティ (番号、タイムスタンプ、ハッシュなど) を設定します。
後者の場合、トランザクションはロールアップ ノードによって作成されます。ガス代は支払われず、使用したガスはガスプールから差し引かれません。
Ticking-Optimism は、ロールアップ ノードを変更し、同様に動作する「ティック トランザクション」も作成しますが、L1 プロパティを設定する代わりに、アドレス 0x4200000000000000000000000000000000000A0 に事前にデプロイされたコントラクト内の Nick() 関数を呼び出します。このコントラクトは、ターゲット変数を設定することで別のコントラクトを呼び出すことができます。
＃＃＃ モチベーション
ティックチェーンの威力を説明するために、複数の NPC (ノンプレイヤー キャラクター) がマップ上を移動するブロックチェーン上のゲームを想像してください。ティック チェーンを使用しない場合、主な設計アプローチは 2 つあります。
更新が遅い。クライアント側では、NPC は継続的に移動しているように見えますが、その位置はユーザーがトランザクションを送信して対話するときにのみオンチェーンで更新されます。次に、コントラクトは、最後のオンチェーン更新とそれ以降に経過したブロック数に基づいて NPC の新しい位置を計算します。
手動カチカチ音。マップ上の各 NPC の位置を設定する更新関数を定義し、外部アカウントから定期的に呼び出されます。
ティックチェーンを使用すると、ソリューションは手動ティックと似ていますが、ティック コントラクトは手動ではなく自動的に更新関数を呼び出します。
手動ティックの代わりにティック チェーンの「自動ティック」を使用する利点は次のとおりです。
更新は契約により保証されています。
更新はブロック内のすべてのトランザクションの前に実行され、プロトコル自体の一部であるため前に実行することはできません。
更新取引は通常のガス市場には参加しません。
ただし、自動ティックにはカスタム ブロックチェーンが必要です。更新レートが同じ場合、手動ティックと自動ティックではノード上に同じコンピューティング リソースが必要です。一方、遅延更新は、オンチェーン更新の規模が小さく、頻度も低いため、通常は安価です。
さらに、更新する必要がある状態が大きくなるにつれて、ティック トランザクションの計算コストも増加します。これにより、開発者には、コストがチェーンがサポートできる金額を決して超えないようにアプリケーションを設計するというさらなるプレッシャーがかかります。
これらの大きな欠点にもかかわらず、特定の種類のアプリケーションでは、遅延更新よりも自動ティックの方が適しています。
ティックにより、スマート コントラクトは、オープン形式の式を使用して更新される動的状態に、一定のコストでアクセスできるようになります。
状態 (上記の例では、NPC の位置) は、一定の比較的低いガスコストで常にオンチェーンで読み取り可能です。ただし、現在の状態を計算するコストは、前回の更新以降のブロック数に応じて増加し、ガスコストはさらに増加します。
一定の速度で移動するエンティティの位置を更新している場合、最後に設定された位置と更新以降のチャンクの数から、エンティティが特定のチャンク内のどこにあるべきかを計算できます。この操作のコストは、更新間のブロック数に応じて増加しません。
一方、更新する状態がコンウェイのライフ ゲーム (または 3 重力シミュレーション) のようなものである場合、更新のコストは最後の更新以降のステップ数に比例して増加します。ユーザーが支払ってもよい金額やチェーンがサポートできる金額を超えて成長する可能性があるため、これは問題です。
遅延更新では、更新ロジックをスマート コントラクトとクライアントの両方に実装する必要があります。ティッキングを使用すると、ブロックチェーン上に実装するだけで済み、クライアントはオンチェーンのイベントに簡単に反応できます。
遅延更新により、開発者は更新ロジックを多くの関数とスマート コントラクトに分散し、各関数が特定のトランザクションが実行された場合にのみトリガーされるようにすることができます。対照的に、ティックティックアプローチでは、定期的に起動することが保証されている更新関数のみが必要です。後者により、状態の一貫性と整合性を維持することが容易になります。
また、新しい遅延更新状態 (新しいタイプの NPC など) が追加されるたびに、それを考慮してすべての更新関数を変更する必要がある場合があります。これにより、コード ベースがより複雑になり、問題が発生しやすくなります。
遅延更新のコストは大きく異なることが多く、ユーザーは更新の負担のほとんどが他の人にかかるようにトランザクションを作成できます。ティックを使用すると、すべての操作のコストが比較的安定し、MEV 攻撃に対して脆弱になりません。
Conway の人生ゲームのデモ
Conway のライフ ゲームのインタラクティブ バージョンを実行するティックチェーン デモを構築しました。チェーンは、実行エンジンにセル オートマトン ロジックを組み込むように変更され、効率が向上し、スマート コントラクト バイトコードとして実装できるよりも大きなゲーム ボードが可能になりました。
デモのソースコード:
デモビデオ: