週刊Life is beautiful ２０２２年１１月１日号：Halloween

今週のざっくばらん Halloween 今年もハロウィンの季節になりましたが、渋谷の交差点で大人たちが大騒ぎをする日本と違って、米国のハロウィンは、子供たちにとっての一大イベントです。 ハロウィンの日（１０月３１日）の夕方に、子供たちが束になって近所の家を一軒づつ訪問し、「Trick or Treat（「いたずら」か「おやつか」）と言って、おやつを集めるのです。 訪問される方も、カボチャで作ったランタンを飾ったり、庭に骸骨を置いたりして子供たちを歓迎します。子供たちを通して、近所付き合いを深める、という意味合いもある、とても健全なイベントです。 下の写真は近所を歩いている時に撮影したものですが、米国の住宅地をこの時期に歩くと、こんな風景を見ることが出来ます。 On-Chain Bitcoin Art 先々週にリリースしたOn-Chain Splatterに続いて、フルオンチェーン・ジェネラティブ・アートNFTコレクション、On-Chain Bitcoin Artを日曜日（日本の月曜日）にリリースしました。 当初は、日本の週末に間に合わせる予定だったのですが、ベータテスト中にバグが見つかったことに加え、二次流通市場を提供している OpenSea のサービスが不調だったため、１日延期したのです。 Splatter との大きな違いは、ビットコインのロゴのデータを事前にデプロイしてあった On-Chain AssetStore から取得している点です。AssetStore にはクラウドミント（ベクトルデータをブロックチェーンに書き込むコストを皆さんに負担してもらうこと）により 1,500 個以上のベクトルデータが集まっていますが、その最初の応用例として作ったのです。 アーキテクチャは以下のダイアグラムの通りです。 新たにデプロイしたのは、青色の５つのスマートコントラクトです。 AssetStoreProvider は、AssetStore に（後から定義された）IAssestProvider インターフェイスでのアクセスを可能にするためのラッパーです。もし、AssetStoreをデプロイした時から、IAssetProvider の構想があったら、最初から組み込んでいたと思いますが、既にデプロイしたものを変更することは出来ないので、ラッパーで対処します。 ちなみに、ラッパーとは、ソフトウェア業界の言葉で、既存のを特定のインターフェイスをサポートするために、既存のモジュール（ソフトウェアの部品）を包み込むように作る別のモジュールのことです。アダプターと呼ぶ人もいます。 CoinProvider は、AssetStoreProvider から取得したビットコインロゴの周りに丸を表示するモジュールです。技術的には、次に説明する RepeatProvider にこの機能を組み込んでも良かったのですが、RepeatProvider を再利用しやすくするために、こんなアーキテクチャにしました。 RepeatProvider は、CoinProvider から取得した画像を ColorSchemes から取得したカラースキームを使ってランダムに配置する役割を果たしています。 ColorSchemes は、１５種類のカラースキーム（色の組み合わせ）を持つ、リードオンリーなライブラリです。本来なら、Splatter をデプロイした時に、これを作っておくべきでしたが、今後のジェネラティブ・アートのために、再利用可能な形で、デプロイしました。 BitcoinToken は、（NFTの標準である）IERC721をインターフェイスとして持つコントラクトですが、画像とメタデータは、全て RepeatProvider から取得しています。BitconTokenが SplatterToken を参照しているのは、SplatterToken を持った人に対して割引を提供するためです。 ITokenGate というインターフェイスは私が定めたインターフェイスですが、IERC721の balanceOf メソッドと同型のメソッドを一つだけ持つインターフェイスなので、既にデプロイされている IERC721 インターフェイスを持つコントラクト（つまり、すべてのNFTコントラクト）は、このインターフェイスを自動的にサポートすることになります。 UIEvolution起業話（４） Sun Microsystems および NTT DoCoMo から入手した携帯電話向けのJavaの開発環境を触り始めてすぐに認識したことは、それが’とても限定されたものだ、ということです。アプリケーションのサイズは３０キロバイトに限定されていたため、複雑なアプリケーションを作るのは非常に困難だったのです。 そこで私が開発を始めたのは、この「大規模なアプリケーションを作ることが出来ない」という問題を解決するための仕組みでした。基本的なアイデアは、今でいうところの（ReactやVueを使った）リアクティブな１ページアプリケーションと似ています。アプリケーションの本体はサーバー側にあり、必要なユーザーインターフェイスとデータだけクライアント側に取得し、状態遷移を使ってインタラクティブなユーザーインターフェイスを提供する、というものです。 最初はブラウザー上にJavaScriptでプロトタイプを作り、それを携帯端末向けの Java (J2ME）に移植するというプロセスで行いました。 現代であれば、パソコンと同じ機能を持ったブラウザーがスマートフォン上で動いているので、そんなものは必要はありませんが、当時は画期的なもので、まだ誰も見たことがないような複雑なアプリケーションがJava端末の上で動き始めていました。 サーバー側のアプリケーションのUIを携帯端末に届ける役目を担うプラットフォームなので、名前はUIEngineと名付け、アプリケーションを記述するマークアップ言語をUJMLと名付けました。 そこで早速、Ignitionのパートナーたちに対して、この技術をベースに会社を興したいと説明すると、とても喜んでくれ、すぐさに投資が決まりました。私のプロトタイプの価値を $5M と見なして、$1.5M を投資する、という条件です。会社の名前は UIEvoluition に決まりました。 私にとっては何もかも初めての体験でしたが、この起業のプロセスに関しては、とても良い動きが出来ました。私がMicrosoftのストックオプションで作った資産の運用を任せていた人が、いくつかとても良いアドバイスをくれたからです。 最も価値があるアドバイスは、「弁護士料をケチってはいけない」というものでした。そこで、Venture Law Group という当時はシリコンバレーでも良く知られた弁護士事務所を雇い、Ignition との交渉をすべて任せました。