アーキテクチャーに関して

基本的なwebサービスと比べて、blockchainで実装されたDappsも自分の理解ではコントラクト部分以外のクライアント、サーバーサイドやデータの持たせ方などはwebと変わらないので、基本的にアプリケーション自体に幅を持たせるのはweb developmentとそこまで変わらないなあと思った。

ただ、その場合、dappsを量産させたり、早く実装させるためにはコントラクトの部分以外は変わらないので満遍なくやれる方が良いなという考え方であることにはまちがいない。

一方で、限られた時間的リソースをどこに注入するべきかと考えたときに、プロトコルレイヤー、コントラクトやapi呼び込みや関連開発ツールをossベースで追っていきつつ、長期的にプロトコル開発と同時並行で自分のdapps?、もしくはトークン設計や、コントラクトの特性を活かしたアーキテクチャを深く考えて実装した方が良いかもしれないなとも感じてきた。

いずれにせよ、アウトプット→思考という流れには変わりはないんだけれども、良いdappsを作れるようにという考え方よりはプロトコルや、どんな意味をもたらすのか、アプリケーションレイヤーよりもっと低レイヤーのところでこれからどんなアプリケーションが乗っかっていってどのような価値を生み出すのか。どういったところが他のプロトコルとの差別化要素なのか。どうしてこのプロトコルをみんな使うのか。何がバイラル要素なのか。ということを考えながら開発を進めていった方が賢い。

理由は簡単で、みんなが理解できないけど、本当に意味のあるものを作った方が、ファストファッション競争みたいな無駄な戦をせずに、価値に気付いた時にはそれを作り出したプロセスの理解もなく、ナレッジの蓄積もないので他の人たちの戦意喪失させつつ、競争に巻き込まれないで自分の本当に取り組むべきプロダクト開発、事業推進に集中することができるからと思った。

現状は、dapps開発にはcontract以外の多くのweb開発要素、分散化してない部分が多く影響している。ただ、開発が進むにつれて、データの持たせ方はipfsやswarmのように非分散化していくし、eosの上に全てのアプリケーションが乗っかっていったり、cosmos sdkの上にアプリケーションを実装していく世界観も見えていくし、polkadotのように全てがつながりあう世界観も見えていくので、長期的にどういった要素が必要になりうるのかということをきちんと自分の頭で考えつつ、手を動かしながら、みんなが盛り上がっている部分よりも本質的な価値にのみ目をむけつつ開発を進めていきたいなと思った。