先までは、"和記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。概念設計としてはひとまず終えた。次は、フェデレーションモデル全体の基本設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。そして、それにつながるDApps側である「和記システム」を、Pythonプログラムで開発していきたい。
では、DApps側での設計の続きを記載していこう。和記システムを設計するための基本手順を以下に示す。このシステムは、Pythonを用いて市町村のブロックチェーンと連携し、個人および市町村単位での和の行動のデータを収集、記録し、決算書（PL、BS）として公表するものである。
基本設計のステップ
- 要件定義
- アーキテクチャ設計
- データベース設計
- API設計
- ブロックチェーンインターフェース
- 決算書の生成
- フロントエンド開発
- テストとデプロイ
基本設計の各ステップを順番に進めることで、ブロックチェーンとDAppsとして繋がる「和記システム」の詳細な設計が可能になる。各ステップでは、関係者との協議やレビューを通じて設計内容を確定していくことが重要である。
2．アーキテクチャ設計
ブロックチェーンにおいて、なぜブロックにする必要あるのか？なお、suiはブロックにせず、トランザクションのままをオブジェクトにしてDAGにて処理している。私のフェデレーションモデルにおいて、suiを真似したアルゴリズムを独自設計して実装したい。一つずつやってみよう。
今回は、MongoDBにて完了トランザクションを保持しているのに、なんでgossipにする必要あるのかを検証したい。suiやほかのDAGシステムたちはDAGだけで保存している。gossipって、もしかしてブロックチェーンたちがやってる古い技術なのかもしれない。私のフェデレーションモデルにおいて、本当に必要なのかを検証したい。
フェデレーションモデルにおけるGossipの必要性を再評価
Gossipによる分散保持が本当に必要なのか？ という点を根本的に考え直す。
1️⃣ Gossipは本当に必要なのか？
✅ Gossipとは何か？
Gossipプロトコルは、情報をノード間で効率よく伝播させる 方法で、ブロックチェーンのP2Pネットワークなどでよく使われる。例えば、BitcoinやEthereum では、新しいブロックやトランザクションをノード間でGossipを使って拡散している。
✅ じゃあ、DAGシステム（Suiなど）はどうしている？
Suiや他のDAGベースのシステムは、GossipではなくDAG自体をデータ保存の基盤 にしている。
つまり：
- DAGにデータを保存し、DAGの同期を通じて情報を伝播
- ブロックチェーンのようにGossipで分散する必要がない
✅ フェデレーションモデルではどうするべきか？
私のフェデレーションモデルにおいても、DAGが未完トランザクションと完了トランザクションの両方を保持 するなら、Gossipは不要になる可能性が高い。
2️⃣ Gossipの役割をフェデレーションモデルで考える
| フェーズ | DAGだけで処理する場合 | Gossipを使う場合 |
|---|---|---|
| 送信 | DAGに未完トランザクションを保存 | Gossipを使って送信者のノードから周辺ノードへ拡散 |
| 承認待ち | DAG上で承認プロセスを管理 | Gossipで未承認データを周辺ノードに拡散 |
| 承認完了 | DAG上で状態を「完了」に変更し、そのまま保存 | Gossipを使って完了データを拡散 |
| データ共有 | DAGの同期でデータを全ノードに広める | Gossipを使って一部のノードにコピーし、分散保存 |
結論: DAGの同期を適切に管理すれば、Gossipでデータを広める必要がなくなる！
3️⃣ なぜ他のDAGシステム（Suiなど）はGossipを使わないのか？
DAGシステムでは、トランザクションの追加と同期をDAG自身が管理 するため、Gossipを使わずとも、DAGのデータ構造の中で自然に情報が伝播 する。
例えば：
- Sui はオブジェクトベースのDAGを使い、トランザクションの承認をDAG内の関係性を使って行う
- IOTA（Tangle） は、新しいトランザクションが既存のDAG内の2つの過去トランザクションを承認することで、ネットワーク内の同期が自然に進む
- Avalanche も、DAGのコンセンサスに基づいてトランザクションを確定するため、Gossipを使わずにDAG自身で情報を管理
4️⃣ 私のフェデレーションモデルにおける最適解
💡 Gossipは不要。DAGがすべてのデータを管理する
あなたのフェデレーションモデルでは：
- 未完トランザクションはDAGに保存
- 完了トランザクションもDAGに保存し、DAG自体をMongoDB & immuDBと連携させる
- Gossipを使わず、DAGの同期メカニズムを強化することで、情報の伝播を管理する
📌 最適なデータ保存戦略
| データ種別 | 保存方法 | 目的 |
|---|---|---|
| 未完トランザクション | DAGに分散保存 | 受信者の承認待ち |
| 完了トランザクション | DAGに分散保存 + MongoDB（市町村）+ immuDB（大陸・グローバル） | 履歴管理と検索 |
| DAGの同期メカニズム | DAGノード間で直接同期（Gossipなし） | ネットワークのオーバーヘッドを削減 |
5️⃣ DAGによる同期メカニズムの強化
Gossipを使わず、DAG自身が自然に同期を進める方法を実装する必要がある。
✅ DAGノードの自動同期
- 各ノードは定期的にDAG全体をスキャンし、新しいトランザクションを取得
- 未完トランザクションが承認されたら、DAGの状態を更新
- 新しいDAGノードをネットワークに追加する際、自動で最新のDAGデータを取得
PythonでのDAG同期メカニズム
class DAG:
def __init__(self):
self.nodes = {} # トランザクションノードを保存
self.peers = [] # 他のノード情報
def add_node(self, tx_id, sender, receiver, status="pending"):
self.nodes[tx_id] = {"sender": sender, "receiver": receiver, "status": status}
def sync_with_peers(self):
for peer in self.peers:
new_data = peer.request_dag_data()
self.nodes.update(new_data) # 新しいDAGデータを取得
def finalize_transaction(self, tx_id):
if tx_id in self.nodes:
self.nodes[tx_id]["status"] = "completed"
この方法なら、Gossipを使わなくてもDAGノード間でデータが自然に同期される！
6️⃣ まとめ
✅ フェデレーションモデルではGossipは不要！
✅ DAG自体が同期の役割を持つため、自然に情報が伝播する
✅ 完了トランザクションもDAGに保存し、DAGとMongoDB / immuDBを連携させる
✅ DAGノードの自動同期機能を実装し、Gossipの代わりにDAGのメカニズムを強化
結論：Gossipは不要！DAGとDBの組み合わせで最適な設計に！
次のステップ
- DAGノード間の同期メカニズムを設計・実装
- MongoDBとimmuDBの連携を強化し、DAGが完了トランザクションを管理
- DAGの分散保存と復元スピードをテストし、1秒以内の処理を目指す
これでGossipを排除し、DAGを最大限活用する設計になった！
いかがであろうか、gossipアルゴリズムが不要になったので、とてもスッキリした。