愛記システム概念設計:システム構築の品質評価のポイント4 移植性③ | 続・ティール組織 研究会のブログ

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

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

先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。大まかな概念としてはひとまず終えた。次は、ブロックチェーンの概念設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。

愛記システムのシステム評価について

システム評価とは、つまりは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。

システム構築の品質評価のポイント1:理解可能性(Understandability)

システム構築の品質評価のポイント2:完全性(Completeness)

システム構築の品質評価のポイント3:簡潔性(Conciseness)

システム構築の品質評価のポイント4:移植性(Portability)

システム構築の品質評価のポイント5:一貫性(Consistency)と構造化の度合い

システム構築の品質評価のポイント6:保守性(Maintainability)

システム構築の品質評価のポイント7:試験性(Testability)

システム構築の品質評価のポイント8:ユーザビリティ(Usability)

システム構築の品質評価のポイント9:効率性(Efficiency)

システム構築の品質評価のポイント10:セキュリティ(Security)

◆システム構築の品質評価のポイント4:移植性③(Portability)

システム構築の評価に繋がる移植性とは、異なるブロックチェーン間の相互運用性を意識し、アプリケーションの移植性や互換性を加味してシステム設計を行うことが肝要であるということだ。特に、コンポーネント間の通信に共通のプロトコルや標準化されたインターフェースを使用することは、異なるブロックチェーン上のコンポーネントが協調して作業するための基盤を提供する。

 

これらのプロトコルは、異なるブロックチェーンや分散型ネットワークが協力して動作するための基盤を提供し、相互運用性を高める。これにより、様々なシステムが連携しやすくなり、異なるデータソースやサービスを統合する際のハードルが低減する。これをDApps側である愛記システムと、愛貨をトークンとするブロックチェーンSNSの設計に用いた場合、どうなるか見てみよう。なお、承認者はどのブロックチェーンの承認依頼も承認できるようにする。市町村ごとに分散されたブロックチェーンを構築し、世界中の承認者がどのブロックチェーンの承認依頼も承認できるようにする。

 

仮にある市町村のブロックチェーンがだめになった場合、愛記システム等のDAppsは他の市町村のブロックチェーンに移り変わるということも可能になる。

  1. データの移行:

    • 同じプロトコルを採用している場合、データの移行が比較的スムーズに進む可能性がある。ブロックチェーン上のトランザクションやアカウントのデータ形式が一致することが期待される。
  2. スマートコントラクトの再利用:

    • 同じスマートコントラクト言語や仕様が使われている場合、既存のスマートコントラクトを再利用できる可能性がある。これにより、再開発の手間を軽減できる。
  3. 技術的な相互運用性:

    • 同じプロトコルを採用することで、技術的な相互運用性が高まる。共通の標準を共有することで、異なる市町村のブロックチェーンがより効果的に連携できる。
  4. 開発者コミュニティとサポート:

    • 同じプロトコルを使用することで、広範な開発者コミュニティやサポート体制が利用できるかもしれない。これは新しいアプリケーションやアップデートの開発において有利であろう。
  5. セキュリティと信頼性:

    • 共通のプロトコルを使用することで、セキュリティや信頼性に関する共通の基準が存在する可能性がある。これが新しいブロックチェーンの導入において安心感を提供する。

ただし、プロトコルが同じであっても、個別の市町村のブロックチェーンは別々のネットワークとして機能するため、それぞれのブロックチェーンのガバナンスや運用方針は異なることに留意する必要がある。

 

以下のコードでは、ある市町村のブロックチェーンが機能しなくなった場合に、DAppsである愛記システムが他の市町村のブロックチェーンに移り変わる仕組みを追加している。この例では、fallback_to_another_blockchain エンドポイントがそれを担当する。移行時に発動する/fallback_to_another_blockchainエンドポイントは、通常の市町村のブロックチェーンのプログラムには含まれない部分である。このエンドポイントは、移行が必要な際に手動または自動で呼び出されるように設計されることが一般的であろう。実際の移行処理は、移行先の新しいブロックチェーンシステムに合わせて実装されるため、一般的には以下の手順で行われる:

  1. 移行先の新しいブロックチェーンシステムを準備する。これには、新しいブロックチェーンのセットアップやネットワークの構築などが含まれる。

  2. 古いブロックチェーンからデータをエクスポートする。これには、古いブロックチェーンのデータベースからデータを取得し、移行可能な形式に変換する作業が含まれる。

  3. 新しいブロックチェーンシステムにデータをインポートする。エクスポートしたデータを新しいブロックチェーンシステムにインポートし、正常にデータが移行されることを確認する。

  4. 移行が成功したことを通知する。移行が成功した場合は、移行完了の通知を発信し、システムを新しいブロックチェーンシステムに切り替える。

これらの手順は、移行が比較的単純なケースでの一般的な手順である。移行先の新しいブロックチェーンシステムやデータの複雑さによっては、より詳細な手順や処理が必要になる場合もある。

 

import time
from flask import Flask, request, jsonify

app = Flask(__name__)

# 各市町村ごとのブロックチェーンと最終更新時刻を保存するための辞書
blockchains = {}
last_updated = {}

# ネットワーク遅延の閾値(秒)
NETWORK_DELAY_THRESHOLD = 1

@app.route('/request_approval', methods=['POST'])
def request_approval():
    data = request.get_json()

    # リクエストから市町村名を取得
    municipality = data.get('municipality')
    
    # 対応するブロックチェーンがなければ新しく作成
    if municipality not in blockchains:
        blockchains[municipality] = []

    # ブロックチェーンに承認依頼を追加
    blockchains[municipality].append(data)

    # 最終更新時刻を更新
    last_updated[municipality] = time.time()

    return jsonify({'message': f'Approval request added to {municipality} blockchain'}), 200

@app.route('/approve_request', methods=['POST'])
def approve_request():
    data = request.get_json()

    # 承認者がどの市町村のブロックチェーンでも承認できるようにする
    for municipality, blockchain in blockchains.items():
        # ネットワーク遅延が閾値以下であれば承認
        if time.time() - last_updated.get(municipality, 0) <= NETWORK_DELAY_THRESHOLD:
            # Verifiable Credentialsを承認し、ブロックチェーンに追加
            blockchain.append({'approver': data.get('approver'), 'approved_request': data.get('approved_request'), 'verifiable_credentials': data.get('verifiable_credentials')})
        else:
            return jsonify({'error': f'Network delay too high for {municipality} blockchain. Fallback mechanism initiated.'}), 500

    return jsonify({'message': 'Request approved on all blockchains'}), 200

# /fallback_to_another_blockchain エンドポイントに新しいブロックチェーン情報を受け取った場合の処理を追加

@app.route('/fallback_to_another_blockchain', methods=['POST'])
def fallback_to_another_blockchain():
    data = request.get_json()

    # 新しいブロックチェーン情報を取得
    new_blockchain_info = data.get('new_blockchain_info')

    # 移行処理を行う(この部分は実際の移行処理に合わせて実装)
    if migrate_data_to_new_blockchain(new_blockchain_info):
        # 移行が成功した場合、新しい情報を通知
        return jsonify({'message': 'Fallback to another blockchain initiated', 'new_blockchain_info': new_blockchain_info}), 200
    else:
        # 移行が失敗した場合のエラー処理
        return jsonify({'error': 'Failed to migrate data to the new blockchain'}), 500

# 実際の移行処理を行う関数
def migrate_data_to_new_blockchain(new_blockchain_info):
    # ここに実際の移行処理を実装
    # 例: データベースから古いブロックチェーンのデータを取得し、新しいブロックチェーンに変換して保存
    # この部分はプロジェクトの要件に合わせて適切に実装する必要がある
    return True  # 移行成功

if __name__ == '__main__':
    app.run(debug=True)

 

このコードでは、/fallback_to_another_blockchain エンドポイントが新しいブロックチェーン情報を受け取り、それに基づいて移行処理を行う。そして、migrate_data_to_new_blockchain 関数が実際の移行処理を模擬している。この関数内で、古いブロックチェーンからデータを取得し、新しいブロックチェーンに変換して保存する処理を実装することが想定されている。実際のプロジェクトでは、これを適切な方法で行う必要があるが。

 

DApps側の移行処理

移行処理が行われる場合、DApps側のプログラミングも必要である。移行処理は、新しいブロックチェーンに適応するためにデータを変換し、新しい仕組みに合わせてプログラムを調整するプロセスであり、新しいブロックチェーンの要件と連携して行われるべきである。DApps側のプログラムは、新しいブロックチェーンのAPIや仕様に対応できるようにアップデートされ、データの整合性を保つために必要な手続きを行う。移行処理はシステム全体を考慮したものであり、DApps側とブロックチェーン側の双方で協力して実現される。

 

以下は、移行処理を行うためのDApps側のPythonプログラムの例である。このプログラムは、新しいブロックチェーンにデータを移行するための基本的な手順を示している。

import requests
from flask import Flask, request, jsonify

app = Flask(__name__)

# 移行先のブロックチェーンのエンドポイント
NEW_BLOCKCHAIN_ENDPOINT = 'http://example.com/new_blockchain'

@app.route('/migrate_data_to_new_blockchain', methods=['POST'])
def migrate_data_to_new_blockchain():
    try:
        data = request.get_json()
        new_blockchain_info = data.get('new_blockchain_info')
        # 移行処理を行う
        # 例: 古いブロックチェーンのデータを取得して、新しいブロックチェーンに変換して送信
        # この部分はプロジェクトの要件に合わせて適切に実装する必要がある
        response = requests.post(NEW_BLOCKCHAIN_ENDPOINT + '/fallback_to_another_blockchain', json={'new_blockchain_info': new_blockchain_info})
        if response.status_code == 200:
            return jsonify({'message': 'Data migration to the new blockchain successful'}), 200
        else:
            return jsonify({'error': 'Failed to migrate data to the new blockchain'}), 500
    except Exception as e:
        return jsonify({'error': f'Error during data migration: {e}'}), 500

if __name__ == '__main__':
    app.run(debug=True)
 

このプログラムでは、/migrate_data_to_new_blockchainエンドポイントを作成し、移行処理を行うためのAPIを提供している。クライアントは、このAPIを使用して新しいブロックチェーンにデータを移行するリクエストを送信できる。実際の移行処理は、プロジェクトの要件や新しいブロックチェーンの仕様に合わせて適切に実装する必要がある。

 

 

いかがであろうか、システム評価の移植性について記載した。各市町村のブロックチェーンが独立して運用しつつ、共通のプロトコルを使用することで、承認者は全体の承認が可能となるというような設計にすることで、移植性を確保したいし、セキュリティも確保したい。仮にどこかの市町村のブロックチェーンがだめになった場合、他のブロックチェーンに移行する例も示した。このような設計案を具現化していきたい。