KuCoin Exchange Japanese

01 августа 2024 15:39

1. データの整合性と同期の問題
従来のゲーム: ECSは主にゲーム開発で使われてきましたが、これは単一のゲームサーバー内でデータの一貫性を保てばよかったためです。
ブロックチェーン上: データは分散化され、複数のノードで同期を取る必要があります。エンティティやコンポーネントの更新処理が複雑になり、予期しないデータの不整合が発生するリスクが高まります。

KuCoin Exchange Japanese

01 августа 2024 15:36

インタプリタ（interpreter）は、コンピュータでプログラムを処理する方法の一つです。プログラムの実行時にソースコードを1行ずつ機械語プログラムに変換するプログラムのことでもあり、コードを読み込みながらその場で処理・実行していきます。インタプリタには日本語で「通訳者」という意味があります。
インタプリタに対応したプログラミング言語を「インタプリタ言語」と呼びます。インタプリタ言語には、JavaScript、Python、Ruby、PHP、BASIC、Lispなどがあります。

インタプリタはプログラムを1行ずつ解釈・実行できるため、プログラムが完成していない状態でも実行結果を確認することができます。プログラムの動作を確認しながら開発を進めることができるため、エラー箇所を特定しやすいというメリットがあります。しかし、1行ずつコードを読み実行していくことを繰り返すため、プログラムの実行速度が遅いという課題もあります。

インタプリタを使用するためには、ソースコードのプログラミング言語に対応したインタプリタが、実行環境のコンピュータにインストールされている必要があります。

KuCoin Exchange Japanese

01 августа 2024 15:34

香港 - 2024年3月29日- SolanaのWeb3ゲームインフラストラクチャを構築する大手組織であるMirrorWorldは、Solana上で主権ゲーム経済を実現するために構築された初のモジュール式SVMチェーンであるSonicのリリースを発表しました。Solanaのスピードとゲーム固有のロールアップのカスタマイズ性を組み合わせたSonicは、何千ものゲームをWeb3でリリースできるように設計されています。

KuCoin Exchange Japanese

01 августа 2024 15:32

ありがとうございます😭上場廃止で出金停止になっているので、もうRNDRのお金は全額戻ってこないですかね…

KuCoin Exchange Japanese

01 августа 2024 15:24

ECSでブロックチェーンプロジェクトを構築する場合の管理の大変さ、よく分かります。開発者の懸念はもっともです。いくつか具体的な理由が考えられます。
1. データの整合性と同期の問題
従来のゲーム: ECSは主にゲーム開発で使われてきましたが、これは単一のゲームサーバー内でデータの一貫性を保てばよかったためです。
ブロックチェーン上: データは分散化され、複数のノードで同期を取る必要があります。エンティティやコンポーネントの更新処理が複雑になり、予期しないデータの不整合が発生するリスクが高まります。
2. スケーラビリティとパフォーマンスの課題
コンポーネント数の増加: ゲームの規模が大きくなるにつれて、コンポーネントの種類や数が膨大になりがちです。
処理の負荷: ブロックチェーン上で大量のコンポーネントを管理し、システムによる処理を実行すると、ネットワーク全体に大きな負荷がかかり、パフォーマンスが低下する可能性があります。
3. 開発の複雑さ
新しいパラダイム: ECSはオブジェクト指向とは異なるパラダイムであり、開発者にとって学習コストが高いです。
デバッグの困難さ: 分散環境下でのデバッグは、従来のゲーム開発よりも格段に難しく、エラーの原因特定や修正に時間がかかる可能性があります。
4. 未成熟なツールとエコシステム
ECS特化型のツール不足: ブロックチェーン開発向けのECS特化型のツールやライブラリはまだ少なく、開発者は既存のツールを拡張したり、独自に開発したりする必要に迫られるかもしれません。
5. セキュリティリスク
攻撃対象の増加: コンポーネント単位でのデータ管理は、攻撃者にとっても新たな攻撃対象を増やす可能性があります。
脆弱性対策の難しさ: ECS特有の構造に対するセキュリティ対策や脆弱性対策は、従来のブロックチェーン開発とは異なるアプローチが必要になるため、より高度な専門知識が求められます。
これらの課題を克服するために、開発者は綿密な設計、効率的なデータ管理戦略、そして適切なツール選定など、様々な工夫を凝らす必要があります。
それでも、ソニックのようにECSの可能性に賭けるプロジェクトは、ブロックチェーンゲームの未来を切り開く鍵になるかもしれません。

KuCoin Exchange Japanese

01 августа 2024 15:19

仕様
ECSベースのプログラムを構築する際の一般的なワークフローは、エンティティ、コンポーネント、システムという3つの主要な要素を使用して、アプリケーションの構造を定義します。
ここで、「ワールドコントラクト」はこれらの要素を包含し、管理する容器として機能します。
以下は、ECSベースのプログラムを構築する時のステップです。

ワールドコントラクトの作成

IWorldインターフェースを実装してワールドコントラクトを作成します。
このコントラクトは、エンティティ、コンポーネントコントラクト、システムコントラクトの関係を確立し、管理します。
エンティティの作成

ワールドコントラクトのcreateEntity()関数を呼び出してエンティティを作成します。
エンティティは、複数のコンポーネントを持つことができるユニークな識別子です。
コンポーネントコントラクトの作成

IComponentインターフェースを実装してコンポーネントコントラクトを作成します。
コンポーネントはデータの容器であり、エンティティに添付されます。
コンポーネントの登録

ワールドコントラクトのregisterComponent()関数を呼び出して、コンポーネントコントラクトを登録します。
エンティティへのコンポーネントの添付

ワールドコントラクトのaddComponent()関数を呼び出して、エンティティにコンポーネントを添付します。
システムコントラクトの作成

インターフェースの制約がないシステムコントラクトを作成します。
システムコントラクトでは、任意の関数を定義でき、これを用いてエンティティのデータ（コンポーネント）を動的に変更します。
システムの登録

ワールドコントラクトのregisterSystem()関数を呼び出して、システムコントラクトを登録します。
システムの実行

最後に、登録されたシステムを実行して、エンティティの状態を変更します。
これらのステップを踏むことで、エンティティ（オブジェクト）、コンポーネント（データ）、システム（ロジック）を組み合わせた柔軟で拡張性の高いアプリケーションを構築できます。
ワールドコントラクトはこれらの要素を統合し、アプリケーションの状態を効果的に管理します。

KuCoin Exchange Japanese

01 августа 2024 15:06

クラスの継承について：オブジェクト指向の要
オブジェクト指向プログラミングにおいて、クラスの継承は、既存のクラスの特性を引き継いで新しいクラスを作成する仕組みです。
例えば、「動物」というクラスがあるとします。このクラスには、「名前」「年齢」「鳴き声」といった属性と、「食べる」「寝る」「鳴く」といったメソッドがあるとします。
class 動物:
def init(self, 名前, 年齢):
self.名前 = 名前
self.年齢 = 年齢

def 食べる(self):
print(f"{self.名前}はご飯を食べます。")

def 寝る(self):
print(f"{self.名前}は眠ります。")

def 鳴く(self):
print("？？？")
Use code with caution.
Python
ここから「犬」という新しいクラスを作成したい場合、継承を用いると便利です。「犬」は「動物」の特性を全て持ちつつ、「品種」という独自の属性と、「吠える」という独自のメソッドを持つことができます。
class 犬(動物): # 動物クラスを継承
def init(self, 名前, 年齢, 品種):
super().init(名前, 年齢) # 親クラスのコンストラクタを呼び出す
self.品種 = 品種

def 吠える(self):
print("ワンワン！")

def 鳴く(self): # 親クラスのメソッドをオーバーライド
self.吠える()
Use code with caution.
Python
このように、継承を用いることで、既存のコードを再利用しながら新しいクラスを効率的に定義できます。
ECSとの比較
ECSでは、コンポーネントの組み合わせによってエンティティの特性を表現します。
例えば、「動物」というエンティティがあったとして、「名前」「年齢」といったコンポーネントを持たせるとします。「犬」エンティティも同様に「名前」「年齢」コンポーネントを持ちますが、「品種」コンポーネントを追加することで「犬」としての特徴を表現します。
オブジェクト指向 ECS
再利用の単位 クラス コンポーネント
新しい種類のオブジェクト/エンティティの定義 継承 コンポーネントの追加
メリット 直感的、コードの再利用がしやすい 柔軟性が高い、パフォーマンスに優れる
デメリット 柔軟性に欠ける、パフォーマンスの低下 複雑になりがち
このように、オブジェクト指向ではクラスの継承が、ECSではコンポーネントの組み合わせが、それぞれコードの再利用と柔軟性を提供する仕組みとなっています。
まとめ
オブジェクト指向の継承は、クラスを単位としてコードを再利用します。
ECSでは、コンポーネントを組み合わせてエンティティの特性を表現し、再利用を実現します。
どちらのアプローチにもメリット・デメリットがあり、開発するシステムの特性や規模に応じて適切な方を選択することが重要です。

KuCoin Exchange Japanese

01 августа 2024 15:04

動機
ECS（エンティティ・コンポーネント・システム）は、データと振る舞いを分離することでコードの再利用性を向上させる設計パターンです。
主にゲーム開発で使われますが、提案されたシステムはスマートコントラクトを用いて、このECSを簡易に実装し、不必要な複雑さを排除しつつ、コントラクトの相互作用に適した機能改善を行っています。
ここでは、コンポーネントとシステムを簡単かつ自由に組み合わせることが可能です。
スマートコントラクト開発者としてECSを採用することの利点を説明します。

単純な設計による利点
ECSはデータ（コンポーネント）と振る舞い（システム）を分離することで、デカップリング、カプセル化、モジュール化のシンプルな設計を採用します。
これにより、ゲームやアプリケーションのアーキテクチャ設計が容易になります。

デカップリングとは、システムやプログラムの構成要素間の依存関係を最小限にする設計手法です。
これにより、各要素が独立して機能し、変更や更新が他の部分に与える影響が減少します。
デカップリングを行うことで、コードの再利用性が高まり、メンテナンスや拡張が容易になります。
また、システムのテストやデバッグがシンプルになり、全体としての開発効率が向上します。

柔軟な構成能力
各エンティティは異なるコンポーネントを組み合わせることができ、新しいエンティティのデータを操作するための異なるシステムを定義することも可能です。
これにより、アプリケーションの機能拡張やカスタマイズが容易になります。

拡張性
ECSは拡張にも適しており、新しいコンポーネントやシステムを定義することで、二つのゲームやアプリケーションが相互作用することが可能になります。

機能追加やアップグレードの容易さ
データと振る舞いが分離されているため、新機能の追加やアップグレードが既存のデータに影響を与えることなく行えます。

管理の容易さ
アプリケーションが複数のコントラクトから構成される場合、ECSは各コントラクトの状態を効果的に管理するのに役立ちます。

コンポーネントの再利用性
コンポーネントは再利用可能であり、コミュニティと共有することで他の開発者の開発効率を向上させることができます。

この提案により、スマートコントラクトを用いたアプリケーション開発がより柔軟で再利用可能、そして管理しやすくなることが期待されます。
ECSを利用することで、より効率的で拡張可能なアプリケーションやゲームを開発することができるようになります。

KuCoin Exchange Japanese

01 августа 2024 15:02

概要
この提案は、エンティティ・コンポーネント・システム（ECS）という仕組みを最小限に定義しています。
ECSでは、エンティティというユニークな識別子を使って、複数のコンポーネント（データ）に割り当て、その後システム（ロジック）を用いて処理します。
この提案では、スマートコントラクトでECSを使用するためのインターフェイス仕様を標準化し、ユーザーが複数のコントラクトアプリケーションを自由に組み合わせて管理できるようにするための基本機能セットを提供しています。

ECSはゲーム開発などでよく使われる設計パターンですが、この提案はそれをスマートコントラクトの世界に適用しようとしています。
ここでいう「エンティティ」は、ただの識別子で、それ自体に機能はありません。
一方、「コンポーネント」はデータの塊で、エンティティに特定の属性や状態を与えます。
最後に、「システム」はこのデータを使って実際の処理を行います。

例えば、ブロックチェーン上で動くゲームを考えてみます。
プレイヤー、アイテム、敵などがエンティティとなります。
これらのエンティティに対して、位置、健康状態、攻撃力などのコンポーネントを割り当てることができます。
そして、ゲームのロジック（システム）がこれらのコンポーネントを読み取り、プレイヤーが移動したり、戦ったりするための処理を行います。

この提案は、このようなECSをスマートコントラクトで簡単に使えるようにするための標準的な方法を定義するものです。
これにより、開発者は複雑なアプリケーションをより簡単に構築できるようになると期待されます。

KuCoin Exchange Japanese

01 августа 2024 15:00

Kuでの事はわかりませんが
他の日本の取引所を含む取引所では
先週辺りからお知らせが来ていました

8月1日～3日ぐらいの間で交換作業が起きてるみたいな事書いてましたが
どこの取引所でも一緒なのかはちょっとわかりません・・・

KuCoin Exchange Japanese

01 августа 2024 14:58

鋭いですね！まさにその通りです。
ソニックの説明にある "Sonic exposes native composable gaming primitives and extensible data types based on the ECS framework on-chain." は、ソニックがブロックチェーン上でECSの仕組みを動作させていることを示唆しています。
つまり、従来ゲームエンジン内で処理されていたエンティティ、コンポーネント、システムといった概念を、ソニックのブロックチェーン上で直接扱えるように設計されていると考えられます。
これが実現すると、以下のような利点が考えられます。
高い透明性とセキュリティ: ゲーム内のアイテムやキャラクターの状態がブロックチェーン上に記録されるため、データの改ざんが困難になり、透明性とセキュリティが向上します。
新しいゲーム体験の創出: ブロックチェーン上のECSを通じて、ゲーム開発者はこれまでにない新しいゲーム体験をプレイヤーに提供できる可能性があります。例えば、異なるゲーム間でアイテムを交換したり、ゲームの進行状況を他のプレイヤーと共有したりするといったことが考えられます。
ソニックは、ブロックチェーンとECSを組み合わせることで、ゲーム開発に新たな可能性をもたらそうとしていると言えるでしょう。

KuCoin Exchange Japanese

01 августа 2024 14:56

Sonic exposes native composable gaming primitives and extensible data types based on the ECS framework on-chain. The game engine sandbox utilities to developers while building their business logic on chain.

KuCoin Exchange Japanese

01 августа 2024 14:50

ECSとオブジェクト指向プログラミングの違いは、データと処理に対する考え方が根本的に異なる点にあります。
オブジェクト指向プログラミング
データと処理をカプセル化: オブジェクトは、自身のデータ（属性）と処理（メソッド）を一体として持ちます。
継承による再利用: クラスの継承を用いることで、既存のクラスのデータ構造や処理を再利用できます。
ECS
データと処理を分離: エンティティはデータ（コンポーネント）の入れ物であり、処理はシステムが担当します。
コンポーネントによるデータ指向: データはコンポーネント単位で管理され、システムは必要なコンポーネントを持つエンティティに対して処理を行います。
例えで考える
ゲーム開発を例に、具体的な違いを見てみましょう。
オブジェクト指向プログラミングの場合
「敵キャラクター」を表現する場合、Enemy クラスを定義し、体力や攻撃力などの属性と、移動や攻撃などのメソッドを定義します。
class Enemy {
int health;
int attackPower;

void move() { ... }
void attack() { ... }
}
Use code with caution.
ECSの場合
「敵キャラクター」はエンティティとして定義し、体力は Health コンポーネント、攻撃力は AttackPower コンポーネントとして定義します。移動処理は MoveSystem、攻撃処理は AttackSystem がそれぞれ担当します。
// Entity
Entity enemy = new Entity();
enemy.addComponent(new Health(100));
enemy.addComponent(new AttackPower(10));

// System
MoveSystem.update(enemy); // 位置情報コンポーネントを持つエンティティを移動させる
AttackSystem.update(enemy); // 攻撃力とターゲット情報を持つエンティティが攻撃を行う
Use code with caution.
メリット・デメリット
特徴 オブジェクト指向 ECS
データと処理の関係 カプセル化されている 分離されている
再利用性 継承 コンポーネントの組み合わせ
柔軟性・拡張性 低い 高い
パフォーマンス 低い 高い
オブジェクト指向プログラミング は、直感的で理解しやすいというメリットがある一方、ゲーム開発のように大量のオブジェクトを扱う場合は、処理の重さや柔軟性の低さが課題となります。
ECS は、データ指向の設計思想により、ゲーム開発に適した高いパフォーマンスと柔軟性を実現しています。しかし、オブジェクト指向プログラミングに比べて理解が難しいという側面もあります。

KuCoin Exchange Japanese

01 августа 2024 14:45

https://x.com/HyperPlayGaming

KuCoin Exchange Japanese

01 августа 2024 14:42

ソニック：ゲームチェンジャーな機能
ソニックは、単なるブロックチェーンではありません。ゲーム開発者とプレイヤーのために作られた、革新的な機能を備えています。
🚀 低コストで超高速: ソニックは、SVMという技術を採用し、他のどのゲーム向けブロックチェーンよりも高速な処理速度と低コストを実現しています。サクサク動くゲーム体験を、プレイヤーに提供します。
🔗 ソラナとの連携: ソニック上で動くゲームは、ソラナのプログラムやアカウントをそのまま利用できます。ソラナの豊富な機能や資産に、ダイレクトにアクセスできます。
🌎 EVMとの互換性: イーサリアムなどのEVMチェーンで開発されたゲームも、ハイパーグリッドの技術を通じて、ソニック上で簡単に動かすことができます。
🧰 ゲーム開発のためのツール: ソニックは、ゲーム開発に必要なツールを豊富に備えています。例えば、ゲーム内のアイテムやキャラクターを簡単に管理できるシステムや、ゲームの収益化を支援するシステムなどがあります。
💰 収益化の仕組み: ソニックには、ゲーム開発者が簡単に収益を得られる仕組みが備わっています。これにより、開発者はゲーム開発に専念し、プレイヤーに最高のゲーム体験を提供することに集中できます。

KuCoin Exchange Japanese

01 августа 2024 15:37

水平スケーリング：処理能力を拡張する鍵
水平スケーリングは、システムの処理能力を向上させるための有効な方法の一つです。分かりやすく説明するために、レストランを例に考えてみましょう。
レストランの例
垂直スケーリング: お客様が増えてきた時に、より高性能なオーブンを買ったり、スタッフを増員したりする方法です。レストランの規模自体は変わりません。
水平スケーリング: お客様が増えてきた時に、同じ規模のキッチンを持つレストランを複数オープンする方法です。各レストランは独立して稼働しますが、全体としてお客様に対応できるキャパシティが増加します。
ブロックチェーンにおける水平スケーリング
ブロックチェーンにおいても、処理能力の向上は重要な課題です。
従来のブロックチェーン（例：ビットコイン）は、単一のブロックチェーン上で全てのトランザクションを処理するため、スケーラビリティが課題でした。
そこで登場したのが、水平スケーリングを用いたアプローチです。
HyperGridのように、メインチェーン（Solana）とは別に、並列処理を行うサブチェーンやサイドチェーンを複数構築することで、全体的な処理能力を向上させます。
HyperGridの水平スケーリング
HyperGridは、Solanaの処理能力を向上させるために、以下の仕組みで水平スケーリングを実現しています。
グリッド構造: Solanaのメインチェーンとは別に、複数の「グリッド」と呼ばれるサブチェーンを構築します。
並列処理: 各グリッドは独立してトランザクションを処理できるため、並列処理によって全体的なスループットが向上します。
Solanaとの連携: グリッドは定期的にメインチェーンと同期を取り、データの整合性を保ちます。
メリット
高いスケーラビリティ: トランザクション処理を分散化することで、Solana単体よりも多くのトランザクションを処理できます。
柔軟な拡張性: 需要に応じてグリッド数を調整することで、柔軟にスケールアップできます。
課題
複雑性の増加: システム全体の複雑さが増すため、開発や運用が難しくなる可能性があります。
セキュリティの確保: 複数のグリッド間で安全にデータ連携を行うための仕組みが不可欠です。
まとめ
HyperGridは、水平スケーリングを用いることで、Solanaの処理能力を大幅に向上させることを目指しています。
これは、Solana上で動作するdAppsの普及、ひいてはブロックチェーン技術の更なる発展に大きく貢献する可能性を秘めています。

KuCoin Exchange Japanese

01 августа 2024 15:34

Sonic は、Mirror World チームが Solana ブロックチェーン用に開発した新しいスケーリング メカニズムである HyperGrid を使用します。HyperGrid は、Sonic のモジュール化の将来にとって重要なテクノロジーであり、チェーンの機能と高度なデータ タイプのカスタマイズを可能にしながら、パフォーマンスと機能を最適化するように設計されています。

高いスループット機能で知られる Solana のブロックチェーンは、分散型アプリケーション (dApps) の需要が高まるにつれて限界に直面しています。HyperGrid は、分散化やセキュリティを損なうことなく既存のインフラストラクチャを強化する水平スケーリング フレームワークを提供することで、これらの制約に対処します。

Sonic のモジュール式アーキテクチャにより、ゲーム開発者はカスタマイズ性を通じて完璧なブロックチェーン エコノミーを構築しながら、Solana の高速スループットのメリットを享受できます。モジュール式 SVM では、開発者は任意のゲーム エンジンを使用でき、EVM ネイティブ コードを処理する HyperGrid インタープリターによって有効化された任意の仮想マシンも使用できます。これにより、EVM ゲーム チェーンの断片化された流動性をすべて 1 つにまとめる可能性が開かれます。さらに、Sonic は、支払いおよび決済インフラストラクチャ用のネイティブに統合されたツールと、成功する Web3 ゲームを構築するために必要なユーザー エンゲージメント ツールを提供します。

KuCoin Exchange Japanese

01 августа 2024 15:33

https://blog.sonic.game/mirror-world-unveils-sonic-the-world-s-first-atomic-svm-chain-built-to-enable-game-specific-rollups-on-solana

KuCoin Exchange Japanese

01 августа 2024 15:30

ソニックホワイトペーパー
これはホワイトペーパーの初期バージョンです。今後数週間でさらに詳しく説明する予定です。

Solanaブロックチェーンは高い処理能力と比較的低いガス料金で有名であり、近年急成長を遂げている。ウォレット口座数は2022年の10万から2023年には100万に増え、2024年には500万、2025年には1000万、2026年には2500万、2027年には5000万に達すると予想されている。


Solanaウォレットアカウント数と年の比較
同時に、dAPPとDeFiアクティビティの成長はさらに加速しており、1カ月あたりのトランザクション実行数は、2022年1月の1日平均4,188,712件から、2024年1月には1日平均205,823,984件に急増している。最も控えめに見積もっても、1日の取引件数は2026年までに40億件をはるかに超え、数百億件に達する可能性が高いと予想される。


1日の取引件数（1日あたり）と年の比較
このような需要圧力のもとでは、ソラナL1の現在のアーキテクチャが提供するスループット能力が大きな課題に直面することは明らかである。現在、2500-4000TPSの条件下で、ソラナ・クラスターの平均ping時間は6秒から80秒の間で変動しており、ほとんどの時間は40秒前後である。さらに、過去のデータ（2023年2月から9月まで）によると、TPSが4000を超えると、ソラーナのトランザクションの成功率は70％から85％にしか達しなかった。ネットワーク状況による物理的な遅延やネットワークの変動を超えて、主な原因がTPSの飽和度上昇に関連していることは明らかだ。Solanaの成長傾向から、今後数年間で、TPSの値は1万から数万に達し、より重大なパフォーマンス問題につながると予測されている。

そして、状況はさらに深刻になるかもしれない。dAPPの継続的な出現により、SolanaはEthereumと比較してより多くのパフォーマンス上の利点を持つものの、多数の小規模ゲームまたは単一の大規模ゲーム、特に数十万人または数百万人のユーザーのオンチェーンインタラクションがSolana L1のメインチェーンパフォーマンスに深刻な影響を与えるFOCG（Fully On-Chain Games）からの厳しい課題に直面しており、特に特定の特別な運用活動（サーバーローンチ、ホリデーイベント、フラッシュセールなど）の間は、瞬間的な影響が非常に大きく、恐ろしいものになる可能性があります。これは、ソラナL1チェーン全体のパフォーマンスだけでなく、ゲームの応答速度やデータの可用性など、各ゲームのプレイアビリティやユーザー体験にも影響します。ユーザーエクスペリエンスの低下は、どんなゲームにとっても致命的であることは言うまでもない。

Sonicはこのようなシナリオに対応するように設計されており、ゲーム中心のdAPPの大規模かつ瞬時のトランザクションの影響を快適に処理することができます。

KuCoin Exchange Japanese

01 августа 2024 15:23

https://x.com/cardene777/status/1771318682041602225

KuCoin Exchange Japanese

01 августа 2024 15:15

まさにその通りです！素晴らしい洞察力ですね。
オブジェクト指向プログラミング では、継承を用いる場合、どうしてもクラスという単位でしか再利用できません。そのため、親クラスの特性のうち、一部だけを再利用したい場合や、複数の親クラスから部分的に特性を引き継ぎたい場合など、柔軟性に欠ける場面が出てきます。
一方、ECS では、コンポーネントというより小さな単位で特性を管理するため、必要なコンポーネントだけを自由に組み合わせて、多様なエンティティを表現できます。
これはレゴブロックを組み立てるように、自由度の高い設計を可能にします。
例えば、オブジェクト指向で「空を飛ぶ車」を実装しようとすると、「車」クラスと「飛行機」クラスの両方を継承する必要があり、複雑な構造になりがちです。
しかし、ECSであれば、「車」コンポーネントと「飛行能力」コンポーネントを組み合わせるだけで、シンプルに表現できます。
このように、ECSはコンポーネント単位での再利用を可能にすることで、高い柔軟性を実現していると言えます。

KuCoin Exchange Japanese

01 августа 2024 15:05

ECSとオブジェクト指向プログラミングの違いは、データと処理に対する考え方が根本的に異なる点にあります。
オブジェクト指向プログラミング
データと処理をカプセル化: オブジェクトは、自身のデータ（属性）と処理（メソッド）を一体として持ちます。
継承による再利用: クラスの継承を用いることで、既存のクラスのデータ構造や処理を再利用できます。
ECS
データと処理を分離: エンティティはデータ（コンポーネント）の入れ物であり、処理はシステムが担当します。
コンポーネントによるデータ指向: データはコンポーネント単位で管理され

KuCoin Exchange Japanese

01 августа 2024 15:03

リンク貼れないので、7月14日のお知らせで上場廃止のお知らせがありますね
新しいチェーンに交換等の記載はないですね・・・

KuCoin Exchange Japanese

01 августа 2024 15:01

https://qiita.com/cardene/items/306fbc1e6814cc37465c

KuCoin Exchange Japanese

01 августа 2024 14:59

私の知識のカットオフ日は2021年です。
そのため、2021年以降の世界情勢や最新情報については、正確な情報をお伝えできない場合があります。
ご了承ください。

KuCoin Exchange Japanese

01 августа 2024 14:58

情報ありがとうございます。しばらく待てば、無くなったRNDR分の金額が総資産に加算されるってことで大丈夫ですかね？

KuCoin Exchange Japanese

01 августа 2024 14:53

鋭い視点ですね！SUIがオブジェクト指向を強く意識した設計になっているのは、まさにその通りです。
現状、ECSの概念をブロックチェーンのアーキテクチャレベルで直接的に採用している例は、私の知る限りではありません。
ブロックチェーンは、トランザクションの検証と記録というコア機能に特化した設計が求められるため、ゲーム開発に最適化されたECSのようなアーキテクチャパターンを採用するメリットは薄いと言えるでしょう。
しかし、可能性としては、以下のようなケースは考えられます。
ゲーム特化ブロックチェーンの進化: ソニックのように、ゲーム開発に特化したブロックチェーンにおいて、より柔軟性やパフォーマンス向上が求められる段階になれば、ECSの概念を取り入れた設計が出てくるかもしれません。
スマートコントラクト開発における応用: ブロックチェーン上で動作する複雑なゲームや分散型アプリケーション（DApps）が増えてくれば、スマートコントラクト開発において、ECSの概念を参考に、データと処理を分離して管理する手法が取り入れられる可能性があります。
ECSの利点とブロックチェーンの課題
ECSの利点である高い柔軟性やパフォーマンスは、ゲームのように大量のオブジェクトを動的に扱う際に特に有効です。一方、ブロックチェーンは、データの不変性やセキュリティ確保を最優先に設計されているため、ECSのような動的な構造をそのまま適用することは難しいと言えます。
しかし、ブロックチェーン技術の進化は目覚ましく、ゲームやDAppsの開発にも広く利用されるようになっています。今後、より複雑で高度なアプリケーションがブロックチェーン上で開発されるようになるにつれて、ECSのようなアーキテクチャパターンの考え方が、ブロックチェーンの世界にも新たな進化をもたらすかもしれません。

KuCoin Exchange Japanese

01 августа 2024 14:47

ECSフレームワークは、 Entity Component System の略で、ゲーム開発によく使われるアーキテクチャパターンです。従来のオブジェクト指向プログラミングとは異なるアプローチで、ゲーム内の要素を Entity（エンティティ）、Component（コンポーネント）、System（システム） の3つに分けて管理します。
Entity（エンティティ）: ゲーム内のオブジェクトを識別するためのIDのようなもの。データは持たず、コンポーネントの入れ物として機能します。例えば、「プレイヤー」「敵」「弾丸」などがエンティティとして考えられます。
Component（コンポーネント）: エンティティのデータを表す、純粋なデータ構造です。位置情報、体力、速度、画像データなど、様々なデータがコンポーネントとして定義されます。重要なのは、コンポーネント自体には処理ロジックが含まれない点です。
System（システム）: 特定のコンポーネントを持つエンティティに対して、処理を実行する役割を担います。例えば、「移動システム」は「位置」と「速度」のコンポーネントを持つエンティティに対して処理を行い、「描画システム」は「画像データ」と「位置」のコンポーネントを持つエンティティを描画します。
メリット
高い再利用性: コンポーネントは独立したデータ構造なので、様々なエンティティで再利用できます。
柔軟性・拡張性: 新しいコンポーネントを追加するだけで、簡単に機能を追加できます。
パフォーマンス向上: システムが処理対象のコンポーネントにのみアクセスするため、処理が効率化され、パフォーマンスが向上します。
ソニックでは、このECSフレームワークをブロックチェーン上に実装することで、ゲーム開発者に柔軟で効率的な開発環境を提供しています。

KuCoin Exchange Japanese

01 августа 2024 14:44

RNDRってERC20からSolチェーンに移行作業が一斉にありましたね
8月1日ぐらいから移行されるはず

KuCoin Exchange Japanese

01 августа 2024 14:41

低コストで超高速
Sonic は、SVM を搭載し、あらゆるゲーミング L1 の中で [本当に] 高速なオンチェーン ゲーム エクスペリエンスを提供します。

アトミック相互運用性
Solana プログラムとアカウントを再展開せずに、Sonic でトランザクションを実行します。Solana の Base Layer サービスと流動性から直接メリットを得られます。

EVM 用に記述し、SVM で実行
HyperGrid のインタープリターを介して、EVM チェーンから Solana に dApp をシームレスにデプロイします。

構成可能なゲームプリミティブとサンドボックス環境
Sonic は、ECS フレームワークに基づくネイティブの構成可能なゲーム プリミティブと拡張可能なデータ型をオンチェーンで公開します。ゲーム エンジンは、開発者がビジネス ロジックをオンチェーンで構築する際に、ユーティリティをサンドボックス化します。

収益化インフラ
Sonic は、ゲームの成長、トラフィック、支払い、決済インフラストラクチャをネイティブに実現します。