先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。大まかな概念としてはひとまず終えた。次は、ブロックチェーンの概念設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。
愛記システムのシステム評価について
システム評価とは、つまりは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。
システム構築の品質評価のポイント1：理解可能性（Understandability）
システム構築の品質評価のポイント2：完全性（Completeness）
システム構築の品質評価のポイント3：簡潔性（Conciseness）
システム構築の品質評価のポイント4：移植性（Portability）
システム構築の品質評価のポイント5：一貫性（Consistency）と構造化の度合い
システム構築の品質評価のポイント6：保守性（Maintainability）
システム構築の品質評価のポイント7：試験性（Testability）
システム構築の品質評価のポイント8：ユーザビリティ（Usability）
システム構築の品質評価のポイント9：効率性（Efficiency）
システム構築の品質評価のポイント10：セキュリティ（Security）
システム構築の品質評価のポイント6：保守性（Maintainability）
システム構築の評価に繋がる保守性であるが、当方は、ブロックチェーンSNSとDapps側の愛記システムを、”愛貨”というトークンで創っていくということを考えている。そのために、APIによる通信ではなく、フェデレーションモデルを検討したい。
というのも、市町村ごとに異なるブロックチェーンが同じコンポーネントの通信を行う場合、APIを使用することが一般的であろう。これにより、異なるブロックチェーン間でデータを移動しやすくなるのは確かだ。以下に、考えられるAPIや通信手段の例を挙げてみよう。
-
RESTful API: 各ブロックチェーンがRESTful APIを提供し、相互にデータを取得および送信できるようになる。RESTful APIは一般的なHTTPプロトコルを使用して通信し、柔軟性がある。
-
GraphQL: GraphQLはクエリ言語であり、必要なデータを柔軟に取得できるため、異なるブロックチェーン間でのデータ取得に適している。RESTful APIよりも柔軟性があり、効率的な通信が可能であろう。
-
メッセージングプロトコル: MQTTやAMQPなどのメッセージングプロトコルを使用することで、非同期でデータをやり取りできる。これにより、リアルタイムなデータ更新や通知が可能になる。
-
ブロックチェーンインターオペラビリティフレームワーク: ブロックチェーン間の相互運用性を提供するフレームワークを使用することも考えられる。例えば、PolkadotやCosmosなどがこれに該当する。
これらの選択はプロジェクトの具体的な要件や制約に依存する。通信の頻度、データのサイズ、セキュリティの要件などを考慮して、最適な手段を選択することが重要となる。
例えば、Polkadotのセキュリティモデルは、Relay Chainと呼ばれる共通のセキュリティハブに焦点を当てているが、これにより異なるブロックチェーンが共有セキュリティを利用できるようになる。ただし、Polkadot自体も十分なセキュリティ対策が施されている必要がある。以下は、Polkadotがセキュリティを確保するための主な要素である：
-
共通のセキュリティハブ (Relay Chain):
- PolkadotのRelay Chainは、異なるパラチェーン（ブロックチェーン）と共有セキュリティを提供する役割を果たす。しかし、Relay Chain自体が安全であることが重要である。Polkadotの設計では、Relay Chainにおいても強力なセキュリティメカニズムが組み込まれている。
-
Nominated Proof-of-Stake (NPoS):
- PolkadotはNominated Proof-of-Stake（NPoS）と呼ばれる共同ステーキングメカニズムを使用している。この仕組みにより、ユーザーは信頼できるネットワークノードを選んでステーキングできる。このモデルは、選ばれたノードが不正行為を行うことを抑制する。
-
ステートオブリギング (State Transition Function):
- Polkadotでは、パラチェーンごとに独自のステートトランジション関数を持つことができる。これにより、セキュリティの障害が1つのパラチェーンにとどまる可能性がある。
-
ヒューマンステーク (Human Staking):
- パラチェーンの運営者やネットワークセキュリティに参加するエコシステムの一環として、ヒューマンステークが利用される。これは、個人または組織がステーキングを通じてネットワークに貢献する仕組みである。
これらの要素により、Polkadotは異なるブロックチェーン間での共有セキュリティを提供し、セキュリティの弱点を最小限に抑えるように設計されている。ただし、どんなブロックチェーンシステムでもセキュリティに対する注意が必要であり、特に量子コンピューターが台頭してきた場合にはさらなる注意が必要であろう。
量子コンピューターが登場すると、従来の暗号アルゴリズムに対する新たな脅威が考えられる。PolkadotやCosmosがそのような脅威にどれだけ耐えられるかは、使用されている暗号アルゴリズムや将来の技術の進化に依存する。量子セキュリティに関する研究は進行中であり、将来のアップデートや新しい技術の導入によって対応する可能性がある。
フェデレーションモデル
そこで、当方は、フェデレーションモデルを検討したい。各市町村のブロックチェーンが独立して存在し、必要に応じて特定のフェデレーション（連携体）に参加することで、相互に通信やデータ共有を行う。フェデレーションは各市町村の代表者で構成され、彼らがブロックチェーン間の連携を管理するというものだ。このモデルにおいてフェデレーションが承認行為に関与する場合と関与しない場合の２つのケースが考えられる。
-
フェデレーションが承認行為に関与する場合:
- 各市町村のブロックチェーンはフェデレーションに参加し、フェデレーションがブロックチェーン全体の承認行為を行う。フェデレーションは各市町村の代表者で構成され、彼らが決定を行い、その結果が各市町村のブロックチェーンに反映される。
-
フェデレーションが承認行為に関与しない場合:
- 各市町村のブロックチェーンは独立して自己承認行為を行う。フェデレーションはデータの仲介や通信の管理を行いつつ、各市町村が自身のブロックチェーンにおいて承認行為を行うことを許容する。各市町村は自らのブロックチェーンでのルールやプロセスを管理し、フェデレーションはそれを補完的にサポートする。
このようなモデルでは、フェデレーションの役割が重要である。フェデレーションが承認行為に関与する場合は、各市町村はフェデレーションの意思決定を尊重し、フェデレーションが設定した基準に基づいて行動する。一方で、フェデレーションが承認行為に関与しない場合は、各市町村が独自のブロックチェーンで自治体の規定に従って活動する。
当方は、フェデレーションが承認行為に参加する場合を採用したいと思っている。このモデルでは、各市町村のブロックチェーンがフェデレーションに参加し、フェデレーションがブロックチェーン全体の承認行為を行うことによって、世界中の承認者が各市町村のトランザクションを承認できるようになる。しかし、承認の処理速度にはいくつかのポイントがある。
-
フェデレーションの決定速度: フェデレーションが各市町村の代表者で構成され、彼らが承認の決定を行う速度が鍵となる。フェデレーション内での効率的な合意形成や決定プロセスが重要である。
-
通信遅延: フェデレーションが地理的に離れた市町村を含んでいる場合、通信遅延が影響を与える可能性がある。これに対処するためには、高性能な通信インフラや最適化が必要である。
-
ブロックチェーンのスケーラビリティ: 各市町村のブロックチェーンが取り扱うトランザクションのスケーラビリティも考慮する必要がある。ブロックチェーンが大量のトランザクションを処理できるようになっているかどうかが影響する。
これらの課題に対処するためには、技術的な最適化や高度な通信手段の活用、ブロックチェーンの改善などが必要である。また、実際のシステムのデザインや構成によっても異なるため、具体的な要件や状況に基づいた最適なアプローチが求められる。それには、以下のようなアプローチや技術的な手法が考えられる。
-
分散型コンセンサスアルゴリズムの最適化: フェデレーションが承認を行うために使用するコンセンサスアルゴリズムを最適化することが考えられる。例えば、柔軟性やスケーラビリティに優れたコンセンサスアルゴリズムの導入が考えられる。
-
高度な通信手段の利用: 高性能で低遅延の通信手段を活用することで、フェデレーション内での通信速度を向上させることができる。高速なネットワークインフラや専用の通信チャネルの導入が考えられる。
-
分散型ストレージの活用: ブロックチェーンにおけるデータの分散型ストレージを効果的に活用することで、データの共有や取得を迅速に行えるようになる。IPFS（InterPlanetary File System）などの分散型ストレージシステムが利用される可能性がある。
-
ブロックチェーンのプロトコル改善: ブロックチェーンプロトコル自体の改善や、スケーラビリティを向上させるための新しいプロトコルの採用が考えられる。これにより、トランザクション処理の高速化やスケーラビリティ向上が期待できる。
-
クォンタムセキュリティ対策: 量子コンピュータの脅威に対処するため、クォンタムセキュアな暗号アルゴリズムや通信プロトコルの導入が必要であろう。これにより、通信内容が量子コンピュータによって傍受されにくくなる。
-
分散型アプリケーションの最適化: 各市町村のブロックチェーン上で実行される分散型アプリケーション（DApps）の最適化も重要である。処理の効率化やスケーラビリティの向上が求められる。
これらのアプローチを総合的に検討し、実際の状況や要件に合わせて最適な手法を採用することが必要であろう。ただし、技術の進化や新しいアイデアが出てくる可能性もあるため、常に最新のトレンドや研究を追いかけることも重要である。なお、フェデレーションモデルとAPI通信の主な違いは、セキュリティと中央集権性の度合いである。
-
セキュリティ: フェデレーションモデルでは、各自治体が独自のブロックチェーンを持ち、データの共有や通信を行うためのフェデレーションが設定される。この際、各自治体のブロックチェーンは独立しており、セキュリティは各自治体が独自に管理する必要がある。一方、API通信では、データを共有するための中央のサーバーが存在し、セキュリティは中央のサーバーで管理される。
-
中央集権性: フェデレーションモデルでは、各自治体が独立してブロックチェーンを持ち、フェデレーションを通じて通信やデータ共有を行う。フェデレーションは各自治体のブロックチェーン間でコンセンサスを形成し、異なるブロックチェーン間での取引やデータ共有の合意形成を支援し、自治体間で合意が形成されるとブロックチェーン間でのデータの移動や取引が行われるというものだ。このため、中央集権性は比較的低く、各自治体が独自にデータを管理する。一方、API通信では、データ共有や通信は中央のサーバーを介して行われるため、中央集権性が高くなる。
ポリゴンのセキュリティモデルでは、Relay Chainと呼ばれる共通のセキュリティハブが存在し、異なるブロックチェーンが共有セキュリティを利用できるようになる。これにより、異なるブロックチェーン間でセキュリティを共有することができる。一方、フェデレーションモデルでは、各自治体が独立してブロックチェーンを持ち、セキュリティは各自治体が独自に管理するため、ポリゴンのセキュリティモデルとは異なる。
ただ、DApps側は話が異なる。例えば、あるDAppが中央のサーバーを使用してセキュリティを強化し、API通信を介して市町村のブロックチェーンとフェデレーションモデルであるメインチェーンの両方からデータを取得することは可能である。中央のサーバーを使用することで、データの管理やセキュリティをより効果的に管理することができる。ただし、中央のサーバーを使用する場合でも、各市町村のブロックチェーンやフェデレーションモデルとの連携やデータの整合性を確保するためには適切なセキュリティ対策が必要である。
量子コンピュータの台頭時：
一方、量子コンピューターが実用化され、暗号解読の脅威が現実のものとなる可能性がある場合、フェデレーションモデルが量子セキュリティ要件に対応する可能性がいくつか考えられる。以下は一般的な考え方の一例である：
-
量子耐性アルゴリズムの導入： フェデレーションモデルでは、各市町村が独立して存在し、それぞれが異なるセキュリティ対策を導入できる。量子耐性のある暗号アルゴリズムや署名アルゴリズムを導入することで、現行の量子コンピューターに対する脆弱性を低減できる可能性がある。
-
分散鍵管理： 量子セキュリティにおいては、伝統的な鍵交換プロトコルが量子コンピューターによって簡単に解読される可能性があるが、フェデレーション内で分散鍵管理を採用することで、鍵情報を効果的に保護し、より安全な通信を実現できるかもしれない。
-
量子セキュア通信プロトコルの利用： フェデレーション内で、量子セキュア通信プロトコルを利用することで、通信内容が量子コンピューターによって傍受・解読されるリスクを軽減できるかもしれない。
-
分散型識別システム： 量子コンピューターの影響を最小限に抑えるためには、分散型の識別システムを導入することが考えられる。これにより、単一のシステムへの攻撃が難しくなる。
これらの要素を含め、将来の量子セキュリティの標準が確立されるにつれて、フェデレーションモデルがどのように進化するかは、研究や技術の進展に依存する部分が大きい。
なお、フェデレーション内での効率的な合意形成には様々な方法が考えられる。一般的なブロックチェーンにおいては、合意形成は通常コンセンサスアルゴリズムによって達成されるが、各市町村の代表者が分散されており、合意形成を行う際には以下のような方法が考えられる。
-
委任されたプルーフ・オブ・ステーク (Delegated Proof of Stake, DPoS): 各市町村の代表者がフェデレーションに参加し、トランザクションの承認を行うために一部の代表者が選ばれる方式である。DPoSは、通常、持っているトークンの数（当方の場合は、相手に与えた愛貨の量）に応じて投票権が与えられ、最も信頼性のある代表者が承認行為を行う。これにより、トランザクションの迅速な承認と合意形成が可能になる。
-
フェデレーションへの参加: 各市町村の代表者がフェデレーションに参加する。これにより、各市町村からの承認行為の候補者がフェデレーションプールに存在することになる。
-
ランダム選出プロセス： 承認者が必要な際（新しいトランザクションが生じたときなど）、ランダム選出のプロセスがトリガーされる。
-
ランダム性の導入： ブロックチェーンのスマートコントラクトや分散アプリケーション（DApp）内で、ランダム性を導入するアルゴリズムを使用する。これは、ブロックハッシュや特定のオラクルサービスから取得される外部データなどを使用してランダム性を確保することが考えられる。
-
ランダム選出： 導入したランダム性を基に、フェデレーションプール内の代表者からランダムに一人を選出する。
-
-
承認行為： 選ばれた代表者が承認行為を行う。これは、新しいブロックの生成やトランザクションの確定など、プロジェクトの具体的な仕様に応じて異なる。
このようなランダム選出のプロセスは、分散環境での公平性を確保し、各代表者が公正に機会を持つことができる仕組みである。ランダム性の導入においては、セキュリティや予測不可能性が重要である。
ランダム選出において、ブロックハッシュを使用する一般的な手法は、ブロックのハッシュ値を適切な方法で変換し、その結果を元にランダムな数値を生成して承認者を選出することであろう。以下に、簡単なプログラミング例を示す。ただし、これはあくまでシンプルな例であり、実際の環境によってはセキュリティの観点からより洗練された手法が必要である。
import hashlib
import random
def select_approver(block_hash, total_approvers):
# ブロックハッシュをSHA-256でハッシュ化
hashed_block = hashlib.sha256(block_hash.encode()).hexdigest()
# ハッシュを整数に変換
hash_as_int = int(hashed_block, 16)
# 0からtotal_approvers - 1までの範囲でランダムな数を生成
random_number = random.randint(0, total_approvers - 1)
# ランダムな数を承認者の数で割った余りを取得
selected_approver = (hash_as_int + random_number) % total_approvers
return selected_approver
# ブロックハッシュと承認者の数を指定して承認者を選出
block_hash = "block_hash_example"
total_approvers = 5
selected_approver = select_approver(block_hash, total_approvers)
print(f"Selected Approver: {selected_approver}")
この例では、ブロックハッシュをSHA-256でハッシュ化し、その結果を整数に変換している。その後、0から承認者の総数までの範囲でランダムな数を生成し、それをブロックハッシュから得られた整数と合わせて承認者の総数で割った余りを最終的な選出結果としている。これにより、ブロックハッシュに基づいてランダムに承認者を選出することができる。
また、DApps側の最適化も確かに重要である。ブロックハッシュを使用してランダムな承認者を選出する場合、DApps側でその結果を受け取りやすいような形に整形することや、選出された承認者がトランザクションを処理できるような仕組みを構築することが考えられる。以下は、簡単なプログラミング例である。
# DApps側のプログラム
def send_transaction_to_selected_approver(selected_approver, transaction_data):
# 選出された承認者にトランザクションデータを送信
print(f"Sending transaction to Approver {selected_approver}: {transaction_data}")
# ブロックハッシュと承認者の数を指定して承認者を選出
block_hash = "block_hash_example"
total_approvers = 5
selected_approver = select_approver(block_hash, total_approvers)
# DApps側でトランザクションデータを生成
transaction_data = "Transaction data example"
# 選出された承認者にトランザクションデータを送信
send_transaction_to_selected_approver(selected_approver, transaction_data)
この例では、send_transaction_to_selected_approver関数が選出された承認者にトランザクションデータを送信する役割を果たしている。DApps側では、選出された承認者に対してトランザクションデータを適切に伝え、その後の処理をトリガーすることが求められる。最適な通信プロトコルやデータフォーマットを選択し、DAppsと承認者とのインタラクションをスムーズに行うことが必要であろう。
最適な通信プロトコルやデータフォーマットを選択することは、DAppsと承認者との間でデータをやり取りする際の方法や形式を検討し、それに基づいて通信を行うということである。以下に、具体的な選択肢とその例を示す。
１．通信プロトコルの選択:
- HTTP/HTTPS: Webアプリケーションで一般的に使用されるプロトコル。
- WebSocket: リアルタイムな通信が必要な場合に適しています。
- gRPC: 軽量で効率的なRPC（Remote Procedure Call）を実現するためのプロトコル。
# WebSocketを使用する例
import websocket
def send_transaction_to_selected_approver_ws(selected_approver, transaction_data):
ws_url = f"ws://approver-{selected_approver}/"
with websocket.create_connection(ws_url) as ws:
ws.send(transaction_data)
# 選出された承認者にWebSocketを介してトランザクションデータを送信
send_transaction_to_selected_approver_ws(selected_approver, transaction_data)
２．データフォーマットの選択:
- JSON: 軽量で人間にも読みやすい形式。
- Protocol Buffers: バイナリ形式で効率的にデータをシリアライズできる形式。
# JSONを使用する例
import json
def send_transaction_to_selected_approver_json(selected_approver, transaction_data):
data = {'approver': selected_approver, 'transaction': transaction_data}
json_data = json.dumps(data)
# HTTP POSTなどで送信
# ...
# 選出された承認者にJSON形式でトランザクションデータを送信
send_transaction_to_selected_approver_json(selected_approver, transaction_data)
これらの例では、WebSocketを使用する場合やJSON形式のデータを送信する場合など、具体的な通信プロトコルやデータフォーマットを示している。最適な選択は、アプリケーションの要件や性能、セキュリティなどに依存するため、慎重に検討する必要がある。
さらに、DApps側の愛記システムにおいて、スマートコントラクトの最適化も重要である。スマートコントラクトが実行されるブロックチェーン上での処理は、効率的でリソースを節約することが求められる。以下は、スマートコントラクトを最適化するための一般的なアプローチである。
-
ガスコストの最適化:
- ガスはトランザクションの実行に必要なコストを表す。不要なガスの使用を避け、コストを最小限に抑えるための最適化を行う。
-
ストレージの最適利用:
- ストレージの使用を最小限に抑え、必要な情報だけを保持するようにする。過度なデータの保持はコストを増加させる可能性がある。
-
イベントの適切な利用:
- イベントを使用して必要な情報を記録することで、クライアントがそれを監視できるようになり、冗長なデータをスマートコントラクトに格納する必要がなくなる。
-
処理の分割:
- 大規模で複雑なスマートコントラクトを複数の小さな関数に分割することで、再利用性が向上し、コードの可読性が向上する。
rust言語を使用していくつかの最適化の例を示す。以下は具体的なプログラム例ではなく、最適化のアイディアの一般的な表現である。
１．ガスコストの最適化:
// 不要なループの削減
fn sum_array(numbers: Vec<u32>) -> u32 {
let mut sum = 0;
for &number in numbers.iter() {
sum += number;
}
sum
}
// ガス効率の向上
fn sum_array_optimized(numbers: Vec<u32>) -> u32 {
let mut sum = 0;
let length = numbers.len(); // 長さを一度取得してループ内で再利用
for i in 0..length {
sum += numbers[i];
}
sum
}
２．ストレージの最適利用:
// 不要なストレージ使用の回避
struct StorageOptimization {
value: u32,
}
impl StorageOptimization {
fn set_value(&mut self, new_value: u32) {
self.value = new_value;
}
}
// ストレージ変数をローカル変数に代入して使用
struct StorageOptimizationOptimized;
impl StorageOptimizationOptimized {
fn set_value(new_value: u32) {
let local_var = new_value;
// localVarを使用して処理
}
}
３．イベントの適切な利用:
// 冗長なデータをイベントに記録
event ValueUpdated(uint);
// イベントの利用を最適化
event ValueUpdated(uint, uint);
fn update_value(old_value: uint, new_value: uint) {
// イベントに必要な情報だけを記録
emit ValueUpdated(old_value, new_value);
}
これらはあくまで一般的な例であり、実際のプロジェクトにおいてはコードのコンテキストや要件に基づいて最適化を行う必要がある。
いかがであろうか、このようなフェデレーションモデルにより、将来を見据えたブロックチェーンSNSとDapps側の愛記システムを構築したいと考えている。続きはもう少し具体的に、次回以降記載したい。