先までは、"愛記"についての記載で、どのようにブロックチェーン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で組み込み、PoHで履歴とし、ブロックチェーンに保存していきたい。このようなアルゴリズム設計の例をプログラミング例で示してみよう。
# Gulf StreamのMempoolレスなトランザクションフォワードプロトコルの例
class GulfStream:
def __init__(self):
self.transactions = []
def add_transaction(self, transaction):
self.transactions.append(transaction)
def forward_transactions(self):
# トランザクションをフェデレーションに転送する処理
pass
# Turbineのブロックの伝搬プロトコルの例
class Turbine:
def __init__(self):
self.blocks = []
def add_block(self, block):
self.blocks.append(block)
def propagate_blocks(self):
# ブロックをネットワーク上で伝搬する処理
pass
# Proof of Place (PoP) の計算の例
import hashlib
def calculate_pop_proof(latitude, longitude):
location_data = f"Latitude: {latitude}, Longitude: {longitude}"
pop_proof = hashlib.sha256(location_data.encode()).hexdigest()
return pop_proof
# Proof of History (PoH) の例
class ProofOfHistory:
def __init__(self):
self.history = []
def add_to_history(self, data):
# データを履歴に追加する処理
self.history.append(data)
# 愛記システムの全体的なアーキテクチャ
class AiKiSystem:
def __init__(self):
self.gulf_stream = GulfStream()
self.turbine = Turbine()
self.proof_of_history = ProofOfHistory()
def process_transaction(self, transaction_data, latitude, longitude):
# トランザクションデータをGulf Streamに追加
self.gulf_stream.add_transaction(transaction_data)
# PoPの計算
pop_proof = calculate_pop_proof(latitude, longitude)
# PoHへの追加
self.proof_of_history.add_to_history(pop_proof)
def generate_block(self):
# トランザクションをブロックにまとめる処理
block_data = self.gulf_stream.transactions + self.proof_of_history.history
# ブロックをTurbineに追加
self.turbine.add_block(block_data)
# トランザクションと履歴をクリア
self.gulf_stream.transactions = []
self.proof_of_history.history = []
# 愛記システムのインスタンス生成
aiki_system = AiKiSystem()
# トランザクションの処理とブロック生成の例
aiki_system.process_transaction("Transaction1", 35.6895, 139.6917)
aiki_system.process_transaction("Transaction2", 37.7749, -122.4194)
aiki_system.generate_block()
これにはGulf StreamとTurbineという独自の機能があり、Proof of Place（PoP）とProof of History（PoH）も組み込まれている。より複雑にしていくには、いくつかの改善が必要であろう。
-
トランザクションとブロックのデータ構造:
- 現在の例では、トランザクションやブロックのデータはシンプルなリストに追加されている。これらのデータ構造をより構造的にし、トランザクションやブロックの属性（例: sender, receiver, timestamp）を考慮してみる必要がある。
-
ネットワークの同期:
- 分散環境で動作するようなブロックチェーンシステムでは、ネットワーク全体での同期が重要である。ブロックの伝搬やトランザクションの処理がネットワークに適切に伝わるように確認する必要がある。
-
トランザクションとブロックの署名:
- セキュリティ向上のために、トランザクションやブロックに署名機能を導入する必要がある。これにより、データの改ざんを防ぐことができる。
-
エラーハンドリング:
- 現在のコードではエラーハンドリングが考慮されていない。ネットワーク上での通信エラーやデータの不整合に対処できるようなエラーハンドリングを追加したい。
-
トランザクションのバッチ処理:
- 現在の例では、トランザクションを個別に処理している。効率を向上させるために、トランザクションのバッチ処理を考慮することも重要である。
-
PoPとPoHの拡張:
- PoPとPoHは十分にシンプルだが、より複雑な機能やセキュリティ検証を組み込むことも検討したい。
これらの提案を取り入れることで、より堅牢で効率的な愛記システムを構築できるのだろう。フェデレーションモデルも考慮して、今一度記載すると、下記のようになる。
# Gulf StreamのMempoolレスなトランザクションフォワードプロトコルの例
class GulfStream:
def __init__(self):
self.transactions = []
def add_transaction(self, transaction):
self.transactions.append(transaction)
def forward_transactions(self, federation):
# トランザクションをフェデレーションに転送する処理
federation.process_transactions(self.transactions)
# Turbineのブロックの伝搬プロトコルの例
class Turbine:
def __init__(self):
self.blocks = []
def add_block(self, block):
self.blocks.append(block)
def propagate_blocks(self, network):
# ブロックをネットワーク上で伝搬する処理
network.process_blocks(self.blocks)
# Proof of Place (PoP) の計算の例
import hashlib
def calculate_pop_proof(latitude, longitude):
location_data = f"Latitude: {latitude}, Longitude: {longitude}"
pop_proof = hashlib.sha256(location_data.encode()).hexdigest()
return pop_proof
# Proof of History (PoH) の例
class ProofOfHistory:
def __init__(self):
self.history = []
def add_to_history(self, data):
# データを履歴に追加する処理
self.history.append(data)
# フェデレーションの例
class Federation:
def __init__(self):
self.main_chain = AiKiSystem() # メインチェーンのインスタンス
def process_transactions(self, transactions):
# トランザクションをメインチェーンに追加
for transaction in transactions:
self.main_chain.gulf_stream.add_transaction(transaction)
def process_blocks(self, blocks):
# ブロックをメインチェーンのTurbineに追加
for block in blocks:
self.main_chain.turbine.add_block(block)
# 愛記システムの全体的なアーキテクチャ
class AiKiSystem:
def __init__(self):
self.gulf_stream = GulfStream()
self.turbine = Turbine()
self.proof_of_history = ProofOfHistory()
def process_transaction(self, transaction_data, latitude, longitude):
# トランザクションデータをGulf Streamに追加
self.gulf_stream.add_transaction(transaction_data)
# PoPの計算
pop_proof = calculate_pop_proof(latitude, longitude)
# PoHへの追加
self.proof_of_history.add_to_history(pop_proof)
def generate_block(self):
# トランザクションをブロックにまとめる処理
block_data = self.gulf_stream.transactions + self.proof_of_history.history
# ブロックをTurbineに追加
self.turbine.add_block(block_data)
# トランザクションと履歴をクリア
self.gulf_stream.transactions = []
self.proof_of_history.history = []
# 愛記システムのインスタンス生成
aiki_system = AiKiSystem()
# フェデレーションのインスタンス生成
federation = Federation()
# トランザクションの処理とブロック生成の例
aiki_system.process_transaction("Transaction1", 35.6895, 139.6917)
aiki_system.process_transaction("Transaction2", 37.7749, -122.4194)
# フェデレーションによるトランザクションの処理
aiki_system.gulf_stream.forward_transactions(federation)
# メインチェーンでのブロック生成
aiki_system.generate_block()
この例では、フェデレーションがトランザクションを処理し、それらがメインチェーンのガルフストリームに転送され、最終的にメインチェーンでブロックが生成される。これにより、各市町村のブロックチェーンが独立して動作し、必要に応じてメインチェーンと連携できるようになる。
上記に、Dapps側である愛記システムを組み込んでみよう。愛記システムとは、愛の行動をしたら相手に愛貨トークンを渡し減らせる。相手は愛貨を受け取り増える。つまり、愛貨とは目標管理制度のようなもので、各市町村に最初に自己申告し、その後愛の行動をして愛貨を減らしていく。それを集計していくアプリケーションが愛記システムであった。
# Solidityで書かれたスマートコントラクトの例
pragma solidity ^0.8.0;
contract LoveToken {
mapping(address => uint256) public loveBalances;
event LoveGiven(address indexed from, address indexed to, uint256 amount);
// 愛貨を送る関数
function giveLove(address to, uint256 amount) external {
require(loveBalances[msg.sender] >= amount, "Insufficient Love balance");
loveBalances[msg.sender] -= amount;
loveBalances[to] += amount;
emit LoveGiven(msg.sender, to, amount);
}
}
このSolidityのスマートコントラクトでは、LoveToken というコントラクトが作成され、giveLove 関数によって愛貨を送ることができる。送信者のアドレスと受信者のアドレス、送る量がイベントとして記録される。これにより、各市町村が自身のDapp内でこのスマートコントラクトを使用できる。
そして、Pythonのコードに愛記システムを組み込む際には、以下のような変更が必要であろう。
# AiKiSystemの全体的なアーキテクチャにDappのスマートコントラクトを組み込んだ例
class AiKiSystem:
def __init__(self, love_token_contract):
self.gulf_stream = GulfStream()
self.turbine = Turbine()
self.proof_of_history = ProofOfHistory()
self.love_token_contract = love_token_contract
def process_transaction(self, transaction_data, latitude, longitude, recipient_address, love_amount):
# トランザクションデータをGulf Streamに追加
self.gulf_stream.add_transaction(transaction_data)
# PoPの計算
pop_proof = calculate_pop_proof(latitude, longitude)
# PoHへの追加
self.proof_of_history.add_to_history(pop_proof)
# Dappのスマートコントラクトに愛貨を送信
self.love_token_contract.giveLove(recipient_address, love_amount)
def generate_block(self):
# トランザクションをブロックにまとめる処理
block_data = self.gulf_stream.transactions + self.proof_of_history.history
# ブロックをTurbineに追加
self.turbine.add_block(block_data)
# トランザクションと履歴をクリア
self.gulf_stream.transactions = []
self.proof_of_history.history = []
# Dappのスマートコントラクトを作成
love_token_contract = LoveToken()
# 愛記システムのインスタンス生成
aiki_system = AiKiSystem(love_token_contract)
# トランザクションの処理とブロック生成の例
aiki_system.process_transaction("Transaction1", 35.6895, 139.6917, recipient_address="0xRecipient", love_amount=10)
aiki_system.process_transaction("Transaction2", 37.7749, -122.4194, recipient_address="0xAnotherRecipient", love_amount=5)
# メインチェーンでのブロック生成
aiki_system.generate_block()
この例では、AiKiSystem クラスに love_token_contract パラメータを追加し、トランザクション処理の中で LoveToken スマートコントラクトを呼び出している。これにより、Dappが愛貨を管理し、愛の行動に基づいてトークンを送受信できるようになる。
PoPアルゴリズム
数学的な概念からの設計は別に行うとして、各市町村というエリア内で行われた愛の行動かどうかを証明するアルゴリズムであればよいと考える。それには、下記のような概念を用いることを検討している。
import hashlib
import random
class AdvancedProofOfPlaceGPS:
def calculate_pop_proof(self, latitude, longitude):
# GPSデータを考慮したPoPの計算
location_data = f"Latitude: {latitude}, Longitude: {longitude}"
nonce = random.randint(0, 1000000) # ランダムなnonceを生成
combined_data = location_data + str(nonce)
# ハッシュ関数の複雑な組み合わせ
pop_proof = hashlib.sha256(combined_data.encode()).hexdigest()
return pop_proof
# AiKiSystemの全体的なアーキテクチャ
class AiKiSystem:
def __init__(self, love_token_contract):
self.gulf_stream = GulfStream()
self.turbine = Turbine()
self.proof_of_history = ProofOfHistory()
self.love_token_contract = love_token_contract
self.pop_algorithm = AdvancedProofOfPlaceGPS()
def process_transaction(self, transaction_data, latitude, longitude, recipient_address, love_amount):
# トランザクションデータをGulf Streamに追加
self.gulf_stream.add_transaction(transaction_data)
# 複雑なPoPの計算
pop_proof = self.pop_algorithm.calculate_pop_proof(latitude, longitude)
# PoHへの追加
self.proof_of_history.add_to_history(pop_proof)
# Dappのスマートコントラクトに愛貨を送信
self.love_token_contract.giveLove(recipient_address, love_amount)
def generate_block(self):
# トランザクションをブロックにまとめる処理
block_data = self.gulf_stream.transactions + self.proof_of_history.history
# ブロックをTurbineに追加
self.turbine.add_block(block_data)
# トランザクションと履歴をクリア
self.gulf_stream.transactions = []
self.proof_of_history.history = []
# Dappのスマートコントラクトを作成
love_token_contract = LoveToken()
# 愛記システムのインスタンス生成
aiki_system = AiKiSystem(love_token_contract)
# GPSからの仮想的な位置情報の生成
latitude = 35.6895
longitude = 139.6917
# トランザクションの処理とブロック生成の例
aiki_system.process_transaction("Transaction1", latitude, longitude, recipient_address="0xRecipient", love_amount=10)
aiki_system.process_transaction("Transaction2", latitude, longitude, recipient_address="0xAnotherRecipient", love_amount=5)
# メインチェーンでのブロック生成
aiki_system.generate_block()
この例では、GPSから取得した緯度と経度を使用して、より現実的な位置情報の信頼性を向上させるPoPアルゴリズムを採用している。GPSデータが利用可能な場合、このようなアプローチが位置認証の高度なセキュリティを提供できる。
いかがであろうか、Solanaの仕組みは魅力的であり、”愛貨”も同様な仕組みとすることを検討したい。Solanaは、トランザクションの処理にシャードやセカンドレイヤーを利用することなく、すべての処理がオンチェーンで行われるため、透明性が担保される。また、開発者やプログラムはSolanaの単一のグローバルな状態にアクセスできるため、プロジェクト間のコンポーザビリティが向上する。極めて保守性が高いといえる。”愛貨”もこのような状態を目指したい。