和記システムの基本設計：アーキテクチャ設計　DAGから分析までの全体設計改良 | 続・ティール組織　研究会のブログ
Amebaホームピグアメブロ
芸能人ブログ人気ブログ
新規登録
ログイン

続・ティール組織　研究会のブログ

ティール組織が話題になっているが、具現化するにはどうしたらよいか？
その研究を続けるにあたり、さらに次の形態である、続・ティール組織なるものまで視野に入れ、具体的な施策・行動内容を研究・支援する会。

和記システムの基本設計：アーキテクチャ設計　DAGから分析までの全体設計改良

先までは、"和記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。概念設計としてはひとまず終えた。次は、フェデレーションモデル全体の基本設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。そして、それにつながるDApps側である「和記システム」を、Pythonプログラムで開発していきたい。

 

では、DApps側での設計の続きを記載していこう。和記システムを設計するための基本手順を以下に示す。このシステムは、Pythonを用いて市町村のブロックチェーンと連携し、個人および市町村単位での和の行動のデータを収集、記録し、決算書（PL、BS）として公表するものである。

基本設計のステップ

  1. 要件定義
  2. アーキテクチャ設計
  3. データベース設計
  4. API設計
  5. ブロックチェーンインターフェース
  6. 決算書の生成
  7. フロントエンド開発
  8. テストとデプロイ

基本設計の各ステップを順番に進めることで、ブロックチェーンとDAppsとして繋がる「和記システム」の詳細な設計が可能になる。各ステップでは、関係者との協議やレビューを通じて設計内容を確定していくことが重要である。

 

2．アーキテクチャ設計

ブロックチェーンにおいて、なぜブロックにする必要あるのか？なお、suiはブロックにせず、トランザクションのままをオブジェクトにしてDAGにて処理している。私のフェデレーションモデルにおいて、suiを真似したアルゴリズムを独自設計して実装したい。一つずつやってみよう。

 

今回、DAGは未完トランザクション＋完了トランザクションを1秒だけ保持させる仕組みに変更したい。1秒後はバッチ処理で市町村のMongDBへ保存される仕組みにすれば超高速並列処理が保たれるだろう。完了トランザクションを保持は市町村単位ではMongoDBであり、大陸単位ではimmuDBでおこなう。ということは、MongoDBにて完了トランザクションを保持するのも6ヶ月程度の短期間のみで、あとはimmuDBへ引き継ぐので、結局は大陸immuDBとグローバルのimmuDBの2重持ちにて保証するという構図。コスト高になるのを工夫が必要だ。

 

また、分析でMongoDBを主につかうが、ここが改ざんされたりハッキングされたら、immuDBとの整合性がとれなくなくので、即時アラームがなるような仕組みにして、セキュリティをMongDBだけでは完璧と言えない抜け穴をもこれで塞ぐことにして、ぜったいにハッキングさせないし、されてもすぐに発覚して対処する方法を採用して、やりなおしてみたい。

 

以下に、「分析はMongoDBをメインとしつつ、immuDBとの整合性を常時検証してセキュリティを強化する」 設計を詳しく解説したい。MongoDBのデータが改ざんされても、immuDB（不変ストレージ）との検証で即時アラームを出す 方法を採用し、ハッキングのリスクを最小化する。

1. 全体像：DAG + MongoDB + immuDB + 整合性検証

  1. 市町村DAG

    • 未完トランザクションを1秒保持し、その後完了トランザクションとしてMongoDBへ移動
    • 並列処理によりトランザクション完了を超高速化

  2. MongoDB（市町村 & 大陸）

    • 分析用のメインDB。市町村は6ヶ月保持、大陸は長期保持
    • ハッキングや改ざんリスク があるため、immuDBとの整合性検証 で防御

  3. immuDB（大陸 ）

    • 不変ストレージ として改ざん検知用の ハッシュ情報 のみを保存
    • MongoDBデータをハッシュ化 し、immuDBに書き込む → 整合性検証で違反があれば即アラート

  4. リアルタイム整合性検証

    • MongoDBに保存したデータを定期 or 随時 で immuDB のハッシュ値と突合し、改ざんを検知
    • 検知時には即アラーム を発火し、対処する

2. 具体的なデータフロー

2.1 未完トランザクション（DAG）

  1. 送信者がTx作成 → 市町村DAG に保存
  2. 受信者が承認 → Tx状態=completed に更新
  3. 1秒後のバッチ でDAGから削除 → MongoDBへ移動

2.2 完了トランザクション（MongoDB + immuDB）

  1. MongoDBに保存（分析用）
  2. 同時に、Txレコードのハッシュ を作成し、immuDB に書き込む
    • immuDBに (tx_id, hash, timestamp, sign...) などを記録
  3. このハッシュを「不変」 として保持 → MongoDB 側のデータと比較可能

def insert_tx_mongodb(tx):
    # MongoDBに保存
    tx_id = completed_tx_collection.insert_one(tx).inserted_id
    
    # ハッシュをimmuDBに登録
    tx_hash = hashlib.sha256(str(tx).encode()).hexdigest()
    immu_client.set(str(tx_id), tx_hash.encode())

3. 整合性検証の仕組み

3.1 データ書き込み時にハッシュ登録

  • MongoDBへトランザクションを保存 するとき、同じタイミングで immuDB にハッシュ（もしくは署名）を保存
  • immuDBは改ざん防止機能を持つ → 書き込まれたハッシュは変更不可

3.2 データ取得 or 定期検証時

  • MongoDBからデータを取得 し、ハッシュを再計算
  • immuDBに保存されているハッシュと 一致するか 確認
  • 不一致なら改ざん疑い → 即アラーム

def verify_tx(tx_id):
    # 1) MongoDBから取得
    tx_record = completed_tx_collection.find_one({"_id": tx_id})
    if not tx_record:
        return False, "Record not found"
    
    # 2) ローカルハッシュ計算
    local_hash = hashlib.sha256(str(tx_record).encode()).hexdigest()

    # 3) immuDBに登録されているハッシュと比較
    immu_hash = immu_client.get(str(tx_id))  # 取得したvalueをデコード
    if local_hash == immu_hash.decode():
        return True, "OK"
    else:
        # 改ざん発覚 → アラーム発火
        trigger_alarm(tx_id)
        return False, "Hash mismatch!"

4. 改ざん検知後の対処（アラーム発火）

4.1 即時アラート & ロールバック

  • 不一致が見つかったら、セキュリティチームに通知（Slackやメール、SMSなど）
  • MongoDBを読み取り専用 に切り替え、攻撃状況を調査
  • immuDBの正しいハッシュに基づき、最新バックアップやimmuDBとの照合で修復 する

4.2 ロールバックシナリオ

  1. 該当トランザクションID の MongoDBデータを廃棄
  2. DAGログやバックアップを確認
  3. immuDBに記録されている正しいデータ と再同期
  4. 正常状態に復旧

5. 分析プロセスの最適化

5.1 市町村レベル分析 (6ヶ月内)

  1. MongoDBデータをインデックス駆動 で高速検索
  2. ハッシュ検証 は必要に応じて行う（リアルタイムor定期的）

5.2 大陸レベル分析 (永久データ)

  1. 大陸MongoDBに集約した履歴を、シャーディングで大規模分析
  2. 大規模OLAP → Spark/Hadoopなどの分散システム導入も検討
  3. ハッシュ検証（任意サンプリング or 必要時に全件）で改ざん検出

6. セキュリティ強化策 (詳細)

6.1 immuDBとのリアルタイム同期

  • 書き込み時 → immuDBにハッシュ登録
  • 定期ジョブ → MongoDBのランダムレコードを抽出し、immuDBとのハッシュ照合

6.2 ノード障害に備えたバックアップ

  • 市町村DAG：1秒しかデータを持たないとはいえ、複数ノード冗長で運用
  • MongoDB：レプリカセット + オフサイトバックアップ
  • immuDB：クラスタリング + 毎日のバックアップ

6.3 ネットワーク通信の暗号化

  • MongoDBとの通信もTLS
  • immuDBとの通信はmTLSで相互認証
  • 大陸間APIはJWT + 署名

7. まとめ - 新設計のメリット

  1. DAG未完Tx → 1秒 で完了トランザクションをMongoDBへ移行 → 並列処理 & 高速完了
  2. MongoDBが分析メインDB → シンプルかつ高速
  3. immuDBはハッシュだけ保存 → 改ざんチェック用 & コスト低減
  4. 改ざん検知
    • MongoDBレコードのハッシュを常時 or 定期的にimmuDBと突合
    • 不一致があれば 即アラート & ロールバック

最適化ポイント

  • 1秒保持 でDAGに滞留するデータ量を最小化 → リスクや競合をさらに低減
  • 分析中も定期的にハッシュ検証 → 誰かが MongoDB をハッキングしてもすぐ発覚
  • 大陸MongoDB → 永久保存 → 大陸横断分析が高速に
  • グローバルレベル → immuDB管理者専用 + 大陸間API

8. 実装プロセス

  1. DAGノードの実装
    • 1秒後の移行タイマー + ステータス管理
  2. MongoDBへの書き込み & immuDBハッシュ登録
    • 同時トランザクションで処理し、一貫性を保つ
  3. 改ざん検証モジュール

    • タイマー or リクエストごとに (tx_id, local_hash) vs immuDB_hash 照合

    • 不一致時 trigger_alarm(tx_id)

  4. アラームとロールバック
    • Slack/メール通知 + Database Lockdown + 復旧フロー

この修正案により、MongoDBの改ざんリスク に対して immuDBとのハッシュ整合性検証 で 即時アラーム を出し、ハッキングを防ぐ。DAGの1秒保持 で競合リスクやメモリ負荷を最低限にしつつ、超高速処理を維持できる。これでより詳細かつ安全なフェデレーションモデルの全体像が完成！

 

 

いかがであろうか、これでDAGから分析までの設計の全体像が見えた。このような基本設計で進めて行きたい。