先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。概念設計としてはひとまず終えた。次は、フェデレーションモデル全体の基本設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。そして、それにつながるDApps側である「愛記システム」を、Pythonプログラムで開発していきたい。
愛の行動のPL,BSを決算書として、個人単位、市町村単位、で公表するような愛記システムというものを考えている。愛の行動のデータベースはブロックチェーンのプログラムであり、日々の愛の行動による愛貨の移動を決算書にまとめていきたい。なお、市町村のブロックチェーンのプログラムは以前にも記載している。その市町村のブロックチェーンのプログラムにつながる愛記システムを、DApps側であるPythonプログラムとして設計したい。その場合、基本設計をどのような手順で進めていけばよいか、詳しく見ていこう。
愛記システムを設計するための基本手順を以下に示す。このシステムは、Pythonを用いて市町村のブロックチェーンと連携し、個人および市町村単位での愛の行動のデータを収集、記録し、決算書（PL、BS）として公表するものである。
基本設計のステップ
- 要件定義
- アーキテクチャ設計
- データベース設計
- API設計
- ブロックチェーンインターフェース
- 決算書の生成
- フロントエンド開発
- テストとデプロイ
基本設計の各ステップを順番に進めることで、ブロックチェーンとDAppsとして繋がる「愛記システム」の詳細な設計が可能になる。各ステップでは、関係者との協議やレビューを通じて設計内容を確定していくことが重要である。
1．要件定義
まず、基本設計の最初のステップである要件定義をしていきたい。どのような機能が必要か、どのような問題を解決するのかを洗い出したい。要件定義はシステム設計の最初の重要なステップであり、システムが解決するべき問題と、必要な機能を明確に定義するプロセスである。以下に、愛記システムのプログラムに必要な機能と解決すべき問題を列挙してみよう。
機能要件
-
愛の行動の記録
-
愛貨の移動の記録
-
決算書の生成
-
個人および市町村単位でのデータの集約
-
データのブロックチェーンへの記録と取得
-
愛貨の管理
-
ユーザー管理
-
通知機能
-
レポート機能
-
ダッシュボード
非機能要件
-
セキュリティ
-
可用性
-
パフォーマンス
-
スケーラビリティ
-
ユーザビリティ
-
コンプライアンス
解決すべき問題
-
透明性と信頼性の確保
-
データの一元管理
-
愛の行動の促進
-
評価制度の確立
-
データのセキュリティとプライバシーの保護
これらの要件を基に、愛記システムの基本設計を進めていくことが重要である。次のステップでは、これらの要件を具体的なアーキテクチャ設計に反映していくことになる。まずは、要件定義の解決すべき問題を一つずつクリアにしていきたい。
透明性と信頼性の確保
1. データの完全性と一貫性の保証
-
データの完全性: すべての取引と愛の行動記録が正確かつ改ざんされていないことを保証する。
-
データの一貫性: システム全体でデータが統一されていることを確認する。
2. 取引の透明性の確保
-
公開取引データ: 取引データを公開し、誰でも確認できるようにする。
-
監査ログ: 取引や行動のすべての変更履歴を保持し、監査可能にする。
3. データのセキュリティとプライバシー保護
-
暗号化: データの送受信時および保存時に暗号化を行い、データの安全性を確保。
-
アクセス制御: データへのアクセスを制御し、必要な権限を持つユーザーのみに限定。
4. 取引の正当性の確認
-
署名の生成と検証: 取引データの署名を生成し、取引の正当性を検証。
-
取引の検証: 各取引を検証し、不正行為や二重支出を防止。
これらの項目を詳細に決定し、実装することで、愛記システムの透明性と信頼性を確保することができる。各項目については、具体的な技術要件や設計仕様を定義し、システム開発の各フェーズで反映させることが重要である。
公開取引データについて
取引データを公開し、誰でも確認できるようにするというが、公開取引データの基本設計をするにあたり、いつ、何を、どのように設計していけばいいのか、具体的にプログラムも含めて見ていこう。公開取引データの基本設計を行うにあたり、以下のステップで進める。
-
公開取引データの定義
- 公開すべき取引データの項目を定義する。例えば、取引ID、送信者、受信者、金額、タイムスタンプ、取引内容など。
- プライバシーに配慮し、公開するデータから個人情報を排除する。
-
データの公開方法
- 取引データを公開するAPIエンドポイントを設計する。
- 公開データを格納するデータベースまたはストレージを設計する。
-
データの整合性と完全性の確保
- 公開データの整合性チェックを実装する。
- 公開データが改ざんされていないことを保証するための仕組みを設計する。
-
透明性の確保
- 誰でも取引データを確認できるインターフェースを提供する。
- 取引データの照会ログを記録し、誰がいつデータを照会したかを追跡できるようにする。
公開すべき取引データの項目を定義する
取引データの項目を定義するにあたり、ユーザビリティをまず考えていこう。ユーザビリティとは、国際規格のISO 9241-11では、「特定の利用状況において、特定の利用者によって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、利用者の満足度の度合い」と定義されている。ユーザビリティを高めるためには、利用者が操作しやすいように、情報やメッセージの提示の仕方やタイミング、言い回し、操作要素や選択肢の提示の仕方、操作の理解のしやすさや結果の想像しやすさ、操作のしやすさや誤りにくさ、誤操作に対する案内や回復過程の丁寧さ、利用者の操作に応じた表示や状況の変化（インタラクション）などを考慮する必要がある。
デザインや詳細な機能要件に関しては、専門のUI/UXデザイナーや開発者と協力して具体的なユーザーフローを検討することが重要であろう。他に注意点としては下記のようなことだ。
-
愛貨管理:
- ユーザーが簡単に自分の愛貨を管理できるように、直感的でシンプルな愛貨トークン画面を提供したい（愛貨も10種類あるため）。
-
統合されたウォレット機能: ユーザーが愛貨を簡単に管理できるように、統合されたウォレット機能を提供する。これにより、ユーザーは同じプラットフォーム内で愛貨を表示、送受信、管理できる。
-
簡易な残高表示: ウォレット画面には、ユーザーが保有している愛貨の簡易な残高が表示される。これにより、ユーザーは一目で自分の資産状況を確認できる。
-
愛貨のリスト表示: ユーザーが保有している愛貨の一覧が表示される。これにより、ユーザーは異なる種類の愛貨間を簡単に切り替えることができる。
-
送金/受信機能: 愛貨の送信や受信が直感的に行えるような機能を提供する。ユーザーは相手のウォレットアドレスを入力し、送信ボタンをクリックすることで簡単に愛貨を送受信できる。
-
愛貨の詳細表示: 各愛貨に関する詳細情報が表示される。これには、愛貨の種類、残高、最新の取引履歴などが含まれる。
-
カスタム表示オプション: ユーザーは表示される愛貨をカスタマイズできるようにする。おそらく、ユーザーが特に興味のある種類の愛貨を画面上で優先的に表示できるようにすると良いだろう。
-
取引履歴: ユーザーが行った取引の履歴が表示される。これにより、過去の取引や愛貨の移動を追跡しやすくなる。
-
セキュリティ機能: ウォレットにはセキュリティ機能が組み込まれているべきである。例えば、2要素認証や生体認証などのセキュリティ機能を提供して、ユーザーの資産を保護する。
-
通知機能: 愛貨の受信や重要な愛貨に関する通知機能を追加することで、ユーザーは重要なイベントにすばやく気付くことができる。
-
-
愛貨の一元管理: ユーザーが保有するすべての愛貨を一元的に管理できるダッシュボードを提供する。これにより、特定の愛貨にアクセスするのが簡単になる。
-
カスタマイズ可能な表示: ユーザーが自分の愛貨管理画面をカスタマイズできるようにする。10種類の愛貨がある場合、ユーザーはよく利用する愛貨や重要な情報に焦点を当てたり、非表示にできるようにしたりすることが望ましいだろう。
-
簡単な愛貨転送機能: 他のユーザーへの愛貨の転送が簡単にできる機能を提供する。友達や家族との愛貨のやりとりが直感的に行えるようにする。
-
ユーザー検索機能:
愛貨を転送する相手を見つけるために、ユーザー検索機能を提供する。ユーザーは相手のユーザー名、アドレス、または連絡先情報を利用して友達や家族を簡単に検索できる。 -
友達リストの統合:
既存の友達リストや連絡先から愛貨を転送する相手を選ぶために、友達リストの統合機能を提供する。これにより、ユーザーはすでに知っている相手に対して簡単に愛貨を送ることができる。 -
QRコードスキャン機能:
愛貨を受け取る相手のアドレスやユーザーIDをQRコードでスキャンして簡単に選択できる機能を提供する。これにより、手動でアドレスを入力する手間を省くことができる。 -
転送フォームのシンプル化:
愛貨の転送フォームをシンプルかつ直感的に設計する。相手の情報を入力し、転送する愛貨の量を指定するだけで簡単に愛貨を送ることができるようにする。 -
転送履歴の表示:
ユーザーが過去に行った愛貨の転送履歴を表示し、再度同じ相手に対して簡単に転送できるようにする。履歴から相手を選ぶことで手間を省くことができる。 -
通知機能:
愛貨を受け取る相手に通知を送信し、相手が愛貨を確認できるようにする。これにより、愛貨の受け取りがスムーズかつ透明に行われる。
-
-
リアルタイムな価値情報: 愛貨の価値や取引履歴などの情報をリアルタイムで提供する。ユーザーは常に最新の情報を確認でき、愛貨の動向を把握しやすくなる。
-
価値チャートの統合:
愛貨の価値変動をリアルタイムで表示する価値チャートを統合する。チャートはユーザーが直感的に価値の変動を確認できるようにし、過去の取引データも容易に閲覧できるようにする。 -
通知機能:
愛貨価値がユーザーが設定した閾値を超えた場合に通知を送信する。これにより、ユーザーは価格の急激な変動に迅速に対応できる。 -
取引履歴のリアルタイム表示:
ユーザーの取引履歴をリアルタイムで表示する。愛貨の送金や受け取りが行われるたびに、取引履歴が更新され、ユーザーは常に最新の情報を確認できる。 -
相場情報のウィジェット:
価格や取引量などの相場情報を画面上のウィジェットとして表示する。ウィジェットはリアルタイムで更新され、ユーザーは他の画面に移動せずに相場情報を把握できる。 -
重要なイベントのアラート:
愛貨に関連する重要なイベント（例: 新しいリリース、パートナーシップの発表）に関するアラートを提供する。これにより、ユーザーは価値に影響を与える可能性がある出来事に早く気付くことができる。 -
愛貨のリアルタイム詳細情報:
愛貨の詳細情報（供給量、時価総額など）をリアルタイムで提供する。これにより、ユーザーはトークンの基本的な情報をすばやく確認できる。
-
-
通知機能: 重要な愛貨の取引や変動に関する通知機能を組み込むことで、ユーザーはリアルタイムで重要なイベントに気付ける。
-
ユーザー教育: 愛貨管理画面が初めてのユーザーにも理解しやすいように、ユーザー教育のためのガイドやツールを提供する。操作の手順や基本的な用語の説明などを含める。
-
セキュリティの確保:
- 取引に関する画面では、セキュリティに特に注意が必要である。二段階認証（2FA）やユーザーピンコードの設定など、追加のセキュリティ手段を提供したい。
- 取引に関する画面では、セキュリティに特に注意が必要である。二段階認証（2FA）やユーザーピンコードの設定など、追加のセキュリティ手段を提供したい。
-
トランザクションの透明性:
- 愛貨の送受信履歴やトランザクション詳細をユーザーにわかりやすく表示することが重要である。愛貨の流れや受信者などが明確に分かるようにデザインしたい。あとは、バリデーターも表示できたら尚良い。
-
トランザクション履歴ページ:
-
愛貨の流れの視覚化: 愛貨の送受信履歴を時系列で表示し、愛貨の流れをグラフやチャートで視覚的に表現する。これにより、ユーザーは愛貨の移動履歴を理解しやすくなる。
-
送信者と受信者の情報: 各トランザクションには、送信者と受信者の情報が明示的に表示される。ウォレットアドレスやユーザー名など、識別可能な情報を提供して、愛貨の流れを特定できるようにする。
-
トランザクション詳細: 各トランザクションに関する詳細情報（トランザクションID、日時、金額など）を表示する。トランザクションが発生したコンテキストや理由も記載し、ユーザーがトランザクションの目的を理解しやすくする。
-
-
トランザクション詳細ページ:
-
愛貨の詳細情報: 愛貨の送信や受信時には、愛貨の詳細情報（愛貨の種類、量、残高など）を表示する。これにより、愛貨の種類や量が明確になる。
-
バリデーター情報: トランザクションに関与するバリデーターの情報を表示します。バリデーターのウォレットアドレスやパブリック鍵、役割などを表示し、トランザクションの信頼性を高める。
-
トランザクションステータス: トランザクションの実行状態や確認状況をわかりやすく表示する。成功したトランザクションやエラーが発生した場合には、ユーザーに適切なメッセージを提供する。
-
-
検索機能とフィルタリング:
-
検索機能: ユーザーが特定のトランザクションを素早く検索できる機能を提供する。トランザクションIDや関連する情報で検索が行えるようにする。
-
フィルタリングオプション: トランザクションを日付、金額、愛貨の種類などでフィルタリングできるオプションを提供する。これにより、ユーザーは特定の条件に合致するトランザクションを見つけやすくなる。
-
-
手数料の表示:
- ブロックチェーンネットワーク上での愛貨送受信には手数料（愛貨にて）が発生する。手数料がどれくらいか、または愛貨の送受信に対する手数料の割合を明示的に表示し、ユーザーにわかりやすく伝えたい。
-
トランザクションフォーム内での手数料表示:
- 愛貨の送受信フォーム内に、手数料の欄を追加する。ユーザーが愛貨の送受信を行う際、予め手数料がどれくらいかを確認できるようになる。
-
手数料の合算表示:
- 愛貨の送受信に関連する手数料を合算して、トランザクションの合計金額として表示する。これにより、ユーザーは手数料を含んだ総額を一目で確認できる。
-
手数料の割合表示:
- トランザクションの詳細ページにおいて、手数料が愛貨の量に占める割合を明示的に表示する。例えば、手数料が愛貨量の5%である場合、それを分かりやすく表示する。
-
手数料の変動通知:
- 手数料が変動する可能性がある場合、ユーザーに対して変更通知を行う。愛貨を送受信しようとする際に手数料が変更された場合、その旨をユーザーに通知して意識させる。
-
手数料明細の提供:
- ユーザーが手数料に関する詳細情報を確認できるように、手数料の明細ページを提供する。手数料の計算方法や発生理由などを分かりやすく説明し、愛貨の送受信に伴う手数料を透明にする。
-
通貨換算の提供:
- 手数料を愛貨だけでなく、通常の通貨に換算して表示するオプションを提供する。これにより、ユーザーは手数料を自分の通常の通貨単位で理解しやすくなる。
-
これらの要素を取り入れることで、ユーザーは手数料に関する情報を理解しやすくなり、愛貨の送受信に際して迅速で正確な判断ができるようになる。
-
愛貨の受け取り先の確認:
- 送信画面では、愛貨の受け取り先アドレスを入力する際に誤りがないかを確認する手段を提供したい。これによって、ユーザーが誤って愛貨を誤ったアドレスに送ることを防ぐ。ただ、手入力は少なく、多くの場合はNFT化して送受信するので、誤りは少ないと考える。
-
QRコードスキャン機能:
- 受け取り先アドレスを手入力する代わりに、QRコードスキャン機能を提供する。ユーザーは相手のアドレスをQRコードでスキャンして受け取り先アドレスを入力できる。これにより、手入力ミスを回避できる。
-
アドレスフォーマットの確認:
- ユーザーがアドレスを手入力する場合、アドレスのフォーマットが正しいかどうかを即座に確認する機能を提供する。誤ったフォーマットで入力された場合には、ユーザーにエラーメッセージを表示し、正しい形式でアドレスを入力するよう促す。
-
最近の送信先リスト:
- 過去に送信した相手のアドレスを履歴として保存し、ユーザーが再度送信する際には選択肢として表示する。これにより、ユーザーは過去の正しいアドレスを手入力する手間を省くことができる。
-
受け取り先アドレスのプレビュー:
- ユーザーがアドレスを入力すると、入力したアドレスのプレビューを表示する。これにより、ユーザーは確認のためにアドレスを視覚的に確認できる。
-
NFT化による確認:
- 愛貨をNFT化して送受信する場合、NFTには受け取り先アドレスが紐づいているはずである。送信前にNFTを確認し、正しいアドレスとリンクされているかを確認する。これにより、アドレスミスを防ぐことができる。
-
アドレスブックの管理:
- ユーザーがよく使用するアドレスをアドレスブックとして管理できる機能を提供する。アドレスブックからアドレスを選択することで、ユーザーは手入力のリスクを最小限に抑えることができる。
-
これらの機能を組み合わせることで、ユーザーが愛貨の受け取り先アドレスを確認する際のミスを最小限にし、安全かつ効率的な愛貨の送受信が可能となる。
-
リアルタイムな更新:
- 愛貨の送受信が行われると、ユーザーに対してリアルタイムで更新される情報を提供することで、トランザクションが成功したことを確認できる。
- 愛貨の送受信が行われると、ユーザーに対してリアルタイムで更新される情報を提供することで、トランザクションが成功したことを確認できる。
-
ユーザーフィードバック:
- 愛貨の送信や受け取りの成功・失敗に関する明確なフィードバックを提供したい。エラーメッセージや成功メッセージが適切であることを確認する。
-
成功メッセージ:
- 愛貨の送信や受け取りが成功した場合、ユーザーに対して分かりやすい成功メッセージを表示する。メッセージは肯定的で明確であり、トランザクションが成功したことを確認できるようにする。
-
エラーメッセージの詳細:
- 愛貨の送信や受け取りが失敗した場合、エラーメッセージを提供する。エラーメッセージは具体的で分かりやすく、ユーザーが問題を理解し対処できるようにする。例えば、アカウントが存在しない、残高不足、ネットワークの問題などを含めたエラーを詳細に示す。
-
トランザクションIDの表示:
- 愛貨の送信や受け取りが成功した場合、トランザクションIDを表示する。これにより、ユーザーはブロックチェーン上でトランザクションのステータスや詳細を確認できる。
-
進捗バーの利用:
- 愛貨の送信や受け取りが処理中であることを示す進捗バーを表示する。これにより、ユーザーはトランザクションの進行状況をリアルタイムで確認できる。
-
通知機能:
- 愛貨の送信や受け取りが成功または失敗した場合に、ユーザーに通知を送信する。モバイルアプリやウェブアプリを通じて即座に通知を受け取れるようにする。
-
トランザクション履歴へのリンク:
- ユーザーが成功または失敗したトランザクションに簡単にアクセスできるように、トランザクション履歴へのリンクを提供する。これにより、ユーザーは過去のトランザクションに関する詳細を確認できる。
- ユーザーが成功または失敗したトランザクションに簡単にアクセスできるように、トランザクション履歴へのリンクを提供する。これにより、ユーザーは過去のトランザクションに関する詳細を確認できる。
-
ユーザーサポート:
- 問題が発生した場合に備え、ユーザーサポートへのアクセスを提供したい。ヘルプセンターへのリンクや問題解決のためのガイドを提供することが役立つ。
- 問題が発生した場合に備え、ユーザーサポートへのアクセスを提供したい。ヘルプセンターへのリンクや問題解決のためのガイドを提供することが役立つ。
では、次はネットワークアーキテクチャから考えていこう。ネットワークアーキテクチャには、スマートコントラクト、トランザクションのフォーマット、ノードの役割と構成ガイド、デプロイメントガイド、モジュールやコンポーネントのAPIドキュメンテーション、セキュリティガイド、などが含まれる。
-
ドキュメンテーション: システムやコンポーネントの理解を助けるために十分なドキュメンテーションを提供する。フェデレーションモデルにおいて、十分なドキュメンテーションを提供することは非常に重要である。以下は、その一例である：
- メインブロックチェーンと各市町村のブロックチェーンのアーキテクチャを説明する。以下は、フェデレーションモデルの一部としてのシンプルなアーキテクチャの概要である。
-
○メインブロックチェーンのアーキテクチャ:
-
Delegated Proof of Stake (DPoS):
- 各市町村の代表者がDPoSによって選ばれる。これにより、ブロック生成のためのバリデーターが定期的に選ばれ、分散的な意思決定が行われる。
-
ランダムな承認者の選定:
- メインブロックチェーン上で、完全なランダム性を持つ乱数を発生させる。
- 生成されたランダムな値に基づいて、1人の承認者が選ばれる。
-
スマートコントラクト:
- メインブロックチェーン上には、フェデレーション全体で共有されるスマートコントラクトが配置されている。
- このスマートコントラクトは、フェデレーションメンバーが相互にやり取りする際のルールや条件を定義している。
-
ブロックチェーンノード:
- メインブロックチェーンは、各市町村のノードと連携し、ネットワーク全体を維持する。
- バリデーターとなるノードは、新しいブロックの生成やトランザクションの承認に参加する。
-
○各市町村のブロックチェーンのアーキテクチャ:
-
独自のブロックチェーン:
- 各市町村は独自のブロックチェーンを有しており、自治体ごとに分散台帳が独立して構築されている。
- 各ブロックチェーンはメインブロックチェーンとは独立して動作する。
-
自治体データ:
- 各自治体のブロックチェーンには、その自治体に関連するデータやトランザクションが格納される。
- 例えば、マイナンバーカード情報などが含まれる。
-
自治体ノード:
- 各市町村は自身のノードを運用し、自治体ブロックチェーンに参加する。
- バリデーターとしての権限を持つ自治体のノードが新しいブロックを生成し、トランザクションを検証する。
-
フェデレーションへの連携:
- 各自治体のブロックチェーンは、メインブロックチェーンと連携している。
- データの相互運用性やブロックチェーン間のトランザクションが可能なように、相互に連携が行われる。
-
これらのアーキテクチャは、各自治体が自身のデータを独立して管理しながら、メインブロックチェーンと連携して全体の信頼性やセキュリティを確保するように設計されている。なお、実際のシステムにおいては、様々な詳細が考慮されるべきであろう。
- 各スマートコントラクトの機能、パラメータ、トランザクションのフォーマットなどを明確に定義する。
- 各関数やメソッドの役割や期待される挙動を説明する。以下は、フェデレーションモデルにおいて各スマートコントラクトの機能、パラメータ、およびトランザクションのフォーマットを定義した例である。具体的な実装に先立っての例であり、必要に応じて変更が必要である。
-
MunicipalityRegistry スマートコントラクト:
- 機能:
- 各市町村の登録と管理を担当する。
- 新しい市町村が参加する際の手続きを管理する。
- メソッド/関数:
- registerMunicipality(address municipalityAddress, string municipalityName): 新しい市町村の登録を行う。
- getMunicipality(address municipalityAddress) returns (string): 指定された市町村の情報を取得する。
- 機能:
-
TransactionProposal スマートコントラクト:
- 機能:
- ネットワーク上での提案されたトランザクションを管理する。
- メソッド/関数:
- submitProposal(address municipality, uint256 amount, string description): トランザクションの提案を行う。
- approveProposal(uint256 proposalId): 提案されたトランザクションを承認する。
- executeProposal(uint256 proposalId): 承認されたトランザクションを実行する。
- 機能:
-
ValidatorRegistry スマートコントラクト:
- 機能:
- バリデーターの登録と管理を担当する。
- メソッド/関数:
- registerValidator(address validatorAddress, string validatorName): 新しいバリデーターの登録を行う。
- getValidator(address validatorAddress) returns (string): 指定されたバリデーターの情報を取得する。
- 機能:
-
FederationConfiguration スマートコントラクト:
- 機能:
- フェデレーション全体の設定を管理する。
- メソッド/関数:
- setThreshold(uint256 newThreshold): 承認のための閾値を設定する。
- setReward(uint256 newReward): 承認者に与えられる報酬を設定する。
- 機能:
-
これらのスマートコントラクトは、各機能の要件に基づいて設計され、相互に連携してフェデレーションモデル全体を構築する。なお、実際の実装においては、セキュリティや効率性を考慮した適切な実装が必要である。
- トランザクションがどのようなデータを含むか、それがどのように処理されるかについてのドキュメントを提供する。以下は、フェデレーションモデルにおいて、初期ドキュメンテーションの一部であり、実際の要件に応じて変更が必要である。
-
トランザクションデータの構造:
- トランザクションID（Transaction ID）: トランザクションを一意に識別するためのユニークなID。
- ユーザーアカウント（User Account）: トランザクションを送信したユーザーのアカウント情報。
- タイムスタンプ（Timestamp）: トランザクションが作成された時間情報。
- 署名（Signature）: トランザクションが有効であることを確認するためのデジタル署名。
- トランザクションの前提条件（Preconditions）: トランザクションが実行される前に満たされている必要がある条件。
- 位置（GIS）:トランザクションが作成されたときの位置情報。
- 愛の行動レベル（Love Action Level）: トランザクションの愛に関する行動のレベルを示す数値と科目。
- 次元（Dimension）: 生命体の次元を表す識別子やカテゴリ。
- 愛貨額（Amount）: 提案されたトランザクションの愛貨額。
- 行動内容（Action Content）: 実際の行動や提案された行動の詳細な説明。
- 承認相手（Approval Target）: 行動の承認を得る対象のアドレスやID。
- ゆらぎ（Fluctuation）: 新たな生命体の発起活動。
-
追加の要素:
- ハッシュ（Hash）: トランザクションデータ全体のハッシュ値。データの整合性を確保するための重要な要素。
- メタデータ（Metadata）: トランザクションに関する追加情報やコンテキストを含む任意のメタデータ。
- ガス代（Fee）: トランザクションの実行にかかるガス代。
- イベント通知（Event Notifications）: トランザクションが実行されたことを他のコンポーネントに通知するためのイベント情報。
-
トランザクションの処理:
- 提案されたトランザクションは、ValidatorRegistry スマートコントラクトによって承認される前提とする。
- 承認が得られたトランザクションは TransactionProposal スマートコントラクトに送信され、実行のために保留される。
- 各バリデーターがトランザクションを承認すると、承認の数が閾値を超えると TransactionProposal スマートコントラクトによって実際に実行される。
-
トランザクションのステータスやエラーメッセージの意味を説明する。
- 各市町村のノードがどのような役割を果たし、どのように構成されるかに関するドキュメントを提供する。
- バリデーターとしての期待される機能や責務を明示する。
- フェデレーションモデルを実際にデプロイする手順や要件に関するガイドを提供する。
- 必要な依存関係、設定、および最適な構成に関する情報を提供する。
- メインブロックチェーンや各市町村のブロックチェーンで提供されるAPIやインターフェースに関するドキュメントを提供する。
- 開発者がこれらのAPIを使用する際の期待される入力と出力を示す。以下は、メインブロックチェーンと各市町村のブロックチェーンが提供するAPIの簡単なドキュメンテーションの例である。具体的な仕様やエンドポイントは実際のシステムによって異なるため、この例は一般的なガイドとして理解してもらいたい。
○メインブロックチェーン API
1. トランザクション発行エンドポイント -
エンドポイント: /api/transactions/issue
-
メソッド: POST
-
リクエスト:
- Body パラメータ:
- sender_address: 送信者のウォレットアドレス
- recipient_address: 受信者のウォレットアドレス
- amount: 送金額
- data: トランザクションに関連するデータ
- Body パラメータ:
-
レスポンス:
- transaction_id: トランザクションの一意の識別子
- status: トランザクションのステータス
- 2. ブロック情報取得エンドポイント
-
エンドポイント: /api/blocks/{block_number}
-
メソッド: GET
-
パラメータ:
- block_number: 取得したいブロックの番号
-
レスポンス:
- block_hash: ブロックのハッシュ
- transactions: ブロック内のトランザクションリスト
- 他のブロック情報...
-
○各市町村のブロックチェーン API
1. ノード情報取得エンドポイント -
エンドポイント: /api/node/info
-
メソッド: GET
-
レスポンス:
- node_id: ノードの識別子
- peer_nodes: 接続している他のノードのリスト
- current_block: ノードが保持する最新のブロック情報
- 他のノード情報...
- 2. トランザクション検証エンドポイント
-
エンドポイント: /api/transactions/verify
-
メソッド: POST
-
リクエスト:
- Body パラメータ:
- transaction_data: 検証するトランザクションデータ
- Body パラメータ:
-
レスポンス:
- valid: トランザクションの検証結果 (true/false)
- error_message: 検証エラーがある場合のエラーメッセージ
- システム全体のセキュリティ設計やベストプラクティスに関するガイドラインを提供する。
- ユーザーがセキュリティのリスクを理解し、適切な対策を講じるのに役立つ情報を提供する。
これらのポイントを考慮することで、ユーザーが安心して愛貨の送受信を行えるような画面デザインが可能となる。
公開取引データの項目について
公開取引データの項目について、DApps側であるPythonプログラムの設計における具体的な項目を以下に示す。
- トランザクションID: transaction_id
- 送信者: sender
- 受信者: receiver
- 金額: amount
- 取引内容: action_content
- 場所: location
- 市町村: municipality
- タイムスタンプ: timestamp
- 署名: signature
- PoP（Proof of Place）: proof_of_place
- 承認者情報: approver_info
- 取引の状態: transaction_status
- 手数料: fee
- 取引履歴: transaction_history
- 公開ステータス: public_status
- 愛貨の種類: currency_type
- バリデーター情報: validator_info
- 手数料の割合表示: fee_percentage
- 通知機能: notification_status
- セキュリティ機能: security_features
- 送信者と受信者の情報: sender_receiver_info
- 愛貨のリスト表示: currency_list
- 残高表示: balance_display
- ユーザー検索機能: user_search
- 友達リストの統合: friends_list
- QRコードスキャン機能: qr_code_scan
- 転送フォームのシンプル化: transfer_form
- 転送履歴の表示: transfer_history
- リアルタイムな価値情報: real_time_value_info
- 価値チャートの統合: value_chart
- 重要なイベントのアラート: event_alerts
- 手数料の変動通知: fee_change_notification
- 手数料明細の提供: fee_details
- 通貨換算の提供: currency_conversion
- 受け取り先の確認: recipient_verification
- ユーザーフィードバック: user_feedback
- トランザクションIDの表示: transaction_id_display
- 進捗バーの利用: progress_bar
- トランザクション履歴へのリンク: transaction_history_link
- ユーザーサポート: user_support
以下に、上記の項目を含むデータ構造の例を示す。
import hashlib
import datetime
import re
from pymongo import MongoClient, errors
from flask import Flask, jsonify, request, abort
app = Flask(__name__)
client = MongoClient('mongodb://localhost:27017/')
db = client['blockchain_db']
# データ構造定義
class DataStructure:
def __init__(self):
self.transactions = db.transactions
self.users = db.users
self.approval_history = db.approval_history
data_structure = DataStructure()
# データの整合性要件
def validate_input_data(data):
"""ユーザー入力データのバリデーション"""
if not re.match(r'^[a-zA-Z0-9]+$', data['transaction_id']):
raise ValueError("Invalid Transaction ID")
if not isinstance(data['amount'], (int, float)) or data['amount'] <= 0:
raise ValueError("Invalid Amount")
if not data['sender'] or not data['receiver']:
raise ValueError("Sender and Receiver must be specified")
if not data['timestamp'] or data['timestamp'] > datetime.datetime.now().timestamp():
raise ValueError("Invalid Timestamp")
# 他のバリデーションチェックを追加
def verify_signature(transaction_data, public_key, signature):
"""署名を検証する疑似関数"""
return hashlib.sha256(str(transaction_data + public_key).encode()).hexdigest() == signature
def check_transaction_consistency(transaction):
"""トランザクションの整合性をチェックする"""
if not verify_signature(transaction['data'], transaction['public_key'], transaction['signature']):
raise ValueError("Invalid Signature")
if transaction['timestamp'] > datetime.datetime.now().timestamp():
raise ValueError("Future timestamp")
# データベーストランザクションの利用
def add_transaction(transaction):
"""トランザクションを安全にデータベースに追加する"""
try:
validate_input_data(transaction)
with client.start_session() as session:
with session.start_transaction():
check_transaction_consistency(transaction)
data_structure.transactions.insert_one(transaction, session=session)
record_audit_log("Transaction Added", transaction, "Success")
print("Transaction added successfully.")
except ValueError as e:
record_audit_log("Transaction Add Failed", transaction, f"Failed - {e}")
print(f"Error adding transaction: {e}")
# 監査ログ
def record_audit_log(operation, details, result):
"""監査ログを記録する"""
timestamp = datetime.datetime.now().isoformat()
audit_log = {
'operation': operation,
'details': details,
'timestamp': timestamp,
'result': result
}
try:
db.audit_logs.insert_one(audit_log)
print("Audit log recorded successfully.")
except errors.OperationFailure as e:
print(f"Failed to record audit log: {e}")
# 公開取引データのAPI
@app.route('/transactions', methods=['POST'])
def create_transaction():
"""新しいトランザクションを作成し、データベースに追加"""
if not request.json:
abort(400, description="Invalid input")
transaction = request.json
add_transaction(transaction)
return jsonify({"status": "Transaction created"}), 201
@app.route('/transactions/<transaction_id>', methods=['GET'])
def get_transaction(transaction_id):
"""特定のトランザクションを取得"""
transaction = data_structure.transactions.find_one({"transaction_id": transaction_id})
if not transaction:
abort(404, description="Transaction not found")
return jsonify(transaction), 200
# 取引データの例
transaction_example = {
'transaction_id': 'tx12345',
'sender': 'user123',
'receiver': 'user456',
'amount': 100.0,
'action_content': 'Donation',
'location': '36.565, 136.656',
'municipality': 'Kaga',
'timestamp': datetime.datetime.now().timestamp(),
'signature': 'validsignature123',
'proof_of_place': {
'latitude': 36.565,
'longitude': 136.656,
'timestamp': datetime.datetime.now().isoformat()
},
'approver_info': {
'user_id': 'approver789',
'public_key': 'approverPublicKey123',
'approval_timestamp': datetime.datetime.now().isoformat(),
'signature': 'approverSignature123'
},
'transaction_status': 'Pending',
'fee': 5.0,
'transaction_history': [],
'public_status': True,
'currency_type': 'LoveCurrency',
'validator_info': 'validator_info',
'fee_percentage': 5,
'notification_status': 'enabled',
'security_features': ['2FA', 'Biometric'],
'sender_receiver_info': 'info',
'currency_list': ['LoveCurrency1', 'LoveCurrency2'],
'balance_display': 100.0,
'user_search': 'search_user',
'friends_list': ['friend1', 'friend2'],
'qr_code_scan': 'qr_code_data',
'transfer_form': 'simple_form',
'transfer_history': 'history',
'real_time_value_info': 'real_time_value',
'value_chart': 'value_chart_data',
'event_alerts': 'alerts',
'fee_change_notification': 'fee_change',
'fee_details': 'fee_details',
'currency_conversion': 'conversion_rate',
'recipient_verification': 'verified',
'user_feedback': 'positive',
'transaction_id_display': 'tx12345_display',
'progress_bar': 'in_progress',
'transaction_history_link': 'history_link',
'user_support': 'support_link'
}
# トランザクションの追加
add_transaction(transaction_example)
if __name__ == '__main__':
app.run(debug=True)
この設計は、ユーザーが愛貨の取引データを公開し、容易にアクセスできるようにするための項目をすべて含んでいる。これにより、データの完全性と透明性を確保し、ユーザーが取引情報を確認しやすくなるように設計されている。
いかがであろうか、今回は公開取引データについて記載した。考えられる項目はすべて列挙しておく。現時点では少し多い気はするが、上記のような項目としたい。