Wait a moment...

お悩み相談:既存のポイントシステムをブロックチェーントークンで実装する優位性は何かある?

nem79.85xem (9)
1413
45
2020-09-25 14:05:11
お悩み相談:既存のポイントシステムをブロックチェーントークンで実装する優位性は何かある?

みなさん、こんにちは。
nemlogの運営を始めてから2年、nemgraphは1年が経過したそうで。早いですね。
細々ではありますが、皆さんのお陰でコツコツやってこれました。ありがとうございます。

「そろそろ新しいものを作りたいな~」などと考えているわけですが、NEMというものを知ってしまったが故に「ブロックチェーン(以下BC)を使わなきゃ!」という強迫観念で思考の幅が狭まっています。自由な発想からアイデアが生み出されるのではなく、「BCを使うこと」から思考が始まってしまうんですよね。


お叱りを受けそうなので、この記事を書くか書かないか迷ったのですが、新しい開発に関して「何かいいヒントがもらえればラッキー!」ぐらいの気持ちでもう少し書いてみます。

 

まず、みなさんご存知の通りnemlog、nemgraphはNEMのブロックチェーンシステムを使ってます。これらはNEM現ナマを使うので、BCを活用する意味は多少なりあると思っています。なかなか個人間で価値を送りあうことはできませんからね。秘密鍵の扱いに関しても工夫ができたことはよかったと思っています。(未だに「よくわからないから鍵をメモしませんでした。僕のお財布どうしてくれるんですか?」という裏での戦いは微レ存。。。つらい。)


しかし、現ナマを使う以上のBC「有効」活用方法が思いつかないのです。イメージ貧困なのです。BCを使ってできるコトはたくさんあるのですが、どうも既存システムと比較した時の「優位性」と「合理性」が見い出せないでいます。まぁ、やりたい内容にもよるんでしょうけど、とにかくイメージ貧困なのです。データをハッシュ化してTxに記録したり なんて使い方もしてますが、法的根拠なんてものはないし。要は自分の作るものにDecentrizedが真に必要なものが無いってだけです。「じゃあ使うなよ。」で議論は終わりなのですが、ハーベストがもっとたくさん発生するようなシステム作りたいじゃないですか。(これが強迫観念ですね)

 

以下悩んでいることの一例、まぁ表題ですね・・・。みんな大好きモザイクです。
今とあるサービスを作成中で、その中でポイント的なものを付与する仕組みを入れるか入れまいかで迷っています。(完成させるかは未定ですが、基幹部分7割くらいは作ってある。Android&iOSアプリ。)
当然NEMを触っているエンジニアであれば、Decentrizedの必要性を考える以前に「あ、モザイク使えんじゃね?」って盲目的に思考してしまうのが自然です。オレだけか。しかし実際モザイクを使ったサービスもありますよね。

 

この現在検討中のポイントシステム実装に際し、従来システムに倣い「データベース」で実装するか、それとも「Symbolモザイク」で実装するのかで葛藤しております。イメージ貧困ゆえにモザイクを使う優位性というか意義が見い出せないのです。厚かましくも何かヒントがあれば頂きたいのです。「モザイクを使うとこんな優位性があるぜ!」っていうのを。悶々と考えていて思考が前に進みません。せっかくなので使いたいとは思う。(あ、これが強迫(ry )


データベース・モザイクに関して、今思うそれぞれのメリットデメリットを未整理で殴り書きました。こんな感じ。もっとあるんでしょうけど、ざっと。

 

データベース(ご存知の通り、世のポイントシステムはほぼこっち)

  • ポイントの残高更新が即時
  • webサービス上であれば、ポイント運用に係わる追加コストはほぼ0
  • サイト内の仕組み・アルゴリズムと連携しやすい。自サーバー内で事が完結する。
  • サイト上にデータ保管の為、運営が操作可能。データ飛ぶ可能性が0ではない。


Symbolモザイク

  • Symbolホルダーにハーベストのチャンス!(唯一のメリット???)
  • ポイント残高の更新が数十秒 (大きな問題とは考えていない)
  • Tx詰まると面倒、reorgとかになると更に面倒 (可能性は小か?)
  • ポイント発行・使用の手数料が都度発生。(AggregateTxでローコストではあるが)
  • ポイント用ウォレットアドレスをサイト側で管理しているのであれば、運営が操作可能。データ飛ぶ可能性が0ではない。Failure modeは異なるが結局DBと一緒。
  • ポイントだけのウォレットならカストデイ規制の対象外だと思ってますが、もし規制対象であれば、ユーザーサイドでのポイント管理が必要となる。その際、非仮想通貨民に鍵の説明やらが面倒、そして当然の様に鍵を無くす&再発行できないとは何ごとだ!となる。(nemlog & nemgraphでも このやり取りが裏で相当数繰り広げられている。疲れた。)
  • ユーザーが財布管理の場合、サイトデータが飛んでもポイントは残る。要るのか?ってのは置いといて。あとユーザー間でのポイント受け渡しが自由で楽しいのかも。(手数料はいるが)
  • ポイントの偽造がしにくい。(ポイントの偽造なんて聞いたこともないが。)
  • 色んな所で使えるポイントに発展するのであれば優位性はありそう。しかし個人開発・小規模開発でこの可能性は0に近い。自分が展開するサービス内での流通はありだとは思うが、はて。


モザイクに関しては「ノンプログラマー」が自由に・気軽に発行して遊べるってのが楽しいところなんですよね。しかしデータベースタイプで自由で気軽なトークン発行システムが提供されれば、同じことなんじゃ・・・。と思ってしまったり。手数料いらんし。BCでビシッとdecentrized管理しないといけない個人お遊びトークンがあるとも思えん・・・。BCトークンやモザイク等々をディスっているわけではありませんので、誤解されませんよう。僕のイメージが貧困なだけです。

 

運用コスト以上の優位性があればグイグイいけるんですけどね。「なんでモザイクにしたんですか?」って聞かれた時に困る。クールにキメれる理由があればベストなんですが。。。色々な与太話、脱線話をしてしまいましたが、要点は「既存のポイントシステムをモザイクで実装する優位性は何か?」です。本質が見えていないのは僕だけなのかもしれませんが、悩んでます。

社会的な課題に取り組む(それこそ今トレンドのハンコとか)以外、Just enjoyだと「それ、BCでやる必要ないよね。」に陥るパターンが多い。オレも心の中では相当数突っ込んでいる。それを避けるための思考能力が欲しいですね。いいコにしてたハズだからサンタにお願いしようかね。。。

Comment
naokits
naokits
2020-10-27 13:31:10ID:213665
>>
しゅう:nemlog作ったモヒカン

取引所とかではなくて、個人でワレット管理する場合は、秘密鍵の管理必須になってしまうけど、非エンジニアの人たちにしてみれば、「秘密鍵?なにそれおいしいの?」状態でしょうから、重要性を理解してもらうのは難儀するとおもいます。実はすでになくしてしまっている人も多かったりするのではないでしょうか。。

家や車の鍵をなくすのと同じくらい重要なことだと理解してもらうしか無いでしょうね。。

目指せ北海道
目指せ北海道
2020-10-05 06:10:54ID:210667
>>
ボー太郎

そうなんです。保留ラーメンの考え方って、参考になると思います。ポイントを、個人所有にするのではなく、サービスを受けるすべてのユーザーで共有してもらうから、公益性があります。「おかげさま」や「ありがとう」の気持ちをポイントに乗せるわけです。

ポイント=現金という考え方からは、なかなかブロックチェーンのメリットは出てこないのですが、ポイントに気持ちを乗せることができれば、ほっこりした良いサービスが実現できる気がするんですよね。

ボー太郎
ボー太郎
2020-10-03 15:46:03ID:210292
>>
目指せ北海道

ポイントに絞ってしまうとそうですね。保留ラーメンすごく良いですよね!これはポイントでもBCの出番のような気がします!
対象のMOSAICにどれぐらいの複合的な価値の重さが乗っているか?という事かもしれません。
そういった目線で見ていくとポイントでもBCが有効なパターンが見えてきそうですね!素晴らしい!

目指せ北海道
目指せ北海道
2020-10-01 07:44:35ID:209897
>>
ボー太郎

まとめると、多くの人が共有する公的な情報はブロックチェーンに、少人数のコミュニティーで一過性に使われるポイントはデータベースに軍配が上がりそうですね。

そこでこういう風に考えてみたらどうでしょう。ブロックチェーンが本質的に持っている公益性が、最大限に発揮されれば、もしかしたらこの図式に当てはまらないようなサービスが生まれるかもしれません。そのひとつの可能性が、屋台けいじさんの保留ラーメンです。屋台という小さなコミュニティなんだけど、そこに公益性(お金のない人にラーメン奢る)が生じた時、ブロックチェーンの透明性や改ざん不能性が意味を持ってくる。そういう観点からなら、モザイクを使ったポイントでも同じようなサービスができるんじゃないかなと思います。

ボー太郎
ボー太郎
2020-09-30 21:40:06ID:209767
>>
目指せ北海道

いえいえ、恐れ多いですw 扱うデータは公けかつ重要なデータになりますよね。
資格情報は結構いいと思います。ログイン認証なんかをmosaicでするともう一段上のセキュリティを構築できるかもしれません。

僕が勝手に想像してる未来は電気水道ガス使用量、製品の製造工程、野菜に水をあげた量や日照時間などのあらゆるMOSAIC情報が、ブロックチェーン上にすべて記録そして公開されていて、膨大なデータをAIが捜索して欲しい情報にたどり着くようなイメージをしています。
たとえば、スーパーで野菜をスマホにもしくはARグラス等のデバイスでスキャンすればAIがその野菜の栽培履歴や出荷情報などを表示してくるような仕組みになっていくと思います。

NEMのQRコードなどで一意に管理できそうですよね。
そのためにはNEMのようなブロックチェーンが必要だし、あらゆるものをトークン化するのはまさに僕のイメージ通りですw
ポイントと言うよりは見えなかったものを見えるかする時の担保のようなシステムとも言えるかもしれません。

目指せ北海道
目指せ北海道
2020-09-30 07:52:06ID:209706
>>
ボー太郎
しゅう:nemlog作ったモヒカン

ポー太郎さんのコメント見て、そうだった!ShizuiNetって、ある種の公共サービスだからブロックチェーンなんだって、思い出すことができました(忘れてたのかよw)。

サービス提供者がいなくなった後も、そのデータが継続利用される場合には、ブロックチェーンはとても意味のある仕組みですよね。「北海道死すとも、ShizuiNetは死なず!」とか言いながらこの世を去ってみたい。

そういうデータってなんでしょうね。やっぱりお金?医療や健康データ?芸術作品とかもそうかもしれません。あと資格情報とか。

ポイントというのは、サービス提供終了と同時に不要になるものとして発行されるから、サービス提供者が持つDBと一体化していて良いんですよね。じゃあ、そうじゃなくて、サービス終了後も必要になるポイントや情報って、なんでしょう?

ようやく僕にも話の流れが理解できてきました。皆さんの思考についていくのは大変ですが、とても勉強になります。ありがとうございます!

ボー太郎
ボー太郎
2020-09-30 07:26:55ID:209703
>>
しゅう:nemlog作ったモヒカン

効率的に考えるとそうなりますよね😂
でもBCもしくはnemじゃないと駄目な理由が気づいてないだけであるかも…。
哲学っぽいですがもし発見されればnem旋風が巻き起こりますね!
研究する価値はあるかも😀

しおじい
しおじい
2020-09-29 21:37:05ID:209647

う~ん、大規模ならDBのコスト削減で他人が建てたノードに相乗りするというのが言いやすいけど、小規模だとそんなに問題にならないですからね。
あと、どうしても承認されるまでに時間が掛かるので、リアルタイム性の高い仕組みだとDBを選択した方が確実ということになりそう。

DBかどうかと言うよりも、既存のポイントカードとは違う運用を模索する方が、モザイクに適したものが生まれそうな気もする。
たとえば、非リアルタイムで、任意に交換可能なポイントとか?

・ポイント発行はリアルタイムである必要が薄い
 1時間後、半日後、1日後とかに自動でポイント発行して、リマインドやリピーター獲得のために使う
 忘れた頃に通知が来ると思い出してもらえそう
 リアルタイム性が低くて問題ない運用なら、DBである必要もないし、自前のノードも不要

・複数のポイント(モザイク)を作って交換可能にする
 発行種類はランダムで、トレーディングカード的な立ち位置にする
 集めることを目的の一つにする
 交換によって、他者にサービスを周知する効果も期待
 ポイントを使った後は、ゲームの実績みたいな感じで転送不可モザイク(ってシンボルでも出来たっけ?)を代わりに発行して、後から記録を確認出来るようにする

なんとなく思いついたのはこんな感じですかね?
DBでも出来るけど、ポイント交換の仕組みとかは、ただのモザイク送信なのでDBでわざわざ管理しなくて良いという利点はありそう。
ポイント改ざんの心配も無いので、セキュリティ的にも問題なし。
間違えて送信してしまった・・・みたいなケースはDBと違って対応できない問題はあるので、あえてポイントの価値を高めすぎない必要はあるかも。

しゅう:nemlog作ったモヒカン
しゅう:nemlog作ったモヒカン
2020-09-29 19:56:35ID:209637
>>
案山子の優午

データベースでもトークンのやり取りをユーザー間で行うことは全然可能なんですよね。
BCで実装するよりはるかに簡単に・・・。だからこそ、そこにわざわざBCをはさむ意義はなんなのかと悩んでおります・・・。難しい・・・。

この記事を書いた人
nemlog、nem store、nemgraphを作った人。 これら全部ひとりでプログラム書いて、英訳したと思うと吐き気がしますな。