これは明らかに従来のゲームの開発モデルとは異なります。 成功した従来のゲームは、魅力的なゲームメカニクスを通じて多くのユーザーを引き付け、開発者が収益性の高い経路を構築し、関連商品やIPに拡大する可能性があります。 これらのゲームは、プレイヤーがゲームを楽しんでいる間にゲーム内外の経済的利益をしばしば得るというポジティブなサイクルで運営されています。

一方、現在のブロックチェーンゲームは主に金銭的なリターンを通じてプレイヤーを引き付けます。彼らの低いプレイ性に加えて、Web3ゲームは高い参入障壁や手間のかかるインタラクションプロセスなど、長年の課題に直面しています。

これらの問題の根本原因は何ですか？意見は分かれています。 TabiChainチームは、優れた伝統的なゲーム開発者が技術的および学習の障壁のためにWeb3エコシステムに参入するのに苦労していると考えています。ゲームやソフトウェア開発に馴染みのない人々にとって、Web2からWeb3への移行は単なる物語と環境の変化に見えるかもしれませんが、現実ははるかに厳しいものです。

では、どのようにして伝統的なゲーム開発者や関連企業に対して技術を通じてより歓迎される環境を作ることができるのでしょうか？次のセクションでは、Web3ゲームが直面する課題とその解決策を徹底的に分析し、将来のWeb3ゲーム産業がどのように伝統的なゲーム開発者により適したように技術的に調整されるかを説明します。

従来のゲーム開発者がWeb3エコシステムに参入するのを妨げる技術的な理由

前回の記事では、不親切なテクノロジーと高い学習コストが、従来のゲーム実践者がWeb3エコシステムに参入するのを妨げる主な要因であることについて簡単に述べました。いわゆる不親切なテクノロジーと高い学習コストは、次の点に拡張できます。

1. web3アプリケーションと従来のソフトウェア構造の違い

ブロックチェーンおよびその上のアプリケーション（dApps）は、従来のソフトウェアアーキテクチャとは根本的に異なり、開発者にはブロックチェーンの動作原理、合意プロトコル、スマートコントラクトプログラミングモデルなどの新しい知識体系が必要です。従来のゲーム開発者は、Solidityや他のスマートコントラクト言語を学ぶために多くの時間を費やす必要があり、EVMの動作原理を理解する必要があります。

さらに、従来のゲームロジックは通常、集中型サーバーで実行されるため、複雑なゲーム状態や高頻度の相互作用を柔軟に処理できます。ブロックチェーン上でゲームロジックを実行するには、各操作を分散ネットワークに公開して実行し、その後チェーンにアップロードする必要があるため、高度な簡略化やリファクタリングが必要です。これはブロックチェーンのパフォーマンスやコストの制約を受けています。

1. スマートコントラクトの設計上の制限

EVMはチューリング完全であり、理論上は任意のロジックを表現できますが、その特性はゲーム開発には非常に不利です。

• タイマーの不足。イーサリアムチェーン上のすべての操作は、EOAアカウントによって手動でトリガーされる必要があります。タイマーに類似した効果を得るためには、開発者は追加のサービスを展開し、EOAアカウントとイベントリストを維持して予定されたタスクを手動でトリガーする必要があります。チェーン上の遅延の問題により、これらの予定されたタスクが時間通りに完了することは保証されません。

• コールバックやその他のメカニズムはありませんし、マルチスレッディングや非同期をサポートしていません。SolidityはEthereumのスマートコントラクト開発用に設計されており、その実行環境は従来のランタイム環境とは大きく異なります。EVMの動作はトランザクショナルであり、各関数呼び出しはトランザクション内で完全に実行される必要があります。従来の意味での「非同期」の概念はありません。つまり、Solidityにおける関数呼び出しは最初から最後までアトミックであり、他のトランザクションによって中断されることはありません。
• 外部データを参照する能力はありません。Chainlinkのようなオラクルがあるにもかかわらず、統合の観点やデータコールの観点から見て、httpsリクエストを介してデータコールを直接取得することとは大きく異なり、これにより開発者は追加の統合を行うことができます。負担と依存。
• スケーラビリティとパフォーマンスの制限。ゲームロジックは、単一のトランザクションのガス料金が高すぎるか、最大限度を超えないように複数の単純なトランザクションに単純化または分割する必要があります。これにより、複雑な相互作用や機能の実装が制限されます。

1. データの保存と取得に関する制限

• スマートコントラクトには高額なストレージスペースと限られた設計があり、大量のゲームデータを保存するには適していません。
• イベントログは、ゲームの状態を間接的に追跡するために必要となる場合がありますが、イベントのキャプチャが安定しないことがあります。ゲームの状態をいつ更新するかという問題は、プレイヤーやゲームオペレーターが手動でトリガーする必要があることがよくあります。
• EVM が採用しているアカウントデータ構造は、データのインデクシング機能が貧弱であるため、アカウントのデータをクエリすると、そのETHまたはチェーン固有トークンの残高を知ることしかできませんが、所有するERC-20アセットや各アセットの残高は直接知ることができません。NFTについても同様です。この情報は、ユーザー自身のアカウントに格納されているのではなく、各アセットの専用契約にカプセル化されています。

特定のアドレスがどのようなトークンや残高情報を持っているかは、Etherscanなどのツールから確認できます。これらはブロックチェーンブラウザなどの周辺ツールがインデックス化し、後者は専用の巨大なデータベースを構築して完全にクロールする必要があります。チェーン上のすべてのデータを要約するには、すべてのブロックデータを収集するか、チェーン上のイベントを監視する必要があります。

Web3の開発者は通常、Etherscan、NFTscan、The Graphなどのサードパーティのデータプロバイダを統合する必要があり、API KEYを支払う必要があります。さらに、これらのサードパーティサービスは基本的にオフチェーンのデータベースであり、遅延、エラー、コールリミット超過、サービス利用不可などの障害を引き起こす可能性があります。

ほとんどのゲームのデータベース形式とブロックチェーンのデータストレージ方法の違いを比較しましょう。 2つの違いは明らかです。 ほとんどのゲームのデータ構造は完全に独自にカスタマイズされており、優れた表現およびインデックス機能を持ち、第三者サービスに頼る必要はありません。

1. 既存のゲームアセットをブロックチェーンと統合する際の課題

既存のゲームアセット（プロップやキャラクターなど）は通常、ブロックチェーン上で作成および管理されません。これらのアセットをブロックチェーンに移行する場合、一般的ながらも長尾のデータ型を標準的なNFTやトークンに変換する必要があり、複雑な移行および統合作業が必要となり、既存のゲーム経済システムに影響を与えるでしょう。

1. アップグレード、パッチ、および災害予防

Ethereumでは、スマートコントラクトがデプロイされると、コードは不変になり、アップグレードやパッチが伝統的なソフトウェアよりも複雑になります。 開発者は、通常、この制限を回避するためにプロキシコントラクトやバージョン管理パターンを使用しますが、これは全体の構造の複雑さを増加させます。 プロキシコントラクトは、ストレージスロットの競合によるデータの破損を回避するために特に注意して使用する必要があります。 さらに、管理権限漏洩のリスクも深刻です。

伝統的なゲームのコードアップグレードは技術構造の観点からはそれほど複雑ではありません。制限する必要がある唯一のことは、中央集権化されたアップグレード権限です。これは、スマートコントラクトに頼るのではなく、DAOなどの方法を通じて達成できます。

さらに、伝統的なゲームでは、データベースのスナップショットやバックアップを取ることがよくあります。通常はそれほど重要ではありませんが、アップグレードで重大なバグに遭遇した場合、データを素早くロールバックすることができます。これは基本的にブロックチェーン上のファンタジーです。古い契約のデータや状態を新しい契約に移行する方法はまだ複雑です。たとえ一部のゲームデータが契約の再構築によってロールバックされたとしても、古い契約のデータや状態を新しい契約に移行する方法はまだ複雑です。

1. 生態的断片化とユーザーエクスペリエンスの問題

異なる公開チェーンやVMには、完全に異なるスマートコントラクト言語、アーキテクチャ、データ構造などがあります。Web2では、ゲーム開発者はUnityなどのクロスプラットフォームのフロントエンドエンジンを選択します。これにより、iPhone、Android、デスクトップなどの異なる環境で実行するためにわずかに適応されたコードセットを作成できます。バックエンドがユーザーターミナルで実行されないため、クロスプラットフォームの問題は発生しません。

Web3では、これは基本的に贅沢です。異なるチェーンやVMに移行すると、プロジェクト全体を再構築し、莫大なコストが発生します。さらに、Web3に新しく参入する開発者は、自分に適したエコシステムを選択するための全くの経験がありません。それは技術的な観点からか、生態系の観点からか、どちらでしょうか。

ユーザーエクスペリエンスレベルでは、ブロックチェーンの相互作用は非常に複雑です。以前は非常に人気のあったアカウント抽象化の概念は、Web3のユーザーエクスペリエンスの問題を解決するために正確に登場したため、ここでは詳細には立ち入りません。

上記の6つの主な議論をリストした後、要約しましょう: web2からweb3への開発者は非常に大きな適応の閾値に直面しています。彼らがweb2のトップ開発者であれば、web2のキャリアを捨ててweb3のような見知らぬものに行く必要はありません。この環境では、成功するかどうかわからないビジネスを開発しています。

言えることは、ほとんどのトップゲーム開発者がWeb3に参入していないということです。ある程度、これにより、ほとんどのWeb3ゲームは特に高いプレイ性や楽しさよりも財務的な投機に偏っていると言えます。

同様の障害はユーザー側にも存在します。Web3ゲームには、ユーザーの変換率を妨げる一連の操作ステップがあり、Web2の巨大なユーザーグループがWeb3ゲームの存在を経験したがらず、あるいは完全に無自覚であることが原因です。

上記の問題を解決できるインフラレベルのプロジェクトはありますか？ Tabi Chainは、Web3ゲームの究極の解決策の1つに非常に近いプロジェクトかもしれません。そのコアコンセプトは「オムニ実行レイヤー」です。開発者はもはやさまざまなVMやオペレーティング環境の違いを気にする必要はありません。彼らは自分の使い慣れた、またはカスタマイズ可能なオペレーティング環境を直接使用してゲームを開発したり移植したりすることができます。

さらに、Tabi Chainにはモジュラーコンセンサス、セキュリティレイヤー、およびその他の機能が備わっています。すべてがモジュール化され、さまざまなゲームやアプリケーションのニーズに対応できるようカスタマイズ可能です。

Omni-Execution Layer: 開発者のニーズに基づいて実行環境を選択する

ブロックチェーンの基本的な概念を再考しましょう。一部の人はそれを分散型で変更不可能な台帳と説明するかもしれませんが、より正確には分散ネットワーク内で状態機械の永続的な状態を検証可能に同期させるものと定義されます。

基本的に、ブロックチェーンは普遍的に受け入れられたステートマシンとその運用状況を維持します。

• 各入力は決定論的であり、すべてのブロックに記録されています;
• 状態遷移関数はブロックチェーンクライアント内のVMまたはランタイムによって表され、決定論的です;
• アウトプット状態も決定論的であり、すべてのブロックに記録されています。

したがって、ブロックチェーンの合意システムは、単一の実行レイヤー（EVMのみなど）に限定される必要はありません。実行レイヤーの数に関係なく、チェーンが複数のレイヤーを横断して状態を検証できる限り、各ゲームが独自の環境で動作できるようにすることで、これまでに議論されてきたさまざまな問題に対処できます。

In Tabi,各ゲームまたはdAppは独自のサービスを構築できます。すべてのサービスは独自に生成されたブロックをチェーンのコンセンサスシステムに提出します。スーパーバイザーノードには、サービスのすべてにランタイム/VMが含まれ、サービスブロックの状態を検証します。存在するTabiのオールラウンド実行レイヤーの中心は、多態性の能力を持つVMと見なすことができるため、それは多態性VMと呼ばれています。

既存のブロックチェーンVMについて、多様性VMはこれらのVMをランタイム環境内に統合し、必要なインターフェイス呼び出しメソッドを提供する必要があります。“統合”という概念は、ここでは2つの方法で実装することができます。

共有ワールドステート：Ethermintに似ており、Cosmos上でEVMをサポートしています。 EVMは、ユーザーのインタラクションと契約操作に焦点を当てた表面層として機能し、すべてのユーザーサイドの活動がEVM上で実行されているように見えます。 ただし、これらの操作の最終的な結果とデータは、他のCosmosモジュールに格納されています。 したがって、このEVM互換性は基礎データのマッピングであると言えます。

このマッピング関係は、他のVMにも拡張することができます。例えば、Ethermintは追加のSVMモジュールレイヤーを組み込むことができ、SVMとEVMの両方が同じ基礎データに対応しています。

これは、Windows仮想マシンを実行するためにPC上でVMWareを使用するのに似ています。VMWareは、仮想マシンの仮想ハードドライブと物理コンピュータのハードドライブの両方にアクセスできます。その後、Mac仮想マシンを起動すると、物理ディスクからデータを同じ方法でマウントできます。この設定により、複数の仮想マシンが同じ環境のリソースと状態を共有できるようになります。

Tabi Chain’s Main Serviceは共有ワールドステートアプローチを使用します。これは、対応するVMが適応されている限り、そのVM向けに開発されたdAppsは、別のサービスを作成する必要なく、Main Serviceに直接展開できるということを意味します。

Independent World State: 異なるアプリケーションやゲームには固有の要件があり、一部のゲームはカスタムランタイムを使用しています。そのため、Polymorphism VM内の「共有ワールドステート」を介してすべてのVMを統合する普遍的なアプローチはすべてのケースに適していません。独立したワールドステートも必要です。なぜなら、実装が簡単で完全に分離されたデータを持つサービスに最適だからです。

どのアプローチを使用しても、それはスーパーバイザーノードによって検証可能でなければなりません。つまり、Polymorphism VM は、さまざまな実装方法で使用されるすべての VM またはランタイムを含める必要があります。

Web2ゲームの移植例

Polymorphism VMは非常にカスタマイズ可能で、特にWeb2開発者にとって非常に有益です。彼らはなじみのある言語やフレームワークを使用して、任意のビジネスロジックをPolymorphism VMに移植することができます。

MinecraftがTabiに移植したいとします。一般的なプロセスは次のとおりです:

1. サーバーコードを変更します。Minecraftサーバーコード（Javaまたは他の言語）をわずかに変更し、チェーン上にある必要があるデータをデータベース（または一連のデータベース）に移動します。このデータベースを変更する可能性のあるすべての機能（つまり、状態遷移機能）を特定および選択します。
2. コンポーネントをパッケージ化します。このデータベースとこれらの機能をJARファイルにパッケージ化し、これはJavaの実行可能プログラムです。このパッケージにJRE（Java Runtime Environment）を含めます。この全体のパッケージは、すべてのデータがオンチェーンであることを確認しながら、Polymorphism VMにロードされます。
3. オフチェーンロジックの実行：（チーム形成、チャットなど）チェーン上に必要のない他のバックエンドロジックをオフチェーンサーバーで実行します。
4. サービスを開始します：Tabi Chainでサービスを開始し、監督ノードのポリモーフィズムVMに同じJREをロードするように通知します。
   

これで、全プロセスが完了しました。

開発者にとって、これらの修正は既存のJava言語とフレームワーク内で行われます。同じコンセプトは、他の方法を使用して開発されたゲームにも適用されます。ユーザーにとっては、ゲームの相互作用はほとんど変わりません。明らかに、このWeb2ゲームの移植方法は非常に迅速で効率的であり、おそらくWeb3ゲームの大規模な導入の基本モデルとなる可能性があります。

ゲームSTR（State Transition Runtime）機能の詳細

前の例は、Web2ゲームの移植の概要を提供しました。 より深く理解するには、さらに詳細に踏み込む必要があります。 今回は、特定のゲームではなく一般的な例を使用して、Omni-Execution Layerのランタイムに関連する詳細を説明します。

基本的に、ゲームのランタイム環境をカスタマイズすることは、ブロックチェーン上でゲームの状態遷移ランタイム（STR）と呼ばれる状態機械を作成することと見なすことができます。

上記の例は、Web2ゲームの移植の一般的なプロセスです。詳細については、さらに詳しく知る必要があります。今回は、特定のゲームの例ではなく、万能な実行レイヤーでのランタイムに関連する詳細を示す一般的な例を使用しています。

基本的に、ゲームの実行環境をカスタマイズすることは、ブロックチェーン上の特定のゲームのための状態遷移ランタイムと呼ばれるものを作成することと見なすことができます。

STRは、バイナリまたはモジュールの形式でポリモーフィズムVMに統合できます。

ブロックチェーンのようなシステムでは、入力の透明性、状態遷移の公開可視性、およびグローバル状態の表現力を確保する必要があります。これらの要件を満たすために、以下の機能を備えたランタイムを構築する必要があります:

1. World DBContains all user data within the application that needs to be recorded on the blockchain. This data should be valuable and important, so a blockchain-like structure is needed to ensure its availability. Therefore, not all data needs to be recorded on the blockchain. For example, in games, the user’s chat content is generally not important and is disposable, so there is no need to put it on the blockchain.
2. それは世界の完全な状態を表現することができます。多くのシナリオでは、ゲームなどでは、この表現が必ずしも高い追跡可能性を意味するものではありません - シンプルなアキュムレーターで十分です。これは、Merkleツリーのようなデータ構造が常に必要とされるわけではないことを意味します。ただし、世界の状態を表現するためにどのようなデータ構造を使用しても、世界のデータベースの世界の状態を要約形式で表現できることが重要です。
3. 世界データベースに変更をもたらす可能性のあるすべての機能は、状態遷移関数と呼ばれ、状態遷移ランタイムにカプセル化する必要があります。ランタイム外での世界データベースの変更は違法と見なされ、拒否されるべきです。
4. 入出力インターフェースは、入力インタプリターとブロック提案者の設計に準拠する必要があります。これは比較的簡単であり、ここでは詳細に説明しません。

以下の組織構造は、このSTRの重要な要素です。 Tabiは、開発者がランタイムを簡単に作成できるように、デフォルトでSDKを提供します。

ワールドDB

実際には、ゲームやアプリケーションはおそらく1つ以上のデータベースを使用し、これらのデータベースは異なるタイプである可能性があります。特定のゲームがリレーショナルデータベースとキー値データベースの両方を使用していると仮定しましょう。

以下はシンプルな関係データベースの例です:

1. UID: ユーザーを表す一意のユーザーです。これは公開鍵または他の識別子である可能性があります。
2. Nonce: リプレイ攻撃を防ぐために使用されます。
3. 追加データフィールド: 任意の種類のデータ。

これは単純なキー値データベースです：

ステート遷移関数

これは単純な状態遷移関数です。この関数はユーザーからの入力を受け取ると、単純にそれを5倍にして関係データベース内のデータを変更します。

ワールドステートアキュムレータ

簡単なハッシュアキュムレータを構築して、ワールドステートを表現することができます:

A_s+1 = ハッシュ(A_s + ハッシュ(クエリ))

この方法により、世界データベースへの任意の変更後も、その変更に対応する一意で明確な状態が常に存在することが保証されます。

重要なのは、すべての状態遷移関数がこのメソッドを実装する必要があるということです。この要件は、修飾子、インターフェイス、フック、または他の言語固有のメカニズムを使用して強制できます。さまざまなプログラミング言語の特性の違いにより、ここでは具体的な詳細には立ち入りません。

キー値データベース（KVDB）の更新プロセスは、同じ原則に従います。

ランダムな数字

状態遷移関数にはランダムな数値を含めるべきではありません。なぜなら、これによって異なる検証者によって検証されたときに異なる結果が生じ、一貫性が壊れる可能性があるからです。ランダムな数値はシステムの入力パラメータの一部として含めるべきです。

要約

上記の例から、Tabi ChainのOmni-Execution Layerは、モジュラーアプローチを通じてゲーム開発者に大きな柔軟性を提供していることがわかります。スペースの制約により、ここではすべての詳細を議論することはできませんが、言及された中核的なポイントは、Tabi Chainのソリューションが実用的かつ革新的であることを十分に示しています。

現在のWeb3エコシステムでは、異なるチェーンやVMで開発された作品は一般的にポータビリティに欠けています。Web2ゲームがWeb3に移行するためには、しばしば馴染みのない言語や環境でゲームを書き直すことを意味し、さまざまな理解できない制限に直面することが多いです。

Tabiを使用することで、開発者は元の言語、開発プラットフォーム、エンジンを使用できます。彼らは、プロジェクトをブロックチェーンの世界にもたらすために、SDKを呼び出すのと似た簡単な適応と修正を行うだけです。これにより、効率が指数関数的に改善され、複雑さが低減されます。

We hope Tabi Chain can become a catalyst for the mass adoption of Web3 games, attracting talented Web2 game developers and bringing truly entertaining and playable games to the Web3 space.

免責事項：

1. この記事は[から転載されました极客 Web3]. すべての著作権は元の著者に帰属します [ローベンベン]. If there are objections to this reprint, please contact the Gate Learnチームが promptly で対処します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。