Rust/DApp実習 - 設計する#1

とりあえずできることからやっていこう
平たく言うと、今日はユースケースを書く日だった。

やったこと

アイデア出しが苦手な自分、そんな自分が苦手な「ユースケース図」を書く時間だ。

Flowchart Maker & Online Diagram Software

ユースケース図を頑張って書いた

↑このシステムで実現したいユースケースを整理した。
１〜９の番号を振ってある。３，６，９はスマートコントラクトになる想定でいる。

１．学習の記録
２．フィードバックの記録
３．記録の承認（トークン発行）※スマートコントラクト

４．チャレンジのお気持ち表明
５．トークン->内申点交換（トークン償却）　※スマートコントラクト
６．評価する気持ちだけは。

７．ご褒美だす
８．ご褒美リクエスト
９．トークン->ご褒美（トークン償却）※スマートコントラクト

次のアクション

次は、コレをもとに、アーキテクチャを設計していく。

NEARブロックチェーン, Rust, Next.jsの３つの技術を使うことを念頭において、このシステムに適したアーキテクチャ設計を考える。

クラウドサービスのRDBMS,NoSQLサービスを使ったデータの管理と、ブロックチェーン上での台帳管理の両方を使ったシステム構成で考えていくことになりそう。

参考にできるアーキテクチャも探していこう。
SPAサイト(Web3/Web2クライアント), スマートコントラクト, OAuth, RPC/GraphQL/NoSQLあたりが構成要素になると思う。

以下、備忘録。

• トークンを発行するシステム

  • 学習の記事の実態はnoteの記事のURLだと仮定。

  • トークン発行時には、URLをどのような条件で検証し、どこで保管するか。

    • URLの記事は変わってしまう可能性がある。

      • 複製をブロックチェーン上に保管するのは可能（適当）なのか？

• 発行したトークンを交換するシステム

  • 評価または褒美と交換する

    • トークンの償却はオンチェーンで行うことが必要。

    • 交換するご褒美管理もオンチェーンか？

      • このユースケースでは家に何かが届くらしい（書くんじゃなかった）どのような設計で考えればよいか。

        • 褒美を出品する仕組みもオンチェーンにすべきか？

      • こういうの、CryptoPunk NFT x ティファニーでも似たようなことを考えていそう。どう管理・制御してる？

    • 交換する褒美をオンチェーンで管理しても、配送までは制御できないのでは

      • 結局オフチェーンとの接点は出てくると思った。

補足

githubリポジトリの準備。

NEARが公開してるスマートコントラクトとdAppのテンプレートリポジトリを発見。さっそく複製。

以下のリポジトリを作っておいた。概ねここで開発を進める。

全然関係ないけれど、Gitpodすげぇ！便利！

準備を地道に進めていく。
また次回！