先までは、"愛記"についての記載で、どのようにブロックチェーン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による通信ではなく、フェデレーションモデルを検討したい。
最初は一つの市町村における所得税減税や法人税減税サービスにつながるブロックチェーンSNSを考慮しているのだが、ゆくゆくは、他の市町村も同様に”愛貨”をやり取りするブロックチェーンSNSを導入したい！という声があがるだろう。さらには、世界中の各都市が同様に手をあげるかもしれない。そうなると、各市町村のブロックチェーンSNSが群雄割拠することになり、それらブロックチェーン間をブリッジして情報をやりとりすることも出てくるだろう。そうなると、各市町村のブロックチェーンを跨いで承認行為を行うようなフェデレーションモデルが必要になってくるということだ。
そして、フェデレーションが承認を行う際に、データやトランザクションにアクセスして必要な合意形成を行うことで、各市町村のブロックチェーンが提供する様々なサービスや機能を統合し、連携させる。このような仕組みを設けておけば、ある市町村のブロックチェーンSNSと、別の市町村のブロックチェーンSNSとを選択しながらユーザーは行動していけるということも可能となる。
”愛貨”をトークンとするブロックチェーンについて
Solanaの仕組みは魅力的であり、”愛貨”をトークンとする当方のブロックチェーンや愛記システムも同様な仕組みとすることを検討したい。Solanaは、トランザクションの処理にシャードやセカンドレイヤーを利用することなく、すべての処理がオンチェーンで行われるため、透明性が担保される。また、開発者やプログラムはSolanaの単一のグローバルな状態にアクセスできるため、プロジェクト間のコンポーザビリティが向上する。極めて保守性が高いといえる。”愛貨”もこのような状態を目指したい。
Proof of History (POH) — コンセンサスにおける時間同期。
Tower BFT — POHに最適化されたビザンチン将軍問題解決
Turbine — ブロックの伝搬プロトコル
Gulf Stream — Mempoolレスなトランザクションフォワードプロトコル
Sealevel — スマートコントラクトを並列で実行
Pipelining — 認証最適化のためのトランザクション処理ユニット
Cloudbreak — パラレルスケーリングのアカウントデータベース
Archivers — 分散型台帳保管
これらのアイデアはとても魅力的であり、愛記システムにもできる限り組み込んでいきたい。愛記システムにこれらの技術を組み込み、さらに、PoP（proof of Place)のアルゴリズムも加えたい。というのも、各市町村のブロックチェーンは、各市町村で愛の行動をしたという場所の証明が重要になる。
PoPアルゴリズム
数学的な概念からの設計は別に行うとして、各市町村というエリア内で行われた愛の行動かどうかを証明するアルゴリズムであればよいと考える。以下に、フェデレーションが各市町村の公開鍵を持ち、ユーザーが位置情報を署名してその署名が検証されると、フェデレーションを通じて各市町村に対して位置情報が通知されるフローを示す。
-
各市町村の鍵生成:
- 各市町村は自身の鍵ペア（公開鍵と秘密鍵）を生成する。
-
ユーザーの鍵生成:
- ユーザーは自身の鍵ペアを生成する。この鍵ペアには、公開鍵が他者に共有される部分で、秘密鍵はユーザーが秘密に保持する部分が含まれる。
-
位置情報の署名:
- ユーザーは自身の秘密鍵を使用して、位置情報を署名する。これにより、ユーザーがその位置情報に対して正当な所有者であることが示される。
-
署名検証:
- フェデレーションはユーザーの公開鍵を使用して、ユーザーが署名した位置情報を検証する。署名が正当であれば、その位置情報はユーザーによって認証されたものと見なされる。
-
位置情報の通知:
- 署名が検証された位置情報は、フェデレーションを通じて各市町村に通知される。各市町村はそれを受け取り、必要に応じて処理を行う。
このような流れを通じて、フェデレーションを介して位置情報が各市町村に配信され、信頼性のある位置情報が得られることが期待される。
また、Proof of Place (PoP) のアルゴリズムをブロックチェーンに組み込む試みは、他でも実際に行われているが、その導入には様々な課題がある。以下にいくつかの理由を挙げてみよう：
-
セキュリティの懸念:
- PoPのアルゴリズムがうまく機能するためには、位置情報が正確で信頼性が高いことが求められる。しかし、GPSや他の位置情報取得手段は、スプーフィング（位置情報の偽装）などの攻撃に対して脆弱である可能性がある。このため、セキュリティの懸念が存在する。
-
プライバシーの問題:
- ブロックチェーン上で個々のユーザーの位置情報を扱うことは、プライバシーの観点から慎重に考える必要がある。ユーザーの位置情報を不用意に公開すると、プライバシー侵害のリスクが高まる。
-
実装の複雑性:
- ブロックチェーン上で位置情報を扱うことは、実装の複雑性を増す可能性がある。特に、リアルタイムで位置情報を確認し、それをブロックチェーンに反映させることは技術的な課題を伴う。
-
合法的な制約:
- ある地域では位置情報の取り扱いに法的な制約がある場合がある。これらの法的な要件を満たすためには、慎重な設計と実装が必要である。
これらの理由から、PoPをブロックチェーンに組み込むことは難易度が高く、検討すべき多くの側面が存在する。一部のプロジェクトやアプリケーションは、これらの問題に対処し、PoPを導入しているが、一般的には慎重な検討とセキュリティ対策が求められる。
そこで当方では、位置をそのまま取ると法的に問題があるなら、市町村に居るか居ないかだけを判別するというアルゴリズムにしているという具合だ。市町村に居るかどうかを判別するアルゴリズムを設計することは、プライバシーに対する配慮があり、法的な問題を軽減する一手段となりえる。
-
ユーザーが特定の市町村にいる場合、特定のトリガーが発生する（例: 特定のWi-Fiネットワークに接続された、特定のBluetoothデバイスが検出された、GPSの位置情報を取得し市町村内にいるかどうかを判別する、など）。
-
ユーザーのデバイスは、トリガーの発生を検知し、それをブロックチェーンにトランザクションとして送信する。
-
ブロックチェーン上でトランザクションが確認されると、ユーザーはその市町村にいると見なされる。
-
ブロックチェーン上でトランザクションがない場合、ユーザーはその市町村にいないと見なされる。
from ecdsa import SigningKey, VerifyingKey, NIST521p
class LocationAlgorithmECC:
def __init__(self, municipality_private_key, municipality_boundary):
self.private_key = SigningKey.generate(curve=NIST521p) if municipality_private_key is None else municipality_private_key
self.public_key = self.private_key.verifying_key
self.is_in_municipality = False
self.municipality_boundary = municipality_boundary
def detect_location_trigger(self, user_public_key, user_signature, gps_location):
# ユーザーの公開鍵で署名を検証
verification_result = self.verify_user_signature(user_public_key, user_signature)
if verification_result:
# ユーザーの署名が正当な場合、GPS位置情報を検証
self.is_in_municipality = self.verify_gps_location(gps_location)
return self.is_in_municipality
else:
# ユーザーの署名が不正な場合、市町村にいないと見なす
self.is_in_municipality = False
return False
def verify_user_signature(self, user_public_key, user_signature):
try:
verifying_key = VerifyingKey.from_string(user_public_key, curve=NIST521p)
verifying_key.verify(user_signature, "User is in the municipality".encode())
return True
except Exception as e:
print(f"Verification failed: {e}")
return False
def verify_gps_location(self, gps_location):
# 市町村の範囲内にいるかどうかを判定
return self.municipality_boundary[0][0] <= gps_location[0] <= self.municipality_boundary[1][0] and \
self.municipality_boundary[0][1] <= gps_location[1] <= self.municipality_boundary[1][1]
# メインチェーンのフェデレーション
class Federation:
def __init__(self, municipality_public_keys, municipality_boundaries):
self.municipality_public_keys = [VerifyingKey.from_string(key, curve=NIST521p) for key in municipality_public_keys]
self.municipality_boundaries = municipality_boundaries
def verify_user_location(self, user_public_key, user_signature, gps_location):
for i, public_key in enumerate(self.municipality_public_keys):
try:
public_key.verify(user_signature, "User is in the municipality".encode())
# フェデレーションの検証が成功した場合、GPS位置情報を検証
if self.verify_gps_location(gps_location, i):
return True
except Exception as e:
pass # 各市町村の公開鍵で検証を試みる
return False
def verify_gps_location(self, gps_location, municipality_index):
# 市町村の範囲内にいるかどうかを判定
return self.municipality_boundaries[municipality_index][0][0] <= gps_location[0] <= self.municipality_boundaries[municipality_index][1][0] and \
self.municipality_boundaries[municipality_index][0][1] <= gps_location[1] <= self.municipality_boundaries[municipality_index][1][1]
# 各市町村の鍵ペア生成
municipality1_private_key = SigningKey.generate(curve=NIST521p)
municipality1_public_key = municipality1_private_key.verifying_key.to_string().hex()
municipality2_private_key = SigningKey.generate(curve=NIST521p)
municipality2_public_key = municipality2_private_key.verifying_key.to_string().hex()
# 各市町村の範囲を設定（仮のダミーデータ）
municipality1_boundary = ((35.0, 138.5), (35.5, 139.0))
municipality2_boundary = ((36.0, 139.0), (36.5, 139.5))
# 各市町村のインスタンス生成
municipality1_algorithm = LocationAlgorithmECC(municipality1_private_key, municipality1_boundary)
municipality2_algorithm = LocationAlgorithmECC(municipality2_private_key, municipality2_boundary)
# 各市町村の公開鍵リストおよび範囲のリスト
municipality_public_keys = [municipality1_public_key, municipality2_public_key]
municipality_boundaries = [municipality1_boundary, municipality2_boundary]
# フェデレーションのインスタンス生成
federation = Federation(municipality_public_keys, municipality_boundaries)
# ユーザーの鍵ペア生成
user_private_key = SigningKey.generate(curve=NIST521p)
user_public_key = user_private_key.verifying_key.to_string().hex()
# ダミーのGPS位置情報 (例: 東京都庁の位置)
gps_location = (35.6895, 139.6917)
# ユーザーが位置情報を署名
user_signature = user_private_key.sign("User is in the municipality".encode())
# トリガーが検出されたかどうかの確認
trigger_detected = check_specific_trigger()
# 各市町村でトリガーが検出された場合、ユーザーの位置情報を検証
for municipality_algorithm in [municipality1_algorithm, municipality2_algorithm]:
if municipality_algorithm.detect_location_trigger(user_public_key, user_signature, gps_location):
print("User is in the municipality.")
break
else:
print("User is not in the municipality.")
この例では、各市町村とフェデレーションが位置情報の検証を行う。各市町村は自身の範囲内にユーザーがいるかどうかを検証し、フェデレーションは各市町村の検証結果を確認して最終的な結果を出力する。GPS位置情報の範囲判定の具体的なアルゴリズムは、地理情報データを利用して正確な範囲を設定する必要があるのだろう。
なお、今は直接オープンデータやGISデータベースにアクセスすることはしない。しかし、一般的な手順に基づいて、地理情報データを使用して範囲判定を行うアルゴリズムを作成することができる。実際のデータに基づいた正確なアルゴリズムを作成するには、対象となる地域の具体的なデータを入手する必要がある。
def is_in_municipality(gps_location, municipality_polygon):
"""
緯度経度が市町村のポリゴン内にあるかどうかを判定する関数
:param gps_location: (latitude, longitude) 形式の緯度経度
:param municipality_polygon: 市町村のポリゴン座標 [(lat1, lon1), (lat2, lon2), ..., (latn, lonn)]
:return: 真(True)なら市町村内、偽(False)なら市町村外
"""
lat, lon = gps_location
# ポリゴン内外の判定アルゴリズム
cross_count = 0
for i in range(len(municipality_polygon)):
lat1, lon1 = municipality_polygon[i]
lat2, lon2 = municipality_polygon[(i + 1) % len(municipality_polygon)]
if ((lat1 <= lat < lat2) or (lat2 <= lat < lat1)) and \
(lon < (lon2 - lon1) * (lat - lat1) / (lat2 - lat1) + lon1):
cross_count += 1
return cross_count % 2 == 1
# 例として市町村のポリゴン座標を設定
municipality_polygon = [(35.0, 138.5), (36.0, 138.5), (36.0, 139.5), (35.0, 139.5)]
# 例としてGPS位置を設定
gps_location = (35.5, 139.0)
# 範囲判定を行う
result = is_in_municipality(gps_location, municipality_polygon)
print(f"The user is in the municipality: {result}")
この例では、市町村のポリゴン座標とGPS位置が与えられた場合に、指定された座標が市町村内にあるかどうかを判定できる。実際のデータを使用する場合は、データのフォーマットに合わせて適切な変更が必要である。
いかがであろうか、以上がブロックチェーンの保守性であった。Solanaの仕組みは魅力的であり、”愛貨”も同様な仕組みにPoPというアルゴリズムを加えることを検討したい。Solanaは、トランザクションの処理にシャードやセカンドレイヤーを利用することなく、すべての処理がオンチェーンで行われるため、透明性が担保される。また、開発者やプログラムはSolanaの単一のグローバルな状態にアクセスできるため、プロジェクト間のコンポーザビリティが向上する。極めて保守性が高いといえる。”愛貨”もこのような状態を目指したい。