Solidity x ECSパターンとMUD #Ethereum

この記事では、Latticeが開発した「MUD」フレームワークを用いて、SolidityにおけるEntity Component System（ECS）を実現する方法について探ります。

MUDは、ECSを組み込んだ革新的なSolidityフレームワークで、コントラクト設計に新たな視点を提供します。また、Diamond Proxyパターン（EIP2535）を知っていると、より理解が深まると思います。MUDはDiamond Proxyと似ている部分があります。

MUD: https://mud.dev/
DiamondProxy: https://eips.ethereum.org/EIPS/eip-2535

ECSとは？

ECSはゲーム開発から派生したソフトウェアアーキテクチャのパラダイムで、「継承」よりも「構成」を重視します（Composition over inheritance）。Solidityコントラクトの継承の複雑さに対処し、個々のComponentとロジックを用いてモジュラーな設計を促進します。

Entity：オブジェクトを表すID。
Component：テーブルのような構造化されたデータ。
System：ロジック。

この説明だけだとわかりづらいと思うので、実際の使われ方を見てみましょう。

MUDにおけるECSの活用

MUDには多くの機能が存在しますが、Store機能を見ると、ECSがどのように活用されるかが明確になります。

1: レイアウトの設定：mud.configでテーブルレイアウトを定義し、EntityとComponentの構造を指定します。

//Positionテーブルを定義
Position: {
  valueSchema: {
    x: "uint32",
    y: "uint32",
  },
  ...

2: EntityとComponentの作成：MUDのCLIツールを使用して、mud.configに基づきEntity IDとComponentを生成します。

//定義ファイルよりEntityとComponentが生成される

//Entity ID
bytes32 constant _tableId = bytes32(abi.encodePacked(bytes16(""), bytes16("Position")));
bytes32 constant PositionTableId = _tableId;

//Component
struct PositionData {
  uint32 x;
  uint32 y;
}

library Position {
  function getX() internal view returns (uint32 x) {
...

同時にgetter/setterが定義されたライブラリが出力されます。

3: Systemコントラクトの開発：Systemコントラクトはテーブルのデータを扱います。

//Systemコントラクトからテーブルのデータにアクセスする
import { PositionTable } from "../codegen/index.sol";

contract PositionSystem is System {
  function move(uint32 x, uint32 y) public {
    PositionTable.set(x, y);
  }
}

実際には、ユーザーはWorldコントラクトを介して取引し、Systemコントラクトとのやり取りにはdelegateCallを使用します。これによりすべてのデータはWorldコントラクトのストレージスロット内に保持されます。

MUDアーキテクチャ図

上記の図より、コントラクト全体が複雑になった場合でも、多重継承ではなく、並列にコンポーネントを並べていく設計思想が読み取れると思います。

MUDとDiamondProxyの比較

MUDとDiamondProxyパターンは、delegateCallの使用とストレージの分離という点で類似しています。

DiamondProxyパターン

ただ、両者は目的が異なります。DiamondProxyはファンクションの追加やアップグレードに焦点を当てているのに対し、MUDはECSを用いたコントラクトの構造化に重点を置いています。

また、MUDはDiamondProxyに比べて多くのコントラクトを含んでおり、その複雑さが特徴です。この複雑さを踏まえると、ECSを維持しつつ構造をシンプルにする新しい軽量フレームワークの開発が考えられます。このようなフレームワークは、自動生成されるComponentコントラクトとシンプルなStoreコントラクトから成る可能性があります。

おわりに

MUDフレームワークはSolidityにおいてECSを実装するためのユニークな方法を提供しますが、その複雑さから、もっとシンプルで軽量なフレームワークが同様に効果的である可能性があります。

もしこの考えに賛同し、協力や議論をしてくれるエンジニアの方がいたら、お気軽にご連絡ください。

Github（作成中）