jakiro
著者：Luo Benben、Tabi ChainのCTO
導入：前のサイクルでのAxieとStepnの誕生以来、GameFiとフルチェーンゲームは常にブロックチェーン業界のホットスポットの1つです。 。これらのビジョンは美しく聞こえますが、解決されたことのない問題に直面しています。
チェーンツアーのプレイ可能性は一般的に高くなく、憶測が低下した後、ユーザースケールは急速に縮小します。エッセンス
明らかに、これは従来のゲームの開発モデルに反しています。従来のゲームのスムーズな開発は、多くのユーザーを引き付けることができるゲームメカニズムに依存していますそして、彼ら自身の影響のために操作に成功したシステム全体は、ゲームの楽しみを体験できると言えます。
対照的に、現在のチェーンツアーは、プレーヤーを引き付けるための純粋なリターンに基づいていますエッセンスプレイアビリティが弱いことに加えて、Web3ゲームは、使用のしきい値や面倒な相互作用プロセスなどの古いファッションの問題にも直面しています。
これらすべてのルートは何ですか？さまざまな意見が異なります。Tabichainチームは、Web3ゲームに影響を与える重要な要因は、テクノロジーと学習コストのためにWeb3エコシステムに参入するのが難しい優れた従来のゲーム開発者であると考えています。Web2からWeb3まで、ゲームやソフトウェアの開発を理解していない人にとっては、それは単なる物語と環境ですが、実際の状況は予想よりもはるかに悪いです。
そうすべきですテクノロジーを通じて達成して、従来のゲーム開発者や関連メーカーにとってより友好的な環境を作成する方法は？以下では、Web3ゲームと複数の側面からの対応するソリューションが直面する問題を包括的に分析し、将来のWeb3ゲーム業界が従来のゲームプラクティショナーにより技術的に適している方法を説明します。
従来のゲーム開発者がWeb3エコロジーに入ることを妨げる技術的な理由
前の記事では、ハイテクと高学習コストが、Web3エコロジーに入る従来のゲーム開業医を妨げる中核的な要因であると簡単に述べました。
1.WEB3アプリケーションと従来のソフトウェア構造の違い
ブロックチェーンとアプリケーション（DAPPS）は、従来のソフトウェアアーキテクチャとは異なります。これは、動作原則、コンセンサス契約、ブロックチェーンのスマート契約プログラミングモデルなどの新しい知識システムを持つ必要があります。従来のゲーム開発者は、堅実さやその他のスマートコントラクト言語を学ぶために多くの時間を費やす必要があり、EVMの作業方法を理解する必要があります。
さらに、従来のゲームロジックは通常、集中サーバーで実行され、複雑なゲームステータスと高い周波数相互作用を柔軟に処理できます。ブロックチェーンでゲームロジックを実行するには、高い簡素化または再建が必要です各操作は分散ネットワークでリリースする必要があり、チェーンがオンになっているため、ブロックチェーンのパフォーマンスとコストによって大幅に制限されています。
2。スマートコントラクトの設計制限
EVMはチューリングの完全性に満足しており、理論的には任意の論理を表現できますが、その特性は以下などのゲーム開発に非常に不利です。
-
タイマーの欠如。Ethereumチェーンのすべての操作は、EOAアカウントによってトリガーされる必要があります。タイマーと同様の効果を達成するために、開発者は、タイミングタスクを手動でトリガーするためにEOAアカウントリストとイベントリストを維持するために追加のサービスを展開する必要があります。チェーンの遅延により、これらのタイミングタスクは時間通りに完了することはできません。
>
-
コールバックやその他のメカニズムはなく、マルチスレッドや非同期をサポートしていません。SolidityはEthereum Smart Contractsの開発のために設計されているため、その実行環境は従来のランタイム環境とは大きく異なります。EVMの操作は、従来の意味で「非同期」の概念を存在せずに1つのトランザクションで完全に実行する必要があります。これは、堅牢性の関数呼び出しが終わりの終わりまで開始されることを意味します。これは原子であり、他のトランザクションで中断することはできません。
-
外部データを引用する能力はありません。ChainLinkのような預言的なマシンはありますが、統合またはデータの呼び出しの観点からであろうと、使いやすさと直接HTTPSリクエストはデータコールを取得できます。
-
扩展性和性能限制。ゲームロジックは、単一のトランザクションのガス料金が高すぎるか、最大制限を超えないようにするために、複数の簡単なトランザクションに簡素化または分解する必要があります。これにより、複雑な相互作用と関数の実現が制限されます。
3.数据存储与调用的限制
-
智能合约的存储空间昂贵且设计有限，不适合存储大量游戏数据。
-
イベントログを使用してゲームステータスを間接的に追跡する必要がある場合があり、イベントの取得は不安定ではない場合があります。诸如何时刷新游戏状态等问题，常常需要玩家或者游戏运营方手动触发。
-
EVM采用的账户数据结构，导致其数据索引能力很差エッセンス特定のアカウントのデータを確認すると、ETHまたはチェーンプライマリートークンのバランスのみを理解できますが、それが持っている各資産のERC-20資産とバランスは直接知ることはできません。对于NFT也是一样的道理。この情報は、各資産の独占契約にカプセル化されており、ユーザー自身のアカウントに保存されていません。
>
Etherscanやその他のツールなどのツール、トークンなどの情報などから、これらはすべてのブロックデータやチェーンの聴取のみの周辺ツールからインデックス付けされています。チェーン。
Web3開発者は通常、EtherScan、NFTSCAN、グラフ、さらにはAPIキーの支払いなどの第3パーティデータプロバイダーを統合しました。さらに、これらの3番目のパーティサービスは、チェーンの下のデータベースの本質であり、停滞、エラー、コール制限を超える、およびサービスの失敗がある場合があります。
2つのゲーム独自のデータベースと、2つの違いが明らかになっていることを比較しましょう。ほとんどのゲームのデータ構造は、それ自体で完全にカスタマイズされています。
>
4.既存のゲーム資産と統合することの難しさ
既存のゲーム資産（小道具やキャラクターなど）は通常、ブロックチェーン上で作成および管理されません。これらの資産をブロックチェーンに移動し、一般に普遍的ではあるが長い尾のあるデータ型を標準のNFTまたはトークンに変換し、複雑な移行と統合作業を伴い、既存のゲームエコノミーシステムに影響します。
5.アップグレード、パッチ、災害防止
Ethereumでは、スマートコントラクトが展開されると、コードは不可能であるため、アップグレードおよび修理プログラムが従来のソフトウェアよりも複雑になります。開発者は、この制限をバイパスするためにプロキシ契約またはバージョンモデルを使用することがよくありますが、これにより、プロキシ契約の複雑さが増加します。さらに、管理当局の開示のリスクも深刻です。
従来のゲームのコードアップグレードは、技術構造ではそれほど複雑ではありません。抑制する必要がある唯一の可能性は、集中アップグレード機関だけです。これは、DAOやその他の方法を通じてスマートコントラクトの代わりに実装できます。
さらに、従来のゲームはしばしばデータベースのスナップショットまたはバックアップを実行します。これは重要ではないかもしれませんが、アップグレードに遭遇したときに大きなバグがある場合は、データをすばやくロールバックできます。これは基本的にナイトチェーンです。特定のゲームのデータが契約の再構成によって巻き戻されたとしても、古い契約のデータとステータスを新しい契約に移行する方法は依然として複雑です。
6.生態学的分割とユーザーエクスペリエンスの問題
異なる公共チェーンとVM、スマートコントラクト言語、アーキテクチャ、データ構造などは非常に異なっています。Web2では、ゲーム開発者はUnityなどのクロスプラットフォームのフロントエンジンを選択します。これは、iPhone、Android、デスクトップエンドなどのさまざまな環境でわずかに適応して実行できます。
Web3では、これは基本的に贅沢な希望です。
ユーザーエクスペリエンスのレベルでは、ブロックチェーンは相互に接続されています。
上記の6つの引数をリストした後、Web2からWeb3の開発者は、Web2のトップ開発者である場合、Web2のキャリアを放棄する必要はありません彼らが成功できるかどうかわからない。
言えますがトップゲーム開発者のほとんどはWeb3を入力していません。エッセンス
また、ユーザーのコンバージョン率を妨げる一連のWeb3ゲームの性質もあります。
上記の問題を解決できるインフラレベルのプロジェクトはありますか？Tabiチェーンは、Web3ゲームの究極のソリューションに非常に近いプロジェクトの1つです。：開発者は、さまざまなVMまたは操作環境の違いを気にする必要はなく、慣れ親しんでいる、またはカスタマイズできるゲームを直接開発または移植する必要があります。
さらに、Tabiチェーンには、モジュール式コンセンサスと安全層の特性もあります。
全能の実行層：実行環境を選択する開発者のニーズに応じて
ブロックチェーンの本質が何であるかを思い出しましょう。一部の人々は、それが分散していない非暴露元帳であると言うかもしれません。しかし、それがテクノロジーの本質に近い場合、分散ネットワーク内の状態マシンの検証された永久状態同期が同期されていると言われるべきです。
つまり、ブロックチェーンは実際に状態認識された状態マシンとその動作ステータスを維持しています。
-
各入力は確実であり、各ブロックに記録されています。
-
ステータス変換関数は確実であり、これは特にVMとして現れたり、ブロックチェーンクライアントで実行されたりします。
-
状態の出力も確実であり、各ブロックにも記録されています。
したがって、チェーンのコンセンサスシステムでは、どれだけの程度であっても、1つの実行レイヤー（EVMのみなど）だけではない場合があります。このチェーンが複数の実行レイヤーの状態を検証し、各ゲームを独自の環境で実行できる限り、上記のさまざまな問題を解決できます。エッセンス
>
Tabiでは、各ゲームまたはDAPPが独自の独立したサービスを構築できます。すべてのサービスは、チェーンのコンセンサスシステムに独自のブロックを提出します。
存在するTabiのすべてのアラウンド実行レイヤーのコアは、多型のVMと見なすことができるため、多型VMと呼ばれます。
>
既存のブロックチェーンVMの場合、多型VMはVMを独自の動作環境に含める必要があり、対応するインターフェイスコールメソッドを提供する必要があります。「含まれる」の概念には、ここに2つの特定の実装があります。
世界状態を共有：Ethermintと同様に、CosmosのEVMをサポートします。しかし、EVMは、ユーザーのインタラクション、契約操作などに焦点を当てた表面層にすぎないため、すべてのユーザー側の操作がEVMに実装されているようです。しかし、これらの操作の最終結果とデータは、他のCosmosモジュールにまだ保存されています。したがって、このEVM互換性は、基本的にボトムデータのマッピングです。
したがって、このマッピング関係は、他のVMに拡張することもできます。
>
これは、VMwareを使用してWindows仮想マシンを起動することに似ています。VMwareは、仮想マシン内の仮想ハードドライブにアクセスするだけでなく、物理的なコンピューターハードディスクにもアクセスできます。現時点でMac仮想マシンを起動すると、物理ディスクにデータを同じ方法でマウントすることもできます。このようにして、多くの仮想マシンが同じ世界のリソースとステータスを共有しています。
>
Tabiチェーンの主なサービスは、この形式の世界状態共有を使用します。したがって、対応するVMへの適応がある限り、VMに基づいて開発されたDAPPは、別のサービスではなくメインサービスに直接展開することを選択できます。
独立した世界の地位：さまざまなアプリケーションとゲームのニーズがさまざまであるため、一部のゲームには操作がカスタマイズされており、すべてのVMが「世界ステータス」を介してPolymorphism VMに統一されています。したがって、独立した世界の状態も必要です。この実装方法は比較的単純であり、データに完全に反対しています。
しかし、どんな形であっても、スーパーバイザーノードによって検証する必要があります。つまり、多型VMにはすべての実装方法VMまたはランタイムが含まれています。
Web2ゲーム移植ケース
多型VMは、特にWeb2開発者にとって高度にカスタマイズされています。おなじみの言語とフレームワークを使用して、あらゆるビジネスロジックを多型VMに移植できます。
MinecraftがTabiに移植したいと仮定すると、一般的なプロセスは次のとおりです。
-
Minecraft Service Side Code（Java、その他の言語）をわずかに変更し、チェーン上にある必要があるデータをデータベース（または1つのグループ）に移動し、DBを変更する可能性のあるすべての機能を配置します（つまり、状態は状態です。変換機能）も選択されました。
-
データベースとこれらの機能をJARパッケージとして梱包することは、Javaの実行可能なプログラムとして理解できます。最後に、プラスJREはJavaの運用環境です。これは全体として多型VMにロードされ、そのすべてのデータは最終的にチェーンになります。
-
サーバーで実行されない他のバックエンドロジック（チーム、チャットなど）を実行します。
-
TABIチェーンでサービスを開始し、スーパーバイザーノードの多型VMに通知して、同じJREをロードします。
-
ワールドデータベース（ワールドDB）ブロックチェーンに記録する必要があるすべてのユーザーデータが含まれています。これらのデータは価値があり重要である必要があるため、ブロックチェーンに似た構造がその可用性を確保するために必要です。したがって、すべてのデータをブロックチェーンに記録する必要があるわけではありません。たとえば、ゲームでは、ユーザーのチャットコンテンツは一般に重要ではなく、破棄することができるため、ブロックチェーンに配置する必要はありません。
-
完全な世界状態を表現できます。ゲーム内などの多くのシナリオでは、この表現は必ずしも高いレベルのトレーサビリティを意味するわけではありません。つまり、単純なアキュムレータで十分です。つまり、メルケルツリーのようなデータ構造が常に必要であるとは限りません。ただし、どのデータ構造が世界の状態を表すために使用されていても、世界データベースの世界の状態を抽象として表現できることが重要です。
-
世界データベースの変更を引き起こす可能性のある関数は呼び出されますステータス変換関数州の変換中にカプセル化する必要があります。実行に加えて世界データベースの変更は、違法で拒否されると見なされる必要があります。
-
入力および出力インターフェイスは、入力インタープリターとブロック提案者の設計と一致している必要があります。これは比較的簡単であり、ここでは詳細な説明をしていません。
-
UID：一意のユーザーを表します。これは、公開鍵または他の識別子になる可能性があります。
-
NONCE：オーバーライド攻撃を防ぐために使用されます。
-
追加のデータフィールド：あらゆるタイプのデータ。
>
これまでのところ、すべてのプロセスは終了しています。
開発者の場合、これらの変更は元のJava言語とフレームワークの下で完了します。他の開発ゲームにも同じことが言えます。ユーザーの場合、ゲームの相互作用は大幅に変更されていません。明らかに、Web2ゲームを移植するこの方法は非常に高速で効率的であり、Web3ゲームの大衆採用の基本的なパラダイムになる可能性があります。
ゲームSTRステータス変換機能の詳細
上記の例は、Web2ゲーム移植の一般的なプロセスです。また、詳細についてさらに学ぶ必要があります。今回は、特定のゲームの例ではなく共通の例を使用して、実行中のレイヤーに関係する詳細を表示します。
基本的に、カスタマイズされたゲームの操作環境は、Tabiの状態遷移ランタイムと呼ばれるブロックチェーンでゲームを作成する状態マシンと見なすことができます。
>
STRは、バイナリまたはモジュールによって多型VMに統合できます。
同様のブロックチェーンシステムでは、入力の透明性、状態変換のオープンな可視性、およびグローバル状態の表現能力を確保する必要があります。これらのニーズを満たすために、次の特性を構築する必要があります。
次の組織構造は、STRの重要なコンテンツです。Tabiは、開発者がこの実行を行うように促進するSDKをデフォルトで提供します。
ワールドdb
実際には、ゲームやアプリケーションは複数のデータベースを使用する可能性が高く、これらのデータベースは異なるタイプになる可能性があります。特定のゲームがリレーショナルデータベースとキー値データベースを同時に使用していると仮定しましょう。
以下は、単純な関係データベースの例です。
>
これは単純なキー値データベースです。
>
ステータス変換関数
これは、単純な状態変換関数です。この関数がユーザーの入力を受信すると、単純に5を掛けて、リレーショナルデータベースのデータを変更します。
>
世界のアキュムレータ
私たちは、世界の状態を表すために非常に単純なハッシュ疲労を構築することができます：
a_s + 1 = hash（a_s + hash（query））
この構造を通じて、世界データベースの変更後、その変更操作に対応するために常に唯一の決定的な状態があることを保証できます。
これは、この方法を各状態変換関数に実装する必要があることを意味することに注意する必要があります。この要件は、言語に固有の修飾子、インターフェイス、フック、またはその他のロジックを使用して実装を強制することができます。異なる言語には異なる特性があるため、ここでは具体的な詳細については説明しません。
Key -Valueデータベース（KVDB）の更新プロセスは同じです。
乱数
状態変換関数には乱数がないはずです。そうしないと、異なる結果が検証中に異なる結果を引き起こし、一貫性が導かれます。乱数は、システム入力パラメーターに含める必要があります。
要約します
上記の2つの例により、Tabi Chainのすべてのアラウンド実行レイヤーがモジュール式の方法でゲーム開発者に大きな柔軟性を提供することがわかります。ここですべての詳細を議論することはできないため、上記のコアコンテンツは、Tabiチェーンの解決策を実証するのに十分であり、非常に実用的で斬新です。
元のWeb3システムでは、さまざまなチェーンで開発された作業は、基本的にWeb3を入力したいと考えています理解の。
Tabiでは、開発者は元の言語、開発プラットフォーム、およびエンジンを使用しています。この効率の改善と複雑さの減少は、インデックスレベルです。
Web3ゲームの大規模な採用、Web2の優れたゲーム開発者を引き付け、実際のエンターテイメントの価値とプレイ可能性をWeb3をもたらすことを楽しみにしています。
