一般的に、ゲームはループベースのシステムに基づいています。ゲームループは、ユーザーの入力の処理、ゲームの状態の更新、ゲームワールドのレンダリングなどのステップを繰り返し実行するプロセスです。このループはゲームの実行中に継続的に行われ、通常は 1 秒間に数十回から数百回実行されます。これにより、ゲームワールドがスムーズに表示されます。
しかし、ブロックチェーンのアーキテクチャはプッシュベースです。ブロックチェーンは分散型のデータベースであり、ネットワーク上のノードが情報を共有・保存します。ノードが新しいトランザクション（送金、契約呼び出しなど）を生成すると、そのトランザクションはネットワークにプッシュされ、他のノードはそのトランザクションを受け取り、検証してブロックチェーンに追加します。これは受動的なプロセスであり、ノードは新しいトランザクションをアクティブに検索するのではなく、ネットワーク上の他のノードからの新しいトランザクションを待ちます。そのため、ブロックチェーンのアーキテクチャはプッシュベースと呼ばれています。
したがって、フルチェーンゲームでクロックサイクルを持つループシステムを実装することは非常に重要です。なぜなら、「自治世界」では、いくつかの NPC や仮想環境が時間とともに自動的に進化することを望んでいるからです。それらはブロックチェーンにプッシュされたトランザクションの入力に従って受動的に進化するのではなく、時計周期に従って進化することを望んでいます。
@therealbytes は、OP スタックをベースにした Tick-Chain（クロックサイクルを持つチェーン）のコンセプト検証を開発しました。これは、自動的にチックする Conway's Game of Life の実装を実行します。以下では、彼がどのように実現したのかについて説明します。
翻訳の簡略化のために、"tick" を「滴答」と直訳します。これは「ループサイクル」を意味します。
Ticking-Optimism は、Optimism Bedrock rollup アーキテクチャに基づいた「滴答チェーン」のコンセプト検証実装です。
滴答チェーンでは、特別なスマートコントラクトである「滴答コントラクト」があり、各ブロックでプロトコルによって自動的に呼び出されます。これにより、他のスマートコントラクトが特定の時間や間隔で自動的にトリガーされることが可能になり、ユーザーがトランザクションを送信する必要はありません。
実装方法#
Optimism の新しいモジュール化された rollup アーキテクチャである Optimism Bedrock は、「デポジットトランザクション」という新しいトランザクションタイプを導入しました。通常のトランザクションとは異なり、デポジットトランザクションは次のような特徴があります。
- Layer 1 からのブロックから来ます。
- 署名の検証は必要ありません。
- L1 で L2 のガスを購入するため、L2 のガスは返金されません。
元の Bedrock では、デポジットトランザクションは 2 つの目的で使用されます。
- L1 に直接送信されるトランザクションを実行する。
- 各ブロックで事前にデプロイされた L2 スマートコントラクトに L1 のプロパティ（番号、タイムスタンプ、ハッシュなど）を設定する。
後者の場合、トランザクションは rollup ノードによって作成されます。それはガスを支払わず、使用されるガスはガスプールから差し引かれません。
Ticking-Optimism は、rollup ノードを変更し、「滴答トランザクション」（tick transaction）も作成しました。これは同じように機能しますが、L1 のプロパティを設定するのではなく、アドレス 0x42000000000000000000000000000000000000A0 に事前にデプロイされたコントラクトの tick () 関数を呼び出します。このコントラクトは、目標変数を設定することで別のコントラクトを呼び出すことができます。
動機#
Ticking-Optimism のパワーを示すために、マップ上で複数の NPC（非プレイヤーキャラクター）が移動するゲームを想像してみてください。滴答チェーンがない場合、2 つの主要な設計方法があります。
-
怠惰な更新（Lazy updating）。クライアント側では、NPC は連続的に移動しているように見えますが、その位置はユーザーが相互作用するトランザクションをチェーンに送信したときにのみ更新されます。その後、コントラクトは最後のチェーン上の更新とそれ以降のブロック数に基づいて NPC の新しい位置を計算します。
-
手動の滴答（Manual ticking）。更新関数を定義し、地図上の各 NPC の位置を設定し、外部アカウントが定期的にそれを呼び出します。
滴答チェーンを使用すると、手動の滴答と同様のソリューションが得られますが、滴答コントラクトが自動的に更新関数を呼び出すため、手動で呼び出す必要はありません。
手動の滴答と比較して、自動の滴答の利点は次のとおりです。
- 更新がプロトコルによって保証されます。
- 更新はブロック内のすべてのトランザクションの前に実行され、前に置かれることはありません。なぜなら、それはプロトコル自体の一部だからです。
- 更新トランザクションは通常のガス市場に参加しません。
ただし、自動の滴答にはカスタムのブロックチェーンが必要です。更新レートが同じ場合、手動と自動の滴答はノードの計算リソース要件が同じです。一方、怠惰な更新は通常、チェーン上の更新がより小さく、少ないため、より安価です。
さらに、更新する必要のある状態が増えるにつれて、滴答トランザクションの計算コストも増加します。これは開発者に追加のプレッシャーをかけ、コストがチェーンがサポートできる範囲を超えないようにアプリケーションを設計する必要があります。
これらの大きな欠点があるにもかかわらず、自動の滴答は、怠惰な更新よりも特定のタイプのアプリケーションに適しています。
- 状態が常に明確で最新であること
滴答により、スマートコントラクトは更新される動的な状態に恒定のコストでアクセスできます。この状態は、オープンな形式の式で更新されます。
状態（上記の例では NPC の位置）は常に恒定の、比較的低いガスコストでチェーン上から読み取ることができます。ただし、現在の状態を計算するコストは、前回の更新以来のブロック数の増加に応じて増加するため、ガスコストも増加します。
一定の速度で移動するエンティティの位置を更新している場合、最後に設定された位置と前回の更新以来のブロック数から、任意のブロックでの位置を計算できます。この操作のコストは、更新間のブロック数の増加に伴って増加しません。
一方、更新する状態が Conway's Game of Life（または Three-Body Gravity Simulation）のようなものである場合、更新のコストは前回の更新以来のステップ数に比例して増加します。これは問題です。なぜなら、それはユーザーが支払いたいか、またはチェーンがサポートできる範囲を超えるまで成長する可能性があるからです。
-
クライアントの役割が異なる
怠惰な更新を使用する場合、更新ロジックはスマートコントラクトとクライアントの両方で実装する必要があります。滴答を使用する場合、ブロックチェーン上でのみ実装する必要があり、クライアントは単にチェーン上のイベントに反応するだけです。 -
コードがよりシンプルで監査しやすい
怠惰な更新では、開発者は更新ロジックを多くの関数やスマートコントラクトに分散させ、各関数は特定のトランザクションの実行時にのみトリガーされます。対照的に、滴答の方法では、定期的にトリガーされる更新関数だけが必要です。後者は状態の一貫性と完全性を維持するのがより簡単になります。
また、新しい怠惰な更新状態（例えば、新しいタイプの NPC）を追加するたびに、すべての更新関数を変更して考慮する必要があります。これにより、コードベースが複雑になり、問題が発生しやすくなります。
- ユーザーは更新のコストを支払いません
怠惰な更新のコストは通常大きく変動し、ユーザーはトランザクションを調整して、大部分の更新の負担を他の人に押し付けることができます。滴答を使用すると、すべての操作のコストが比較的安定し、MEV 攻撃の影響を受けにくくなります。
Conway's Game of Life デモ
私は滴答チェーンのデモを構築し、対話型バージョンの Conway's Game of Life を実行しました。チェーンは変更され、実行エンジン内のセルオートマトンロジックが最適化され、スマートコントラクトのバイトコード実装よりも大きなゲームボードを可能にします。
デモのソースコード：https://github.com/therealbytes/ticking-conway
デモビデオ：
オリジナルの記事：https://therealbytes.substack.com/p/presenting-ticking-optimism
オリジナルの著者：@therealbytes
日本語への翻訳：@hicaptainz