先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。概念設計としてはひとまず終えた。次は、フェデレーションモデル全体の基本設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。
フェデレーションモデルのブロックチェーンの基本設計を進めるには、以下の手順に従って詳細に設計していくことが重要である。これにはシステムの機能、アーキテクチャ、データフロー、技術スタック、および具体的な実装方法の設計が含まれる。
基本設計のステップ
-
要求分析
-
システムアーキテクチャの設計
-
データフローの設計
-
技術スタックの選定
-
データモデルの設計
-
API設計
-
セキュリティ設計
-
エラーハンドリングとログ設計
基本設計の各ステップを順番に進めることで、フェデレーションモデルのブロックチェーンの詳細な設計が可能になる。各ステップでは、関係者との協議やレビューを通じて設計内容を確定していくことが重要である。
1．要求分析
まず、基本設計の最初のステップである要求分析をしていきたい。どのような機能が必要か、どのような問題を解決するのかを洗い出したい。要求分析はシステム設計の最初の重要なステップであり、システムが解決するべき問題と、必要な機能を明確に定義するプロセスである。以下に、メインチェーンとフェデレーションモデルでつながる市町村のブロックチェーンのプログラムに必要な機能と解決すべき問題を列挙してみよう。
解決すべき問題
-
データの一貫性と整合性
-
スケーラビリティとパフォーマンス
-
ガバナンスとコンセンサス
-
システムの拡張性
-
トランザクションの信頼性とセキュリティ
-
トランザクションのトレーサビリティ
必要な機能
-
トランザクション生成
-
トランザクションの検証
-
トランザクション承認と統合
-
ブロック生成
-
自治体の登録と管理
-
履歴証明（Proof of History）
-
APIゲートウェイ
-
ガバナンス機能
-
セキュリティ機能
-
スケーラビリティとパフォーマンス最適化
コンセンサスの設計項目
-
コンセンサスアルゴリズムの選定
- DPoS (Delegated Proof of Stake): 市町村代表がトランザクションを承認するためのアルゴリズム。
- PoP（Proof of Place): 位置証明。各ノードや承認の位置を証明することで、地域間の利益を演出するためのアルゴリズム。
- PoH (Proof of History): 履歴証明。トランザクションの順序を保証するためのアルゴリズム。
-
代表選出のメカニズム
- 選出プロセス: 代表ノードを選ぶためのプロセス（例: 投票、ランダム選出）。
- 任期と再選ルール: 代表ノードの任期や再選ルールを設定。
-
コンセンサスの合意形成
- 合意形成のフロー: トランザクションがどのように承認されるか（例: 提案→検証→承認）。
- コンフリクト解決メカニズム: コンフリクトが発生した場合の解決方法（例: 再投票、仲裁）。
-
コンセンサスの拡張性と効率化
- スケーラブルな合意形成: ノード数が増えてもコンセンサスを効率的に行うための手法。
- APIゲートウェイ: 効率的でセキュリティも強化されたAPIが必要。
- 最適化戦略: コンセンサスプロセスを最適化するための技術的手法（例: 先行承認、PoP活用）。
PoPアルゴリズム
参加者の位置データが例えば石川県加賀市内に居るかどうかを証明するアルゴリズムを構築するために、Proof of Place の手法を使用できる。以下に、簡単な例を挙げてみよう。
-
参加者の証明生成:
- 参加者は現在の位置データ（緯度経度など）を取得する。
-
位置情報の離散化:
- 石川県加賀市の境界を離散的な領域にマッピングする。例えば、特定の単位で緯度経度を区切り、各領域に番号を付ける。位置情報を離散的な領域にマッピングするために、緯度経度を特定の単位で区切り、各領域に番号を付けるという手法を数学的に表現してみよう。以下は簡単な例である。
-
緯度経度の離散化:
ϕdiscrete=⌊ϕ⌋,λdiscrete=⌊λ⌋
ここで、⌊x⌋ は x の床関数を表す。床関数（floor function）を適用することにより、各座標は離散的な整数の値となる。
- 緯度 ϕ と経度 λ をそれぞれ特定の単位で離散化する。例えば、1度ごとに区切ることを考える。これにより、各点は離散的な座標になる。たとえば、1度ごとに離散化する場合、ある位置の緯度が35.75で経度が139.5であれば、それぞれ離散化された座標は (35,139) となる。この手法を使って座標を離散的な番号に変換することで、参加者の位置情報を一定の単位で表現しやすくなる。
-
領域への番号付け:
RegionNumber=Concatenate(ϕdiscrete,λdiscrete)
ここで、ConcatenateConcatenate は座標を組み合わせて一意の番号を生成する関数である。
- 離散化された座標に基づいて各領域に番号を付ける。例えば、(1,2) は緯度が1度、経度が2度の領域に対応するとする。
-
参加者の位置を領域にマッピング:
- 参加者の現在位置を離散化した領域にマッピングする。この際、離散化された座標が生成される。
-
位置情報のハッシュ:
- 離散化された座標（またはその他の関連情報）に対してハッシュ関数を適用し、ハッシュ値を生成する。
-
参加者の証明の生成:
- 生成されたハッシュ値を含む証明を作成する。
-
証明の検証:
- 検証者は事前に公開された石川県加賀市の領域情報と、参加者の提供するハッシュ値を用いて証明を検証する。
以下に数学的検証の例を示す。 -
地理情報の公開:
- G を地理情報が含まれた離散化された領域の集合とし、G加賀市 が石川県加賀市の領域を表す。
-
参加者の提供するハッシュ値:
- 参加者の離散化された座標を P=(xP,yP) とし、ハッシュ関数を H として、H(P)=Hash(xP,yP) を生成。
-
証明の検証手順:
- 検証者は参加者から受け取ったハッシュ値を H提供 とし、H提供 に対応する離散化された座標を P提供=(xP提供,yP提供) とする。
- P提供∈G が成り立つことを確認。
- G加賀市 において、P提供 が含まれているか確認。
参加者が提供した座標に対応するハッシュ値: H提供=Hash(xP提供,yP提供)
参加者が提供した座標: P提供=(xP提供,yP提供) -
具体的な座標範囲:
石川県加賀市の座標範囲を、簡略な直交座標系で次のように表現する。
G加賀市={(x,y)∣135≤x≤136,36.1≤y≤36.3}
ここで、x は経度、y は緯度を表している。
参加者の提供する座標:
参加者が提供した座標 P提供=(xP提供,yP提供) が G加賀市 に含まれるかを確認する。
P提供∈G加賀市⇔(135≤xP提供≤136)∧(36.1≤yP提供≤36.3)
もし P提供 の座標がこの条件を満たしていれば、参加者の提供した座標は石川県加賀市の範囲内に存在することが確認できる。この条件は、具体的な座標が与えられれば適用できるものである。
- 実際は加賀市は領域なので各区域の点座標が直線やポリゴンなどで構成されている場合、提供された座標がその形状内に存在するかどうかを判定する。加賀市のような複雑な形状を持つ領域内に参加者の位置（P）が含まれるかどうかを判定するためには、ポリゴン内点検出アルゴリズムを使用することが一般的である。これは、ジオメトリックな方法を用いて点がポリゴンの内部にあるかどうかを判定するものである。最も広く使われている方法の一つは、レイキャスティングアルゴリズムだ。
・レイキャスティングアルゴリズムの概念：
点Pから無限遠に向かって水平な線（レイ）を引く。このレイとポリゴンの各辺との交点の数を数える。交点の数が奇数ならば点Pはポリゴン内にあり、偶数ならばポリゴン外にある。
・実装例（Python）：
以下にPythonでの実装例を示す。これは、加賀市のポリゴン内に点が含まれるかどうかをチェックする関数である。
def is_point_in_polygon(x, y, polygon):
"""
ポリゴン内に点が含まれているかを判定する関数。
:param x: 点の緯度
:param y: 点の経度
:param polygon: ポリゴンの頂点リスト [(x1, y1), (x2, y2), ...]
:return: 点がポリゴン内にある場合True、それ以外の場合False
"""
num = len(polygon)
j = num - 1
inside = False
for i in range(num):
xi, yi = polygon[i]
xj, yj = polygon[j]
if ((yi > y) != (yj > y)) and (x < (xj - xi) * (y - yi) / (yj - yi) + xi):
inside = not inside
j = i
return inside
# 加賀市のポリゴン定義（例としてランダムな座標を使用）
kaga_polygon = [
(36.27, 136.27),
(36.25, 136.29),
(36.23, 136.25),
(36.26, 136.23),
(36.27, 136.27)
]
# 検証する点
latitude = 36.26
longitude = 136.26
if is_point_in_polygon(latitude, longitude, kaga_polygon):
print("Location is inside Kaga City polygon")
else:
print("Location is outside Kaga City polygon")
■説明：
1．ポリゴン内に点が含まれているかを判定する関数 is_point_in_polygon
・入力として点の緯度・経度（x, y）と、ポリゴンの頂点リストを受け取る。
・ループを使用して各辺を調べ、レイキャスティングの条件に基づいて交点の数をカウントする。
・交点の数が奇数の場合は点がポリゴン内に、偶数の場合は点がポリゴン外にあると判定する。
2．加賀市のポリゴン定義
・実際のポリゴン座標を入力する必要があるが、例としてランダムな座標を使用している。
3．点の検証
・点の緯度・経度を指定し、関数を使用してその点がポリゴン内にあるかを検証する。
このようにして、参加者の位置データが加賀市のポリゴン内にあるかどうかを証明することができる。
- 検証者は事前に公開された石川県加賀市の領域情報と、参加者の提供するハッシュ値を用いて証明を検証する。
-
このアルゴリズムでは、参加者は現在の位置データを離散化された地理的な領域に変換し、その情報をハッシュ化して証明を生成する。検証者は公開された領域情報と照らし合わせて証明の妥当性を確認する。なお、このアルゴリズムは簡略化されたものであり、実際にはセキュリティやプライバシーの側面から検討が必要であろう。
追加確認事項
-
位置情報の精度: 実際のアプリケーションで使用する際は、より細かい精度で位置情報を管理する必要がある。離散化の単位を調整するか、APIやライブラリを使用して精度を高めることが推奨される。
-
セキュリティ強化: PoPの証明生成および検証には、暗号技術の強化が必要である。例えば、ラティスの暗号化プロトコルを使用してデータの通信を保護することが考えられる。
-
パフォーマンスの考慮: ブロックチェーンにおけるPoPの実装は、パフォーマンスに影響を与える可能性があるため、効率化のためのオフチェーン処理やキャッシュの導入も検討する必要がある。
-
愛貨額の減額処理：愛貨額を同じ市町村内で同じ組織内で無い人どおしがやり取りする場合は、減額処理は不要だ。しかし、同じ組織内に居る人どおしがやり取りする場合は、1／4に減額処理をする。また、同じ市町村で無い人とやり取りする場合は、3／4に減額処理をする。
# 自分の市町村内での行動の場合は、額は変化しない
if not self.is_local:
if self.close_flag:
self.amount *= 0.25 # 同じ組織内の場合は1/4倍に
else:
self.amount *= 0.75 # 他の市町村での行動の場合は3/4倍に
else:
self.amount = decrease_love_currency(self.amount) -
市町村が新たに参加表明した時: 新たな市町村がフェデレーションモデルに参加した際に、運用チームがポリゴンデータを追加・更新。なぜなら、このフェデレーションモデルに参加表明した市町村の住民のみがブロックチェーンに入れるのであって、それ以外の一般の人はWebを閲覧するのみで、愛貨のやりとりに参加できない。だから、参加表明した市町村のポリゴンを更新していけばいい。
-
Continental_Main_Chainの役割：まずは地域レベルでの管理として、各大陸ごとにContinental_Main_Chainが存在し、市町村のトランザクションやPoPデータの管理を担当する。さらに連携の確保として、Continental_Main_Chainどおしでデータの連携を行い、大陸間でのトランザクションやデータ交換が円滑に行われる。
-
Global_Main_Chainの役割：まず統括管理として、各Continental_Main_Chainから集められたデータを一元管理し、オフラインでデータの集約とバックアップを行う。さらにスケーラビリティ確保として、Continental_Main_Chainが分散して処理を行うため、Global_Main_Chainの負荷を軽減できる。これにより、何百万市町村が参加してもシステムが問題なく動作する。
PoPアルゴリズムの設計
では実際に設計をやってみよう。
1. 設計の全体概要
- 目的: 各トランザクションが正しい場所で行われたことを証明し、信頼性の高いトランザクション処理を実現する。
- 対象: Municipal_Chain、Continental_Main_Chain、DAppsでのPoP検証。
- 実施期間: システム設計フェーズから運用フェーズまで継続的に管理。
2. 計画フェーズ
誰が:
- システム設計チーム: PoPアルゴリズムの設計と実装。
- 運用チーム: PoPデータの管理と運用、ポリゴンデータの更新。
- セキュリティチーム: PoPデータのセキュリティ設計。
何を:
- 地理データの収集とポリゴンデータの作成。
- トランザクションに位置情報を埋め込むシステム設計。
- PoP検証の仕組みを実装し、ブロックチェーンでの記録。
いつ:
- 設計フェーズでPoPアルゴリズムの基本設計。
- 開発フェーズでPoPアルゴリズムの実装。
- 運用フェーズで定期的に地理データとアルゴリズムの更新・監視。
どのように:
- 地理データを離散化し、PoPアルゴリズムを用いて各トランザクションが行われた場所を検証する仕組みを実装する。
3. 実装フェーズ
3.1. 地理データの収集と管理
誰が:
- データエンジニア: 地理データを収集し、加賀市のポリゴンデータを構築。
- セキュリティエンジニア: データのセキュリティを確保。
何を:
- 加賀市の正確なポリゴンデータを取得。
- ポリゴンデータをブロックチェーンネットワークで共有。
- 加賀市の正確なポリゴンデータを取得し、ブロックチェーンネットワークで共有する方法はいくつかある。以下にそのプロセスを詳しく説明する。
1.1. 公共の地理情報サービスを利用する
加賀市や石川県、または日本の政府機関が提供する地理情報システム (GIS) からデータを取得する。
・自治体の公式ウェブサイト: 市町村の公式ウェブサイトで、GISデータや地理データを提供している場合がある。加賀市の公式サイトや石川県の地理情報ポータルサイトを確認する。
・国土地理院: 日本の国土地理院が提供する地理データ（地図、境界データなど）を利用する。国土地理院の地理院地図やダウンロードサービスから加賀市の境界データを取得できる可能性がある。
・Geospatial Information Authority of Japan (GSI): 国土地理院が提供するオープンデータセットを使用して、ポリゴンデータを取得する。多くの場合、Shapefile形式やGeoJSON形式で提供されており、これらのファイルをGISソフトウェアやプログラムで利用できる。
1.2. オープンデータやAPIを利用する
オープンデータポータルやAPIを利用して、加賀市のポリゴンデータを取得する。
・OpenStreetMap (OSM): OpenStreetMapから地理データを取得することが可能である。OSMは、地理データをオープンな形式で提供しており、特定の市町村や地域の境界データを取得することができる。
・QGIS: 無料のGISソフトウェアを使用して、オープンデータや政府提供のデータを視覚化し、必要なポリゴンデータを抽出する。
・Overpass API: OpenStreetMapのデータをクエリして特定の市町村境界データを取得できる。
例: Overpass API を使用したクエリ (GeoJSON形式で加賀市のポリゴンデータを取得)：
[out:json];
area[name="加賀市"]->.searchArea;
(
relation["admin_level"="8"](area.searchArea);
);
out body;
>;
out skel qt;
いつ:
- システム設計の初期段階で地理データを準備。
- 定期的な更新や追加データの処理。
どのように:
- ポリゴンデータをジオJSON形式などで保存し、ネットワーク上で共有。
- 実装例:
kaga_polygon = [ (36.2, 136.2), (36.2, 137.5), (36.7, 137.5), (36.7, 136.2) ]
3.2. トランザクション処理へのPoP組み込み
誰が:
- システムエンジニア: トランザクション処理にPoPアルゴリズムを組み込む。
- 開発チーム: トランザクション生成および検証システムの実装。
何を:
- トランザクション生成時に位置データを埋め込み、PoP証明を生成。
- ブロックチェーン上でPoPを検証。
いつ:
- トランザクション生成時に自動的にPoPを計算。
- トランザクション承認時にPoP検証。
どのように:
- トランザクションに位置情報を含めるコードを実装。
- 受信トランザクションでは、受信者の位置情報も検証。
実装例（Rust）：
struct Transaction {
id: u32,
location: String,
amount: u64,
status: TransactionStatus,
location_hash: String,
}
impl Transaction {
fn new(id: u32, location: String, amount: u64) -> Self {
let location_hash = Self::calculate_location_hash(&location);
Self {
id,
location,
amount,
status: TransactionStatus::Pending,
location_hash,
}
}
fn calculate_location_hash(location: &str) -> String {
let mut hasher = Sha256::new();
hasher.update(location);
format!("{:x}", hasher.finalize())
}
}
3.3. 検証とブロックチェーンへの記録
誰が:
- 検証チーム: トランザクションのPoP検証を行い、ブロックチェーンに記録。
- セキュリティチーム: 検証データの保護と監査。
何を:
- トランザクションを検証し、適切なPoPデータをブロックチェーンに記録。
- 不正なトランザクションを検出し、ブロックチェーンに記録しない。
いつ:
- トランザクション承認時に自動的に検証。
どのように:
- PoPの検証フローをブロックチェーンに統合し、ネットワーク全体で共有。
実装例（Rust）：
fn verify_transaction(transaction: &Transaction, valid_polygons: Vec<Vec<(f64, f64)>>) -> bool {
for polygon in valid_polygons {
if is_point_in_polygon(transaction.location, polygon) {
return true;
}
}
false
}
4. 運用フェーズ
誰が:
- 運用チーム: PoPデータの監視、更新、運用。
- ガバナンスチーム: 定期的なPoPポリシーの見直し。
何を:
- PoPデータの定期的な更新と修正。
- 新しい地理データが必要な場合に更新する手順を確立。
いつ:
- 毎月の定期的な更新と、必要に応じて追加のメンテナンス。
どのように:
- ブロックチェーンのPoPアルゴリズムをメンテナンスし、最新の地理データに基づいて運用を最適化。
この設計により、Proof of Place (PoP) をフェデレーションモデルに効果的に統合し、トランザクションの信頼性とセキュリティを強化することができる。
いかがであろうか、PoPアルゴリズムの設計概要であった。次回もう少し、具体的なところを一つずつ見ていきたい。