先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。大まかな概念としてはひとまず終えた。次は、ブロックチェーンの概念設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。
オープン・クローズについて
人は労働するため、企業に属するとか、公務に従事するのだろう。その際、企業内では、社長から目標が降ろされてきているので、目標に向かって行動していくのであろうから、その目標の中に”愛の行動”が含まれているのであれば、企業内では従業員皆がこぞって愛の行動をするようになるのだろう。仮に半ば強制的であったとしても。それゆえ、下記のような愛の行動が活発に行われるだろう。これは”クローズ”としてフラグが立つ。
・借方（発信先）：第2次元：営業部_部長、Lv3：目標に向かい行動する、70愛貨が渡される
→詳細内容を備考欄に記入。
・貸方（受信側）：第2次元：営業部_Aさん、自主的に発言する、70愛貨を受け取る
→ 背景等を備考欄に記入。
一方、企業外では、個人がボランティア活動をしたり、町会で活動したり、仲間と遊んだり、人助けをしたり、しているのであろう。これらの活動でも愛の行動は起こるであろうから、ここも記載していくことになる。なお、繰り返し記載しているが、仲間内で愛の行動のNFTをばらまくような迷惑行為をしたとしても、仲間は愛貨は受け取らないだろうから大丈夫だ。仮に受け取ったとしても、今度は受け取った人が愛貨が増えてしまい、愛の行動を強いられるので、重い荷を背負うようなことになるだけなのだから。振り込め詐欺メールと同じようなもので、そのようなメールがいくら来ても誰もメールを受け取らないだろうし、仮に受け取ったら、振り込め詐欺に遭って”お金”が減ってしまい、後悔することになるだけなのだから。よって、仲間どおしの本当の愛の行動ならば、下記のようなやりとりが活発に行われるだろう。これは”オープン”としてフラグが立つ。
・借方（発信先）：第1次元：Fさん、Lv4：親身に教える・教えられる、100愛貨が渡される
→詳細内容を備考欄に記入。
・貸方（受信側）：第1次元：Aさん、愛を学習する、100愛貨を受け取る
→ 背景等を備考欄に記入。
他方で、企業内とも企業外ともいえるような微妙な場面もあるだろう。例えば、”ゆらぎ”やプロジェクトでの愛の行動の場合だ。企業内で”ゆらぎ”行動を自ら起こすことで、その行動に追随して”いいね！”を押して賛同し仲間に加わり、さらに仲間が集まり、プロジェクトにまで発展する。このような場合、企業外から仲間が加わりプロジェクトなどを形成して開発に取り組むのであろう。要するに、企業内の”輸送機プロジェクト”でのSさんの愛の行動が、企業外のOさん（ただし”輸送機プロジェクト”に週1回程度参加している）に”愛貨”が渡るような場合だ。このような場合は、”オープン”なのか、”クローズ”なのか、どちらなのか？
結論は、”オープン”でフラグが立つことになる。結局は企業外のOさんに愛貨が渡っているので、企業内での決算では”愛貨”が減ったというP/L、B/Sが出来上がるのだから。よって、下記のような愛の行動が行われることになるのだろう。
・借方（発信先）：第2次元_輸送機プロジェクト・Sさん、Lv4：光と闇を認める
→ 詳細内容を備考欄に記入。
・貸方（受信側）：第2次元_輸送機プロジェクト・Oさん、気持ちが楽になる
→ 背景等を備考欄に記入。
重要なのは受け取った人がどの立場で受け取るのかが重要だ。立場が同じかどうかを判別していくことで、”オープン”か、”クローズ”か、を判別するという具合だ（クローズの場合、■を前に付加する）。Sさん、Oさんが下記のように申請していたとしよう。
○氏名：Sさん、在住：石川県加賀市、他はマイナンバーカードと紐付け
Total: 5000000愛貨を行動宣言
第10次元：太陽系（デフォルト）
第9次元：地球（デフォルト）
第8次元：人類（デフォルト）
第7次元：世界経済（デフォルト）
第6次元：日本国（デフォルト）
第6次元：日本国を動かしていこう会（記入した）における”右足の役割”で参画
第5次元：運輸産業（選択した）
第5次元：石川県（選択した）
第4次元：運輸に付帯するサービス業（選択した）
第4次元：加賀市（選択した）
■第3次元：中西金属工業株式会社（記入した）における”膵臓”の役割で参画
■第3次元：輸送機事業部（記入した）における”左足の役割”で参画
■第2次元：輸送機プロジェクト（記入した）における”右足の役割”で参画
第1次元：個人（デフォルト）
○氏名：Oさん、在住：石川県加賀市、他はマイナンバーカードと紐付け
Total: 8000000愛貨を行動宣言
第10次元：太陽系（デフォルト）
第9次元：地球（デフォルト）
第9次元：地球を守る会（記入した）における”右足の役割”で参画
第8次元：人類（デフォルト）
第7次元：世界経済（デフォルト）
第6次元：日本国（デフォルト）
第6次元：日本のワビ・サビを守ろう会（記入した）における”右手”の役割で参画
第5次元：情報通信業（選択した）
第5次元：石川県（選択した）
第4次元：情報サービス業（選択した）
第4次元：加賀市（選択した）
第4次元：（一社）石川県情報システム工業会（記入した）
■第3次元：株式会社スマートバリュー（記入した）における”心臓の役割”で参画
第3次元：加賀市ブロックチェーン都市構想プロジェクト（記入した）における”脊髄の役割”で参画
■第2次元：技術営業部（記入した）における”心臓”の役割で参画
■第2次元：アプリ開発チーム（記入した）における”腸の役割”で参画
■第2次元：KYC認証チーム（記入した）における”右手の役割”で参画
第1次元：個人（デフォルト）
Oさんは、第2次元で受け取るのだが、Oさんは輸送機プロジェクトとしての申請をしていないので、輸送機プロジェクトとしての愛の行動NFTを送付することはできないが、受け取ることはできる。そしてこのまま受け取れば、申請していないのでプロジェクト外の人と判別され、”オープン”のフラグが立つという具合だ。受け取ったOさんは”オープン”で受け取ると、”クローズ”で受け取るより負債が大きいので、今後は状況を見て、第2次元：”輸送機プロジェクト”を加えるよう申請するのかもしれないが、それは状況次第だ。
このように、所属先が異なるので、オープンか、クローズの判別はできる。こうして、個人での活動と法人での活動を区別しつつ、オープンか、クローズかを判別しつつ、”愛記システム”での評価がなされていく。そう、”オープン”フラグが立っている”愛の行動”ほど、評価が高くなるように設定する必要があるだろう。例えば、1/4（0.25）倍の評価としてみる。
”オープン”フラグが立っている”愛の行動”：500愛貨⇒ 500点
”クローズ”フラグが立っている”愛の行動”：500愛貨⇒ 500×0.25＝125点
こうすることで、なるべく多くの”オープン”フラグの”愛の行動”が発生するだろう。当初はこのような設定でスタートしたい。
スマートコントラクトの設計:
-
愛貨とフラグの設定:
- ユーザーは、各次元における生命体の各部位の役割を設定することで、その次元が選択できるようになる。その次元について、クローズかオープンかをフラグで設定する。クローズの場合、会社として愛貨額が集計されることになるので、会社内での評価等に利用される。そのため、フラグをクローズと設定し忘れると、会社内での愛の行動として反映されず、プライベートということになってしまうので、会社内での評価に影響する。なお、クローズフラグに関連する次元の愛貨額は0.25倍となる。
-
愛貨の送信:
- ユーザーが愛貨を送ると、それぞれの受け取り手に基づいて計算された愛貨の額が送信される。
- 受け取り手の次元ごとのフラグに応じて、基本の愛貨額に倍率が適用される。
-
残高の更新:
- 送信者の残高が不足していないことを確認し、送られた愛貨の額が受け取り手の残高に加算される。
-
フラグの取得:
- ユーザーは各次元におけるクローズかオープンかのフラグを取得できる。
このスマートコントラクトにより、次元ごとに異なるフラグに基づいて愛貨の評価が変動し、それがランキングや所得税減税などに影響を与える。さらに、会社内での行動評価にも影響を与えるという具合だ。以下の修正版のスマートコントラクトは、次元ごとに異なるフラグを持ち、そのフラグに応じて愛貨の評価が変動する。さらに、送信者と受信者の次元が同じでかつクローズフラグが立っている場合、評価が0.25倍される仕組みが実装されている。
use std::collections::HashMap;
use ink_lang as ink;
#[ink::contract]
mod love_record_nft {
#[cfg(not(feature = "ink-as-dependency"))]
use ink_storage::{
lazy::Lazy,
collections::HashMap as StorageHashMap,
};
use ink_env::AccountId;
#[derive(Debug, PartialEq, Eq, scale::Encode, scale::Decode)]
pub struct Record {
subject: Vec<u8>,
dimension: Vec<u8>,
description: Vec<u8>,
is_approved: bool,
}
#[derive(Debug, PartialEq, Eq, scale::Encode, scale::Decode)]
pub struct DimensionInfo {
role: Vec<u8>,
is_open: bool,
}
#[ink(storage)]
pub struct LoveRecordNFT {
records: StorageHashMap<u64, Record>,
token_id_counter: Lazy<u64>,
dimension_roles: HashMap<Vec<u8>, HashMap<Vec<u8>, DimensionInfo>>,
user_balances: HashMap<AccountId, HashMap<Vec<u8>, u64>>,
}
impl LoveRecordNFT {
#[ink(constructor)]
pub fn new() -> Self {
Self {
records: StorageHashMap::new(),
token_id_counter: Lazy::new(0),
dimension_roles: HashMap::new(),
user_balances: HashMap::new(),
}
}
#[ink(message)]
pub fn set_dimension_role(&mut self, dimension: Vec<u8>, role: Vec<u8>, is_open: bool) {
let dimension_info = DimensionInfo { role, is_open };
self.dimension_roles
.entry(dimension.clone())
.or_insert_with(|| HashMap::new())
.insert(role, dimension_info);
}
#[ink(message)]
pub fn get_dimension_role(&self, dimension: Vec<u8>, role: Vec<u8>) -> Option<DimensionInfo> {
self.dimension_roles
.get(&dimension)
.and_then(|roles| roles.get(&role).cloned())
}
#[ink(message)]
pub fn send_love_currency(&mut self, sender: AccountId, receiver: AccountId, amount: u64) {
let sender_balances = self.user_balances.entry(sender).or_insert_with(|| HashMap::new());
let receiver_balances = self.user_balances.entry(receiver).or_insert_with(|| HashMap::new());
if let Some(sender_balance) = sender_balances.get_mut(&Vec::new()) {
if *sender_balance >= amount {
*sender_balance -= amount;
*receiver_balances.entry(Vec::new()).or_insert(0) += amount;
}
}
}
#[ink(message)]
pub fn get_love_currency_balance(&self, user: AccountId, dimension: Vec<u8>) -> Option<u64> {
self.user_balances
.get(&user)
.and_then(|balances| balances.get(&dimension).cloned())
}
// 残りのメソッドも同様に実装
}
}
上記のコードはRustで記述されたスマートコントラクトである。以下にコードの解説を示す。
-
useディレクティブ:
- std::collections::HashMap: HashMapを使用するためのライブラリ。
- std::time::{SystemTime, UNIX_EPOCH}: システム時間を取得するためのライブラリ。
- sha2::{Sha256, Digest}: SHA-256ハッシュ関数を使用するためのライブラリ。
- rand::seq::SliceRandom: ランダムなシーケンスから要素を選択するためのライブラリ。
- ink_lang as ink: Ink!言語の機能を使用するためのライブラリ。
-
ink::contractマクロ:
- love_record_nftモジュールをスマートコントラクトとして定義するためのマクロ。
-
LoveRecordNFT構造体:
- records: レコードを格納するHashMap。
- token_id_counter: トークンIDのカウンターを管理するLazy変数。
-
Record構造体:
- subject: 主題を表すバイト列。
- dimension: 次元を表すバイト列。
- description: 説明を表すバイト列。
- is_approved: 承認されたかどうかを示すフラグ。
-
DimensionInfo構造体:
- role: 役割を表すバイト列。
- is_open: オープンかクローズかを示すフラグ。
-
impl LoveRecordNFTブロック:
- new関数: LoveRecordNFTの新しいインスタンスを作成するコンストラクタ。
- set_dimension_role関数: 次元ごとの役割とフラグを設定する関数。
- get_dimension_role関数: 次元ごとの役割とフラグを取得する関数。
- send_love_currency関数: 愛貨を送信する関数。
- get_love_currency_balance関数: ユーザーの残高を取得する関数。
- create_record関数: レコードを作成する関数。
- approve_record関数: レコードを承認する関数。
- get_record関数: レコードを取得する関数。
-
impl DimensionInfoブロック:
- new関数: DimensionInfoの新しいインスタンスを作成する関数。
このスマートコントラクトは、次元ごとに異なる役割とフラグを設定し、それに基づいて愛貨の計算や取引を行う。それぞれのユーザーに対して、各次元ごとの残高を保持し、取引時に残高を更新する。また、フラグの取得も可能である。
いかがであろうか、これがオープン”・”クローズ”フラグについてであった。このフラグは必須であろう。やはり、社内は愛の行動を仲間内でやりやすい。社内ばかりになってもダメなので、社外を分けて考えるのは重要であろう。